Monitor Honeytokens with Defender for Identity

What Are Honeytokens and Why They Matter

Honeytokens are fake high‑value artifacts planted to detect malicious activity early. Examples of these artifacts include user accounts, API keys, files, or shares. When an attacker enumerates identities, harvests credentials, or tries lateral movement, interacting with a honeytoken produces a high‑signal alert with minimal false positives.

Why they’re important:

  • Reduce dwell time: Trigger alerts at the reconnaissance or initial access stage.
  • High fidelity: You control who should ever use them: nobody. Any touch is suspicious.
  • Low blast radius: If configured correctly, they can’t be abused to damage production.
  • Threat intel: Alerts provide IP addresses, tool names, and Tactics, Techniques, and Procedures (TTPs) used in your environment.

Typical honeytoken flavors:

  • Identity honeytokens: Fake user/service accounts (focus of this article).
  • Credential honeytokens: Decoy API keys, access tokens, password vault entries.
  • Data honeytokens: Canary docs, decoy file shares, or links that phone home when opened.

Should Honeytoken Accounts Have Elevated Permissions?

Absolutely not! Do NOT assign real roles, powerful group memberships, app consents, mailboxes, or licenses. A privileged honeytoken turns a tripwire into a ready‑made escalation path if detection ever fails.

Design goal: Credible appearance of privilege with zero actual capability.

Avoid granting:

  • Entra roles: Global Admin, Privileged Role Admin, Exchange/SharePoint/Teams admin roles, Application/Cloud App Admin.
  • Privileged groups: Domain Admins/Enterprise Admins (on‑prem), any Tier‑0 groups, or production resource owner groups.
  • Mailbox/licenses: No M365 license or mailbox.
  • App/API permissions & SPNs: No app consents, app role assignments, or SPNs tied to real apps.

If realism is required, scope access to isolated decoys only (e.g., Reader role on a quarantined subscription or local admin on a non‑routed sandbox VM). Never to production.

Getting Creative with Honeytoken Account Names

Honeytoken account names should look like valuable admin or service identities attackers probe while having zero real rights. Follow your organization’s naming patterns (svc-, adm-, sys-) and add realistic context (-prod, -ops, -backup) so they blend in.

Avoid exact matches to real accounts, don’t include words like “honey” or “decoy,” reserve the UPNs to prevent collisions, hide them from the GAL, and exclude them from HR or lifecycle flows.

Accounts can be placed in OUs of your choosing – follow organization standards and either use an existing OU to make it more realistic or create new OU. Ensure that Group Policies don’t automatically provide additional permissions or functionality to the honeytoken account placed in the OU.

Example names:

  • svc_backup-admin
  • admin_build
  • cloud-root-sync
  • o365-globaladm
  • AWS_connector
  • SQL-svc-prod
  • AzureVM-admin
  • automation-SVC
  • IDM_sync
  • IntuneJoin-svc

How to Deploy Identity Honeytokens (Entra ID & Hybrid AD)

A. Entra‑only (Azure AD / Microsoft 365)

  1. Create a cloud‑only user with a privileged‑sounding name (see above)
  2. No roles, no groups, no licenses, no mailbox.
  3. Block interactive sign‑in via Conditional Access (CA):
    • Target: the honeytoken account(s)
    • Cloud apps: All cloud apps
    • Grant: Block access
  4. Prevent registration: Exclude from MFA/SSPR registration policies and device registration.
  5. Strong random password (rotated and stored in your secrets manager), even if unused.
  6. Hide from GAL and HR/lifecycle workflows to avoid confusion.
  7. Tag for monitoring: Place in a Honeytokens security group to drive detections/watchlists.

B. Hybrid Active Directory (On‑prem + Entra)

  1. Create a standard user with no privileged group memberships (no DA/EA/BA, no server local admins).
  2. Mark Account is sensitive and cannot be delegated.
  3. Apply GPO deny log on locally/through RDP where appropriate (especially Tier‑0 servers).
  4. No SPNs (avoid creating unintended Kerberos paths).
  5. Sync to Entra if you want cloud‑side telemetry and CA protection.
  6. In Defender for Identity (MDI), mark the account as a honeytoken to generate high‑fidelity alerts on on‑prem touches.

Monitoring with Microsoft Defender for Identity (MDI)

Defender for Identity adds visibility into on‑prem AD recon and lateral movement. When you mark a user as a honeytoken in MDI, interactions like authentication attempts, LDAP/Kerberos queries, or enumeration from that account generate dedicated alerts.

Operational tips:

  • Keep a dedicated “honeytokens” tag/metadata so IR and SOC instantly recognize the signal.
  • Use entity pages in the Defender portal for fast triage across correlated events.
  • Pair MDI alerts with SIEM automation to enrich, notify, and open incidents.

Extending Visibility with Other Microsoft Tools

Microsoft Sentinel (SIEM): Centralize telemetry (Sign‑in logs, Audit logs, MDI alerts) and create analytics rules. Maintain a Watchlist of honeytoken UPNs to drive detections and hunting.

Microsoft Defender XDR: Use Advanced Hunting to pivot on identity‑related events across devices, identities, email, and cloud resources.

Microsoft Defender for Cloud Apps (MDCA): Monitor for suspicious OAuth app consents or strange cloud app usage patterns involving honeytoken identities (should be none). Create policies that alert on any honeytoken sign‑in to sanctioned apps.

Identity Protection (Entra): Optional—but consider user/sign‑in risk detections as another correlation signal. Honeytokens should never accrue normal risk over time; spikes are noteworthy.

Ready‑to‑Use Analytics (KQL)

Replace the example UPNs ([“svc_backup-admin@contoso.com”,”adm_build@contoso.com”]) with your own. Store them in a Sentinel Watchlist named Honeytokens and join against it for easier maintenance.

1) Any sign‑in attempts involving honeytokens (cloud)

let Honeytokens = dynamic(["svc_backup-admin@contoso.com","adm_build@contoso.com"]);
SigninLogs
| where UserPrincipalName has_any (Honeytokens)
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription,
AppDisplayName, IPAddress, Location, ConditionalAccessStatus

2) Role/group changes touching honeytokens (cloud)

let Honeytokens = dynamic(["svc_backup-admin","adm_build"])
AuditLogs
| where OperationName in ("Add member to role","Add eligible member (PIM)",
"Add member to group","Update user",
"Add app role assignment to user")
| where tostring(TargetResources) has_any (Honeytokens)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
TargetResources, Result

3) MDI Honeytoken alerts (on‑prem)

SecurityAlert
| where ProductName == "Microsoft Defender for Identity"
| where tostring(Entities) contains "Honeytoken"
| project TimeGenerated, AlertName, Severity, CompromisedEntity = tostring(Entities)

Detonation Playbook (IR Workflow)

When a honeytoken fires, treat it as potential hands‑on‑keyboard:

  1. Enrich the alert: IP, ASN, geolocation, device, user agent, app, and recent auth noise.
  2. Scope: Look for lateral movement, failed logons, password spray, or mass enumeration from the same source.
  3. Contain: Block offending IPs (temporary), disable suspicious session tokens, and isolate compromised endpoints.
  4. Hunt: Pivot across MDI, SigninLogs, AuditLogs, and MDE device telemetry for adjacent activity.
  5. Report & learn: Update detections, tune CA coverage, and expand decoys where attackers looked next.

Common Pitfalls

  • Granting roles in prod (even Reader): Metadata exposure still hurts. Keep access limited to decoys.
  • Accidental mailbox/licensing: Bulk licensing rules can bite – explicitly exclude honeytokens.
  • CA policy gaps: Ensure All cloud apps are covered; avoid exceptions that create backdoors.
  • Untracked sprawl: Maintain as‑code inventory: names, UPNs, CA policy IDs, MDI tag status.
  • No testing: Simulate failed sign‑ins from varied IPs/agents to validate telemetry and alerting.
  • No communication: Make sure all relevant teams are aware of honeytoken accounts.
  • Missing documentation: Ensure that the honeytoken accounts are well documented.

Quick Checklist

Create: Cloud‑only user; privileged‑sounding name; hide from GAL; strong password stored.
Deny: No roles, groups, licenses, mailboxes, SPNs, app consents, or device ownership.
Block: CA policy → All cloud apps → Block access; exclude from MFA/SSPR/device registration.
Tag: Add to Honeytokens group; tag as Honeytoken in MDI (for hybrid).
Detect: Sentinel watchlist + analytics for sign‑ins and role/group changes; MDI honeytoken alerts.
Drill: Test quarterly; include in red‑team exercises with controlled scenarios.

Conclusion

Honeytokens are a low‑cost, high‑impact way to catch adversaries early. Keep them powerless, make them believable, and wire them into Defender for Identity, Defender XDR, and Sentinel so that the first touch becomes your earliest warning – not the first beachhead.