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.
Here are the key concepts and tools I explored :
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)
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
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
I discovered how Engage supports proactive adversary engagement, and how emulation plans based on ATT&CK can simulate real attacker behavior in lab environments.
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.
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
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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 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.
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.
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
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:
Rebuild tooling, retrain, and restart the operation
Abandon the target and move on
The latter is often the attacker’s preferred path when faced with a resilient, behavior-aware defense posture.
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
Well detailed and explanatory. Great Job