False positive failover

[TormentedSoul666]

Without a failover to prevent false positives, you will get completely unreliable results due to SonicWall etc.
Easiest approach:
stdin, stdout, stderr = ssh.exec_command("/sbin/ifconfig") output = stdout.read() if 'inet' in output etc...

BTW: This is not "distributed" credential stuffing, as this would be based on multiple hosts communicating targets/credentials with each other and "distribute" the workload (usually following a p2p majority voting approach).

If you use ThreadPool etc., why no CIDR-range for hosts or at least a hosts file? Makes the proxy approach quite timid.
The same can btw. be achieved by using proxychains and any random related tool.

[TormentedSoul666]

Also there is something wrong with the queue, it only loops all passwords over the first user in the user list...

[k4yt3x]

This script was supposed to be a PoC, and I never imagined it to receive this much attention. Thus, some of the functionalities were implemented in a simplified way for rapid prototyping. If you look at the commit history, you'll see that I've only spent one afternoon to develop this. I hope that explains why there isn't any advanced functionalities included. With that said, as it receives more attention and more issues come in, I'll implement more features as it goes.

ifconfig is not a built-in command that's included in all distros. It's a part of the net-tools package which is no longer installed by default on a lot of new distros. Instead, you'll see iproute2 more widely adopted. On the other hand, /usr/bin/true is a part of coreutils, which is more likely to be installed, if a command has to be executed. I believe there are other ways to verify as well without executing commands.

This is not "distributed" credential stuffing

Credential stuffing and brute-forcing are different concepts. This is a brute-forcing tool to begin with.

...based on multiple hosts communicating targets/credentials with each other and "distribute" the workload...

In some sense, this is what's happening. This tool will proxy requests over a pool of proxy servers and have the proxy servers send authentication requests to the SSH server. While in a narrow sense, this kind of brute-forcing is not as distributed as running a brute-forcing tool on multiple hosts, from a network perspective, the traffic is distributed. It really depends on how you interpret the terms. I found "distributed" to be an intuitive way to describe what's happening. That's all.

why no CIDR-range for hosts or at least a hosts file?

You mean a file containing a list of proxies? That can be implemented quite easily with some tweaking. It's not there because this is a prototype PoC. I can make that happen if you want.

The same can btw. be achieved by using proxychains and any random related tool.

AFAIK proxychains cannot send each of the SSH requests over a different proxy. This is part of the reason why I wrote this tool. The other half was just for fun and playing with paramiko.

Thanks for the issue and your interest in this tool, and sorry for the delay.
I read it before I went to bed and I forgot to send the reply out.

[TormentedSoul666]

Well, the approach is good and it's featured on kitploit and related blogs.

You're right about ifconfig, an approach which should work even on embedded devices is if ([ /bin/echo -e "\x6c\x6f\x6c"== "lol" ] || [printf "\x6c\x6f\x6c"== "lol" ] || /bin/echocat /etc/passwd >/dev/null 2>&1 );then <payload> ;fi

This is a tool to perform a dictionary attack (nowadays also called credential stuffing, especially in context of Account "Crackers"), Bruteforce is creating strings with a predefined charset (and optional rules like prefixes) in runtime and running them against user and/or password prompts.

Proxychains may be used in context of sh scripts and/or piping into parallel, which - with threads per server limited to one equal to amount of attempts and in a loop - may be used with Hydra, NCrack, or any desired tool for a 1:1 relation between proxy and attempt.

I use Hydra with rotating proxies in a random_chain proxychains-ng configuration. I also have coded own tools in Python and Go but Hydra returns much less false positives overall.

[TormentedSoul666]

P.S. I know that the Socks4 list is usually the largest on proxyscrape but you should limit them at least to anonymous, if not elite level. Also the most of them are blacklisted on many servers and you might use a single proxy per request approach by using e.g. gimmeproxy API.

[TormentedSoul666]

Two additions:

1. I'd definitely apply a simple routine (e.g. via GET request to a website with a known laissez-faire WAF/IPS config like microsoft.com using the already imported requests) to check if the proxies are alive and acceptable in terms of timeouts etc.
2. The key to exhaust the capabilities of your approach is to avoid triggering fail2ban/IPS/firewall rules by using either a) an approach like ncrack --stealthy-linear does or b) shuffling the queue to avoid having two requests with the same username to the same host.

Do you want to apply the changes yourself or should I take some time on weekend to find the bug in the loop, apply an optional parameter for loading hosts from a list (the CIDR idea doesn't make sense since there are very capable options like zmap/masscan and adding any CIDR notation support would make at least a basic half-open port scan mandatory, which is not among the scope of your concept), shuffling the queue and adding a simple proxy test all via commits and pull requests?

[TormentedSoul666]

Last thing for now (sorry, my mind likes to "chew" on thoughts ad nauseam): "real" distribution of workload is easier to implement than one might think. My approach would be in this case to use existing PoCs of Botnets using the Tox protocol and using a simple broadcast and response pattern to coordinate efficient distribution of random class C netmasks (255.255.255.0/24) with a communication between the peers like "I randomized x.x.x.0 and will start auditing it, is any other peer already working on this subnet?" (Broadcast) no response=go to go or "I'm already working on this netmask, repeat IP randomize" (Response in case of already queued/running repetation of this netmask).