Moving Around

These techniques target movement within the cloud environment.

Automation Accounts

Automation Accounts are used to automate tasks by executing scripts/programs on configured computers. The system is structured into two parts:

• automation accounts that can have attached credentials
• runbooks that describe what is executed during the automation

Execution of runbook is logged, there are multiple opportunities for leaked credentials:

• within the runbook (script) itself
• by modifying a runbook to output attached credentials
• within the runbook’s execution logs

A legacy option are so-called run as accounts which will be disabled in 2024-09-01: here the service-principal is contributor on the entire subscription! If you’re contributor on a runbook you can run any command as contributor!

If automation runbooks are run on on-premise machines, this is also an opportunity to move on-prem, see Abusing HybridWorkers

Continuous Deployment

• function apps
  • deployment slots
  • compromise source code repo
    • deployment center → check source code repo URL
• is your github identity as secure as your azure identity?

Virtual Machines

If an attacker gains contributor rights on an azure virtual machine resource, multiple venues of attack appear:

• Gathering attached user data (which might contain credentials): abuse user data attached to VM
• Directly running commands on the Virtual Machine: abuse command execution on VM
• Installing a new Virtual Machine Custom Script Extension for Command Execution: adding custom script extension to VMs

KeyVaults

If an application has access to a KeyVaults, dump all it’s data: there might be credentials in them.

internal phishing

Once you’re within the network, we can use the information gathered from within the directory to perform spear-phishing. Mostly we would use phishing for credentials with evilginx to emulate existing microsoft services to get users to give up their credentials.

Enterprise Applications

An attacker can either find an existing application managed identity, or add new client-secrets to an existing application. In both cases they can login as that application (typically bypassing MFA protections) and access other resources with the permission of the captured application.

See Enterprise Applications

Deployment History / ARM Templates

• infrastructure as code (biceps later on)
• each resource group has a deployment history (up to 800 deployments)
  • permission Microsoft.Resources/deployments/read
  • permission Microsoft.Resources/subscriptions/resourceGroup/read
• Should use SecureString for sensitive data
  • use older versions of ARM template which might use String
• search for configuration scripts that are downloaded from some URL

Dynamic Groups

By default, any azure user can invite new users as Guests. While guests accounts can be used for enumeration (Enumerate as a Guest), together with dynamic groups this can be abused for privilege escalation.

Dynamic Group membership can be determined through rules. Attackers can retrieve those rules and try to modify their user to fulfill the requirements to automatically join that group. For more information, see Dynamic Groups.

Device Identities

A user on a Azure AD joined device typically posses a PRT (primary refresh token) which is used for SSO. If an attacker is able to retrieve that PRT, they can login into, e.g., https://portal.azure.com with the identity of the victim.

For more information, see Device Identities.

Further Information

• https://cloudbrothers.info/en/azure-attack-paths/?utm_source=tldrsec.com&utm_medium=newsletter&utm_campaign=tl-dr-sec-216-azure-attack-paths-recipe-for-scaling-security-cybersecurity-incident-tracker