--continue-on-success is nor working correct

[id2746]

Describe the bug --continue-on-success option isn't working. If guest session is enabled, brutforce is spopping on first password

To Reproduce Steps to reproduce the behavior i.e.: Command: nxc smb ip.txt -u User -p brut/top20admin.txt --continue-on-success Resulted in:

└─$ nxc smb ip.txt -u User -p brut/top20admin.txt  **--continue-on-success**             
SMB         192.168.1.10    445    BUG              [*] Windows 10 Pro 19045 x64 (name:BUG) (domain:Buh) (signing:False) (SMBv1:True)
SMB         192.168.1.12    445    BUG1             [*] Windows 10 Pro 19045 x64 (name:BUG1) (domain:Buh1) (signing:False) (SMBv1:True)
SMB         192.168.1.10    445    BUG              [+] Bug\User:admin (Guest)
SMB         192.168.1.12    445    BUG1             [+] Bug1\User:admin (Guest)
Running nxc against 2 targets ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

**NetExec info**
 - OS: Kali 2024.3
 - Version of nxc: v1.5.2
 - Installed from: apt

[Dfte]

If guest session is allowed, if you authenticate using any unknown domain user, you will get a valid authentication tho. Can you try the same thing but for a valid domain user ? Otherwise it doesn't make sense to bruteforce unknown users

[id2746]

this case is not from my network))) if i use cme, its look like this: └─$ cme smb ip.txt -u user -p brut/top20admin.txt --continue-on-success
SMB 192.168.1.12 445 BUH1 [] Windows 10 Pro 19045 x64 (name:BUH1) (domain:Buh1) (signing:False) (SMBv1:True) SMB 192.168.1.10 445 BUH [] Windows 10 Pro 19045 x64 (name:BUH) (domain:Buh) (signing:False) (SMBv1:True) SMB 192.168.1.12 445 BUH1 [+] Buh1\user:admin SMB 192.168.1.12 445 BUH1 [+] Buh1\user:123456 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:12345678 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:1234 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:Password SMB 192.168.1.12 445 BUH1 [+] Buh1\user:123 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:12345 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:admin123 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:123456789 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:adminisp SMB 192.168.1.12 445 BUH1 [+] Buh1\user:demo SMB 192.168.1.12 445 BUH1 [+] Buh1\user:root SMB 192.168.1.12 445 BUH1 [+] Buh1\user:123123 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:admin@123 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:123456aA@ SMB 192.168.1.12 445 BUH1 [+] Buh1\user:01031974 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:Admin@123 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:111111 SMB 192.168.1.12 445 BUH1 [+] Buh1\user:admin1234

[Dfte]

Ah yeah I got your point! Taking a look at it :)

[Dfte]

@mpgn looks like it's related to this https://github.com/byt3bl33d3r/CrackMapExec/issues/321

I have got the same issue without the guest thing:

Apparently you issued a patch because continue-on-success wasn't working on servers with smb signing enabled ?

[mpgn]

if you have only one user and a password is found, why you want to continue to bf ? the feature is useful if you have multiple users

[Dfte]

Yeah I agree xD So going back to what I said before. There is no issue, if guest is enabled, authentication will always be valid so nxc stops.

[NeffIsBack]

Adding to the discussion: Nxc removes users with a correct password from the queue, even if --continue-on-success is enabled because:

1. Bruteforcing the guest account doesn't make any sense
2. There is no reason to hammer passwords against an account where you already found a valid password

Fyi this feature was not implemented back in CME (at least the kali version), that is why you see the different behaviour. Add another user to the queue and you will see the result:

[id2746]

the point is that the user "User" is valid, but because of the guest session enabled, I can't brute force it. How should I be in such a case? That is why I cited the case from CME as an example

[NeffIsBack]

Are you sure you are authenticating against the correct domain? If the user exists in the domain you should get a failed login (as you can see in my screenshot).

In your screenshot it looks like you found the user for the domain "Buh" but in the cme output you are authenticating against the "Buh1" domain.

[Dfte]

These look like local users. If you want to bruteforce local users, add the --local-auth. Otherwise disable the guest domain user and guest local accounts

[NeffIsBack]

If there still is something unclear feel free to reopen or hit us up on discord