HackBlue

Tools · Workbench

Forensics tools

Lessons on preserving and reading disks, memory, and logs from systems you were asked to examine.

  • 25 lessons
  • 6.5 h of reading
  • 5 topics

The useful question is what an artifact can support, and where the tool stops being evidence. The lessons linked below cover disk images, memory, and logs in those terms.

Examine systems you own or were asked to examine. Take a copy, record the hash, and work on the copy so the original stays unchanged.

  1. 01Autopsy: open a case you can still explainA case is the container for an image, the parsed results, and the notes that say what you did. Set the hash, the timezone, and the ingest you can defend before you start clicking through files.16 min
  2. 02Autopsy: build a timeline and read it in orderA folder tree shows what is on disk. A timeline shows what happened in time, and only after you know which timestamp source each row came from.17 min
  3. 03Autopsy: names, deleted files, and hash setsA file name, the bytes still on disk, and a hash match are three separate facts. Hash sets tell you where to spend the afternoon. They do not close the case.16 min
  4. 04Autopsy: browser, downloads, and the traces a person leavesRecent activity is a set of databases Windows and the browsers already kept. Read each store for what it records, and keep a missing row as a missing row.17 min
  5. 05Autopsy: tags, notes, and a report a second reader can useTags are how you gather the files that matter. The report is how someone who never opened the case can see what you saw, where it came from, and what you are not claiming.15 min
  1. 01Volatility 3: an image, a symbol table, and the first pluginA memory image is a snapshot of RAM. Volatility 3 can read it only after a symbol table matches the kernel that was running. windows.info is how you check that match before you believe a process list.16 min
  2. 02Volatility 3: processes, parents, and command lineswindows.pslist is the live list. windows.psscan is a search for process objects that remain in memory. The command line, when it is still readable, tells you how a process was started.17 min
  3. 03Volatility 3: connections still sitting in memorywindows.netscan lists network objects the kernel still has in the snapshot. You get addresses, ports, state, and an owner when the structure still points at one. You do not get the payload.16 min
  4. 04Volatility 3: loaded modules and private executable memorywindows.dlllist and windows.ldrmodules describe modules a process loaded. windows.malfind points at private executable pages. Each hit is a region to account for, and security tools produce hits too.16 min
  5. 05Volatility 3: files and registry hives cached in RAMThe kernel caches file objects and registry hives. windows.filescan and the registry plugins let you see names that were open recently, including some the disk timeline already showed you from a different side.16 min
  1. 01YARA: a rule is a claim you can run againA YARA rule names the bytes you care about and the condition that counts as a hit. A hit means the pattern was present. It is a queue for an examiner, and the meta block is how the next person knows why the rule exists.15 min
  2. 02YARA: strings and conditions that stay specificText, wide text, and hex are different needles. The condition is where you decide how many of them must be present, and where most false positives are either invited or refused.17 min
  3. 03YARA: scan the files the case already holdsRun the rule against the export folder, print the strings that fired, and triage each hit. The command is the easy part. The case log is the result.15 min
  4. 04YARA: describe a portable executable without quoting a payloadThe PE module lets a rule talk about imports, sections, and an import hash. Use it to describe a binary you already have, and keep the hit as a cluster to review.16 min
  5. 05YARA: test a rule before the hit becomes a findingA rule earns a place in the report only after a must-hit file hits, a must-not-hit file stays quiet, and the wording of the finding matches the condition you actually wrote.15 min
  1. 01CyberChef: a recipe is a chain you can hand to someone elseCyberChef applies a sequence of operations to bytes you already have. The input, the operation list, and the output are the exhibit. Save all three with the case number.15 min
  2. 02CyberChef: encodings that show up in real evidenceBase64, hex, URL encoding, and UTF-16 are ways a log stores bytes. Recognizing them lets you recover text you were already holding, and the alphabet is a check against a wishful decode.17 min
  3. 03CyberChef: raw clocks, epochs, and case timeUnix time and Windows FILETIME are numbers you will find in logs and registry extracts. Convert them, then apply the same timezone you set in Autopsy before you put a clock time in the report.16 min
  4. 04CyberChef: decode with a key the case already recoveredWhen a note, a config, or a memory string already holds the key, XOR and similar operations are just another recipe step. The check is whether the output is the format you expected.16 min
  5. 05CyberChef: pull URLs and strings out of a blob you already haveExtract URLs and Strings are scanners for a buffer you already collected. They make a list of leads. Each lead still has to be found in a real exhibit before it is a finding.15 min
  1. 01Sysmon: the log is only as wide as the configSysmon writes process, file, registry, and network events to a Windows log. Which of those IDs appear depends on the configuration that was installed. Read that config before you treat a gap as a quiet host.16 min
  2. 02Sysmon: Event ID 1, a process being createdEvent ID 1 records a new process: image path, command line, user, hashes, and the parent. Read the parent and the path together. A stock binary can still be the process that copied the file.17 min
  3. 03Sysmon: Event ID 3 and Event ID 22Event ID 3 is a connection opened by a process. Event ID 22 is a DNS query. Together they name a peer. They still do not contain the file that may have been transferred.16 min
  4. 04Sysmon: files, registry values, and deletesEvent IDs 11, 13, 15, 23, and 26 record files and registry values a process touched. Use them to corroborate the Temp path and to see whether anything was set up to run later.17 min
  5. 05Sysmon: follow one ProcessGuid across the logThe case becomes a single chain when Event IDs 1, 11, 22, and 3 share a ProcessGuid. Other IDs, including 7, 8, and 10, are how you notice a second process. Security tools generate those too.17 min