Cloud
Azure Concepts

Authentication & Authorization

Azure Access Concepts

  • There is nothing as direct user access to Azure (Entra ID or Resources). Only applications have access to Azure Entra ID and Resources.
  • If a user wants to interact with Azure Entra ID or Resources, He has to access through an application (ex: Azure Portal). and here the Azure portal website portal.azure.com is the application. When you open Outlook or Teams, Those are the applications.
  • There are 2 types of Access in Azure:
    • Application Access: The app acts by itself. There is no user present. This is used for background services, daemons, or automations that run on a server. Is done through Application Permissions and is also called App role assignments
    • Delegated Access:
      • An app acts with a user. There is always a signed-in user in the loop. It's used for interactive apps, like a PowerShell script you run on your machine or a web portal you log into.
      • So, when you run Connect-MgGraph -Scopes "User.Read.All", you are telling PowerShell: "I want to connect to Microsoft Graph. Please ask me, the user, to sign in and grant this script the delegated permission to read all user profiles on my behalf."

Claims

  • Are a key:value pairs in the JWT token that is used for authentication, authorization, role based access, SSO .. etc.
  • Optional claims maybe added to be used by Entra ID Applications, like Role Claims, Group Claims, Email Claimss, you can use custom claims as well.
  • nOAuth Attack:
    • If an Entra ID application is using a mutable claim like email for identification or authorization its vulnerable to this attacl.
    • For Defense you can use:
      • Use of sub Subject claim as the unique identifier.
      • Use xms_edov optional claim to check for email verification.
    • Email addresses with unverified domain are removed from the tokens. However, if required it can be turned off.

Authentication Flows

Authorization Code Flow

  1. User Accesses App: You navigate to a web application (e.g., the Azure Portal).
  2. Redirect to Azure AD: The application redirects your browser to the Azure AD login page login.microsoftonline.com.
  3. User Authenticates: You enter your username, password, and MFA.
  4. Authorization Code Granted: After successful authentication, Azure AD redirects your browser back to the application with a short-lived, one-time-use authorization code.
  5. Token Exchange (Back-Channel): The application's backend server takes this authorization code and securely sends it to Azure AD's /token endpoint, along with its own client ID and secret.
  6. Tokens Issued: Azure AD validates the code and the client's credentials, then returns the ID token, access token, and refresh token to the application's backend.
  7. API Call: The application now wants to list your VMs. It makes a call to the Azure Resource Manager (ARM) API and includes the access token in the Authorization header (as a "Bearer token").
  8. API Validation: The ARM API receives the request, validates the signature and claims of the access token, confirms it has the required permissions, and then returns the list of VMs.
  9. Token Refresh: An hour later, the access token expires. The application uses the refresh token to call the /tokenendpoint again and get a brand new access token without you, the user, noticing a thing.

Client Credentials Flow

  • Use Case: Service-to-service communication. This is for applications (like a backend daemon, a script, or an API) that need to authenticate and get a token for themselves, with no user present.
  • How it Works: The application authenticates directly with Azure AD using its own credentials—either a client secret (a password for the app) or a client certificate. It hits the /token endpoint directly and gets back an access token.
  • Red Team Angle: This is a primary target. If you can find an application's client secret or certificate (in source code, configuration files, CI/CD variables, etc.), you can impersonate that application and gain all of its permissions.

Device Code Grant Flow

  • Use Case: Devices with limited input, like smart TVs, IoT devices, or command-line interface (CLI) tools (the Azure CLI uses this).
  • How it Works: 
    1. An app that supports device code flow is started on the device and sends the application client_id and scope to the /devicecode endpoint.
    2. The endpoint responds with a JSON object with device_code, user_code and verification_uri (https://microsoft.com/devicelogin (opens in a new tab)) and a few more parameters.
    3. The user_code and verification_uri are displayed to the user.
    4. User browses to verification_uri on a computer or mobile, enters the user_code and completes the normal authentication process.
    5. The device keeps polling the /token endpoint for access_token and refresh_token using the device_code.
  • Phishing Attack:  Device Code Flow can be abused for phishing as follows:
Device Code Phishing
  1. Connect to the /devicecode endpoint and use a legit client_id - client_id is a number that represents an Azure application. for instance Microsoft Office's client_id is "d3590ed6-52b3-4102-aeff-aad2292ab01c" - and scope to generate a code.
  2. Send the received verification_uri and user_code to the victim.
  3. Hope that the victim opens the link, enters code and completes sign-in within 15 minutes.
  4. Request access and refresh tokens for the victim.
Dynamic device code phishing

Dynamic Device Code Phishing (opens in a new tab)

Implicit Grant Flow (Legacy)

  • Use Case: Originally designed for Single-Page Applications (SPAs) running entirely in the browser.
  • How it Works: It's a simplified flow where the access token is returned directly in the URL fragment (#access_token=...) after the user authenticates.
  • Why it's Legacy: Returning tokens in the URL is risky as they can be exposed in browser history or referrer headers. Modern SPAs should use the Authorization Code Flow with PKCE (Proof Key for Code Exchange), which is more secure. You'll still find older applications using this flow.

On-Behalf-Of (OBO) Flow

  • Use Case: A web API needs to call another, downstream web API. For example, a user calls your custom "Employee API," which then needs to call the Microsoft Graph API to get more user details.
  • How it Works: The "Employee API" takes the user's access token it received, sends it to the /token endpoint, and "exchanges" it for a new access token that is valid for calling the downstream API (Microsoft Graph) on behalf of that original user.
  • Red Team Angle: Understanding this is key to tracing permissions through complex microservice architectures. A compromise of a middle-tier API might allow you to pivot to other internal APIs.

SSO

  • Entra ID provides SSO methods for enterprise applications:
    • SAML
    • Password-based
    • Linked
  • A Global Administrator, Cloud Application Administrator, Application Administer or Owner of the application can configure SSO.

SAML SSO

  • When SAML SSO is configured, Entra ID provides a self-signed certificate for SAML response signing. But It is possible to use an external self-signed certificate. (If an attacker gets the external certificate that is configured to sign the SAML response, they can access the application as any user!) and that is the Silver SAML attack
Silver SAML attack

TAP

  • A Temporary Access Pass TAP is a time-limited passcode that can be configured for single or multiple uses. By design,
  • TAP :
    • Allows users to access their account without a password
    • Satisfies the MFA requirement (considered strong authentication in CAPs)
    • Allows users to configure other authentication methods, including passwordless methods
    • Is preferred over Identity Provider (IdP) in federated domains
  • Roles can create a temporary access pass:
    • Global Administrators
    • Privileged Authentication Administrators
    • Authentication Administrators
    • UserAuthenticationMethod.ReadWrite.All
  • A TAP Policy defines what users or groups can use TAP and the lifetime of TAP. Works across tenants
  • Roles that can create a TAP policy:
    • Global Administrator
    • Authentication policy administrators
  • A Global Reader or role with Policy.Read.All can read TAP Policy.
  • TAP abuse:
    • Compromising any of the roles with rights to create TAP can be abused!
    • Any CAP forcing MFA or authentication strength can be bypassed.

External Identities

  • An External identity or External ID refers to scenarios where external users can access resources in a tenant using their own credentials or identity.
  • supported scenarios:
    • B2B Collaboration Typical guest access. External users visible in current tenant. Enabled by default.
    • B2B direct connect Mutual, two-way trust is established but external users are not visible in the current tenant. Disabled by default.
    • Azure AD B2C Similar to Entra ID but a separate service that targets external customer identities.
    • Multi-tenant organization Create a group of tenants to manage access.
  • Cross-tenant access settings
    • Governs the collaboration with other tenants.
    • Useful terms:
      • Outbound access: If users from current tenant can access resources in other tenants.
      • Inbound access: If users from other tenants can access resources in the current tenant.
      • Trust settings: If claims (MFA, Compliance Device, Hybrid joined devices) would be trusted from other tenants.
  • Automatic Redemption: Automatic redemption can be used to suppress the Consent prompt if both the source tenant (outbound) and resource tenant (inbound) has it configured. For instance if Automatic Redemtion is configuered for TenantA output and TenantB inbound, users from TenantA can Access resources from TenantB without consent.
  • Cross-tenant Synchronization
    • Automatically keeps B2B users updated across different tenants.
    • You can choose to sync all users or only specific users and groups to another tenant.
    • Can be used for:
      • Entra roles
      • Azure roles
      • Groups - Access to member and Owner role of a security group.
    • Classic subscription administrator roles (Account Administrator, Service Administrator and Co-Administrator) can’t be managed using PIM.
    • Role activation can be configured to require:
      • MFA
      • Conditional access authentication context
      • Justification/Approval by selected Approvers/Ticket information
      • PIM also enables notifications when roles are assigned and activated.
      • Access Reviews helps in removing dormant role assignments.
    • Types of role assignment:
      • Permanent eligible
      • Permanent active
      • Time-bound eligible
      • Time-bound active
    • PIM with a stolen access_token
      • MFA is not enforced by PIM on the stolen access token.
      • Privileges of the new activated role are available with the stolen access token!

Authentication Strength

  • There are 3 types of known authentication strength, and custom authentication strength can be created as well:
    • MFA
      • Password + SMS, TAP, Federated MFA
    • Passwordless MFA
      • doesn't require password like - Microsoft Authenticator
    • Phishing resistent MFA
      • FIDO2 security key
      • Windows Hello for Business
      • Certificate-based Authentication Multi-Factor

Hybrid Identities

Azure AD Connect

Cloud Sync

  • Microsoft Doc for Cloud Sync (opens in a new tab)
  • It supports PHS and Federation.
  • It accomplishes the synchronization by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application.
  • Cloud Sync abuse: Provisioning agent runs on the on-prem env as a GMSA named pGMSA_installationID. and it has DCSync rights on the on-prem env. and a synchronization service account is created on Entra ID called ADToAADSyncServiceAccount@tenant
  • Lateral movement: From Entra ID to on-prem, Cloud Sync supports write-back to on the on-prem AD - can be disabled -. so with a user with password reset role in Entra ID. It can reset passwords for synced users. And from there you can move in the on-prem environment.

Microsoft Entra Kerberos

  • Allows hybrid users to access Azure file shares over the internet using their on-prem credentials.
  • An Entra application registration is automatically created when Entra Kerberos is configured for the file share Storage Account <storage-account-name>.file.core.windows.net.
  • The service principal associated with this application requires manual admin consent and must be exempted from any MFA enforcement.
  • This service principal does not have direct access permissions to the storage account.
  • The application is owned by the Storage Resource Provider.
  • Entra Kerberos Azure file share abuse:
    • If a hybrid user that has access to the file shares got comprimised, we can have access to the file shares.
    • Can be used for persistance if we managed ( with a Global Admin, Application Admin, Cloud app administrator) roles to set an app secret for the storage account. can be a backdoor.

PIM

  • Allows just-in-time, time-bound and approval-based access to Entra ID and Azure roles.
  • In place of permanent role assignments, using PIM, a user can activate a role for privileged tasks.

JWT Assertion

Certificate-Credentials (opens in a new tab)

  • We can authenticate directly with the certificate. but JWT assertion will happen automatically under the hood.

  • Its used whenever the application is authenticating as itself (not on behalf of a user).

  • The application creates a JWT token with required claims, then signs it with the private key of its certificate and sends it to the /token endpoint

  • Azure issues the required tokens after validating it.

  • Check if any application has a secret or a certificate

    • Every application in Azure Entra can have a secret or a certificate
    • They are stored on the application object in Azure entra under 2 properties:
      • passwordCredentials → for client secrets.
      • keyCredentials → for certificates (public certificates), each entry looks like
        JSON
        {
"customKeyIdentifier": "aGVsbG8td29ybGQ=",
"keyId": "12345678-aaaa-bbbb-cccc-1234567890ab",
"type": "AsymmetricX509Cert",
"usage": "Verify",
"key": "MIIDdzCCAl+gAwIBAgIEUzuwQTANBgkqhkiG9w0BAQsFADBoMQswCQYDVQQGEwJVUzELMAkGA1UE"
}
        and when the application creates the JWT Assertion and encrypt it with its private key, Azure validates it using this certificate.

  • Check if any application has a secret or a certificate. Users who own / have access to those applications are only the ones who can see this data

    Powershell
    $URI = "https://graph.microsoft.com/v1.0/Applications"
 
$RequestParams = @{
Method  = 'GET'
Uri     = $URI
Headers = @{
    'Authorization' = "Bearer $GraphAccessToken"
}
}
 
$Applications = (Invoke-RestMethod @RequestParams).value
 
$ApplicationsDetails = [PSCustomObject]@{
Applications = @()
}
 
foreach ($Application in $Applications) {
$applicationObject = [PSCustomObject]@{
    DisplayName        = $Application.displayName
    AppId              = $Application.appId
    CreatedDateTime    = $Application.createdDateTime
    ID                 = $Application.id
    keyCredentials     = $Application.keyCredentials
    passwordCredentials = $Application.passwordCredentials
}
 
$ApplicationsDetails.Applications += $applicationObject
}
 
$ApplicationsDetails.Applications
 
# Save output to a file for later use
$ApplicationsDetails.Applications | Export-Clixml -Path ApplicationsWithCertificates.xml

  • Get what application is using this certificate by comparing the Certificate ThumpPrint in the customKeyIdentifier field with the actual pfx certificate's ThumpPrint

    Powershell
    Import-Clixml ApplicationsWithCertificates.xml | Where {$_.keyCredentials.customKeyIdentifier -eq $clientCertificate.Thumbprint}

Consent and Permissions

  • Users can consent for apps to access resources on their bahalf.
  • Consent permissions for users in a tenant can be controlled by the admin, options are:
    • Don't allow user consent
    • Allow user consent for trusted publishers.
    • Allow user consent for all apps.
  • Applications need to ask user for permissions to access their data. For example, for basic sign-in.
  • Turned-on by-default, a normal user can grant consent only for "Low Impact" permissions. In all other cases, admin consent is required.
  • Only permissions that do not require admin consent are considered low impact; for example, basic sign-in permissions such as openid, profile, email, User.Read, and offline_access can be granted by users themselves. This means that if an organization allows user consent for all apps, employees can authorize applications to access these details from their profiles. Interestingly, some low-impact permissions —such as User.ReadBasic.All - allows an app to read the display name, first and last name, email address, open extensions, and photo of all users in the directory.
  • Admin consents:
    • Global Administrator, Privileged Role Administrator, can provide tenant-wide admin consent for any permission for any API.
    • Application Administrator and Cloud Application Administrator can provide tenant-wide consent except application permissions for Graph API.
    • A custom role including permission to grant permissions to applications can provide tenant-wide admin consent.

CSPs

Partners and Solution providers.

Managing CSPs

Partner Center

Azure Light House

  • Uses Azure delegated resource management which makes it possible to manage customer's Azure resources without having to sign in to the customer's tenant.
  • Not to be confused with Microsoft 365 Lighthouse which is for M365 services.
  • Onboarding
    • A subscription or a resource group from a customer tenant needs to be onboarded to the service provider tenant.
    • Only a subscription Owner or a user with Microsoft.Authorization/roleAssignments/write can onboard the subscription or any resource group in it.
    • To see the delegated roles and customers, a user must be granted the Reader role during onboarding.

Azure Arc

  • Allows managing resources outside Azure using Azure resource manager. like:
    • Servers and Application Services (App Services, Azure Functions etc.)
    • Kubernetes clusters
    • SQL Servers
    • VMs from VMWare, Hyper-V and Azure Stack HCI
  • The agent uses three services:
    • Hybrid Instance Metadata Service (himds) - NT Service
    • Guest Configuration (GCService) and Guest Configuration
    • Extension services - Local System
  • Arc-enabled servers Managed Identity
    • Its access token can be requested calling the IMDS metadata service http://localhost:40342/metadata/identity/oauth2/token

Azure SQL

  • There are three products in the Azure SQL family:
    • Azure SQL Database - Manged database service (Database-as-a-service).
    • Azure SQL Managed Instance - Instance as a service (supports Arc)
    • SQL Server on Azure VMs
  • Using SQL Server links or Linked servers, a SQL server instance can read data and execute commands against remote database servers and OLE DB data sources.
  • SQL authentication, managed identity and Entra authentication is supported.

Applications & Service Principals & Managed Identities

References: Applications and service principal objects in Microsoft Entra ID (opens in a new tab) Use Service Principals and Managed Identities in Azure Dev Ops (opens in a new tab)

Application Objects

  • A Microsoft Entra application is defined by its one and only application object, which resides in the Microsoft Entra tenant where the application was registered (known as the application's home tenant).
  • Think of the Application as a blue print / a class to an object in OOP / a docker image to docker instances.
  • A service principal object for the application is created in every tenant the application is used in.
  • Relationship between application object and a service principal:
    • The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant.
    • The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects.

Managed Identities

Types of identities:

  • Human
  • Non-Human Identities:
    • Device Identities
    • Workload Identities:
      • Application Identities
      • Service Principals
      • Managed Identities
  • A managed identity is an identity that can be assigned to an Azure compute resource (Azure Virtual Machine, Azure Kuerbernetes cluster set, .. etc).
  • Once a managed identity is assigned on the compute resource, it can be authorized, directly or indirectly, to access resources, such as a storage account, SQL database, .. etc.
  • Managed identity replaces secrets such as access keys, passwords, certificates or other forms of authentication for service-to-service dependencies.

Types of Managed Identities:

  • System-assigned:
    • Some Azure resources, such as virtual machines allow you to enable a managed identity directly on the resource. When you enable a system-assigned managed identity:
    • A service principal of a special type is created in Microsoft Entra ID for the identity. The service principal is tied to the lifecycle of that Azure resource. When the Azure resource is deleted, Azure automatically deletes the service principal for you.
    • By design, only that Azure resource can use this identity to request tokens from Microsoft Entra ID.
    • You authorize the managed identity to have access to one or more services.
    • The name of the system-assigned service principal is always the same as the name of the Azure resource it's created for. For a deployment slot, the name of its system-assigned managed identity is <app-name>/slots/<slot-name>.
  • User-assigned:
    • You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more Azure Resources. When you enable a user-assigned managed identity:
    • A service principal of a special type is created in Microsoft Entra ID for the identity. The service principal is managed separately from the resources that use it.
    • User-assigned managed identities can be used by multiple resources.
    • You authorize the managed identity to have access to one or more services.
  • User-assigned managed identities, which are provisioned independently from compute and can be assigned to multiple compute resources, are the recommended managed identity type for Microsoft services.

Service Principals

  • To access resources that are secured by a Microsoft Entra tenant, the entity that requires access must be represented by a security principal.
  • The security principal defines the access policy and permissions for the user/application in the Microsoft Entra tenant.
  • The security principal of a user is called user principal and for an application is called service principal.
  • This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.
  • There are 3 types of service principals depending on what it represents:
    • Application:
      • This type of service principal is the local representation, or application instance, of a global application object in a single tenant or directory. In this case, a service principal is a concrete instance created from the application object
      • A service principal is created in each tenant where the application is used and references the globally unique app object.
      • The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.
      • When an application is given permission to access resources in a tenant (upon registration or consent), a service principal object is created. When you register an application, a service principal is created automatically.
    • Managed identity 
      • This type of service principal is used to represent a managed identity (opens in a new tab).
      • Managed identities eliminate the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Microsoft Entra authentication.
      • When a managed identity is enabled for an Azure resource, a service principal representing that managed identity is automatically created in your tenant and is tied to that resource life time.
      • A service principal representing a managed identity doesn't have an associated app object (unlike the Application type above).
    • Legacy 
      • This type of service principal represents a legacy app, which is an app created before app registrations were introduced.
      • A legacy service principal can have credentials, service principal names, reply URLs, and other properties that an authorized user can edit, but doesn't have an associated app registration.

Azure Roles RBAC and ABAC

RBAC

  • Azure has more than 120 built in roles
  • The most important 4 are:
RolePermissionsApplies to
Owner- Full Access to all resources
- Can manage access for other users
All resource types
Contributor- Full access to all resources
- Cannot manage access		All resource types
Reader- View all resourcesAll resource types
User Access Administrator- View all resources
- Can manage access for other users		All resource

RBAC roles Assignment

  • Azure AD Object/Principal HAS Role ON Resource/Resources
  • An explicit deny role assignment takes precedence!.

ABAC

  • ABAC = Attribute-Based Access Control.
  • It extends RBAC (role-based access control) by adding conditions based on attributes instead of only static role assignments.
  • RBAC alone: “User X is a Storage Blob Data Reader on Storage Account Y.”
  • RBAC + ABAC (with conditions): “User X is a Storage Blob Data Reader on Storage Account Y but only if blob.IndexTag = 'ProjectA' and user.department = 'Finance'.”

Azure AD Roles

  • Azure AD roles are on the level of the Azure AD/Entra ID. And its different than the Azure Roles which are on the level of the Azure tenant itself.
  • The role Global Administrator is the highest Azure AD role and can elevate to the User Access Administrator Azure role to the Root Management Group

Azure Resources

Azure AD

  • Azure AD is NOT directory services in the cloud. That one is Azure Active Directory Domain Services which provides 'domain controller as a service'.
  • It is possible to integrate on prem AD with Azure AD for a hybrid identity.
  • Global Administration can elevate their privileges to the Root Management Group.
  • Azure AD roles are applicable on Azure AD resources like users, groups, domains, licenses etc.
  • There are many Administrator roles in Azure AD. We can also define custom roles.

ARM Azure Resource Management

  • ARM or Azure Resource Manager: is used to manage azure resources

  • We can write ARM templates (is like terraform scripts) for managing azure resources.

  • 2 planes to communicate with Azure resources:

    Control Plan:

    • Only needs an access token for ARM management.azure.com
    • Is used to create/update/delete resources (Ex: Crete a new keyvault)

    Data Plane:

    • Needs 2 tokens, one for ARM and one specific for the service itself (Ex: keyvault)
    • Is used to interact with the resource itself (Ex: Retrieve secrets from the keyvault)

  • Enumerating Azure Resources

Azure Workflow services

There are currently 4 workflow services in Azure. Including:

Azure Logic Apps

  • Can be used for example for:
    • Email notifications when a specific event happens
    • Moving uploaded files from a FTP server to Azure Storage
    • Monitor social media
  • Abusing Logic apps:
    • Run history may contain sensitive info.
    • A user with readMicrosoft.Logic/workflows/read permission can read the logic app workflow which may contain sensitive info.
    • If IP restriction and authentication are not implemented for HTTP triggers for the logic app. Anyone can trigger it.

Azure App Service

  • Azure App Service is a platform that lets you run web applications, mobile back ends, and RESTful APIs without worrying about managing the underlying infrastructure.

  • Supports multiple dev stacks (Node js, .NET, ... etc) also if you hve your app containerized you can just run your container.

  • Apps are susciptible to normal web app vulnerabilities.

  • If the app is vulnerable to an RCE, the privs we will get will be only the low-priv worker process.

  • Unless the app was assigned a Managed Identity then we can use that inside the Azure env.

  • Managed identity authentication happens through 2 important ENV Variables

  • Retrieve the token by senging a GET request

    Powershell
    curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com&api-version=2017-09-01" -H secret:$IDENTITY_HEADER'

    if they exist in the ENV of a Azure service app. then it has an attached managed identity.

Storage Account

  • Also called Azure Blob Storage
  • Structure: Storage Account (Uniqe accross the tenant ) > containers (folders) > blobs (files)
  • Authorization for it can be done through:
    • RBAC
    • Shared Key: use access keys of the storage account. Grants full access to the storage account
    • SAS URLs shared access signature: is time limited and grants specific permissions (Same like the signed URLs in AWS for S3 buckets)

Automation Account

  • Allows automating tasks for azure resources, on-prem and other cloud providers (ex: creating VMs)
  • It must be assigned a Managed Identity with high privs in order to do its work
  • It uses Runbooks which contains automation logic, (Ex: can be Powershell, Python, .. ).
  • Always checkout Runbooks! They often have credentials that are not stored in the shared resources.

Tokens

Token Types

  • Azure AD uses tokens based on open standards (OAuth 2.0 and OpenID Connect). These tokens are typically JSON Web Tokens (JWTs), which are specially formatted, signed strings of text that you can decode to see the information inside.

  • The most common azure api for issuing tokens is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/{endpint}

    Powershell
    https://login.microsoftonline.com/12345678-1234-1234-1234-1234567890ab/oauth2/v2.0/authorize
    Powershell
    https://login.microsoftonline.com/12345678-1234-1234-1234-1234567890ab/oauth2/v2.0/token

ID Tokens (Authentication)

  • Purpose: To prove the identity of the user. It's the output of the authentication process.
  • Issued By: Azure AD's /authorize endpoint.
  • Consumed By: The application the user is logging into (the "client").
  • Key Contents (Claims): Information about the user, such as their name (name), username (upn), tenant ID (tid), and the time the token was issued. It answers the question, "Who are you?"
  • Red Team Note: An ID token is useful for reconnaissance on a user's identity, but it can't be used to access APIs directly.

Refresh Tokens (Persistence)

  • When you use the refresh token, you are stepping into the shoes of that specific application, and you can only operate within the boundaries of the permissions the user granted to that application in the first place.
  • Bound To:
    • Subject (sub): The user who authenticated.
    • Client (client_id): The application that requested the token on behalf of the user.
  • Purpose: To obtain new access tokens (and sometimes new ID tokens) without requiring the user to log in again.
  • Issued By: Azure AD's /token endpoint, alongside the access token.
  • Consumed By: The client application, which sends it back to Azure AD to refresh the session.
  • Key Contents: Opaque to the client. It's an encrypted string only meant for Azure AD to understand.
  • Revoked When the user resets their password, or manually revokes all active sessions
  • Red Team Note: This is the crown jewel. A refresh token is extremely powerful. They are long-lived (can be valid for days or even indefinitely until revoked). If you steal a refresh token, you can maintain persistent access to the user's account, silently generating new access tokens whenever you need them.
  • FRT and FOCI
    • FOCI:
      • Family of client IDs. are a group of applications in Azure that a single access or refresh token can work for all of them.
      • Currently, there is only one family and it contains many "First-Party" Microsoft Applications with "public" client IDs - Office, Teams, Az CLI, Az PowerShell, Microsoft support, OneDrive and so on!
    • FRT:
      • Family Refresh Token is not bound to a client_id or a scope
      • Even using a normal refresh token, we can request access token for different scopes. For example, using a MSGraph refresh token to request an access token for ARM.

Access Tokens (Authorization)

Purpose: To grant access to a protected resource (an API like Microsoft Graph, the ARM API, or your own custom API).

  • Issued By: Azure AD's /token endpoint.
  • Consumed By: The protected resource/API. The API inspects the token to ensure it's valid and that the bearer has the necessary permissions.
  • Key Contents (Claims): 
    • Subject (sub): Binds the token to the user who is acting.
    • Audience (aud): Binds the token to the resource or API it is meant for. An access token with an audience of https://graph.microsoft.com (opens in a new tab) will be immediately rejected by the Azure Resource Manager (ARM) API, which expects an audience of https://management.azure.com/ (opens in a new tab).
      JSON
      {
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/12345678-1234-1234-1234-1234567890ab/",
"iat": 1727493234,
"nbf": 1727493234,
"exp": 1727497134,
"aio": "E2ZgYhhfW7IRC_tjC0t1gAsJztgEA",
"appid": "f12cd596-07c4-4054-b5f7-013b632903ab",
"appidacr": "1",
"idp": "https://sts.windows.net/12345678-1234-1234-1234-1234567890ab/",
"oid": "11111111-1111-1111-1111-111111111111",
"rh": "0.ASEAQky8ENcvz_IL1MASRmvSBgYAAAAAAAAwAAAAAAAAFA4QAA.",
"roles": [
    "User.Read.All",
    "Directory.Read.All"
],
"tid": "12345678-1234-1234-1234-1234567890ab",
"sub": "11111111-1111-1111-1111-111111111111",
"uti": "FQ80ixno0UiQgnXsSD3AAA",
"ver": "1.0"
}
    • Scope (scp) or roles: Defines what specific permissions the user has for that audience (e.g., Mail.Read, User.ReadWrite.All).
  • Red Team Note: An access token is a receipt, issued only after a user has passed all security checks like MFA and Conditional Access. The token contains claims that certify these checks were met. allowing us to bypass those security measures.

Red Teamer's POV: Stealing and Abusing Tokens

Your goal as a red teamer is to short-circuit this process by stealing the tokens after they've been issued.

Where to Find Tokens

  • Browser Storage: localStorage and sessionStorage.
  • Configuration Files: Web server configs, CI/CD pipeline variables, developer source code.
  • PowerShell History: Get-History or the history file on disk.
  • Process Memory: Can be difficult but possible.
  • Man-in-the-Middle (MitM): Intercepting unencrypted traffic (less common now with TLS everywhere, but possible in misconfigured environments).
AZ cli tokens
  • az cli stores tokens in clear-text format in C:\\[UserName]\.Azure\accessTokens.json
  • We can read tokens from the file, use them and request new ones too!
  • azureProfile.json in the same directory contains information about subscriptions.
  • You can modify accessTokens.json to use access tokens with az cli but better to use with Az PowerShell or the Azure AD module.
  • Always use az logout to clear the tokens.
Az Powershell tokens
  • It stores tokens in clear-text format in C:\\[UserName\.Azure\TokenCache.dat]
  • It stores serviceprincipalsecret in AzureRmContext.json if a service principal secret is used to authenticate.
  • Another interesting method is to take a process dump of PowerShell and looking for tokens in it!
  • Users can save tokens using Save-AzContext, So, we should look for them in powershell history
  • Always use Disconnect-AZ-Account
Office365 app memory
  • We can use procdump.
DPAPI cached tokens

Use Stolen Tokens

  • Access Token Replay: You can use a stolen access token with tools like the Azure CLI, PowerShell, or curl to directly make API calls as if you were the user.
  • Refresh Token Abuse: This is more advanced. You can use a stolen refresh token to generate your own access tokens, giving you persistent access. Tools like AADInternals have functions specifically for this (Get-AADIAccessTokenForRefreshToken).

Let's make this practical. If you are on a compromised machine and have the Azure CLI installed and a user is logged in, you can easily grab an access token for the ARM API:

Powershell
# Get an access token for the currently logged-in user
$token = az account get-access-token --resource https://management.azure.com --query accessToken --output tsv
 
# Now use that token to list all resource groups in the subscription
curl -X GET -H "Authorization: Bearer $token" "https://management.azure.com/subscriptions/{subscription-id}/resourcegroups?api-version=2021-04-01"
Using Tokens with CLI Tools
  • Usually, tokens contain all the claims (including that for MFA and Conditional Access etc.) so they are useful in bypassing such security controls. Token Commands
Using tokens with APIs

The two REST APIs endpoints that are most widely used are:

MG API
  • Microsoft Graph API a single API endpiont graph.microsoft.com and the deprecated one is graph.windows.net
  • Provides access to:
    • Entra ID
    • Microsoft 365 core services - Office, OneDrive, Outlook/Exchange, Teams and more.
    • Enterprise Mobility + Security Services - Entra ID, Intune, Defender 365 etc.
    • Windows services - Activities, devices, notifications etc.
    • Dynamics 365 Business Central services - ERP services
  • Ex:
    Powershell
    # List all users
 
$Token='eyJ0eXAi..'
$URI='https://graph.microsoft.com/v1.0/users'
$RequestParams=@{
Method ='GET'
Uri =$URI
Headers =@{
    'Authorization'="Bearer $Token"
    }
}
(Invoke-RestMethod@RequestParams).value
ARM API
  • Azure Resource Management API
  • management.azure.com
  • Enables developers to manage Azure resources programmatically.
  • This API allows for tasks such as creating and managing virtual machines, managing storage accounts, configuring networking resources, and monitoring Azure services.
  • Ex
    Powershell
    # List all subscriptions
$Token='eyJ0eXAi..'
 
$URI='https://management.azure.com/subscriptions?api-version=2020-01-01'
$RequestParams=@{
Method ='GET'
Uri =$URI
Headers =@{
    'Authorization'="Bearer $Token"
    }
}
(Invoke-RestMethod@RequestParams).value

Azure security

Conditional Access Policy

  • Uses Signals to take Decision on access when an identity wants to access all resources or specified resources.

  • Common signals:

    • User or group membership
    • IP Location
    • Device Platform
    • Device State
    • Risk detection

  • Common Decisions:

    • Block
    • Grant
    • Grant but require - MFA / Authentication Strength / Compliant Device / Hybrid Joined Device / Approved Client App / App Protection Policy / Password Change / Terms of use

  • Conditional access blocks access even if you have correct credentials but do not satisfy conditions.

  • Who can enumerate CAPs:

    • Following roles can read Conditional Access Policies (CAPs):
      • Security Reader
      • Global Reader
      • Security Administrator
      • Conditional Access Administrator
      • Global Administrator
    • An application with any of the following permissions:
      • Policy.Read.ConditionalAccess
      • Policy.ReadWrite.ConditionalAccess
      • Policy.Read.All
    • Using Microsoft Graph PowerShell requires all of the following permissions:
      • Policy.Read.ConditionalAccess
      • AuditLog.Read.All
      • Directory.Read.All

CAE

  • What is Azure CAE?

    • Azure Continuous Access Evaluation (CAE) is a modern security feature in Microsoft Entra ID.
    • Replaces the traditional, fixed-lifetime access 1 hour token model with an event-driven system.
    • Goal: Provide near real-time enforcement of security policies and react instantly to changes in a user's security state.

  • How It Works: The Shift to Continuous Verification

    • Instead of trusting an access token for 60 minutes, CAE establishes a continuous subscription model between:
      • Identity provider (Microsoft Entra ID)
      • Resource provider (e.g., SharePoint Online, Microsoft Teams)
    • Flow:
      • User logs in and gets an access token.
      • Service subscribes to critical events in Microsoft Entra ID.
      • Entra ID publishes events if they occur.
      • Service rejects the current token, even if not expired.
      • User re-authenticates and policies are re-evaluated.

  • The client (app, cli, .. ) must be CAE aware. (to understand that the access token is not expired, but still not usable) The claim xms_cc in the access token can show you if the applicatin it was issued for is CAE available, If it has a value of CP1 its CAE aware

  • The Triggers: When is Access Re-Evaluated?

    • Scenario 1: Critical Security Events

      • User Account Disabled or Deleted → Access revoked immediately.
      • Password Changed or Reset → Sessions invalidated; user must sign in again.
      • MFA Enabled → Forces re-evaluation to ensure MFA can be satisfied.
      • Administrator Revokes Tokens → Enforced almost instantly via CAE.
      • High User Risk Detected → Risky behavior triggers termination of session.

    • Scenario 2: Conditional Access Policy Changes

      • Example: Location Change
        • Conditional Access allows access from trusted corporate network.
        • User logs in from office (trusted) and begins working.
        • User moves to a coffee shop (untrusted public Wi-Fi).
        • CAE detects IP change and invalidates token.
        • Conditional Access re-evaluated → prompts MFA.

Azure Security Solutions

Microsoft Introduction to Azure Security (opens in a new tab)

The built-in capabilities are organized in six functional areas:

  • Identity

    Focuses on securing identities, which is the control plane for accessing resources. This includes:

    • Microsoft Entra ID for authentication and authorization.
    • Multi-Factor Authentication (MFA).
    • Role-Based Access Control (RBAC).
    • Continuous Access Evaluation (CAE) for real-time policy enforcement.
    • Microsoft Entra ID Protection for detecting and responding to threats like compromised accounts.

  • Compute

    Protects the virtual machines (VMs), containers, and other computing resources you use. Key capabilities include:

    • Microsoft Defender for Cloud for antimalware and antivirus solutions.
    • Azure Disk Encryption for data at rest.
    • Secure Boot and integrity monitoring to protect the host environment.

  • Networking

    Secures your network and the connections between your resources. This area includes:

    • Network Security Groups (NSGs) for filtering network traffic.
    • Azure Firewall to protect virtual networks.
    • Azure DDoS Protection to defend against distributed denial-of-service attacks.
    • Web Application Firewall (WAF) to protect web applications.
    • Azure VPN Gateway and ExpressRoute for secure hybrid connectivity.

  • Storage

    Deals with securing data stored in Azure. Capabilities include:

    • Azure Storage Service Encryption for data at rest and in transit.
    • Azure Key Vault to securely manage cryptographic keys and secrets.
    • Role-Based Access Control (RBAC) to control access.
    • Shared Access Signatures (SAS) for granting granular, time-limited access.

  • Applications

    Focuses on securing the applications you build and deploy. This involves:

    • Secure development practices.
    • Azure API Management for API security.
    • Azure Application Gateway to protect web apps.
    • Managed Identities for secure application-to-resource authentication without credentials.

  • Operations

    Encompasses the security practices and tools used to manage and monitor your Azure environment. Key features include:

    • Microsoft Defender for Cloud, a unified security management and threat protection platform.
    • Microsoft Sentinel, a cloud-native SIEM and SOAR solution.
    • Azure Policy to enforce organizational standards and assess compliance.
    • Azure Monitor for collecting, analyzing, and acting on telemetry data.

References:

CheatBookAzure Cheat Sheet