Site icon Windows Active Directory

Using canary tokens in AD to detect breaches

Arun Kumar

Canary tokens are deliberate “tripwires”: objects, credentials, or breadcrumbs that should never be touched in normal operations. When an attacker (or an automated tool) interacts with them, you get a high-signal alert that something is wrong—often early, before full domain compromise.

This guide focuses on practical canary patterns that work well in Active Directory (AD), how to deploy them safely, and how to wire detections into your SOC. If you need a quick refresher on how authentication/authorization and access tokens actually work in AD, start here: Authenticating and authorizing objects in AD.

What a canary token is (in AD terms)

In an AD environment, “canary tokens” usually mean one of these:

  • Canary credentials: a username/password (or hash) planted where it should never be used.
  • Canary objects: users, groups, SPNs, GPO links, or computer objects that should never be modified or authenticated.
  • Canary resources: a share, file, printer, or URL that should never be accessed.
  • Canary telemetry hooks: detections wired into identity sensors, Windows logs, or your SIEM to raise an alert when touched.

The key idea is not “more logging.” It’s creating an event that is inherently suspicious because legitimate usage should be zero.

Where canaries fit in an AD detection strategy

Canary tokens complement (not replace) identity threat detection products and baselining. Think of them as booby-trapped choke points placed along common attacker workflows:

  • Credential harvesting and reuse
  • Kerberos abuse (ticketing, SPN hunting)
  • Privilege escalation and group membership tampering
  • Recon and enumeration of high-value targets
  • Persistence via GPO, scheduled tasks, or rogue services

Many organizations pair canaries with Microsoft Defender for Identity (MDI) or a SIEM. If you’re using MDI, these two articles help you understand the coverage and what you must collect: Microsoft Defender for Identity: A comprehensive overview and Event collection with Microsoft Defender for Identity.

High-signal canary patterns for AD

1) Canary user account (credential tripwire)

Create a decoy user that should never authenticate. Then “seed” the credentials where attackers commonly scrape: internal documentation, old scripts, a bait GPP preference file in a lab share, or a decoy vault entry. When the account is used, alert immediately.

Design rules for a strong canary account:

  • No real privileges. Do not add it to privileged groups. Ever.
  • Deny interactive logon (workstations and servers), and block RDP.
  • Restrict logon to “no systems” (or to a non-existent host) and/or use logon hour restrictions.
  • Never used by automation. The only purpose is detection.
  • Unique name that looks “interesting” to attackers (but doesn’t confuse admins).

2) Canary SPN (Kerberos reconnaissance tripwire)

Many attackers enumerate SPNs and request service tickets to attempt offline cracking (Kerberoasting). A canary service account with an SPN can generate a high-signal event when ticket requests appear. Understanding Kerberos/NTLM helps here: NTLM authentication and Kerberos protocols explained.

Practical approach:

  • Create a canary user (no privileges).
  • Assign a “fake” SPN (e.g., HTTP/canary-app).
  • Alert on abnormal service ticket requests (4769) for that SPN.

3) Canary group membership (privilege tampering tripwire)

Create a harmless “Canary-Admins” group that should never be used and never have members added. Alert on:

  • Any member add/remove to that group
  • Any ACL change on the group object

This catches “test edits” and automated privilege escalation tooling that tries multiple groups. (It also teaches your team to treat group changes as high-value events.) For the fundamentals behind object permissions and why ACL changes matter, see: Active Directory permissions explained.

4) Canary file on a sensitive share (share crawling tripwire)

Attackers often crawl SYSVOL/NETLOGON and common file shares looking for scripts, credentials, and infrastructure clues. Drop a decoy file with a canary URL/token:

  • \\corp\NETLOGON\VPN-Password-Reset-Instructions.docx
  • \\corp\IT\Passwords\BreakGlass_ReadMe.txt

Alert when the file is read or copied (SMB access auditing + SACLs), or when the embedded token calls home. Use unique filenames that match your environment’s naming style.

5) Canary DNS record (recon tripwire)

Add a decoy DNS record that looks valuable (e.g., filesync-prod, backup-core, k8s-master), but points nowhere. Alert on DNS queries for that name from unexpected hosts.

6) Canary “admin-like” breadcrumb (credential stuffing tripwire)

If you want to detect brute force or password spraying against attractive identities, create a canary account that resembles a legacy admin naming pattern (for example, adm.backup), but with strong controls and no permissions. Alert on any failed logons and any successful authentication.

Step-by-step: building a “canary account” the safe way

Below is a practical baseline. Adjust to your policies and test in a non-production OU first. The goal is: the account should never be used, and any use should page someone.

Step 1: Create the canary user in a dedicated OU

# Requires RSAT ActiveDirectory module
# Create a dedicated OU like "OU=Canaries,DC=corp,DC=local" first.

$ou = "OU=Canaries,DC=corp,DC=local"
$uname = "svc_canary_backup"
$upn = "$uname@corp.local"

New-ADUser `
  -Name "Service Canary - Backup" `
  -SamAccountName $uname `
  -UserPrincipalName $upn `
  -Path $ou `
  -Enabled $true `
  -AccountPassword (Read-Host -AsSecureString "Set a strong canary password") `
  -Description "CANARY ACCOUNT - SHOULD NEVER BE USED. Any authentication is an incident." `
  -PasswordNeverExpires $false `
  -ChangePasswordAtLogon $false

# Optional: make it harder for helpdesk mistakes
Set-ADUser $uname -CannotChangePassword $true

Step 2: Deny interactive use via GPO

Use Group Policy to block interactive logon paths for the canary account (or for the entire Canary OU via a group). Recommended user rights to deny:

  • Deny log on locally
  • Deny log on through Remote Desktop Services
  • Deny access to this computer from the network (only if you still want to allow specific network auth scenarios; otherwise leave it allowed and alert on any use)

The exact mix depends on your canary design. For “credential use = incident,” denying interactive logons is a safe default.

Step 3: (Optional) Add a canary SPN

If you want a Kerberos ticketing tripwire: 

# Example SPN
setspn -S HTTP/canary-backup-app corp\svc_canary_backup

Alert on service ticket requests for that SPN (commonly Event ID 4769 on DCs).

Step 4: Seed the credential carefully

Do not spray canary creds everywhere. Place them where an attacker would plausibly find them:

  • A decoy “runbook” in an internal wiki (not the real runbook area)
  • A decoy script on a share that resembles legacy admin tooling
  • A decoy text file in a “Migration” folder (attackers love old migration artifacts)

Keep placement limited so you can triage alerts quickly (“which breadcrumb was touched?”).

Alerting: what to log and how to route signals

Canary value comes from fast, reliable alerting. Use at least two paths where possible: (1) Windows/DC events and (2) an identity detection tool or SIEM correlation.

Core signals to alert on

  • Any successful logon for the canary user (e.g., Event ID 4624 on the authenticating system / DC depending on logon type).
  • Any failed logon bursts for the canary user (e.g., 4625) indicating password spraying or guessing.
  • Kerberos ticketing for canary SPNs (commonly 4769).
  • Group membership change events for canary groups (adds/removes).
  • Object ACL changes on canary objects (advanced auditing / directory service access).
  • File access events for canary files (share auditing + SACLs).
  • DNS queries for canary hostnames from unusual subnets/devices.

Practical routing

  • Send canary alerts to a high-priority channel (PagerDuty/Teams/Slack/SMS) with strict noise control.
  • Include who, where, and how: source device, source IP, logon type, process (if available), and the exact canary that was touched.
  • Auto-enrich with identity context: device owner, recent sign-in history, and whether the device is managed.

If you’re using MDI, ensure your event collection is correct so canary activity isn’t missed: Event collection with Microsoft Defender for Identity.

Pitfalls and hardening tips

Avoid false positives by design

  • Keep canaries out of real workflows (no service dependencies, no scheduled tasks, no “temporary” use).
  • Name clearly in Description so admins don’t “fix” it and accidentally use it.
  • Scope visibility: seed credentials in places attackers will reach, not everywhere employees browse.

Assume attackers will test safely

Skilled attackers may “validate” credentials without fully logging on (or may try them against a less monitored endpoint). That’s why it’s powerful to pair multiple canary types:

  • Canary credential + canary SPN ticketing alerts
  • Canary file + SMB auditing
  • Canary DNS + resolver logs

Protect the canary’s containment

Don’t let a canary become a stepping stone:

  • No privileged group memberships
  • No delegated rights on OUs
  • No access to shares beyond what’s needed to generate the detection
  • Consider placing canaries in a dedicated OU with strict ACL review

Run tabletop triage

Before going live, rehearse what happens when a canary fires:

  • Who is on-call?
  • What is the first 10-minute playbook?
  • What gets isolated first (device, account, subnet)?
  • What logs do you pivot to?

Implementation checklist

  • Create a dedicated “Canaries” OU and document ownership.
  • Deploy 1–2 canary users (no privileges) and deny interactive logon via GPO.
  • Optionally add a canary SPN and alert on service ticket requests.
  • Create a canary group and alert on membership changes and ACL changes.
  • Place 1–2 canary files on shares attackers commonly crawl; enable auditing and/or embed a token callback.
  • Add a decoy DNS record and monitor queries.
  • Wire alerts into your SIEM/SOAR and page the right channel.
  • Test alerting monthly and rotate/refresh tokens periodically.

FAQ

Are canary tokens “honeypots”?

They’re related. Honeypots are typically full decoy systems or services. Canary tokens are usually lightweight tripwires: a credential, object, file, or record that should never be accessed.

Will attackers ignore canaries?

Some advanced attackers try to avoid them, but canaries still catch a lot of real-world intrusion paths: opportunistic attacks, automated tooling, lateral movement scripts, and internal misuse. The goal is not perfection—it’s fast detection with minimal noise.

How many canaries should I deploy?

Start small: 2–3 high-signal canaries (one credential, one SPN/group tripwire, one file/share tripwire). Prove the alert pipeline works, then expand coverage based on your environment’s attacker paths.

Exit mobile version