ROADtools and AADInternals Detection Guide: Spotting Entra ID Recon, Token Abuse and Federation Backdoors

ROADtools and AADInternals are open source frameworks that let anyone with a foothold, or sometimes no foothold at all, map a Microsoft Entra ID tenant, trade tokens between applications, register rogue devices and plant federation backdoors, and both appear in real intrusions by APT29 and Storm-0501. Both are also legitimate tools that red teams, consultants and some administrators run on purpose, so blocking the binaries is not an option: the tenant only sees API calls, sign-ins and directory changes. This guide explains what each tool can do in ATT&CK terms, which Entra and Microsoft Graph logs carry the evidence, the specific detections worth building, and the tenant settings that take the most dangerous capabilities off the table. It is for detection engineers, SOC analysts and Entra administrators, and it is defensive only: no commands or usage steps. For the log streams themselves, see the Entra ID Sign-In and Audit Log Detection Guide; this page goes deeper on two specific toolsets.

This is an independent guide from NHI Mgmt Group, based on the public documentation of ROADtools (Dirk-jan Mollema) and AADInternals (Nestori Syynimaa) and Microsoft's published guidance as of November 2026. It is not sponsored or reviewed by either project's author or by Microsoft. Tools change, so confirm behaviour against the projects' and Microsoft's current documentation.

Key takeaways

• Detect the outcome, not the tool name. Both tools call documented Microsoft endpoints with first-party client IDs, so the durable signals are bulk directory reads, unusual token flows, new devices and federation changes, not a tool signature.
• AADInternals is the more dangerous of the two. ATT&CK v20 maps AADInternals (S0677) to 24 techniques including SAML token forgery, hybrid identity abuse and trust modification; Storm-0501 used it to add a federated domain that trusted an attacker tenant.
• ROADtools is mostly reconnaissance plus token handling. ROADrecon dumps the directory for offline analysis and roadtx handles device registration, Primary Refresh Tokens and token exchange between Microsoft client applications.
• Microsoft Graph activity logs close the biggest gap. Sign-in logs show that a token was issued; only the MicrosoftGraphActivityLogs table shows that the token then enumerated every user, group and role.
• Prevention beats detection for the worst cases. Hardening federation settings, protecting the Entra Connect sync account, blocking device code flow and controlling device registration remove the steps that turn recon into tenant takeover.

What the two toolsets are

ROADtools (Rogue Office 365 and Azure (active) Directory tools) is a Python framework published under the MIT licence by Dirk-jan Mollema. Its README describes three parts: roadlib, a shared library for authentication and the database model; ROADrecon, which uses asynchronous HTTP calls to dump available directory information into a local SQLAlchemy database and explore it through an offline web interface; and roadtx (ROADtools Token eXchange), which handles token flows, device registration and Primary Refresh Token (PRT) operations. The README explicitly frames ROADrecon as useful from both a red team and a blue team perspective, and many defenders use it to audit their own tenants.

AADInternals is a PowerShell module by Nestori Syynimaa, installed from the PowerShell Gallery, described as a module "for administering Azure AD and Office 365". Its documentation groups functions into access tokens, tenant information and manipulation, users and MFA, workloads (Exchange Online, SharePoint, OneDrive, Teams) and a set of "hack functions" covering identity federation, pass-through authentication (PTA), directory synchronisation, AD FS, Seamless SSO, Entra join, MDM and PRT. It also organises functions by kill chain stage: outsider, guest, insider and phishing.

The practical consequence: assume you will see these tools only through cloud telemetry, except where AADInternals is run on a hybrid identity server you own, where endpoint logging becomes your best evidence.

Capabilities mapped to ATT&CK

The mappings below come from the ATT&CK v20 software entries. They show which behaviours to cover, regardless of which tool performs them; AzureHound and custom Graph scripts produce many of the same records.

Unauthenticated "outsider" functions in AADInternals, such as tenant ID, domain and login information lookups, query public discovery endpoints and leave no record in your tenant. Treat them as unavoidable exposure and focus detection on what follows.

The telemetry you need before you can detect anything

• Sign-in logs, all four streams: SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs. Token refreshes and exchanges used by these tools are mostly non-interactive, so a tenant that exports only interactive sign-ins misses them.
• Audit logs: AuditLogs for domain, federation, device, application credential, role and authentication method changes.
• Microsoft Graph activity logs: the MicrosoftGraphActivityLogs table records each Graph request with AppId, UserAgent, RequestUri, IPAddress, ResponseStatusCode, Scopes, Roles, SessionId and SignInActivityId. Microsoft documents that it needs an Entra ID P1 or P2 licence, is configured through Diagnostic Settings by at least a Security Administrator, and usually arrives within 30 minutes but sometimes up to 2 hours. Join SignInActivityId to the sign-in tables' UniqueTokenIdentifier to tie each request back to the sign-in that issued the token.
• Endpoint telemetry on hybrid identity servers: PowerShell Script Block Logging (event 4104) and EDR on Entra Connect, PTA agent and AD FS servers, where AADInternals functions that extract sync credentials or install backdoors must run.
• Defender alerts where licensed: Microsoft's Storm-0501 write-up lists Defender for Cloud Apps alerts named "Backdoor creation using AADInternals tool", "Suspicious login from AADInternals tool" and "AADInternals tool used by a Microsoft Entra Sync account", a Defender for Endpoint alert "Suspicious cmdlets launch using AADInternals", and "Federated domain backdoor was added". Treat these as useful extra signals, not as the whole detection set.

Graph activity logs can be large. Microsoft notes you cannot filter them in Diagnostic Settings, so reduce cost with workspace transformations or the Basic log plan rather than leaving them off. Microsoft also warns that request URIs can contain sensitive values, so restrict who can read the table.

Detections that work

Reconnaissance and bulk collection

• Enumeration burst: one SessionId or SignInActivityId issuing hundreds or thousands of GET requests across /users, /groups, /directoryRoles, /servicePrincipals, /applications and /devices within minutes. Normal users touch a handful of these paths; collection tools touch all of them, page by page. Baseline per AppId, because some admin tools legitimately page through the directory.
• Breadth score: count distinct top-level resource paths per session over 30 minutes. A session hitting seven or more directory object types is worth triage regardless of request count.
• Admin client used by a non-admin: sign-ins to first-party administrative client applications (Azure PowerShell, Azure CLI, Microsoft Graph PowerShell) by users who are not in any admin role and have never used them before. roadtx's documented default is the Azure AD PowerShell client ID with the Azure AD Graph resource, and it ships aliases for clients such as Azure CLI and Teams.
• Retired API attempts: Microsoft blocked Azure AD Graph for applications from early September 2025 (see the Azure AD Graph and MSOnline Retirement guide). Sign-ins or failures requesting the Azure AD Graph resource from user accounts in late 2026 indicate old scripts or older offensive tooling, and either deserves follow-up.

Token abuse and device registration

• Family refresh token hopping: one session that obtains tokens for several unrelated first-party clients in quick succession (for example Teams, then Azure CLI, then Office) from the same IP without interactive sign-ins. roadtx documents exchanging refresh tokens between Family of Client IDs (FOCI) applications to reach different scopes.
• Device code sign-ins: AuthenticationProtocol equal to deviceCode for users with no input-constrained device need, especially followed by device registration. See the Device Code Phishing Guide.
• New device soon after risky sign-in: an audit record registering or joining a device within an hour of a sign-in from a new ASN, a device code sign-in or an MFA method change. CISA's advisory AA24-057A describes SVR actors registering their own devices after MFA fatigue succeeded.
• PRT use from unexpected platforms: sign-ins that present a PRT or device claims from a device ID that was registered recently, has no Intune record, or reports an operating system and browser combination that does not match the device record. roadtx's browser PRT mode always presents an Edge user agent, so a user agent alone proves nothing; compare it with the device record and the IP. See the Entra ID Primary Refresh Token (PRT) Security Guide.
• User agent drift within a session: CISA recommends prioritising unexpected user agent changes, which can indicate session hijacking, over IP indicators, because residential proxies make IPs look normal.

Federation, sync and hybrid backdoors

• Federation changes: alert on every audit event that adds a domain, verifies a domain, or sets or changes domain authentication or federation settings. These are rare in a stable tenant and should map to a change ticket. Follow with a hunt for federated sign-ins whose issuer is new, and for sign-ins as users whose ImmutableId does not match an on-premises object. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Directory sync account outside its lane: the On-Premises Directory Synchronization Service Account signing in from any IP other than the Connect server, or to any application other than the sync service. Microsoft's Storm-0501 hunting guidance queries IdentityLogonEvents and CloudAppEvents for exactly this. The Storm-0501 hybrid cloud attacks show where it leads.
• PowerShell on identity servers: script block events on Connect, PTA and AD FS servers containing the module name or its function prefix, any module installation from the PowerShell Gallery on those servers, and access to the sync service's credential store. These servers should run almost no interactive PowerShell, which keeps the signal clean.
• Privilege jumps that follow: the Storm-0501 chain moved from Global Administrator to Azure with Microsoft.Authorization/elevateAccess/action and then roleAssignments/write. Alert on elevate access in Azure activity logs at all times.

Hardening that removes the attack paths

One common misunderstanding: the Entra setting "Restrict access to Microsoft Entra admin center" does not stop ROADrecon or AADInternals. Microsoft's own documentation says it does not block programmatic access through PowerShell, Microsoft Graph or other tools and is not a security measure. For guests, set guest user access to "restricted to properties and memberships of their own directory objects", which blocks lookups of other users and groups. For a broader tenant baseline see the Entra ID Security Guide.

Where identity fits

Most of what these tools abuse is non-human identity. The Entra Connect Directory Synchronization Account, PTA agents, application registrations with credentials and service accounts excluded from MFA are the identities that turn a reconnaissance dump into persistence. CISA's AA24-057A notes SVR actors target service accounts precisely because they often cannot use MFA and are highly privileged, and recommends canary service accounts whose any use is a high-confidence alert. Build an inventory of every hybrid identity component and its credentials, review owners, and alert on any new credential added to an application or service principal. See the How to audit the Entra Connect sync account guide and the Entra ID Applications and Consent Guide.

How to implement

1. Turn on the data. Export all four sign-in streams, AuditLogs and MicrosoftGraphActivityLogs to your SIEM with at least 90 days of searchable retention. Restrict read access to the Graph table.
2. Run the tools yourself, with approval. In a test tenant or under a signed authorisation, run ROADrecon collection and a small set of AADInternals read-only functions from a known IP. Record exactly which client IDs, user agents, request paths and audit events appear. This is your detection test fixture.
3. Build the high-fidelity rules first. Federation and domain changes, sync account sign-ins outside the Connect server, elevate access, and PowerShell module activity on identity servers. These are rare enough to alert on directly.
4. Add the behavioural rules in report mode. Enumeration burst, breadth score, FOCI hopping and device-after-risky-sign-in. Run them for two to four weeks, tune per AppId and per admin group, then promote to alerting.
5. Apply hardening in rings. Federation policy settings on one domain, then all; device code block in report-only, then on; device registration restrictions for a pilot group, then everyone. Roll back by switching the Conditional Access policy to report-only or reverting the domain setting.
6. Set an authorisation register. Red team and consultant use of these tools must be logged with source IPs, accounts and dates, so analysts can close alerts fast and spot unauthorised use.

Decision guidance

• Small tenant, no SIEM: rely on Entra ID Protection, Defender alerts if licensed, and the hardening table above. Federation policy, device code blocking and cloud-only admins give the most protection per hour of effort.
• Large or hybrid tenant: Graph activity logs are worth the cost. Without them you cannot tell a reconnaissance dump from a normal sign-in.
• Federated tenant: prioritise federation change alerting and the token validation settings above everything else; a federation backdoor is a full tenant compromise.
• Allow or forbid defensive use: ROADrecon is a good audit tool. Allow it from named admin accounts and fixed IPs under the register, so any other use stands out.

Detection and measurement

• Telemetry coverage: percentage of the six log sources above flowing to the SIEM with 90 days or more retention (target 100%).
• Test detection rate: share of steps from your approved tool test that raise an alert or a hunting hit (target above 80% for recon, 100% for federation and sync abuse).
• Federation change reconciliation: percentage of domain and federation audit events matched to a change ticket within 24 hours (target 100%).
• Device code exceptions: number of accounts excluded from the device code block, trending down.
• Tier 0 hygiene: count of synced or non-human accounts holding Global Administrator or Privileged Role Administrator (target zero).
• Time to triage: median time from enumeration alert to analyst decision.

Common failure patterns

• Collecting only interactive sign-ins. Token exchange, refresh and FOCI activity is non-interactive, so the tool's main activity never reaches the SIEM.
• Trusting the admin center restriction. It hides the portal from users but leaves Graph and PowerShell enumeration fully open.
• Leaving the sync account unwatched. In the Storm-0501 intrusions the sync account enumerated two tenants and reset a password that let the actor sign in as a privileged synced identity.
• No alert on federation changes. A new federated domain trusting an outside tenant is a silent master key. It is rare, auditable and still often not monitored.
• Forgotten test tenants and apps. The Microsoft Midnight Blizzard breach began in a legacy test tenant and pivoted through an OAuth application; recon tooling finds exactly these forgotten objects.
• Allow-listing tools by user agent. User agents are set by the client, and roadtx's browser mode presents as Edge, so a user agent rule is easy to sidestep.

Framework mapping

Practitioner checklist

• Export all four Entra sign-in streams, AuditLogs and MicrosoftGraphActivityLogs with 90 days or more of retention.
• Alert on every domain addition, verification and federation setting change.
• Set federatedTokenValidationPolicy and federatedIdpMfaBehavior on every federated domain.
• Restrict the directory sync account to the Connect server and alert on any other sign-in.
• Enable PowerShell Script Block Logging and EDR on Connect, PTA and AD FS servers.
• Block device code flow with Conditional Access, starting in report-only.
• Restrict device registration and alert on devices registered after risky sign-ins.
• Build enumeration burst and FOCI hopping rules from your own approved tool test.
• Keep an authorisation register for red team and consultant use of these tools.
• Remove synced and non-human accounts from Tier 0 roles.

Standards and references

• MITRE ATT&CK: AADInternals (S0677)
• MITRE ATT&CK: ROADTools (S0684)
• Microsoft Learn: Access Microsoft Graph activity logs
• Microsoft Learn: Block authentication flows with Conditional Access policy
• Microsoft Learn: Default user permissions in Microsoft Entra ID
• CISA: SVR Cyber Actors Adapt Tactics for Initial Cloud Access (AA24-057A)
• Microsoft Threat Intelligence: Storm-0501's evolving techniques lead to cloud-based ransomware
• GitHub: ROADtools project documentation

Related NHI Mgmt Group resources: Entra ID Sign-In and Audit Log Detection Guide · Golden SAML and Federation Trust Abuse Defence Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide · BloodHound and Active Directory Attack Path Guide · Pacu and Cloud Attack Tooling Detection Guide