Cloud identity infrastructure has become the primary attack surface for modern adversaries. Microsoft Entra ID (formerly Azure Active Directory) and the broader Azure platform are at the heart of millions of enterprise environments, and a single misconfiguration can hand attackers the keys to your entire tenant. This post breaks down the most dangerous, real-world misconfigurations seen in penetration testing engagements and red team operations, along with the commands and techniques used to surface them.
If you want a professional team to find these gaps before threat actors do, Redfox Cybersecurity's pentesting services are built exactly for this.
Unlike on-premises Active Directory, cloud identity environments move fast. Permissions get granted without formal processes, applications get registered without review, and legacy settings from tenant creation linger unnoticed for years. The result is an attack surface that grows silently.
Penetration testers at Redfox Cybersecurity routinely uncover privilege escalation paths, lateral movement opportunities, and data exfiltration vectors in environments that organizations believed were secure.
By default, Entra ID allows standard users to read properties of all other users, groups, and even some application registrations. Guest users, depending on tenant settings, can enumerate directory objects and probe for sensitive resources. Many organizations never tighten these defaults.
Using the Azure CLI, you can pull the authorization policy that governs user permissions:
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" \
--headers "Content-Type=application/json"
[cta]
Key fields to examine in the response:
allowInvitesFrom - should not be set to everyoneallowedToSignUpEmailBasedSubscriptions - should be false in most enterprise tenantsguestUserRoleId - the GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3 maps to the most restrictive guest role; anything else is a misconfigurationUsing PowerShell via the Microsoft Graph module:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions
[cta]
Pay attention to AllowedToCreateSecurityGroups, AllowedToCreateTenants, and AllowedToReadOtherUsers. Any of these set to true for guests is a red flag.
An attacker who compromises a low-privilege guest account can use directory enumeration to map out privileged users, high-value service principals, and application registrations with sensitive API permissions. That reconnaissance feeds the next phase of the attack.
Application registrations in Entra ID can be granted delegated or application-level permissions to Microsoft Graph and other APIs. The dangerous combination is application-level permissions (not requiring user consent) combined with powerful scopes like Mail.ReadWrite, Directory.ReadWrite.All, or RoleManagement.ReadWrite.Directory.
List all service principals and their app role assignments using Graph:
az ad sp list --all --query "[].{Name:displayName, AppId:appId, ObjectId:id}" -o table
[cta]
Then pull the API permissions for a specific service principal by object ID:
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/servicePrincipals/{objectId}/appRoleAssignments"
[cta]
For a broader sweep using PowerShell:
Connect-MgGraph -Scopes "Application.Read.All"
$sps = Get-MgServicePrincipal -All
foreach ($sp in $sps) {
$roles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id
if ($roles) {
Write-Output "$($sp.DisplayName): $($roles.Count) app role assignments"
}
}
[cta]
Cross-reference the returned AppRoleId values against Graph's published permission GUIDs to identify dangerous scopes.
If an attacker gains control of an application registration (through a leaked client secret, a misconfigured CI/CD pipeline, or a compromised developer account), they inherit all of its permissions. An app with Directory.ReadWrite.All effectively gives them global admin capability over the directory.
Letting these issues linger is expensive. Engage Redfox Cybersecurity for a focused cloud security assessment to identify over-privileged applications before they become breach vectors.
Conditional Access is Entra ID's policy engine for enforcing access controls like MFA, device compliance, and location restrictions. Gaps in policy coverage, such as exclusions for break-glass accounts that are too broad, legacy authentication not blocked, or policies that only apply to specific apps, create exploitable windows.
Pull all Conditional Access policies and their state:
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
--headers "Content-Type=application/json"
[cta]
Look for:
report-only state that were never moved to enabledexcludeUsers or excludeGroups listsother and exchangeActiveSync clients (legacy auth)In PowerShell:
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy
$policies | Where-Object { $_.State -eq "enabledForReportingButNotEnforced" } | Select DisplayName
[cta]
Also check whether any policy explicitly blocks legacy authentication protocols:
$policies | ForEach-Object {
$_.Conditions.ClientAppTypes
} | Sort-Object -Unique
[cta]
If exchangeActiveSync and other are not included in any blocking policy, legacy auth is open.
Legacy authentication protocols do not support MFA. Password spraying against SMTP, IMAP, or EAS bypasses Conditional Access entirely if it is not blocked. This is one of the most exploited gaps in enterprise Entra ID tenants.
Azure Role-Based Access Control governs who can do what within subscriptions, resource groups, and individual resources. The most common problems are permanent Owner or Contributor assignments at the subscription level, service principals with subscription-wide write access, and inherited permissions that nobody has reviewed in years.
List all role assignments at the subscription level:
az role assignment list --all --include-inherited \
--query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor']" \
-o table
[cta]
To see role assignments for a specific resource group:
az role assignment list --resource-group <resource-group-name> -o table
[cta]
Check for custom roles that may have been created with wildcard permissions:
az role definition list --custom-role-only true \
--query "[].{Name:roleName, Permissions:permissions[0].actions}" -o table
[cta]
Look for * in the actions list of any custom role definition. This grants all actions and is functionally equivalent to Owner on that scope.
A compromised identity with Contributor access on a subscription can create new resources, exfiltrate data from storage accounts, access Key Vault secrets (depending on access policies), and establish persistence through new service principals or automation accounts.
Azure Storage Accounts with public blob access enabled, combined with permissive container access levels, result in sensitive data being readable without authentication. This is one of the most common findings in cloud security assessments.
List all storage accounts across the subscription and check their public access setting:
az storage account list \
--query "[].{Name:name, PublicAccess:allowBlobPublicAccess, ResourceGroup:resourceGroup}" \
-o table
[cta]
For each storage account with allowBlobPublicAccess: true, enumerate its containers:
az storage container list --account-name <storage-account-name> \
--query "[].{Name:name, PublicAccess:properties.publicAccess}" \
-o table
[cta]
A container with publicAccess: blob or publicAccess: container is readable without any credentials.
Also check for storage accounts not enforcing HTTPS-only:
az storage account list \
--query "[?enableHttpsTrafficOnly==\`false\`].name" -o table
[cta]
Exposed storage containers have been responsible for some of the largest cloud data breaches on record. Configuration and secrets files, database backups, application logs containing credentials, and customer data all regularly appear in improperly secured blob containers.
Redfox Cybersecurity's cloud penetration testing team performs systematic enumeration of storage account misconfigurations as part of every Azure engagement. If you have not had this tested recently, the risk is real.
Microsoft Entra Privileged Identity Management (PIM) enables just-in-time activation for privileged roles, requiring justification, MFA, and approval for sensitive access. Many organizations have PIM licensed but never configure it, leaving Global Administrator, Privileged Role Administrator, and other high-value roles permanently assigned.
Using Graph API, query for permanent (not eligible) assignments to privileged directory roles:
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$expand=principal,roleDefinition" \
--headers "Content-Type=application/json"
[cta]
Filter the response for assignments where the roleDefinition matches Global Administrator (62e90394-69f5-4237-9190-012177145e10) and where there is no associated PIM schedule (indicating permanent assignment).
In PowerShell:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'" `
-ExpandProperty "principal,roleDefinition" |
Select-Object -ExpandProperty Principal | Select DisplayName, UserPrincipalName
[cta]
More than two or three permanent Global Administrator accounts is a misconfiguration in most environments.
Permanent privileged role assignments mean that compromising one credential gives an attacker full, immediate, unrestricted control over the Entra ID tenant, with no activation window, no approval gate, and no time limit.
Azure Monitor, Entra ID audit logs, and sign-in logs provide the telemetry needed to detect attacks in progress. Environments that do not ship these logs to a SIEM, do not retain them beyond the default 30 days, or have no alerting on high-risk sign-ins, are effectively blind to attacks even as they happen.
Check diagnostic settings on the Entra ID tenant:
az monitor diagnostic-settings list \
--resource "/tenants/<tenant-id>/providers/microsoft.aadiam" \
--resource-type "microsoft.aadiam/diagnosticSettings" 2>/dev/null || \
echo "No diagnostic settings configured or insufficient permissions"
[cta]
Check whether log analytics workspaces exist and have data flowing:
az monitor log-analytics workspace list \
--query "[].{Name:name, RetentionDays:retentionInDays, ResourceGroup:resourceGroup}" \
-o table
[cta]
Query sign-in logs for high-risk events via Graph:
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=riskLevelDuringSignIn eq 'high'&\$top=10"
[cta]
An attacker operating in an environment with no logging has unlimited dwell time. They can enumerate, escalate, exfiltrate, and establish persistence while generating zero alerts. The average time to detect a breach in poorly monitored cloud environments remains measured in months.
The misconfigurations above are not theoretical. They are found in production Azure environments consistently, across industries and organization sizes. The commands provided here form a starting checklist, but thorough assessment requires experienced testers who understand how these weaknesses chain together into full attack paths.
A guest enumeration finding becomes critical when combined with an over-permissioned application registration and a Conditional Access gap. One misconfiguration in isolation might be a medium finding. Three chained together is a tenant takeover.
Redfox Cybersecurity specializes in cloud and identity security assessments, red team operations, and adversarial simulation against Azure and Entra ID environments. Our team uses the same techniques outlined above, and dozens more, to deliver findings that are actionable and tied to real business risk.
Whether you need a focused Azure configuration review, a full cloud penetration test, or an ongoing adversarial simulation program, Redfox Cybersecurity's services are designed to give your security team clarity on where the real exposure lies.
Do not wait for an incident to drive remediation. Start a conversation with Redfox Cybersecurity today and get ahead of the misconfigurations that attackers are actively scanning for right now.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
