In the previous article, we talked about a variety of traps and decoys. Now that the decoys are ready, there is very little left to do – to distribute them to the right hosts. This is where another criteria for selecting a Deception solution comes into play, namely how the decoys are delivered to the hosts.
Currently, the solutions fall into two main categories:
- Agent-based solutions: specialized software is installed on the endpoint host through which decoys can be delivered and updated;
- Agentless solutions: in this case, remote management tools, group policies, or third-party agents are used.
Each of these categories has its pros and cons:
The agent-based solution is more flexible, it allows monitoring the current state of the decoys on the host, and has quick access to all forensics but unfortunately can be detected by an attacker.
Agentless solutions offer more stealth because there is no software on the endpoint devices that can be detected by an attacker. However, local/domain administrator rights may be required to perform many actions.
Furthermore, using an agentless platform, decoys can be distributed using already deployed and familiar IT solutions like SCCM or anti-viruses that allow remote launching of scheduled software. In particular, antivirus agents can be used to regularly run some scripts to distribute or update the decoys.
Active Directory
The use of Active Directory is the most popular method of privilege escalation and lateral movement among attackers. Almost every solution vendor supports the ability to work with it. AD can host both traps and decoy accounts.
Some of the popular methods to mislead attackers include the following:
- Creating false privileged/typical accounts;
- Using existing accounts as a decoy (using a fake password in the decoy host);
- Creation of fake SPN records and different kinds of Constraint/Unconstrained delegation for Kerberos attacks;
- Creation of fake DNS records;
- Storing fake passwords in user profiles. For example, a test user is created with the description “Temporary test user, password 225468vvTEST”;
- False LAPS-like vulnerabilities: when a password is stored in a “protected” attribute but is accidentally accessible to a much larger group of users.
The realism of the decoys being created is very important here. For example, there is a popular HoneypotBuster script for determining Deception solutions in Active Directory. It must also be kept in mind that queries to AD can be done by absolutely any user and if your fake user is not in AD, an attacker will quickly detect this.
Many solutions have the possibility to identify popular scripts like PowerView, whose peculiarity is that they perform bulk attribute queries on an object in AD, which almost never happens in normal operation, often a marker for the use of these utilities.
Looking realistic
In addition to increasing the interactivity of traps and the plausibility of decoys and fake accounts in AD, solutions from some vendors can create and dynamically adapt an emulated trap and decoy network for the attacker right as he moves through it. This is especially true for vendors working with hybrid and cloud solutions.
The following techniques are used for this purpose:
- All unauthorized requests to AD are handled by a special Deception copy of AD;
- Traps are created at once with decoys inside, allowing the attacker to “lead” through a chain of such traps and distract from the real infrastructure;
- When ports are scanned, some ports “respond” to the scan even though they are proxy ports and lead the attacker into a low-interactive trap already deployed for him;
- If the attacker continues to explore the service, the trap is replaced by a higher-interactive trap;
- The “rabbit hole” gets deeper and deeper as it progresses;
- Machine learning techniques are used extensively to create and extend realistic infrastructure.
Unfortunately, on-premise solutions often lack this flexibility in dynamic adaptation, so manufacturers try to disguise traps and decoys in real infrastructure as much as possible. Therefore, to facilitate user implementation and speed up the process, some solutions have the following functionality in their arsenal:
- Initial traffic analysis to identify popular services and generate traps for them;
- Integration with CMDB systems for automatic filling of the trap parameters, like software version, cores used, etc.;
- Regular updates/re-creation of traps for updated system versions;
- Trap hosts and decoy accounts in AD are named according to the naming policies in the organization
- Traps can exchange false traffic to give the appearance of life on them. But we note that this point causes a lot of controversies because it creates an additional load on the infrastructure;
- Automatic generation and updating of decoys on hosts corresponding to the traps created in the system.
I would especially like to emphasize the need to group traps into realistic hosts. A host from the outside should look like a Windows/macOS/Linux host and not just a “Port 445-SMB trap”. Manufacturers have different approaches here but some solutions create emulations that are almost indistinguishable from real hosts.
Management and monitoring tools
It is not enough to lure an attacker into a trap, it is necessary to learn about it in time and notify the right people. If your goal is not only to prevent an attack but also to investigate the attacker’s TTPs, Deception must have the ability to further collect forensics and track the attacker’s movements.
This is the part where Deception solutions offer very flexible functionality, which typically includes:
- Built-in management and monitoring tools. This functionality usually differentiates a HoneyPot set from the complete solution by collecting all incoming information into a single system, thus providing visualization of the attacker’s actions on a network map, attack history, most frequently used decoy/attack trap types, and much more. The possibility to create flexible reporting is a must.
- Easy scalability and recovery. Solutions are usually easily scalable by adding new trap management modules. Some solutions allow horizontal scaling of system management centers as well.
- Easy setup and deployment. This point is also a key differentiator from the set of traps from Open Source solutions. Vendors are able to automatically scan the network and create the necessary set of traps and decoys directly for the customer’s infrastructure. There is obligatory integration with various distribution tools within the domain, which allows implementing all the functionality from a single interface literally “in one click”.
- Open API for integration. Many solutions have an open API for interaction, allowing even tighter integration of solutions into their own system and managing it programmatically.
- Built-in correlation and advanced reporting. Several solutions are capable of automatic mapping of the attacker’s actions (usually on the MITRE ATT&CK matrix). This allows a better understanding of the attacker’s actions by searching for additional information in the MITRE database. However, it should be noted that a very small list of matrix techniques and sub-techniques is usually covered.
- Integration with SIEM and other tools. As mentioned above, the task of Deception solutions is to quickly detect an attacker, so solutions necessarily have the possibility to transfer information to SIEM systems to correlate an incident.
- Basic intrusion prevention tools based on triggering traps and decoys. Several solutions allow integration with NAC and IDS systems, quarantining suspicious hosts or isolating certain ports for further advancement.
- Role-based access models. As in many enterprise solutions, the possibility to differentiate access at the role level, full-fledged logging of user actions in the system, and other necessary functionality is supported.
Prevention tools
You have probably wondered if it is possible to exclude the actions of an attacker on the machine. It is almost impossible to completely exclude it but it is possible to complicate or impede the further movement, yes! For this purpose, some manufacturers build a functionality into their products to detect possible resources for further lateral movement. Most often, this is an automated deletion of cached credentials and replacing them with false decoys. In addition, there is functionality for detecting identical local administrator passwords on multiple machines, searching for so-called “shadow administrators” in a domain, and much more.
The need for such functionality in Deception technologies is much debated. Besides its obvious usefulness, there is also a chance of disturbing the normal operation of the infrastructure, so many people prefer to leave it in “inform only” mode. It should be kept in mind that typically the local password reading functionality is very similar to malicious activity, and may cause false positives from various host security tools.
Conclusions
Modern Deception technologies have long stepped beyond “just a few honeypots” and offer a much more extensive functionality, which is constantly evolving in response to market demands: today there is a number of successful commercial Deception platforms.