How to Arm Yourself with Threat Intelligence

Welcome back to this series on making threat intelligence actionable!

In the previous instalment, I discussed the MITRE ATT&CK framework and how it was the “holy bible” for threat intelligence analysts. This framework covers all the ways adversaries can perform a cyber attack in a step-by-step fashion and it provides a common language for defenders to share what they are seeing attackers do in their environment. This sharing of TTPs (tactics/techniques/procedures) is fundamental for keeping organisations save from ever evolving cyber threats.

If you missed this article you can check it out The Holy Bible of Threat Intelligence.

Frameworks are all well and good but how can we, as defenders, actually use this detailing of adversary TTPs to better defend ourselves? That’s the question this blog post looks to explore by focusing on how we can use threat intelligence articles to perform threat-informed hunting.

What are Threat Intelligence Articles?

Threat intelligence articles are reports or publications that provide information about potential cyber threats, attacks, or vulnerabilities. They are typically created by security experts working for businesses that specialise in cybersecurity in one of two ways:

1. Organizations that provide managed cyber security services for a range of clients. These organisations are known as Managed Security Service Providers (MSSPs) and businesses will out-source their cybersecurity to these providers. These providers can report on emerging cyber threats, and how to prevent or mitigate them, because they server a wide range across various demographics, geographies, and industries. This cliental provides them a unique insight into the cybersecurity threat landscape at large, something that larger organisations who have in-house security services are unlikely to see. Well-established MSSPs usually have a blog that is updated with the latest cyber threats the organisation is seeing across their clients’ estates.
2. Organisations that sell security solutions. These organisations are in the business of selling their products to companies. As such, if they can provide up-to-date intelligence on the latest threats and say that their products will mitigate said threat, this is a great selling point.

You may also find threat intelligence reports on cyber news websites, from large technology firms (Google, Microsoft, Apple, etc.), or on a vendor-specific basis (e.g. if their is a security bug in Citrix software they may publish a threat intelligence article on this along with their security guidance). That said, the vast majority of day-to-day threat intelligence articles come from either MSSPs or security solution sellers. A list I regularly visit includes:

• AlienVault OTX
• CISA Alerts
• Cisco Talos Blog
• Cyble Research Blog
• IBM X-Force Exchange
• Microsoft Security Intelligence
• NCSC Weekly Threat Reports
• Red Canary Blog
• RiskIQ Community Edition
• Trend Micro Research Blog
• Palo Alto Networks Unit 42 Blog

These are all what are referred to as “open-source” threat intelligence sources, in that the information is free and publicly available. Organisations will often subscribe to curated threat intelligence feeds that include articles detailing specific threats they may face. These feeds often come from specialist threat intelligence companies or large security solution sellers who have a threat intelligence division. This information costs organisations money to acquire but provides information that the organisation would have to devote considerable resources to acquiring or curating otherwise. The information in these reports often comes from dark web forums, propriety information collected by security solution sellers from their products, or from intelligence gathered by a specialist team.

The Intelligence in Threat Intelligence Articles

Threat intelligence articles can detail anything from new types of malware, phishing attacks, data breaches, ransomware, and other types of cyber threats.

From a threat intelligence perspective we can break this information down into the three main types:

1. Strategic Threat Intelligence: This type of threat intelligence provides high-level insights into the tactics, techniques, and procedures (TTPs) of threat actors, their motivations, and their objectives. It helps organizations understand the broader threat landscape and make informed decisions about their overall security posture. For instance, information that a Russia-based threat actor is targeting organisations who are supporting Ukraine in the ongoing conflict would be strategic intelligence. A good example of a threat intelligence article primarily focusing on Strategic Threat Intelligence is this one from Red Canary.
2. Operational Threat Intelligence: This type of threat intelligence provides more detailed information about specific threats and how they might impact an organization’s systems or data. It includes information on indicators of compromise (IOCs), malware signatures, and other technical details that can be used to detect and respond to threats. This intelligence is specific, technical, and allows defenders on the front lines to combat threats they may see. An example of a an article focusing on Operational Threat Intelligence in regards to BianLian Ransomware can be found here.
3. Tactical Threat Intelligence: This type of threat intelligence provides real-time information on active threats, such as ongoing attacks or phishing campaigns. It includes information on the latest vulnerabilities and exploits, as well as information on threat actors and their activities. This intelligence is a level up from Operational Threat Intelligence in that it details tactics, techniques, and procedures (TTPs) rather than specific IOCs. To learn the difference, and why this intelligence is often more fruitful to hunt on, check out my blog post on the Pyramid of Pain. An article looking at Tactical Threat Intelligence can by analysing how a recent wave of Emotet malware is spreading can be found here.

The reason why you are reading a certain threat intelligence article will dictate the intelligence most pertinent to you.

For instance, if you are combing through reports looking for threats related to your organisation so that you can perform IOC-based hunting, you will want to focus on the sections that detail the Operational Threat Intelligence. If you are looking at tracking a specific threat actor’s TTPs and how you can hunt for these in your environment then you want to focus on the Tactical Threat Intelligence sections. Or if you need to provide intelligence to management about trends that you are seeing across the cybersecurity landscape then making a note of Strategic Threat Intelligence is the way to go.

It is important to define your objective whenever you read a threat intelligence article and make sure you focus on taking information away that is related to that objective. Of course you might just want to learn cool new things that are happening. In that case just read everything.

The two main takeaways for most threat intelligence analysts from these articles will be IOCs related to a given threat and a list of TTPs a particular threat exhibits. The majority of articles will include these lists and your task, more often than not, is to hunt for these two things. Let’s first explore how we can hunt for IOCs.

Threat Hunting IOCs

IOC-based threat hunting involves proactively searching for indicators of compromise (IOCs) within an organization’s estate (network and endpoints) to identify potential security threats. IOCs are pieces of data that are associated with known malicious activity, such as IP addresses, domain names, file hashes, or network traffic patterns.

In an IOC-based hunt an organisation will collect and analyse a large amount of data from various log sources, including network traffic logs, system event logs, security logs, etc. They will search for specific IOCs which have been identified as malicious or suspicious by a threat intelligence article, hence indicating the presence of a threat.

Once a threat has been identified an analyst will use additional tools and techniques to investigate further and determine the extent of the threat and potential impact. This may involve isolating affected systems, gathering additional forensic evidence, and implementing mitigations to prevent further damage.

For example, if a threat intelligence article identifies the IP address 142.251.16.100 as malicious we may search the network logs to see if any of the systems in our estate have communicated with this IP address. Either they have been contacted by this IP address (typical indicating scanning activity) or they have reached out to this IP address (indicating C2 activity). These logs are usually ingested into a Security Event and Incident Management (SIEM) solution which allows us to perform search queries to look for IP addresses. In Splunk, such a query might look something like this.

* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" DestinationIp="142.251.16.100"

This query searches through the Sysmon logs collected on an endpoint device, and pushed to Splunk, for the destination IP address 142.251.16.100. The results of this can be seen below.

Aside from IP addresses, threat actors and malware will often use domain names to make network connections. These IOCs are often included in threat intelligence articles alongside IP addresses as either a domain name, hostname, or a specific URL. Domains are often used as C2 servers or to distribute malware in phishing attacks and hunting for them in your environment is often trivial if your organisation maintains DNS logs. These logs may come from a DNS server or through network logs and are likely to be ingested into a SIEM solution. We can query for domains in Splunk with the following query.

* "www.google.com"

This query searches all logs ingested in Splunk for the string www.google.com (a domain you may have heard of before). The results show a DNS query was made for this URL.

A threat intelligence article may also identify a specific file hash which we can use to perform an IOC-based hunt. The majority of cyber attacks are smash and grab jobs where attackers will re-use the same malware to target multiple systems. Once this malware is identified security vendors and MSSPs will spread this information via threat intelligence articles and list the the file hashes of the malware they detected so organisation can hunt for these hashes or add them to their block lists.

Analysts can hunt for file hashes by either using a SIEM solution, and looking at system logs, or by using an Endpoint Detection Response (EDR) solution that provides more detailed information on what is happening on endpoint devices. You can search for a file hash in Splunk with the following query.

* 43E1429166C69A4616CC1D2A88381D57DE73CF1D471CF8B551A9F7B44CA74E2C

This query searches all logs ingested in Splunk for the string 43E1429166C69A4616CC1D2A88381D57DE73CF1D471CF8B551A9F7B44CA74E2C (a malicious files SHA256 hash). Here we see that the malicious hash belongs to the file C:\Windows\Tasks\shell-x64.exe.

Now let’s take a look at how we hunt for a threat’s TTPs.

Threat Hunting TTPs and Sigma Rules

TTP-based threat hunting involves proactively identifying potential security threats based on known tactics, techniques, and procedures (TTPs) of threat actors. This approach relies on the idea that threat actors often use similar methods and strategies when carrying out attacks, and that by identifying these TTPs, organizations can better understand and respond to potential threats.

You will find that many threat intelligence articles list the TTPs that the security researcher found a certain threat exhibited. These TTPs are mapped to the MITRE ATT&CK framework which acts as a universal language for sharing attacker TTPs. Using the TTPs listed, and the MITRE ATT&CK framework, we can either find or make our own threat hunting queries that will detect the behaviour exhibited by the certain threat.

For instance, if a threat is using a Spearphishing Attachment (T1566.001) as an initial access vector then we can look for a query that will detect this behaviour or create our own. In this case, perhaps a query that finds if winword.exe (Word) is spawning a child process of cmd.exe (Command Prompt); this would indicate a Macro that uses the Windows Command Prompt is being run, very suspicious.

The aforementioned Splunk queries used the Splunk Searching Processing Language (SPL) for searching for IOCs. This language is specific to the Splunk SIEM solution and, although it has been adopted by other security solutions (most notably CrowdStrike’s EDR), it is not a universal detection language.

To hunt for TTPs we need a universal language for describing characteristics of the TTP that we can detect, be it a parent image spawning a particular child process with a specific command line or a certain Windows Security Event ID targeting a specific file location. So let me introduce you to Sigma rules.

Sigma rules are a set of open-source, community-driven rules for threat detection, security analytics, and SIEM systems. They are written in simple and flexible YAML syntax, which is easy to write and understand, and is security solution agnostic. They are made to be universal and can be translated to a wide range of security solutions from EDRs to SIEMs. These rules define conditions that, when met, indicate a potential security issue such as malware, phishing, brute-force attacks, lateral movement, and more.

These conditions can be based on various sources of data, including system logs, network traffic, and endpoint telemetry.

In threat hunting they are often used to describe a TTP used by a threat actor and include a mapping to the MITRE ATT&CK framework. This means we can easily find a Sigma rule for a specific TTP mentioned in a threat intelligence article. In fact, some threat intelligence articles will include Sigma rules which you can use to hunt for a threat’s TTPs!

Sigma represents a community-driven effort to promote standardization and sharing of detection rules across different security tools and platforms. The main Sigma rules repository is freely available on GitHub and you can use this repository to identify rules related to the MITRE ATT&CK TTPs expressed in threat intelligence articles.

That said, it is important to remember that the TTPs listed in the MITRE ATT&CK framework may differ from the ones a specific threat is using. There are multiple ways a Spearphishing Attachment (T1566.001) can be used to gain initial access. If you only have a query that detects winword.exe (Word) spawning cmd.exe (Command Prompt) then you will miss if excel.exe (Excel) or powerpnt.exe (PowerPoint) spawn cmd.exe.

This is illustrative of why there is so many Sigma rules listed on the SigmaHQ GitHub. There is so many ways to detect a TTP and so many ways to achieve a TTP that it is impossible to say you are 100% locked down from T1566.001 based on a few threat hunting queries you run.

To combat this defenders should focus on defence in-depth. This is a concept used in cybersecurity in which multiple layers of security controls are placed throughout an information technology system. This forces an attacker to bypass multiple security controls to achieve their objective and increases the likelihood of detection. Applied to TTP-based threat hunting this means running multiple queries for TTPs exhibited by a threat, and searching for multiple TTPs described by the threat intelligence article. This may involve running 50+ queries for one specific threat in an effort to detect just one of it’s TTPs! Here is where automation becomes very important.

Let’s take a look at finding a TTP in a threat intelligence article, finding a Sigma rule that detects this TTP, and translating this Sigma rule into SPL format to hunt for it using Splunk.

Using TTPs and Sigma Rules to Threat Hunt

To begin with, this article details how Medusa Ransomware uses a Scheduled Task as a means of Persistence once it infects a system (T1053.005). We can search for this MITRE ATT&CK technique in the SigmaHQ GitHub repository. In doing so we find the following rule named proc_creation_win_schtasks_creation.

This rule detects scheduled tasks being created using the built-in Windows executable schtasks.exe. Let’s now translate it into the query language specific to the security solution we will be hunting on (Splunk). We can either do this manually or automatically using uncoder.io (the preferred way). If we copy and paste the Sigma rule into the uncoder.io interface, select Splunk from the dropdown menu, and hit Translate we get the following output.

This is the Splunk query we can run to detect this specific TTP outlined in the threat intelligence article in our environment.

source="WinEventLog:*" AND ((Image="*\\\\schtasks.exe" AND CommandLine="* /create *") AND NOT (User="*AUTHORI*" OR User="*AUTORI*")) | table CommandLine,ParentCommandLine

Let’s give it a go.

Here we have found a schedule task called “Reverse Shell” being created that executes an executable every 1 minute named revshell.exe. We have successfully used a threat intelligence articles to hunt for IOCs and TTPs in you environment using the MITRE ATT&CK and Sigma rules!

However, our work may not be done yet. Next time we will look at how a senior threat intelligence analyst may use a threat intelligence article to write their own Sigma rules. Until then, happy hunting friends!

Discover more in the Load & Load: Actionable Threat Intelligence 101 series!