Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), is the backbone of identity and access management for millions of organizations worldwide. As enterprises accelerate their migration to the cloud, Entra ID has become the single most critical control plane governing who can access what, when, and from where. That makes it one of the most targeted surfaces in modern cyberattacks.
This blog breaks down how Microsoft Entra ID works under the hood, what attackers look for, how to harden it, and why a professional penetration test from Redfox Cybersecurity can uncover risks your internal team may never see.
Microsoft Entra ID is a cloud-native Identity-as-a-Service (IDaaS) platform that handles authentication, authorization, and identity governance across Microsoft 365, Azure, and thousands of third-party SaaS applications. It is not simply a cloud version of on-premises Active Directory. It is a fundamentally different system built on modern protocols including OAuth 2.0, OpenID Connect (OIDC), and SAML 2.0.
At its core, Entra ID manages:
Every one of these areas represents a potential attack surface if misconfigured or left unaudited.
Each organization using Microsoft Entra ID operates within a tenant, a dedicated instance of the directory service. Tenants are globally distributed across Microsoft's Azure infrastructure and communicate via a distributed, geo-replicated backend. Each tenant has a unique tenant ID (a GUID) and an associated primary domain such as contoso.onmicrosoft.com.
Objects within a tenant include users, groups, devices, applications, and service principals. These objects are addressable via the Microsoft Graph API, which is the unified API layer for interacting with Entra ID programmatically.
Authentication in Entra ID relies on token-based flows. When a user or service authenticates, Entra ID issues tokens:
Understanding token flows is essential for both defenders and attackers. Access tokens are typically short-lived (60 to 90 minutes), but refresh tokens can persist for days or weeks depending on policy configuration, making them a high-value target for threat actors.
To inspect the contents of an access token, you can decode it using:
# Decode a JWT token manually
echo "<token_value>" | cut -d'.' -f2 | base64 --decode 2>/dev/null | python3 -m json.tool
[cta]
This reveals the claims inside the token including the audience (aud), scope (scp), tenant ID (tid), and user object ID (oid), all of which are critical during a penetration test or security review.
Password spray is one of the most common initial access techniques used against Entra ID environments. Rather than brute-forcing a single account, attackers try one or a few commonly used passwords across many accounts to avoid lockout policies.
Using tools like MSOLSpray or TeamFiltration, a red team can simulate this attack:
# Install MSOLSpray
git clone https://github.com/dafthack/MSOLSpray
cd MSOLSpray
# Run password spray against a list of user emails
Invoke-MSOLSpray -UserList .\users.txt -Password "Winter2024!" -Verbose
[cta]
Organizations often lack visibility into these spray attempts, especially when they originate from anonymized infrastructure. A professional red team assessment from Redfox Cybersecurity tests exactly this scenario and validates whether your logging, alerting, and identity protection policies are functioning as expected.
Entra ID allows users to grant third-party applications permissions to their accounts through OAuth consent flows. Attackers craft malicious OAuth applications that mimic legitimate productivity tools and trick users into granting permissions like Mail.Read, Files.ReadWrite.All, or User.Read.All.
Once consent is granted, the attacker receives an access token that works without passwords or MFA. This is known as illicit consent grant abuse.
To enumerate OAuth permissions granted to applications in a tenant using PowerShell:
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Directory.Read.All"
# List all service principals and their assigned permissions
Get-MgServicePrincipal | ForEach-Object {
$sp = $_
Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id | Select-Object ClientId, Scope, ConsentType
}
[cta]
Reviewing this output regularly can surface over-permissioned or unrecognized applications that may indicate a compromise or a misconfiguration.
Because Entra ID is token-based, stealing a valid token is as good as having the user's credentials. Token theft can happen through adversary-in-the-middle (AiTM) phishing frameworks like Evilginx2 or through post-exploitation on compromised endpoints where tokens are cached.
Once an attacker has a refresh token, they can use tools like TokenTactics to generate new access tokens for different Microsoft services:
# Import TokenTactics
Import-Module .\TokenTactics.ps1
# Refresh to get a Graph API token
Invoke-RefreshToMSGraphToken -domain "contoso.com" -refreshToken "<stolen_refresh_token>"
# Use token to query user data
Invoke-RestMethod -Headers @{Authorization = "Bearer $accessToken"} `
-Uri "https://graph.microsoft.com/v1.0/me"
[cta]
This type of attack completely bypasses MFA because the token was already issued post-authentication. This is precisely why Continuous Access Evaluation (CAE) and token binding controls matter and why they should be validated through a hands-on pentesting engagement with Redfox Cybersecurity.
Attackers who gain a foothold in an Entra ID environment frequently attempt privilege escalation by targeting high-value roles: Global Administrator, Privileged Role Administrator, Application Administrator, and Cloud Application Administrator.
Using the Azure CLI, you can enumerate current role assignments across a tenant:
# Login to Azure
az login
# List all role assignments at the tenant scope
az role assignment list --all --query "[].{Principal:principalName, Role:roleDefinitionName, Scope:scope}" -o table
# Identify members of the Global Administrator role in Entra ID
az ad directory-role list --query "[?displayName=='Global Administrator'].id" -o tsv | \
xargs -I {} az ad directory-role member list --id {}
[cta]
A common misconfiguration is granting Application Administrator or Cloud Application Administrator to service accounts or developer identities. These roles allow the creation of service principals and manipulation of existing applications, which can be abused to escalate to Global Admin in certain scenarios.
Conditional Access is the policy engine of Entra ID. It evaluates signals like user identity, device compliance, location, and sign-in risk before granting access. A well-configured Conditional Access posture should enforce:
To audit your current Conditional Access policies using Microsoft Graph:
# Query all Conditional Access policies via Graph API
curl -X GET "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
-H "Authorization: Bearer <access_token>" \
-H "Content-Type: application/json"
[cta]
Parse the output and look for policies with state: disabled or missing user/application assignments. These gaps are common findings in security assessments and can represent complete bypasses of your intended controls.
PIM enforces just-in-time (JIT) access to privileged roles. Instead of permanent role assignments, users activate roles on demand with approval workflows and time-limited windows.
Critical PIM hardening steps include:
To check for permanent high-privilege role assignments via PowerShell:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
# Get all permanent (not eligible) role assignments for Global Administrator
$roleId = (Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }).Id
Get-MgDirectoryRoleMember -DirectoryRoleId $roleId | Select-Object DisplayName, UserPrincipalName, Id
[cta]
Any identity appearing here outside of documented break-glass accounts should be investigated and converted to an eligible PIM assignment.
Application registrations are a frequently overlooked attack surface. Developers often create app registrations with overly broad API permissions, long-lived client secrets, and no ownership tracking. These become orphaned over time and represent persistent backdoors into your environment.
A focused hardening checklist for app registrations includes:
Application (not Delegated) permissions to Graph API, especially Directory.ReadWrite.All and RoleManagement.ReadWrite.DirectoryAppManagementPolicy to restrict secret lifetimes tenant-wide# Find all app registrations with secrets expiring more than 1 year from now or already expired
$apps = Get-MgApplication -All
foreach ($app in $apps) {
$secrets = $app.PasswordCredentials
foreach ($secret in $secrets) {
if ($secret.EndDateTime -lt (Get-Date) -or $secret.EndDateTime -gt (Get-Date).AddDays(365)) {
Write-Output "$($app.DisplayName) | Secret: $($secret.DisplayName) | Expires: $($secret.EndDateTime)"
}
}
}
[cta]
Entra ID generates two primary log categories for security monitoring:
These logs should be forwarded to a SIEM (Microsoft Sentinel or a third-party solution) with retention policies that meet your compliance requirements. Raw log access via Graph API:
# Pull sign-in logs for risky sign-ins (risk level: high)
curl -X GET "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=riskLevelDuringSignIn eq 'high'" \
-H "Authorization: Bearer <access_token>"
[cta]
Many organizations collect logs but do not build detection rules on top of them. Without alerts for impossible travel, mass consent grants, bulk role assignment changes, or service principal authentication from unusual IPs, the logs sit unused until after a breach.
Configuration reviews and automated scanners catch known issues, but they cannot simulate the creative lateral movement, chained exploits, and social engineering tactics that real attackers use against Entra ID environments. A structured penetration test covers:
Redfox Cybersecurity provides specialized cloud and identity penetration testing services designed to stress-test your Microsoft Entra ID environment against real-world attack scenarios. Their assessments produce prioritized findings with detailed remediation guidance, not just a list of CVEs.
If your organization relies on Microsoft 365, Azure, or any Entra ID-integrated application, you have a cloud identity attack surface that deserves professional validation. Engage the Redfox Cybersecurity team to find out what an attacker would find before they do.
Microsoft Entra ID is not just an authentication service. It is the identity perimeter of your entire cloud environment. Misconfigurations in Conditional Access, over-permissioned service principals, absent PIM controls, and weak token policies each represent a viable path for attackers to move laterally, escalate privileges, and establish persistent access.
The commands and techniques covered in this blog represent a fraction of what a skilled attacker or red team will execute against a real Entra ID tenant. Understanding the architecture, knowing where the weaknesses live, and continuously validating your controls through real adversarial simulation is the only reliable path to staying ahead.
For organizations ready to take Entra ID security seriously, the logical next step is a professional assessment. Redfox Cybersecurity's penetration testing services are built for exactly this, offering the technical depth and real-world attack simulation that automated tools simply cannot replicate.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
