Threat Intelligence and SIEM (Part 4) — An Active Cyber Defense Approach

In the previous posts of this blog series, we saw how threat intelligence can significantly help organizations move from a reactive to a proactive security approach. By having real-time insight and context on the threat landscape, we can “move left” in the Cyber Kill Chain (see image below) and thwart an attack at an earlier stage, limiting its impact and cost.

However, even with fine-tuned security devices and actionable intelligence, there’s still a risk that determined hackers will be able to break through your defenses. Nothing prevents them from buying the same IDS/IPS and firewalls you have to find an unknown hole and craft a novel attack (otherwise known as a “zero-day exploit”).

In this post we’ll describe how to use active defense mechanisms as another layer of security to improve your chances against adversaries.

Using Deception as an Active Defense

Active defense (AD) can be defined as “any measures originated by the defender against the attacker,” and can be divided into three categories:

1. Counterattack

2. Preemptive attack

3. Active deception¹

The first two categories, respectively, involve “hacking back” as an act of retribution, and engaging an adversary upon its first hostile move for prevention purposes. In this post, we will focus on the non-offensive part — the last category of active deception.

Its main goal is to thwart attacks and provides the defender with attribution capabilities, helping him or her to define the opponent; collect information about its tactics, techniques, and procedures (TTPs); and create threat intelligence based on this information.

The idea is to increase the complexity of an attack (e.g., make it more difficult for the attacker) using tools such as honeypots and honeytokens, forcing the attacker to make more moves that will eventually be noticed. We can deploy decoys and monitor their activity with our security information and event management (SIEM); every time the attacker interacts with one of them, we will be aware of his or her presence and will be able to gather information about possible next moves.

Based on this data we’ll create our own internal threat intelligence (TI) which can be correlated with the external TI within the SIEM.

Let’s look at these tools in details.

Honeypots

Lance Spitzner, security researcher at Symantec, defined a honeypot as an “information system resource whose value lies in unauthorized or illicit use of that resource.”

Its goal is to mimic a legitimate system running vulnerable services on the network, with all activities monitored. Once spotted, an attacker will very likely try to compromised this easy-looking target. However, no valid information will be found, and no further damage can be done to harm the other legitimate instances running on the same network.

An important characteristic is that honeypots cannot be accessed by normal users. By monitoring their activities, security staff know that all events are genuinely malicious and can gain insight into opponents’ methodologies to better protect their infrastructure. Moreover, they can extract forensics information to provide law enforcement with details to prosecute. Honeypot systems can be deployed at diverse locations on the infrastructure.

Figure 1: Possible honeypot deployment. (Source: SANS)

The sole purpose of honeypots is to be mistaken for a production resource and undergo attacks. From a hacker’s perspective, there should be no difference between honeypots and regular machines. The ENISA identified two fundamental criteria for honeypot classification²:

1. Type of attacked resources

2. Level of interaction

Attacked Resources

The types of attacked resources describes the running service(s) to be exploited. On a server-side honeypot, running services such as SSH or NetBIOS is a good idea and will likely tempt attackers to misuse them. On a client-side honeypot (or “honeyclient”), we can deploy specific applications, such as a Web browser that actively connects itself to remote services and analyzes the behavior of the server or its delivered content to detect malicious attempts.

Level of Interaction

Depending on the level of mimetic we want to achieve, we can use honeypots with three different levels of interaction: low, high, or hybrid. Low-interaction honeypots emulate a resource, providing limited functionality compared to the real instance. The success of tricking the opponent depends on the degree of accuracy of emulation. Easy to deploy, emulation (in this context) reduces the risk from a machine to be compromised. However, some emulated resources might behave differently than the real ones and experienced hackers may notice and abort their attempts at an early stage.

High-interaction honeypots do not use emulation and instead employ real operating systems and resources. These are less likely to be noticed. However, the resource consumption and complexity may affect scalability and performance.

Finally hybrid honeypots are a combination of low and high interaction, providing the best features of both types.

In their report, the ENISA and the CERT researchers from Poland evaluated a broad range of honeypots depending on criteria such as the detection scope, accuracy of emulation, quality of collected data, and even the scalability. They covered and tested up to 30 different standalone honeypots with various levels of interaction and purposes (general purpose, Web, SSH, SCADA, VoIP, USB, etc.).

Honeytokens

The concept of honeypots mimicking a legitimate machine has been extended to files. In the same approach, a honeytoken (also called “decoy document”) is information or a digital file that no legitimate user should use.

Each access to that token is monitored and considered malicious. A typical use case is to disseminate honeytokens in a database or a system, entitled with a juicy name such as “passwordlist” or “medicalrecords.” It can be a text file, a spreadsheet, bogus social security numbers, or even a (fake) user account.

Once an attacker (external or internal) accesses that file or tries to log himself in using the user account, an alert is triggered. CERT researchers advise three different techniques to detect honeytokens misuse:

1. System or application logs

2. IDS signatures

3. Usage of specialized data loss prevention solutions*

*Which may make use of the previous two methods.

Another technique proposed by Matthew Toussain is to use CybOX to automatically retrieve extra information and create an indicator of compromise (IOC). In fact CybOX supports the logging of data and could allow us to “not only identify that access, but also log information concerning what process on the system opened its file handle, what network ports it is currently utilizing, and what other system files it has accessed.³”

Before creating honeytokens, there are few requirements identified by Brian M. Bowen et al.⁴:

• Must appear to be true/valid/valuable/desirable

• Should not interfere with normal system operations; not pollute authentic data

• Should be obvious for legitimate users “that the honeytoken is a decoy for an attacker”

• Has to be monitored; access has to be detected

• Must be unique to minimize false-positive rates

Regarding the location of decoy documents, some places should be privileged such as databases, file-sharing services (FTP servers, Windows shares SMB), user’s email inbox, and corporate cloud.

The location in which tokens are deployed can be chosen according to the requirements above, but also according to external TI such as TTPs data to increase detection: by having insights on relevant APT groups for the business, we can use this intelligence to deploy decoys at locations the attackers will most likely look, enhancing our detection and deception capabilities.

The most important point to consider is to make sure that the token will not interfere with the production systems and files.

Conclusion

Active defense provides a mechanism to add an extra layer of security. It enables defenders to better protect their network against determined attackers. Some tools such as honeypots and honeytokens can be deployed: they increase the effort an attacker has to put in to succeed. Every interaction he’ll have with a decoy will be monitored and the security team can collect this information and act.

Security teams can not only harden their infrastructure to prevent further instance of attack, but also formalize the collected information with certain standards such as STIX and CybOX to create internal TI and feed it into their SIEM solution.

In addition, external TI retrieved from diverse sources — including the open, deep, and dark Web — can help enrich the newly created TI, providing contextual awareness to increase detection and efficient SIEM correlation. For example, Recorded Future’s real-time threat intelligence can enrich information in Splunk and ArcSight. Finally, security teams can share their homemade TI with the security information community to help others protecting their environment.