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):
Attempts per minute
Attempts per hour
hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 1 -I smb://192.168.0.5
hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -I -t 4 rdp://192.168.0.5
hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 64 -I ftp://192.168.0.5
hydra -L /home/mrr3b00t/users -P /usr/share/wordlists/rockyou.txt -t 4 -I ssh://192.168.0.5
hydra -P /usr/share/wordlists/rockyou.txt -t 1 -w 5 -s 5900 -I vnc://192.168.0.5 -v
As you can see brute force over these protocols without distributed compute, to complete rockyou.txt will take you some time.
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
- Alert/Monitoring Review testing
- Password audits
Then it is to try and brute force a large wordlist (in most scenarios).
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.
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)