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 with address
  • Windows Server 2012R2 (64-bit) : target machine, 5GB of RAM, 2 vCPUs, fully up-to-date, same NAT network with address

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 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

  • "CTRL+X" isn't doing anything special. You can get this status line by pressing any key that isn't bound to a special runtime interaction function. Press "?" to get a list of key bindings. Feb 18, 2020 at 17:18

2 Answers 2


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


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

  • Unfortunately, this does not change the problem. The only difference is that instead of being frozen at 33.33% it's frozen at 99.80%. The level 2 debugging information is still the same. Feb 18, 2020 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.