An unfair game

Defending an IT infrastructure is usually considered as a much harder task than attacking it. And there are two good reasons for this.

First, the attack surface. It is getting huge, and mostly out of control.

The digital transformation pushes more and more data and processes in the cloud. The IT infrastructure is now scattered across multiple cloud platforms and applications. Processes pop up in VMs and containers, disappear and reappear "somewhere" else with no warning and no notifications, while data make sneakily their way to buckets, hosted databases and 3rd party applications.

This is to be combined with the integration of new components that suddenly created connections to the network: entire OT infrastructures, dozens of IoT devices and users mobiles, tablets and home computers. A whole lot of vulnerable devices which can be turned into a deadly Trojan horse in minutes.

Second, an unbalanced game.

The defender tries to keep control of its heterogeneous, vulnerable and dispersed infrastructure with limited human and financial resources. Attackers are countless, and will take advantage of the slightest technical or human vulnerability to gain a foothold and start propagating.

Just like a dam. A single, unremarkable hole may cause the entire structure to collapse and lead to a complete disaster.

And that's where we stand: Relentless enemies looking for the slightest flaw in an uncontrollable attack surface protected by a handful of defenders. A digital version of Fort Alamo.

Meet the decoy

However, the situation may not be that desperate. Indeed, the attackers may be hundred of thousands they are (almost) all the same - at least according to The Mentor 1 - they obey to the least resistance principle.

The trick is to help them finding this weakness in your defense, to the difference that defenders will control and closely monitor any activity related to this vulnerable asset, providing sufficient intel to properly react to the threat.

Roles are then inverted. Any mistake from the attacker will immediately lead to termination of the intrusion attempt. And believe me it is hard to make a difference between a real unmanaged vulnerability and a real properly but supervised one. 2

The point is "simply" to lure the attacker, have him spend time on a path that leads to a dead end, and let the defenders take proper action. By setting up a 100% fake component, we ensure that any related activity is malicious, making the work of defenders much simpler. No triage, no correlation, no in-depth analysis. Most of the time, a brainless automated reaction will do the job.

We call: the Decoy

Decoys make it possible to detect different types of malicious operations, such as: reconnaissance, technical or social targeted attack, insider threats as well as spam and malware campaigns.

Moreover, information gathered from these detections can help building different types of blacklist (IP, domains, email, users, phone number, etc.) and generate IoC to improve incident response operations efficiency. It is also an easy, reliable and effortless way to identify the current stage and severity of an on-going intrusion.

The icing on the cake ? It is entirely passive, meaning there is no risk of network or service disruption during the deployment...

Types of decoys

Depending on the goal one wants to achieve, different types of decoys can be deployed. Obviously they are not mutually exclusive and deploying a full set of decoys will dramatically improve the details and quality of detection.

User decoys

A user decoy is a fake user in the organization, with a relevant social profile, a real corporate email address and an attractive role (VP, sysop, CxO PA, etc.). The more visible the user is, the more likely it will be added to spam and phishing campaigns lists. The more consistent and realistic the user will appear, the more likely it will be targeted by BEC and social engineering attacks.

Properly coordinated with security tools, such decoy will make it possible to timely prevent most of human flaw-based attacks, and identify that you may be targeted by some threat actor.

Infrastructure decoys

At the infrastructure level, the decoy is a fake network that seems to lack of some (not all, this would make the trap too obvious) security requirements, such as loose firewall rules. Any incoming traffic is suspicious, making it trivial to detect the reconnaissance and scanning phases of an intrusion.

The first step of the setup is to reveal the access point. The easiest way is to create interesting DNS entries such as admin.mycompany.com. This could be a good bait. Additionally, generating certificates for those entries will improve visibility to those conscientious hackers who want to make sure this is for real.

Second, setup the infrastructure. A decoy network doesn't have to be real. A single host, running multiple VM can easily simulate a small LAN with a dozen of potential targets. At a larger scale a cloud-based infrastructure on a separate VPC, tenant or cloud platform, with real compute resources will even look more appealing. And remember, one of the defenders' pain points is the spread of assets across multiple cloud infrastructures. Finding a network on a different cloud provider platform will not look suspicious to the attacker.

Third, monitor. Any connection, successful or not is suspicious. So is the source IP address.

Resource decoys

Two types of resources are to be considered: processing and data.

Both of them can be deployed either in an entirely fake infrastructure or within the protected network. The first case is useful to make a decoy infrastructure look more real, while the latest make it possible to identify the current stage of an on-going intrusions, and detect malicious internal activity.

Processing decoys are fake components deployed to artificially populate an environment. It can be fake servers, Pods or serverless functions exposing vulnerable OS and services. On top of making it possible to detect and stop an attack at early stage, they may reveal unknown vulnerabilities, exploits, payloads and evasion techniques.

Data decoys are specific components which have no legitimate reasons to be accessed. It can be a container (directory, cloud bucket, database) or a specific content (file or database table). Again, any monitored activity upon these resources is malicious and should trigger appropriate reaction. Another benefit from these type of decoys is that it provides information about the depth of the intrusion. Access to a database table, hosted on a server running in a highly sensitive zone clearly indicates that the infrastructure is badly compromised, while the listing of a publicly accessible cloud bucket warns about a potentially targeted attack intent.

Application decoys

The main goal of an application decoy is to have the attacker waste time, while defender prepare reaction to the intrusion. It can be a standalone appealing application, such as a network admin Web UI or a database named "customers", or a service running on a real server along with other applications. This last one will definitely look more real, but has some drawbacks.

The time spent by an attacker on such fake application depends on the level of interaction it provides. A single login page leading to nothing will most probably keep the intruder busy for a few minutes. Now if this page, after few brute-forcing effort, leads to a network management page or a VIP user directory, then the game reaches another level. Because all the information gathered is 100% fake, the attack will probably be diverted from its original path, and the attacker will spend hours or days investigating an illusionary infrastructure.

Beware of backfire

Unfortunately there is no silver bullet in security, and it is always important to be aware of potential drawbacks. The main one for decoys is the risk of having a resource or application decoys used as an attack platform inside the protected infrastructure. Indeed, having a vulnerable system or application running makes it possible to detect intrusion attempts, gather exploits and generate IoCs. In the meantime it provides the attacker with a bridgehead, either to get deeper into the network, or attack other infrastructures, the decoy becoming a relay.

This implies that decoys remain closely monitored and properly isolated from their environment, by limiting as much as possible the authorized outgoing connections.

Another key topic is logging. It is not recommended to perform logging on or from the decoy. Local logging (if much more detailed than the usual defualt one) will easily indicate to the intruder that their target is under heavy monitoring. Remote logging will provide information about some security infrastructure components, such as the SIEM or log server. That's why monitoring should definitely be performed via a network tap or an inline device.

Last, a vulnerable application component running on a real server may effectively be used to take control of the server. It is then imperative to entirely isolate the application, and that remains a challenge...

Conclusion

Decoys can be a game-changer.

When attackers could launch broad scope attacks with impunity, a properly set collection of decoys will help stopping them even before they think of going further. They are also very efficient in identifying and preventing complex attack scenarios, especially when they involve insiders or social engineering.

Hacking game is no longer a bloody brainless FPS, it turns now into a mime sweeper, without indication of the number of mines surrounding your position.

Attackers and defenders are now playing with the same rules. The slightest error on either side and it is Game Over.