Nmap with snmp-brute script freezes at 33.33%

Question

I'm currently undergoing a penetration testing course where I discover the basics and I have a task where I need to perform SNMP enumeration on a target.

My working environment is as follows :
Host : Windows 10 (64-bit)
Oracle VM VirutalBox machines :

• Kali Linux 2019.4 (64-bit) : attacker machine, 4GB of RAM, 4 vCPUs, fully up-to-date, NAT network 10.10.10.0/24 with address 10.10.10.11
• Windows Server 2012R2 (64-bit) : target machine, 5GB of RAM, 2 vCPUs, fully up-to-date, same NAT network 10.10.10.0/24 with address 10.10.10.12

Edit : The 2 machines can ping each other.

On the target machine, SNMP service has been activated via the "Add roles and features" window and configured to have a basic "public" community string and to allow SNMP packets from any host.

The problem :

I need to use the following command : nmap -sU -p 161 --script=snmp-brute 10.10.10.12 on Kali Linux to brute-force the community string of the target machine.

But when I do so, UDP scan goes on without a problem, but the NSE script just freezes at 33.33%. If I use combination CTRL+X (found it accidentally, didn't know it was a thing) (edit : if I get a status line by pressing any key) I get the following information :

Stats: 12:26:31 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 33.33% done; ETC: 04:57 (24:53:00 remaining)

and the "time remaining" keeps on rising.

If I increase debugging level to 2 with d, I get these similar packets forever :

NSOCK INFO [47243.1930s] nsock_pcap_read_packet(): Pcap read request from IOD #2  EID 262533
NSOCK INFO [47243.4940s] nsock_trace_handler_callback(): Callback: READ-PCAP TIMEOUT for EID 262533 

Edit : Just to be sure that it has nothing to do with Windows Firewall on the target machine, I deactivated it. Nothing changed.

Can someone please shed some light on this problem for me ? Thank you very much

Answer 1

This is a bug in the snmp-brute script. I just pushed a fix to the development branch to address this. There was a set of checks put into place due to a different bug that made the behavior of snmp-brute's sending thread illegal, causing it to terminate with an error. Because the main thread's loop condition didn't check for an error in the sending thread, it kept running the receive thread. That's 1 out of 3 threads ending, and the other 2 in an infinite loop, hence 33.33% completed.

The fix I pushed will allow the script to end, but it's still currently broken; I hope to have a fix later today to resolve the underlying issue of cross-thread socket reuse.

EDIT: cross-thread script reuse fix

Answer 2

Don't specify UDP port as you can see in this example: https://nmap.org/nsedoc/scripts/snmp-brute.html