Azure AD Pentest Methodology for Entra ID Tenants

Cloud Security

Entra ID attacks rarely look like brute force. They look like consented apps, sneaky service principal credentials, and dynamic group rules nobody reviews. Here is how we work them and how to harden against them.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 26, 2025 · 8 min read

Entra ID is a graph. Users own apps, apps own service principals, service principals own credentials, credentials act on resources, and admins delegate roles to all of the above. A pentester walks that graph looking for an edge that should not exist. The findings are rarely a single misconfigured account; they are six small mistakes lined up.

How attackers find this

We start with read-only enumeration through Microsoft Graph. AzureHound dumps the directory into BloodHound so we can see role assignments, group nesting, app ownership, and conditional access scope at a glance. ROADtools extracts richer detail through ROADrecon and lets us query what AzureHound abstracts away. MicroBurst sweeps subscriptions for storage accounts, key vaults, and runbook secrets that map back to identity primitives.

• Application consent abuse: a low-privilege user consents to a malicious app that requests Mail.Read or Files.Read.All under their own scope.
• Service principal credential add: an Application Administrator can append a password or certificate to any non-privileged app's service principal and use it.
• App role assignment: granting an app the RoleManagement.ReadWrite.Directory permission gives it the ability to grant itself anything.
• Dynamic group membership rules: rules based on user-controllable attributes (department, jobTitle, extensionAttribute1) let a user join a privileged group by editing their own profile.
• Federated credential injection on a workload identity: adding a federated credential pointing to an attacker-controlled OIDC issuer.

Methodology in practice

We chain. A consented Mail.Read pulls SSO emails that contain reset links. An Application Administrator role added via dynamic group membership lets us add a credential to a high-privilege app. A federated credential pointing at our own GitHub Actions runner lets us mint tokens for that app from outside the tenant. Each step is mundane. The chain is administrator.

Detection

Entra ID audit logs and sign-in logs are where the truth lives. Ship both to a SIEM. The signals we hunt as defenders: 'Add service principal credentials' on apps that have not been touched in months, 'Consent to application' events from non-admin users granting high-impact scopes, 'Update group' events on dynamic groups, sign-ins from service principals out of their normal IP range. Microsoft Sentinel has analytics for several of these but they need tuning to your tenant baseline.

Remediation

1. Turn on the admin consent workflow so users cannot consent to apps requesting risky scopes; admins approve through a ticketed flow.
2. Restrict who can register applications; the default of 'all users' is the wrong default for any tenant past fifty employees.
3. Move privileged role assignments into Privileged Identity Management with just-in-time activation, MFA, and approval.
4. Block dynamic group rules from referencing user-controllable attributes; review existing rules for the same anti-pattern.
5. Enforce conditional access policies that require compliant devices for privileged role activation and block legacy authentication.
6. Schedule quarterly app credential and consent reviews; remove anything inactive for ninety days.

Entra ID hardening is not a single switch. It is a posture: tight registration, monitored consent, just-in-time roles, and continuous review of the long tail of apps and service principals that accumulate over years. The pentest finding is almost always something the tenant could have removed but did not.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.