Chapter 3: Incident Response and Management
Incident response is where everything in the first two chapters gets tested under pressure. Detection tools flag
an event, vulnerability data tells you which weaknesses the attacker probably used, and then a human analyst
has to decide, in order: what happened, how bad it is, what to stop first, and how to prove the environment is
clean again. This chapter covers the two halves of Domain 3. The first half is the language analysts use to
describe attacks: MITRE ATT&CK, the Cyber Kill Chain, and the Diamond Model. The second half is the work itself:
the seven incident response phases, triage, evidence handling, containment, eradication, recovery, root-cause
analysis, and the lessons-learned process that turns one incident into better defenses for the next one. Domain
3 is 24% of the CS0-004 exam, so expect questions that ask you to map an observed behavior to a tactic, order IR
phases from a timeline, choose the right containment action, and judge whether evidence was handled
correctly.
Attack methodology frameworks
Frameworks matter because they give every analyst on a team the same vocabulary. When one analyst writes
"persistence via scheduled task" and another writes "the attacker came back after reboot," they are describing
the same thing, but only the first description can be searched, counted, and turned into a detection rule.
Frameworks also let you compare incidents: if three separate incidents all show the same technique in the same
tactic, you have a pattern worth hunting for across the whole estate.
MITRE ATT&CK
MITRE ATT&CK is a knowledge base of adversary behavior, built from real-world observations. It is organized as
tactics, techniques, sub-techniques, and procedures. A tactic is the attacker's goal, the "why" of an action. A
technique is how that goal is achieved, the "how." A sub-technique is a more specific variation of a technique. A
procedure is the concrete way a particular threat actor or malware implements a technique in a real incident.
Tactic. A tactic is the tactical goal of an adversary during an attack, such as gaining a foothold, staying in the
environment, or stealing data. ATT&CK names fourteen enterprise tactics, and every technique belongs to at
least one of them.
Technique. A technique is a method an adversary uses to achieve a tactical goal, for example creating a
scheduled task to gain persistence, or dumping credentials from memory to gain credential access.
Techniques can have sub-techniques that describe narrower variants.
The fourteen enterprise tactics, in the order ATT&CK lists them, are:
Tactic What the attacker is trying to do Example technique
| Reconnaissance Gather information about the target Scanning for open ports and services | ||
|---|---|---|
| Resource Development | Build or acquire tools and infrastructure Registering a domain for phishing or command and control | |
| Initial Access Get a first foothold in the environment Phishing with a malicious attachment | ||
| Execution Run malicious code on a victim system Running a script through a command interpreter | ||
| Persistence Keep access across restarts and password changes | Creating a scheduled task or a new service | |
| Privilege Escalation | Gain higher-level permissions Exploiting a vulnerable service to reach administrator rights | |
| Defense Evasion Avoid being detected Deleting logs or disguising a file as a legitimate program | ||
| Credential Access | Steal account names, passwords, or tokens Dumping credentials from operating system memory | |
| Discovery Learn about the internal environment Querying Active Directory or listing network shares | ||
| Lateral Movement | Move from one system to another Using stolen credentials over remote desktop or SMB | |
| Collection Gather data of interest on a system Copying files from a staging folder | ||
| Command and Control | Communicate with compromised systems Beaconing to an external server over HTTPS | |
| Exfiltration Move stolen data out of the environment Uploading compressed archives to a cloud storage service | ||
| Impact Disrupt, destroy, or manipulate systems and data | Encrypting files for ransom or wiping disks | |
| Analysts use ATT&CK in four practical ways. First, mapping: when you observe a behavior, you map it to a | ||
| technique so the incident record is precise. Second, detection: each technique suggests data sources and | ||
| detection ideas, such as monitoring process creation for execution techniques or monitoring scheduled task | ||
| creation for persistence. Third, hunting: if you know an adversary group favors a set of techniques, you can | ||
| proactively search your logs for those techniques even before an alert fires. Fourth, gap analysis: mapping your |
existing detections against the full technique list shows which tactics you cannot see at all, and those blind spots
become the next detection engineering project.
Exam questions love to give you a behavior and ask for the tactic. A scheduled task that runs malware after
reboot is Persistence, not Execution. Dumping passwords from memory is Credential Access, not Discovery.
Copying data to an external server is Exfiltration, while gathering files into a local staging folder is Collection.
Read the behavior, name the goal, and the tactic follows.
Techniques are the bridge between raw logs and attacker intent. A log line that says a process launched a
scripting interpreter is just an event. Mapping it to an Execution technique turns it into evidence of a specific
stage of an attack, which tells the team what to look for next: if the attacker has reached Execution, the team
should check for Persistence and Command and Control, because those are the stages that usually follow.
ATT&CK also publishes matrices beyond Enterprise, including Mobile and ICS (industrial control systems). For the
CS0-004 exam, Enterprise is the matrix that matters most, but the concept is the same everywhere: tactics
describe goals, techniques describe methods, and procedures describe real implementations. Note that ATT&CK
describes what adversaries do, not how to defend in detail; defensive guidance appears in related resources
such as MITRE D3FEND, which maps defensive countermeasures to ATT&CK techniques.
A host shows a new service that starts a remote access tool every time the system boots, and the service was
created with a stolen domain administrator account. Which ATT&CK tactics are present, and which one is the
most urgent to address first?
Answer: Persistence (the service surviving reboot) and Privilege Escalation (use of the administrator account)
are both present, with Initial Access and possibly Lateral Movement depending on how the account was
obtained. Persistence is the most urgent to address first in containment terms, because every reboot
re-establishes the attacker's foothold; removing the service without also resetting the stolen credentials would
leave the attacker a way back in.
The Cyber Kill Chain
The Cyber Kill Chain, developed by Lockheed Martin, describes an intrusion as seven sequential stages. The
model's power is its central idea: an attacker must complete every stage to succeed, so defenders who break
any single stage defeat the attack. That is why the model is often summarized as "break the chain."
Stage What happens Defender's opportunity
| Reconnaissanc e | The attacker researches the target: people, technology, public information | Limit public exposure, train staff against social engineering |
|---|---|---|
| Weaponization The attacker builds a deliverable, such as a malicious document paired with an exploit | Patching and application controls reduce what an exploit can achieve | |
| Delivery The weapon reaches the target, usually by email, web, or removable media | Email filtering, web filtering, and user awareness | |
| Exploitation The malicious code runs and exploits a vulnerability | Patching, endpoint protection, least privilege | |
| Installation Malware is installed to establish a lasting presence Application allowlisting, endpoint detection | ||
| Command and Control | The compromised host connects to attacker infrastructure | Egress filtering, DNS monitoring, proxy inspection |
| Actions on Objectives | The attacker achieves the goal: theft, encryption, destruction | Data loss prevention, segmentation, backups |
Cyber Kill Chain. A seven-stage model of an intrusion (Reconnaissance, Weaponization, Delivery, Exploitation,
Installation, Command and Control, Actions on Objectives) built on the idea that stopping any one stage
breaks the whole attack.
The Kill Chain's weakness is that real attacks are rarely a neat straight line. Insiders do not need delivery or
exploitation. Cloud attacks may skip installation entirely. Attackers loop back: after Actions on Objectives on one
host, they run reconnaissance again on the internal network and start a new chain. Exam questions sometimes
test this directly, asking which model fits a non-linear attack or an insider scenario. The honest answer is that the
Kill Chain is a useful teaching and planning model, but it describes the classic perimeter intrusion better than it
describes modern, cloud, or insider attacks. That limitation is exactly why analysts use ATT&CK alongside it:
ATT&CK describes behaviors at a finer grain and does not force them into a single sequence.
When a question describes an attack in stages and asks what the defender should do, look for the earliest
stage where a control can break the chain. The cheapest and most reliable breaks are usually early: blocking
delivery at the email gateway or patching the exploited vulnerability stops everything downstream, while
controls at Actions on Objectives are the last resort.
The Diamond Model
The Diamond Model describes an intrusion as four connected vertices: Adversary, Capability, Infrastructure, and
Victim. Every intrusion event involves an adversary using a capability over infrastructure against a victim. The
model adds two ideas that make it practical. Meta-features describe each event: timestamp, phase, result,
direction, methodology, and resources. Activity threads link events together into a single intrusion story,
showing how one event led to the next.
Diamond Model. A model of intrusions built from four vertices (Adversary, Capability, Infrastructure, Victim)
connected by the event itself, plus meta-features that describe each event and activity threads that link events
into an intrusion narrative.
Pivoting is the Diamond Model's most exam-relevant concept. Pivoting means using one known vertex to
discover an unknown one. If you know the victim and the infrastructure (say, a command-and-control domain),
you can pivot to find other victims that contacted the same domain. If you know the capability (a distinctive
malware sample), you can pivot to find other infrastructure that delivered it. Each pivot expands the
investigation outward from a single confirmed fact, which is how a one-host incident becomes a discovered
campaign.
The Diamond Model and ATT&CK answer different questions. ATT&CK answers "what did the attacker do" in
terms of tactics and techniques. The Diamond Model answers "who did it, with what, over what infrastructure,
against whom" and, through pivoting, "what else is connected to this event." In a real investigation you use
both: ATT&CK to classify behaviors and write detections, the Diamond Model to expand the scope of the
investigation.
CertCrack.com's analysts confirm that a phishing domain sent credential-harvesting emails to three
employees. Using the Diamond Model, what is the most useful next pivot, and why?
Answer: Pivot from the known infrastructure (the phishing domain) to discover other victims: search email and
proxy logs for any other host or user that contacted the domain or received mail from it. This turns one
confirmed victim set into the full victim set, which defines the true scope of the incident before containment
begins.
Figure: the Diamond Model of intrusion analysis
The incident response process
CompTIA's incident response model has seven phases: Preparation, Detection, Analysis, Containment,
Eradication, Recovery, and Lessons Learned. The order matters, and the exam tests it. Preparation happens
before any incident. Detection and Analysis establish what happened and how bad it is. Containment stops the
bleeding. Eradication removes the cause. Recovery returns systems to normal operation. Lessons Learned turns
the experience into improvements. Phases can overlap in practice - analysis continues during containment, and
containment decisions get revisited as analysis improves - but skipping a phase is how incidents go wrong:
containing before analysis means you may cut off the wrong systems, and recovering before eradication means
the attacker simply returns.
If a question gives you a timeline of incident events and asks which phase is missing or out of order, look for
the classic mistakes: recovery before eradication, containment before analysis has established scope, or no
lessons learned at all. The phase order is Preparation, Detection, Analysis, Containment, Eradication, Recovery,
Lessons Learned.
Phase 1: Preparation
Preparation is everything done before an incident exists: the incident response plan, the response team and its
roles, contact lists, playbooks for common incident types, tooling (SIEM, EDR, forensic workstations, clean build
media), and training and exercises. A plan that has never been exercised is a hypothesis, not a capability, which
is why tabletop exercises matter: they force the team to discover, in a safe setting, that the contact list is out of
date or that nobody knows who can authorize taking a revenue system offline.
Incident response plan. A documented plan that defines incident categories and severity levels, team roles
and authority, communication procedures, escalation paths, and the tools and resources the team will use. It is
approved by management before any incident occurs, because decisions made under pressure without prior
authority are slow and contested.
Phase 2: Detection
Detection is recognizing that something worth investigating has occurred. Sources include SIEM alerts, EDR
alerts, user reports, threat intelligence matches, and anomalies found during hunting. Detection is not the same
as confirmation: an alert is a hypothesis that an incident may exist, and many alerts turn out to be benign. The
detection phase ends when the team has enough evidence to declare an incident and move to analysis.
Phase 3: Analysis
Analysis answers three questions: what happened, what is affected, and how serious is it. Analysts build a
timeline from logs, identify the attacker's techniques and tools, determine the scope (which hosts, accounts, and
data), and assess impact. Analysis is what makes containment decisions defensible: without scope, you cannot
know whether disconnecting one host is enough or whether a whole segment must be isolated.
Scope before action. The single most expensive mistake in incident response is acting on an incomplete scope
- cleaning one host while the attacker still holds three others, or restoring from a backup that contains the
same backdoor. Analysis earns its time by preventing rework: every hour spent confirming scope saves the
team from repeating containment and eradication later.
Phase 4: Containment
Containment limits damage and prevents spread. It is covered in detail later in this chapter, including the
trade-offs between short-term and long-term containment.
Phase 5: Eradication
Eradication removes the root cause and every attacker artifact: malware, backdoors, persistence mechanisms,
and stolen credentials are reset or removed. Eradication is covered in detail later in this chapter.
Phase 6: Recovery
Recovery returns affected systems to normal operation, from clean sources, with validation that the
environment is actually clean. Recovery is covered in detail later in this chapter.
Phase 7: Lessons Learned
Lessons Learned, also called post-incident activity, reviews the incident and converts findings into
improvements: updated playbooks, new detections, fixed processes, and tracked action items. It is covered in
detail later in this chapter.
During an incident at CertCrack.com, the team restores a compromised server from backup, and the same
backdoor reappears within hours. Which phase was skipped or done badly, and what should the team do now?
Answer: Eradication was skipped or done badly - the backup itself contained the backdoor, or a persistence
mechanism survived. The team should return to analysis to find every persistence mechanism, complete
eradication (remove the backdoor, reset affected credentials, rebuild from known-clean media if needed), and
only then recover again, with monitoring in place to catch a return.
Figure: the seven incident response phases, in order
Take the ransomware timeline in this chapter and relabel each entry with its IR phase without looking at the
answers. Then check yourself: isolation is containment, blocking the sender domain is still containment,
removal and patching is eradication, restoration is recovery.
Triage and prioritization
Triage is the sorting step: when several alerts or incidents compete for the same analysts, which one gets
attention first. Good triage is fast, documented, and revisable - a first judgment made from limited information,
updated as analysis improves. Triage is not a final verdict; it is a queue order.
Prioritization weighs several factors together. Severity asks how much harm the incident can cause: data theft of
regulated records outranks a single adware infection. Scope asks how far the incident has spread: one host
versus a whole domain. Impact asks what is at stake: a compromised finance server matters more than a
compromised test workstation. Urgency asks how fast the situation is worsening: active exfiltration or active
encryption outranks a dormant backdoor discovered in an old log. Finally, business context matters: an incident
on a system that supports a product launch this week outranks the same incident on a system scheduled for
decommissioning.
Factor Questions to ask High-priority signal
Severity What harm is occurring or likely? Data theft, encryption, destruction, privilege escalation to domain control
Scope How many hosts, accounts, or segments? Multiple hosts, lateral movement, shared credentials
Impact What data or service is affected? Regulated data, customer data, revenue systems
Urgency How fast is it getting worse? Active exfiltration, spreading ransomware, attacker currently online
Business context What does this system do for the organization? Production, customer-facing, deadline-critical
Triage questions often present two incidents and ask which to handle first. Do not pick the one that arrived
first - pick the one with the greater combination of severity, scope, and urgency. An active ransomware
encryption on one server outranks a week-old suspicious login on a single workstation, even though the
workstation alert is older.
False positive. An alert that fires on benign activity, such as a legitimate administrative script that resembles a
known attack technique. Tuning and whitelisting reduce false positives, but tuning must be careful:
suppressing the alert entirely can hide a real attack that uses the same technique.
A related concept is the false negative: a real attack that produces no alert at all. False negatives are found by
hunting, by user reports, and by post-incident review - which is why a quiet console is never proof of a quiet
environment.
Evidence handling and chain of custody
Evidence is anything that can establish what happened: disk images, memory captures, logs, network captures,
screenshots, and the analyst's own notes. Incident response evidence is handled with forensic discipline because
it may be needed later for legal action, regulatory reporting, insurance claims, or law enforcement. Even when
nobody expects a courtroom, the same discipline protects the investigation: if evidence is altered or its handling
is undocumented, its conclusions can be challenged and its value collapses.
The core rules of evidence handling are simple and strict. Collect the most volatile evidence first, following the
order of volatility below. Work on copies, not originals: create a forensic image of a disk or memory capture and
analyze the copy, so the original remains pristine. Prove integrity with hashes: record a cryptographic hash of
each item at collection time, and verify the hash again whenever the item changes hands or is analyzed, so any
alteration is detectable. Document everything: who collected what, when, where, with what tool, and who held it
afterward. Limit access: only people who need the evidence should handle it, and each transfer is recorded.
Chain of custody. A documented, unbroken record of who collected, held, transferred, and analyzed each
piece of evidence, from collection to final disposition. A gap in the chain - an unrecorded transfer, an
undocumented time period - undermines the evidence, because nobody can prove it was not altered during
the gap.
A chain-of-custody record typically includes the item description, a unique identifier, the date and time of each
transfer, the names and signatures of the releasing and receiving persons, the purpose of the transfer, and the
item's hash value. The record travels with the evidence. In practice, analysts keep the form simple and fill it in at
the moment of transfer, not from memory at the end of the day.
Hashing is what makes chain of custody verifiable rather than merely asserted. A hash recorded at collection
time lets anyone later confirm the item is byte-for-byte identical to what was collected. If the hash does not
match, the item's integrity is in doubt regardless of how good the paperwork looks. Hash first, then analyze,
and re-verify the hash at every handoff.
Legal hold is the obligation to preserve evidence once litigation or an investigation is reasonably anticipated:
affected data must not be deleted, overwritten, or allowed to expire under normal retention policies. When legal
hold applies, the response team coordinates with legal counsel before any deletion or system rebuild, because
rebuilding a compromised host destroys evidence stored on it. This is one reason containment decisions
sometimes favor isolating a host over wiping it: the host is both a threat to remove and evidence to preserve.
Evidence questions frequently test two distinctions. First, original versus copy: analysts work on forensic
copies, never on the original evidence. Second, order of volatility: memory and running-state data are collected
before disk images, because a reboot destroys them. If a question asks what to collect first from a live
compromised host, the answer is almost always memory, not the hard drive.
On your own computer, copy any file, then run a SHA-256 hash on the original and the copy and compare
them. Now change one byte in the copy and hash it again. That changed hash is exactly why chain of custody
starts with hashing at acquisition.
Hashing evidence, step by step
Hashing is what makes chain of custody verifiable. The procedure is short and must happen before analysis:
1. Make a working copy of the evidence and keep the original untouched.
2. Hash the original and the copy and confirm the two hashes match.
3. Change one byte in the copy and hash it again.
4. Compare: the changed hash proves that any alteration, however small, is detectable. That is why the hash
is recorded at acquisition and re-verified at every handoff.
Terminal session: hashing evidence before and after a one-byte change (genuine output)
Order of volatility
The order of volatility ranks data by how quickly it disappears. The principle is to collect the most fragile
evidence first, because every minute of delay and every action on the system (including the act of collecting
other evidence) risks destroying it. The standard order, following the widely used RFC 3227 guidance, is:
Ord er
Data Why it is fragile
1 CPU registers and cache Lost the instant the system powers off or the process ends
2 Routing table, ARP cache, process table, kernel statistics, memory (RAM) Lost on reboot; changes constantly while the system runs
3 Temporary file systems and swap space Overwritten quickly by normal system activity
4 Data on the hard disk Persists across reboot but can be overwritten or wiped
5 Remotely logged data Persists on the log server even if the local host is wiped
6 Physical configuration and network topology Changes only when hardware or cabling changes
7 Archival media (backups, offline storage) The most durable evidence available
In practice, analysts rarely capture CPU registers directly; the practical first steps on a live host are a memory
capture and a snapshot of running processes, network connections, and logged-in users, followed by disk
imaging. The exam point is the ordering principle, not the tooling: volatile before non-volatile, live state before
disk, local disk before remote logs only in the sense that local disk is more easily destroyed by an attacker who
still has access.
An analyst arrives at a running compromised workstation and must choose between pulling the power plug to
preserve the disk exactly as it is, and capturing memory first. Which is correct, and why?
Answer: Capture memory first. Pulling the plug destroys RAM contents - running processes, network
connections, encryption keys, and injected code - which cannot be recovered from the disk. The disk can be
imaged afterward; the memory cannot be recreated. The only common exception is a situation where the
system is configured to wipe or encrypt on shutdown, which the analyst must weigh, but the general rule is
volatile data first.
Figure: order of volatility — collect the most volatile evidence first
Escalation criteria
Escalation means moving an incident to a higher level of authority, a larger team, or an outside party. Clear
escalation criteria prevent two opposite failures: incidents that stay with front-line analysts long after they have
outgrown them, and incidents escalated so aggressively that senior staff are pulled into every routine alert.
Typical escalation triggers include:
• Severity thresholds: an incident reaches a defined severity level, such as confirmed data breach or
domain-wide compromise.
• Scope expansion: the incident spreads beyond the initially affected systems, or lateral movement is
confirmed.
• Regulated or sensitive data: customer personal data, payment card data, or health information is involved,
which may trigger legal and regulatory obligations.
• Business impact: a critical service is down, or the incident affects a deadline or a customer commitment.
• Attacker persistence: the attacker returns after containment, or eradication fails.
• External involvement needed: law enforcement, a regulator, an insurer, or an outside forensic firm must be
engaged.
• Time thresholds: an incident is not contained within a defined window, so a larger team takes over.
Escalation is also a communication act: the escalating analyst passes a clear summary (what happened, scope,
impact, actions taken, what is needed) so the receiving team does not have to restart analysis from zero. A
handoff without that summary is not an escalation; it is an interruption.
Escalation questions often describe a scenario that crosses a threshold - regulated data involved, scope
expanding, containment failing - and ask what to do next. The answer is to escalate, not to keep working the
incident at the same level. Conversely, a routine single-host malware alert with no spread and no sensitive
data does not need executive escalation; over-escalation wastes the senior team's time and teaches them to
ignore the next alert.
Containment: trade-offs and techniques
Containment is where technical judgment meets business reality. The perfect technical answer - disconnect
everything suspicious immediately - can be the wrong business answer if it takes a revenue system offline for a
false positive. The perfect business answer - keep everything running while you investigate - can be the wrong
technical answer if the attacker is actively stealing data. Containment decisions are trade-offs, and the exam
tests whether you can weigh both sides.
Short-term containment acts fast to limit immediate damage: disconnecting a host from the network, disabling a
compromised account, blocking a malicious domain at the proxy, or isolating a segment. Long-term
containment is a temporary fix that lets the business keep running while eradication is prepared: routing traffic
through a clean path, applying a workaround rule, or placing a host in a restricted VLAN with monitored access.
The two are often used together: short-term containment stops the bleeding, long-term containment buys time
for a proper fix.
Technique Speed Business impact When to use it
Disconnect host from network Immed That host is unusable Active exfiltration or spreading malware on
iate the host
Technique Speed Business impact When to use it
| Disconnect host from network Immed | That host is unusable Active exfiltration or spreading malware on | ||
|---|---|---|---|
| iate | the host | ||
| Disable compromised accounts Immed | Affected users cannot log in Stolen credentials in active use | ||
| iate | |||
| Block malicious domain or IP at | Fast Minimal, unless the destination | Known command-and-control or phishing | |
| proxy/firewall | is shared | infrastructure | |
| Isolate a network segment Moder | All hosts in the segment lose | Lateral movement across a segment | |
| ate | connectivity | ||
| Restrict host to a monitored VLAN Moder | Host works under observation You want to watch the attacker before full | ||
| ate | removal | ||
| Leave the host running and | No | None, but risk continues Law enforcement request, or intelligence | |
| monitor it | disrupt | value outweighs risk | |
| ion | |||
| The most debated containment choice is whether to watch or to disconnect. Watching lets analysts learn the | |||
| attacker's tools, targets, and infrastructure, which improves eradication and may reveal other victims. Watching | |||
| also lets the attacker keep stealing data. The decision depends on what is at stake: watching a host that holds | |||
| only public data is defensible; watching a host that holds customer payment data is not. If the decision is to | |||
| watch, it must be a deliberate, authorized decision with a time limit and a monitoring plan - not drift caused by | |||
| indecision. |
Short-term containment. Immediate actions that limit an incident's damage, such as disconnecting a host or
disabling an account. Short-term containment is fast and disruptive, and it is usually followed by long-term
containment and then eradication.
Containment is a business decision as much as a technical one, which is why containment authority is defined
in advance in the incident response plan. An analyst who must ask permission to disconnect a production
server during an active incident has already lost the time that matters. The plan should name who can
authorize isolation of critical systems, and under what conditions, before the incident ever happens.
A common exam scenario: an analyst discovers a compromised host and immediately wipes and rebuilds it. That
is not containment; it is destruction of evidence and a skipped eradication step, because the team never learned
the scope, the persistence mechanisms, or whether other hosts are affected. The correct sequence is to contain
(isolate), analyze (scope and evidence), eradicate (remove all artifacts), and then recover.
Eradication
Eradication removes the cause of the incident and every trace of the attacker's presence. The work depends on
what analysis found, but the checklist is consistent:
• Remove malware and backdoors from every affected host, not just the first one found.
• Remove persistence mechanisms: scheduled tasks, rogue services, startup entries, malicious browser
extensions, and unauthorized accounts.
• Reset credentials: every account the attacker touched or could have touched, including service accounts,
and consider the blast radius of shared or reused passwords.
• Patch or otherwise close the exploited vulnerability, or apply a compensating control if a patch is not yet
available.
• Remove attacker infrastructure access: block command-and-control domains and IPs, and revoke any
attacker-created firewall rules, VPN accounts, or cloud access keys.
• Verify the environment: scan for the same indicators across the estate to confirm no other host carries the
same artifacts.
Eradication questions often hinge on completeness. Removing the malware but leaving the persistence
mechanism means the attacker returns at the next reboot. Removing the persistence mechanism but leaving
the stolen credentials means the attacker logs back in. The correct eradication answer is the one that
addresses every artifact analysis found - malware, persistence, credentials, and the exploited weakness
together.
Eradication can also require rebuilding hosts from known-clean media when the compromise is deep enough
that cleaning cannot be trusted - for example, a rootkit or firmware-level compromise. Rebuilding is slower and
more disruptive, but a cleaned host that still contains a hidden backdoor is worse than a rebuilt host, because it
creates false confidence.
Recovery validation
Recovery returns systems to normal operation, and validation is what makes recovery trustworthy. Recovery
steps include restoring systems from clean backups or rebuilding them, restoring data, re-enabling accounts
and services that were disabled during containment, and returning the system to production. Validation steps
include confirming the system is free of attacker artifacts (scan with updated signatures, check for the incident's
indicators of compromise), confirming the exploited vulnerability is closed, monitoring the recovered system
closely for signs of the attacker's return, and confirming normal business function before declaring the incident
over.
Timeline - recovery of a compromised web server at CertCrack.com
Day 1 09:00 Host isolated; memory and disk images captured
Day 1 14:00 Analysis confirms web shell + scheduled task persistence
Day 2 10:00 Eradication: web shell removed, task deleted, admin credentials reset
Day 2 15:00 Recovery: server rebuilt from known-clean image, vulnerability patched
Day 3 09:00 Validation: full scan clean, no indicators found, monitoring heightened
Day 3 17:00 Monitoring shows no recurrence; system returned to production
Day 5 10:00 Lessons-learned meeting held; action items assigned
The timeline shows the order the exam expects: containment before eradication, eradication before recovery,
validation before return to production, and lessons learned after recovery. Returning a system to production
without heightened monitoring is a common error: the first hours after recovery are when a missed persistence
mechanism announces itself, and close monitoring is what catches it before it becomes a second incident.
Recovery validation. The process of confirming, before a recovered system returns to normal operation, that
attacker artifacts are gone, the exploited weakness is closed, and the system behaves normally under
heightened monitoring.
Root-cause analysis
Root-cause analysis asks why the incident happened, not just what happened. Containment and eradication
answer "how do we stop it"; root-cause analysis answers "why were we vulnerable, and what do we change so it
does not happen again." Without it, the team fixes the symptom and leaves the weakness that produced it.
The 5 Whys technique asks "why" repeatedly, usually five times, following each answer to the next deeper cause.
It is fast, requires no special tooling, and works well for straightforward incidents.
Example - 5 Whys for a phishing success at CertCrack.com
Problem: An employee's credentials were stolen by a phishing email.
Why 1: Why did the employee enter credentials? The email looked like a legitimate login page.
Why 2: Why did it reach the inbox? The email filter did not flag the sender domain.
Why 3: Why did the filter miss it? The domain was newly registered and had no bad reputation yet.
Why 4: Why was there no second defense? The login page had no multi-factor authentication.
Why 5: Why was multi-factor authentication not enforced? Rollout was incomplete for that application.
Root cause: Incomplete multi-factor authentication rollout, compounded by reliance on reputation-based filte
Fix: Complete the rollout and add a rule flagging newly registered domains in external mail.
The fishbone diagram (Ishikawa diagram) is the complementary method for complex incidents: it groups
possible causes into categories such as people, process, technology, and environment, and the team
brainstorms contributing causes under each. The point of both methods is the same discipline: distinguish a
root cause from a contributing cause. A contributing cause made the incident worse; a root cause is the
underlying weakness whose removal prevents recurrence. In the example above, the employee clicking the link
is a contributing cause; the missing multi-factor authentication is a root cause, because with it enforced, the
stolen password alone would not have granted access.
Root-cause questions often present a chain of causes and ask which is the root cause. Do not pick the first
event in the chain (the user clicked) or the most dramatic one (the data was stolen). Pick the underlying
weakness that, if fixed, breaks the chain - usually a missing control, an incomplete rollout, or a process gap.
Every incident has at least two stories: the attacker's story (how they got in and what they did) and the
defender's story (which controls failed or were missing). Containment and eradication close the attacker's
story. Root-cause analysis writes the defender's story, and lessons learned act on it. A team that only tells the
attacker's story will fight the same incident again.
Lessons learned
Lessons learned is the phase most often skipped and the one that most improves the organization over time. It
happens after recovery, while memories are fresh, and it is deliberately blameless: the goal is to find process
and control failures, not to assign personal blame, because blame makes people hide mistakes and the next
incident goes unreported.
A good lessons-learned review covers: what happened and the timeline; what went well (detections that fired,
playbooks that worked, decisions that were fast); what went badly (detection gaps, unclear authority, missing
tools, slow escalation); and action items with owners and deadlines. Action items are the phase's real output: a
new detection rule, an updated playbook, a completed control rollout, a fixed contact list, an added training
module. An action item without an owner and a deadline is a wish, not an improvement, and the exam
sometimes tests exactly that distinction.
The review also feeds back into preparation: updated playbooks, revised severity definitions, new tabletop
exercise scenarios based on the real incident, and metrics that show whether the response is getting faster.
Over time, lessons learned is what turns incident response from a firefighting exercise into a capability that
measurably improves.
IR communications during an incident
Communication during an incident is a controlled activity, not a side effect. Different audiences need different
information, and giving the wrong audience the wrong detail creates harm: telling customers about an
unconfirmed breach destroys trust unnecessarily, while telling executives only that "IT is handling it" leaves
them unable to make decisions about disclosure, legal exposure, or customer notification.
Audience What they need What to avoid
Response team Full technical detail: indicators, timelines, scope Vague summaries that force re-analysis
Management and executives Impact, scope, timeline, decisions needed, next update time Technical jargon, speculation, unconfirmed attribution
Legal counsel Facts, evidence handling, regulatory exposure Conclusions before evidence supports them
Customers and the public What happened in plain language, what data was affected, what to do Speculation, blame, premature "all clear" statements
Regulators Required facts within required timeframes Late, incomplete, or inconsistent filings
Law enforcement Evidence, indicators, timeline Altering evidence or tipping off suspects
Need-to-know. The principle that incident information is shared only with people who require it for their role
in the response. Need-to-know protects the investigation, prevents leaks that could alert the attacker, and
limits legal exposure from premature disclosure.
Three communication rules deserve emphasis. First, never speculate: report what is confirmed, label what is
unconfirmed, and say when the next update will come rather than guessing at an answer. Second, never
attribute publicly: naming a threat actor or a country before evidence supports it creates legal and diplomatic
problems and is almost always premature. Third, keep a communication log: who was told what, when, and by
whom, because disclosure timelines are often examined later by regulators, insurers, and counsel.
Communication questions often test audience-appropriate messaging. Executives get impact and decisions
needed, not log excerpts. The public gets plain language and protective actions, not speculation. And any
question involving regulated data, a suspected crime, or a disclosure deadline is a cue to involve legal counsel
early - analysts do not make disclosure decisions alone.
Chapter check
1. An analyst finds a scheduled task on a server that downloads a remote access tool every time the server
restarts. Which MITRE ATT&CK tactic does this behavior best represent?
A. Execution
B. Persistence
C. Command and Control
D. Discovery
2. A security team is building a detection strategy and wants to know which adversary behaviors they cannot
currently detect at all. Which use of MITRE ATT&CK best serves this goal?
A. Mapping a single incident to techniques
B. Gap analysis against the full technique list
C. Pivoting from a known command-and-control domain
D. Building an activity thread for one intrusion
3. An attacker researches CertCrack.com employees on public websites, then sends them a phishing email
carrying a malicious document. According to the Cyber Kill Chain, which stage is the phishing email itself?
A. Reconnaissance
B. Weaponization
C. Delivery
D. Exploitation
4. During an incident, analysts confirm one compromised host and a command-and-control domain. Using the
Diamond Model, what is the most useful next step to determine the full scope?
A. Rebuild the confirmed host immediately
B. Pivot from the known domain to find other hosts that contacted it
C. Reset all user passwords in the organization
D. Notify customers of a data breach
5. A team restores a compromised database server from backup and returns it to production the same day. The
same malware reappears the next morning. Which phase was most likely skipped or done badly?
A. Detection
B. Containment
C. Eradication
D. Lessons Learned
6. An analyst arrives at a running compromised workstation and must preserve evidence. According to the order
of volatility, what should be collected first?
A. A full disk image
B. Data from archival backup media
C. Memory contents and running processes
D. Remotely logged data from the log server
7. A compromised host holds customer payment card data, and the attacker is actively copying data out. The
team debates whether to keep watching the host to learn the attacker's methods. What is the correct decision?
A. Keep watching, because intelligence value always outweighs risk
B. Disconnect the host, because active theft of regulated data outweighs intelligence value
C. Wait until the next business day to decide
D. Wipe and rebuild the host immediately without capturing evidence
8. After an incident, a review finds that a phishing email succeeded because multi-factor authentication had not
been rolled out to one application, and the email filter missed a newly registered domain. Which is the root
cause?
A. The employee who clicked the link
B. The newly registered domain
C. The incomplete multi-factor authentication rollout
D. The phishing email itself
Answer key
1. B - The task's purpose is to survive restarts and re-establish access, which is the definition of Persistence.
Execution would be the act of running the tool once.
2. B - Gap analysis maps existing detections against the technique list and reveals which tactics and techniques
have no coverage at all.
3. C - The phishing email carrying the weapon is Delivery. Reconnaissance was the earlier research,
Weaponization was building the document, and Exploitation happens when the document's code runs.
4. B - Pivoting from known infrastructure (the domain) to find other victims is how the Diamond Model expands
scope from a single confirmed fact.
5. C - Eradication was skipped or incomplete: the backup contained the malware, or a persistence mechanism
survived, so recovery restored the attacker along with the system.
6. C - Memory and running processes are the most volatile evidence and are lost on reboot, so they are collected
before disk images or remote logs.
7. B - Active theft of regulated payment card data outweighs intelligence value. Watching is defensible only
when the data at risk is low and the decision is deliberate, authorized, and time-limited.
8. C - The incomplete multi-factor authentication rollout is the underlying weakness whose fix breaks the chain:
with it enforced, the stolen password alone would not grant access. The click and the domain are contributing
causes, not the root cause.
Analyst Toolkit: Tools in the Incident Room
Some tools earn their place during an investigation rather than before one. This short toolkit section gathers the five the objectives point to, in the order an incident tends to need them.
YARA (classifying what you recovered). YARA. When responders recover a suspicious file, the first question is "what family is this?" A YARA rule written from the family's known strings and byte patterns answers it in seconds: a match classifies the file so containment and hunting can target the right threat. Hash lookups alone fail on repacked variants; pattern matching does not.
tcpdump (evidence-grade capture). tcpdump. On a headless compromised server, tcpdump captures exactly the traffic that matters with a BPF filter and writes it to a .pcap file. For evidence, the file is hashed at the moment of capture and entered into the chain-of-custody log — the hash is what later proves the capture was never altered.
Metasploit Framework (confirming the entry vector). Metasploit Framework. A scanner can only suggest how an attacker got in. Running the matching exploit module against a lab clone of the affected system confirms whether the CVE in the timeline is genuinely exploitable on that version — the difference between a suspected and a proven root cause.
Maltego (mapping the attacker's infrastructure). Maltego. Starting from one seed — a domain or address found in the logs — Maltego's transforms draw the graph of connected infrastructure from public data: related domains, mail servers, registrants. The graph guides blocking and hunting, and belongs in the report as supporting leads with sources named, never as proof of attribution by itself.
Caldera (proving the gap is closed). Caldera. The last tool an incident needs is the retest. After new detections are written, a Caldera operation replays the attacker's technique chain under controlled conditions; the detections firing — or not — is the evidence that the gap found by the incident is closed before the case is signed off.
Evidence before conclusions. In incident scenarios, the exam rewards the tool that produces proof: YARA for classification, hashes for capture integrity, Metasploit for exploitability, a Caldera retest for detection closure. Answers that merely re-scan or re-ask are the distractors.
Want the full CompTIA CySA+ (CS0-004) package?
This guide is free to read. Get the full CS0-004 practice exam — 750 questions plus 10 PBQs — with the complete PDF and online access.
Get CS0-004 Full Access — $10