Active Directory Deception Technology

2020-04-01

What are Honeypots and Deception Technologies?

Honeypots and Deception Technology (finally) provide an opportunity for defenders to be one step ahead of attackers.

In cybersecurity, a honeypot is a system designed to appear attractive to an adversary and lure them into attacking it. This provides responders an opportunity to study adversary tradecraft or perhaps trigger an alarm, signaling malicious activity within an environment. Similarly, deception technology is a decoy system/object that appears to be enticing to an attacker, but alerts blue teams on attacker activity. With deception technologies, the primary focus is alerting on malicious activity, whereas honeypots focus on the studying of an adversary.

Below are three variants of (many) honeypots and deception technologies, the third of which this article is dedicated to.

1. Public-Facing Systems - It is common to hear security researchers discuss attacks being seen "exploited in the wild" or "an increase in scanning activity." One of the many ways this information is collected is through public-facing systems that appear to be vulnerable. Setting up a public honeypot to monitor for scanning activity is easy to accomplish such as by using this article, Build your own RDP Honeypot, to monitor for BlueKeep scanning activity.

2. Documents - Enticing documents with names "passwords.docx" or "Exec. Bonuses 2019.docx" which are placed on file shares could lure both attackers and curious employees into opening them. Word macros can be leveraged to alert on the opening of these documents, which can identify an employee or rogue actor. While there is certainly a place for decoy documents, they are notorious for false positives. Thinkst Canary is one of the leaders in this space, and they allow their decoy document to be demoed.

3. Active Directory Deception Technologies - There are certain Active Directory (AD) objects that appear enticing to an attacker, such as accounts within the Domain Admins group, accounts with passwords set to never expire with passwords last set 2+ years ago, and legacy Microsoft Windows systems lacking the latest security updates. Alerts can be configured via Windows Events to alert on the abnormal querying of these objects.

The Need for Active Directory Deception Technology

Once threat actors gain an initial foothold in an environment, they will perform discovery techniques to identify how to gain further persistence and escalate privileges. AD reconnaissance is a given for both pentesters and sophisticated actors. Tools such as PowerSploit's PowerView allow for the querying of AD over Lightweight Directory Access Protocol (LDAP) which is nearly impossible to detect ( however I'm certainly open to suggestions on this), except for excellent network visibility into LDAP traffic containing privileged group names, in the case of querying for group membership.

How to Deploy AD Deception Technology

AD deception can be implemented in a variety of ways including in Active Directory, as I recently discovered in Nikhil Mittal's blog post, Forging Trusts for Deception in Active Directory. He describes his Deploy-Deception PowerShell module which eases deploying decoy/honeypot users in AD. Deploy-Deception’s decoy objects can be used to detect tools such as PowerView by alerting on the querying of abnormal or unusual object properties, such as the x500uniqueIdentifier property. This property is queried via PowerView over LDAP, but not when using the Windows net commands (e.g. net user...).

While Mittal's Deploy-Deception GitHub project goes in more depth, I ran the following command to deploy a decoy user designed to detect the PowerView querying of x500uniqueIdentifier:

PS C:\> Import-Module C:\Deploy-Deception\Deploy-Deception.psd1
PS C:\> Create-DecoyUser -UserFirstName blake -UserLastName jarvis -Password Ppe6h2^^tNRvf | Deploy-UserDeception -UserFlag PasswordNeverExpires -GUID szY976DX-bz7w-ui3w-0i6w-7AnZ93gESzwp -Verbose

This command needs to be ran on a Domain Controller by an account within the Domain Admins group, as it both creates a new user and configures the Domain controller to log event ID 4661: An Operation was Performed an an Object, containing the GUID of the decoy object. This Windows Event ID will be the indicator that the x500uniqueIdentifier property was queried by a user.

How to Avoid The Trap

In testing this technique I discovered that, as with any other deception technology, the trap can be avoided when taking the right precautions. In this case, a minor syntax change when querying using PowerView can avoid triggering the decoy object alert but return the same results. I began AD reconnaissance by running the following to give me a list of all domain users, their account name and when their password was last set:

Get-DomainUser | select samaccountname, pwdlastset

I let PowerView query its default properties then filtered the two properties I wanted client slide. Since PowerView's Get-DomainUser function requests the x500uniqueIdentifier, specifying the properties requested with the -Properties flag prevents the x500uniqueIdentifier property from being requested on the decoy object:

Trips decoy object:

PS C:\> Get-DomainUser | select samaccountname, pwdlastset

Does not trip decoy object:

PS C:\> Get-DomainUser -Properties samaccountname, pwdlastset

For the red teamers, these commands return the same results, but the second avoids asking a domain controller for unnecessary properties when querying for every user within a domain.

This post is a longer form adapted version of my original post on Linkedin.

Additional Resources

1. Deception Technology (Rapid7)

2. Universal Honeypot (GitHub Project)

3. Honeypot Buster (GitHub Project)

4. Awesome Honeypots (GitHub Project)