Understanding Threat Intelligence for Infrastructure Security

If you are responsible for protecting the corporate infrastructure, you probably have various security products in use to support you in this task – with a distinction made between network and host security. These terms primarily relate to where a security system is deployed. Firewalls or network intrusion detection systems (NIDS) are deployed at central points on the network, and antivirus programs or host intrusion detection systems (HIDS) are put on as many computers as possible in the enterprise.

Firewalls let you allow or deny network connections according to a fixed ruleset and primarily prevent requests from the Internet access to the corporate network. Depending on the size of your environment, firewalls can also isolate different departments. In addition to a fixed set of rules, a NIDS can use dynamic or heuristic detection techniques that classify network connections on the basis of metadata, as well as communication content, and trigger an alert when suspicious connections are detected.

Classic antivirus programs protect your computer by means of bytecode signatures or use heuristics that combine special system calls or file and hardware access. HIDS also monitors user actions, files, and directories, as well as the registry and network connections. Some vendors specifically enhance their virus scanners with HIDS-specific features to enable comprehensive host security.

Even if you have implemented the normal protections in your company, as an administrator or security analyst you will want to take a more in-depth look in some situations (e.g., employees reporting irregularities in IT-specific processes, such as untypical behavior of their PCs or certain programs) to make sure attacks on your infrastructure are not happening. Also, attacks on high-ranking targets by smart hackers can encourage a look into infrastructures to search for signs of attacks.

TTPs, IoCs, and CoAs

In published media reports and analyses on the web, you will often find descriptions of the attacks and the malware used. The attackers’ tools and approaches, to the extent that they are traceable, are summarized as tactics, tools, and procedures (TTPs) and contain indicators of the approach in terms of information gathering, the attack targets, exploited vulnerabilities, and lateral movement details after a successful intrusion.

The traces that attackers leave behind on the network and on computers in the scope of their activities are referred to as indicators of compromise (IoCs). From IoCs, you can see whether you are currently feeling the effects of, or have been affected by, a particular attack. These IoCs can be files, registry entries or installed services, changes to the hosts file, and the like. Instructions on how to proceed in the event of a demonstrable attack should also form part of the online documentation of security attacks as courses of action (CoAs).

This threat information can therefore be used to diagnose an attack over the network or potential malware infections. Before I look at how to use these tools to search for IoCs specifically, I first need to talk about the source of this information.

The basis of information (threat intelligence) gathering is IT security analysis, which is carried out by specialist companies, research institutions, and government entities. Whereas government and research institutions specifically search for and analyze malware, analyses by companies are often carried out in the scope of incident analysis (i.e., dealing with the actual malware infection).

Security Providers as a Source

The result of an analysis often comprises a technical description of the findings and a detailed report. The analyst collects everything that can help describe the malware in a designated data format. The best known are probably the integrated STIX/CybOX tool and MISP (formerly Malware Information Sharing Platform); both are based on JSON and therefore considered to be human readable. Only a few truly comprehensive examples of the use of STIX/CybOX exist. In fact, the best insight you can get is from the reports provided on the official website, such as one that relates to the Poison Ivy malware created by security specialists FireEye, as well as from the technical description.

If you are not able to analyze malware yourself, you will have to rely on the results of other people’s work for your investigations. Fortunately, most analysts are happy to share their findings and make them available over appropriate sharing platforms or simply for direct download.

Exchanging Information with MISP

The MISP Threat Sharing Platform is currently the tool of choice for processing threat intelligence. Locally installed instances can connect to community servers, enabling threat intelligence sharing across enterprise boundaries. Within MISP, you can define the visibility of individual entries in such a way that the content does not leave your company. Then you always have an overview of what you share with other companies and what information remains internal. For an overview of some quite interesting MISP communities, see the MISP Communities page.

MISP offers some useful extensions. For example, if you use Snort as a NIDS, you can export existing rules directly in Snort format and roll them out immediately after you receive them. Of course, you will want to be careful when adopting third-party rules that you have not checked and initially only output warning messages for any criteria added automatically. Alternatively, you can obtain threat information without a running MISP instance. Often, the downloads offered are specialized in certain areas. For example, you will find many lists of IP addresses that have been discovered to propagate Spam or launch brute force attacks against SSH login servers. Unfortunately, the information contained is often only usable for a certain period of time because it very often involves dynamically allocated IP addresses from Internet providers.

More Sources

In addition to structured information, you will also find simple verbal descriptions of analysis results in various places. Proofpoint, for example, publishes detailed reports on its blog. The authors describe and reference the TTPs and IoCs they were able to identify during their investigations. To provide an overview, all IoCs are once again clearly presented at the end of the articles and enriched with additional data such as URLs and hash values of files and programs or libraries. Some contributions add Yara signatures, which are basically regular expressions you can use to search for patterns in text and binary data with different tools.

The more sources you find and consult, the more descriptions of attacks, malware, and procedures you will have. However, this knowledge alone does not give you any information about how your own systems may be affected. You can collect this information at various points in your infrastructure. Network-based IoCs can be located in centralized locations in most cases. You will want to block IP addresses directly in the packet filter and use your internal DNS server to redirect listed domains to local destinations and route the requests into a black hole. Of course, you will want to log the requesting computers and, if possible, isolate them automatically for further analysis in special network areas. The same applies to URLs, which you can easily transfer to your HTTP proxy to log and prevent access attempts.

To detect host-based IoCs on your organization’s computers, you need technical support. One possibility is the well-known GRR Rapid Response open source tool. With its client-server architecture, GRR enables centralized management and asynchronous processing of requests (known as hunts) on the clients. For a defined runtime, clients receive the requests as soon as they are connected to the corporate network.

The results are then published at the next opportunity. This approach also covers mobile devices and home office computers that only sporadically connect to the corporate network. Of course, this means you need to install the GRR clients on your systems; it is not suitable for use on the fly. To test the tool, you can simply store a file named notepad.* in the Windows system folder after installation (Figure 1).