Honeytokens are a great tool for defenders to augment their security posture with traps hidden within their digital environments. Similar to honeypots, Honeytokens are decoy accounts set up purely to lure attackers and divert their attention away from actual targets. Where honeypots are interactive and responsive systems pretending to be applications or services running on vulnerable servers on the network, honeytokens form a more granular item within in a database, file share, hsm key vault, or identity systems. These fake entities provide security teams a mechanism to better detect, deflect, or study attempted attacks.
Microsoft Defender for Identity offers an easy-to-use capability that tags identities on local active directory domains and generates an alert once that user/identity is authenticated on the domain. Using these Honeytoken tags on enticing identities throughout your enterprise can act as trip wiring that will alert your Security Operations (SOC) teams of a potential threat. In this blog we will discuss some best practices for Honeytokens within local Active Directory identities to help you think through what accounts to use and where.
What type of identities make the best honeytokens ?
User Accounts:
If possible, re-use an existing account with attributes that would be enticing to a potential attacker. When using this method its also often good to rename the account to make it stand out even more. Why are existing users preferred to creating new ones? In short, history. Things like log-in history, group memberships (but be careful to not expose data via group membership privileges) and other existing metadata around that identity can help obfuscates the fact that this is a honeytoken and better trick would-be attackers. One of the easiest ways to leverage an existing user is to utilize accounts for employees leaving your company. In these instances, its often best to reset the password and disable them for some time but not completely delete them. As discussed earlier, renaming these accounts may also be appropriate. Other key things to consider for the accounts you choose:
- When evaluating and using privileged accounts be extra cautious. Be sure the account has strong complex passwords and the breakout path of privileges is limited to a few machines for login.
- Suggestions for account names: Backup Administrator, admin, adm, oracle, ftp, puppet, ansible, ec2-user, vagrant, azureuser, leverage SecLists on GitHub as well for further inspiration.
- Be conscious of how account placement will impact the names you use, for instance if you have SAP environment and want to place tokens there using existing accounts, check out the SAP default usernames SecLists on GitHub for some inspiration.
- If you do create a new user be sure to generate some logins and artifact changes overtime on the account, change group memberships, maybe after a few months the manager, or some other data, develop a bit of a persona (developer, it admin, project manager) on the new account as to where you might place it.
Service Accounts:
Service accounts that are no longer in use are also a good option to use as a honeytokens. In this instance its crucial however that you make sure their privileges are removed. Adding an SPN (service principal names) to an account may entice the attacker to attempt Kerberos the account which should also trigger an alert from Defender for Identity. As an example, around a SQL server environment, you could create a SPN for SQL (again be sure to remove privileges to server\database). One other great option is to put them in fake groups called something like sec.right.AllServerAdmins. This will make them appear to have broader admin access.
Where should you place Honeytokens?
Just as important as the type of account you use and the meta data surrounding it, is how visible your Honeytokens are to attackers that may have penetrated initial access controls and begun to do internal discovery. Below are a list of techniques that you may want to leverage to ensure these fake accounts are easily uncovered by common attack strategies.
One way to plant breadcrumbs leading to these accounts is to place the account and password in a Domain Admin Passwords.xslx on a discoverable \\fileserver\fileshare. When using this method be sure again to use an existing .xslx with an older creation date versus creating a new one. Tools like Mockaroo can help you to quickly mockup data as well to put into the file.
The above concept allows discovery in cleartext, some other examples of location of file/data might be.
- SharePoint Site (file listed as passwords)
- Code Repositories
- Mapped Drives
- Local documents
You can also leverage other techniques, for example placing the account in a PowerShell script, and attaching the script locally or in a \\fileserver\fileshare to use as a scheduled task. This will provide log in history and may also lend some credence and enticement to the attacker. If you choose to use this method, be sure to exclude or auto dismiss this pattern from any alerts or monitoring and notify the security operations team so they are aware of the scripted pattern.
While placing the account in a file or script, you can generate logon history by leveraging weaker protocols or channels and using it in a nearby office printer. In this scenario you could exclude the known pattern from the printers IP (Internet Protocol) to the login server but if any other activity or usage elsewhere the pattern becomes different and actionable.
Attackers also often dump LSA (Microsoft Windows Local Security Authority) Secrets from a Windows Server. You can generate a dummy token by using a real user but a fake password. To generate:
Sc create BackupSvc binpath=” C:\Program Files\Symantec\Backup\backupsvc.exe” obj=’’symadmin@<localdomain>’ password=” _yJLN5cn32(n”
Services like Tanium package could also be used to push this token throughout parts of your network on targeted servers. Seeing this in multiple places not only spreads the trip wire but also lends credence and enticement to the viability of this credential.
In addition, sending Windows Security event 4625 to your SIEM (Security Incident and Event Management) like Microsoft Sentinel and writing a detection for this specific account or utilizing watchlists can create additional tripwires and alerts.
Attackers may also target LSASS (Local Security Authority Subsystem Service) where hashes of passwords are stored in the system memory. A simple method to seed the honeytoken credentials in memory is:
Runas /<userlocaldomain>\<honeytokenusername> /netonly cmd.exe
To keep the seed persisting in memory and not tied to a process use EmpireProject’s New-HoneyHash.ps1
The script can be run like:
New-HoneyHash.ps1 -Domain <localdomain> -Username <honeytokenusername> -Password <honeytokenpassword>
Powershell -windowstyle hidden -noexit -file C:\New-HoneyHash.ps1
The script could be deployed as a package in Tanium, as part of a login script or scheduled task. Place these in common foothold areas in your network, DMZ (Data Management Zone) Servers and also workstations.
For even more coverage you might consider building detections for these credentials outside of Defender for Identity with Microsoft Sentinel, by monitoring and collecting logs from VPN (virtual private networks) Services, Internal Web Applications, or third-party tools for cross correlation.
Operational Use of Honey Credentials
Beyond the use cases to detect threats mentioned above, Honeytokens can also serve as a great way to monitor in-progress attacks. For instance, you can leverage a unique set of Honeytoken credentials that are purposefully not left anywhere or have any permissions but are passed directly to an attacker when encountering password focused phishing attempts. Most times these attempts are external; however, if the attacker is internal to the systems, this is a great way to discover where they are coming from and tag ongoing phishing activity to other compromises you are tracking.
In a similar way tagging credentials or accounts as soon as they are flagged as exploited by the SOC with the honeytoken tag allows you to capture and monitor further instances of where the attacker may be positioned in the network and infrastructure.
Responding to Honeytoken activity:
With release 2.198 (February 2023) of Defender for Identity Honeytoken alerts are now split into separate categories to differentiate the type of authentication used. They are:
| Alert Name |
|
Honeytoken user was queried via LDAP |
|
Honeytoken user authentication activity |
| Honeytoken user had attributes modified |
| Honeytoken group membership changed |
Upon tripping the account, you may receive an alert in Microsoft 365 Defender, follow the guidance here and determine if the alert is Benign True Positive application owner or legitimate process or in the course of the investigation there is malicious activity occurring due to account discovery with the honeytoken account. Exclusions by detection rule are also supported. You can leverage an exclusion on an alert name above if needed based on certain entities like users, devices, and IP Addresses.
Conclusion
Honeytoken tagging can be a fantastic way to leverage Microsoft Defender for Identities insights into authentication to further help you defend your enterprise. There are different methods of placing and creating enticing honeytokens, start to test and modify to reduce benign false positive alerts. Finally leverage Honeytoken tagging feature in creative ways in your operation practices.
If you want to learn more about honey tokens in general or further advanced identity-based tokens specifically to broadcasting credentials via LLMNR (Link Local Multicast Name Resolution) check out Chris Sanders Intrusion Detection Honeypots. An excellent read to get started and a dedicated chapter 8 for identity-based tokens.
Most Honeytokens are used in domain account credential access and discovery phases. Further study the MITRE Attack Framework for insights of what and where for honey token credentials.
Additionally, Honey Tokens you can checkout using Microsoft Sentinel:
What’s new: Microsoft Sentinel Deception Solution
Ingest-CanaryToken Playbook and Detection
Specially Thanks to:
Gershon Levitz, Angelo Palma for reviewing and editing
Chris Sanders book Intrusion Detection Honeypots
Matt Zorich from operation experience using MDI and Honeytoken Tags
Victor Zapata for testing scenarios in local AD (Azure Active Directory) environment and MDI
