Attackers use AADInternals to interact with Microsoft Entra ID and related cloud identity services for reconnaissance, token abuse, mailbox or directory access, and tenant configuration review. It can support post-compromise cloud identity operations. Defenders should monitor for abnormal directory queries, privilege changes, consent events, and unusual authentication patterns.
What AADInternals is used for in an attack path
AADInternals is not a generic “hack everything” toolkit. It is used when an attacker wants to operationalise Microsoft Entra ID access, learn how a tenant is configured, and turn identity footholds into broader cloud access. That usually means enumerating the directory, finding trust relationships, testing permissions, and identifying where tokens, app consent, or synced identities can be abused.
The tool becomes useful when the attacker already has some level of cloud identity access, because it helps convert that access into clearer reconnaissance and more durable control. It is especially relevant in post-compromise activity where the goal is to understand the tenant, locate privileged pathways, or prepare follow-on actions against mail, directory objects, or synchronisation infrastructure.
Attackers also use AADInternals to surface identity control weaknesses that are easy to miss in normal administration, such as unexpected app registrations, consent grants, federation settings, directory sync exposure, or stale privileged relationships. That is why it sits in the same operational family as identity abuse tooling: it helps an intruder move from access to understanding, and from understanding to action.
What the technique reveals about cloud identity risk
The practical risk is not the tool itself, but the fact that it makes cloud identity abuse faster, quieter, and more targeted once an attacker is inside the tenant. In a Microsoft Entra ID environment, identity control planes are high-value because they govern authentication, authorisation, token issuance, and administrative trust. When those controls are weak, a small foothold can become tenant-wide visibility or privilege.
This is why AADInternals is most concerning where organisations treat cloud identity as “just administration” rather than as a security boundary. If an attacker can review configuration, query directory state, or inspect token and sync behaviour, they may find routes to persistence or lateral movement without needing traditional malware on endpoints.
The defender’s job is to look for the same behaviours the tool depends on: unusual directory enumeration, consent events that do not match normal admin work, privilege changes outside change windows, and authentication patterns that do not fit the user, workload, or location profile. Those signals matter because they often appear before the attacker has finished converting reconnaissance into impact.
How defenders should respond when AADInternals-style activity is suspected
When this kind of activity is suspected, the first question is whether the tenant has already been partially mapped or altered. If the answer is yes, response should focus on identity containment first, not just device triage. That means checking administrative role assignments, app consent history, federation and directory sync settings, and whether any token-bearing sessions or privileged accounts need to be invalidated.
Where the environment has hybrid identity, the investigation should also include synchronisation infrastructure and the accounts that govern it. Those pathways often give an attacker more leverage than a single user account because they can bridge on-premises and cloud identity state. Identity Threat Detection and Response (ITDR) Guide is useful here because it frames the detections and response steps that matter when identity itself is the attack surface.
If the activity aligns with token abuse, consent abuse, or post-compromise cloud identity operations, prioritise session invalidation and credential review over broad password resets alone. If the attacker had access to a sync account, privileged admin, or application credential, assess whether those secrets or delegated permissions could still be used to re-enter the tenant after remediation. The State of NHI & AI Agent Breach Report 2026 is relevant as a pattern reference for how stolen tokens, compromised service accounts, and leaked keys turn into real-world compromise.
Risk and Threat Considerations
AADInternals is risky because it helps an attacker turn identity access into tenant understanding, then into persistence or privilege expansion. The danger is highest when cloud identity, application consent, and directory sync are not tightly governed, because those are the areas where attacker actions can look like legitimate administration.
Failure mechanism: An intruder with a foothold uses directory and tenant-reconnaissance capabilities to discover privileges, trust relationships, consent paths, or synchronisation dependencies, then abuses the most durable path available for continued access.
Impact: The result can be mailbox access, directory control, token replay opportunities, persistence through federation or sync abuse, and a much harder incident because the attacker may operate through valid identity mechanisms.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1087 — Account Discovery | AADInternals is used for directory and tenant reconnaissance. |
| T1550 — Use Alternate Authentication Material | AADInternals abuse often relies on token or session misuse after compromise. | |
| T1098 — Account Manipulation | The technique can support privilege changes, consent abuse, and persistence in Entra ID. | |
| Recommendation — Map directory-enumeration activity to T1087 and alert on unusual identity discovery queries. Hunt for token replay and other alternate-authentication use after suspected tenant compromise. Monitor for unexpected role, consent, and trust-setting changes under T1098. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Directory queries, privilege changes, and consent events need review and correlation. |
| IA-5 — Authenticator Management | Token and secret abuse make credential lifecycle control central to response. | |
| Recommendation — Correlate identity audit events to spot anomalous directory and privilege activity. Rotate exposed credentials and invalidate sessions when token abuse is suspected. | ||
Practitioner Guidance
What to prioritise: Treat abnormal directory queries, privilege changes, and consent events as identity incidents, not routine admin noise. Confirm whether the actor touched app consent, federation, or sync infrastructure before focusing on endpoint evidence.
What to verify: Check whether the activity involved a normal admin account, a service account, or a compromised session token, because the remediation path changes if the attacker can re-authenticate without re-entering the endpoint.
Decision rule: If you cannot explain the identity action as approved administration, assume the tenant may already be partially mapped and contain it by revoking active sessions, reviewing delegated access, and rotating any exposed credentials or sync secrets.
Practitioner takeaway: The key judgement is whether the attacker has merely accessed the tenant or has already converted that access into durable identity control; once that line is crossed, identity containment becomes the primary response.