The Defender Dilemma paradigm in IT-Security is well known to everybody. It states that breaches are inevitable because defenders must be right 100% of the time, whereby attackers only have to be right once. This negative perspective is not empowering to build a creative Defenders mindset. In this article, we flip the focus to the attacker’s dilemma by utilising one defensive technique called Honeytokens. They can help to increase the dilemma of an attacker to stay undetected in your IT-Environment

An attacker enters the playing field of a defender as soon as a compromise usually of an endpoint has taken place. From now on, an attacker has different ways to explore the defenders playing field, imaginable as in the game Minesweeper, which probably only the older generation among you knows.

The task as a defender is to detect and block the attackers as quickly as possible before they can access critical data. To achieve this, defenders usually use a variety of security tools these days, which, among other functionality, collect logs from the endpoints. However, based on our red teams, we can say that although our actions were occasionally recorded, they mainly got lost in the noise. What could be the reason? One reason could be that we as Defenders tend to be not creative enough. We work through lists to make our systems safer but pay too little attention to the playing field of an attacker. Or quoting John Lambert (2015):

Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.

So how can we make the playing field more difficult for attackers? As a first step, attackers usually try to collect additional information about the IT environment. This action occurs either on the endpoint or over the network to services such as Active Directory, File servers, or other IT systems. One effective way to detect this attempt can be to utilise Honeytokens. To do this, we set out traps on our playing field, imaginable like the mines in Minesweeper.

It is essential to think like an attacker when placing Honeytokens, with the aim to provoke an early alert by an attackers actions. When triggered, it is up to the defender to react as quickly as possible to identify the involved entities and drive the attackers off the playing field.

Honeytokens are available in different variations. The following chapter describes one example by using an Active Directory Honeytoken.

Honeytoken Idea for Active Directory

Active Directory is ideal for attackers to gather information about the IT environment. Comparable to Google Maps, we search for a good restaurant or attractions, attackers look for a simple path in Active Directory to get to privileged objects. Various tools can be used to query information from Active Directory, such as dsquery.exe, dsa.msc, SharpHound, ADExplorer, PowerView and many more which we will not describe further in this article. We are more interested in the query itself. To query Active Directoy, LDAP or LDAPS is used. We could record the LDAP request, or more straightforward, we can record the property requests on domain controllers with the help of System Access Control Lists (SACL). SACL’s are generally underused compared to Discretionary Access Control List (DACL). Unlike a DACL that controls access to an object via SIDs, SACL allows access to an object’s audit ACE. An audit ACE describes whether particular actions on an object was successful or not. A recommended article for profound research on the subject of ACL’s is the An ACE Up the Sleeve document published by the company SpecterOps.

From the two existing SACL categories, Object Read and Object Write, we will only use the Object Read category to record Active Directory property access. The procedure to create a Honeytoken account and assign the correct SACLs is as follows:

1. As a first step, we create a new user in Active Directory with a complex password. The naming convention should be based on existing objects to avoid that an attacker can quickly identify the account as a Honeytoken. Also, it may be beneficial to consider what kind of name or prefix an attacker would search first in an Active Directory such as adm*, admin* or svc*
   
2. Now we should login with the created account multiple times over the next few days. The logon will populate the LastLogon attributes in Active Directory. Attackers may try to discover Honeytoken accounts by filtering out accounts that never logged in or have the password set on the same day as the LastLogon attributes
3. In a next step, we add a new SACL to the Honeytoken account via the Security Tab -> Advanced -> Auditing:
   • Principal: Everyone
   • Applies to: The object only
   • Permissions: Read all properties
     
4. In order for the domain controllers to generate an event from our SACL settings, we need to configure the Advanced Audit Policy as follows:
   • DS Access – Audit Directory Service Access: Success (At least Success)
   • Preferably, this setting is made via GPOs and must be applied to all domain controllers
     
5. Now, we can test our Honeytoken by running an LDAP query against the created Honeytoken. In our example, we used dsquery.exe and SharpHound.exe
   • Query with dsquery.exe for all AD user accounts that start with adm
     
   • The query generated two security log entries on the domain controller with the event ID: 4662
     
   • The query with SharpHound generates four entries with our Read All Properties SACL configuration, because multiple properties from the Honeytoken account are queried
     
6. As a last step, an alert must be triggered when event 4462 is created. Either with a SIEM solution or by attaching an action to the event

With the above Honeytoken, you should from now on be able to spot attackers when they read out the entire Active Directory or, in our example, search specifically for adm* accounts. However, it should be noted that false positives can occur if the Honeytoken account was created in an OU where legitimate administrators often run queries or by 3rd party applications such as an identity management system. Alert exceptions may therefore be necessary to avoid false positives.

More Honeytoken Ideas for SACLs

In Windows, there are a variety of Securable Objects such as:

• Network Shares
• Registry Keys
• Files and directories on the NTFS file system
• Printers
• Processes
• Active Directory objects

SACLs can be set on all these objects. Files are ideal for Honeytokens and generate, like in the example above, the same event if visited. As a start for the file names, you can orient yourself on the PowerView function Find-InterestingDomainShareFile, which by default searches for file names such as pass, sensitive, secret, admin, login or unattend*. xml.

More Honeytoken Ideas

Numerous websites describe different types of Honeytoken implementation. Following are some links to tap into an endless well of Honeytoken creativity:

• Canary Tokens or Canary Tools offer an automated way to deploy Honeytokens to simulate network services. When attackers scan the network for interesting services such as file servers or web services, an alert will be triggered
• Microsoft describes how to create an Azure Key Vault Honeytoken by triggering an alert when an attacker tries to read out key material
• Rene Feingruber describes in his blog post different types of Honeytokens. Especially creative are the Honeytoken ideas regarding BloodHound, PowerView and Responder tools which attackers often use
• Nikhil Mittal describes in his blog post how attackers could identify Honeytokens. Remember, for creating effective honeypots, you should think like an attacker. So what would you see as deception and ignore to pursue?
• Sean Metcalf is going more in detail about how to create a normal-looking Honeytoken account in Active Directory

Conclusion

Creating effective traps in your IT environment requires both an attacker’s mindset and creativity. As we learned, Honeytokens can be designed for nearly every scenario and can give you the chance to tip off an attacker in the early stage of an attack. This initial signal can help you identify and stop an attack more quickly. You should create several Honeytokens in your environment by layering them according to the attack stages of an attacker. Important to say is that Honeytoken should not endanger your environment. Therefore, we are not recommending assigning privileged access rights to Honeytokens. As with everything in IT, test your Honeytokens if they are working as expected. At last, you should not only rely on Honeytokens. However, it is an effective technique that a defender can use to increase the attackers dilemma.

About the Author

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• http://www.labofapenetrationtester.com/2018/10/deploy-deception.html
• https://apt29a.blogspot.com/2019/11/deploying-honeytokens-in-active.html
• https://bloodhound.readthedocs.io/en/latest/data-collection/sharphound.html
• https://canary.tools
• https://canarytokens.org
• https://docs.microsoft.com/en-us/azure/sentinel/monitor-key-vault-_Honeytokens_?tabs=deploy-at-scale
• https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer
• https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon
• https://www.hub.trimarcsecurity.com/post/the-art-of-the-honeypot-account-making-the-unusual-look-normal
• https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf