Initial Access

Password Spraying, etc.

This is a low-skill attack vector that still works very well. Be aware that this is very noisy and can (will) lead to detection in a well-managed environment.

Typically you send a single password against multiple users (the users have to be identified first, e.g., through OSINT and o365creeper).

Tools for spraying would be MSOLSpray, if you have an account you should also check for MFA-configuration with mfasweeper.

An alternative to brute-forcing would be Phishing Azure Accounts.

Attacking Web Applications

Web Applications are still web applications, if they contain vulnerabilities (and they will) we can abuse them to get an initial foothold into the azure tenant.

Very often app-workers are used:

• free/shared run on shared VMs
• standard/premium is on separated VMs
• part of an app service plan
• network shares, filesystems, powershell or cmdline (both low privilege)

If the service uses managed identity, we might have permissions on other resources. This is similar to database connection strings on traditional web applications. Typically we try to get the used managed identity by querying environmental variables ( IDENTITY_HEADER and IDENTITY_ENDPOINT).

Typical web vulnerabilities (insecure file uploads, SSTI, OS Command Injections) are detailed in Abuse Public Web-Application.

Illicit Consent Grant Attack

This is a special form of phishing attack: instead of trying for user credentials, this attack tries to lure an user to install a new application within their tenant. The attacker can then use the application’s identity to further enumerate the tenant (with the access rights/permissions of the accepting phishing victim).

This depends upon an Azure Tenant that allows for registration of multi-tenant applications (the phishing application is within the attacker’s tenant and is registered within the phishing victims tenant). The phishing application has the requested OAuth2 permissions listed within it.

Typically, during an initial phishing attack, only low-privilege permissions are requests (those are permissions that a normal user can give) and used for further enumeration (e.g., emails, calendars, users). In a subsequent targeted phishing attack, more elaborate (i.e., admin rights) can be requested.

For further details see Illicit Consent Attack

Storage Accounts

Often public storage accounts are forgotten and juicy data can be found within them.

The following access methods can be configured for an Azure Storage Account:

• azure AD credentials, RBAC roles are supported
• share keys: full control to storage account
• shared access signature
• there is anonymous access

To enumerate this, check enumerate storage accounts. For accessing the storage account, use Microsoft Azure Storage Explorer.