Take a close look at BARK's functions and you will see that most of them are simple wrappers around basic REST API calls. This means it's very easy to extend BARK.
For example, BARK is missing a function to list virtual machines. Here's how easy this is to add: 🧵
Let's look at an existing function that lists objects in AzureRM, "Get-AllAzureRMResourceGroups":
The most "difficult" line we need to change is line 24. We must ensure we are hitting the right URL.
The Microsoft documentation can help us here. We will Google "azure api list virtual machines", and the first result is this page:
From initial access to Global Admin with #BloodHound and BARK.
In this thread let's walk, step by step, through an example attack path based on real configurations we've seen in real environments:
There are MANY ways to achieve initial access into AzureAD. For this example we will go with something simple: we were able to phish a user and get their username and clear text password.
This user has no MFA/CAP restrictions - we'll discuss how to deal with these later.
We now want to collect data with AzureHound. We'll clone the repo, inspect the source code, then build the binary ourselves:
If you're like me, you are angry and disappointed at SCOTUS striking down Roe v Wade. You might also be exhausted and feel defeated.
Here are three things you can do RIGHT NOW to help defend women's rights in the United States. This will take you THREE minutes. Do these NOW: 🧵
First and most importantly, contact your congressional rep and tell them you support the Women's Health Protection Act, which will protect abortion access for every person in every state.
Second, contact your healthcare provider and ask them to do the same thing. Lawmakers need to hear from healthcare professionals that abortion is safe, abortion is normal, and that abortion is health care.
Where do #Azure attack paths come from? Attack paths that abuse (mis)configurations generally emerge from two types of control in Azure: explicit control and implicit control.
Let's see what that means and how you as a defender can eliminate the most dangerous paths:🧵
Explicit control means there is a one-to-one control relationship clearly defined on the controlled object. For example, Azure Users can be made explicit owners of Azure Service Principals:
David owns MyCoolAzureApp, meaning David can add a new credential to that Service Principal and authenticate as it, taking over the identity.
But this explicit configuration does not exist in isolation: there are paths INTO the user OUT of the SP:
One year ago this week I published The Attack Path Management Manifesto, which you can read here: medium.com/p/3a3b117f5e5
It's a long read, so in this thread I'm going to give you the most succinct version of the manifesto I can:
Adversaries have been abusing identity-based attack paths -- in particular those that emerge in Active Directory environments -- for over 20 years. Why? There are three major reasons:
1. Active Directory is the FOUNDATION upon which all identity and access in the enterprise is built. Your workstation? AD auth. Your CI/CD pipeline? AD via ADFS. Your network devices? AD via RADIUS.
Control the foundation and you control the enterprise.
"...this case does not meet the bar for servicing by MSRC and we will be closing this case..."
and:
"...This is considered by-design..."
A quick thread on what the "issue" is and why MSRC is right 🧵
While preparing for my @WWHackinFest talk, I was creating demo videos showing Managed Identity abuse primitives in various Azure services. For example, you can remotely extract the JWT for a VM's managed identity like this:
My abuse primitive demo for Logic Apps was a little different: I was using the Logic App to add a secret to another Service Principal, then capturing the output in the Logic App, showing the other Service Principal's new key credential in plain text: