CH8: IR Analysis Phase

Introduction

In Chapter 7, we learned how to detect the enemy—how to spot the signal amidst the noise using human sensors, network monitoring, and SIEM correlation. An alert has fired. The SOC analyst has triaged it and confirmed: this is not a false positive. We have an Incident.

Now what?

The natural instinct is to act immediately—pull the network cable, disable the account, shut down the server. But acting without understanding is like a surgeon cutting before the X-ray. You might stop the bleeding in one place while missing the internal damage that kills the patient. The Analysis Phase is the X-ray. It is the disciplined process of determining what happened, how it happened, where the adversary went, and how far the damage extends before committing to a containment strategy.

Analysis is not a single step performed in isolation. It is an iterative, hypothesis-driven investigation that often runs in parallel with early containment actions. The analyst must think like a detective and an adversary simultaneously—following the evidence trail while anticipating the attacker's next move.

This chapter equips you with the methodology and technical skills to conduct that investigation.

Learning Objectives

By the end of this chapter, you will be able to:

Explain the purpose of the Analysis phase and its relationship to Detection and Containment within the IR lifecycle.
Apply a hypothesis-driven investigation methodology to scope an incident from initial indicator to full impact assessment.
Perform log analysis across multiple sources, including SIEM, authentication logs, and firewall logs, to reconstruct an attack timeline.
Identify key host-based forensic artifacts on Windows and Linux systems that reveal attacker activity.
Integrate threat intelligence sources and the MITRE ATT&CK framework to contextualize findings during an active investigation.
Construct a unified incident timeline that maps the full attack chain from initial access to objective completion.

8.1 The Analyst's Mission: Scope Before Action

When a detection alert is validated as a true positive, the immediate question from leadership will be: "How bad is it?" The Analysis phase exists to answer that question with evidence, not guesswork.

Why We Analyze Before We Contain

Recall the ransomware scenario from Chapter 5. If the team had contained only the Finance laptop without analyzing the network logs, they would have missed the lateral movement to the Payroll file server. The attacker's foothold would have survived, and the ransomware would have continued spreading.

Premature containment carries real risks:

Incomplete Scope: You isolate one compromised host but miss three others. The attacker retains access.
Tipping Off the Adversary: If the attacker notices you have isolated one of their footholds, they may accelerate their operation—detonating ransomware early, destroying evidence, or activating dormant backdoors on other systems.
Destroying Evidence: Rebooting a server to "fix" it wipes volatile memory (RAM), which may contain the only evidence of fileless malware or injected processes.

Professional Insight: The "Slow is Smooth, Smooth is Fast" Principle

In high-stakes incidents, experienced responders resist the urge to act immediately. Taking 30 minutes to analyze logs and scope the breach often saves hours of chasing the attacker through systems you did not know were compromised. The goal is to act once, decisively, when you understand the full picture.

Establishing Severity and Scope

The first task during analysis is refining the Severity Classification assigned during detection. Chapter 6 introduced the Severity Matrix (SEV-1 through SEV-4). During Analysis, the severity may change as more information emerges.

The analyst must answer four scoping questions as quickly as possible:

What systems are affected? (A single workstation? A domain controller? The entire Active Directory forest?)
What accounts are compromised? (A standard user? A service account? A Domain Admin?)
What data is at risk? (Internal memos? Customer PII? Payment card data subject to PCI-DSS?)
Is the attacker still active? (Are we looking at a historical breach or a live intrusion?)

The answers to these questions determine whether this remains a SEV-3 handled by the SOC, or escalates to a SEV-1 requiring the Incident Commander, Legal Counsel, and Crisis Management.

8.2 Hypothesis-Driven Investigation

Amateur investigations are reactive: the analyst looks at whatever data appears first and follows it wherever it leads. Professional investigations are hypothesis-driven: the analyst forms a theory based on available evidence and then systematically tests it.

The Investigation Cycle

The hypothesis-driven approach follows a repeating cycle:

Observe: Review the initial indicator (the alert, the user report, the anomalous log entry).
Hypothesize: Form a theory about what the indicator means. (e.g., "This PowerShell execution on the HR server suggests the attacker has moved laterally from the initial phishing victim.")
Collect: Gather the specific evidence needed to prove or disprove the hypothesis. (e.g., Pull authentication logs for the HR server. Check for new scheduled tasks.)
Analyze: Examine the collected evidence. Does it support or refute the hypothesis?
Refine: If the hypothesis is confirmed, expand the scope. If refuted, form a new hypothesis.

This cycle repeats until the analyst can confidently define the full scope of the incident.

Tip

Avoiding Tunnel Vision

One of the most dangerous cognitive biases in incident analysis is Confirmation Bias—the tendency to focus on evidence that supports your initial theory while ignoring evidence that contradicts it. A disciplined analyst actively looks for evidence that disproves their hypothesis. If the evidence says the attacker did not move laterally, accept it and pivot, even if lateral movement "made sense" in the initial theory.

Identifying Patient Zero

A critical early objective is identifying Patient Zero—the first system compromised in the attack. This is not always the system that triggered the alert. An alert on a file server might trace back to a phishing email opened on a workstation three days earlier.

Tracing back to Patient Zero reveals the Initial Access Vector, which is essential for two reasons:

Eradication: You cannot fully eradicate the threat without closing the door the attacker used to enter.
Prevention: The lessons learned phase will use this finding to prevent recurrence.

8.3 Evidence Collection During Active Analysis

Analysis requires data, and data requires careful collection. In Chapter 6, we discussed the Forensic Jump Bag and evidence handling in preparation. Now we apply those principles under pressure.

The Order of Volatility

Not all evidence has the same lifespan. The Order of Volatility dictates the priority of collection—capture the most fragile evidence first.

Priority	Evidence Type	Volatility	Example
1 (Highest)	CPU Registers & Cache	Nanoseconds	Current processor state
2	RAM (System Memory)	Lost on reboot	Running processes, network connections, decrypted data, injected code
3	Temporary Files & Swap	May persist hours	Pagefile, `/tmp` directory contents
4	Disk (File System)	Persistent until overwritten	User files, application logs, Registry hives
5	Remote Logs	Persistent if retained	SIEM data, firewall logs, cloud audit trails
6 (Lowest)	Backups & Archives	Long-term storage	Tape backups, offsite replicas

The practical takeaway: if you suspect a server is compromised, capture a memory dump before rebooting it. Tools like WinPMem, FTK Imager, or LiME (Linux Memory Extractor) can acquire RAM from a live system without shutting it down.

Balancing Speed and Forensic Integrity

In a live incident, you are simultaneously an investigator and a first responder. There is a constant tension between moving fast (to stop the bleeding) and preserving evidence (to support legal proceedings and root cause analysis).

Professional Insight: The "Good Enough" Image

In a critical incident, you may not have time to perform a full forensic disk image of every affected system. Many teams use a triage image approach: capture RAM, export critical log files and key forensic artifacts (Registry hives, event logs, prefetch files), and move on. A full disk image can be taken later during the Eradication phase when the system is offline. Document everything you collect, hash every file, and maintain the chain of custody.

8.4 Log Analysis: Reconstructing the Story

Logs are the historian's record of an incident. Every authentication attempt, every firewall rule match, every process execution is potentially recorded somewhere. The analyst's job is to find the relevant entries across dozens of sources and stitch them into a coherent narrative.

Prioritizing Log Sources

Not all logs are equally useful. Experienced analysts prioritize based on what the hypothesis demands:

Authentication Logs (Active Directory / LDAP / Okta): Who logged in, from where, and when? This is the first place to look for lateral movement and privilege escalation.
Firewall / Proxy Logs: What left the network? What came in? This is critical for identifying Command and Control (C2) traffic and data exfiltration.
Endpoint Detection & Response (EDR): What processes executed on the host? What files were created or modified? EDR telemetry is often the richest source of host-level activity.
SIEM Correlation: As we discussed in Chapter 7, the SIEM ties these sources together. An alert that combines DNS queries + authentication events + EDR process telemetry can reveal an attack chain that no single log source could expose alone.
DNS Logs: What domains were resolved? DNS is a goldmine for detecting C2 beaconing, domain generation algorithms (DGAs), and DNS tunneling.
Application Logs (Web Server, Database): For web application attacks, the Apache/Nginx access logs and database query logs may contain the initial exploit (SQL injection, path traversal).

Timestamp Normalization

One of the most overlooked challenges in log analysis is time synchronization. If your firewall logs are in UTC, your Windows Event Logs are in Eastern Time, and your cloud audit trail is in Pacific Time, correlating events across sources becomes a nightmare.

During analysis, the first step when pulling logs from multiple sources is to normalize all timestamps to a single time zone (UTC is the industry standard). Failure to do this can lead to incorrect sequencing of events, which means the attack timeline will be wrong.

Note

NTP is a Preparation Issue

Proper time synchronization via Network Time Protocol (NTP) should be configured during the Preparation phase (Chapter 6). If your servers are not synced to a reliable NTP source, log correlation during analysis becomes significantly more difficult. This is a common finding in post-incident reviews.

Recognizing Anti-Forensic Techniques

Sophisticated adversaries know that logs are the analyst's weapon. They will attempt to cover their tracks:

Log Clearing: Deleting Windows Event Logs (Event ID 1102 records when the Security log is cleared—ironically, one of the most suspicious events you can find).
Timestomping: Modifying file timestamps (Created, Modified, Accessed) to make malicious files appear to have existed long before the attack.
Log Gaps: If a system's logs suddenly stop for a period and then resume, this may indicate the attacker disabled the logging service temporarily.

An experienced analyst treats the absence of evidence as evidence itself. A gap in the logs is not "nothing happened"—it may be "something happened, and someone erased the record."

8.5 Network Traffic Analysis

While logs tell us what systems reported, network traffic analysis tells us what actually traversed the wire. This is particularly valuable when endpoint logs have been tampered with or are unavailable.

Full Packet Capture vs. Flow Data

Recall from Chapter 7 the distinction between PCAP and NetFlow:

Full Packet Capture (PCAP): The entire conversation, including payloads. This allows the analyst to extract transferred files, read unencrypted commands, and reconstruct sessions. The trade-off is massive storage requirements.
Flow Data (NetFlow/sFlow/IPFIX): Metadata only—source, destination, ports, byte counts, duration. Think of it as a phone bill: you know who called whom and for how long, but not what was said.

During analysis, flow data is typically used first to identify suspicious communication patterns, and then PCAP (if available) is used to drill into specific conversations of interest.

Identifying C2 and Beaconing

Command and Control (C2) communication is the adversary's lifeline. Once they have a foothold, they need a way to send commands to the compromised host and receive stolen data. C2 traffic often exhibits recognizable patterns:

Beaconing: The compromised host "checks in" with the C2 server at regular intervals (e.g., every 60 seconds). This creates a rhythmic pattern in flow data that stands out against normal browsing traffic, which is irregular and bursty.
DNS Tunneling: The attacker encodes data within DNS queries to exfiltrate information through a protocol that is rarely blocked. Look for unusually long subdomain strings or high volumes of DNS queries to a single domain.
Protocol Abuse: Using standard protocols (HTTP/HTTPS, DNS) on standard ports (80, 443, 53) to blend in with legitimate traffic. The content is malicious, but the wrapper looks normal.

Professional Insight: Encrypted Traffic Challenges

With TLS 1.3 now standard across much of the internet, analysts often cannot read packet payloads. However, metadata still reveals patterns. The size, timing, and frequency of encrypted connections can identify beaconing behavior even when the content is invisible. This is why flow data remains valuable even in a fully encrypted environment.

8.6 Host-Based Forensic Analysis

When the investigation focuses on a specific compromised endpoint, the analyst shifts to host-based forensic artifacts. These are the digital fingerprints left by both legitimate users and attackers on the operating system.

Windows Forensic Artifacts

Windows systems are rich with forensic data, often in locations that even experienced system administrators are unaware of:

Windows Event Logs: Security logs (logon events, privilege use), System logs (service installations), and PowerShell logs (script execution). Event ID 4624 (Successful Logon) and Event ID 4672 (Special Privileges Assigned) are high-value indicators during analysis.
Registry Hives: The Windows Registry records an enormous amount of user and system activity. Key areas include ShimCache (tracks executable compatibility checks—proves a program existed on disk even if deleted), Amcache (records application execution history with SHA-1 hashes), and UserAssist (tracks GUI program launches).
Prefetch Files: Located in C:\Windows\Prefetch, these files record the last 8 execution times of any application, including malicious tools an attacker ran and later deleted.
SRUM (System Resource Usage Monitor): Records per-application network usage, CPU time, and energy usage for the last 30+ days. If the attacker exfiltrated 2 GB of data through a specific process, SRUM may record it.

Linux Forensic Artifacts

Linux and macOS systems provide a different but equally valuable set of artifacts:

Authentication Logs: /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) record SSH sessions, sudo usage, and account modifications.
Bash History: ~/.bash_history records commands typed by the user—or the attacker. Savvy adversaries will clear this, but the file's sudden truncation or absence is itself an indicator.
Cron Jobs: Persistent scheduled tasks in /etc/crontab or user-level cron files are a common persistence mechanism.
Journal Logs: Systems using systemd store binary logs accessible via journalctl, which can reveal service starts, failures, and kernel messages.

Tip

The Artifact is Only as Good as the Analyst

Knowing where forensic artifacts live is necessary but not sufficient. The real skill is knowing what questions to ask. Rather than dumping every artifact from a system, start with your hypothesis: "I believe the attacker used this host to move laterally." Then target the specific artifacts that prove or disprove that claim—authentication logs, RDP connection records, and PowerShell execution history.

8.7 Threat Intelligence Integration

Raw forensic data tells you what happened on a system. Threat Intelligence tells you why it matters and who might be behind it.

Enriching Indicators of Compromise (IOCs)

During analysis, you will uncover indicators: IP addresses, domain names, file hashes, and unique strings. These raw IOCs become actionable intelligence when you enrich them against external sources:

VirusTotal: Upload a suspicious file hash to check if it has been flagged by antivirus engines worldwide.
AbuseIPDB / Shodan: Check whether an IP address has been reported for malicious activity or is associated with known threat infrastructure.
MISP / OTX (Open Threat Exchange): Community platforms where organizations share IOCs tied to specific campaigns and threat actors.

If your investigation reveals that the C2 server's IP address was used in attacks attributed to a known ransomware group last month, you now have context that shapes your entire response strategy.

Mapping to MITRE ATT&CK

In Chapter 7, we introduced the ATT&CK framework as a tool for detection engineering. During the Analysis phase, ATT&CK becomes an investigation framework. As you uncover attacker actions, map each one to a specific Technique.

For example, during your investigation you might document:

Initial Access: T1566.001 - Phishing: Spearphishing Attachment
Execution: T1059.001 - Command and Scripting Interpreter: PowerShell
Persistence: T1053.005 - Scheduled Task/Job: Scheduled Task
Credential Access: T1003.001 - OS Credential Dumping: LSASS Memory
Lateral Movement: T1021.001 - Remote Services: Remote Desktop Protocol
Exfiltration: T1041 - Exfiltration Over C2 Channel

This mapping serves multiple purposes: it provides a common language for communicating findings, it helps predict what the attacker might do next (by reviewing adjacent techniques), and it directly feeds the detection engineering process discussed in Chapter 7 to improve future coverage.

8.8 Building the Incident Timeline

The culmination of the Analysis phase is the Incident Timeline—a unified, chronological reconstruction of every significant event from the attacker's initial entry to their last observed action.

Super-Timeline Construction

A super-timeline is created by merging forensic artifacts from multiple sources into a single chronological view. This includes file system timestamps, log entries, Registry modifications, browser history, and network flow data—all normalized to UTC and sorted by time.

Tools commonly used for this process include:

log2timeline / Plaso: An open-source tool that extracts timestamps from dozens of artifact types and combines them into a single timeline file.
Timeline Explorer (Eric Zimmerman): A Windows-based viewer optimized for sorting and filtering massive timeline datasets.
Manual Spreadsheet Correlation: For smaller incidents, an analyst may construct the timeline manually in a spreadsheet, pulling key timestamps from each evidence source.

What a Good Timeline Looks Like

A well-constructed timeline reads like a story. Here is a simplified example:

Timestamp (UTC)	Source	Event
2025-02-10 09:14	Email Gateway	Phishing email delivered to jsmith@company.com
2025-02-10 09:22	EDR	jsmith workstation: `WINWORD.EXE` spawned `powershell.exe`
2025-02-10 09:23	DNS Log	jsmith workstation resolved `update-service[.]xyz` (C2 domain)
2025-02-10 09:25	Proxy Log	HTTPS connection to `update-service[.]xyz` (443) — 4.2 MB transferred outbound
2025-02-10 11:47	AD Auth Log	jsmith account authenticated to `HR-SERVER-01` via RDP (Event ID 4624, Type 10)
2025-02-10 11:52	EDR (HR-SERVER)	`procdump.exe` executed targeting `lsass.exe`
2025-02-10 12:03	AD Auth Log	Domain Admin account `da-backup` authenticated from `HR-SERVER-01`
2025-02-10 12:15	Firewall Log	12 GB outbound transfer to external IP `198.51.100.47` over port 443

This timeline tells the complete story: phishing email to macro execution, C2 establishment, lateral movement, credential dumping, privilege escalation, and data exfiltration—all in under three hours.

Gaps in the Timeline

No timeline is perfect. Gaps occur when logs were not configured, retention periods expired, or the attacker erased evidence. When documenting the timeline, explicitly note what is missing and why.

A gap is not a failure—it is a finding. If the investigation reveals that DNS logging was not enabled on the internal resolver, that becomes a critical recommendation for the Lessons Learned phase.

8.9 Root Cause Analysis

Before handing off to the Containment team, the analyst must determine the root cause of the incident. Root cause analysis goes beyond the technical exploit to ask, "Why was this possible in the first place?"

Symptoms vs. Causes

The ransomware encryption is a symptom. The root cause might be any of the following:

A missing email gateway rule that failed to block macro-enabled attachments.
A lack of network segmentation that allowed a workstation to RDP directly to a server.
A stale Domain Admin account (da-backup) that had not been used in months but was never disabled.

The "Five Whys" Technique

A simple but effective method for reaching root cause is to ask "Why?" repeatedly:

Why was data exfiltrated? → Because the attacker obtained Domain Admin credentials.
Why did the attacker obtain Domain Admin credentials? → Because they dumped LSASS memory on the HR server.
Why could they access the HR server? → Because the compromised user account had RDP access to it.
Why did a Finance user have RDP access to an HR server? → Because there was no network segmentation or access control policy restricting RDP.
Why was there no segmentation? → Because the last network audit was three years ago and new servers were added to the flat network without review.

The root cause is not "the attacker used Mimikatz." The root cause is a process failure: inadequate network segmentation review and access control governance.

8.10 Communicating Findings and Handing Off to Containment

Analysis does not end when the analyst understands the incident—it ends when the Containment team has everything they need to act.

The Interim Analysis Brief

During an active incident, leadership cannot wait for a polished 50-page report. The analyst produces an Interim Analysis Brief that communicates the essential findings concisely:

Scope: Number and identity of compromised systems and accounts.
Attack Vector: How the attacker got in.
Current Status: Is the attacker still active?
Recommended Containment Actions: Specific systems to isolate, accounts to disable, and firewall rules to implement.
Data at Risk: What sensitive data may have been accessed or exfiltrated.
Confidence Level: How certain is the team in these findings? (High / Medium / Low)

Note

Confidence Levels Matter

Stating your confidence level is not a sign of weakness—it is professional integrity. Telling leadership "We have high confidence that the attacker exfiltrated the customer database, but low confidence on whether they accessed the payment processing system" allows decision-makers to prioritize actions and allocate resources appropriately. Overstating certainty leads to bad decisions.

Feeding the Containment Phase

The Analysis phase produces the intelligence that the Containment phase consumes. Specifically, the containment team needs:

A complete list of compromised hosts and accounts.
The C2 infrastructure (IPs, domains) to block at the firewall.
The persistence mechanisms (scheduled tasks, new accounts, Registry run keys) to eradicate.
The attack timeline to verify that containment actions address every stage of the intrusion.

Without a thorough analysis, containment becomes guesswork—and guesswork against a motivated adversary is a losing strategy.

Summary

The Analysis phase transforms a detection alert into actionable intelligence. It is the bridge between knowing something is wrong and knowing exactly what to do about it. We resist the urge to act prematurely, instead investing the time to understand the full scope of the compromise before committing to containment.

We accomplish this by:

Scoping the Incident: Determining which systems, accounts, and data are affected before acting.
Investigating with Discipline: Using a hypothesis-driven cycle to follow evidence rather than assumptions.
Collecting Evidence Carefully: Respecting the order of volatility and maintaining forensic integrity under pressure.
Analyzing Logs and Traffic: Correlating events across authentication, network, and endpoint sources to reconstruct the attack.
Leveraging Threat Intelligence: Enriching IOCs and mapping findings to MITRE ATT&CK to understand the adversary.
Building the Timeline: Constructing a unified chronological narrative that tells the complete story of the breach.
Communicating Clearly: Producing interim briefs that give leadership and the containment team the intelligence they need to act decisively.

In the next chapter, we will take the intelligence produced by the Analysis phase and use it to execute the Containment strategy—isolating the threat and stopping the bleeding.