SMB: Dumping users takes really long time

[evmxattr]

While working on a HTB lab I noticed something odd when using nxc through a Ligolo proxy.

I'm trying to figure out why nxc is slow when dumping users when proxying through Ligolo.

I have Ligolo-ng agent running on a HTB attack box, and the Ligolo proxy running on Kali.

Proxy setup

# Kali
./proxy -selfcert -laddr 0.0.0.0:9001

sudo ip tunap add user kali mode tun ligolo  
sudo ip link set ligolo up
sudo ip route add 172.16.5.0/24 dev ligolo

# Agent
./agent -connect 10.10.15.171:9001 -ignore-cert

The thing is, it works and gets the users. It is however extremely slow compared to Crackmapexec. It prints user every one second for some reason.

Command

nxc smb 172.16.5.5 -u forend -p Klmcargo2 --users

NetExec info

• OS: Linux kali 6.8.11-amd64 Kali 6.8.11-1kali2 (2024-05-30) x86_64 GNU/Linux
• Version of nxc: 1.1.0 - nxc4u
• Installed from: Self built binary from Github

Latest from Github has been tried, as well 1.1.0 from releases.

I made a comparison video where the same command was run on crackmapexec.

Note: nxc: v1.2.0 doesn't even work when running the same command as listed above, it just hangs indefinitely, therefore I am using v1.1.0

Any idea how to tackle this ?

https://github.com/user-attachments/assets/acff11ee-1617-4df0-aca2-0dc0b2fc25b5

[Marshall-Hallenbeck]

Is it equally slow with a different proxy?

[evmxattr]

Wow. Quick response.

I tried with SSH and Proxychains4, and it's equally slow.

ssh -N -D 127.0.0.1:1080 htb-student@10.129.74.124

Proxychains conf

# proxychains.conf  VER 4.x
#
#        HTTP, SOCKS4a, SOCKS5 tunneling proxifier with DNS.

strict_chain

## Proxy DNS requests - no leak for DNS data
# (disable all of the 3 items below to not proxy your DNS requests)

# method 1. this uses the proxychains4 style method to do remote dns:
# a thread is spawned that serves DNS requests and hands down an ip
# assigned from an internal list (via remote_dns_subnet).
# this is the easiest (setup-wise) and fastest method, however on
# systems with buggy libcs and very complex software like webbrowsers
# this might not work and/or cause crashes.
proxy_dns

remote_dns_subnet 224

# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks5  127.0.0.1 1080

I also compared the two commands against my home lab (No proxy here).

time nxc smb 10.0.10.72 -u Administrator -p Password100 --users
real    5.56s
user    3.12s
sys     0.15s
cpu     58%

time crackmapexec smb 10.0.10.72 -u Administrator -p Password100 --users
real    0.98s
user    0.73s
sys     0.08s
cpu     82%

[Marshall-Hallenbeck]

Is it also very slow without the proxy? Can you test the HTB host without a proxy or is it required for that specific box?

If it's fast without the proxy, can you run the command with --debug and post the results here?

[evmxattr]

The proxy isn't needed for this specific box. I'm just using the box as a proxy so I can use my own tools on it.

$./nxc smb 172.16.5.5 -u forend -p Klmcargo2 --users
[1826] Error loading Python lib '/tmp/_MEI7Q76Rc/libpython3.11.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /tmp/_MEI7Q76Rc/libpython3.11.so.1.0)

HTB host has 3.9.2

I will try building it with 3.9.2 and report back.

[evmxattr]

I ran it on the host with a v1.1.0.

Dumping ~2900 users.

time ./nxc smb 172.16.5.5 -u forend -p Klmcargo2 --users 
real    1m16.699s
user    1m5.402s
sys     0m1.047s

time crackmapexec smb 172.16.5.5 -u forend -p Klmcargo2 --users 
real    0m59.259s
user    0m22.086s
sys     0m3.856s

debug_nxc_smb_htb.log

[Marshall-Hallenbeck]

@evmxattr Can you run it with --debug?

[evmxattr]

@Marshall-Hallenbeck sure. Here it is. nxc_1.1.0_debug.txt

[NeffIsBack]

Which version of cme is this? The one on apt? Took a look at the archived version and there isn't much of a difference in the code

[evmxattr]

Version 5.4.0

[NeffIsBack]

Could you try Netexec 1.0.0?

[evmxattr]

Sure. I built v1.0.0 and ran it on HTB.

nxc 1.0.0 on HTB

time ./nxc1.0.0_py392 smb 172.16.5.5 -u forend -p Klmcargo2 --users

real    1m35.520s
user    1m21.574s
sys     0m1.444s

cme Version: 5.1.7dev on HTB

time crackmapexec smb 172.16.5.5 -u forend -p Klmcargo2 --users

real    1m4.048s
user    0m22.028s
sys     0m3.888s

Also ran the same tests on Kali.

nxc 1.0.0 on Kali

time proxychains4 -q -f proxychains4.conf ./nxc1.0.0  smb 172.16.5.5 -u forend -p Klmcargo2 --users

Note: I stopped this since it was printing user every 1 second or so. With ~2700 users this would take around an hour to print.

cme Version : 5.4.0 on Kali

time proxychains4 -q -f proxychains4.conf crackmapexec  smb 172.16.5.5 -u forend -p Klmcargo2 --users

real    51.66s
user    4.40s
sys     0.22s
cpu     8%

Attached log from nxc v1.0.0 ran on HTB. nxc1.0.0_py392_debug.txt

[NeffIsBack]

This is really weird, the code didn't really change from cme5.4.0 to nxc1.0.0: https://github.dev/byt3bl33d3r/CrackMapExec/tree/v5.4.0 https://github.dev/Pennyw0rth/NetExec/tree/v1.0.0

Perhaps a dependency issue? Do you build the nxc version manually (looks like it from your command)?

EDIT: Impacket version comparison of both versions cme 5.4.0: 0.10.1.dev1+20220720.103933.3c6713e3 nxc 1.0.0: 0.12.0.dev1+20230909.154612.3beeda7c

[mpgn]

cme is using ldap behind this command while not nxc in order to make a comparaison use nxc ldap :)

[evmxattr]

This is really weird, the code didn't really change from cme5.4.0 to nxc1.0.0: https://github.dev/byt3bl33d3r/CrackMapExec/tree/v5.4.0 https://github.dev/Pennyw0rth/NetExec/tree/v1.0.0

Perhaps a dependency issue? Do you build the nxc version manually (looks like it from your command)?

EDIT: Impacket version comparison of both versions cme 5.4.0: 0.10.1.dev1+20220720.103933.3c6713e3 nxc 1.0.0: 0.12.0.dev1+20230909.154612.3beeda7c

They were all manually built yes.

[NeffIsBack]

cme is using ldap behind this command while not nxc in order to make a comparaison use nxc ldap :)

Ahhh makes sense! @evmxattr maybe use ldap's --users then if that's an option

[evmxattr]

Ok, thanks. Will do. Just thought the implementation was similar since it was the same command. Thanks for the tip @mpgn

[NeffIsBack]

Closing. If there are any further problems feel free to reopen :)