CHAPTER 21
Deception: Next-Generation Honeypots
This chapter covers the topic of deception for defensive purposes. The chapter first covers deception in conflict from a historical perspective and then moves into the use of deception for protection of information systems using honeypots. The chapter provides many hands-on examples and explores the latest in deception and honeypot technologies.
In this chapter, we cover the following topics:
• Brief history of deception
• Honeypots as a form of deception
• Open source honeypots
• Commercial options
Brief History of Deception
Deception is as old as conflict. In fact, earlier than 800 bce, Sun Tzu, in his book The Art of War, said, “All warfare is based on deception.”1 A notable example of using deception in war includes Operation Bodyguard during WWII, when Allied forces used deception to feint attacks and make the Germans think the attacks were coming from another direction.2 Several fake airfields and a small army of Hollywood set builders created inflatable tanks and planes and buildings. All of this effort was successful in deceiving the Germans and caused them to hold a portion of their forces in reserve on D-Day.
As far as using deception to protect information systems, Fred Cohen is considered by many to be the grandfather of deception and derivative concepts such as honeypots. Cohen is also known as the person who first published the term computer virus, in 1984,3 by citing Len Adleman, who coined the term. Later, Cohen wrote the seminal work, “A Note on the Role of Deception in Information Protection,” in 1998.4 Although Cohen gave credit to others before him, such as Bill Cheswick and researchers at AT&T, it was Cohen and his associates who created the Deception Toolkit, which served as one of the first real honeypots.5
If Fred Cohen is the grandfather of modern deception technologies and honeypots, then Lance Spitzner should be considered the father of those technologies. Spitzner, in 1999, with little more than a computer connected to the Internet from his spare bedroom,6 inspired a generation of enthusiasts and founded the honeynet.org group,7 which continues to contribute to the field of deception technologies to this day. The honeynet.org group defined and built many levels and types of honeypots, many of which were the precursors of what we have today. We stand on the shoulders of these giants as we present some of the latest technologies in this chapter.
Honeypots as a Form of Deception
A honeypot may be simply defined as a system that has no legitimate purpose other than to be attacked and thereby give alerts of such activity. As has already been discussed, honeypots have been used for deception for many years. One of the problems with early honeypot technologies was the lack of the ability to scale. It often took an experienced security expert to deploy and monitor the technology, which was a full-time job in some environments, even just to monitor a few honeypots. In today’s corporate environments, the older honeypot technology is simply too labor intensive to deploy effectively. However, what was old is new again! With the advent of greater virtual technologies, container technologies such as Docker, and analytic tools such as the Elasticsearch, Logstash, Kibana (ELK) stack, what was once a full-time challenge has turned into a valuable asset of any organization’s cyberdefense, which may be managed part time. As we will demonstrate in this chapter, modern honeypots are easy to deploy and manage, at scale. Even industry analysts have noted that modern deception technologies should be deployed in order to supplement the other enterprise security technologies.8 Honeypot technology will not replace other layers of technology, but once an attacker is inside a network, it may be your best shot at catching them.
The main reason to deploy honeypots as a form of deception is to delay, disrupt, and distract the attacker in order to detect and stop them. The key attribute of honeypot technology is its low false-positive nature. By the very definition we used, honeypots should not be touched by anyone but an attacker. Therefore, when a connection is made to a honeypot, there is either a misconfigured server that needs attention, a curious user who needs attention, or an attacker who needs attention. There are no other options; therefore, honeypot technology is about as false-positive proof as you can get. In today’s high-false-positive environment, the ability to deploy a low or no false-positive technology should get your attention.
We’ll take a closer look at the following types of honeypot technologies:
• High-interaction honeypots
• Low-interaction honeypots
• Medium-interaction honeypots
• Honeyclients
• Honeytokens
High-Interaction Honeypots
High-interaction honeypots are most often real systems that are instrumented to monitor and catch an attacker in a near real-time manner. The problem, of course, with high-interaction honeypots is that real systems may be rooted and then used by the attacker to further their attack on the hosting network or other networks. Therefore, high-interaction honeypots are risky and often avoided.
Low-Interaction Honeypots
Low-interaction honeypots are at the other end of the spectrum; they are simulated services that run in some sort of emulated environment, whereby the service is simulating realistic responses. However, there is often a limit to that simulation. For example, the commands of the Telnet service may be emulated using Python or another scripting language, but not all of the commands work. If an attacker attempts to download a file with wget, for example, perhaps the command appears to work but the file is not provided to the attacker; instead, it is provided to the defender for further analysis. There are other practical limits as well in that it might not be feasible to emulate all the commands of Telnet. Therefore, if an attacker tries one of those commands and it fails, the deception could be over. We will take a look at some popular low-interaction honeypots in the coming sections and labs.
Medium-Interaction Honeypots
Medium-interaction honeypots were purposely listed after the other two, as they are a newer concept of deeply emulating services. This includes fully reproducing complex operating system processes, such as the SMB network protocol, to a degree that an attacker can run real exploits against the seemingly vulnerable service and in some cases even return a shell. This is a marked improvement over low-interaction honeypots, which would normally fail on those types of attacks. Some medium-interaction honeypots actually proxy the commands to the real operating system to achieve this level of deception.9,10 Another form of medium-interaction honeypot would be a canary service, running on a real system, whose purpose is to alert the defender to attacker behavior.
Honeyclients
Honeyclients are the other side of the honeypot coin. Whereas honeypots are generally services, soliciting a connection and request from an attacker, honeyclients are client applications, seeking to make connections to potentially compromised systems and extract binaries and potential malware for the purpose of analysis and defensive use of that knowledge elsewhere in the enterprise. There are web-based honeyclients and other forms of honeyclients available as well.11
Honeytokens
Honeytokens are any form of bait that falls outside the traditional server/client model. A common form of honeytokens is a file that contains fake data that is attractive to the attacker. When used by the attacker, this file alerts the defender to their presence. For example, imagine a file called passwords.txt that sits in the root directory of a user on a honeypot system. The file contains fake accounts and fake passwords that do not exist. However, the attacker does not know that when they try to use those accounts, and an alert is fired off in the enterprise’s Security Information Event Management (SIEM) system, notifying the defender to the attack. A great open source resource for generating and tracking honeytokens is canarytokens.org.12 Another great open source project providing honeytokens to be deployed in a Linux environment is honeybits.13
Deployment Considerations
When you’re deploying honeypots, a few things should be considered. First, the honeypot should look as real as possible and thus attractive to an attacker. The level of verisimilitude—the appearance of being real—will make the difference between catching an attacker and wasting your time, or worse.14 After all, if an attacker discovers you are running a honeypot, don’t expect them to be kind. At best, they will simply leave; at worst, they may start deleting things—and not only on your honeypot. Therefore, great care should be given to the realism of the honeypot, particularly if it’s placed in a production environment. For example, if the honeypot is supposed to be a Linux system, then don’t run Windows services, and vice versa. Further, if the attacker gains access to the system, leave them something real to find, such as honeytokens or other realistic user-level documents and configurations.
Second, where you place your honeypot will make a difference. When considering an Internet-accessible honeypot, you may ask yourself whether SCADA (supervisory control and data acquisition) services would really be hosted in Amazon AWS IP space. When you’re considering an internal honeypot, the configuration and services running should blend into the environment where you place the honeypot. If the entire enterprise is running Windows, except for one host, what would you suspect as an attacker? Also, if there are user VLANs and server VLANs, then host-based honeypots, with few, if any, services, should be found in the user VLAN and server-type configurations with multiple but realistic services should be found in the server VLAN.
However, for the security researcher, there is another alternative. When using honeypots in a nonproduction environment, for the purpose of research, you may be more liberal in spreading your net (or honeynet), so to speak. By running one system on the cloud with multiple ports open (ports that don’t even make sense together), you may certainly deter a sophisticated attacker, but the latest variant of a worm will happily connect and donate a sample binary specimen for you to analyze. You see, it all depends on your purpose in establishing a honeypot in the first place.
Setting Up a Virtual Machine
You may decide to install your honeypot on an actual full operating system, but you will likely want to benefit from the protections afforded by a virtual machine, in terms of snapshots, significant isolation from the host, and virtual network settings. In this chapter we use 64-bit Kali Linux 2017.1, running in a virtual machine, to take advantage of Docker. However, you may also decide to run your honeypots within the cloud, on Amazon AWS, Digital Ocean, or a similar platform.
NOTE See the “For Further Reading” section for a reference to setting up Ubuntu 16.04 on Amazon AWS, but user beware: do not violate any user agreements of Amazon or your hosting service. You have been warned.
Open Source Honeypots
In this section, we demonstrate several open source honeypots.
Lab 21-1: Dionaea
In this lab, we investigate the Dionaea honeypot, a lightweight honeypot that emulates several services.15
NOTE The labs in this chapter require 64-bit Linux, as Docker does not support 32-bit operating systems. We use 64-bit Kali 2017.1, if you want to follow along.
First, set up a folder to transfer files off the Docker:
Pull down and run the Dionaea Docker image:
Now, from the new shell of the container, let’s make some changes and enable logging:
Next, let’s enable stream capture of sessions in the dionaea.cfg file:
Now, enable the processors:
Now, let’s launch it:
Open another terminal session to Kali and, from that new shell, attack the honeypot with Metasploit:
Notice that the exploit from Metasploit failed. However, that was expected since we are running a low-interaction honeypot. The payload was transmitted and captured, though, which was the point of this lab.
Now, from that second Kali shell, connect to your honeypot with FTP, as shown next. If you have a new install of Kali, you will have to install FTP first.
Now, let’s look at the logs. From the honeypot shell, press ctrl-c to stop the honeypot and then view the logs as follows:
Binaries may be found at
and streams of session data may be found at
NOTE Because our honeypot is running in a Docker, the files are not persistent. Therefore, if you want to further inspect a file, you need to move it to the shared folder we set up. From within the Docker container, use tar to copy files to the /data folder, which maps to our working directory on Kali, as follows:
Lab 21-2: ConPot
In this lab, we investigate the ConPot honeypot, which emulates an ICS/SCADA device.16
Again, make a directory, this time to hold the logs (another common use case):
Now pull and run the ConPot honeypot:
Now, from another Linux or Mac shell, run snmpwalk against the host:
Open a web page and view the web interface, shown next. Be sure to click Refresh a few times to see the changes.
NOTE The system name and other fingerprint items may be adjusted in the templates directory of the source files. It is strongly advised that you change these; otherwise, you will not have a very active ConPot.
Logs may be found in the shared folder:
Lab 21-3: Cowrie
In this lab, we pull and use the Cowrie honeypot, which, as described by the author, is a medium-interaction honeypot,17 capable of emulating SSH and Telnet and, most importantly, capturing each command. It is also able to replay the key sequences for an entertaining view of hacker activity.
Clone the honeypot GitHub repository, and then configure, build, and run the honeypot:
Due to the fact that this particular Docker image sets the username as “cowrie” and because we don’t want to set up a shared folder that’s world writable (so that users can write to logs), we will use the Docker volume functionality this time. Set up a Docker volume, as follows:
Now, confirm creation of the volume and check its location (to be used later):
Build the Docker image and run it:
As you can see here, the ./run.sh script runs the honeypot on ports 2222 (SSH) and 2223 (Telnet). You may choose to run these on their normal ports, 22 and 23, but you will need to move any real services running there. For example, to change SSH to another port, edit /etc/ssh/sshd_config, change the port setting, and issue the following command to restart the service:
From another Linux or Mac shell, interact with the honeypot. You may log in using root and any password besides root or 123456:
Notice that the system only appears to download a file (it is not really there, the file size is zero). Press ctrl-c on the Docker instance to stop the container.
Now, one of the neat things about Cowrie is the ability to replay attacks in the same time sequence as the hacker. Using the preceding volume location, pull down the Cowrie playlog script and run it against the tty logs:
Now that’s cool: we see exactly what has been typed or run by an automated bot in real time. The playlog script also has options to slow down or speed up the playback.
Lab 21-4: T-Pot
In this lab, we pull it all together and download and install the T-Pot honeypot, which is an automated install of several other honeypots, including the ones we’ve used in previous labs. Further, T-Pot includes a user interface that’s built on an Elasticsearch, Logstash, and Kibana (ELK) stack.18 The version of T-Pot tested in this lab may be downloaded from the book’s website. The latest version may be downloaded from the T-Pot GitHub (see the “For Further Reading” section).
The minimum system requirements of the T-Pot honeypot are 4GB of RAM and 64GB of hard drive space for the standard honeypot (it may run with less, but these are the posted minimums). The easiest option to run the T-Pot honeypot is to download the ISO image or build your own and then mount it to a virtual CD in VMware or VirtualBox and launch the machine. The ISO is a 64-bit Ubuntu build, as shown next. Again, be sure to establish the minimum settings just given. For limited testing, you can get by with a smaller (5GB) hard drive.
Press ENTER to select the default installer (T-Pot 17.10). You will be prompted to select your language and keyboard. The installation will then begin and will take 20–30 minutes, depending on your system resources. Along the way, you will also be asked some configuration questions, such as type of honeypot (we selected Standard for this lab), password for the tsec user account, and a second username and password for the web interface (do not lose that). When finished, you will be prompted to log in. Use the tsec account and first password you supplied. On the login screen, you will see the IP of the honeypot and web URL, as shown next. Use the second user account you established and password for the web interface.
From another Linux or Mac system, scan the IP with Nmap. Next, open the web interface, using the preceding IP (https://IP:64297), and select the T-Pot dashboard. You will need to place your honeypot on a public Internet connection and/or scan it to see some activity in the dashboards. However, the following screenshot shows the potential of this tool.
NOTE The following two images were used with permission of the developer of the latest version of T-Pot and may have changed in format or functionality by the time of this book’s publication.
Scroll down to see further details.
The web interface has several tools, including an Elasticsearch head (starting point for searches), shown here.
Another tool is the SpiderFoot search page, which allows you to find out information about attackers.
Also, the web interface includes a Docker container UI, called Portainer, that allows you to control the Docker containers (for example, Dionaea, shown here).
You may also interact by shell with each container, as shown next.
Also, a Netdata page shows vital server information, which seemingly scrolls down endlessly.
Finally, if needed, you have full access to the web console via Wetty, shown next. For nonlocal access, you will need to upload your SSH keys.
All data is stored in the /data folder, which is accessible from the host.
NOTE To run this honeypot on a cloud-based Ubuntu 16.04 system, simply run the following commands. You will also need to open TCP ports 0–64000 to the public and 64001 and above to your IP (see the T-Pot website link at end of this chapter if you want to be more selective in what ports you expose).
Commercial Alternative: TrapX
When it comes to commercial solutions, you have several to choose from, including these:
• TrapX
• Attivo
• Illusive Networks
• Cymmetria
Each one has its merits and deserves a trial. However, in this chapter, we highlight only one: TrapX DeceptionGrid. TrapX was highlighted in the last edition of this book and was impressive then. Yet it has improved greatly since that time.
When logging into TrapX, you will be presented with a dashboard displaying various forms of data, including inbound and outbound threats, top-10 events, threat statistics, and the health status of workstation, server, and network decoy traps.
When displaying events using the Event Analysis screen, shown next, you may filter events (for example, you might filter on infections).
In order to inspect an event, simply double-click it to see all recorded actions in a kill chain view, as shown here.
Notice how the attacker started the PSEXEC service and created a file (file.exe). You may view the dynamic analysis of that file in a sandbox report that includes behavior, network activity, processes, artifacts, registry key activity, and file-system activity.
Further, as shown next, you may view a static and reputation analysis of that file.
Where things really get interesting is when TrapX is used to emulate SMB commands and allow an attacker to exploit a decoy system, all while TrapX monitors and controls the impact of those commands.
Beyond the classical decoys of Linux and Windows systems, TrapX is able to emulate a wide array of devices, such as Juniper and Cisco devices; various medical, Internet of Things (IOT), and SCADA devices; and financial services like Swift and ATM. For this lab, we enable a Cisco switch, as shown here, but notice the other services available.
When running the Cisco decoy, the attacker may interact with the Cisco command-line interface (CLI) over SSH/Telnet. Further, the decoy sends Cisco Discovery Protocol (CDP) packets that may attract an attacker and divert them into interacting with the realistic but fake web GUI, shown next. Again, all actions taken on this fake GUI are logged and the Security Operations Center (SOC) analyst is alerted.
Also, TrapX can interface with Cisco Identity Services Engine (ISE) and ForeScout to use Network Access Control (NAC) and divert suspicious connections to an isolated deception network for further analysis. See the “For Further Reading” section at the end of this chapter for a link to a video of TrapX diverting Wannacry to an isolated network.
TrapX allows for deception (honey) tokens. For example, a fake network drive may be established on a host (in this case, fileserver004), as shown next. Notice how the fake network drive (R:\) is not visible to the user via the desktop; instead, only the attacker can see it when using command-line tools, which is how attackers normally operate. Also, notice how fake files are presented on the fake network drive.
All of the attacker’s actions are tracked back at the SOC (the fake share mapped to C:\data).
TrapX has web-based deception tokens as well, providing three levels of deception:
• Browser history Fake URLs that look interesting to an attacker
• Browser credentials Fake URL with a fake saved username and password
• Browser bookmark Fake browser bookmark links to a decoy web application
All this information is configurable; for example, the browser credentials are shown here.
This browser data may lure an attacker to a decoy web application, as shown next.
Back in the SOC, the analyst gets an alert, as shown next, because no one is supposed to connect to this site.
One of the most advanced features of TrapX is the ability to safely proxy commands to a full operating system, providing the highest levels of emulation possible. TrapX calls this Full Operating System (FOS) decoy. For example, an attacker might gain a foothold using a phishing e-mail and then find deliberately placed deception token information, pointing to a file share running Remote Desktop Protocol (RDP). The attacker might even run Mimikatz, as shown next, thinking they are obtaining real credentials.
As shown next, the attacker might then use those stolen credentials to establish an RDP session with that full but fake system, whose only purpose is to be touched and provide alerts to the SOC analyst, which matches our earlier definition of a honeypot.
The attacker might not know this is a honeypot because it is a full operating system and might think they have full access to the system. However, they are under the watchful eye of the SOC team, as shown here.
As you can see, the commercial offerings are quite substantial. It is hoped that you are now better informed as to your options and can select a honeypot technology (open source or commercial) that suits your needs.
Summary
In this chapter, we discussed the subject of deception, as it relates to defending a network, using honeypot technologies. We started with a discussion of the history of deception and honeypots in general. Next, we moved to a discussion of modern honeypots, in terms of types and deployment considerations. Then, we worked through a series of labs, using the latest open source honeypot tools. Finally, we took a look at a commercial solution, TrapX, to see an example of what vendors are bringing to the deception battle.
For Further Reading
Attivo Networks https://attivonetworks.com/
Awesome list of honeypot resources https://github.com/paralax/awesome-honeypots
Cymmetria https://cymmetria.com/product/
Good article on controlling and killing Docker containers https://medium.com/@lherrera/life-and-death-of-a-container-146dfc62f808
Good place to deposit malware samples for analysis https://malwr.com/submission/
Good tutorial on manually deploying Cowrie and Dionaea honeypots http://executemalware.com/?p=302
Illusive Networks https://illusivenetworks.com/
Installing Dionaea on EC2 in 40 minutes https://tazdrumm3r.wordpress.com/2012/08/26/dionaea-honeypot-on-ec2-in-40-minutes/
Installing Docker on Kali 2017.1, 64 bit https://gist.github.com/nikallass/e5124756d0e2bdcf8981827f3ed40bcc
Installing Ubuntu 16.04 https://tutorials.ubuntu.com/tutorial/tutorial-install-ubuntu-server#0
Installing Ubuntu 16.04 on Amazon AWS http://mobisoftinfotech.com/resources/mguide/launch-aws-ec2-server-set-ubuntu-16-04/
Modern honey network https://github.com/threatstream/mhn
T-Pot Honeypot 17.10 https://github.com/dtag-dev-sec/tpotce/releases
TrapX https://trapx.com
Ubuntu 16.04 64-bit ISO http://releases.ubuntu.com/xenial/ubuntu-16.04.3-server-amd64.iso
Video of TrapX trapping Wannacry in a honeypot https://vimeo.com/218929440
References
1. “Sun Tzu,” Wikiquote, https://en.wikiquote.org/wiki/Sun_Tzu. [Accessed: 26-Aug-2017].
2. “Operation Bodyguard,” Wikipedia, June 5, 2017.
3. F. Cohen, “Computer Viruses – Theory and Experiments,” IFIPsec 84, 1984.
4. F. Cohen, “A Note on the Role of Deception in Information Protection,” Computers & Security, vol. 17, no. 6, pp. 483–506, 1998.
5. F. Cohen, “Deception Toolkit,” http://all.net/dtk/.
6. K. Johnson, “Hackers Caught in Security ‘Honeypot,’” ZDNet, December 19, 2000, www.zdnet.com/article/hackers-caught-in-security-honeypot/. [Accessed: 26-Aug-2017].
7. “Blogs | The Honeynet Project,” http://honeynet.org/. [Accessed: 26-Aug-2017].
8. L. Pingree, “Deception Related Technology – It’s Not Just a ‘Nice to Have’, It’s a New Strategy of Defense,” Lawrence Pingree, September 28, 2016.
9. D. Katz, “MongoDB-HoneyProxy: A Honeypot Proxy for mongodb. When Run, This Will Proxy and Log All Traffic to a Dummy mongodb Server,” 2017, https://github.com/Plazmaz/MongoDB-HoneyProxy.
10. T. Nicholson, “honssh: HonSSH Is Designed to Log All SSH Communications Between a Client and Server,” 2017, https://github.com/tnich/honssh.
11. “Client Honeypot,” Wikipedia, August 9, 2017.
12. “Canarytokens.org – Quick, Free, Detection for the Masses,” http://blog.thinkst.com/2015/09/canarytokensorg-quick-free-detection.html.
13. A. Karimi, Honeybits: A Simple Tool Designed to Enhance the Effectiveness of Your Traps by Spreading Breadcrumbs & Honeytokens Across Your Production Servers and Workstations to Lure the Attacker Toward, 2017, https://github.com/0x4D31/honeybits.
14. “Verisimilitude | Define Verisimilitude at Dictionary.com,” Dictionary.com, www.dictionary.com/browse/verisimilitude. [Accessed: 19-Aug-2017].
15. “Home of the Dionaea Honeypot,” GitHub, August 9, 2017, https://github.com/DinoTools/dionaea. [Accessed: 19-Aug-2017]
16. “Conpot: ICS/SCADA Honeypot,” GitHub, August 18, 2017, https://github.com/mushorg/conpot. [Accessed: 19-Aug-2017].
17. M. Oosterhof, “docker-cowrie: Docker Cowrie Honeypot Image,” GitHub, July 19, 2017, https://github.com/micheloosterhof/docker-cowrie. [Accessed: 19-Aug-2017].
18. “DTAG Community Honeypot Project,” GitHub, http://dtag-dev-sec.github.io/. [Accessed: 19-Aug-2017].