One of the easiest ways for us to capture and/or relay hashes on the network is through NBNS spoofing. We will primarily use Responder.py or the Metasploit nbns spoofing module . Both of these tools can be great for attackers to use during a pen test, but remediation options for fixing the underlying issues are limited. In response to a lack of available mitigation options, I’ve written a script to help identify NBNS spoofers on the network.
This script makes frequent NBNS requests for a non-existent host name (the default is NETSPITEST) and it then listens for NBNS responses. Since there shouldn’t be any responses for this host name, the listener will sit idle until a response is received. If a response is received, we will know that there’s a spoofer on the network. Once a spoofer is identified, email alerting and syslogging options are available to alert network administrators of the issue.
This example command will make custom queries for NBNSHOSTQUERY for the responder to respond to. It will send an email alert to firstname.lastname@example.org when an attack is identified and responses will also be logged to test.log
The IP of this host
The Broadcast IP of this host
Show this help message and exit
-f /home/nbns.log, -F /home/nbns.log
File name to save a log file
Log to local Syslog – this is pretty beta
The email to receive alerts at
Email Server to Send Emails to
The string to query with NBNS, this should be unique
The option to send Garbage SMB Auth requests to the attacker (not implemented yet)
Continue Emailing After a Detection, could lead to spam
Example Script Output:
$ sudo python spoofspotter.py -i 192.168.1.161 -b 192.168.1.255 -n testfakehostname -s 192.168.1.2 -e email@example.com -f test.log
Starting NBNS Request Thread...
Starting UDP Response Server...
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:47.497274 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:49.549245 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:51.600981 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:53.657044 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:55.721037 from host 192.168.1.162
Stopping Server and Exiting...
There is an additional option that I’m currently working on, to make your pen tester especially annoyed. The –R flag will set the SMB response option to try and authenticate with the spoofer’s system. Since the NBNS spoofing attacks are used to capture (or relay hashes), why not send the attacker some hashes. Why not send a ton of them and make the attacker take their time trying to crack them, or just overload their logs. This will probably annoy an attacker more than anything else, but anything to make their attack harder may give you extra time to respond.
On that note, it was a little difficult for me to write this tool, as I have a feeling it will come back to haunt me in a future pen test. Feel free to send me any comments or feedback on the script through this blog or through our github page.
Special thanks go out to our client who had the idea for this script.
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform.
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.