Deploys deception-based honeytokens in Active Directory including fake privileged accounts with AdminCount=1, fake SPNs for Kerberoasting detection (honeyroasting), decoy GPOs with cpassword traps, and fake BloodHound paths. Monitors Windows Security Event IDs 4769, 4625, 4662, 5136 for honeytoken interaction. Use when implementing AD deception defenses for detecting lateral movement, credential theft, and reconnaissance.
Instrucciones de origen · Vista previa de solo lectura
name
deploying-active-directory-honeytokens
description
Deploys deception-based honeytokens in Active Directory including fake privileged accounts with AdminCount=1, fake SPNs for Kerberoasting detection (honeyroasting), decoy GPOs with cpassword traps, and fake BloodHound paths. Monitors Windows Security Event IDs 4769, 4625, 4662, 5136 for honeytoken interaction. Use when implementing AD deception defenses for detecting lateral movement, credential theft, and reconnaissance.
When deploying deception-based detection in Active Directory environments
When detecting Kerberoasting attacks via fake SPN honeytokens (honeyroasting)
When creating tripwire accounts to detect credential theft and lateral movement
When building decoy GPOs to detect Group Policy Preference password harvesting
When creating deceptive BloodHound paths to misdirect and detect attackers
When supplementing existing AD monitoring with high-fidelity detection signals
Common Misconfigurations & Verification
AD honeytokens fail silently when they are either too obvious (attackers skip
them) or never wired to an alert (they trip but nobody knows):
Token too obvious / unrealistic: a brand-new account named
HONEYPOT_DONT_TOUCH with creation date == last-logon date == password date
is an instant tell. Make creation/last-logon/password-set dates internally
consistent and aged, set AdminCount=1, and use naming that matches real
service accounts (svc_sqlbackup_legacy).
SPN registered but no auditing: honeyroasting only works if Event ID 4769
for that ServiceName reaches the SIEM. Confirm Kerberos audit logging is on
and the DC forwards it.
Whitelisted into noise: vuln scanners and discovery tools touch the token
daily, so analysts mute the rule. Exclude scanner source IPs so a real hit
stands out.
How to confirm it actually alerts: trip it yourself - request a TGS for
the honey SPN with Rubeus kerberoast /user:svc_sqlbackup_legacy, read the
decoy GPO cpassword with Get-GPPPassword, and read the DACL on the honey
user. Verify 4769 / 4663 / 4662 fire and the SIEM rule pages within minutes.
Prerequisites
Domain Admin or delegated AD administration privileges
Active Directory domain (Windows Server 2016+ recommended)
Windows Event Log forwarding to SIEM (Splunk, Sentinel, Elastic)
PowerShell 5.1+ with ActiveDirectory module
Group Policy Management Console (GPMC)
Understanding of AD security, Kerberos, and BloodHound attack paths
Background
Why AD Honeytokens
Traditional signature-based detection misses novel attack techniques. Honeytokens
provide high-fidelity detection with near-zero false positives because any interaction
with a decoy object is inherently suspicious. In Active Directory:
Fake SPNs detect Kerberoasting reconnaissance (TGS requests for nonexistent services)
Decoy GPOs detect Group Policy Preference password harvesting
Fake BloodHound paths mislead attackers using graph-based AD analysis
Key Detection Event IDs
Event ID
Description
Honeytoken Use
4769
Kerberos TGS ticket requested
Detect Kerberoast against honey SPN
4625
Failed logon attempt
Detect use of fake credentials from decoy GPO
4662
Directory service object accessed
Detect DACL read on honeytoken user
5136
Directory service object modified
Detect modification of decoy GPO
5137
Directory service object created
Detect GPO creation mimicking decoy
4768
Kerberos TGT requested
Detect AS-REP roasting of honey account
Making Honeytokens Realistic
Per Trimarc Security research, effective honeytokens must appear legitimate:
Age the account: Repurpose old inactive accounts (10-15 year old accounts in
similarly aged domains appear authentic)
Set AdminCount=1: Flags the account as having elevated AD rights, making it
an attractive Kerberoasting target
Use realistic naming: Match organizational naming conventions (svc_sqlbackup,
admin.maintenance, svc_exchange_legacy)
Set old password date: Password age of 10+ years with an SPN looks like a
high-value, neglected service account to attackers
Add group memberships: Place in visible groups like "Remote Desktop Users" or
a custom "Backup Operators" to increase attacker interest
Avoid detection tells: Attackers check creation date vs. last logon vs.
password change date for consistency
Instructions
Step 1: Deploy Fake Privileged Admin Account
Create a honeytoken account that mimics a legacy privileged service account.
# Import the deployment module
Import-Module .\scripts\Deploy-ADHoneytokens.ps1
# Create a honeytoken admin account
$honeyAdmin = New-HoneytokenAdmin `
-SamAccountName "svc_sqlbackup_legacy" `
-DisplayName "SQL Backup Service (Legacy)" `
-Description "Legacy SQL Server backup service account - DO NOT DELETE" `
-OU "OU=Service Accounts,DC=corp,DC=example,DC=com" `
-PasswordLength 128 `
-SetAdminCount $true
Write-Host "Honeytoken admin created: $($honeyAdmin.DistinguishedName)"
Step 2: Deploy Fake SPN for Kerberoasting Detection
Assign a realistic but fake SPN to the honeytoken account. Any TGS request
for this SPN is definitively malicious (honeyroasting).
# Add fake SPN to honeytoken account
$honeySPN = Add-HoneytokenSPN `
-SamAccountName "svc_sqlbackup_legacy" `
-ServiceClass "MSSQLSvc" `
-Hostname "sql-legacy-bak01.corp.example.com" `
-Port 1433
Write-Host "Honey SPN registered: $($honeySPN.SPN)"
Write-Host "Monitor Event ID 4769 for TGS requests targeting this SPN"
Step 3: Deploy Decoy GPO with Credential Trap
Create a fake GPO in SYSVOL with an embedded cpassword (Group Policy Preference
password). Attackers using tools like Get-GPPPassword or gpp-decrypt will find
and attempt to use these credentials, triggering detection.
