Serving up AD Decoy accounts to Responder
Last updated
Last updated
Editor's Note: This article was reproduced with the permission of the author. The original article was posted on medium titled: Serving Up AD Decoy Accounts to Responder on October 25, 2022.
Responder is one of the most popular Active Directory (AD) exploitation tools used once an adversary (or penetration tester) has gained a foothold into a network. In this article we’re going to look at how we can turn it around to serve up a juicy decoy account which will both waste attackers time and give us a high quality early alert to their presence. Want to just see a video, skip to the end of the article for a YouTube demo.
If you’re not familiar with Responder I’d highly suggest checking out this TCM Security video on it’s use, if you are familiar feel free to skip ahead to the Poisoning the Poisoner section below.
The TLDR; on Responder is that it listens on a network for NetBIOS, LLMNR and MDNS for SMB connections (think network shares). These generally happen when someone (or something) tries to resolve a hostname that doesn’t exist or is offline. When DNS resolution fails, on most default configured networks it will then fallback to LLMNR. LLMNR works by sending out a broadcast message asking if other hosts knows how to reach the host name. In theory, this sounds great, however Responder abuses this by sending poisoned LLMNR responses for SMB connections saying that it’s actually hosting the share. When the victim connects back it will automatically send over it’s username and NTLMv2 hash unknowingly to Responder which will capture it.
Attackers can use this hash to relay it on the network and gain a shell. Alternatively these hashes are very crackable especially for weak passwords. One of the first things most attackers will do after capturing a hash is take it offline and try and crack it.
Most modern IDS/IPS can detect and alert on the poisoned responses from Responder, however, these sometimes have false positives and have to wait for something on the network to trigger an LLMNR look up. One way to avoid this is to trigger the LLMNR lookup yourself. This can be done by simply trying to connect to a network share for a known bad host name and seeing if it resolves. If it does resolve and you get a response back this is a good indication of poisoning.
Proactively triggering Responder poisoned responses is not a new idea and there have been open source tools that do some form of this as a Responder detection. One of the reasons detecting Responder early on is so advantageous for defenders is that for a lot of penetrations testers (and adversaries) it’s one of the very first things they will start up on an engagement. We can get an early warning of network intrusion or an unannounced pen test.
I created an open source tool called f1rstResponder which proactively detects responder by attempting to connect to an SMB share with a bad hostname. You can pass a hostname to the tool so that it matches your network naming convention, I suggest using a common typo of a high traffic share.
If f1rstResponder picks up a response to the hostname it will record the IP address it came from and alert on the possibility of a poisoned response by Responder. In addition to writing out to the console, it can also write out to syslog which allows it to interface with most popular SIEMs or log collectors.
Active Directory decoy accounts seem to be all the rage right now, while these aren’t a new creation or concept by any means they are picking up lots of popularity. The main idea behind these accounts is to make them appealing to attackers while being locked down and monitored such that any activity on them will trigger an alert. Ippsec recently did an awesome video on AD Honey Pot accounts that gave me the idea to tie them in with f1rstResponder. Check out his video below on how to set them up and also for an alternative alerting method.
For decoy accounts to work we need to entice an attacker to interact with them somehow. One common method is to include a password in the account description which will then be viewed by popular AD enumeration tools (like PowerView).
Alternatively, using f1rstResponder we can serve the account up on a silver platter to anyone running Responder. By specifying the account name, password and domain as optional flags to f1rstResponder it can send these back as if it were a regular victim. When the script picks up a response to the bad hostname, it will attempt to connect back to the share on the IP that responds using the credentials which passes the username and hash right to Responder.
In the example above we try to connect to the share EngineeringServerr (notice the typo) and if there is a response to that host resolution the script will pass back the username and domain for our decoy account along with a common weak password hash.
The password should fall to any cracking tool and word-list almost immediately and the network intruder will be ready to take their easy win and pass it around the network. At this point not only will we get a notification that Responder is running but we’ll also get a trigger on our decoy account for the login attempt. If we correlate these two alerts together we can have a basically 100% indication of network intrusion.
Of course, no one is going to sit and watch the console output of a script or Windows event log. Luckily f1rstResponder can write out to syslog and we can capture that along with Windows logs in any SIEM.
For my lab I used Graylog because it’s free and relatively easy to get up. A huge shoutout to 🛡️ David Elgut for his write up on setting up Graylog to do Windows threat hunting.
Following along with the above guide will get Graylog set up and all of the required Windows logging required. Next add a basic Syslog UDP input keeping note of the port it’s setup on and point 1rstResponder to log the Graylog IP and port. Once it’s working you’ll start to see messages come in (don’t forget to open up your firewall ports if needed).
Finally we can add some alerts in Graylog so that we’re notified of the important events. I added events for f1rstResponder poisoning detection, when it passed back a hash/username and finally for any logon attempts to our decoy account.
In Graylog you can configure alerts to be sent out to many different sources including email, text, slack and discord. You can also correlate alerts together to create higher priority alerts, for example you could create a high priority alert if there was a f1rstResponder detection where it passed back a username and hash and then an attempted decoy account login.
https://www.youtube.com/watch?v=hoBELulE7Js
Have any questions, please send me a message, I love to chat about all things Cybersecurity!
My name is Andrew Bellini and I sometimes go as DigitalAndrew on social media. I am an electrical engineer by trade with a bachelor’s degree in electrical engineering and is a licensed Professional Engineer (P. Eng) in Ontario, Canada. While my background and the majority of my career has been in electrical engineering, I am also an avid and passionate ethical hacker. In addition to being an instructor I am also a longtime student of TCM, and their courses helped me transition my career to working as a technical trainer for a cybersecurity company.
In addition to my love for all things ethical hacking, cybersecurity, CTFs and tech I also am a dad, play guitar and am passionate about the outdoors and fishing.
Follow Andrew on social media:
LinkedIn - https://www.linkedin.com/in/andrew-bellini/
Twitter - https://twitter.com/d1gitalandrew
Website – www.andrewbellini.com