How do you detect AADInternals PowerShell cmdlets targeting Microsoft Entra ID?

What AADInternals activity looks like in Entra ID telemetry

AADInternals usually stands out less by a single signature than by a cluster of behaviours. The strongest signals are PowerShell execution on an admin workstation, module import patterns that are uncommon in your environment, and follow-on directory activity such as role changes, application changes, federation changes, or token-related actions that do not match the operator’s normal work.

That means the detection problem is behavioural and contextual. Watch for command-line invocation, encoded or scripted PowerShell, parent-child process chains, and interactive sessions that pivot into Entra ID management tools. When those events appear together, treat them as a likely identity-administration workflow rather than an isolated script event.

Which telemetry should you correlate first?

Start with endpoints that can legitimately administer Entra ID, then correlate process creation, script block logging, module loads, and identity-plane actions from the same user or host. If the same account later performs consent changes, app registration edits, role assignment changes, or federation updates, the confidence rises sharply.

Directory-level signals matter because AADInternals is often used after initial compromise to enumerate tenants, test privileges, or alter identity settings. Correlating those changes with sign-in activity and token use helps separate normal administrative automation from hands-on-keyboard abuse. The Identity Threat Detection and Response (ITDR) Guide is useful here because it frames detections around identity attack paths, not just endpoint alerts.

Normal admin behaviour is the baseline, not the label. If your privileged staff rarely use PowerShell for Entra administration, then a one-off module import may be enough to justify deeper inspection, especially when it is paired with directory writes or token manipulation.

How do you separate admin automation from malicious use?

The practical distinction is intent plus sequencing. Legitimate automation is usually repeatable, tied to known change windows, and followed by expected administrative outputs. Malicious use tends to be opportunistic, noisy in the PowerShell layer, and aimed at inventory, privilege expansion, persistence, or covert access to Entra objects.

Pay special attention to abuse of privileged identity paths. The Active Directory and Entra ID Hardening Guide is a strong companion because it focuses on the high-value control points that attackers probe first, including privileged groups, delegation, service accounts, and hybrid identity. When AADInternals activity intersects those areas, the incident is no longer just suspicious command execution, it is an identity control problem.

Also look for the operator behaviour around the session itself. AADInternals use from a host that normally handles email or tickets, not directory administration, is more suspicious than the same command on a hardened admin jump host. Endpoint context often gives the difference between routine maintenance and post-compromise tradecraft.

Where do incident response and privilege controls fit?

Once the behaviour is confirmed, pivot quickly to scope rather than to a narrow command review. The first question is whether the same account, host, or session touched privileged roles, app registrations, federation settings, or token-bearing assets. The second question is whether the attacker used those changes to move laterally, persist, or broaden access.

That is where the Privileged Identity Management (PIM) Guide helps, because role activation history, approval flow, and alert settings can show whether privilege was legitimately obtained or quietly abused. If the account did not need standing privilege, but still performed sensitive changes, treat that as a strong compromise indicator.

When identity compromise is confirmed, recovery becomes a race against persistence. The Identity Recovery Guide is relevant because Entra-side response often has to be coordinated with on-prem identity recovery, token invalidation, and clean rebuild decisions. The detection lesson is simple: if the attacker can change identity settings, they can often outlast a single host reimage.

Risk and Threat Considerations

AADInternals use is risky because it often sits at the point where post-exploitation turns into durable control of identity infrastructure. The tool can support discovery, privilege escalation, token abuse, and configuration changes that are easy to miss if teams only monitor malware-style indicators.

Failure mechanism: Attackers execute PowerShell from a trusted admin context, then use legitimate Entra management paths to enumerate settings, change roles, or abuse tokens, which blends into normal administration unless endpoint and directory telemetry are correlated.

Impact: The result can be tenant-wide access expansion, persistence through identity changes, and faster lateral movement into cloud services even after the original foothold is removed.

Practitioner Guidance

What to prioritise: Prioritise detections on privileged endpoints, script block logging, module import events, and any Entra change activity tied to those sessions. If you can only instrument one layer first, instrument the identity-plane actions that AADInternals would actually touch.

What to verify: Verify whether the account had a legitimate reason to run PowerShell for Entra administration, whether the host is approved for that work, and whether the same session made sensitive directory changes. If those three do not line up, treat the event as suspicious by default.

Practitioner takeaway: The most useful detections are cross-layer detections, because AADInternals is rarely about a single command, it is about an operator using PowerShell to change identity state in ways that should be visible across endpoint, token, and directory telemetry.

Related resources from NHI Mgmt Group

• What should you monitor to detect suspicious device activity in Microsoft Entra ID?
• How do you detect applications using the ROPC authentication flow in Microsoft Entra ID?
• How do you detect Conditional Access policy changes by unapproved actors in Microsoft Entra ID?
• How do you detect delegated permissions granted for all users in Microsoft Entra ID?