Event ID 4625 & 4740

Today we are going to discuss the relationship between Account Lockout Policy, badPwdCount, badPasswordTime, Event ID 4625 and Event ID 4740 in Windows domain environment. In fact, this is one of most important topics when we engage in designing SIEM solutions.

Account Lockout Policy

First of all, we start with the Account Lockout Policy in GPO. The above Policy enforces account lockout (by setting LDAP attribute lockoutTime to CurrentTime) of a user when ALL the following conditions were met:

• The value of badPwdCount is equal to LockoutThreshold (Account lockout threshold). Actually, it is the ONLY rule!
• Continuous failure authentication occurred 3 times (LockoutThreshold) within 30 minutes (ObservationWindow).
• No successful authentication between the failure authentication because successful authentication will reset badPwdCount to 0.
• The password that contributes to failure authentication is NOT N-1 Password (Previous Password) or N-2 Password (password before previous password) if the password history is equal or greater than 2. It is because N-1 Password and N-2 Password will not increment badPwdCount.

P.S. In our observation, N-1 password will never trigger badPwdCount to increment. However, in some case, when you use N-2 Password followed by a wrong password, the badPwdCount may increased by 2.

After 30 minutes (CurrentTime – lockoutTime exceeds the LockoutDuration), PDC emulator will automatically unlock the user account and reset badPwdCount. The value of lockoutTime will reset to 0 ONLY when a successful authentication occurred, and lockoutTime will not change even failure authentication keep occurring during the lockout period. The value of lockoutTime will stay forever if no successful authentication, even the account is actually unlocked. The only exception is built-in local administrator/domain administrator with RID 500 do not follow this rule.

Event ID 4740

So, why do I still see Event ID 4740 (Account Lockout) of a built-in administrator/built-in domain administrator? The reason is built-in administrator is actually locked out, but it is unlocked immediately when a correct password is used to authenticate. In other words, account lockout duration does not affect the built-in administrator/built-in domain administrator. Therefore, we need to carefully consider monitoring password attacks against built-in administrators with a different threshold.

In addition, Event ID 4740 always logged on the domain controller with PDC emulator role. However, sometimes it also logs on other domain controllers as well as PDC emulator. The PDC emulator is actually the final owner of all domain passwords, and it contains the latest password information and account lockout status. Whenever a failure authentication occurs, other domain controllers will consult PDC emulator for the latest password and account lockout status. In this manner, the PDC emulator always knows failure authentication occurred. Microsoft also wrote a test result for other scenario such as PDC emulator is not available here. If you have an SIEM collecting security log of all domain controller, it is possible to locate PDC emulator role by counting the total number of Event ID 4740 from each domain controller.

Event ID 4625, 4771 & 4776

In a Windows domain environment, if a user inputs the wrong password to authenticate, you will see an Event ID 4625 with Status 0xc000006d and Sub-Status 0xc000006a. Moreover, you will always see Event ID 4771 (Kerberos) with Error code 0x18 OR Event ID 4776 with Error code C000006A accompanied with Event ID 4625. There is a great article here explaining the reason and where the Event ID appears. What we want to point out is that we may see different combinations:

• Only one Event ID 4625 with multiple Event ID 4776
• Only Event ID 4776 without Event ID 4625
• Workstation name is missing in Event ID 4776

For the first scenario, it is likely due to the Windows machine trying to send out ALL the known credentials belonging to the current user before prompting the user. An example for the second scenario is that the user authenticated via a Linux-based squid proxy using NTLM authentication. Event ID 4625 is supposed to be logged on the machine facing the user, which is a squid proxy in this case. Of course, the squid proxy will not log Event ID 4625. It brings out an important rule for security monitoring. Event ID 4776 seems to be low value and does not contain much information, but we cannot remove it from our picture.

Conclusion

From the above information, we may see more than 3 Event ID 4625 within 30 minutes without Event ID 4740. It is most likely due to user enter previous password. So, can we still monitoring if the account lockout policy is effective or the user applied the desired policy ? In general, we use 2 approach to handle this situation:

• Assume the user hits 3 previous password and he/she will remember he/she changed the password. In other words, increase the threshold.
• If you have a domain account, check the Account Lockout Policy using PowerShell script. We have 2 sample scripts available: check_GPO_password_policy.ps1 and GpoInheritanceBlocked.ps1. To use check_GPO_password_policy.ps1, just change the dest_nt_domain variable. GpoInheritanceBlocked.ps1 can be used to audit which GPO block inheritance.