Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The thirteenth one in the series is the “Set a honeytoken account” recommended action.
Introduction
You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.
- Resolve unsecure domain configurations
- Resolve unsecure account attributes
- Remove dormant accounts from sensitive groups
- Protect and manage local admin passwords with Microsoft LAPS
- Configure VPN integration
- Reduce lateral movement path risk to sensitive entities
- Stop clear text credentials exposure
- Disable Print spooler service on domain controllers
- Stop weak cipher usage
- Remove unsecure SID history attributes from entities
- Modify unsecure Kerberos delegations to prevent impersonation
- Install Defender for Identity Sensor on all Domain Controllers
- Set a honeytoken account
- Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
- Accounts with non-default Primary Group ID
- Change Domain Controller computer account old password
- Reversible passwords found in GPOs
- Unsafe permissions on the DnsAdmins group
- GPO assigns unprivileged identities to local groups with elevated privileges
- Remove access rights on suspicious accounts with the Admin SDHolder permission
- Remove local admins on identity assets
- Remove non-admin accounts with DCSync permissions
- GPO can be modified by unprivileged accounts
- Built-in Active Directory Guest account is enabled
- Change password for krbtgt account
- Change password of built-in domain Administrator account
- Ensure that all privileged accounts have the configuration flag
Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Set a honeytoken account.”
Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.
Honeytoken Account
Microsoft Defender for Identity monitors your on-premises environment. One of its features is setting up a honeytoken account. A honeytoken account is a dormant account that traps malicious actors attempting to use it. Microsoft Defender for Identity supports adding multiple honeytoken accounts. This blog post will describe my recommendations for setting up a honeytoken account.
Recommendations
A honeytoken account is a dormant account used as a trap for malicious actors. After setting it up as a honeytoken account, any activity associated with it triggers an alert. Since a honeytoken account usually shows no activity, use it after creation or occasionally create some activity to make it less obvious it is a honeytoken account. Here are my recommendations regarding a honeytoken account.
- Malicious actors use the object’s “adminCount” property to see if it is a privileged account. It is an easy and quick way for malicious actors to identify any object in Active Directory with high privileges. Either set the “adminCount” to 1 or add the user to a group with elevated privileges.
- When adding a honeytoken account to a highly privileged group, ensure that a malicious actor cannot take control of the account. For example, when the account is Kerberoastable, set a strong, generated password that can not be brute-forced.
- Use an old account that has never been used but shows some past activity because of the creation date. Just be sure you use an account with no active activity, or it will trigger false-positive alerts.
- If using an admin account, ensure it does not stick out. When using a honeytoken account with the name “adm-thalpius,” be sure there’s an account named “thalpius” if all other “adm” accounts have similar accounts as well.
- Use multiple accounts as a honeytoken account so the malicious actor is not limited to falling for a single trap.
- Use a service account that does not stand out from the rest and add a valid Service Principal Name. Using a Service Principal Name makes an account Kerberoastable. Kerberoasting is an attack in which authenticated users can request a Kerberos ticket encrypted with the account’s password. If a malicious actor brute-forces the ticket, the malicious actor holds the plain-text password of that account.
- Do not use only the Administrator account as a honeytoken account. Malicious actors are likelier to use low-hanging fruit like password sprays, Kerberoasting, AS-Rep roasting, etc. You want to detect a potential attack as soon as possible, and a malicious actor is probably going for something other than the Administrator account in the first place. A Domain Admin account or an account for a crown-jewel application is their end goal.
Setting a honeytoken account in Microsoft Defender for Identity is easy, but an account that is helpful as a honeytoken account can be challenging.
Conclusion
Setting up a honeytoken account is challenging, but once done correctly, it is a perfect way to set a trap for malicious actors. Since Microsoft Defender for Identity supports multiple honeytoken accounts, I recommend setting up multiple accounts to increase the risk of a malicious actor falling for it.