As Cybersecurity/Infosec Professionals we know that all you have to do is wait 30 seconds and someone else has been breached and two new vulnerabilities have been discovered (hypothetically of course). There are few jobs on Earth that see the constantly evolving challenges that we get the privilege to deal with. This constant state of flux and learning has been what has kept me interested in this field as there are no shortages of challenges to counter. With an ever-growing list of Nation State attackers, organized criminals, hacktivist groups, and every other threat out there, no organization is safe. When you look across all industries in the private sector as well as government organizations at all levels, we are all getting attacked constantly.
Active Defense: Any defensive activity that is not simply installing a product or waiting for an IDS/firewall alert
- Proactive and anticipatory (hunt teaming, software restriction polices, and Internet whitelisting)
Cyber Deception: The deliberate and calculated process of deceiving attackers in an effort to wage a better defense (“Honey” things placed in your network which wouldn’t normally be accessed)
“All warfare is based on deception. There is no place where espionage is not used.
Offer the enemy bait to lure him.” ~Sun Tzu”
- The tactics covered here are meant to augment existing defensive techniques and technologies; not replace them
- Before employing these tactics, you must make sure you have the ability to ingest and analyze the additional alerts that could arise
- Make sure you vet all tactics with your legal team, human resources, and upper management first
Reducing Blind Spots in your Network
Many organizations today have solid defensive capabilities and monitoring at their network boundary, but once an attacker is within the network their activities and movements they often go unnoticed. One of the goals of implementing Active Defense and Cyber Deception is to reduce blind spots within the network by essentially setting up virtual trip-wires within the network. More specifically, it involves strategically deploying honeypots, honeyports, and honeyobjects. These “honey” things serve no legitimate purpose, so anytime they are interacted with it needs to be investigated. The tools and tactics that I am covering in this post utilize built-in capabilities within the operating system or free open-source software.
There are a few key things to keep in mind as you deploy a honeypot, honeyport, or any form of honeyobject. First anything you deploy should be done in such a way that it is believable, and secondly, you must ensure that you can receive alerts when the honeypot, honeyport, or honeyobject is interacted with. By doing these things you will greatly increase your chances of identifying anomalous activity within the lower areas of your network.
In addition to these capabilities custom IDS signatures should be created to identify unique strings or port access across your network. With this in mind, let’s look at a couple common honeypots in use today.
The goal of all Active Defense and Cyber Deception techniques is to disrupt the attack cycle to give defenders a better chance of early detection. The earlier in the attack cycle we detect anomalous/malicious activity, the greater our chances of stopping an attacker from establishing long term persistence and/or exfiltrating sensitive data.
There are many different honeypots available today both in the open-source and commercial software arenas. There is definitely no one-size fits-all solution out there. With this being said, I am going to cover two common open-source honeypots that have very specialized functions. The two that I am going to discuss here are Dionaea and Conpot. Dionaea is a honeypot that is focused on malware collection, but is also capable of logging information pertaining to server-side attacks. Conpot is a ICS/SCADA honeypot that is able to mimic a wide variety of different control systems.
I chose these two honeypots to discuss because they provide an excellent example of why you should not deploy a honeypot in its default configuration, and you must put some thought into how and where the system is deployed.
One of the first steps most attackers are going to take will be to scan your environment to identify the systems and services available within your network. For this example I have deployed Dionaea in its default configuration and have run a nmap service scan against the system. As you can see in the scan results below, there are three ports that have services being identified as Dionaea honeypot.
If an attacker was to discover this they will likely change their tactics to be more careful and they will definitely avoid this system. As defenders we don’t want any type of active defense measure to be able to be identified this easily; so we should investigate the tool prior to deploying it and try to make some subtle modifications to help avoid detection. This is essentially the same thing attackers do by utilizing measures to avoid detection of A/V, IDS, and other traditional defense products.
To help avoid easy detection of the Dionaea honeypot I needed to find out what nmap was using to fingerprint these services. I started doing the research and code analysis to determine this, but during the course of my investigation I discovered that Jose Manuel Fernandez had already done this research and had published it on securityartwork.es.
When nmap is working to fingerprint a service, it simply compares the strings coming back to it against the nmap-service-probes file, which contains a listing of known strings along with their corresponding service identifier. To help Dionaea avoid detection by nmap, we simply need to change the strings that it is sending in response to the probes sent by nmap. As I stated earlier, we want to make sure that this is believable, so we want to pick service fingerprints that make sense for our environment and ideally aren’t too far out of date.
For the FTP service I did a little research on vulnerable FTP services that were relatively current. In addition to making the service current, I also wanted to find a vulnerable FTP service, so I did some research on the https://www.cvedetails.com/ site; and chose to mimic VsFTPD 3.0.2.
To make the changes for Dionaea’s responses I had to modify the ftp.py script being used for the service. The exact location will vary depending on where you install, but for my instance it was located in
Once I opened the ftp.py file in a text editor, I needed to find the string being used to fingerprint it, which is highlighted below.
To complete the modifications, I updated the SMB and MSSQL files so that they wouldn’t match the nmap-service-profiles definitions for the SMB and MSSQL services as shown below.
Once all of these changes were complete and the Dionaea honeypot was restarted, you can see that the scan results no longer scream “I’m a Honeypot!”
Conpot is a low interactive server side Industrial Control Systems honeypot designed to be easy to deploy, modify and extend to mimic a wide variety of devices/infrastructures. There has been some interesting research on Conpot with regards to its default configuration and deployment. Specifically, Darren Martyn documented a significant amount of data for Conpot on http://xiphosresearch.com/2015/12/09/OPSEC-For-Honeypots.html.
Conpot can be easily identified by a series of default values set within its configuration file simply named default.xml. On my installation it is located here:
Below are two excerpts from the default.xml file with specific values pointed out that can be used to identify the presence of Conpot.
With these values in mind, I went to Shodan to demonstrate how you can do a search on these values and get quite a few responses back. In the graphic below, you can see that I did a search on the device serial number and got back 206 results. If you take a look at the results you can see that they all have the same Module Type, Module name, and serial number. Additionally, if you were to run this same search in Shodan, you will find a number of these Conpot systems hosted by Cloud based providers. This ties in with my earlier statement on deploying systems in a way that is believable. You should not see ICS systems running in the cloud! Could it happen, sure, you could theoretically virtualize a PLC and host it in the cloud, but just because you can, doesn’t necessarily mean you should.
From this result, I picked one IP and did another search in Shodan’s experimental site Honeyscore to see if the IP could be identified as a honeypot. As you can see in the following graphic, Honeyscore identified the IP 220.127.116.11 as a honeypot.
As an alternative to deploying full honeypot systems, we can always stand-up a handful of decoy ports that serve no legitimate purpose. Personally, honeyports are something I believe are best used within your network and should mimic services that attackers will use to move laterally. They can be extended well beyond this of course, and their implementation is only limited by the creativity of the defender. There are numerous FREE tools and methods available for honeyports, so it is recommended to try a few and see what works best for your environment. A few examples are:
- Honeyports python script by Paul Asadorian: https://github.com/ethack/honeyports/blob/master/honeyports-0.4a.py
- Honeyports.py is a simply python script that will establish a set of honeyports, monitor for connections, and automatically enter firewall block rules to block attacker IPs from connecting to the system again.
- Artillery by Dave Kennedy: https://www.trustedsec.com/artillery/
- Artillery is an open source project aimed at the detection of early warning indicators and attacks. The concept is that Artillery will spawn multiple ports on a system giving the attacker the idea that multiple ports are exposed. Additionally, Artillery actively monitors the filesystem for changes, brute force attacks, and other indicators of compromise. Artillery is a full suite for protection against attack on Linux and Windows based devices. It can be used as an early warning indicator of attackers on your network. Additionally, Artillery integrates into threat intelligence feeds which can notify when a previously seen attacker IP address has been identified. Artillery supports multiple configuration types, different versions of Linux, and can be deployed across multiple systems and events sent centrally.
Or, we can simply use some good old fashioned command-line kung-fu to accomplish the same thing. Just like with the above-mentioned tools, the goal is to have a port or ports which will show up in port scan results that are not meant for a legitimate purpose. When anyone interacts with them it is automatically considered suspicious, and a firewall block is put in place. When setting up a honeyport, remember that it should mimic a vulnerable service or one that an attacker would use to move laterally.
On Windows XP and later, we can set-up a Windows batch file to set-up our honeyport and to automatically create a firewall rule if it is accessed. In the example below, the firewall syntax is for Window 7 and above, but it could be changed to simply use the netsh firewall command if you were using this on an XP machine.
To make this work, we would simply enter the commands below into a .bat file and set it to run on system start.
You will want to ensure that you are logging firewall events, and you can then set to forward and monitor for Event ID’s 2002 & 2010. Event ID 2002, indicates that firewall rules were changed, and Event ID 2010 indicates that the network profile has been changed. In situations where we are deploying honeyports or honeyobjects, we really need to be forwarding logs to a central log management server and monitoring from there.
An example of how this could be deployed, would be for us to set-up a Honeyport on TCP port 5900 to mimic a listening VNC server across many, or even all systems in the network. Legitimate users should never touch this, but it would be an attractive port to an attacker seeking to move laterally throughout the network. When the attacker attempts to access the port, they are blocked and the event gets logged. The way this would look on the local event viewer is shown in the graphic below.
The goal with a honeyobject is to simply have some files or folders in a place where typical users are never going to access them, and if someone does it would be deemed suspicious. For files and folders being used as a honeyobject, you could apply the hidden attribute to help ensure that casual users don’t interact with them. Once the honey file/folder is created, you will need to have object access auditing enabled. For an example, I created the following scenario:
1. Established object auditing on the C:\Users\zander\Wicked Stuff directory
2. Applied hidden attribute, so that an average user won’t know the file is there
To enable object auditing you need to do the following:
Step 1: From the Security Policy Editor, Select Local Policy > Audit Policy > Audit Object Access > Select success & failure
Step 2: Go into Advanced properties for the folder you want to monitor
Step 3: Select Auditing Tab
Step 4: Add the user accounts you want to track usage for
Once this was completed, I ran a recursive directory listing in the same fashion that a bad guy would comb your file system looking for interesting files.
The result will be a number of entries in the Security log under Event ID 4663.
Active Defense and Cyber Deception capabilities provide a serious force multiplier for those trying to defend their networks. Determined attackers will find a way in, and you must be able to detect them once they do. Incident response is not an if it is going to happen situation, it is a when. Everyone is a target, and statistics show that attackers definitely have the advantage in this fight. Active Defense and Cyber Deception techniques can help you disrupt the attack cycle to disrupt and frustrate attacker activities. The tools and techniques discussed above are not meant to replace anything, they are meant to augment your existing defense capabilities. When deployed strategically and methodically they can greatly increase your chances of detection thereby reducing attacker dwell time within your environment. Take your network back!
I am teaching SEC504: Hacker Tools, Techniques, Exploits, and Incident Handling at many events in 2018 and 2019.
Chris Pizor, SANS Certified Instructor
Upcoming SANS Special Event – 2018 Holiday Hack Challenge
SANS Holiday Hack Challenge – KringleCon 2018
- Free SANS Online Capture-the-Flag Challenge
- Our annual gift to the entire Information Security Industry
- Designed for novice to advanced InfoSec professionals
- Fun for the whole family!!
- Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
- Learn more: www.kringlecon.com
- Play previous versions from free 24/7/365: www.holidayhackchallenge.com
- “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
- “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
- “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen