Honeypot-Accounts ו־Canary Tokens

Theory

So far we discussed defense that tries to prevent the attack. There is another principle: lure the attacker into a trap. The Deception idea is simple — place attractive baits (accounts, passwords, files) in the organization that no legitimate person would ever touch. Any interaction = an alert that the organization is under attack.

Two main techniques

Honeypot-Accounts: accounts with tempting names (svc_sql_backup, svc_exchange_admin) with a convincing description and a "password" that looks real but without real privileges. A is enabled on the account, logging every authentication/read/write attempt.
Canary Tokens: trap tokens that trigger an alert on contact — for example a fake Word file in a share, or a fake AWS key.

Why it is so powerful: an attacker who has breached the network must gather information (enumeration). They will try to read accounts, see who is admin, pull passwords. Every such step against a honeypot is a precise red flag with no legitimate outcome.

The attacker must enumerate. Left path: a honeypot account lures the attacker, SACL triggers events 4624/4768 and an alert. Right path: a file with a canary token is opened and sends an external alert. Any interaction = an alarm with near-zero false positives.

Short and clear

Deception — baits no legitimate user would ever touch; any interaction is suspicious.
A SACL on the honeypot account logs every authentication and read.
A canary token sends an external alert independent of DC logs.
Low false positives: there is no legitimate reason to touch the bait.

Real-life exampleAn internal scanner checked all accounts and triggered the honeypot. Identifying the source (scanner, not attacker) prevents a recurring false positive.

Practice — creating a honeypot account

New-ADUser -Name "svc_sql_backup" -SamAccountName "svc_sql_backup" `
  -Description "SQL Backup service account - do not disable" `
  -AccountPassword (ConvertTo-SecureString "N3verUseTh1s!" -AsPlainText -Force) `
  -Enabled $true

powershell

Enabling audit via GUI: Users and Computers → View → Advanced Features → account Properties → Security → Advanced → Auditing → Add: Everyone → Read/Write all properties → Success + Failure.

# Adding SACL from PowerShell
$account = Get-ADUser -Identity "svc_sql_backup"
$acl = Get-Acl "AD:$($account.DistinguishedName)"
$identity = New-Object System.Security.Principal.NTAccount("Everyone")
$rule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    $identity,
    [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty -bor
    [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,
    [System.Security.AccessControl.AuditFlags]::Success -bor
    [System.Security.AccessControl.AuditFlags]::Failure
)
$acl.AddAuditRule($rule)
Set-Acl "AD:$($account.DistinguishedName)" $acl

powershell

: go to canarytokens.org, create an MS Word Document token, save the file in an accessible share (\\fileserver\shared\). Every opening sends an email alert.

Detection

Event ID 4624 — a successful logon of the honeypot account = the highest-priority alarm.
Event ID 4768 — a request for the account (who does with svc_sql_backup?!).
Event ID 4776 — authentication against the honeypot — a sign of or password spraying.
Event ID 4662 — an attempt to read/write the object's attributes (enumeration).
Canary token trigger — an external alert independent of DC logs.

Mitigation and response

Any alert = urgent investigation: who touched it, from which computer, using what method.
Keep the honeypot realistic: a convincing description, not marked as disabled.
Track usage to prevent false positives (e.g. an internal scanner that checks all accounts).

Honeypot Accounts and Canary Tokens

What you will learn here