Bruteforcing Windows Accounts
Published: 19 October 2020
A common configuration on Windows Active Directory accounts is to have an account lockout threshold of say, 5 invalid attempts, and an observation window of 30 minutes. This is likely due to the fact that the “Suggested Setting” after setting a threshold is to enable a short observation window. As shown:
When setting an account lockout threshold, Windows “suggests” that you set the observation window at the same time, to 30 minutes.
The observation window is often overlooked as a security risk; however it allows an attacker to perform a bruteforce attack without locking an account.
An account with a lockout threshold of 5 attempts and an observation window of 30 minutes would lock after 5 attempts within 30 minutes; but not if 4 attempts were tried continuously every 30 minutes – that’s 192 attempts per day, per account.
A quick way to validate if this issue is configured is to check the domain policy, which can be done with the net accounts comment (although this will not take into account FGPP if configured):
python3 patator.py smb_login --rate-limit 60 -t 1 user=FILE0 \
password=FILE1 0=users.txt 1=passwords.txt host=10.0.0.4 \
In the above a delay of 60 seconds has been configured with a single thread; although this can be configured however is appropriate to avoid the current observation window. The following screenshot shows an example of the output:
As always a strong recommendation is to ensure that user accounts are configured with passwords that cannot feasibly be bruteforced; however, in this case it is also advisable to disable the observation window.
Disabling the observation window will greatly reduce the number of attempts possible before an account is locked. This timer is distinct from the “Lockout Duration” which controls how long before the account is accessible again.
Posts broken down by category
Articles concentrating on network and operating system level attacks.
Articles covering attacks against web applications and their associated APIS.
Articles concentrating on past data breaches, looking for lessons learned.
Articles covering breaking into wireless networks and how to keep them safe.