When it comes to IT security, I am a subscriber to a couple of “bear” paradigms (admittedly, the second one is a little morbid):
- If the bear is hungry, it will eat - in other words, if a person or entity wants something from your environment badly enough, chances are they will eventually get it (think Stuxnet).
- You do not have to outrun the bear, only your slowest friend - in other words, incremental improvements in security practice can reduce the impact of attacks against your environment and make your organization a less appealing target.
In the spirit of this, I wanted to share some potentially useful information about curbing Active Directory brute force, denial of service (DoS), and/or AD account lockout attacks (event code 4740) against internet facing systems that authenticate against internal Active Directory Domain Services. Although it is possible that an AD account password would eventually be discovered this way, that is less of a concern in my opinion. The real annoyance is that when an AD account becomes locked in this manner, it impacts the actual user who may be legitimately attempting to login and perform work. When an attacker locks a user’s account, the user must wait until the interval you specify for “Reset account lockout counter after” in AD elapses before she/he can resume work.
This sort of attack is most effective when the following criteria are met:
Your organization operates internet facing services that authenticate directly against Active Directory (not ADFS) - these could be Remote Desktop Services/Remote Desktop Protocol (RDS / RDP), CIFS/SMB (File Sharing), Internet Information Services (IIS - websites or web applications), simple mail transfer protocol (SMTP) relay, etc.
AD user names in your organization are known in the “wild” - this may be a result of a previous breach/compromise (one of the first steps most attackers take when an account is compromised is dumping your organization’s directory/GAL/etc.) or simply because some AD usernames are easy to guess (i.e. “bob”).
Additionally, I once worked for a multination corporation (many global aquisitions) where I fondly recall the CISO stating that our internal network was more dangerous than the internet; I did not entirely understand his reasoning at the time but I have come to realize what he meant (emphasis on perimeter security instead of internal or East/West security, explicit trust between internal networks, differing security practices and policies between offices in different nations, etc.). In any case, the following guidance may benefit you if your organization has similar challenges.
In this post, I will cover 2 potential solutions that help reduce the impact of these types of attack. They are IPBan and EZWinBan. Both solutions run on Windows and leverage the Windows Event Log (to identify IP addresses with authentication failures) and Windows Firewall (to ban IP addresses that are responsible for excessive failed AD login attempts). I will also share some tips on properly tuning these solutions to maximize their effectiveness.
Visualization of AD lockout attack WITHOUT IP banning
A picture is worth 1000 words (in this case, maybe more like 100 words since my diagrams are a little rough!).
This graphic shows an example (24 minute) timeline of an AD account lockout attack WITHOUT an IP banning solution implemented. In this sample environment, there are 2 public facing servers (server 1 and server 2) that provide a service that authenticates against AD. Active Directory account lockout settings are configured as shown. An attacker purposefully logins into server 1 and server 2 with the correct username but an incorrect password, resulting in authentication failures (usually Event ID 4625 on the client and Event ID 4771, result code 0x18 on a domain controller); once the number of authentication failures defined by the “Account lockout threshold” setting in AD are reached, the account is locked (Event ID 4740) for the period of time defined by the “Account lockout duration” setting (AD).
The areas of concern are the light blue “AD lockout” (Event ID 4740) events and the light orange “Auth fail: locked out” (usually Event ID 4771, result code 0x12) login attempts. During those intervals, the real user would be locked out and perform work. If the attack is continuous, this can result in hours of lost work since the legitimate user in unable to login.
Visualization of AD lockout attack WITH properly tuned IP banning
This graphic shows an example (24 minute) timeline of an AD account lockout attack WITH a properly tuned IP banning solution implemented. In this sample environment, there are 2 public facing servers (server 1 and server 2) that provide a service that authenticates against AD. Active Directory account lockout settings and IP banning settings are configured as shown. An attacker purposefully logins into server 1 and server 2 with the correct username but an incorrect password, resulting in authentication failures (usually Event ID 4625 on the client and Event ID 4771, result code 0x18 on a domain controller); once the number of authentication failures defined in the IP banning solution are reached, the attacker’s IP address is blocked (preventing further authentication failures) for the period of time defined in the IP banning solution. There are a few best practices regarding these settings which I will cover below.
As you can see, the light blue “AD lockout” (Event ID 4740) events and the light orange “Auth fail: locked out” (usually Event ID 4771, result code 0x12) login attempts are eliminated. The malicious IP addresses are banned before they lockout the account in AD and remain banned until the “Reset account lockout counter after” timer resets. As long as the legitimate user logins in with the proper credentials, she/he will never be locked out and the attacker remains banned just long enough to make this possible.
Determining and setting the proper value for failed login attempts before ban
This setting is named as follows in each of the banning solutions:
With a single public facing server, setting this value is cut and dry. It simply needs to be less than (NOT equal to) the “Account lockout threshold” setting in Active Directory (AD).
If multiple publicly accessible servers authenticate against AD, login attempts from ALL of the nodes must be taken into account (they all count against the Account lockout threshold in Active Directory). The goal is to ensure that the malicious IP address is banned on all nodes before the lockout threshold in AD is reached.
(Failed login attempts before ban) < (Account lockout threshold in AD) / (Number of public facing servers)
The Failed login attempts before ban) setting on each node should be a whole number (usually rounded down) less than the Account lockout threshold in AD divided by the number of public facing severs authenticating against AD.
|Count of public facing servers||Account lockout threshold setting (AD)||Recommended failed login attempts before ban|
|2||3||1 (Since 3⁄2=1.5, round down to 1 - we cannot have fractional login failures)|
|2||5||2 (Since 5⁄2=2.5, round down to 2 - we cannot have fractional login failures)|
|2||10||4 (Although 10⁄2 is an even 5, the value must be LESS THAN 5, so we round down to 4)|
|3||15||4 (Although 15⁄3 is an even 5, the value must be LESS THAN 5, so we round down to 4)|
|4||5||1 (Since 5⁄4=1.25, round down to 1 - we cannot have fractional login failures)|
|4||10||2 (Since 10⁄4=2.5, round down to 2 - we cannot have fractional login failures)|
|5||10||1 (Although 10⁄5 is an even 2, the value must be LESS THAN 2, so we round down to 1)|
|7||15||2 (Since 15⁄7=2.14, round down to 2 - we cannot have fractional login failures)|
|10||5||NA (No feasible value in this situation. Reduce # of public servers or increase Account lockout threshold)|
|25||15||NA (No feasible value in this situation. Reduce # of public servers or increase Account lockout threshold)|
Determining and setting the proper value for ban time
This setting is named as follows in each of the banning solutions:
My knee jerk reaction is generally to the effect of “ban them forever”. That is counterproductive though; these attacks may originate from behind a NAT or from an unknowingly compromised host. If ban time is set too high, you may end up banning legitimate traffic and if the ban duration is weeks/months/years, legitimate users may also be unable to access your services for a long time. In addition, you can easily clog up your firewall with thousands and thousands of rules if you hold onto banned IPs for too long. Although the Windows Firewall is relatively efficient, I am sure there is a slight increase in load (memory/CPU) as the number (and size/scope) of the ruleset grows.
With that in mind, you only need to outrun your slowest friend; as a starting point, I recommend setting your ban time based on your “Reset account lockout counter after” setting in Active Directory (AD). In brief, just enough to allow the lockout counter to reset.
(Ban time) >= (Reset account lockout counter after in AD)
Ban time should be greater than or equal to the time specified in the Reset account lockout counter after in AD.
|Reset account lockout counter after (AD)||Recommended ban time|
|5 minutes||5 minutes (or more)|
|15 minutes||15 minutes (or more)|
|30 minutes||30 minutes (or more)|
|60 minutes||60 minutes (or more)|
Implementing an IP banning solution should help alleviate the impact of AD account lockout attacks in your environment. There are always caveats though; even with a perfectly tuned solution, it is impossible to completely prevent lockouts of this nature. The attacker may vary IP addresses between login attempts with the same username, there are delays in processing failed login attempts (Event Viewer) by both IP banning solutions (seconds matter), etc.
In an ideal world, systems and services that authenticate against Active Directory should not be publicly exposed (there are other solutions for these cases, like Active Directory Federation Services (ADFS) and other SAML/OATH based identity providers (IdPs). But alas, we do not live in a perfect world and I can envision many scenarios were public facing AD authentication is a necessary evil.
In any case, I hope this helps someone facing Active Directory account lockout issues and looking for solution(s) / tuning guidance to address them. If you are doing something similar or have additional guidance, feel free to comment. I am always interested to hear about innovative methods that others have used to tackle problems like this.