Instead of leaving behind recognizable fingerprints from public tooling, adversaries can now generate realistic device names that blend naturally into enterprise environments. This blog explores how that changes Entra ID detection and what are the behavioral signals that still expose these attacks.
Attackers have long relied on repeatable tools and conventions that leave recognizable fingerprints. AI threatens to erode this defensive advantage by enabling attackers to vary artifacts, such as device names and User-Agent strings, making malicious activity appear more ordinary.
We have already observed signs of this shift in Entra ID attacks. Suspicious device registrations are moving beyond predictable conventions like DESKTOP-XXXXXXXX toward generic identifiers such as Work PC.
In this blog, we will outline the necessary strategic shifts that defenders must implement to sharpen their detection strategies in the face of these AI-driven tactics.
The Default Playbook: Exploiting Entra ID Device Joins
Attackers exploit a fundamental design requirement in Entra ID: because Conditional Access policies often restrict authentication to joined devices, attackers must ensure their machines appear as such to gain entry. Since the Device Registration Service (DRS) is designed to allow users to register their own devices, attackers abuse this functionality to register rogue devices using a victim's identity, effectively satisfying the policy requirements.
And this technique is more common than you might expect: looking at a 90-day period, nearly one in seven Entra ID environments experienced at least one such attack.
From Phishing to Persistence: Bypassing Conditional Access
Before attackers can register a rogue device, they must obtain the necessary authorization. One common method is device code phishing, a technique we explored in detail in our previous blog post.
In many cases, attackers use the same infrastructure to host phishing pages and perform the initial sign-in after a victim is compromised. This overlap can help us identify newly deployed phishing infrastructure.
For example, we observed the AWS IP address 3.149.231.11 across device code sign-ins associated with multiple victims. Around the same time as the attack, URLScan captured a phishing page at lockwall.xyz/prime/ using a “shared document” lure that presented victims with a pre-generated Microsoft device code. The resulting access allowed the attacker to register a new device in the victim’s environment, potentially establishing a more persistent foothold.
Over the past few years, we've observed a steady stream of phishing campaigns following this familiar playbook:
Once a rogue device is successfully registered, attackers typically move on to the objectives that matter most, accessing Microsoft 365 resources, exfiltrating emails, maintaining persistence or expanding their foothold within the tenant. This flow was extensively documented by other threat research teams, like Pushsecurity, Unit42 and Huntress.
Looking beneath the surface, however, a common denominator quickly emerges: many attackers relied on ROADrecon, the well-known open-source Entra exploitation framework.
For defenders, this was actually good news. ROADrecon did an excellent job automating the registration process but automation also meant consistency. And consistency creates detection opportunities for a defender’s favorite low hanging fruit - atomic IOCs.
Key IOCs included:
User-Agent: Tools mimicked legitimate strings, such as Dsreg/10.0 (Windows 10.0.19041.928).
Device Name: Tools used predictable naming patterns like DESKTOP-XXXXXXXX.
The DESKTOP device registration attack pattern affects almost 1 in 10 of the customer base
Even simple modifications bypass these static checks, for instance, we’ve observed attackers using names like microsoft-XXXXXXXX.
This demonstrates that attackers can evade rigid fingerprints with minimal effort. This fragility in static detection is now compounded by AI, which allows attackers to rapidly generate highly customized, unpredictable, and benign-looking identifiers, rendering traditional detection methods increasingly obsolete.
Our hunt began with a simple hypothesis: if attackers are using AI to blend into corporate networks, could we use the same tools to catch them?
We started by asking Claude to analyze unusual User-Agent strings observed in device-registration and sign-in activity, and identify characteristics consistent with AI-generated tooling. One string stood out: MSTokens-PRT/1.0., which registered a device with the name Work PC . Its plausible-sounding product name and clean name/version structure resembled patterns we had previously encountered in AI-generated tools, such as Azure-Enum/1.0.
Our next approach we to query multiple models from an attacker’s perspective, asking which device names they would use to make an Azure device registration appear inconspicuous. We compared recurring suggestions across the models with identifiers observed in real-world telemetry.
This experiment was not intended to prove that a specific artifact was generated by AI. A generic device name or unfamiliar User-Agent cannot provide reliable attribution on its own. Instead, the model outputs gave us new hunting hypotheses. We then validated those hypotheses using behavioral context, including device code authentication followed shortly afterward by a new device registration from unusual infrastructure.
By using AI for hypothesis generation and telemetry for validation, we were able to identify suspicious activity that traditional searches for known tool fingerprints would have missed.
Our detection logic focused on two core behavioral techniques that look beyond the tools attackers use to register devices and instead examine how they operate:
#1 Naming Convention Anomaly Detection
Rather than looking for specific device names, we identify newly registered devices whose display names deviate from established organizational naming conventions, a pattern attackers struggle to emulate convincingly when they attempt to blend into your environment.
#2 Sequential Attack Correlation
Device registration is rarely an isolated event. By correlating Device Code Phishing alerts with subsequent device registration events, we significantly reduce the search space, allowing us to evaluate the entire attack chain rather than relying on isolated, and increasingly unpredictable, registration logs.
You can significantly reduce the risk of rogue device registration by enrolling a Conditional Access policy that requires MFA specifically for device registration (via user actions). Even if an attacker has a token for the device registration service, this policy forces them to complete an additional MFA challenge before they can register a new device.
How Wiz Can Help
Wiz Defend gives you clear visibility into identity attacks in Entra ID, using real-time alerts to spot the tactics used in device-code phishing and suspicious device registrations.
Wiz Defend includes dedicated detection rules that alert on these behaviors:
DESKTOP Device Registration by Known Toolkit
Suspicious device registration attempt
Anomalous DESKTOP Device Registered in Non-DESKTOP Environment
Potential Device Code Phishing IP Mismatch Detected
Potential Device Code Phishing
Unusual Device Code Flow Detected
With this early warning, security teams have time to contain an attack, reset credentials, remove unauthorized devices, and block new enrollments before an attacker gets long-term access.
KQL
Identify device naming conventions in tenant (In our example - Desktop devices)
let minDevicesForBaseline = 100;let desktopThreshold = 0.01;let windowStart = ago(14d);let windowEnd = now();SigninLogs| where ingestion_time() between (windowStart .. windowEnd) and ResultType == 0 and OperationName == "Sign-in activity"| where isnotempty(DeviceDetail["deviceId"])| extend deviceId = tostring(DeviceDetail["deviceId"])| extend deviceDisplayName = tostring(DeviceDetail["displayName"])| where isnotempty(deviceDisplayName)| extend HasMatch = deviceDisplayName startswith "DESKTOP-"| summarize TotalDevices = dcount(deviceId), DesktopDevices = dcountif(deviceId, HasMatch == true)| where TotalDevices >= minDevicesForBaseline| where (todouble(DesktopDevices) / todouble(TotalDevices)) <= desktopThreshold| project TotalDevices, DesktopDevices, DesktopRatio = todouble(DesktopDevices) / todouble(TotalDevices), IsRareDesktopTenant = true
Recognizing the partners, integrators, and visionaries driving cloud security transformation, AI risk management, and SOC modernization across AMER, EMEA, and ANZ.
Wiz Red Agent independently discovered and exploited a GitHub Actions injection missed by GitHub’s Advanced Security, validated access to sensitive data in Snowflake’s internal Jira, and assessed the blast radius—all without human intervention, five days after the flaw became live.