Indicators of compromise (IoCs) are key data points used during an incident response process. Your organization’s response handlers will use these indicators in different phases of incident response — from detection through containment and mitigation actions.

These indicators can be received from a third party, such as sharing through a threat intelligence platform, or as the result of an internal incident investigation. Regardless of the source, once these indicators have been vetted and proven reliable, they can be used as the lead for identifying further leads.

This is exactly what pivoting is about: You start with a reliable data point to guide you through the next steps in your incident response process.

Read the white paper: IBM X-Force IRIS Cyberattack Preparation and Execution Frameworks

IoCs: Verified or Bust

All indicators — whatever the source — should go through a verification process, ensuring that the quality of the indicators remains high. Good indicators will allow you to pivot to other good indicators, whereas poor indicators will only lead to more of the same.

This verification process will vary between organizations and, in some cases, can contradict organizational requests for automatic processing of indicators. However, it’s a necessary step to avoid going off track when responding to a real threat.

Diamond Model Incident Response

The diamond model offers threat analysts a method to visualize and evaluate threats. It does this by describing events where an adversary deploys a capability over infrastructure against a victim.

The indicators that are collected during the analysis of these events can be mapped as data points on the capabilities or infrastructure vertices of the diamond model. This will then allow you to pivot further — switching from the capabilities of an attacker to the infrastructure they used for that event. It’s important to note that capabilities are not limited to technical elements only, as it can also describe tools, techniques and procedures used by the attacker.

Intelligence pivoting via the diamond model allows you to build the bigger picture. It gives you the means to pivot from an indicator to an adversary — or to a previously detected campaign. It’s the type of information that provides deeper insight into what is actually happening in your environment.

Defenders are not the only ones pivoting, however. Attackers use pivots to increase their privileges. By starting an attack against a host with lower security — or against a user with fewer privileges — threat actors can gain a foothold in the network.

From there they can collect information and sketch interesting links between the found data points. They can then rate the quality and usability (exploitability) of these links, much as defenders do, and follow the ideal path for achieving their objectives.

How to Evaluate and Track the Links

When you pivot around data points, it’s necessary to document your steps and the environment that you used.

The following questions can help you keep track of this information:

• What data point did you use to pivot to other data points (e.g., a full host name or the only the domain name)?
• Which provider’s data set did you use (WHOIS data, domain name system [DNS] data, etc.)?
• At what time did you pivot — and did you try at different times?
• From which location (network, geographic, etc.) did you perform the pivot? Were filters applied to the network?

Because pivoting can quickly give you a very large data set, it’s easy to lose oversight. To avoid this, you need to evaluate and rate the links between data points continuously. This rating system can be based on your indicator quality ranking.

Parameters that you can use for rating include:

• Whether you received all results or only a subset. For example, did your license allow you to have access to all the available data points?
• The level of trust (or reputation) that you have with the data provider. Does the data set cause a lot of false positives?
• Whether the data set is relevant to your organization, region or specific technical devices used by your organization.
• Whether you have observed similar links in the past.
• Whether your organization has the log information to verify the found indicator and whether it is accessible.

Don’t forget that pivoting via public resources can also alert the attacker (or someone monitoring the network) that their actions have been uncovered.

What Are the Domains for Pivoting?

In general, two domains are primarily used for pivoting. The first is system- and user-based. These include application or system log files, alerts from security solutions, indicators from memory or disk forensics, file and process information and user actions.

The second is network-based pivots from proxy or firewall logs. The information can come from active network connections, recorded network traffic (either in NetFlow or full packet capture [PCAP]) or network protection devices.

What Are the Data Points for Pivoting?

The data points from which you can pivot are dependent on the type of information that you’re looking for. In most incident response cases, you’ll probably be looking for information that you can use to find other infected hosts and to further understand the impact of the incident — and, thus, define containment actions.

The following are a few examples that you can use to pivot:

• VirusTotal: An IP address found in malware. You can search web proxy logs (provided the C2 connections are HTTP-proxied) or firewall logs for other infected hosts. Recorded network traffic can also be queried for connections towards these IPs to find infected hosts. Pivoting on the IP address itself in VirusTotal can give you file hashes of other malware that have been previously associated with the malware.
• Correct file hashes: File hashes (MD5, SHA256) of malware are very useful for pivoting. Take care that you search for the hashes of the correct files. If a PDF file drops an executable, for example, then search for the last dropped file. The first file (i.e., the PDF) can be useful but might not be as relevant because changing the document used for delivering the malware requires little effort. Changing the dropped malware, however, requires more resources. (Modern malware can easily be refactored, however. One example is changed configuration data that’s included in the malware.) Querying #totalhash will list the files created by malware together with the associated process names. The VirusTotal relationship information will also give you pointers to other files or submissions that are linked to the detected file.
• Hybrid-Analysis: A filename is very generic data and will most often not give you valuable results. This is fine if it’s the only data point that you have to work with — but always take into account that it will return a lot of false positives. The online malware sandbox of Hybrid-Analysis allows you to search for specific filenames.
• Specific information: The installation path or application startup parameters can similarly cause a lot of false positives. If they are unique enough, though, it can still be a good starting point. Remember to remove drive- and user-specific information.
• Clear context: A mutex or a registry key can be a strong pivot point but can also lead to a lot of false positives. Make sure that you understand the context and uniqueness of the indicator before you use it as a pivot point.
• RiskIQ Community: Domain names can be searched for in your DNS server logs or proxy logs to spot hosts that attempted to resolve a possible domain name. You can again use VirusTotal to search for related domains or use RiskIQ Community to find other related domains. The same data set will also give you passive DNS information which you can use, in turn, to query the recorded network information or proxy logs. Take care if you use the IP address as a pivot point. Make sure that the data point you pivot to does not belong to a content delivery network (CDN) or “mass-hoster.”
• Registration information: The domain ownership information, together with WHOIS and ASN data, gives you network owner and routing information that you can use for the evaluation of the threat. The registration information for domains (primarily the email address) can be used to search for other registered domains by the same person.
• Passive SSL: HTTPS is no longer only reserved for “good” traffic — malicious actors use HTTPS as well. You can use the information that’s been put in a certificate as a pivot point. Data sets can reveal which other domains or IPs a certificate has been installed on. Also, the Passive SSL service, provided by CIRCL, allows you to query for IP addresses, classless inter-domain routing (CIDR) blocks or a certificate fingerprint.

If you start pivoting too quickly, you’ll run into a situation where you have found data points, but your organization does not have any log data collected to verify them. This is something that you will have to take into account when evaluating the links and indicators. If your reporting shows that you are often missing log information to query for essential indicators, then this might be an incentive to extend your logging capabilities for that specific domain.

Read the white paper: IBM X-Force IRIS Cyberattack Preparation and Execution Frameworks