Chapter 9 — Digital forensics and malware analysis: tools and methods
Lesson map
Lesson 09 published. Map, example, EX033.
flowchart TD
N0["Learning outcomes"]
N1["9.1 EDR console"]
N2["9.2 Memory capture"]
N3["9.3 Triage collection"]
N4["9.4 Sample handling"]
N5["9.5 Static triage results"]
N6["9.6 Tool records"]
N7["9.7 Validation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX033"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 EDR console"]
N2["9.2 Memory capture"]
N3["9.3 Triage collection"]
N4["9.4 Sample handling"]
N5["9.5 Static triage results"]
N6["9.6 Tool records"]
N7["9.7 Validation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX033"]
[Learning outcomes]
|
v
[9.1 EDR console]
|
v
[9.2 Memory capture]
|
v
[9.3 Triage collection]
|
v
[9.4 Sample handling]
|
v
[9.5 Static triage results]
|
v
[9.6 Tool records]
|
v
[9.7 Validation]
|
v
[Worked example] --> [Exercise EX033]
Learning outcomes
You will (1) use EDR, memory capture and triage tools under procedure; (2) hand suspicious files to analysts safely; (3) understand basic static triage results; (4) record tool use.
9.1 EDR console
The console provides process trees, file events, network events and containment. Exports are hashed on download.
For WARD4-PC2 the process tree showed explorer.exe starting wscript.exe and then svch.exe, and the network events showed the contact with update-cdn.example.net. Each export is hashed when downloaded so the console view and the saved file can be compared later. Containment is applied from the same console, which records who applied it and when. Containment, export and download each appear in the console's own audit trail with the operator's name.
9.2 Memory capture
Before reimaging, Sana captures memory from WARD4-PC2 and PHARM-PC3 using the approved tool from the kit drive, recording tool version, commands and times.
Memory holds running processes and network connections that disappear when the PC is switched off or reimaged. The approved tool is run from kit drive KIT-02 rather than downloaded, so its version and hash are known in advance. On PHARM-PC3 the capture ran from 11:42 to 11:51, and its hash went into the collection log. WARD4-PC2's capture also ran before the 14:30 reimage, as the runbook gate required.
9.3 Triage collection
The triage tool gathers event logs, registry hives, prefetch, startup folders and file listings. Output is hashed into a manifest.
The tool runs from the same kit drive and writes its output there, not to the ward PC's disk, so the PC's own files are not overwritten. On PHARM-PC3 the collection produced a manifest of 63 files with its own hash. That manifest is what later verification compares each file against. Collection on PHARM-PC3 took twelve minutes, from 11:55 to 12:07. The kit drive is checked for free space before each run.
9.4 Sample handling
svch.exe and run.vbs are copied into a password-protected archive and sent to the hospital's external malware analysis provider through the agreed secure channel, with hashes and context. Operators never open samples.
Handing the files over with hashes and context, and never opening them, keeps Sana within the course's safety boundary and the hospital's rules. The archive password travels by a separate route from the archive itself. The analysis contract allows two samples a month, and these two used the whole allowance, so any further sample would need a purchase approval.
9.5 Static triage results
The analyst reports: svch.exe is a known remote-access tool family by hash; its strings include update-cdn.example.net; it persists through the startup folder. Sikorski and Honig (2012) describe this kind of triage — hashes, strings, imports — as the safe first step.
The analyst's report answers questions Sana could not safely answer herself, such as whether the domain was built into the program. Matching the startup-folder persistence she had recorded gives her an independent check on her own findings. She quotes the report rather than rewording it, and attributes each statement to the analyst.
9.6 Tool records
The ticket lists every tool, version and output hash.
For each tool the ticket records its name, version, where it was run from, its command and the hash of what it produced. That list lets another operator repeat the collection and explains any changes the tools made to the live PCs. Tools not on the approved kit list need Owen's agreement first, recorded with the reason. The list also shows which actions changed the live PCs, so the analyst can separate them from attacker activity.
9.7 Validation
Tools on the kit are validated before inclusion; NIST CFTT results are consulted where available.
Validation means each tool has been tested on known data before it is trusted with case evidence. NIST's Computer Forensics Tool Testing programme publishes results for some tools, and the hospital keeps its own test notes for the rest. A tool that fails validation stays off kit drive KIT-02 until fixed. Owen keeps the validation notes beside the kit list, so a reviewer can see when each tool on KIT-02 was last tested.
Choosing between tools
When two tools could answer a question, Sana picks the one on the approved kit list with the smallest footprint on the live PC. A remote EDR query is preferred to logging in interactively, because it leaves fewer traces and is already recorded by the console. Interactive sessions are used only when the console cannot reach the data, and then the reason is written in the log.
Worked example
Sana's collection log for PHARM-PC3: "11:42 memory capture started (kit tool v3.2, drive KIT-02); 11:51 complete; SHA-256 recorded. 11:55 triage collection started; 12:07 complete; manifest 63 files; manifest hash recorded." Owen reviews and countersigns.
Synthetic case. The logs are invented.
Errors and limits
Running tools on a live PC alters it; record every action so effects can be accounted for.
Exercises
- EX033 — Sample handover. How were samples sent to the analyst? Rubric: 3 = protected archive, secure channel, hashes and context; 2 = partial; 1 = emailed plainly; 0 = none.
- EX034 — Analyst findings. Summarise the static triage findings. Rubric: 3 = known RAT family by hash; domain string; startup persistence; 2 = two; 1 = one; 0 = none.
- EX035 — Collection log. List four items in Sana's collection log. Rubric: 3 = times, tool version, drive ID, hashes/manifest; 2 = three; 1 = one; 0 = none.
- EX036 — Live alteration. Why record every action on a live PC? Rubric: 3 = tools alter state; account for effects; 2 = partial; 1 = habit; 0 = none.
Synthesis
Use approved tools by procedure, hand samples to analysts safely and record every tool action.
Continue studying — chapter 09 of 18
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →