The Poor Man’s Honeypot; setting up a simple honey token

TL;DR how to setup a honey token, aka a honey file, to audit for those scanning all domain share drives for information useful in an attack.

Welcome to Part XIII of our Back to the Basics Series!

Part I: NTDS.dit vs SAM

Part II: Ownership Matters

Part III: Recovering from a Crash

Part IV: Setting up a Simple Honeypot Account

Part V: Automating DC Deployment

Part VI: Sometimes it’s the dumbest thing

Part VII: Merry Christmas, macros, & Base64

Part VIII: Why old 0 Days make great teaching tools

Part IX: PowerShell & PS1s without PowerShell.exe

Part X: Ownership & so called “effective permissions”

Part XI: Windows Event Forwarding & SACLs

Part XII: Poorly planned honeypots & other Bad Ideas

Part XIII: Setting up a simple honey token

Part XIV: Smartcards and Pass-the-Hash

Part XV: Forwarding logs to Sentinel & basic alerts

Part XVI: Automating VM deployments in Hyper-V

Part XVII: Migrating the lab from ESXi to Hyper-V

Part XVIII: Centrally managing Hyper-V & Live Migrations

Background

In earlier howtos we touched on how to setup a honey account as one way to monitor for password spraying. We went over SACLs and Windows Event Forwarding. We went over an example of a really bad idea for a honey account that could easily lead to a privilege escalation.

I had heard of “honey things” in various courses in the past. The idea is a new adaptation of the old honeypot. A honeypot is of course a VM whose sole purpose is to detect attackers who scan all systems on the network looking for a vulnerable one. “Honey things” are simply files, user accounts, certificates, and so on that are sprinkled throughout the legitimate domain. They are not used for anything and should not lead anywhere, contain any real information, or have any real privileges. They are there simply to detect attackers or disgruntled insiders who are scanning the entire domain.

We setup Exchange in the lab earlier while going over some bad info that ChatGPT put out. It came in quite handy here.

The honey share

Our idea in this particular lab project was to

• Create a shared folder that’s not mapped anywhere
• Put some empty and/or meaningless data in it that however looks interesting from an attacker standpoint
• Set SACLs on some files in that share to log ‘Read’
• Monitor for Event ID 4663 on those files
• If any activity is seen, lock the account, set an account description, and email an alert to admins with the details.

Of course in a real production domain an organization might only want to email an alert, not lock the account, in case a Domain User was simply bored and wandering around.

Regardless, any access to the honey share and especially the files in it are automatically suspicious since someone would have to scan to even find it and there’s no legitimate reason to poke around in it.

Setup the share

Conceptually, to borrow a phrase SANS seemed to love, this part is simple. Create a share and put some meaningless but interesting looking data in it. An easy way to do this is to use ntdsutil to backup a temporary lab’s AD, then drop that backup in a share called Backup. Meaningless data that won’t get an attacker anywhere in the real domain, but it sure looks interesting. It looks like an administrator who wasn’t very security minded left an AD backup where Domain Users could read it …

One has to first enable auditing of object access in Group Policy under

Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Object Access

Then create the honey share, put some interesting files in it, and configure the SACLs

New-Item -ItemType Directory -Path "C:\Backup"
New-SmbShare -Name "Backup" -Path "C:\Backup" -ReadAccess "Domain Users"
New-Item -Path "C:\Backup\ResetPasswords.ps1"
Copy-Item '\\Test2025\C$\Temp\IFM' -Destination "C:\Backup" -Recurse

#borrowed from https://technochat.in/set-file-system-auditing-via-powershell/
$Target = "C:\Backup\ResetPasswords.ps1"
$AuditUser = "Everyone"
$AuditRules = "Read"
$InheritType = "None"
$AuditType = "Success"
$AccessRule = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser,$AuditRules,$InheritType,"None",$AuditType)
$ACL = Get-Acl $Target -Audit
$ACL.SetAuditRule($AccessRule)
$ACL | Set-Acl $Target

#Could be either Event Id 4656 or 4663, but we have only been seeing 4663
$Events = Get-WinEvent -LogName Security | Where-Object {($_.Id -eq "4663") -or ($_.Id -eq "4656")}

# - - Extra honey token - -
$Target = "C:\Backup\IFM\Active Directory\ntds.dit"
$AuditUser = "Everyone"
$AuditRules = "Read"
$InheritType = "None"
$AuditType = "Success"
$AccessRule = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser,$AuditRules,$InheritType,"None",$AuditType)
$ACL = Get-Acl $Target -Audit
$ACL.SetAuditRule($AccessRule)
$ACL | Set-Acl $Target

Confirm

(Get-Acl -Path C:\Backup\ResetPasswords.ps1 -Audit).Audit

(Get-Acl -Path 'C:\Backup\IFM\Active Directory\ntds.dit' -Audit).Audit

On a sidenote, we may have to make a cheatsheet for SACLs later. Information on setting and tweaking them in AD was just about as scarce as that for DACLs out there on Google. Luckily both the theory and the syntax for both is similar, so if you get a handle on one then it’s much quicker to get going on the other.

Setup the trigger

For simplicities sake we ran this project off a lab DC and used an email address for a Domain Admin to send the alert to. Obviously in production Domain Admin accounts wouldn’t have an email, that would be on their Domain User, day to day account. The honey share would also be on a member server. Additionally as we hard coded the credentials to send the alert email from, if you are going to actually use this then create a user account and email that has no privileges besides sending email.

$ErrorActionPreference = "SilentlyContinue"
do
{
if(Get-EventLog -LogName Security -InstanceId 4663 -Message "*C:\Backup*" -Newest 1 | Where-Object {$_.TimeGenerated -ge (Get-Date).AddHours(-.5)})
{

$Event = Get-WinEvent -LogName Security | Where-Object {($_.Id -eq "4663") -and ($_.Message -like "*C:\Backup*") -and ($_.TimeCreated -ge (Get-Date).AddHours(-.5))} | Select-Object -First 1
$Offender = $Event.Properties[1].Value
$Time = $Event.TimeCreated
$FileAccessed = $Event.Properties[6].Value
$Logon = Get-WinEvent -LogName Security | Where-Object {($_.Id -eq "4624") -and ($_.Message -like "*$Offender*")} | Select-Object -First 1
$OffenderIP = $Logon.Properties[18].Value

Set-ADUser -Identity $Offender -Enabled $false -Description "Potential compromised user account detected!"

$username = "<username>@test.local"
$password = "<password>"
$sstr = ConvertTo-SecureString -string $password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential -argumentlist $username, $sstr
$EmailBody = "$Offender accessed $FileAccessed at $Time from IP $OffenderIP. This is highly suspicious as $FileAccessed is a honeytoken. Please look into this and initiate our INC Response plan if required."
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
Send-MailMessage -To "mishky@test.local" -from "mishky@test.local" -Subject 'Potential compromised user account detected' -Body $EmailBody -smtpserver TestExchange -Credential $cred

Write-Host "$EmailBody"
Write-Host "Hide your kids, hide your WiFi! Exiting …"
break
} #Close the if($Event)
else{Write-Host "Nothing found yet" ; Start-Sleep -Seconds 120}
} #Close the do
while($true)

Putting it all together

We will pretend that Test.Dummy was a typical careless user who clicks on every link in every phishing email, downloads random executables off the Internet, plugs random thumb drives they found in the parking lot into their domain workstation, etc etc. Their account and workstation are now compromised and an attacker is performing internal recon and enumeration as them.

The attacker fires up PowerView and looks for interesting shares.

Find-InterestingDomainShareFile

This causes our trigger to fire.

Summary

Conceptually honey things are simple. The trick is to make sure they are meaningless, lead nowhere, but look interesting. They should be something that only an attacker or a disgruntled insider would find.

I know I am probably preaching to the choir by saying “honey tokens shouldn’t lead anywhere”, but I have seen some horrible advice in that area.

References

Set SACL on NTFS: https://technochat.in/set-file-system-auditing-via-powershell/

NTFS rights: https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.filesystemrights?view=net-6.0

Audit policy in AD: https://www.lepide.com/how-to/enable-active-directory-security-auditing.html

NTFS auditing: https://www.lepide.com/how-to/track-who-read-files-on-your-windows-file-servers.html#:~:text=To%20see%20who%20reads%20the,and%204663%20will%20be%20logged.

Send email from PowerShell: https://stackoverflow.com/questions/36385416/smtpclient-failure-during-send-concerning-arguments

Scan for interesting shares: https://powersploit.readthedocs.io/en/latest/Recon/Find-InterestingDomainShareFile/

PowerSploit: https://github.com/PowerShellMafia/PowerSploit/