Diving into the essence of deception technology

You have probably heard about honeypots -- bait targets used to attract and detect hackers. In recent years, this technology has been upgraded and is now collectively called Deception.

Today, deception technology is represented by quite a few vendors. The most famous are Illusive Networks, TrapX, Fidelity Security Deception, and Cymmetria. In this article, I plan to talk about deception technology from the developer's point of view and tell you what makes it interesting. But first, let us talk about the forerunner of this technology -- honeypots.

Honeypots

Honeypot can be considered the first incarnation of deception technology. They appeared back in the late eighties and early nineties. A honeypot is a network entity whose sole purpose is to attract a hacker and be attacked. Honeypot has no other aim or value in the network. There are no legitimate network interactions with it.

When the honeypot is attacked, it identifies the attack and registers all the attacker's actions. In the future, this data will help to analyze the path, tools, and methods used by the attacker. A secondary goal of a honeypot is to delay the attacker's progress through the network, forcing him to spend time studying a fake object.

Honeypot can be a full-fledged operating system that emulates an employee's workplace or a server, a separate service, or even a backup disc or files.

However, honeypots have a number of disadvantages:

• You need to configure each false server separately.
• Honeypots do not interact with each other and with elements of the real infrastructure, so they leave no traces. Actually, it is not easy for a hacker to find honeypots.
• Honeypots, as a rule, are not united in a centralized system.

This technology was gradually replaced by another, more advanced and smarter one.

The essence of deception technology

Deception is close to intrusion detection systems (IDS). The primary purpose of such a system is to detect unwanted network access attempts. In other words, the deception approach helps detect network attacks.

What is the difference between deception and honeypots?

As already mentioned, a honeypot is a separate network object that does not interact with anything else. It only waits for attackers to record their actions. Deception, on the other hand, is a centralized system for managing false network objects, which are often called traps or decoys. Each trap is, in fact, a separate honeypot, but they are all connected to a central server.

Deception solutions usually have a convenient interface for managing traps. The operator can create traps with the preferred set of emulated network services, in the selected subnet, with the preferred method of obtaining an IP address, and so on.

Traps and the services emulated on them maintain a permanent connection to the server. Like honeypots, traps do not provide for legitimate network interaction (except for interaction with other deception components).

The trap will report to the server any attempt to interact with it. This serves as an indicator of an attack. In this case, the operator can instantly receive all the details of what happened: the address and port of the source and target, the interaction protocol, the response time, and so on.

Additional modules within deception can also provide manual or automated incident response capabilities.

The concept of deception may include other things. Some components simplify setup and help automate deployment, others make traps more like real network services, and still, others draw the attention of hackers to false objects or data. Some components can perform related tasks, such as responding to incidents, collecting indicators of compromise from workstations, and searching for vulnerable software.

Agents

An agent is a program that is installed on user workstations or servers. An agent is able to communicate with the deception server, execute its commands or transmit useful data to the control center.

Among the deception solutions, there are both products that include an agent and those that do without it.

The tasks of an agent may include:

• Collection of data on the status of workstations.
• Distribution of lures.
• Emulation of network activity.
• Incident response (manual or automated).
• Data collection for forensics.

It makes sense to make the agent's activity hidden from the person who works at the computer. What for? First, the user may intentionally or accidentally remove the agent or its components. Secondly, the presence of unknown (or known to a certain extent) software on the workstation can cause discomfort. Thirdly, everything that the user sees will be seen by the attacker who has gained access to this computer. But we do not want to show our trump cards to the attacker, right?

Therefore, deception solutions containing agents should be made in such a way that the user does not see either the agent or traces of its activity.

For this, agents usually operate in privileged mode, as a driver for Windows or a kernel module for Linux. This allows, for example, interception of system requests to ensure stealth and also prevents the user from removing the agent or preventing it from working.

Mimicry techniques

The goals of deception as technology are to convince an attacker that all the traps and interactions between them are natural, important in this particular infrastructure, and actively used, thus making traps attractive to attack. In modern systems, several components can help achieve these goals.

Lures

To make the attacker more likely to stumble upon a trap, you can push him to do so. How? To do this, deception solutions use baits or lures.

A lure is an object placed on a real workstation, either discreetly or not. The lure looks like something ordinary and attractive to an attacker. It can be an "accidentally" forgotten password file, a saved session, a browser bookmark, a registry entry, a mounted network drive with backups, etc. The lure contains a link and data to access a fake network resource.

An attacker, having found such a link and authorization data, usually wants to check what kind of service it is. He enters the trap, and the alarm goes off about the incident.

The types and methods of placing the lure depend on the type of trap to which the lure leads.

Lures can be distributed in several ways. If agents are present in the deception solution, the task of scattering lures is assigned to them. In this case, the process can be easily automated. The control server sends a command to the agent, and the latter performs the necessary actions to install the lure.

If there are no agents, the deception solution may offer ready-made scripts that will need to be manually executed on workstations. This approach has some drawbacks. For example, when reconfiguring traps, there is no way to update lures on workstations automatically.

The interaction of real PC users with lures should be limited. However, it is impossible to hide false targets completely. If an attacker cannot find them, why put them?

And, of course, the lure must be believable. If we put a lure in the form of SSH on the accountant's computer, this can make the attacker suspicious.

Often, the lure contains authorization data for accessing the trap - login and password or key. But how to create them correctly so that they look natural and believable? This is where the idea to maintain a database of fake users inside deception appears.

Fake users

So, we want to add authorization data into the bait that is similar to the real one. At the same time, in each organization, user data looks different. Every organization has its own login formats (for example, first letter of the name -- dot -- last name). Every organization has its own password policy. For some lures, you may need a mailing address, a domain address, or something else. So, what is the best way to proceed in this case?

The problem can be solved by maintaining a database of fake network users. There are different approaches to maintaining such a database.

For example, a deception solution can be integrated with a traffic analysis system. This makes it possible to recognize the presence of authorization data in network traffic, find common features, and generate users similar to real ones based on the identified rules.

If there is no such integration, user generation according to manually set rules looks like a good solution. Among such rules can be the choice of a specific dictionary of names, setting a login template, setting password generation rules (presence of special characters, minimum length, passphrases, words from dictionaries, and so on), setting a domain address, mail server.

This approach can be helpful if a company uses deception to protect branch offices in different countries. Then, say, for the German branch, fake users may have names from the German dictionary, and for the Chinese branch, from the Chinese one.

When a database of fake users is formed, deception tools can use it when creating lures. For greater realism, you can make a connection between an agent and a fake user so that all lures placed on a particular agent are on behalf of one person.

Network connection emulation

As noted above, traditional honeypots exist on their own, do not interact with anything else, and do not leave traces on the network. However, deception technology is aimed, among other things, at pushing the attacker to interact with the trap.

To do this, the attacker must be told where to look for the trap. We also should make him think that this is a real thing. Imagine that you found a specific service on the network, and passive sniffing shows that no one ever interacts with it. This looks suspicious.

Therefore, one of the features of deception is the ability to actively emulate network interactions. Any points within the system can interact: traps with traps, agents with traps. The implementation depends on the specific solution and may include interaction with the help of simple TCP/UDP packets, as well as data transfer over some high-level protocols.

The specifics will depend on the type of trap. For example, you can teach an agent to (periodically) go to a trap that emulates SSH, pass authorization there, and even execute some commands.

As noted above, the trap notifies of any attempts to connect to it and sends a notification about this to the server. This includes connections within the emulation! A mechanism must be built into the deception server to distinguish between real and fake security events.

Emulation, by the way, to some extent intersects with the idea of ​​​​lures. Some protocols involve transferring authorization data in clear text (for example, FTP). FTP connection emulation will work in the same way as a lure. We provide the attacker, who monitors the traffic, the username and password to access the trap.

It is essential to use this functionality with caution. A hacker can suspect something is wrong by analyzing the traffic and noting that, for example, all requests are the same, occur too often or regularly, have an atypical length, or other parameters. When developing and configuring deception systems, these nuances must be carefully considered. Randomization and other masking methods should be introduced.

Additional components

A variety of elements can be included in deception solutions. Let me elaborate on the two most relevant -- automatic deployment and data collection from workstations.

Automated deployment

One of the potential problems of deception is the complexity of the initial setup. Without deployment automation, when installing deception on the network, you would have to manually determine the list of traps and emulated services, configure them correctly, and create and place lures for each trap. This is a tremendous job.

At the same time, it is impossible to make a standard solution in order to use it with each customer. Each organization has its own set of network resources. If the company's network is small, one specialist can handle it, but what if a large company wants to use deception technology? It may have many subnets that need traps. Each subnet may have its own set of typical resources. In this case, you cannot do without deployment automation.

You can use several options. For example, if deception is integrated with a traffic analysis system (as in the example with fake users), the system will be able to obtain data about specific protocols used on each individual subnet. Based on this information, a deception system can automatically set the right types of traps and even update the false layer of the network when new real resources are added.

If there is no such integration, the problem can be solved differently. The deception server scans the network for open ports on actual machines or listens passively for traffic where possible. The collected information will be used by deception to set traps automatically.

The third approach involves human operators. However, you provide the operator not with the manual creation and configuration of individual traps but with a way to select the preferred list of network services and the expected number of traps. Then installation and configuration will be performed automatically according to the template.

Data collection

Deception can be more than just an attack detection tool. The presence of agents allows the system to take on other tasks. One of them is the collection of data about the software installed on computers, including versions and dates of installation. The results can be compared with CVE databases and warn about severe vulnerabilities in programs being used.

The deception platform can also be useful in finding hackers and investigating incidents by helping to collect OSINT info and other data gathered, for example, from people search services. When a trap detects an attack originating from a workstation with an agent, the deception platform can match the data from the trap (time, connection type, port) with the information that the agent has. This way, you can get useful information about the attack like which process launched it, how it entered the computer, etc.

The agent can also collect various indicators of compromise on the employee's workstation. This would make it possible to receive notifications even before the attacker proceeds to active actions on the network.

Conclusion

Deception is a relatively new technology. Deception solutions appeared on the market not so long ago. At the same time, they are gradually gaining popularity. Deception does not replace standard, generally used information security systems. It helps to complement protection systems, allowing organizations to detect cyberattacks that have bypassed other means of protection. If you doubt whether your company needs deception technology, you can launch a pilot project and install a trial version of any available solutions.

Photo Credit: andrea michele piacquadio/Shutterstock

Alex Vakulov is a cybersecurity researcher with over 20 years of experience in malware analysis. Alex has strong malware removal skills. He is writing for numerous tech-related publications sharing his security experience.