QuentinRSmith/Threat-Intelligence-for-SOC
GitHub: QuentinRSmith/Threat-Intelligence-for-SOC
Stars: 1 | Forks: 0
# Threat-Intelligence-for-SOC
I will be going through a TryHackMe room to demonstrate how to utilise Threat Intelligence to improve the Security Operations pipeline.
# Introduction
In this room, we’ll focus on how Threat Intelligence strengthens the Security Operations pipeline and how shared information across teams can be used effectively. We’ll also cover who produces and consumes Threat Intelligence, the different types of intelligence, and how it can be applied to prevent and detect malicious activity.
# Threat Intellegence Feed
Threat Intelligence Producers collect, analyse, and share threat data. They gather information through methods like network monitoring, honeypots, and internal incident analysis, then publish reports, advisories, and IOC feeds for others to use. Being a Producer requires large data sets, strong analytical capability, and the resources to identify emerging threats.
Threat Intelligence Consumers use intelligence created by Producers to strengthen their security posture. They rely on shared data to identify vulnerabilities, block or detect malicious activity using IOCs, improve incident response, and collaborate by validating and sharing useful findings.
Whether an organisation is a Producer or Consumer depends on its resources, expertise, and the role its security team plays in gathering versus applying threat intelligence.
First, we will hunt and consume IOCs provided by Threat Intelligence Producers.
We start by starting our VPM and logging in
We will now be using uncoder.io which is an online tool that transforms Sigma rules, IOC lists, and other platform query syntaxes into custom hunting queries prepared for execution in SIEM and XDR. It is an easy-to-use tool that could assist us in hunting the following IOCs up for investigation. For IOCs, the tool accepts six different types of IOCs, namely:
IPs
Domains
URLs
Hashes
Emails
Files
Next, we use the following IP list and upload it to Uncoder. After pasting the IOCs, Uncoder will automatically clean defanged IPs and remove duplicates, leaving four unique addresses.
IP list:
135[.]181[.]103[.]89
185[.]224[.]126[.]215
185[.]224[.]128[.]215
171[.]24[.]136[.]15
171[.]22[.]136[.]15
195[.]133[.]40[.]108
103[.]190[.]37[.]169
103[.]170[.]37[.]169
103[.]190[.]37[.]169
185[.]224[.]128[.]215
107[.]175[.]202[.]151
107[.]175[.]202[.]158
195[.]133[.]40[.]108
107[.]175[.]202[.]158
109[.]206[.]240[.]194
We come out with the following result:
The result of using the tool can be utilised in our Kibana Instance via the Discover feature.
We will paste the destination and add the time frames of 2/14/23 - 2/17/23 in Elastic and come out with the following:
From this, we can see things such as how many connections were made to certain addresses:
We can see the IP address of the compromised host:
Lastly, we can see the destination port of IP: 107.175.202.151:
# Intelligence-Driven Prevention
Now in this room:
Your organisation has identified itself as a consumer of Threat Intelligence, meaning your role is to use intelligence from trusted sources to deploy security controls and prevent threats in your environment. Using the IOCs provided by these sources, you can strengthen your defences by blocking or detecting malicious activity.
To begin, it helps to simplify the common types of IOCs found in threat feeds:
Domains – Often linked to malicious hosting, C2 servers, or spam activity.
IP Addresses – Typically associated with known attack sources or malware callbacks.
These IOCs form the basis of the controls you will apply to protect your infrastructure.
**IP Block Via Firewall**
IP blocking is a common security control that stops inbound or outbound traffic based on the IP address attempting the connection, typically enforced through firewall rules. While firewall configuration can feel complex, blocking known malicious IPs is an effective first step. Doing so helps prevent intrusive connections that could disrupt services or exploit vulnerabilities, and it also stops infected systems from reaching a threat actor’s infrastructure after malware execution.
Next we will use SIEM logs to hunt for any activity involving domains flagged as malicious by your DNS Sinkhole. Starting with the provided domain agrosaoxe[.]info and run searches using the KQL templates below by replacing the placeholders with the domain and your sinkhole IP:
dns.question.name: "agrosaoxe.info"
dns.answers.data: "sinkhole_IP_here"
We see that there are 11 DNS queries to agrosaoxe[.]info that has been created
Next, we see the IPv4 addresses are resolved by agrosaoxe[.]info and the IP address used for DNS Sinkhole
Lastly, we see how many hits were caused by connections to sinkholed domains which is 115
# Intellegence-Driven Detection
Our next task in this room:
You have successfully deployed preventive mechanisms to mitigate known IOCs in your infrastructure. To maximise the capabilities of your detection and response, you are now tasked to improve the detection capabilities of your tooling.
We have started utilising Threat Intelligence from the previous task to prevent potential compromises from malicious actors. Now, we will leverage Threat Intelligence IOCs to know if something suspicious is happening in our infrastructure effectively.
In this task, we will use the following Sigma rule to hunt for sinkholed domains
The Sigma rule searches for DNS queries that resolve to 0.0.0.0, which often indicates a domain blocked by your DNS Sinkhole. Seeing this resolution in logs can signal attempts to reach a known malicious domain based on your sinkhole configuration.
Use Uncoder.io to convert the Sigma rule into an ElastAlert format. Set the conversion direction to Sigma → ElastAlert, then click Translate to generate the ElastAlert version of the rule.
To begin working with ElastAlert, I connected to the machine via SSH using the provided credentials and navigated to the ~/elastalert directory. This directory contains the main config.yaml file, which defines how ElastAlert connects to the Elasticsearch instance, and a rules subdirectory that includes a placeholder rule named sinkhole.yaml.
I replaced the contents of sinkhole.yaml with the ElastAlert rule generated from Uncoder.io after converting the Sigma rule. Before saving it, I made two required adjustments:
I removed everything in the description line starting from Author: to ensure valid syntax.
I updated the index value from winlogbeat-* to filebeat-* so the rule queries the correct data source.
After these changes, the rule defined an alert that triggers whenever DNS queries resolve to 0.0.0.0, which indicates a sinkholed domain.
Once the rule was configured, I returned to the main ElastAlert directory and executed ElastAlert using a command that starts evaluation from February 16, 2023, prints verbose output, and writes the results to output.txt. I allowed the process to run until ElastAlert reported that it had completed its initial query cycle, indicated by a summary showing the number of hits, matches, and alerts sent. After that, I stopped the process with CTRL+C.
This completed the setup, configuration, and execution of the ElastAlert rule for detecting sinkholed DNS activity.
# Conclusion
In the previous tasks, we covered the key differences between Threat Intelligence Producers and Consumers and why understanding your organisation’s needs and capabilities is essential for getting value from intelligence. We also explored how to apply intelligence‑driven prevention and detection, using tools like Sigma, Uncoder, and ElastAlert to build practical detection logic.
Overall, this room focused on how Threat Intelligence can strengthen a Security Operations Center by improving both detection capabilities and preventive controls against known threats. In a landscape where threats constantly evolve, organisations must make full use of shared intelligence—whether produced by dedicated research teams or refined through feedback from consumers. Through collaboration and shared knowledge, we can collectively improve the security posture of every organisation.
We will now be using uncoder.io which is an online tool that transforms Sigma rules, IOC lists, and other platform query syntaxes into custom hunting queries prepared for execution in SIEM and XDR. It is an easy-to-use tool that could assist us in hunting the following IOCs up for investigation. For IOCs, the tool accepts six different types of IOCs, namely:
IPs
Domains
URLs
Hashes
Emails
Files
Next, we use the following IP list and upload it to Uncoder. After pasting the IOCs, Uncoder will automatically clean defanged IPs and remove duplicates, leaving four unique addresses.
IP list:
135[.]181[.]103[.]89
185[.]224[.]126[.]215
185[.]224[.]128[.]215
171[.]24[.]136[.]15
171[.]22[.]136[.]15
195[.]133[.]40[.]108
103[.]190[.]37[.]169
103[.]170[.]37[.]169
103[.]190[.]37[.]169
185[.]224[.]128[.]215
107[.]175[.]202[.]151
107[.]175[.]202[.]158
195[.]133[.]40[.]108
107[.]175[.]202[.]158
109[.]206[.]240[.]194
We come out with the following result:
The result of using the tool can be utilised in our Kibana Instance via the Discover feature.
We will paste the destination and add the time frames of 2/14/23 - 2/17/23 in Elastic and come out with the following:
From this, we can see things such as how many connections were made to certain addresses:
We can see the IP address of the compromised host:
Lastly, we can see the destination port of IP: 107.175.202.151:
# Intelligence-Driven Prevention
Now in this room:
Your organisation has identified itself as a consumer of Threat Intelligence, meaning your role is to use intelligence from trusted sources to deploy security controls and prevent threats in your environment. Using the IOCs provided by these sources, you can strengthen your defences by blocking or detecting malicious activity.
To begin, it helps to simplify the common types of IOCs found in threat feeds:
Domains – Often linked to malicious hosting, C2 servers, or spam activity.
IP Addresses – Typically associated with known attack sources or malware callbacks.
These IOCs form the basis of the controls you will apply to protect your infrastructure.
**IP Block Via Firewall**
IP blocking is a common security control that stops inbound or outbound traffic based on the IP address attempting the connection, typically enforced through firewall rules. While firewall configuration can feel complex, blocking known malicious IPs is an effective first step. Doing so helps prevent intrusive connections that could disrupt services or exploit vulnerabilities, and it also stops infected systems from reaching a threat actor’s infrastructure after malware execution.
Next we will use SIEM logs to hunt for any activity involving domains flagged as malicious by your DNS Sinkhole. Starting with the provided domain agrosaoxe[.]info and run searches using the KQL templates below by replacing the placeholders with the domain and your sinkhole IP:
dns.question.name: "agrosaoxe.info"
dns.answers.data: "sinkhole_IP_here"
We see that there are 11 DNS queries to agrosaoxe[.]info that has been created
Next, we see the IPv4 addresses are resolved by agrosaoxe[.]info and the IP address used for DNS Sinkhole
Lastly, we see how many hits were caused by connections to sinkholed domains which is 115
# Intellegence-Driven Detection
Our next task in this room:
You have successfully deployed preventive mechanisms to mitigate known IOCs in your infrastructure. To maximise the capabilities of your detection and response, you are now tasked to improve the detection capabilities of your tooling.
We have started utilising Threat Intelligence from the previous task to prevent potential compromises from malicious actors. Now, we will leverage Threat Intelligence IOCs to know if something suspicious is happening in our infrastructure effectively.
In this task, we will use the following Sigma rule to hunt for sinkholed domains
The Sigma rule searches for DNS queries that resolve to 0.0.0.0, which often indicates a domain blocked by your DNS Sinkhole. Seeing this resolution in logs can signal attempts to reach a known malicious domain based on your sinkhole configuration.
Use Uncoder.io to convert the Sigma rule into an ElastAlert format. Set the conversion direction to Sigma → ElastAlert, then click Translate to generate the ElastAlert version of the rule.
To begin working with ElastAlert, I connected to the machine via SSH using the provided credentials and navigated to the ~/elastalert directory. This directory contains the main config.yaml file, which defines how ElastAlert connects to the Elasticsearch instance, and a rules subdirectory that includes a placeholder rule named sinkhole.yaml.
I replaced the contents of sinkhole.yaml with the ElastAlert rule generated from Uncoder.io after converting the Sigma rule. Before saving it, I made two required adjustments:
I removed everything in the description line starting from Author: to ensure valid syntax.
I updated the index value from winlogbeat-* to filebeat-* so the rule queries the correct data source.
After these changes, the rule defined an alert that triggers whenever DNS queries resolve to 0.0.0.0, which indicates a sinkholed domain.
Once the rule was configured, I returned to the main ElastAlert directory and executed ElastAlert using a command that starts evaluation from February 16, 2023, prints verbose output, and writes the results to output.txt. I allowed the process to run until ElastAlert reported that it had completed its initial query cycle, indicated by a summary showing the number of hits, matches, and alerts sent. After that, I stopped the process with CTRL+C.
This completed the setup, configuration, and execution of the ElastAlert rule for detecting sinkholed DNS activity.
# Conclusion
In the previous tasks, we covered the key differences between Threat Intelligence Producers and Consumers and why understanding your organisation’s needs and capabilities is essential for getting value from intelligence. We also explored how to apply intelligence‑driven prevention and detection, using tools like Sigma, Uncoder, and ElastAlert to build practical detection logic.
Overall, this room focused on how Threat Intelligence can strengthen a Security Operations Center by improving both detection capabilities and preventive controls against known threats. In a landscape where threats constantly evolve, organisations must make full use of shared intelligence—whether produced by dedicated research teams or refined through feedback from consumers. Through collaboration and shared knowledge, we can collectively improve the security posture of every organisation.