Detecting Password-Spraying with a Honeypot Account
Password-spraying is a popular technique which involves guessing passwords to gain control of accounts. This automated password-guessing is performed against all users and typically avoids account lockout since the logon attempts with a specific password are performed against every user. This technique is popular with penetration testers, Red Teams, and threat actors alike because it works so well. Password-spray detection typically involves correlating bad password attempts based on time. This detection method is fraught with false positives since standard users mistype and/or forget their passwords regularly. This article describes how to detect password-spraying without false positives by leveraging a honeypot account.
Password-Spraying
Password-spraying tooling works by running through a list of potential passwords and, one by one, attempting to authenticate as each user starting with the first password on this list. If successful, the tool notes this and continues. The tool may pause after completing password-spraying of each password for all users before attempting the next one. This avoids the password lockout policy since the attacker can limit the number of bad password attempts over time.
Password-Spraying Approach:
- Attempt authentication for user #1 using password #1
- Attempt authentication for user #2 using password #1
- Continue until attempted authentication has been performed using password #1 for all targeted users
- Pause for a few minutes to avoid account lockout
- Attempt authentication for user #1 using password #2
- Attempt authentication for user #2 using password #2
- Continue until attempted authentication has been performed using password #2 for all targeted users
- Pause for a few minutes to avoid account lockout
Pausing after each password attempt iteration enables the attacker to avoid the standard lockout rules. In the following figure is an example of a domain password policy which has a lockout threshold of 5 and a lockout observation window of 20 minutes. This means that if there are 5 bad password attempts for a specific user within 20 minutes, the account will be locked out and cannot authenticate until the lockout duration is met (20 minutes) or the account is manually unlocked. Ensuring that the password-spraying tool performs less than 5 bad password attempts in 20 minutes avoids locking out any specific user.
This approach continues until the attacker meets their goal (Ex. Guessing the password for a select group of users like administrator accounts) or the password-spraying has gone through the entire password list.
Password-Spraying Detection (The Old Way)
Password spraying a small environment may be detected by looking at the Windows Security log and noticing all the 4625 events.
The challenge here is that the attacker may set “jitter” on the password-spray where 3 attempted logons happen in the same minute, but the next one takes 5 minutes or more. This enables the attacker to blend in with the environment more effectively.
A similar approach, which I have published about previously, is looking at last bad password attempt and/or bad password count (lastbadpasswordattempt & badpwdcount). Note that these attributes are not replicated, so they need to be captured from all domain controllers in the domain and correlated. This may not be practical in environments with numerous domain controllers. Badpwdcount is reset when the correct password is provided during authentication.
get-aduser -filter * -prop lastbadpasswordattempt,badpwdcount | select name,lastbadpasswordattempt,badpwdcount | sort lastbadpasswordattempt | format-table -auto
Configuring Auditing on Domain Controllers to Detect Password-Spraying
I wrote a short PowerShell script to get the results I wanted in the domain controller’s event log. I wanted to be able to toggle the script between NTLM and Kerberos authentication since there are different event IDs logged depending on the authentication. For example, the event ID 4625 is the standard “bad password” event, and other technical articles will note that logging 4625 is what’s necessary for detecting things like password-spraying.
The issue is when Kerberos authentication is used for password-spraying event ID 4625 may not be logged. The event ID 4771 needs to be configured for logging to detect password-spraying using Kerberos authentication. 4771 states, “Kerberos pre-authentication failed” and when we decode the failure code of “0x18”, we find that this represents a bad password attempt. I wrote about this back in 2017 in my article “Detecting Password Spraying with Security Event Auditing”.
In order for the domain controller(s) to log these events, appropriate auditing needs to be configured.
Successful logon events are event IDs 4624, 4768, and 4769.
- 4624 (Success): Audit Logon
- 4768 (Success): Audit Kerberos Authentication Service
- 4769 (Success): Audit Kerberos Service Ticket Operations
Failed logon events are event IDs 4625 and 4771.
Ensure that these event IDs flow into the SIEM and alerting is configured for any activity related to the honeypot account(s).
To configure logging, either create a new Group Policy Object (GPO) or use an existing one linked to the Domain Controllers container. Go to Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, Audit Policy. Then click on Account Logon and configure Audit Kerberos Authentication Service with Success and Failure. Optionally, configure Audit Kerberos Service Ticket Operations with Success. Click on Logon/Logoff and configure Audit Logon with Success and Failure.
The following screenshots show the auditing configuration required to detect password -praying using both NTLM & Kerberos authentication.
Creating a Honeypot Account to Detect Password-Spraying
We could simply utilize a previously configured honeypot account, but I prefer to use each honeypot account for specific purposes, so here we create our account for detecting password-spraying. This approach enables specific Standard Operating Procedures (SOPs) to be created and referenced for each honeypot account separately. When creating a honeypot account to detect Kerberoasting, the account is configured to look like a service account. Here, we create an account to look like a standard user account. The best way to do this is following the guidance in the article “The Art of the Honeypot” to ensure that the account looks like the other user accounts.
The best option is to reuse an old user account, remove group membership that provides access to data locations, and rename it. Leveraging an existing account provides things like total logons and other metrics that are hard to fake. The account should be in an OU structure like where other user accounts are located. I would also logon with the honeypot account so it does have a recent interactive logon. In this example, I use the name “Joe Fox” and have filled out some of the standard fields with some information that should be similar to what other users have set on their accounts. I recommend creating a honeypot account for each domain in the AD forest. You could use variations of the first name with the same last name: Joe Fox, Samantha Fox, Ed Fox, etc.
We can use a bad password like “Password1234” so an attacker can successfully authenticate with this account, or we can use a long, complex password to ensure that the password is never successfully discovered.
The simplest way to use a long complex password is to open the honeypot account, switch to the Account tab, and scroll down in the Account options to Smart card is required for interactive logon and check the box next to it. Click Apply and then uncheck the box and click Ok. The password for this account is now scrambled and unguessable.
Password-Spray Honeypot Detection - Successful logon
We can see in the following screenshots that the honeypot account “Joe Fox” has successfully logged on. Since this is a honeypot account, there should never be successful logon activity associated with this account.
Event ID 4624 - An Account was Successfully Logged On
This event shows the network logon for the account as well as the source IP address for the authentication. It also provides the network address from where the account authenticated.
4768 - A Kerberos authentication ticket (TGT) was Requested
This event shows the authentication for the account. It also provides the network address from where the account authenticated.
4769 - A Kerberos Service Ticket was Requested
This event shows the authentication for the account, specifically the service ticket was requested. It also provides the network address from where the account authenticated.
Password-Spray Honeypot Detection - Failed logon
We can see in the following screenshots that the honeypot account “Joe Fox” has had bad password attempts. Since this is a honeypot account, there should never be logon activity associated with this account.
Every time password-spraying guesses a wrong password, we may see either 4265, 4771, or potentially both events logged depending on the authentication method, the domain controller configuration, etc.
Event 4625 - An Account Failed to Log On
The event shows this a network logon for the user was attempted but failed due to a bad password. The source workstation name and IP address are noted in the event as well.
Event 4771 - Kerberos Pre-Authentication Failed
The event shows this a network logon for the user was attempted but failed due to a bad password (failure code 0x18). It also provides the network address from where the account authenticated.
Conclusion
Using the guidance in this article, password-spray activity can be easily detected by creating a honeypot account and configuring monitoring for logon activity associated with this account. This approach provides a simple methodology to configure the environment to detect password spray activity.