How to Spot and Stop Rogue Device Joins

What it is

Wiz's analysis of rogue device registration in Entra ID and — the part the summary omits — the concrete IOCs, prevalence numbers, mitigation ordering constraint, and the actual KQL thresholds. Prevalence: over a 90-day window nearly 1 in 7 Entra ID tenants saw at least one such attack; the classic DESKTOP-XXXXXXXX pattern affects almost 1 in 10 of Wiz's customer base.

How it works

Attackers obtain a token (commonly via device code phishing), then use the Device Registration Service to enroll a device under the victim's identity, satisfying Conditional Access policies that require a joined device. Observed artifacts:

• Phishing infra reuse: AWS IP 3.149.231.11 seen across device-code sign-ins for multiple victims; URLScan captured a "shared document" lure at lockwall.xyz/prime/ presenting a pre-generated Microsoft device code.
• ROADrecon-era IOCs: User-Agent Dsreg/10.0 (Windows 10.0.19041.928), device name DESKTOP-XXXXXXXX.
• Evasion already seen: microsoft-XXXXXXXX (trivial static-check bypass), and an AI-flavored case — User-Agent MSTokens-PRT/1.0 registering a device named Work PC (Wiz notes clean name/version structure resembling Azure-Enum/1.0).

Wiz used Claude to flag suspect User-Agents and to enumerate inconspicuous device names an attacker might pick, then validated hypotheses with telemetry — explicitly not as attribution, only as hunting leads.

What to do

Two behavioral detections replace static IOC matching: (1) naming-convention anomaly detection against the tenant baseline, (2) correlating device-code-phishing alerts with a subsequent registration. The shared KQL identifies tenants where DESKTOP- devices are rare (so any that appear are suspicious), using minDevicesForBaseline = 100, desktopThreshold = 0.01, over a 14-day window against SigninLogs (ResultType == 0, OperationName == "Sign-in activity"), summarizing the DesktopDevices / TotalDevices ratio and flagging tenants at or below 1%.

Prevention: add a Conditional Access policy requiring MFA for device registration.

Caveats

The MFA-for-registration CAP does not stop token-based attacks: if the attacker gets a token via device code phishing or AiTM where the victim already completed MFA, the token satisfies the policy and registration proceeds. To close that gap, restrict device registration to known corporate IPs or require compliant devices. Wiz also stresses a generic name or unfamiliar User-Agent alone cannot attribute activity to AI tooling.