Chapter 27 — Verification of eradication and restoration | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["27.1 Persistence paths"]
  N2["27.2 Verification tests"]
  N3["27.3 Negative evidence"]
  N4["27.4 Residual uncertainty and reopening triggers"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["27.1 Persistence paths"]
  N2["27.2 Verification tests"]
  N3["27.3 Negative evidence"]
  N4["27.4 Residual uncertainty and reopening triggers"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]

[Learning outcomes and connection]
    |
    v
[27.1 Persistence paths]
    |
    v
[27.2 Verification tests]
    |
    v
[27.3 Negative evidence]
    |
    v
[27.4 Residual uncertainty and reopening triggers]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes and connection

You will be able to (1) enumerate persistence paths across hosts and identity; (2) design verification tests that can actually fail; (3) interpret negative evidence correctly; and (4) define reopening triggers and residual uncertainty. Chapter 26 restored service; this chapter asks how you know the attacker is gone. Chapter 28 then examines why signals are missed.

27.1 Persistence paths

Attackers keep access through persistence: on hosts (services, scheduled tasks, startup items, web shells, modified binaries), in identity (added credentials, MFA methods, OAuth application consents, mailbox rules, new accounts, federation trust changes), and in the network (VPN accounts, firewall rules). Eradication that cleans the host but not identity persistence leaves the door open. MITRE ATT&CK catalogues persistence techniques and is a useful checklist source.

The nurse-07 case shows the gap: WS-031 was reimaged, but the phone authenticator added on 13 March survived.

27.2 Verification tests

A verification test should have a defined procedure, an expected result if eradication succeeded, and — critically — the possibility of failing. "Antivirus scan is clean" is weak if the antivirus missed the original intrusion. Stronger tests target the specific persistence mechanisms found and the mechanisms the attacker could plausibly have used, across independent sources.

In the nurse-07 case, listing MFA methods with their registration dates is a test that can fail, and it did: it revealed the second phone authenticator. A test that only confirmed the reimaged workstation was clean could never have shown the identity persistence that let the attacker back in on 16 March.

27.3 Negative evidence

Absence of evidence is evidence of absence only when the search could have found the thing. A search for a malicious scheduled task across all hosts, using a tool known to enumerate tasks reliably, that finds none, is meaningful. A search on hosts whose telemetry was offline is not.

The fleet search in the nurse-07 case reached 412 of 418 endpoints. Finding no helper on those 412 is meaningful; the six offline machines are listed as unknown and searched when they reconnect, rather than counted as clean.

27.4 Residual uncertainty and reopening triggers

Verification reduces uncertainty; it rarely eliminates it. State what was tested, what was not, and the triggers that would reopen the case — for example a sign-in by a rotated credential, or traffic to known attacker infrastructure.

In the nurse-07 case, the plan named its triggers in advance: any sign-in from the unfamiliar address range, any detection of the helper's hash, and any new MFA method on clinical accounts without a help-desk ticket. Because the triggers were written before the result, finding the authenticator registered on 13 March led directly to reopening rather than to debate about whether it mattered. State residual uncertainty in plain words, such as "six endpoints not yet checked", so a reader knows exactly what closure does not cover.

27.5 Worked example (synthetic): cleaned host, fresh sign-in

Fictional. Workstation WS-031 (Chapter 11) was reimaged on 14 March after a malicious helper was confirmed. On 16 March 03:12, the IdP records a successful sign-in for nurse-07 (the workstation's usual user) from an unfamiliar address, passing MFA by push.

Analysis: the host was cleaned, but the user's credential and MFA were not addressed. Possible persistence: the password was captured by the malware; the attacker may have registered an MFA method or trained the user to accept pushes; there may be a mailbox rule or OAuth consent.

Verification plan: - Identity: list MFA methods and registration dates for nurse-07; list OAuth consents and mailbox rules; review sign-ins since 1 March. - Host: confirm the reimaged WS-031 has no reconnection to the helper's update domain (DNS and proxy logs since 14 March). - Fleet: search all endpoints for the helper's hash and the scheduled-task name (tool coverage confirmed: 412 of 418 endpoints reporting; 6 offline listed). - Network: block and monitor the known command domain. Reopening triggers: any sign-in from the unfamiliar address range; any helper hash detection; any new MFA method on clinical accounts without help-desk ticket.

Result (fictional): a second phone authenticator was registered on 13 March — before reimaging. Eradication was incomplete; the case reopens. Lesson: the eradication checklist must include identity, not only the host.

27.6 Common errors and limits

Equating reimaging with eradication.
Tests that cannot fail.
Claiming fleet-wide absence with incomplete telemetry coverage.
Closing without reopening triggers.
Cleaning the host while leaving the user's credential, MFA methods, mailbox rules and application consents untouched, as happened with nurse-07.
Searching only for the indicators already found, not for persistence the attacker could plausibly have added.
Treating offline endpoints as clean because the search returned no hits for them.
Writing reopening triggers that nobody is assigned to watch.
Reporting a case as closed without stating which checks were skipped or could not be completed.

Exercises — chapter 27

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX079 — Persistence inventory. Steps: list eight persistence mechanisms an attacker with a user's mailbox and laptop access could use, grouped by host and identity. Rubric: 3 = at least four per group, accurate; 2 = six total; 1 = host only; 0 = none.

EX080 — Make the test fail-capable. Inputs: "We ran a full antivirus scan; it was clean, so the host is eradicated." Steps: rewrite as a verification test that could fail. Rubric: 3 = specific artefacts (hash, task name, domain), defined procedure, coverage, expected result; 2 = partial; 1 = another generic scan; 0 = none.

EX081 — Coverage statement. Inputs: fleet search found no hash on 412 of 418 endpoints; 6 offline. Steps: write the result sentence and next action. Rubric: 3 = "no detections on 412 reporting endpoints; 6 unknown" with plan to check them on reconnection or manually; 2 = misses unknowns; 1 = "fleet clean"; 0 = none.

Chapter synthesis

Eradication spans hosts, identity and network. Verify with targeted tests that could fail, state coverage so that negative evidence means something, record residual uncertainty and set reopening triggers.