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.userPrincipalNameand determine whether that user is expected to join or register a new device. - Confirm the user agent in
azure.auditlogs.properties.userAgentand the join type inazure.auditlogs.properties.additional_details.value(Azure AD joinversusAzure AD register). - Inspect the device name in
azure.auditlogs.properties.target_resources.0.display_name. Kit-registered names are commonlyDESKTOP-followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. ROADtools defaults toDESKTOP-followed by 8 random characters. - Use
azure.correlation_idto pivot across the full registration flow (Register device,Add device,Add registered users to device,Add registered owner to device). On the pairedAdd deviceevent, compareCloudDeviceOSVersionwith the build embedded in the user agent (10.0.19045.2006or10.0.19041.928). - Review
azure.auditlogs.properties.initiated_by.user.ipAddressand 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.signinlogsfor 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 aprimaryRefreshToken.
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_idand 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
- Entra ID Device Registration with Phishing Kit Default OS Build
- Entra ID Kali365 Default User-Agent Detected
- Entra ID AiTM Phishing-Kit Chain Detected
- Entra ID Device Registration with ROADtools Default OS Build
- Entra ID ADRS Token Request by Microsoft Authentication Broker