Entra ID Register Device with Phishing Kit or ROADtools User Agent

Detects a successful Microsoft Entra ID Register device audit event for an Azure AD join or Azure AD register whose user agent is a Dsreg client string hardcoded by device-registration tooling. "Dsreg/10.0 (Windows 10.0.19045.2006)" is the frozen user agent used by device code and adversary-in-the-middle (AiTM) phishing-as-a-service kits such as Tycoon2FA and Kali365 when they register a device after capturing a victim session. "Dsreg/10.0 (Windows 10.0.19041.928)" is the default user agent used by ROADtools (roadtx) for Windows device registration. Adversaries register these devices to obtain a Primary Refresh Token (PRT) and persist access that survives password resets and user-level session revocation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/10/07"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/10/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a successful Microsoft Entra ID Register device audit event for an Azure AD join or Azure AD register whose
 11user agent is a Dsreg client string hardcoded by device-registration tooling. "Dsreg/10.0 (Windows 10.0.19045.2006)" is
 12the frozen user agent used by device code and adversary-in-the-middle (AiTM) phishing-as-a-service kits such as
 13Tycoon2FA and Kali365 when they register a device after capturing a victim session. "Dsreg/10.0 (Windows
 1410.0.19041.928)" is the default user agent used by ROADtools (roadtx) for Windows device registration. Adversaries
 15register these devices to obtain a Primary Refresh Token (PRT) and persist access that survives password resets and
 16user-level session revocation.
 17"""
 18false_positives = [
 19    """
 20    A legitimate, never-patched Windows 10 host at build `10.0.19041.928` (20H1) or `10.0.19045.2006` (22H2) can
 21    present the same Dsreg user agent during a genuine Azure AD join or register. Validate the device name, owner, and
 22    patch level against your device inventory before escalating.
 23    """,
 24    """
 25    Authorized red team or penetration testing that uses ROADtools or phishing-kit infrastructure to register devices
 26    will match this rule. If this is expected, add exceptions for the specific user principal names, source IPs, or
 27    device names involved.
 28    """,
 29]
 30from = "now-9m"
 31index = ["logs-azure.auditlogs-*"]
 32language = "kuery"
 33license = "Elastic License v2"
 34name = "Entra ID Register Device with Phishing Kit or ROADtools User Agent"
 35note = """## Triage and analysis
 36Device code and AiTM phishing kits, including Tycoon2FA and Kali365, and dual-use tooling such as ROADtools (roadtx)
 37register a device in Entra ID so they can obtain a device-bound Primary Refresh Token (PRT). The registration client
 38spoofs the Windows device-registration user agent, but the OS build inside that string is a tool default rather than the
 39build of a current, patched host:
 40
 41- `Dsreg/10.0 (Windows 10.0.19045.2006)`: frozen default used by Tycoon2FA and Kali365.
 42- `Dsreg/10.0 (Windows 10.0.19041.928)`: default used by ROADtools (roadtx) for Windows device registration.
 43
 44This rule matches a successful `Register device` audit event where that user agent is recorded and
 45`azure.auditlogs.properties.additional_details.value` is `Azure AD join` or `Azure AD register`. A genuine Windows
 46enrollment uses the same `Dsreg/10.0 (Windows <build>)` format, but a patched host reports a much higher revision than
 47these two frozen values. Rogue device registration is typically a precursor to PRT acquisition, MFA and Conditional
 48Access bypass, and persistent token-based access. Device-bound PRTs survive `revokeSignInSessions` and password resets.
 49
 50### Possible investigation steps
 51
 52- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to join or register a new device.
 53- Confirm the user agent in `azure.auditlogs.properties.userAgent` and the join type in `azure.auditlogs.properties.additional_details.value` (`Azure AD join` versus `Azure AD register`).
 54- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`. Kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. ROADtools defaults to `DESKTOP-` followed by 8 random characters.
 55- Use `azure.correlation_id` to pivot across the full registration flow (`Register device`, `Add device`, `Add registered users to device`, `Add registered owner to device`). On the paired `Add device` event, compare `CloudDeviceOSVersion` with the build embedded in the user agent (`10.0.19045.2006` or `10.0.19041.928`).
 56- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting or VPS ASNs, or impossible travel relative to the user's normal activity.
 57- Check whether the same user registered multiple devices in a short window. A single piece of kit infrastructure registering several devices is common for PRT persistence at scale.
 58- Pivot to `azure.signinlogs` for the same user and timeframe. Look for a preceding device-code or AiTM sign-in, and for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`.
 59
 60### False positive analysis
 61
 62- Unmanaged or never-patched Windows 10 20H1 or 22H2 hosts may legitimately present these exact Dsreg user agents during Azure AD join or register. Validate against device inventory, naming conventions, and known provisioning programs.
 63- Authorized security assessments that register devices with ROADtools or phishing-kit tooling will match. Document the engagement and add scoped exceptions.
 64
 65### Response and remediation
 66
 67- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`.
 68- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials).
 69- Conduct historical analysis using `azure.correlation_id` and the registering user to determine the scope of access.
 70- Tighten device registration and join controls via Conditional Access (restrict who can register or join devices and require MFA for registration).
 71"""
 72references = [
 73    "https://www.huntress.com/blog/kali365-device-code-phishing-kit",
 74    "https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/",
 75    "https://www.ic3.gov/PSA/2026/PSA260521",
 76    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
 77    "https://github.com/dirkjanm/ROADtools",
 78    "https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/",
 79    "https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/",
 80    "https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join",
 81]
 82risk_score = 73
 83rule_id = "63dc7e10-705c-41a3-8b2b-c5ae0c01399e"
 84severity = "high"
 85tags = [
 86    "Domain: Cloud",
 87    "Domain: Identity",
 88    "Data Source: Azure",
 89    "Data Source: Microsoft Entra ID",
 90    "Data Source: Microsoft Entra ID Audit Logs",
 91    "Use Case: Identity and Access Audit",
 92    "Use Case: Threat Detection",
 93    "Threat: Tycoon2FA",
 94    "Threat: Kali365",
 95    "Threat: Device Code Phishing",
 96    "Threat: AiTM Phishing",
 97    "Tactic: Persistence",
 98    "Resources: Investigation Guide",
 99    "Rule Type: Custom Query (KQL)",
100    "Platform: Entra ID",
101]
102timestamp_override = "event.ingested"
103type = "query"
104query = '''
105data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and
106event.outcome:(success or Success) and
107azure.auditlogs.properties.userAgent:(
108    "Dsreg/10.0 (Windows 10.0.19041.928)" or
109    "Dsreg/10.0 (Windows 10.0.19045.2006)"
110) and
111azure.auditlogs.properties.additional_details.value:("Azure AD join" or "Azure AD register")
112'''
113
114[rule.investigation_fields]
115field_names = [
116    "@timestamp",
117    "event.action",
118    "event.outcome",
119    "azure.auditlogs.properties.userAgent",
120    "azure.auditlogs.properties.additional_details.value",
121    "azure.auditlogs.properties.initiated_by.user.userPrincipalName",
122    "azure.auditlogs.properties.initiated_by.user.ipAddress",
123    "source.ip",
124    "azure.auditlogs.properties.target_resources.0.display_name",
125    "azure.auditlogs.properties.target_resources.0.id",
126    "azure.correlation_id",
127]
128
129[[rule.threat]]
130framework = "MITRE ATT&CK"
131
132[[rule.threat.technique]]
133id = "T1098"
134name = "Account Manipulation"
135reference = "https://attack.mitre.org/techniques/T1098/"
136
137[[rule.threat.technique.subtechnique]]
138id = "T1098.005"
139name = "Device Registration"
140reference = "https://attack.mitre.org/techniques/T1098/005/"
141
142[rule.threat.tactic]
143id = "TA0003"
144name = "Persistence"
145reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Device code and AiTM phishing kits, including Tycoon2FA and Kali365, and dual-use tooling such as ROADtools (roadtx) register a device in Entra ID so they can obtain a device-bound Primary Refresh Token (PRT). The registration client spoofs the Windows device-registration user agent, but the OS build inside that string is a tool default rather than the build of a current, patched host:

  • Dsreg/10.0 (Windows 10.0.19045.2006): frozen default used by Tycoon2FA and Kali365.
  • Dsreg/10.0 (Windows 10.0.19041.928): default used by ROADtools (roadtx) for Windows device registration.

This rule matches a successful Register device audit event where that user agent is recorded and azure.auditlogs.properties.additional_details.value is Azure AD join or Azure AD register. A genuine Windows enrollment uses the same Dsreg/10.0 (Windows <build>) format, but a patched host reports a much higher revision than these two frozen values. Rogue device registration is typically a precursor to PRT acquisition, MFA and Conditional Access bypass, and persistent token-based access. Device-bound PRTs survive revokeSignInSessions and password resets.

Possible investigation steps

  • Confirm the registering identity via azure.auditlogs.properties.initiated_by.user.userPrincipalName and determine whether that user is expected to join or register a new device.
  • Confirm the user agent in azure.auditlogs.properties.userAgent and the join type in azure.auditlogs.properties.additional_details.value (Azure AD join versus Azure AD register).
  • Inspect the device name in azure.auditlogs.properties.target_resources.0.display_name. Kit-registered names are commonly DESKTOP- followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. ROADtools defaults to DESKTOP- followed by 8 random characters.
  • Use azure.correlation_id to pivot across the full registration flow (Register device, Add device, Add registered users to device, Add registered owner to device). On the paired Add device event, compare CloudDeviceOSVersion with the build embedded in the user agent (10.0.19045.2006 or 10.0.19041.928).
  • Review azure.auditlogs.properties.initiated_by.user.ipAddress and geolocation for the registration source. Flag unexpected IPs, hosting or VPS ASNs, or impossible travel relative to the user's normal activity.
  • Check whether the same user registered multiple devices in a short window. A single piece of kit infrastructure registering several devices is common for PRT persistence at scale.
  • Pivot to azure.signinlogs for the same user and timeframe. Look for a preceding device-code or AiTM sign-in, and for follow-on sign-ins where the incoming token type is a primaryRefreshToken.

False positive analysis

  • Unmanaged or never-patched Windows 10 20H1 or 22H2 hosts may legitimately present these exact Dsreg user agents during Azure AD join or register. Validate against device inventory, naming conventions, and known provisioning programs.
  • Authorized security assessments that register devices with ROADtools or phishing-kit tooling will match. Document the engagement and add scoped exceptions.

Response and remediation

  • If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive revokeSignInSessions.
  • Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials).
  • Conduct historical analysis using azure.correlation_id and the registering user to determine the scope of access.
  • Tighten device registration and join controls via Conditional Access (restrict who can register or join devices and require MFA for registration).

References

Related rules

to-top