Suggestion.

[Bifrozt]

Really liked your PytheM project, especially the modules/ssh_bruter.py as it was more or less something like that i was about to build myself :)

I did a few changes to the module/ssh_bruter.py that might be interesting to you: https://raw.githubusercontent.com/Bifrozt/PytheM/master/modules/ssh_bruter.py

Didn't do a pull request since its only minor changes, let me know if you rather have it as a pull request.

[m4n3dw0lf]

I really appreciate your interest in the project , especially the patience to comment and improve the code , please send me how many pull requests you want, and lets work together.

only commenting on the improvements , I think we could add a status bar with the percentage of attempts instead of printing each try and use threading like you said.

[Bifrozt]

Glad you appreciated the improvements Pull request has been sent.

add a status bar with the percentage of attempts instead

Sounds like a good idea or maybe some kind of counter? Also, looking at existing tools like JTR and Hydra, it might make sense to add the possibility to resume an interrupted brute force attack from where it left off.

As i understand it, the current module/ssh_brute.py supports attacking one user account on one host machine. This activity would be detected fairly quickly during an engagement if a IDS is deployed on the network. Using threading would possibly trigger the IDS quicker.

Brute force will always be noisy but, it might be possible to delay it by changing the attack pattern and spreading the attack over multiple user accounts and multiple targets plus, adding a grace period.

Example: IDS is triggered after 5 failed attempts per user account within 5 minutes. We are attacking 5 targets, 10.1.1.100 - 10.1.1.1.4 On each target there are 5 accounts, user{0-4}, we want to brute force.

Attacking each user account individually on each target would trigger the IDS at the fifth failed password. Using paramiko to brute force SSH accounts takes (very) roughly 3 seconds per attempt.

With this in mind, not triggering the IDS would requires less than 5 failed logins per user account within the 300 second time frame, on any of the five accounts on any of the five targets.

Attack pattern

• target 1: (4 attempts * 5 accounts) * 3 sec/attempt = 60 seconds
• target 2: (4 attempts * 5 accounts) * 3 sec/attempt = 60 seconds
• target 3: (4 attempts * 5 accounts) * 3 sec/attempt = 60 seconds
• target 4: (4 attempts * 5 accounts) * 3 sec/attempt = 60 seconds
• target 5: (4 attempts * 5 accounts) * 3 sec/attempt = 60 seconds

300 seconds (5 minutes) have elapsed after cycling trough the five targets and the five user accounts. If needed, the script can enter a grace period, (IDS reset time) - (total elapsed time), before resuming the attack pattern.

Yes, im aware that the grace period can be made much shorter with tweaking and further calculations but, i hope you see my general idea here.

Sorry for the long comment, just suggestions, let me know if you think its something you would like to implement and if you would like me to help with this.

[m4n3dw0lf]

I did this module very fast only to add functionality to the tool , it would be a good idea to attack more than a User in reality any idea is welcome , however I am engaged with the sniff/pforensic/arpspoof/injection modules but I will try to analyze the brute-force module this week, if you done any cool updates send more pull requests.