A Guide To Cybersecurity Deception Techniques

Using “low-hanging fruit” cybersecurity deception techniques to entice an attacker that has already infiltrated an environment will offer even more opportunities for early detection — and in turn, will help to increase your organization’s defensive strategy.

Deception, adjective: a statement or action that hides the truth, or the act of hiding the truth.

In cybersecurity, when someone hears the word deception, often the first thing to come to mind are the actions of the attackers. After all, it is worth the effort to work on becoming more deceptive to be able to infect more systems, or exfiltrate more data for longer periods of time without being detected. However, the same principles can be applied to using deceptive techniques for the purpose of baiting and detecting attacks on an environment. Along with the deception comes the detection. 

Tripwire, noun: A mechanical assembly designed to detect an anticipated type of target, and to trigger an apparatus that acts upon or records information about that target.

Concepts like these have been around for countless years, and not restricted to only cybersecurity. Thinkst Canary, a company that specializes in active deception techniques, points out that NPR covered a story about a 1930s mapmaker who added a fake town to prevent map piracy at the time. Tripwires have been around for centuries being used in hunting and trapping, during wartime, and in security systems. The earliest tripwire systems were attached to bells instead of a modern alarm. When the wire triggered, it would pull on the bell, causing it to ring and notifying anyone nearby that intruders were in the area.

Cybersecurity Applications

There are many different ways to implement deception techniques and tripwires in an organization, all depending on what the environment contains and what the goal of the deception is. The goal should never be a legitimate “booby-trap” as no one is attempting to hurt or injure the attacker (other than maybe their pride after being detected), but the concept behind them remains the same. We’re putting a trap of some sort to entice an attacker into easier detection for the greater good. 

There are a great many software applications, scripts, and techniques that provide some type of service around deception and detection. Most of the time, these tools are called Honey ’insert something here’ as the general idea of a “honeypot” is the collective naming scheme. 

• Honeypot  The generic security mechanism that is meant to lure in an attacker for either an early detection alerting system or as a research device.
• Honeynet – A collection of honeypots and other deception techniques.
• Honeytoken – A piece of data that is used to lure in an attacker, such as API keys, database entries, executable files, and keys to cloud resources (e.g. AWS key).
• Honeycred – A username or ID that is used to identify specific types of attacks on systems.
• Honeyport – A job that listens on specific TCP Ports. When a connection is established, it can either simply log or add a local firewall rule to block the host from further connections.

Honeypot Design and Implementation Best Practices

First and foremost, monitoring is key! Any type of honeypot without very strict controls and monitoring just ends up being another possible attack vector that threat actors could maliciously leverage. Many solutions have monitoring of some sort already configured, however sometimes more manual implementations of something like a honeycred would require specific monitoring on other systems. Testing the honeypot would show if the necessary monitoring has been configured correctly. 

Find a strategic location. Can you just stick a honeypot anywhere? Sure! However, planning out the location on the network and in your environment can provide much more meaningful data. For example, if the honeypot is going to be used strictly for an early detection system and not for continuous research on emerging security threats or trends, then it probably shouldn’t be directly connected to the internet. There are scripts and scanners that will constantly run attacks against it and actionable alerting would become near to impossible among all of the other noise. 

Ask yourself, ‘Would this look too good to be true?’ When designing and constructing any part of your honeynation™️ (a term I’ve just coined combining honeypot + implementation/nation), make sure to make sure that in the end, it doesn’t look too enticing to the attacker.

Ask yourself, ‘Does it look too much like an easy target?’ If an attacker sees open plaintext ftp, http logins, and a bunch of sensitive files all on the same device, they’ll stay far away from that information. 

Also ask yourself, ‘Does the honeypot look like it was just set up yesterday?’ What’s even worse is that now they will be more vigilant that honeypots of other types may be in use in the environment. 

Keep it real. Do you have an environment that is fully patched and all on the same versions of Windows? Well then, a fully segmented Linux server with a bunch of open ports not only violates rule #1, but it also doesn’t fit into the environment very well. Take that Linux honeypot and put it with other Linux servers, add PortSpoof to have it act a little more like an active server. There are always going to be ways that an attacker could potentially figure out they are dealing with a honeypot, but hopefully by that point, one of the detections have fired.

Refresh the environment. If someone — whether that person was a penetration tester or attacker — accessed the honeypot, it stands to reason that they could share that information. It isn’t a sure thing anymore that the honeypot will be stealthy enough to catch the next person that comes along. Don’t let your cover be blown! Refresh the IP address, location of the device on the network, and settings on at least a yearly basis.

Detection Wins

Detections that go above and beyond a standard honeypot deployment can include:

Kerberoasting. Threat actors can abuse the Kerberos protocol to recover passwords related to service accounts using a tactic called Kerberoasting. In a Windows domain, the authentication protocol Kerberos uses a Ticket Granting Ticket (TGT) to request access tokens from the Ticket Granting Service (TGS) for specific resources/systems joined to the domain.

In Kerberoasting, threat actors abuse valid Kerberos ticket granting tickets to make a request for a ticket granting service from any valid service principal name (SPN) within your Microsoft Active Directory domain. These ticket granting services are vulnerable to offline password cracking, which can allow a threat actor to recover the plaintext password of the associated service account mapped by the SPN.

To avoid false positive detections, you can create a service account honeypot (honeycred) to detect Kerberoasting.

Microsoft Defender for Identity Honeytoken Activity. With the addition of Microsoft Defender for Identity (previously Azure ATP), you can manually tag honeytokens within the console, making it easy to detect through their console when there is any use or attempted use of the tagged assets.

Blumira Honeypots. Blumira makes deploying honeypots easy. Instead of having to worry about deploying an entire server and configuring it, they can be deployed to any sensor in a couple of minutes. So whether it is an addition to your current…wait for it… honeynation!!! Or the honeypot you rely on, it makes a quick win for any environment. 

Additional Resources

• Free Kindle – Offensive Countermeasures: The Art of Active Defense eBook: Strand, John, Paul Asadoorian, Ethan Robish, Benjamin Donnelly: Kindle Store 
• Detecting Honeypots and other suspicious environments
• Honeypots: How do you know when you are inside one?
• Honeypots and Limitations of Deception