How long should you test brute force password attempts for?

Well, a recent Microsoft report showed the average RDP brute force attack over the internet lasted about 3 days. Now let’s take a look at what a single attacker machine (IP) can send to a single target server over a well-connected network (1GBE low latency):

Protocol	Tasks	Attempts per minute	Attempts per hour	Command Used	Rockyou	Time (hours)	Days
smb	1	530	31800	hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 1 -I smb://192.168.0.5	14344392	451.0815094	18.79506
RDP	4	1114	66840	hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -I -t 4 rdp://192.168.0.5	14344392	214.6078995	8.941996
ftp	64	11935	716100	hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 64 -I ftp://192.168.0.5	14344392	20.03126938	0.834636
ssh	4	44	2640	hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 4 -I ssh://192.168.0.5	14344392	5433.481818	226.3951
VNC	1	12	720	hydra -P /usr/share/wordlists/rockyou.txt -t 1 -w 5 -s 5900 -I vnc://192.168.0.5 -v	14344392	19922.76667	830.1153
WINRM	5	1600	96000	use auxiliary/scanner/winrm/winrm_login	14344392	149.42075	6.225865

As you can see brute force over these protocols without distributed compute, to complete rockyou.txt will take you some time.

Testing Method

Ok so what I would generally do is use a white box approach. I would also look at control on/off testing with regards to account lockouts etc. Also, I’d want to see the logs and the alerts (or lack of!).

Now if I was in a constrained black box scenario that makes it a bit tricker because there might be a don’t cause loss of availability principle in the rules of engagement.

So firstly, agree with the customer before you start sending millions of attempts. Then you need to work out a strategy depending upon service type and position and perspective.

One must also not to forget, consider these other authentication vectors:

• Default passwords
• Password spraying
• Credential stuffing

But back to the brute, so if you are going to test this (and I’d say you should do some level of brute force attacking during penetration testing where appropriate) you want to set a timebox for it.

For FTP I’d say hit it for a day. For WINRM I’d also say hit it for up to a day (if white box methods are not available). Remember this needs to be realistic in terms of operating within constraints. It also depends on how many exposed FTP and WINRM servers are in scope and how many identity planes there are (this is why it’s important to know the network from a defender perspective!)

For the other protocols I’d say hit each for an hour each, you won’t be making much of a dent even if you extended that for a day, and if you don’t get alerted on.

Now that’s from an internal perspective. If you look at exposed internet services, I’d honestly want to discuss each one, and ideally look at them from a Whitebox perspective, if there are gaps and weaknesses then it’s must faster and efficient to do:

• Configuration audits
• Control on/off testing
• Simulations
• Alert/Monitoring Review testing
• Password audits

Then it is to try and brute force a large wordlist (in most scenarios).

Avoiding DoS

The impact on IO is low, a winrm brute force run using metasploit adds ~.5Mb of traffic to the connection.

A single brute force with 64 tasks on FTP produced the following when using hydra.

Summary

So BRUTE FORCE, it’s a real vector, it’s used over the internet 24/7, you also will find both tool based but more likely human based password guessing occurring inside a network, so as I said, I’d take a balanced approach to testing and ideally use white box and other methods with a demo of how the controls prevent and detect the activity (or not)