Introduction
Many articles have been written about Deception. It is not surprising as deceptive technologies have been taking over the cyber security world in recent years. In the recent Gartner report Deception was named as one of the most effective information security technologies: according to experts, it is almost at its peak and is expected to reach the plateau in the horizon of 5-10 years. We decided to fantasize about what it would be like if there was some “ideal solution” in the market that combines all the features of modern cyber deception technologies.
In this series of articles, we have compiled a summary list of Deception’s features present in these or those solutions. And here we will not go into technical details, our goal is to help readers take a broader look at cyber deception technologies and their possibilities, especially in terms of a defensive strategy, and choose their own “golden standard” for themselves.
Architecture and delivery options
Let us start with the basics: the architecture and possible product delivery options. Architecturally, Deception solutions traditionally fall into several classes:
- On-premise solutions, fully deployable on the customer’s equipment;
- Predominantly on-premise solutions with some functionality implemented in the form of cloud services or vendor services;
- Hybrid solutions: on-premise solutions can be deployed but if cloud platforms need to be protected, part of the solution can also be deployed in the cloud;
- Cloud solutions deployed entirely in their cloud (analogue to on-premise but for cloud platforms);
- Mixed cloud solutions. For example, trap modules and the control center are deployed in the cloud, while analytics or false Active Directory entities are already deployed in the vendor’s cloud and just need to be connected.
When it comes to delivery options, they may depend on the chosen solution architecture but are usually fairly typical as well:
- Preconfigured virtual machine image (OVA);
- Distribution software that allows installing the solution on the existing infrastructure (often found for operating systems of the Windows family);
- Hardware and software complex, which comes with preconfigured hardware.
The choice of a suitable option is usually closely related not only to the solutions used in the company but also to the legal requirements or security policies of the organization. It should be noted that AWS, Azure, and GCP are mainly supported as cloud platforms.
Now it is time to set traps and decoys! Vendors use various names for traps and decoys (Lures, Decoys, Honey Tokens, etc.). To avoid confusion, we will refer to them by the terms “trap” and “decoy”.
Types of Traps
Traps are false network nodes allowing one to detect an attacker and most importantly, to distract him from real nodes by slowing down the lateral movement within the network. These can be emulated workstations, network equipment, servers, and various services. Historically, since the days of Honeypot, traps have been divided into 4 main types:
- Low interactive traps;
- Medium interactive traps;
- High interactive traps;
- FullOS.
The degree of interactivity determines the level of the plausibility of the trap, however, there is a direct correlation here. As the old duck test goes, “If something looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.” In the case of traps emulating databases or other heavy services, it also consumes the same or even more (due to detailed logging) resources.
Let us take the SSH trap as an example. In all cases, events from the traps are immediately sent to the management console:
- At the low interactivity level of the SSH trap, the system may only offer the possibility to authenticate but it will not be possible to log in. The necessary client fingerprints, keys, login/password pairs, etc. will be collected.
- At a medium level of SSH interactivity, the SSH trap can be similar to a restricted shell. In this case, an attacker can successfully log in, but the list of commands will be very limited.
- At a high level of interactivity, the trap will contain various processes and users’ home folders. Some traps will limit the possibility of establishing a further SSH connection, so as not to become an intermediate host for an attack to develop.
Depending on the level of interactivity, the system can be practically indistinguishable from the real thing, while integrating with various sandboxes to send payloads uploaded to the system when an attacker tries to elevate privileges or bypass authentication tools.
The debate over how interactive a trap should be has not subsided to this day. Here, you should rely upon specific goals in mind. If your goal is just to quickly detect an attacker, a low-interactive trap may be enough. If you want to investigate his behavior in more detail, as well as slow down the lateral movement across the network, the best solution is to add highly interactive traps.
Here, however, you should be careful when using popular emulation systems. The authors of one of the most popular SSH and Telnet Cowrie emulation systems in 2020 made the following edit: “Rename built-in user richard to phil, it’s used as detection mechanism”. Obviously, since then, the detection mechanism has also been slightly amended 🙂
What kinds of traps can today’s Deception solutions offer? Almost any! The choice is limited only by the customers’ imagination and the vendor’s desire to implement it. One vendor once made a trap in the form of a network-controlled lightbulb by a popular manufacturer because the customer’s infrastructure used them and there was a need to emulate them.
The following types of traps may be present in today’s solutions:
- SMB file resources of varying degrees of interactivity. This may be a low-interactive emulation, where an attacker can only see a list of available shared folders, without being able to access them (such traps are good against scanning malware or an internal user with Kali). More interactive traps already support SMB 2.0/3.0, can dynamically change their contents, and integrate with sandboxes to check the content uploaded to them.
- FTP/TFTP/SFTP servers. Like SMB file traps, these can have varying degrees of interactivity and are usually implemented based on off-the-shelf FTP or SSH solutions.
- Databases (MySQL, PostgresSQL, MSSQL, Oracle). Database emulation is the most interesting task – each vendor is looking for its facet. And if Open Source can be simply forked and packed into a trap, it does not work like that with Oracle… Therefore each vendor chooses its degree of interactivity: from simply repeating the protocol format for authentication to a blank response to all requests like “Request returned 0 lines”.
- Active Directory traps. These are specialized traps to detect things like LLMNR attacks, Kerberos attacks, and Pass The Hash attacks.
- Remote access to VPN services (OpenVPN, IPSec, l2tp). Because of the pandemic and the massive transition to remote working, this type of trap became especially in demand, and many manufacturers started to actively add it to their portfolios.
- Routers and other network equipment. These traps are divided into 2 categories – the web interface of the equipment in which all the details of the interface can even be repeated and settings can be made and statistics can be viewed as well as the SSH interface, which in some way emulates the interface of real network equipment.
- Web Services. Emulation of real internal resources, starting, for example, with Outlook Web Access login form and ending with the possibility to clone the login form of any internal self-written system and several typical pages.
- RDP/VNC systems. Traps that emulate various remote desktop management systems. They are usually low-interactive, however, these same services work well in FullOS traps, where their full-fledged implementation is ensured, so, if a full-fledged OS is available, many vendors recommend using these services in it.
- Printers and MFPs. Emulation of various printing protocols. More advanced versions are bundled with the printer’s web interface, allowing to create a full-fledged emulation.
- Emulating SCADA and IoT devices is a difficult task: there are many protocols and they are very different. There is a number of deception systems that specialize in IoT and SCADA emulation. Many vendors necessarily have this functionality on their list.
- IP phones. A separate class of traps that emulates IP-telephony endpoints. You can’t call them but you can get a web, ssh, or SIP interface.
- CI/CD systems. Imitation of popular systems like Jenkins or GitLab.
- iLO/iDRAC/Server Management. Specialized traps for emulating server hardware management systems.
- Mail Traps. Imitation of popular SMTP, IMAP. POP3 protocols.
- Private Cloud emulation. There’s a whole OpenShift/Docker/k8s emulation spectrum here.
- Trap generation for popular and current CVEs. “Vulnerable” services are created in advance in order to arouse the attacker’s interest in those nodes as much as possible.
The list of possible traps does not end there. Many manufacturers have a special set of traps for Active Directory, macOS, and Linux-based networks in their arsenal. We recommend this repository as an interesting project, a compilation of popular traps with an emphasis on Open Source.
FullOS traps
FullOS traps are used to deploy systems that are difficult to emulate for one reason or another. As their name suggests, these are full-fledged operating systems turned into a trap for the Deception platform, and they do not differ from real systems except for the presence of detailed logging. Most often they are RDP servers, specialized banking automated workstations or automated process control systems.
Identity with the machines used in the organization is vital for FullOS, that’s why they are most often made of Golden Image. This makes it possible to solve, among other things, the issue of licensing such an OS. During its deployment, keylogger services and event log monitors are added to it, and logging tools are configured in more detail.
Some manufacturers allow the installation of a low-level rootkit driver that hides the presence of third-party software on the machine as much as possible and integrates with virtualization tools, for example. This allows the implementation of additional functionality such as:
- Keyloggers that collect all of the attacker’s activity;
- Automatic creation of snapshots or memory dumps for further analysis;
- Return (rollback to reference point) after an attack or a visit by an attacker;
- Collection of full-featured forensics from the node.
Each manufacturer chooses by itself the level of concealment. During one of the roundtables, one manufacturer lamented that it had invested so much in hiding its software but the attackers never got to that level…
Types of decoys
With the traps dealt with, it is time to lure the attacker into them. To do this, Deception solutions use decoys. Decoys are information pieces laid out in the most popular places for attackers to look for opportunities to move horizontally, which will lead them into a trap.
Popular types of decoys include:
- Various AD user credentials;
- Various RDP/VNC remote desktop connections files;
- HOSTS file entries;
- Saved connections to network resources and printers;
- Command history in BASH and PowerShell;
- History of browsers and their password storage;
- Saved data in browsers;
- Network connections to SSH/FTP clients;
- Settings of popular software stored in the registry;
- Test files with “forgotten” passwords;
- Password managers files like KeePass;
- And, of course, password vaults like MS Vault, LSASS RAM, and workstation login caches.
Here it is important to keep in mind that the decoys must be fully compatible with the customer’s infrastructure. We will talk about realism in a separate section but unless the machine is running, say, Putty, it is usually not a good idea to add an entry/decoy for it to the registry, nor to put configs for other popular software.
Hybrid solutions can use hybrid decoys, such as keys for AWS or Google, that lead to traps in the cloud.
Some vendors use documents with special pixels inside, which then allow tracking where such a document was opened and whether it was taken outside the perimeter, although there is still debate about the operability and usefulness of such functionality. For example, few experienced attackers will open documents outside the sandbox, and even with Internet access. But this will allow catching not very experienced insiders, as Deception solutions also have such functions.
In the next article, we will describe how to use Deception technologies to create and place the most realistic traps and decoys in the infrastructure, as well as what functionality differentiates them from the usual honeypots.