Applying the Pyramid of Pain in Threat Detection (EN)

post image

Pyramid of Pain


As part of my SOC Analyst training, I completed the Pyramid of Pain lab on TryHackMe. This lab explores the layers of cyber threat intelligence through the lens of the Pyramid of Pain model — a framework that helps blue teams understand how difficult it is for attackers to adapt when specific indicators are detected and blocked.

But the project goes beyond just understanding the pyramid — it connects theory with real-world applications using the MITRE ATT&CK Framework, MITRE D3FEND, Engage, CAR Knowledge Base, and more.

What This project Covers

Here are the key concepts and tools I explored :

The Pyramid of Pain

A threat detection framework developed by David Bianco. It categorizes indicators based on how disruptive they are to attackers:

  • Hash Values (Easy to evade)

  • IP Addresses

  • Domain Names

  • Host Artifacts

  • Network Artifacts

  • Tools

  • TTPs (Tactics, Techniques, and Procedures — the hardest to change)

MITRE ATT&CK

A globally accessible knowledge base of adversary tactics and techniques. I learned how to:

  • Map attacker behavior to ATT&CK TTPs

  • Understand its matrix structure

  • Apply ATT&CK in threat intel and detection scenarios

MITRE D3FEND

This is the defensive counterpart to ATT&CK. It helped me visualize:

  • How specific countermeasures map to attacker behaviors

  • How defenders can take strategic actions based on detection type

MITRE Engage & Emulation Plans

I discovered how Engage supports proactive adversary engagement, and how emulation plans based on ATT&CK can simulate real attacker behavior in lab environments.

CAR Knowledge Base

The Cyber Analytics Repository provides logic-based detection ideas mapped to ATT&CK techniques — a valuable asset for anyone building SOC detections or Sigma rules.

Why This Room Matters for SOC Analysts

Completing this room gave me insight into how threat intelligence actually translates into detection and response. Instead of just blocking hash values or IPs (which are easy for attackers to change), the goal is to detect patterns of behavior — tools used, methods followed, and techniques mapped to frameworks like ATT&CK.

This room strengthened my ability to:

  • Think beyond technical indicators

  • Use structured threat intelligence

  • Apply threat detection frameworks in a real-world SOC environment

 What Are Hash Values, and Why Do They Matter?

A hash value is a fixed-length string generated by a hashing algorithm to uniquely identify a piece of data. Hashes are essential in cybersecurity for identifying files, especially when analyzing malware or suspicious artifacts.

Security analysts rely on hash values in threat intelligence reports to track known malware samples and compare them across systems or databases.

Common Hash Algorithms:

  • MD5 (128-bit): Fast, but insecure due to known collision vulnerabilities. Deprecated in most security contexts.

  • SHA-1 (160-bit): Also considered weak and deprecated since 2011.

  • SHA-2 / SHA-256 (256-bit): Modern standard with improved collision resistance.

If two files generate the same hash, the algorithm is no longer considered cryptographically secure — a risk known as a collision.

Real-World Use: Hash Lookups

Threat researchers and SOC teams often use tools like:

to cross-check hash values against known malware databases.

VirusTotal

14 antivirus engines flagged the file as malicious, linking it to ransomware families such as WannaCry (Win32/Filecoder.WannaCryptor.D).

MetaDefender Cloud - OPSWAT:


Identifying a malicious file becomes quite straightforward when you already have the hash. Hash-based detection is fast and reliable — but only in static scenarios.

However, from an attacker’s perspective, altering a file's hash is incredibly easy. Even changing a single bit or appending a harmless string is enough to generate a completely different hash value.

With countless variants of the same malware or ransomware circulating in the wild, relying solely on file hashes as Indicators of Compromise (IOCs) can limit your visibility during threat hunting.


Demonstrating Hash Instability through File Modification

The screenshot below shows how a file’s hash can be altered by making a minimal change — in this case, by appending a string using echo. The original file was hashed using the Get-FileHash command with the MD5 algorithm. 

After appending a string to the end of the file, the same hash function produced a completely different value:

 IP Addresses as Indicators of Compromise

IP addresses are essential to network communication and device identification. While foundational to networking, their role as indicators of compromise (IOCs) is more nuanced. In the context of the Pyramid of Pain, IP addresses are considered lower-level indicators — represented in green — because they are relatively easy for an attacker to change.

From a defensive standpoint, knowing which IP addresses are associated with adversary infrastructure can help with blocking or filtering malicious traffic at the perimeter firewall. However, this strategy is limited in effectiveness, as attackers can rapidly pivot to new IPs using public infrastructure, VPNs, or dynamic DNS services.

Observed Malicious IP Activity

The screenshot below shows TCP connections initiated by a malicious binary to multiple IP addresses, all over port 443 — a common method of hiding communication behind encrypted HTTPS traffic.


Each IP address points to infrastructure hosted in different geographic regions, further complicating attribution or blocking.

Evasion Through Fast Flux

One way adversaries make IP-based blocking less effective is by leveraging Fast Flux — a DNS technique where multiple IPs are dynamically associated with a single domain. This technique is commonly used in botnets and phishing infrastructure.

Fast Flux is used to mask malware delivery and command-and-control (C2) communication by routing through rapidly changing compromised hosts. This makes detection and takedown significantly more difficult.

Malicious IP connections (app.any.run): app.any.run


Note: Do not attempt to interact with the IP addresses shown above.

Domain Names as Indicators of Compromise

As we move higher on the Pyramid of Pain, domain names represent a more persistent and slightly harder-to-change indicator compared to IP addresses. While IPs can be rapidly rotated or reassigned, domain names typically require registration, DNS configuration, and may be tied to other infrastructure such as certificates or hosting accounts.

From a defensive standpoint, domains are used in detection signatures, firewall rules, and threat intelligence feeds. However, challenges remain, some DNS providers offer lenient registration policies and automated APIs that allow attackers to register or rotate domains with minimal effort and oversight.

Domain names used in malicious campaigns can take several forms:

  • domain.tld (e.g., evilcorp.com)

  • sub.domain.tld (e.g., c2.evilcorp.com)

Understanding these naming patterns is essential in detecting C2 (Command and Control) infrastructure, phishing lures, and domain generation algorithms (DGAs).


Malicious Sodinokibi C2 Domains

The screenshot below shows a list of command-and-control domains associated with the Sodinokibi (REvil) ransomware campaign.



These domains are typically rotated across multiple campaigns and infrastructure points, enabling threat actors to evade detection and increase the longevity of their operations.


Domain Obfuscation Using Punycode and URL Shorteners

Attackers may register domain names that visually resemble legitimate brands by using Punycode - a method of encoding Unicode characters in a format that browsers can interpret. These domain names can bypass casual visual inspection and redirect users to malicious sites.

The screenshot below shows two addresses that appear identical (adidas.de), but the first one is encoded using Punycode and actually resolves to: http://xn--addas-o4a.de/

Browsers such as Chrome, Edge, Safari, and Firefox can now interpret these encoded domains. However, detection still relies on careful inspection or monitoring DNS and proxy logs.


Malicious Domains via URL Shorteners

To further conceal phishing or malware delivery infrastructure, attackers often use URL shortening services, which create redirects that hide the destination domain.

Common services abused for this purpose include:

bit.ly

goo.gl

ow.ly

tinyurl.com

x.co

smarturl.it

By appending a "+" to shortened URLs some services allow users to preview the actual destination — a basic, but useful, validation step during investigation.


Reviewing Network Activity in Any.run

Any.run provides sandbox-based dynamic analysis of malware samples. During execution, network activity is captured and displayed under the Networking tab. This includes:

  • HTTP Requests

  • DNS Requests

  • IP Connections

These insights are valuable for identifying command-and-control traffic, payload retrieval, or callback attempts.


Caution

Accessing any of the IP addresses or domains shown in analysis reports should be avoided. These indicators originate from live malware behavior and may lead to active or harmful infrastructure.


HTTP Requests

The HTTP Requests tab shows all outbound web traffic generated during execution. This includes requests to download secondary payloads (droppers), establish callbacks, or retrieve remote scripts.


Connections Tab

The Connections tab in Any.run displays all network communications initiated by the sample during execution. This includes outbound traffic such as:

  • Command and Control (C2) communication

  • File transfers (e.g., via FTP, HTTP/S)

  • Connections to remote hosts or services

Monitoring this tab can help identify the purpose of the malware's network activity and reveal potential indicators for detection or blocking.



DNS Requests Tab

The DNS Requests tab lists all domain resolution attempts made by the malware during execution. These requests may serve various purposes, including:

  • Verifying internet connectivity

  • Resolving domains for Command and Control (C2)

  • Identifying sandbox environments by testing DNS response behavior

DNS activity can provide early indicators of malicious intent, especially when combined with unusual domain patterns or known threat infrastructure.



Host Artifacts as Indicators of Compromise

Host artifacts refer to observable traces left by malware or adversary activity on the local system. These may include:

  • Suspicious process execution

  • Registry modifications

  • Dropped or modified files

  • Command-line usage patterns

Detection at this level is more impactful. When defenders identify and respond to host-level indicators, the attacker is often forced to modify their tools or techniques which consumes time and effort.

Suspicious Process Execution from Word

The screenshot below shows PowerShell being executed by a suspicious file dropped into a user path, likely initiated through Microsoft Word. This behavior is typical of macro-enabled attacks or document droppers.


Suspicious process execution from Word:


Suspicious events followed by opening a malicious application:

The sample initiates repeated TCP connections to an external IP and performs file write operations, both of which are strong host-level IOCs.


The files modified/dropped by the malicious actor:


Network Artifacts as Indicators of Compromise

Network artifacts fall within the yellow zone of the Pyramid of Pain. These include observable elements such as:

  • Unusual User-Agent strings

  • C2 URIs or patterns in HTTP/S traffic

  • Consistent header values or payload markers

Detection of these elements can delay an attacker by forcing changes in tooling or communication methods, increasing the defender’s response window.

Analyzing User-Agent Strings with TShark

The screenshot below shows a set of repeated User-Agent strings extracted from a PCAP file using TShark, the command-line version of Wireshark.

tshark -Y http.request -T fields -e http.user_agent -r analysis.pcap

In this example, the User-Agent string reflects an older configuration (MSIE 7.0, Media Center PC 6.0, multiple .NET CLR versions), which may indicate automation or a tool-based request rather than a standard browser.

Such artifacts are useful for developing detection rules or behavioral baselines within IDS or proxy log monitoring systems.

Tools as High-Level Indicators

Tools represent one of the highest-impact detection points in the Pyramid of Pain. When defenders successfully detect and block malicious tooling, it forces the adversary to significantly adjust  potentially abandoning the intrusion or investing in new tool development.

These tools may include:

  • Custom backdoors and droppers

  • Macro builders (for maldocs)

  • Credential stealers

  • Payload generators or obfuscated binaries

Detection at this level disrupts core capabilities of the attacker and often requires them to rewrite or replace core components of their toolkit.

The screenshot below shows a file named Stealer.exe dropped in the user's temporary directory a common staging location for malware artifacts.

A Trojan Dropped the Suspicious Stealer.exe in the Temp Folder

This file is likely part of a credential harvesting operation and demonstrates how threat actors use custom binaries as part of their tooling strategy.

The execution of the suspicious binary: 

The image below shows two suspicious binaries, payload.exe and Stealer.exe, both executed under the RussianPanda user context.

Enhancing Detection Against Tools

At the tools level of the Pyramid of Pain, defenders have access to highly effective countermeasures. Detection signatures, static rules, and behavioral analysis all contribute to identifying and stopping custom malware.

Common detection techniques include:

  • Antivirus signatures

  • YARA rules (used to detect known patterns within malware binaries)

  • Fuzzy hashing (e.g., SSDeep) to detect structurally similar files

Community resources such as MalwareBazaar, MalShare, and SOC Prime Threat Detection Marketplace provide access to samples, intelligence feeds, and crowdsourced detection rules that aid in rapid response.

Sample of SSDeep from VirusTotal:

These files are likely components of an attack chain, with overlapping behaviors. Fuzzy hashing techniques could be used to identify related variants with minimal differences.

Tactics, Techniques, and Procedures (TTPs)

TTPs represent the highest tier in the Pyramid of Pain and the most disruptive level for adversaries. This stage refers to the strategic and behavioral methods an attacker uses throughout the intrusion lifecycle as outlined in the MITRE ATT&CK framework.

TTPs include actions such as:

  • Spearphishing for initial access

  • Credential dumping for privilege escalation

  • Lateral movement via pass-the-hash or RDP

  • Persistence using scheduled tasks or registry keys

  • Data exfiltration using staging and compression tools

Why Detecting TTPs Matters

Detection at the TTP level significantly increases the chances of containment and eradication. Identifying behaviors rather than just file hashes or IPs  leaves the attacker with limited room to pivot.

For example, detecting a Pass-the-Hash attack via Windows Event Logs allows for rapid identification of the compromised host, enabling early intervention and stopping lateral movement.

At this point, an attacker typically has two options:

  1. Rebuild tooling, retrain, and restart the operation

  2. Abandon the target and move on

The latter is often the attacker’s preferred path when faced with a resilient, behavior-aware defense posture.

Conclusion

Completing this lab reinforced the importance of going beyond basic IOCs and focusing on higher-value indicators such as tools and TTPs. Understanding the Pyramid of Pain in a practical context helped clarify how detection at each layer impacts the adversary differently  and why behavior-based detection is essential in a modern SOC environment.

As a SOC analyst in training, this exercise has helped build the mindset needed for threat hunting: not just identifying artifacts, but thinking critically about how and where to detect real attacker behavior.

For continued development, I plan to:

  • Select a known APT group from public threat intelligence sources

  • Analyze their known indicators

  • Map them to the Pyramid of Pain

  • Practice building detection logic that focuses on harder-to-change behaviors

The goal is to move beyond reactive detection and toward disrupting the attacker’s operation at its core where it hurts the most.

Powered by Froala Editor

Comments (1)

Endurance Samson
Jul 10, 2025 10:36

Well detailed and explanatory. Great Job

Leave a Comment