Entra ID Phishing Kit Default OS Build (Entity Analytics)

edit

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

Entra ID Phishing Kit Default OS Build (Entity Analytics)

edit

Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045.<revision>" value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator.

Rule type: new_terms

Rule indices:

logs-entityanalytics_entra_id.device-*

Severity: medium

Risk score: 47

Runs every: 1h

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

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: Identity
Data Source: Microsoft Entra ID
Data Source: Microsoft Entra ID Entity Analytics
Use Case: Asset Visibility
Use Case: Threat Detection
Threat: Tycoon2FA
Threat: Kali365
Tactic: Persistence
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Entra ID Phishing Kit Default OS Build (Entity Analytics)

AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default operating system build of 10.0.19045.2006 and a default name of DESKTOP-<random characters>. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher 10.0.19045.<revision> value), making the build a useful indicator of kit-driven device registration. This rule runs against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access.

Possible investigation steps

Confirm the device identity via host.name, host.os.version, entityanalytics_entra_id.device.display_name, and entityanalytics_entra_id.device.id (or device.id). Default DESKTOP- names that do not match your naming convention are suspicious; kit-registered names are commonly DESKTOP- followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters.
Review entityanalytics_entra_id.device.registration_date_time and entityanalytics_entra_id.device.trust_type to establish when and how the device was registered; kit devices are typically AzureAd joined.
Identify the registered owner via entityanalytics_entra_id.device.registered_owners.user_principal_name and determine whether that user is expected to register a new device.
Check entityanalytics_entra_id.device.is_managed and entityanalytics_entra_id.device.is_compliant; kit-registered devices are typically unmanaged and non-compliant.
Pivot to logs-azure.auditlogs-* for the corresponding Add device and Register device events (initiated by the Device Registration Service via the Microsoft Authentication Broker). Inspect the Register device user agent, which is frequently a spoofed Dsreg/10.0 (Windows 10.0.19045.2006) string or a raw HTTP client such as axios/* or python-requests/*.
Check whether the same owner registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale) and whether the broker was subsequently used to mint tokens for other resources such as Microsoft Graph.
Pivot to logs-azure.signinlogs-* for sign-ins by the device owner where the incoming token type is a primaryRefreshToken.

False positive analysis

Unmanaged or never-patched Windows 10 22H2 hosts may legitimately report the 10.0.19045.2006 build with a default DESKTOP- host name. Validate against device inventory and patch baseline.
Authorized security assessments that register devices with this OS profile will appear in inventory. Document the engagement and add scoped exceptions.

Response and remediation

If confirmed malicious, remove the device from Entra ID and revoke the owner’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).
Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration).

Rule query

edit

data_stream.dataset:"entityanalytics_entra_id.device" and
    event.provider:"Microsoft Entra ID" and
    host.name:DESKTOP-* and host.os.version:"10.0.19045.2006" and
    host.id: *

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: Device Registration
- ID: T1098.005
- Reference URL: https://attack.mitre.org/techniques/T1098/005/

« Entra ID OAuth user_impersonation Scope for Unusual User and Client Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) »