The device was called Work PC. It registered itself into a Microsoft Entra ID tenant carrying a user agent string of MSTokens-PRT/1.0, a product name that sounds like something Microsoft ships and is not. Neither string trips a detection written for the tooling defenders have watched for years. That is roughly the point.
Wiz's threat research team pulled that example out of tenant telemetry while testing a question defenders will keep facing: what happens when attackers stop leaving the same fingerprints? Its answer, in a post published this week, is that much of Entra ID device registration detection rests on naming conventions attackers can change for free.
Why a criminal bothers enrolling a laptop
Conditional Access policies commonly restrict sign-ins to devices joined to the tenant. The Device Registration Service exists so employees can enrol their own machines, so an attacker holding a victim's identity enrols theirs, and the policy is satisfied rather than bypassed. Wiz reports that across a 90 day period, nearly one in seven Entra ID environments experienced at least one such attack. The usual way in is device code phishing: the team observed the AWS address 3[.]149[.]231[.]11 across device code sign-ins associated with multiple victims, and URLScan captured a phishing page at lockwall[.]xyz/prime/ using a shared document lure to hand visitors a pre-generated Microsoft device code. Once the rogue device is on the tenant, the operator reads mail, exfiltrates data and keeps a foothold. It is the same shape as the device code campaign Amazon disrupted earlier this year.
The fingerprints defenders were relying on
Much of this activity ran on ROADrecon, the open source Entra exploitation framework, and automation made it consistent. Consistency handed defenders cheap indicators: a user agent of Dsreg/10.0 (Windows 10.0.19041.928), and device names in the DESKTOP-XXXXXXXX pattern. Wiz says that pattern still affects almost one in ten of its customer base, so the indicator has not stopped earning its keep. It is also trivially avoidable, and the team has logged names such as microsoft-XXXXXXXX alongside blandly generic ones like Work PC.
They asked the models what they would call it
The hunt Wiz describes put AI on both sides of the fence. The team asked Claude to review unusual user agent strings from device registration and sign-in activity for characteristics consistent with AI-generated tooling, which is how MSTokens-PRT/1.0 surfaced: its plausible product name and clean version structure resembled patterns the team had seen before, such as Azure-Enum/1.0. It then queried several models from an attacker's perspective, asking which device names would make a registration look inconspicuous, and compared the recurring suggestions with identifiers in real telemetry. Wiz is careful about what that establishes. The experiment was not intended to prove any artifact was AI-generated, and the post states that a generic device name or an unfamiliar user agent cannot provide reliable attribution on its own. The model output supplied hunting hypotheses, validated afterwards with behavioral context.
The two detections the team landed on name nothing at all. The first flags newly registered devices whose display names deviate from the organization's established naming convention, on the reasoning that an outsider cannot convincingly guess house style. The second correlates a device code phishing alert with the registration that follows it, shrinking the search space to a chain of events rather than an isolated log line.
Require MFA for the registration itself
The preventive control Wiz points to is a Conditional Access policy that requires multi-factor authentication specifically for the device registration user action. An attacker who has phished a token for the registration service still has to clear a second challenge before a rogue machine lands in the tenant. That holds regardless of what the device is called, and it does not decay when the naming conventions shift again. Identity abuse in Entra keeps finding legitimate features to lean on, from agent identities that can be made to send mail to the enrolment service itself.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.