[vc_row][vc_column][vc_wp_text]

[xyz-ips snippet=”metadatatitle”]

[/vc_wp_text][vc_empty_space][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_column_text]

[/vc_column_text][vc_empty_space][vc_column_text]

$a = Get-AzureADMSRoleDefinition | Where-object {$_.DisplayName -eq 'Company Administrator'}
$a.RolePermissions.AllowResourceActions

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

Notice the ‘microsoft.directory’ namespace. That entire namespace is restricted to Azure AD.

Comparatively, the role definitions for ‘Contributor’ in Azure looks like this

[/vc_column_text][vc_empty_space][vc_column_text]Get-AzRoleDefinition[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

Notice that for the Contributor role in Azure, the ‘actions’ property has wildcard (*). This means it can do anything to resources in Azure. However, the ‘NotActions’ property defines what it cannot do, which for the Contributor role, means it cannot add or remove users to resources which is defined in the Microsoft.Authorization/*/Write definition. That is restricted to the ‘Owner’ role.

Azure AD Privilege Escalation via Service Principals

Applications exist at the Azure AD level and if an application needs to perform an action in Azure or Azure AD, it requires a service principal account in order to do that action. Most of the time, service principals are created automatically and rarely require user intervention. On a recent engagement, we discovered an Application’s service principal was a Global Administrator in Azure AD. We then scrambled to find out how to abuse this, as it’s well known you can login to Azure PowerShell as a service principal. We then looked at the ‘Owners’ tab of the Application and saw a regular user was listed as an Owner.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]Owners of applications have the ability to add ‘secrets’ or passwords (as well as certificates) to the application’s service principal so that the service principal can be logged in.[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

The low privileged user could then add a new secret to the service principal, then login to Azure PowerShell as that service principal, who has Global Administrator rights.

The next question we had, was how far could this be abused? So, as Global Administrator, we control Azure AD, but how can we control Azure resources?

Sean Metcalf published an article explaining that Global Administrators have the ability to click a button in the Azure portal to give themselves the ‘User Access Administrator’ role in Azure. This role allows you to add and remove users to resources, resource groups, and subscriptions, effectively meaning you can just add yourself as an Owner to anything Azure.

At a first glance, this toggle switched looked only available in the portal and since service principals cannot login to the portal, I thought I was out of luck. After digging through some Microsoft documentation, there’s an API call that can make that change. After making this a function in PowerZure (Set-AzureElevatedPrivileges), I logged into Azure PowerShell as the service principal and executed the function which gave an odd result.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

As it turns out, after a GitHub issue was opened & answered, this API call cannot be executed by a service principal.

So putting our thinking caps back on, we thought of other things a Global Administrator can do — like creating a new user or assigning other roles! So, as the service principal, we created a new user, then also gave that user the Global Administrator role. I logged in as the new user, executed the API call, and it successfully added the ‘User Access Administrator’ role to them, meaning I now controlled Azure AD and Azure, which all started from a low-privileged user as an Owner on a privileged Application’s Service Principal.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

Moving from Cloud to On-Premise

With Azure and Azure AD compromised, our next goal was to figure out a way to move from Azure into an on-premise domain. While exploring our options, we found that Microsoft’s Mobile Device Management (MDM) platform, Intune, wasn’t just for mobile devices. Any device, meaning even on-premise workstations & servers, can also be added to Intune. Intune allows administrators to perform basic administrative tasks on Azure AD joined devices, such as restarting, deployment of software packages, etc. One of the things we saw, was that you can upload PowerShell scripts to Intune which will execute on a [Windows] device as SYSTEM. Intune is technically an Azure AD resource, meaning only roles in Azure AD affect it. Since we had Global Administrator privileges, we could upload PowerShell scripts at will to Intune. The devices we wanted to target, to move from cloud to on-premise, were ‘hybrid’ joined devices, meaning they were both joined to on-premise AD and Azure AD.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]To do this, we used the Azure Endpoint Management portal as our new user to upload the PowerShell script.[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

In Intune, there’s no button to “execute” scripts, but they automatically execute when the machine is restarted and every hour. After a few minutes of uploading the script (which was a Cobalt Strike beacon payload), we successfully got a beacon back and moved from cloud to on-premise.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

This can also be abused purely through PowerZure using the New-AzureIntuneScript and Restart-AzureVM functions.

[/vc_column_text][vc_empty_space][vc_column_text]
[/vc_column_text][vc_empty_space][vc_column_text]

Abusing Logic Apps

Of the many things we’ve researched in Azure, one interesting abuse we found came from a Logic App.

Logic Apps have two components: a trigger and an action. A trigger is just something that can be enabled to put the action into effect. For example, you can make an HTTP request a trigger, so when someone visits the URL, the trigger enables the action(s). An action is what you want the actual logic app to do. There’s literally hundreds of actions for multiple services, even some from third party applications and you can even create a custom action (might be interesting).

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]One that particularly stood out was AzureAD.[/vc_column_text][vc_empty_space][vc_column_text]
[/vc_column_text][vc_empty_space][vc_column_text]

Unfortunately, there wasn’t any really juicy actions like adding a role to a user, but the ability to create a user was an interesting case for a backdoor and adding a user to a group could mean privilege escalation if certain permissions or roles are tied to that group.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

The question then was “What privileges does this logic app action fire as?”. The answer is that logic apps use a connector. A connector is an API that hooks in an account to the logic app. Of the many services available, there’s many that have a connector, including Azure AD. The interesting part of this abuse was that when I logged into the connector, it persisted across accounts, meaning when I logged out and switched to another account, my original account was still logged into the connector on the logic app.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

The abuse then, is that you’re a Contributor over a logic app which is using a connector, then you can effectively use that connector account to perform any available actions, provided the connector account has the correct role to do those actions.

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

Due to the sheer amount of actions available in a logic app, I chose not to implement this abuse into PowerZure at this time, however you can enumerate if a connector is being used using the Get-LogicAppConnector function.

[/vc_column_text][vc_empty_space][vc_column_text]

PowerZure 2.0

[/vc_column_text][vc_empty_space][vc_column_text][/vc_column_text][vc_empty_space][vc_column_text]

I’m happy to announce that I’ve re-written all of PowerZure to follow more proper coding techniques, such as using approved PowerShell verbiage, returning objects, and removal of several wrapper-functions. One of the biggest changes was the removal of the Azure CLI and Azure AD module requirements, as PowerZure now only requires the Az PowerShell module to reduce overhead for users. All Azure AD functions have been converted to Graph API calls so the functionality still exists without needing the Azure AD PowerShell module. Finally, all functions for PowerZure now contain ‘Azure’ after the verb, e.g. Get-AzureTargets or Get-AzureRole .

If you haven’t already seen it, PowerZure now has a readthedocs page which can be viewed here: https://powerzure.readthedocs.io/en/latest/ which has an overview of each function, its syntax & parameters, and its output example. The aim is to make this much more easily adopted by people getting into Azure penetration testing & red teaming.

With PowerZure 2.0, there’s some new functions being released with it:

• Get-AzureSQLDB — Lists any available SQL databases, their servers, and the administrative user
• Add-AzureSPSecret — Adds a secret to a service principal
• Get-AzureIntuneScript — Lists the current Intune PowerShell scripts available
• New-AzureIntuneScript — Uploads a PowerShell script to Intune which will execute by default against all devices
• Get-AzureLogicAppConnector — Lists any connectors being used for logic apps
• New-AzureUser — Will create a user in AAD
• Set-AzureElevatedPrivileges — Elevates a user’s privileges in AAD to User Access Administrator in Azure if that user is a Global Administrator

As part of any upgrade, several old bugs were fixed and overall functionality has been greatly improved as well. My goal is to put any potential abuses for Azure & Azure AD into PowerZure, so as our research journey continues I’m sure there will be more to come.

[/vc_column_text][vc_separator style=”shadow”][vc_column_text]Source: https://posts.specterops.io[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_wp_text][xyz-ips snippet=”metadatatime”]

[/vc_wp_text][/vc_column][/vc_row]