Categories
Infrastructure

The Myth of Account Lockout: Observation Windows

During Penetration Tests I often gain access to a selection of domain user accounts on my path to compromising a domain admin account. This is often a requirement these days for enumerating domain policy and also it’s quite common to find standard user accounts that have access to interesting information, such as HR or Finance accounts with access to staff and payroll information or a user with VPN access. During the post-engagement meeting with clients they’re often shocked at how I could launch online brute-force attacks against accounts without locking them out.

I believe this comes about due to a misconception of default Windows Settings. On my test domain controller I set up my account lockout threshold to be 5 invalid logon attempts and this prompted my domain controller to suggest the following additional security changes:

Here you can see the suggested defaults along with my 5 invalid logon attempts is the set up the observation window to 30 minutes and lockout duration to 30 minutes. This effectively alters my initial change from “lockout after 5 invalid attempts” to “lockout if 5 invalid attempts are observed within 30 minutes”, meaning that an attacker can simply try four attempts, every 30 minutes, per account – for this set up that’s 192 password attempts per day.

Additionally, if your domain is one of any scale and you have several thousand accounts then it may take several minutes for an attacker to make their way through the list with each password attempt, meaning that if it takes longer than the observation window to make it all the way through the list then the lockout policy offers no delay. This attack can of course be automated, either by a manual attacker scripting the process or through malicious software abusing the setting to compromise more accounts.

EDIT: A colleague reminded me that in Windows 2008 Domains it’s now possible to configure fine-grained lockout policies. This means that lockout policies can be applied at an Organisation Unit level within an Active Directory Domain. This can complicate things for attackers if, for example, most domain users are set to have a loose lockout policy but key accounts such as domain administrators are set much more stringently. This could leave to an attacker accidentally lockout these accounts resulting in the possible detection of the attack. Microsoft has information posted more information about fine-grained control here: https://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx 

Defenders

For those in charge of Windows Active Directory Domains you should take a look at your observation window setting, found under domain security policy and determine if the protection that your lockout policy offers is really as strong as was intended. Additionally think about how an attacker could abuse this window to prevent an account lockout, the worst case scenario would be a piece of malware running a continuous online bruteforce managing several hundred password attempts per day, would you be able to detect that attack if it were under way?

Lockout settings can be found under domain security policy, here’s a screenshot to make finding the setting a touch easier:

Remember that there’s a lockout policy and observation window setting for both domain accounts and for local computer accounts, both of which should be configured securely. There’s also a Microsoft post on configuring these options here.

Breakers

Security Assessors who are looking at testing the effectiveness of lockout policies should determine the lockout policy of the domain. With an initial valid account this can be achieved through the following commands:

net accounts
net accounts /domain

However running the top command for gaining the local account lock out policy should be ran against every machine on the network and that sounds much too manual for my liking, so as an alternative there’s a tool available that can look for common security misconfiguration such as missing local account lockout policy across an entire network range. It’s called ShareCheck and it’s available here.

Once the threshold and observation window have been noted you can launch a bruteforce against the domain and delay the attack such that it will not exceed the observation window.