Squeezing out IoC juice - methodical analysis of network infrastructure.

One of the most common problems CTI analysts face is using the collected data to uncover further elements of hostile activity, the so-calledpivoting". Simply put, pivoting consists in discovering other artifacts such as IP addresses or malware samples through the common features of both elements. In the case of malware, this could be, for example hash of the import tableand in the case of network infrastructure JARM hash profiling the configuration of the TLS service. Assuming that it is not possible for attackers to create a completely unique malware or unique infrastructure configuration every time, we look for artifacts with similar and unique characteristics (or a combination of them), thus expanding our knowledge of the overall activity.

Due to the multitude of combinations of artifacts and indicators, it is difficult to come up with a comprehensive methodology applicable to every situation. However, in my opinion, the biggest problem is the appropriate and repeatable approach to network infrastructure elements. Both in the case of IP addresses and domains, it is difficult to identify elements that could clearly indicate similarity, such as reuse of code fragments, import table hashes, compilation time, or data contained in rich header. The prevalence of privacy regulations and the popularity of cloud services often make it difficult to find connections. A domain whose WHOIS data is filled with the phrase "REDACTED FOR PRIVACY" leading to a site using Amazon Web Services hosting will certainly not be unique enough to find further related items. In this case, we will have to go further, checking the configuration of the services, TLS certificates used, DNS records to find a pattern that allows us to take our search further. These concepts were well presented by Joe Slowik in the post "Analyzing Network Infrastructure as Composite Objects". However, the multitude of characteristics remains a challenge, and therefore it is difficult to analyze the data in a repeatable manner.

Therefore, to help analysts of all skill levels, I decided to gather in one place the features of network infrastructure that can be used for profiling in the form of a spreadsheet. This worksheet is designed to structure the analysis of indicators, serving as a checklist to help analysts make full use of the data obtained. You can find the sheet at this link, and now I will try to briefly explain how to use it.

The first page contains a table of contents and a presentation of the tool's concept, so you will find there links to individual sheets, as well as a network infrastructure correlation diagram taken from the aforementioned entry by Joe Slowik. The main part consists of sheets containing a description of the elements of indicators of a given type and templates for describing the indicator as a complex object and listing links that help us in the analysis. So let's look at the example of the IP address 87.98.236.253, which happens to be the address of the server where the blog you are reading is located. In the IP sheet, we will find a list of features thanks to which we can create an IP address profile.

Since there are specific devices (virtual or physical) behind the IP address, let's also look at the Services/Protocol specific sheet, where we will find a description of the features related to popular services such as TLS.

By analyzing the indicated elements one by one, we can assess which may be useful in finding related elements, e.g. due to their uniqueness. And here we are also entering the area of profiling based on combining elements. A search for IP addresses that are in the same AS will reveal millions of results:

Similarly, a JARM-based TLS configuration profile will return almost 40,000 results:

However, by combining both queries, the number of detected devices will already be orders of magnitude lower:

So, expanding the network infrastructure indicators into objects with a range of characteristics is a powerful tool to reproducibly track infrastructure elements that we have associated with activity. We can save the result in the "Composite Object Template" sheet, additionally describing the sets of values that we think are worth attention:

And the results of individual pivots are saved in the Pivot Template sheet:

In this way, we can catalog all the methods thanks to which we found further elements of the infrastructure. When I started working with network infrastructure mapping, one of the most common mistakes I made was doing too many and too wide pivots at once. As a result, I ended up with a Maltego chart where I couldn't identify elements that actually belonged to the same set of activities with a high probability. Breaking down this process into individual searches and tracking subsequent stages allows you to avoid such a situation and assess which techniques have brought the desired effect on an ongoing basis.

I hope that this tool will help analysts structure their work on detecting hostile network infrastructure and will allow them to make the most of the artifacts left by attackers. The sheets containing the description of individual characteristics also contain the Examples column in which I will try to collect links to studies describing the usefulness of a given range of information in practice.

In the meantime, happy hunting to all analysts!