SSH password spray fails to work where hydra works with same inputs

[edwardsd97]

Describe the bug
Using nxc ssh to password spray does not work where same data with hydra does
Reproduced this while hacking the Wifinetic machine on app.hackthebox.com

To Reproduce
Using the following two input files

pass.txt
VeRyUniUqWiFIPasswrd1!
badpassword
goodpassword

users.txt
olivia.walker17
netadmin
samantha.wood93

nxc

user@kali:~$ nxc ssh 10.10.11.247 -u users.txt -p pass.txt
SSH         10.10.11.247    22     10.10.11.247     [*] SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.9
SSH         10.10.11.247    22     10.10.11.247     [-] olivia.walker17:VeRyUniUqWiFIPasswrd1! Authentication failed.
SSH         10.10.11.247    22     10.10.11.247     [-] netadmin:VeRyUniUqWiFIPasswrd1! 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] samantha.wood93:VeRyUniUqWiFIPasswrd1! 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] olivia.walker17:badpassword 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] netadmin:badpassword 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] samantha.wood93:badpassword 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] olivia.walker17:goodpassword 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] netadmin:goodpassword 'NoneType' object has no attribute 'auth_password'
SSH         10.10.11.247    22     10.10.11.247     [-] samantha.wood93:goodpassword 'NoneType' object has no attribute 'auth_password'

Hydra

user@kali:~$ hydra -L users.txt -P pass.txt 10.10.11.247 ssh
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-11-09 19:03:40
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 9 tasks per 1 server, overall 9 tasks, 9 login tries (l:3/p:3), ~1 try per task
[DATA] attacking ssh://10.10.11.247:22/
[22][ssh] host: 10.10.11.247   login: netadmin   password: VeRyUniUqWiFIPasswrd1!
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2023-11-09 19:03:45

[edwardsd97]

Also: reading the docs there appears to be no way to have the two input files treated round robin.

user1
user2
user3

pass1
pass2
pass3

Its either
user1:pass1
user1:pass2
user1:pass3
user2:pass1
...

or
user1:pass1
user2:pass2
user3:pass3

But no option to do criss cross seems to be available which might avoid being locked out better?
user1:pass1
user2:pass2
user3:pass3
user1:pass2
user2:pass3
user3:pass1
user1:pass3
user2:pass2
user3:pass1

[XiaoliChan]

I see, let me debug it

[NeffIsBack]

Thanks for the bug report!
Regarding the user:password combination: nxc will first iterate over the password list and then iterate over the user list in order to prevent lockout mechanisms as good as possible. This is independent on the protocol, so the same for smb. Doing a rotation like shifting the password by one after each user name iteration seems to be very hard to implement

[edwardsd97]

Sweet. Thanks Alex. Oh from reading the docs the --no-bruteforce option sounded like it was intended to stop the process after the first pass user1:pass1 user2:pass2 user3:pass3 then thats it. Which would make the process pretty pointless. And I thought in my testing of it that was exactly what it was doing. Maybe I mis-remembered that.

…

On Fri, Nov 10, 2023 at 6:27 AM Alex ***@***.***> wrote: Closed #112 <#112> as completed via #113 <#113>. — Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAMO7IV7YY772LKAEC4WTYDYMSBAVCNFSM6AAAAAA7FN4LGKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJQHEZDINJXGM2DMNA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[NeffIsBack]

Oh yes, this is correct for the --brute-force option.

[edwardsd97]

It feels like instead of just stopping after a 1 to 1 pass it should wait a defined period of time and then proceed to the next password for all users? user1:pass1 user2:pass1 user3:pass1 <wait> user1:pass2 user2:pass2 user3:pass2 <wait> user1:pass3 user2:pass3 user3:pass3 Where wait can be zero if you want and maybe the default

…

On Fri, Nov 10, 2023 at 10:17 AM Alex ***@***.***> wrote: Oh yes, this is correct for the --brute-force option. — Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAMOYFN5NFT5IYVH3CY63YDZHP5AVCNFSM6AAAAAA7FN4LGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGAZDMNBSHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[edwardsd97]

So really I guess I am suggesting instead of --no-bruteforce there is just an option for a cycle delay time --delay 30 But whatever. I don't know what I am talking about. you guys are the experts. :) Maybe that doesnt avoid a lockout at all.

…

On Fri, Nov 10, 2023 at 11:38 AM Dan Edwards ***@***.***> wrote: It feels like instead of just stopping after a 1 to 1 pass it should wait a defined period of time and then proceed to the next password for all users? user1:pass1 user2:pass1 user3:pass1 <wait> user1:pass2 user2:pass2 user3:pass2 <wait> user1:pass3 user2:pass3 user3:pass3 Where wait can be zero if you want and maybe the default On Fri, Nov 10, 2023 at 10:17 AM Alex ***@***.***> wrote: > Oh yes, this is correct for the --brute-force option. > > — > Reply to this email directly, view it on GitHub > <#112 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABPAMOYFN5NFT5IYVH3CY63YDZHP5AVCNFSM6AAAAAA7FN4LGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGAZDMNBSHA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[NeffIsBack]

Ah yes throttling login attempts would be an idea, but it gets really complicated with multithreading (when you specify more than one host). That's probably why nobody has done that before. For single targets it would be an idea tho, but i must say in real life pentests i nearly never brute-force over the network as it is incredible slow and companies most often have a lockout policy that would disable that.

For the --no-bruteforce option, it isn't meant to throttle down login attempts, but to try a list of user names with a list of passwords, e.g. username:username