Skip to content

Back to the catalog

dfir.chwriteup

Microsoft Defender XDR's Deception Technology

A DFIR investigation into mysterious domain admin accounts (e.g. "amol.paulson") appearing across an organization's devices, traced back to Microsoft Defender XDR's built-in deception capability, which auto-generates decoy accounts and hosts as lures. The post details how to identify a decoy-account login via local (not network) authentication preceded by a specific PowerShell script execution, and decodes the base64 JSON descriptor blob (containing DetectionKeys, LureDeploymentContext, UserRid, etc.) that reveals which decoy account triggered the alert — useful so defenders don't mistake this feature for an intrusion.

TL;DR Explains how Microsoft Defender XDR's built-in deception feature plants decoy domain admin accounts, and how to identify their logins via PowerShell artifacts so DFIR teams don't mistake them for a breach.
Open original ↗
Document

What it is

A DFIR.ch incident writeup on Microsoft Defender XDR's deception technology — the built-in feature that generates decoy (honey-token) domain admin accounts and hosts, then plants lures across the environment. The post exists to stop responders from escalating decoy-account logins as a real breach. Two "domain admin" users that logged into nearly every device, matched no employee, and appeared in no directory (Azure AD, on-prem AD) turned out to be Defender decoys. A Reddit user reported the same pattern (account amol.paulson, on many but not all devices, in reports as a domain account but findable nowhere).

How it works

Deception is off by default; enabling it auto-creates and turns on a default rule that generates decoy accounts/hosts and pushes lures. Scope is all devices, but lures are only planted on Windows client devices. The decoy accounts look ordinary if you inspect their properties — the tell is in behavior and logs.

Just before a decoy logs into a machine, Defender runs PowerShell locally (the login is a local login, not over the network). The script lives under C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{GUID}.ps1, verifies its own SHA256, and transcripts to ...\Temp\PSScriptOutputs\. It is invoked with a -Descriptor argument: a base64 JSON blob whose DetectionKeys field names the decoy account. That blob's Content field is another base64 JSON containing UserRid and ShouldSuppressDummyLogin: true, plus a LureDeploymentContext with an ExpirationUtc.

Preconditions / Affected

Only relevant where an admin has explicitly enabled Defender XDR deception. Once on, the default rule fans decoys out organization-wide, so any environment with the feature enabled can surface these confusing "phantom admin" accounts.

What to do

To confirm a suspicious login is a decoy rather than a compromise, before escalating:

  • Check whether the account exists in Azure AD / on-prem AD — decoys will not.
  • Look in PowerShell logs on the target machine for a script run from the Windows Defender Advanced Threat Protection\Downloads path with a -Descriptor base64 argument.
  • Decode the Descriptor blob and read DetectionKeys — it holds the decoy username. Optionally decode the nested Content blob for UserRid / ShouldSuppressDummyLogin.
  • Cross-reference against the deception default rule, which lists the created decoy accounts, to confirm the match.

Caveats

The author notes there is limited public documentation of the JSON parameters; the interpretation is derived from analyzing the executed PowerShell rather than official references. Confirmation still rests on cross-referencing the default rule's decoy list, so access to the Defender deception configuration is needed to close the loop.

Technologies named here

Techniques named here

  • Deception technology / decoy accounts
  • Local login detection via PowerShell execution artifacts

Related in Blue Team & Detection