Chapter 7: Digital Forensics and Malware Analysis

Learning Objectives

Classify evidence types: best evidence, corroborative evidence, and indirect (circumstantial) evidence
Interpret OS logs (Windows Event IDs, Linux syslog/auditd), SIEM correlation, and SOAR playbooks to identify security events
Analyze output from malware analysis tools including sandboxes and detonation chambers
Recognize IOC indicators from file hashes, URLs, network artifacts, and system artifacts; understand STIX/TAXII distribution

Section 1: Evidence Types and Classification

Digital evidence is any binary data — stored on or transmitted by a computing device — that can be used in an investigation. Its sources span hard drive images, packet captures, audit logs, deleted file fragments, and memory dumps. Evidence is not equally useful: courts apply a classification hierarchy that determines how much weight each piece carries and what documentation is required.

The Three Core Evidence Classes

Best Evidence

Best evidence is the original, unaltered record. In digital forensics, best evidence includes:

An unmodified disk image captured with a write-blocker
Original log files with intact timestamps and SHA-256-verified checksums
Unedited CCTV or body-camera footage
A forensic memory dump taken directly from a live system

A SHA-256 hash taken at acquisition time and re-verified at every subsequent step is the mechanism by which analysts prove a file has not changed.

Corroborative Evidence

Corroborative evidence supports and reinforces primary evidence. It does not prove the main fact on its own, but it makes the primary evidence more credible. Examples:

Browser history that corroborates the timeline established by server-side access logs
Firewall logs that confirm traffic was blocked at the same time an alert fired in the SIEM
IP geolocation records that support claims about connection origin

Indirect (Circumstantial) Evidence

Indirect evidence does not directly prove a fact — instead, it allows a reasonable inference about what happened. Examples:

Deleted files recovered from unallocated disk space (imply files once existed)
Prefetch records suggesting a program was executed even if the executable was removed
Residual registry keys suggesting a program was installed then uninstalled
Outbound DNS queries to an unusual domain suggesting C2 communication

Evidence Type	Definition	Digital Example	Strength
Best Evidence	Original, unaltered record	SHA-256-verified disk image	Highest — direct proof
Corroborative	Supports and reinforces primary evidence	Firewall log matching SIEM alert	Medium — strengthens primary
Indirect/Circumstantial	Allows inference about a fact	Deleted temp files suggesting execution	Variable — builds cumulatively

Chain of Custody

Chain of custody is the documented, unbroken record of who collected evidence and when, how it was transported and stored, who accessed it and for what purpose, and what transformations were performed. A practical form records the SHA-256 hash of every artifact at the moment of collection. Before analysis, the hash is re-verified. If hashes do not match, the evidence may be inadmissible.

Rules of Evidence

For digital evidence to be accepted in legal proceedings, it must satisfy four properties:

Authentic — it is what it claims to be (proven via hash verification and documentation)
Complete — it tells the whole story, not a cherry-picked fragment
Reliable — collected using sound, repeatable methods
Believable — can be explained to a judge or jury in plain terms

FIGURE 7.1 — Evidence Classification and Chain of Custody Flow

Key Points — Evidence Types and Classification

Best evidence is the original artifact with a hash-verified chain of custody — the gold standard in investigations and legal proceedings.
Corroborative evidence strengthens the primary case by independently confirming the same facts from a different source.
Indirect evidence alone is weak, but ten pieces pointing in the same direction create a compelling circumstantial case.
A broken chain of custody can render even perfect evidence inadmissible — document every collection, transfer, and access event.
SHA-256 is the required hash algorithm for forensic evidence verification; re-hash before every analysis step.

flowchart TD E[Digital Evidence] --> CF[Computer Forensics\nDisk images, file systems] E --> NF[Network Forensics\nPacket captures, flow data] E --> MF[Mobile Device Forensics\nPhone storage, app data] E --> MEM[Memory Forensics\nVolatile RAM — processes] E --> MM[Multimedia Forensics\nImage / video / audio] CF --> CF_T["Autopsy · FTK · EnCase"] NF --> NF_T["Wireshark · Zeek · NetworkMiner"] MF --> MF_T["Cellebrite · Oxygen Forensics"] MEM --> MEM_T["Volatility · Rekall"] MM --> MM_T["ExifTool · FotoForensics"] style E fill:#0d2137,stroke:#58a6ff,color:#e6edf3 style CF fill:#161b22,stroke:#58a6ff,color:#e6edf3 style NF fill:#161b22,stroke:#58a6ff,color:#e6edf3 style MF fill:#161b22,stroke:#58a6ff,color:#e6edf3 style MEM fill:#161b22,stroke:#58a6ff,color:#e6edf3 style MM fill:#161b22,stroke:#58a6ff,color:#e6edf3 style CF_T fill:#0d1117,stroke:#30363d,color:#8b949e style NF_T fill:#0d1117,stroke:#30363d,color:#8b949e style MF_T fill:#0d1117,stroke:#30363d,color:#8b949e style MEM_T fill:#0d1117,stroke:#30363d,color:#8b949e style MM_T fill:#0d1117,stroke:#30363d,color:#8b949e

Pre-Check — Section 1: Evidence Types

1. An analyst captures a disk image with a write-blocker and records its SHA-256 hash. What class of evidence is this?

Indirect evidence Corroborative evidence Best evidence Hearsay evidence

2. Firewall logs that independently confirm the same blocked connection recorded in a SIEM alert are an example of what?

Best evidence Corroborative evidence Indirect evidence Chain of custody

3. Prefetch records suggesting a malicious executable ran, even though the executable was deleted, are classified as:

Best evidence Corroborative evidence Indirect (circumstantial) evidence Documentary evidence

Section 2: Log Analysis and Event Identification

Logs are the primary narrative of any security incident. Every operating system, application, network device, and security platform generates log records as it operates. The investigator's job is to correlate these records across sources and reconstruct a coherent timeline.

Windows Event Logs

Windows Event Logs are stored in .evtx format under C:\Windows\System32\winevt\Logs\. The most security-relevant event IDs:

Log Channel	Event ID	What It Records
Security	4624	Successful logon
Security	4625	Failed logon — watch for brute force patterns
Security	4648	Logon using explicit credentials (pass-the-hash indicator)
Security	4688	Process creation — records command execution
Security	4698 / 4702	Scheduled task created / modified (persistence)
Security	4720 / 4732	User account created / added to privileged group
System	7045	New service installed — common malware persistence method
Security	4104	PowerShell Script Block Logging — full script content

Pattern: Lateral Movement Detection

Event 4625 (failed logon) for administrator from 192.168.10.45 — 47 times in 90 seconds
Event 4624 (successful logon) from the same IP — logon type 3 (network logon)
Event 4688 (process creation) — cmd.exe spawned by services.exe

This sequence — brute force → network logon → command shell from a service process — is a classic indicator of credential stuffing and remote command execution via a compromised service account.

Linux / syslog

File	Contents
`/var/log/auth.log`	SSH logins, sudo usage, PAM authentication
`/var/log/syslog`	General system messages
`/var/log/kern.log`	Kernel messages — driver errors, network issues
`/var/log/secure` (RHEL/CentOS)	Authentication events
`/var/log/audit/audit.log`	Auditd events — file access, syscalls

A burst of "Failed password" entries from a single IP followed by "Accepted password" is the syslog signature of a successful brute-force attack.

SIEM: Aggregation, Correlation, and Alerting

A SIEM ingests log data from hundreds of sources, normalizes it into a common schema, and applies correlation rules. A single failed login is noise. Ten thousand failed logins across fifty accounts from one IP in five minutes is an alert. Common platforms: Splunk (SPL), Microsoft Sentinel (KQL), IBM QRadar, ELK Stack.

SIEM workflow:

Collection — agents push logs to the SIEM
Normalization — raw data parsed into structured fields
Indexing — records stored for search
Correlation — rules match patterns across multiple events
Alerting — correlation rule fires; alert routed to SOC queue
Investigation — analysts query raw logs surrounding the alert

index=windows EventCode=4656 Object_Name="*lsass*" Access_Mask="0x1410"
| stats count by ComputerName, Account_Name, Process_Name
| where count > 1

This Splunk SPL query detects attempts to open a handle to lsass.exe with read permission — the hallmark of credential dumping tools like Mimikatz.

SOAR: Automated Response Playbooks

SOAR platforms take SIEM alerts and execute automated response workflows (playbooks). A typical phishing SOAR playbook:

Receive alert: "User clicked suspicious URL"
Automatically query VirusTotal for URL hash score
Pull email headers, extract sender, reply-to, originating IP
Check originating IP against threat intelligence feeds
If malicious: quarantine inbox, block URL at proxy, create ITSM ticket
Notify SOC analyst with pre-populated summary for human review

SOAR reduces mean-time-to-respond (MTTR) from hours to minutes. Platforms include Palo Alto XSOAR, Splunk SOAR, and IBM Security SOAR.

Application and Command-Line Logs

A typical suspicious Apache log entry:

192.168.1.100 - admin [15/Jan/2026:03:15:42 +0000] "GET /admin/config.php?cmd=id HTTP/1.1" 200 1234 "-" "curl/7.68.0"

Red flags: cmd=id parameter (command injection attempt), user-agent curl/7.68.0 (automated tool), HTTP 200 response (succeeded), /admin/ from external IP (privileged path accessed remotely).

PowerShell Event ID 4104 logs the full content of scripts as they execute. An encoded command:

powershell.exe -EncodedCommand JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0...

is a strong indicator of obfuscation — decoding the Base64 payload in a sandbox often reveals a reverse shell or dropper.

FIGURE 7.2 — SIEM Collection and SOAR Response Pipeline

Key Points — Log Analysis and Event Identification

Windows Event ID 4624/4625 (successful/failed logon) and 4688 (process creation) are the three most critical security log events for detecting intrusions.
SIEM correlation transforms raw log noise into actionable alerts by matching patterns across multiple log sources simultaneously.
SOAR playbooks automate high-volume, well-understood responses — reducing MTTR from hours to minutes while freeing analysts for complex investigations.
PowerShell Event ID 4104 (Script Block Logging) is the highest-value single log source for detecting PowerShell-based attacks; Base64-encoded commands indicate obfuscation.
Web server logs with cmd= parameters in URLs, non-browser user-agents, and HTTP 200 responses to admin paths are strong command injection indicators.

sequenceDiagram participant SIEM as SIEM participant SOAR as SOAR Playbook participant VT as VirusTotal API participant TI as Threat Intel Feed participant FW as Proxy / Firewall participant ITSM as ITSM (Ticket) participant SOC as SOC Analyst SIEM->>SOAR: Alert — "User clicked suspicious URL" SOAR->>VT: Query URL hash score VT-->>SOAR: Score: Malicious (87/90 engines) SOAR->>TI: Check originating IP reputation TI-->>SOAR: IP listed — known C2 infrastructure SOAR->>FW: Block URL at proxy SOAR->>ITSM: Create incident ticket (pre-populated) SOAR->>SOC: Notify — summary report for human review SOC->>SOC: Validate, escalate, or close

Post-Check — Section 2: Log Analysis

4. Which Windows Event ID records a new service being installed — a common malware persistence method?

4624 4688 7045 4698

5. An analyst sees 47 Event ID 4625 entries from 192.168.10.45 in 90 seconds, followed immediately by a 4624 (network logon) and then a 4688 with cmd.exe spawned by services.exe. What does this pattern indicate?

Normal user login activity Credential brute force followed by lateral movement via remote command execution A failed software deployment Scheduled task execution

6. What is the primary purpose of a SOAR playbook compared to a SIEM?

SOAR stores more logs than SIEM SOAR provides better log normalization SOAR automatically executes response actions when SIEM alerts fire, reducing MTTR SOAR replaces the need for human SOC analysts

7. A PowerShell command line contains -EncodedCommand JABjAGwAaQBlAG4AdA.... What does this indicate?

Legitimate administrative scripting Base64 obfuscation — likely a dropper or reverse shell concealing its payload A scheduled task running a backup script Standard PowerShell remoting syntax

Section 3: Malware Analysis Techniques

Analyzing malware presents a fundamental problem: to understand what it does, you must run it — but running it risks infecting your analysis environment. The solution combines two complementary approaches: static analysis (examining code without executing it) and dynamic analysis (executing it in a controlled, isolated environment).

Static Analysis

Static analysis examines a malware sample without executing it. Key techniques:

File Identification and Hashing

The first step is always to hash the file:

sha256sum suspicious_file.exe
# e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Submit the SHA-256 hash to VirusTotal or threat intelligence databases — this immediately reveals if the file is a known malware family.

String Extraction

Running strings against a binary extracts printable ASCII/Unicode sequences, often revealing hardcoded C2 addresses, file paths for dropped payloads, registry persistence keys, and HTTP user-agent strings.

strings -n 8 malware.exe | grep -E "(http|https|cmd|powershell|HKCU|HKLM)"

PE Header Analysis

For Windows PE format executables, tools like PEStudio examine:

Import Address Table (IAT) — API functions the binary calls. CreateRemoteThread, VirtualAllocEx, WriteProcessMemory indicate process injection.
Section entropy — packed/encrypted sections have high entropy (close to 8.0). Normal code runs 5–6.
Digital signature — is the file signed? Is the signature valid or revoked?
Compilation timestamp — can provide context (though easily falsified)

Disassembly and Decompilation

Ghidra (NIST-released, free) and IDA Pro disassemble binary code into assembly language or pseudo-C, allowing analysts to trace execution logic and identify anti-analysis techniques.

Dynamic Analysis: Sandboxes and Detonation Chambers

When a sample is heavily packed, obfuscated, or uses runtime decryption, dynamic analysis in a sandbox or detonation chamber is required.

Feature	Sandbox	Detonation Chamber
Primary purpose	Automated behavioral analysis	Deep investigation, often manual
Implementation	Cloud-based VM, automated	Full emulation or dedicated hardware
Speed	Minutes per sample	Minutes to hours
Output	Automated report + IOC extraction	Detailed forensic artifacts
Examples	Cuckoo, Any.run, Hybrid Analysis	FireEye Malware Analysis, Falcon X

The Sandbox Detonation Workflow

File submission — analyst uploads sample via UI or API
Pre-filter — quick signature check; known malware flagged immediately
Detonation — sample executes in isolated VM (Windows, Linux, or Android)
Event logging — sandbox monitors all system activity during execution
Report generation — analysis returned in human-readable format, typically within minutes

What the Sandbox Monitors

Artifact Category	Specific Observations
Network communications	DNS queries, HTTP/HTTPS requests, C2 beacon patterns
File system changes	Files created, modified, or deleted; dropped payloads
Registry modifications	Persistence keys added (Run, RunOnce, Services)
Process activity	Child processes spawned, process injection, code hollowing
Memory operations	Heap allocations, injected shellcode
System calls	API function calls and their arguments

Interpreting a Sandbox Report

VERDICT: MALICIOUS (High Confidence)
MALWARE FAMILY: Ransomware — LockBit variant

NETWORK ACTIVITY:
  DNS: resolves lockbit-news.onion.to — [C2 CHECK-IN]
  HTTP POST: http://45.33.32.156/upload — [DATA EXFILTRATION]

FILE SYSTEM:
  CREATED: C:\Users\Public\readme.txt — [RANSOM NOTE]
  MODIFIED: 847 files with extension change to .locked

REGISTRY:
  HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svchost32 — [PERSISTENCE]

PROCESS:
  cmd.exe -> vssadmin.exe delete shadows /all /quiet — [SHADOW COPY DELETION]

MITRE ATT&CK MAPPING:
  T1486 — Data Encrypted for Impact
  T1490 — Inhibit System Recovery
  T1547.001 — Registry Run Keys / Startup Folder

Sandbox Evasion Techniques

Technique	How It Works	Detection Approach
Sleep/Delay	Sleeps longer than sandbox timeout (e.g., 10 min)	Accelerate system clock in sandbox
VM detection	Checks for VMware/VirtualBox artifacts	Use bare-metal sandboxes or mask VM indicators
Human interaction check	Waits for mouse movement or keystrokes	Sandbox simulates user activity
Environment fingerprinting	Checks screen resolution, username, file count	Configure sandbox with realistic profiles
Anti-debugging	Detects debugger via timing or API checks	Use stealthy debugger configurations

flowchart TD START([Suspicious File Received]) --> HASH[Hash the file — sha256sum] HASH --> VT{Known in VirusTotal?} VT -- Yes --> REPORT1[Document family and IOCs] VT -- No --> STATIC[Static Analysis\nStrings · PE headers · Disassembly] STATIC --> PACKED{Packed / Obfuscated?} PACKED -- No --> STATICDONE[Document findings\nImports, C2 strings, artifacts] PACKED -- Yes --> DYNAMIC[Dynamic Analysis\nSandbox / Detonation Chamber] DYNAMIC --> MONITOR[Monitor: Network · Registry\nFile system · Processes] MONITOR --> SANDBOX_REPORT[Sandbox Report\nIOCs + ATT&CK mapping] STATICDONE --> COMBINE[Combine Findings] SANDBOX_REPORT --> COMBINE REPORT1 --> COMBINE COMBINE --> SHARE[Share via STIX/TAXII\nUpdate SIEM rules] style START fill:#0d2137,stroke:#58a6ff,color:#e6edf3 style HASH fill:#161b22,stroke:#58a6ff,color:#e6edf3 style VT fill:#1a1200,stroke:#d29922,color:#e6edf3 style PACKED fill:#1a1200,stroke:#d29922,color:#e6edf3 style DYNAMIC fill:#1a0a0a,stroke:#f85149,color:#e6edf3 style MONITOR fill:#1a0a0a,stroke:#f85149,color:#e6edf3 style SANDBOX_REPORT fill:#0a1f0a,stroke:#3fb950,color:#e6edf3 style COMBINE fill:#161b22,stroke:#58a6ff,color:#e6edf3 style SHARE fill:#0a1f0a,stroke:#3fb950,color:#e6edf3

FIGURE 7.3 — Sandbox / Detonation Chamber Workflow

Key Points — Malware Analysis Techniques

Static analysis (hash, strings, PE header) is fast and safe; dynamic analysis in a sandbox reveals runtime behavior that static methods cannot — use both together.
High section entropy (close to 8.0) in a PE file indicates packing or encryption — a strong indicator that dynamic analysis is required.
Sandbox reports map every observed behavior to MITRE ATT&CK technique IDs, providing immediate operational context for SIEM rule creation.
Malware evasion techniques (sleep delays, VM detection, human interaction checks) are countered by sandboxes with clock acceleration, bare-metal environments, and simulated user activity.
Vssadmin.exe deleting shadow copies (delete shadows /all /quiet) is the definitive behavioral indicator of ransomware — T1490 Inhibit System Recovery.

Post-Check — Section 3: Malware Analysis

8. A PE file's .text section shows an entropy value of 7.9. What does this indicate?

Normal compiled code — no concern The file is compressed or packed, concealing its code — warrants dynamic analysis The file is digitally signed The file uses standard Windows APIs

9. During sandbox detonation, a sample executes vssadmin.exe delete shadows /all /quiet. Which MITRE ATT&CK technique does this map to?

T1486 — Data Encrypted for Impact T1490 — Inhibit System Recovery T1547.001 — Registry Run Keys T1059 — Command and Scripting Interpreter

10. What does the presence of CreateRemoteThread, VirtualAllocEx, and WriteProcessMemory in a PE file's Import Address Table strongly indicate?

The file is a legitimate multimedia codec The file uses network sockets for communication The file performs process injection into another running process The file is digitally signed by Microsoft

11. A malware sample detects a mouse cursor that hasn't moved in 3 minutes and refuses to execute its payload. What evasion technique is this?

Sleep/Delay evasion VM detection via registry key check Human interaction check — waits for user activity before detonating Anti-debugging via timing analysis

Section 4: IOC Recognition and Threat Intelligence

An Indicator of Compromise (IOC) is a forensic artifact that, when observed in a system or network, indicates with high confidence that a security breach has occurred or is in progress. IOCs are the actionable outputs of malware analysis and incident investigation — they answer: "What observable evidence can we use to detect this threat?"

File-Level IOCs: Hash Values

The most precise IOC for a specific file is its cryptographic hash. SHA-256 is the current standard:

Algorithm	Output Length	Current Status	Use Case
MD5	128-bit (32 hex chars)	Deprecated — collision-prone	Legacy systems only
SHA-1	160-bit (40 hex chars)	Deprecated	Legacy compatibility
SHA-256	256-bit (64 hex chars)	Preferred standard	All modern forensic and IOC use
SHA-512	512-bit (128 hex chars)	High security	Sensitive data integrity
ssdeep	Variable (fuzzy hash)	Active use	Similarity matching between variants

ssdeep (fuzzy hashing) identifies malware variants that share significant code regions — useful for tracking malware families even after recompilation.

Network-Level IOCs

IP Addresses

IP IOCs have a short shelf life — attackers frequently rotate infrastructure. Validation rules:

Exclude private RFC1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Exclude loopback (127.0.0.0/8) and link-local (169.254.0.0/16)
Verify against threat intelligence feeds before blocking
Check passive DNS history for context

Domain Names

Domain IOCs are more stable than IPs. Malicious domains frequently show:

Very recent registration (days before the attack)
DGA patterns — random-appearing names like kqmxplbv.com
Typosquatting — paypa1.com instead of paypal.com
Fast-flux DNS — the domain resolves to a different IP every few minutes

IOC Type	Specificity	Stability	Action
IP Address	High (exact server)	Low (easily changed)	Block at firewall / proxy
Domain	Medium (campaign level)	Medium (days to weeks)	Block at DNS resolver
URL	Very high (specific resource)	Low (path can change)	Block at proxy / WAF

System Artifact IOCs

Registry Keys (Windows Persistence)

Registry Path	Purpose
`HKCU\Software\Microsoft\Windows\CurrentVersion\Run`	User-level persistence — runs on user login
`HKLM\Software\Microsoft\Windows\CurrentVersion\Run`	System-level persistence — runs on every boot
`HKLM\System\CurrentControlSet\Services\`	Service installation — runs as SYSTEM
`HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon`	Winlogon shell replacement

File System and Process Artifacts

Dropped executables in C:\Users\Public\, %TEMP%, or %APPDATA%\
Modified legitimate system binaries (DLL sideloading)
Processes with no associated executable on disk (process hollowing / fileless malware)
Unexpected parent process chains (explorer.exe → cmd.exe → powershell.exe)

STIX and TAXII: Sharing Intelligence

STIX (Structured Threat Information eXpression) is a JSON-based language for describing cyber threat intelligence objects:

STIX Object Type	Represents
`indicator`	An IOC with detection pattern (hashes, IPs, domains)
`malware`	A malware family — behaviors, capabilities
`threat-actor`	An APT group or threat actor
`campaign`	A coordinated series of attacks
`attack-pattern`	A MITRE ATT&CK technique
`relationship`	Links between objects (malware used by actor)

TAXII (Trusted Automated eXchange of Indicator Information) defines how STIX bundles are distributed. TAXII 2.1 uses REST API endpoints with Collections (named repositories of STIX objects) and Channels (pub/sub for real-time distribution). TAXII consumers (SIEMs, EDR platforms) automatically pull new indicators and create detection rules.

The Pyramid of Pain

David Bianco's Pyramid of Pain ranks IOC types by how difficult they are for attackers to change once defenders start detecting them:

Level	IOC Type	Pain for Attacker	Defender Value
(Bottom) Trivial	Hash values	Recompile or pad the file	Easy to detect, easy to evade
Easy	IP addresses	Rotate infrastructure	Moderate detection value
Simple	Domain names	New domain registration	Better — takes hours
Annoying	Network/Host artifacts	Modify tools	High value
Challenging	Tools	Retool entire capability	Very high
(Top) Tough	TTPs	Change entire attack methodology	Highest — forces new tradecraft

flowchart TD TTP["TTPs — Tactics, Techniques & Procedures\nHardest to change — forces attacker to retrain"] TOOLS["Tools\nMust replace entire toolchain"] ARTIFACTS["Network & Host Artifacts\nRequires modifying tool behavior"] DOMAINS["Domain Names\nNew registration + propagation delay"] IPS["IP Addresses\nRotate to new server — easy"] HASHES["Hash Values\nRecompile or pad file — trivial"] HASHES --> IPS --> DOMAINS --> ARTIFACTS --> TOOLS --> TTP style TTP fill:#0a1f0a,stroke:#3fb950,color:#e6edf3 style TOOLS fill:#0d2137,stroke:#58a6ff,color:#e6edf3 style ARTIFACTS fill:#161b22,stroke:#58a6ff,color:#e6edf3 style DOMAINS fill:#1a1200,stroke:#d29922,color:#e6edf3 style IPS fill:#1a1200,stroke:#d29922,color:#e6edf3 style HASHES fill:#1a0a0a,stroke:#f85149,color:#e6edf3

FIGURE 7.4 — IOC Sources, STIX Packaging, and TAXII Distribution

Key Points — IOC Recognition and Threat Intelligence

SHA-256 is the required standard for IOC file hashes — MD5 and SHA-1 are deprecated due to collision vulnerabilities.
Network IOCs are ranked by stability: domains outlast IPs (days vs. minutes to change), and TTPs outlast all artifact-level IOCs.
Windows persistence registry keys under HKCU\...\Run and HKLM\...\Run are primary system artifact IOCs — any unexpected entry pointing to temp directories is a red flag.
STIX 2.1 is the JSON format for describing threat intelligence objects; TAXII 2.1 is the REST API transport that distributes them to consumers.
The Pyramid of Pain: detecting TTPs (top) forces attackers to completely retrain — far more valuable than detecting hashes (bottom) which attackers can evade in seconds by recompiling.

Post-Check — Section 4: IOC Recognition and Threat Intelligence

12. An analyst identifies a malicious file and wants to share its IOC with partner organizations. Which hash algorithm should they use?

MD5 — it is the fastest to compute SHA-1 — it is the most widely supported SHA-256 — the current preferred standard for forensic and IOC use ssdeep — it provides the highest precision

13. According to the Pyramid of Pain, which IOC type is hardest for an attacker to change once defenders start detecting it?

File hashes IP addresses Domain names TTPs (Tactics, Techniques, and Procedures)

14. What is the relationship between STIX and TAXII?

STIX transports threat data; TAXII formats it STIX is the JSON data model for describing threat intelligence; TAXII is the REST API transport that distributes it They are competing standards with different use cases STIX is for malware only; TAXII is for network IOCs

15. A SIEM alert fires on an unexpected registry value at HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svchost32 pointing to %APPDATA%\temp\update.exe. This is an example of which type of IOC?

Network IOC — IP address File hash IOC System artifact IOC — registry-based persistence mechanism URL-based IOC