« Entra ID ROPC Authentication with Unknown Client ID Entra ID Register Device with Unusual User Agent (Azure AD Join) »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Entra ID Register Device with Phishing Kit or ROADtools User Agent

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID Register Device with Phishing Kit or ROADtools User Agent

edit

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.

Rule type: query

Rule indices:

  • logs-azure.auditlogs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Audit Logs
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Threat: Tycoon2FA
  • Threat: Kali365
  • Threat: Device Code Phishing
  • Threat: AiTM Phishing
  • Tactic: Persistence
  • Resources: Investigation Guide
  • Rule Type: Custom Query (KQL)
  • Platform: Entra ID

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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).

Rule query

edit
data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and
event.outcome:(success or Success) and
azure.auditlogs.properties.userAgent:(
    "Dsreg/10.0 (Windows 10.0.19041.928)" or
    "Dsreg/10.0 (Windows 10.0.19045.2006)"
) and
azure.auditlogs.properties.additional_details.value:("Azure AD join" or "Azure AD register")

Framework: MITRE ATT&CKTM

« Entra ID ROPC Authentication with Unknown Client ID Entra ID Register Device with Unusual User Agent (Azure AD Join) »