Security teams detect AADInternals by looking for suspicious Azure AD and Microsoft 365 administrative activity that matches offensive enumeration or token abuse. Watch for unusual PowerShell use, tenant recon, abnormal directory queries, and changes to identity or federation settings. Correlate cloud audit logs with endpoint telemetry and alert on admin actions from unfamiliar hosts or accounts.
What AADInternals Detection Should Focus On
AADInternals is usually detectable through the behaviour it produces, not a single unique signature. The highest-value signals are administrative actions that do not fit normal identity operations: repeated tenant enumeration, unusual directory or federation changes, token-related abuse patterns, and PowerShell-driven activity from hosts that are not normally used for Azure AD administration. The goal is to spot the workflow of discovery, access, and persistence before it turns into tenant-wide control.
Look for sequences rather than isolated events. A single admin query may be routine, but a burst of reconnaissance, followed by identity configuration changes, followed by unusual authentication or token activity, is far more suspicious. This is especially true when the activity occurs from a new device, from an account with atypical privileges, or outside the team’s normal change window.
Because AADInternals is often used against Microsoft identity infrastructure, defenders should treat identity-plane telemetry as first-class evidence. Cloud audit data, sign-in logs, directory change events, and endpoint telemetry should be correlated so that a PowerShell session, a new admin action, and a downstream token or federation change can be evaluated as one chain.
Identity, Federation, and Token Signals Worth Hunting
Focus on the parts of the tenant that offensive tooling commonly probes first: directory objects, privileged role assignments, federation settings, and token issuance paths. Changes to trusted domains, federation metadata, application registrations, conditional access, or identity-related configuration are especially important when they are made by accounts that do not usually perform that work.
Token abuse indicators matter as much as configuration changes. An attacker may use administrative access to create a path that survives password resets, MFA prompts, or ordinary help desk recovery steps. That makes abnormal token activity, replay-like patterns, and changes that could affect authentication trust just as important as the original reconnaissance.
For broader coverage, use an Identity Threat Detection and Response (ITDR) Guide to structure detections around identity compromise, suspicious administrative actions, and the response steps that follow. If the activity resembles a hybrid identity intrusion chain, the Storm-0501 hybrid cloud attacks 2024 case is a useful reference point for how identity abuse can cross from on-prem systems into Entra ID and token-based persistence.
How to Correlate Telemetry Without Drowning in Noise
The practical challenge is separating normal admin work from offensive enumeration. That means building detection logic around combinations of events, not single alerts. A good correlation model links endpoint execution, cloud audit records, and sign-in context so that an unusual PowerShell session becomes meaningful only when it is tied to tenant reconnaissance, privilege changes, or token-related behaviour.
Baseline the accounts and hosts that legitimately administer Azure AD and Microsoft 365, then alert when those same actions come from unfamiliar machines, new geographic locations, non-standard tooling, or accounts that rarely touch identity administration. The most useful detections are the ones that can answer three questions quickly: who initiated the action, from where, and what identity-plane object changed as a result.
Use this work as part of a broader identity-monitoring program, not as a one-off hunt. The detection logic should be maintainable, because offensive tooling tends to shift its sequence or timing once defenders begin keying on the obvious recon commands.
Risk and Threat Considerations
AADInternals is dangerous because it targets the control plane that governs authentication, privilege, and federation. If an attacker can enumerate the tenant, alter identity settings, or tamper with trust configuration, they can move from visibility into durable access without needing to keep re-exploiting the same initial foothold.
Failure mechanism: The attacker uses administrative visibility or abused credentials to probe the tenant, then changes identity or federation settings to create persistence, impersonation capability, or token abuse paths that survive routine password resets and ordinary endpoint cleanup.
Impact: The likely outcome is tenant-level identity compromise, including unauthorized admin actions, hidden persistence, and the ability to forge or replay trust in ways that undermine normal sign-in controls and incident containment.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1087 — Account Discovery | AADInternals detection centers on tenant recon and directory enumeration. |
| T1550 — Use Alternate Authentication Material | Token abuse and federation tampering align with alternate auth material abuse. | |
| T1098 — Account Manipulation | Identity and federation setting changes are account and trust manipulation. | |
| Recommendation — Map directory enumeration to account discovery and alert on unusual tenant recon patterns. Hunt for token replay and other alternate-auth-material abuse in identity logs. Detect and review changes that modify identity trust, roles, or federation settings. | ||
| NIST CSF 2.0 | DE.CM-03 — Anomalies and Events are Analyzed | This subject depends on correlating endpoint and cloud identity telemetry. |
| Recommendation — Correlate cloud audit, sign-in, and endpoint events to analyze anomalous identity activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detection requires reviewing identity audit logs for suspicious admin behaviour. |
| Recommendation — Review and correlate audit records for suspicious administrative identity actions. | ||
Practitioner Guidance
What to verify: Confirm which accounts are actually expected to perform Azure AD administration, which hosts they should use, and which identity-plane actions are legitimate for each role. If those baselines are unclear, detection will be noisy and attackers will blend into ordinary admin activity.
Decision rule: If the same sequence includes tenant recon, PowerShell execution, and changes to federation or directory trust settings, treat it as a potential identity compromise until proven otherwise. Escalate faster when the account is privileged, the host is unfamiliar, or the activity occurs outside normal maintenance windows.
What practitioners underestimate: The first suspicious event is often not the compromise, only the reconnaissance. The most important judgement is whether the activity changed the tenant’s trust posture, because that determines whether you are dealing with transient probing or persistent identity abuse.
Practitioner takeaway: The best detections for AADInternals are chain-based, identity-aware, and trust-focused, because the real risk is not the PowerShell itself but the tenant changes it can enable.