Views: 46
Threat Intelligence is the analysis of data and information using tools and techniques to generate meaningful patterns to mitigate against potential risks associated with existing or emerging threats targeting organisations, industries, sectors or governments.
There are different classifications of Threat Intelligence, and the primary types of it are:
- Strategic Intel: High-level intel that looks into the organisation’s threat landscape and maps out the risk areas based on trends, patterns and emerging threats that may impact business decisions.
- Technical Intel: Examines evidence and artefacts of attacks an adversary uses. Incident Response teams can use this intel to create a baseline attack surface to analyse and develop defence mechanisms.
- Tactical Intel: Assesses adversaries’ tactics, techniques, and procedures (TTPs). This intel can strengthen security controls and address vulnerabilities through real-time investigations.
- Operational Intel: Assesses an adversary’s specific motives and intent to perform an attack. Security teams may use this intel to understand the critical assets available in the organisation (people, processes, and technologies) that threat actors may target.
Threat Intelligence Producers
Threat Intelligence Producers gather, analyse and disseminate threat intelligence data for others and themselves. This group includes cybersecurity vendors, research labs and organisations specialising in collecting and interpreting data on emerging cyber threats.
The Producers typically collect data using various methods and techniques. Standard methods include network monitoring, which involves monitoring an organisation’s network traffic to identify abnormal behaviour from the inside or a honeypot server exposed externally.
Another example could be a collection of IOCs based on internal incidents handled by an organisation.
Not every organisation can be a Producer.
Threat Intelligence Consumers
Threat Intelligence Consumers are organisations or individuals who consume Threat Intelligence created by Producers. The information gathered from different sources is utilised to improve the organisation’s security posture.
- Identifying vulnerabilities – Consumers can use published vulnerabilities discovered due to zero days launched by threat actors to identify vulnerabilities in an organisation’s infrastructure. Advisories such as CVE publications are commonly utilised to determine if an organisation is impacted by it and apply mitigations if needed.
- Prevention and Detection – Consumers can use IOCs to prevent intrusions by blocking these artefacts or detect them by applying them to threat detection rules.
- Incident Response – Consumers can use intelligence data to respond more effectively to incidents as the data may confirm the likelihood of the attack and the potentially attributed tactics and techniques.
- Collaborating with others – Information sharing is not only for Producers but also for Consumers. Data analysis of IOCs may still require human assessment, so it is helpful to share information that is validated to be beneficial for Security Operations.
Uncoder.io
Uncoder.io 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
Intelligence Driven Prevention
Domain Blocking through DNS Sinkhole
DNS Sinkhole is a security measure that mitigates connections to a malicious domain. This is typically done by redirecting all DNS requests from a known malicious domain to a sinkhole, preventing the resolution to their counterpart IP addresses.
Intelligence Driven Detection
Optimising Detection Capabilities
Implementing detection based on IOCs may be pretty straightforward, as one may think we can deploy a blocklist rule for known malicious IOCs.
Detection Use cases
Using IOCs,
| Indicator of Compromise | Detection Use Case |
|---|---|
| IP Address | Connections via Firewall logs wherein the direction of the connection dictates the potential root cause: • Egress connection to a malicious IP indicates a potential execution of malware, thus communicating with a threat actor’s IP address. • Ingress connection from a malicious IP dictates an intrusion attempt from malicious actors, showing traces of the pre-exploitation phase. |
| URL | Connections via Proxy logs wherein the HTTP method dictates the nature of the connection: • HTTP GET requests indicate a potential download of malicious files or access to a phishing website. • Moreover, HTTP POST requests indicate a potential submission of credentials or exfiltration of stolen files. |
| Domain | Malicious domains seen in DNS logs directly indicate a malicious activity in either of the following: • The domain hosts malware or additional files for its execution chain. • The domain is a phishing website. • The domain is being used for a C2 connection. |
From prevention logs,
| Prevention Technique | Detection Use Case |
|---|---|
| DNS Sinkhole | Domains resolving a loopback (127.0.0.1 or 0.0.0.0) may indicate a connection to a malicious domain based on DNS’ sinkhole blocklist configuration. |
| Firewall IP Blocking | Blocked connections to and from a specific IP address may indicate malicious activity and is worthy of investigation. Logs generated attributed to IOC blocking gives more context about the connection. |
| Proxy Blocking | Blocked web connections may indicate a malicious attempt to access malware or a phishing site. The Proxy service could provide more information if it has tagging capabilities to reflect malicious connections via tags. |
| Mail Gateway Blocking | Emails blocked based on the email sender’s domain may indicate a spam attempt from a malicious sender. |
Sigma is an open-source generic signature language to describe log events in a structured format. This allows for quick sharing of detection methods by security analysts. Sigma rule to hunt for DNS queries resolving 0.0.0.0
title: DNS Sinkhole
author: TryHackMe User
description: Sigma rule for sinkholed DNS queries
logsource:
category: dns
detection:
select_sinkholed:
dns.resolved_ip:
- '0.0.0.0'
condition: select_sinkholed
falsepositives:
- Unknown
status: experimental
level: medium
tags:
- dns
- filebeat
Equivalent KQL query fo generate ElastAlert (using uncoder.io)
alert:
- debug
description: Sigma rule for sinkholed DNS queries.
filter:
- query_string:
query: dns.resolved_ip:0\\.0\\.0\\.0
index: winlogbeat-*
name: DNS Sinkhole
priority: 3
realert:
minutes: 0
type: any
The resulting ElastAlert rule from Uncoder.io contains the following information:
| Field | Definition |
|---|---|
| alert | The Alerter type to use. The value debug will log the alert information at the info level. |
| filter | A list of Elasticsearch query filters. The current query searches for all domains resolving to 0.0.0.0. |
| index | The name of the index that will be searched. In our current context, the rule will scan the contents of the filebeat-* index. |
| realert | This option allows you to ignore repeating alerts for some time. The value minutes: 0 will generate all alerts despite its redundancy. |
| type | The rule type to use. The value any will generate an alert for every successful query return. |
Elastalert
elastalert --start 2023-02-16T00:00:00 --verbose 2>&1 | tee output.txt
The elastalert command above can be broken down as:
- ElastAlert executes the rule we configured starting from 02/16/2023 until the present.
- It also provides verbose output.
- Lastly, the snippet uses
2>&1 | tee output.txtto write the results into output.txt. Note that file descriptors were used since the output is being written at the INFO level.