Deception technology provides a unique approach to detecting adversary activity in a network. Compared to other detection controls, it’s easier to deploy, gives you greater visibility, and solves your false positives problem.
Let’s cut to the chase, shall we? Of course, I’m going to say this. I work for a company that sells a deception solution. I’m quite sure that if you’ve ever spoken to a deception vendor, you would have heard a similar pitch. If you haven’t talked to one, well, that’s more or less what you’re going to hear in a nutshell.
While what I’ve stated above is accurate, there are nuances to every approach. As they say, when it comes to cybersecurity, there are no silver bullets. I’m writing this post because when you’re evaluating technology or deploying it, you must understand the conditions under which it can be effective. It allows you to be pragmatic and set realistic expectations.
In the next couple of paragraphs, I’m going to delve into nuances of deception technology that often don’t make it to marketing materials.
Visibility, realism, and fingerprinting – The deception trifecta
As with any security control, there are several components that come together to make deception effective. For now, I’m going to focus on the three most important properties that can make or break a deception technology deployment. These are:
- Visibility: The deceptive component/decoys must be visible to none but the adversary so that they lead to detection without raising any false positives.
- Realism: The deceptive component/decoys should be indistinguishable from your real assets so that malicious actors can’t tell the difference between what’s real and what’s fake.
- Fingerprinting: The deceptive component/decoys should not exhibit any property that would reveal their true nature resulting in the adversary not interacting with them.
In an ideal world, every deceptive component should exhibit all three properties in totality. The reality, however, is different.
Some decoys will be visible to folks inside your company but will be a popular target for attackers. Some will have limited realism but will not be fingeprintable. The point is, when you’re deploying deception in a living, breathing network, trade-offs have to be made – sometimes because of internal limitations, and other times because that’s the best strategy.
In my experience, an understanding of these three properties helps in deciding what trade-offs to make and what you can expect. Let’s break them down one by one.
Visibility is an important consideration when deploying deceptive components. In organizations, highly visible decoys will lead to false positives and noise. However, the decoys themselves may be the only effective way to detect an adversary. Being aware of different deceptive components and their visibility property can help inform your thinking about what to do. Here’s a handy table.
|Component||Visibility to regular users|
|Private Threat Intelligence (Internet-facing decoys)||Not visible|
|Internal network decoys||Not visible|
|Active Directory decoys||Not visible|
|MiTM Deception||Not visible|
|Endpoint Deception – File Decoys||* Invisible unless the user chooses the option to show hidden files. |
* The Endpoint deception policy allows file decoys to be hidden to make them invisible to regular users.
|Endpoint Deception – Browser Lures||* Cookies are invisible to the user.|
* Credentials may be viewed if the user browses to the Saved Password page.
* Browser Favorites will be visible to the user.
|Endpoint Deception – Session Lures||* Network Shares and Windows Credentials are placed in Credential Manager and rarely accessed by regular users and are therefore effectively invisible.|
* Session Lures created for software like PuTTY and WinSCP will be visible in the panel of saved sessions.
|Endpoint Deception – Privilege Escalation||Not visible|
|Endpoint Deception – Defense Evasion||Effectively invisible. Fake Processes are visible in Task Manager but they masquerade as a real process and hide in plain sight.|
If an adversary can fingerprint your deceptive assets, she will be able to avoid them altogether. That can’t be good, can it? Here are a couple of things to consider when looking at deception solutions to figure out if they’re fingerprintable.
What are the characteristics of the decoys?
For decoys deployed to the network, network characteristics can result in fingerprinting. While it’s relatively easy to fake characteristics like MAC addresses, Hostnames, and IP addresses, NetBIOS names are harder to spoof as they are tied to the machine itself.
Are they high interaction?
All deception components have a limitation to the extent to which they fool an adversary. However, it’s important to test whether interacting with a deception component gives away large portions of your deployment. If decoys are created using multiple virtual network adapters from a single machine, it is likely that once you login to a decoy and run “ipconfig / ifconfig”, you will be able to figure out all the decoys projected from that host.
Test open-source fingerprinting tools
Open-source fingerprinting tools like HoneypotBuster, attempt to fingerprint deception in active directory and fake credentials in memory. We recommend testing these tools, especially on computer objects in Active Directory as they contain properties that cannot be easily modified in a deception scenario. Also, tools like HoneypotBuster check only the domain from which the tool is run and will not check domains that are trusted in any way. Ensure that you run the tool against the domain where the deception has been configured in Active Directory.
The realism of a deception component is critical to keeping an attacker engaged. Ideally, the component should be real enough that it allows the adversary to reveal tools, tactics, and techniques that are being used in your environment. It should also provide you with enough telemetry to determine what the next steps should be.
The overarching goal here is to make the deception component real enough to engage the adversary for long enough so that you can respond to the event.
Here is some guidance for ensuring that the deception technology components you opt for meet the realism criteria:
- Services like SSH, File shares, and FTP servers that are popular targets for attacks should be individually unique. Every set of decoy services should be hosted on their own individual machine. At Smokescreen, we call this one-to-one decoys.
- Ensure web applications can capture credential inputs and web app attacks. Also, check if these applications are interesting to an adversary.
- For credential lures, ensure you have options to make passwords realistic and look like they could belong to your organization.
- For file lures, ensure you can inject passwords into files as password files are the most common targets.
- Ensure your deception agent can be hidden from other running processes.
- Ensure your decoy active directory entries are consistent with other entries in your Active Directory in terms of the properties with which they are configured.
When evaluating deception technology, visibility, realism, and fingerprinting should be some of the key components that you should closely look at to figure how the solution will play out in your network.
Using deception to shield the insurance sector
Finding active defense opportunities in a pentest report
Four MITRE Shield Techniques You Can Implement in 2021
- Detect zero-days, APTs, and insider threats
- 10x the detection capabilities with 1/2 the team
- Get started in minutes, fully functional in hours