Watching the Watchers using Deception Techniques

Watching the Watchers using Deception Techniques

by Muruganandam


This article is a part of our open-access issue, which can be downloaded here: https://pentestmag.com/download/pentest-open-cybersecurity-penetration-testing-trends-2017/


We need to ensure we maintain both the attacker’s interest as well as their acceptance that they are attacking real targets. Honeypots have often been criticized for their lack of believability, causing many attackers to recognize the system as fake and avoid interaction. If we allow this to happen, the Labyrinth could provide no additional intelligence on the attackers, or on their tactics and techniques, and wouldn't allow for any additional timesaving afforded to the security team. So to begin, what is a Honeypot? A Honeypot is a non-production system, typically housed within a virtual environment, whose sole purpose is to be a target. The Honeypot is a decoy system that provides a deceptive layer, shifting the focus of attackers away from production systems.

The objective of a Honeypot is to provide security teams with information about its every function, so the team can determine the tactics and techniques of those actors who interact with the system. To convince the attacker that the decoy system is genuine, "we need to be aware that he will be trying to fingerprint the decoy and its applications." It is critical that Honeypots do not stick out and cause an attacker to move in a different direction.

Within an entire network of honeypots, even if an attacker does move in a different direction, it will likely be towards another honeypot. But, the goal of the Labyrinth is to be as believable as possible, to ensure we keep the attackers focused on what we want them to focus on, and not allowing them to question their actions. To assist with the believability of the Labyrinth, it should behave like a real network. Each system within the internal network should have representation within the Labyrinth, and the topological layout of the Labyrinth should essentially mimic that of the real network.

To ensure the acceptance of the Labyrinth, a logical combination of honeypot systems within each subnet should resemble what the internal network would use. For example, within the DMZ section of the Security Analyst, the legitimate types of DMZ systems should be present: a fake Web Server, an external Domain Name Server (DNS), a Mail Server, and perhaps a File Server (FTP) or even a Voice24 by Muruganandam over IP (VoIP) server. However, if there were also unpatched Windows XP systems with large quantities of internal information, it may cause an advanced attacker to question their situation. This doesn’t mean you cannot have an unpatched Windows XP system in the Labyrinth. You should use a variety of OS's as long as they represent the types of systems with the real environment. Place these systems within subnets that resemble a functional network.

Having a network within the Labyrinth that resembles an actual subnet of endpoint specific systems, e.g. user laptops, desktops, and printers, simply makes the Labyrinth more believable and facilitates the attacker to wander deeper into the Labyrinth, in turn, allowing the security team to develop a much more comprehensive listing of the TTPs on the attackers. The entire point is to make the attackers waste as much time as possible to allow your teams to counter their potential attacks.

With the effort of designing and configuring the Labyrinth to be as believable as possible, there is another level of configuration that can make the Labyrinth resemble the real thing, administrative actions within the Labyrinth. "Day-to-day changes in the environment may include adding, upgrading and removing applications, networks, operating systems, endpoints, and devices." Creating network traffic within the Labyrinth and by essentially treating the Labyrinth like a real environment provides yet another layer of deception. To achieve this deception, we have several scripted actions within the Labyrinth simulating user actions, like requesting DNS lookups, Web Traffic, file transfers, and generating events that trigger log population on the systems. Creating what appears to be legitimate noise within the Labyrinth and aid in the believability of the Labyrinth's functionality. In turn, this can allow the attacker to interpret the network as normal and continue to probe and test the Labyrinth as they would any other network. The beneficial security information gleaned from a honeypot is without a doubt the primary motivation for their use. However, there are limits and restrictions under which a Labyrinth environment should operate.

"A primary concern for honeypot designers is that of an attacker getting control over it. If this happens, the attacker can initiate attacks from the honeypot, which is regarded by the network as a secure environment." While the primary purpose of the Labyrinth is to record and use the tactics and techniques of an attacker to better secure the legitimate network, the risk of having the attacker use the Labyrinth for malicious purposes against other sites are grounds for significant legal concern.

The monitoring of suspected malicious actions within the Labyrinth is the primary goal of the Labyrinth. While ultimately protecting the legitimate network is the objective, protecting outside organizations from attacks based within the Labyrinth is equally as important. Should all identified malicious actions be stopped immediately? Within the Honeypot community it is loosely understood, that "it is sometimes better to observe the attack through to completion and then identify the stolen goods after the deed has been done." By keeping the attacker focused on what you want them to focus on, you gather information.

You are also safeguarding the attacker from actively focusing on something, or someone, else. Since the Labyrinth can be wiped clean at a moment's notice, a critical event or an action targeting an outside entity, the malicious action can be stopped in its tracks as the Labyrinth is reset to a clean version. The defenders could fail to gain a complete picture of the attacker’s TTPs, but the information gathered from these actions still allow the security team to bolster their defenses.

May 13, 2019

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013