Bypassing LLMNR/NBT-NS honeypot

Abstract

MITRE ATT&CK™ [https://attack.mitre.org/] “is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations” which recommends the Conveigh honeypot [https://github.com/Kevin-Robertson/Conveigh] for detection of the LLMNR/NBT-NS Poisoning and Relay (T1171) [https://attack.mitre.org/techniques/T1171/] attack. This type of attack is currently one of the most popular attack on Windows networks. However most honeypots used for detecting it can be easily bypassed by detecting the honeypot itself.

Outsmarting the smart a.k.a. honeypot detection

When you deploy a honeypot one of the most important things is to not reveal to everyone in the neighborhood that this is actually a honeypot.

Honeypot Conveigh approach is simple, it sends random LLMNR and NBNS requests at random intervals. If someone in the network responds to these random requests, then it is most likely an attacker who wants to spoof such request, what leads to MITM attack.

In case of Windows system a NBNS (NBT-NS, NetBIOS Name Service) query is sent using broadcast address based on your network settings, including mask, so for 192.168.1.0/24 it is 192.168.1.255. 

However this honeypot is sending each NBNS query always to 255.255.255.255 [https://github.com/Kevin-Robertson/Conveigh/blob/master/Conveigh.ps1#L295]

> New-Object System.Net.IPEndpoint([IPAddress]::broadcast,137)

AddressFamily Address         Port

------------- -------         ----

 InterNetwork 255.255.255.255  137

Windows is never sending NBNS queries on that special broadcast address (it means “this network”). You can detect Conveigh honeypot by simply using the following Wireshark display filter nbns && ip.dst == 255.255.255.255.

Another problem is that Conveigh is sending other queries, once with LLMNR, the other time with NBNS, when in reality Windows is querying both protocols using the same name and at the same time. If one of these protocols will be disabled then Windows will always send a query using only the enabled one – it means that actually there can never be such situation like for example Windows is querying some name with LLMNR only, and then after 5 minutes is querying another name with NBNS only etc, but this is how Conveigh actually works.

NBNS is using broadcast on port 137/udp, LLMNR is using multicast IP address 224.0.0.252 on port 5355/udp. Please note that there is also a 3rd protocol – mDNS, which is using multicast IP address 224.0.0.251 port 5353/udp, but we will not focus on it as this blog post is about a specific honeypot related to LLMNR and NBNS.

Additional problem arises because of Conveigh’ creation of random looking hostnames in LLMNR/NBNS queries, which are actually random strings between 5 and 10 characters [https://github.com/Kevin-Robertson/Conveigh/blob/master/Conveigh.ps1#L264]. It can work, but only as a script kiddie detector. Well prepared attackers can't be fooled using this simple technique, such detection method can work on people who just blindly run poisoning attacks without any initial recon.

During a red teaming engagement it is a good idea to run Responder [https://github.com/lgandx/Responder] initially for some time with the -A option (“Analyze mode. This option allows you to see NBT-NS, BROWSER, LLMNR requests without responding [poisoning]”). Then just ignore such honeypot IP address during the actual poisoning attack. At least that way we can fool such primitive and reckless tools.

Summary

At least in most cases it will work as described and it makes whole detection of such honeypots quite easy. This is the reason why I always say that red team should have threat hunting skills and vice-versa, because wide experience is very useful in both areas and gives you a better perspective. Red teamers will know that there is a possibility of honeypot presence and how it works, threat hunters will know that such honeypot is useful but only to catch low skilled script kiddies who just run hacking tools without any understanding. Don't look far just check article in which I wrote about detecting Deloitte Greece ethical hacking team technique called "LAME" (LAteral Movement Encryption) [https://blog.redteam.pl/2019/04/dns-based-threat-hunting-and-doh.html] (second part of the article). Purpose of this “LAME” technique is to not being detected or at least making detection harder, but if you will use this, you will be most likely detected, however if you will not use this, you probably will fly under radar... This is a good example why fancy and “advanced hacker methods” are not always as cool as described by their authors, and why you need know how detection systems work if you would like to be red teamer.

Please note that I don’t blame MITRE ATT&CK for bad approach as this is a free and in generally a good project, but it’s not always high quality content as it is created by the community, because of that should not be treated like an oracle by threat hunters. Defensive security is not about blind rewriting that knowledge as detection and prevention methods. This is not how it works in cybersecurity, you need to think like an attacker to be a good defender and for that you need similar knowledge as attacker has, to know tools and TTPs as described on top of The Pyramid of Pain [https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html] – threat hunting is also about researching new detection methods.

BTW. If you are BOFH, you can always name your domain controller (DC) as honeypot and your actual honeypot as DC01 etc. This is funny, but what is even more funny is that it actually works on most of script kiddies…