49 min read

> Where you are: Part V, Chapter 30 of 40. Chapter 29 showed you what happens when an examination hits a wall of strong encryption you cannot break — a genuine limit, honestly stated. This chapter is about the other thing people do when they don't...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 30: Anti-Forensics — How People Try to Hide Evidence (and How to Detect That They Tried)

Where you are: Part V, Chapter 30 of 40. Chapter 29 showed you what happens when an examination hits a wall of strong encryption you cannot break — a genuine limit, honestly stated. This chapter is about the other thing people do when they don't want to be found: they wipe, they backdate, they hide, they clear logs, they route through Tor. It is the second home of anchor case #2 — the departing engineer whose "PC cleaner" was supposed to erase the theft and instead documented it. The lesson Chapter 16 previewed gets its full treatment here, and it is the most liberating idea in the book: the attempt to destroy evidence is itself evidence.

Learning paths: This is a core chapter for the 🔍 Forensic Examiner — detecting timestomping, wiping, log tampering, and data hiding is bread-and-butter casework, and it is where examiners most often get fooled or, worse, fool themselves. 🛡️ Incident Response lives here too: sophisticated intruders clear event logs, timestomp dropped tools, and hide data in alternate data streams and slack, and you must recognize the tells fast. 📜 Legal/eDiscovery practitioners should read the spoliation and "absence as a finding" sections closely — destruction of evidence has its own legal weight, sometimes greater than the evidence destroyed. 💾 Data Recovery technicians get a hard, practical lesson: a region that has been genuinely wiped is gone, and recognizing that early protects both your time and your client's expectations.

The central paradox: hiding evidence creates evidence

Start with a definition and a paradox. Anti-forensics is any technique intended to prevent, mislead, or complicate a forensic examination — to destroy evidence, hide it, alter it, or obscure who did what and when. The paradox, which is the third recurring theme of this book made razor-sharp, is this: almost every anti-forensic act leaves its own trace. You wipe a file and the wiping tool writes a prefetch entry recording that it ran. You backdate a file and the kernel-maintained $FILE_NAME timestamps keep the truth. You clear the Security log and Windows writes event 1102 announcing that the log was cleared, by whom, and when. You hide data in an alternate data stream and dir /r lists it in one command. The would-be evidence-destroyer is in the position of a burglar who mops the floor to remove footprints and leaves a long, clean, suspicious streak across a dusty room.

This is not a comforting platitude — it is a structural fact about how modern operating systems work. Windows, macOS, and Linux are built to be fast, convenient, and recoverable, which means they cache, log, index, journal, and redundantly record nearly everything. An adversary cannot simply "delete the evidence" because there is no single place where the evidence lives; it is smeared across the registry, prefetch, event logs, the file system journal, link files, jump lists, browser databases, memory, and the network. To erase it all, you would need to know every artifact — and the people who know every artifact are the examiners, not the suspects. The corollary, stated plainly for the cross-examination you will someday face: anti-forensics rarely beats a thorough examiner; it usually convicts the person who attempted it.

Recall the anchor. A senior mechanical engineer — user jrivera on workstation image WS-ENG-04.E01 — gave notice to join a competitor, connected a personal SanDisk Cruzer Glide (serial 4C530001234567890123) on a Friday evening, copied proprietary turbine-housing CAD files, and then on Saturday morning ran CCleaner with "wipe free space" enabled, backdated the local copies, and emptied the Recycle Bin. Chapter 16 told the discovery side of that story — how the Windows artifacts surfaced the theft. This chapter tells the anti-forensics side: exactly which acts of concealment jrivera attempted, why each one failed, and how you, methodically, detect each one. By the end you will see that every step taken to hide the theft added a dated, attributable line to the timeline.

Why This Matters. In court, evidence of concealment is often more persuasive than the underlying act. A juror may not understand CAD file formats or volume serial numbers, but everyone understands "he tried to destroy it." Spoliation — the destruction or alteration of evidence relevant to litigation — can trigger an adverse-inference instruction (the jury may assume the destroyed evidence was unfavorable), sanctions, or even default judgment. The legal weight of the cover-up frequently exceeds the weight of the thing covered up. That is why detecting and documenting anti-forensic activity is not a side quest; it is sometimes the whole case.

A taxonomy of anti-forensics

It helps to organize the field before diving in. Anti-forensic techniques fall into five families, and most real adversaries combine several:

ANTI-FORENSIC TECHNIQUES (and the chapter's detection focus)
┌───────────────────────────────────────────────────────────────────────────┐
│ 1. DATA DESTRUCTION    — make the data unrecoverable                        │
│      secure wiping (single-pass/DoD/Gutmann), free-space wipe,             │
│      ATA Secure Erase, crypto-erase, physical destruction                 │
│      DETECT: zeroed/random regions, wiping-tool artifacts, surviving meta  │
├───────────────────────────────────────────────────────────────────────────┤
│ 2. DATA HIDING         — keep the data but make it hard to find            │
│      NTFS alternate data streams, slack space, HPA/DCO,                    │
│      steganography, extension/signature mismatch, hidden partitions       │
│      DETECT: stream enumeration, slack extraction, signature analysis     │
├───────────────────────────────────────────────────────────────────────────┤
│ 3. DATA TRANSFORMATION — make the data unreadable                          │
│      encrypted containers (VeraCrypt), full-disk encryption, packing,     │
│      obfuscation, plausible-deniability hidden volumes                     │
│      DETECT: entropy analysis, container-app artifacts (defer FDE → Ch.29) │
├───────────────────────────────────────────────────────────────────────────┤
│ 4. TRAIL OBFUSCATION   — corrupt the record of what happened               │
│      timestomping, log clearing/editing, MRU wiping, file renaming        │
│      DETECT: $SI vs $FN, sub-second patterns, EventRecordID gaps, USN      │
├───────────────────────────────────────────────────────────────────────────┤
│ 5. COUNTER-ATTRIBUTION — hide WHO and FROM WHERE                           │
│      Tor, VPNs, proxies, anonymous OS (Tails), spoofing                    │
│      DETECT: endpoint/install artifacts, memory, network correlation       │
└───────────────────────────────────────────────────────────────────────────┘

We will take these roughly in order, then close with the meta-method that ties them together: reasoning from the absence of expected artifacts. Throughout, hold the book's defensive framing firmly. This chapter teaches you to detect concealment, not to perform it. We will name the tools and explain the mechanisms because you cannot detect what you do not understand, but there is no evasion playbook here — only the examiner's side of the table.

Ethics Note. The mirror image of detection is evasion, and the line matters. Knowing that timestomping zeroes sub-second fractions is detection knowledge; it tells you what to look for. This book does not, and you should not, package these mechanisms as a how-to-disappear guide. The same rule governs the whole DataField series (see the Cybersecurity and Assembly volumes): understand offense to mount defense, never to enable it. And when you do detect concealment, the sixth theme applies — the human cost is real. A finding that someone tried to destroy evidence is grave; state it with the same rigor and restraint as any other finding, and never inflate "I cannot rule out wiping" into "they wiped it."

Secure deletion and wiping

The first theme of this book is deleted ≠ destroyed: ordinary deletion removes a pointer (an MFT entry's allocation flag, an inode link count, a FAT chain) while leaving the data in place until something overwrites it. That is what makes recovery possible. Secure deletion — wiping — is the deliberate attempt to defeat that: to actually overwrite the data so the pointer leads nowhere and the bytes are gone. Understanding wiping is therefore understanding the one operation that genuinely defeats recovery, and recognizing it is a core skill for both disciplines.

The overwriting standards, and the myth of many passes

A great deal of folklore surrounds how many times you must overwrite data to destroy it. The famous standards:

  • Single-pass overwrite — write zeros, or a single pass of random data, across every sector once. Fast, simple, and — on modern drives — sufficient.
  • DoD 5220.22-M — the U.S. Department of Defense's old National Industrial Security Program standard, popularly cited as a "3-pass" wipe: pass 1 writes a fixed character, pass 2 its complement, pass 3 random data, with a verify. A 7-pass variant ("5220.22-M ECE") also circulated. Note well: the DoD deprecated this as a prescribed sanitization method years ago and now defers to NIST guidance. "DoD wipe" persists in tool menus as marketing, not as a current requirement.
  • Gutmann 35-pass — Peter Gutmann's 1996 paper "Secure Deletion of Data from Magnetic and Solid-State Memory" defined a 27-pattern (plus random) sequence designed to defeat data remanence on the specific magnetic encodings (MFM and RLL) used by drives of that era. It was never meant to be a universal 35-pass ritual, and Gutmann himself wrote an epilogue saying so.

Here is the truth that matters in practice. On any hard drive manufactured in roughly the last two decades, a single overwrite pass is enough to make the original data unrecoverable. The areal density of modern platters is so high that the magnetic-force-microscopy "recover the faint previous bit from track edges" technique that motivated multi-pass standards simply does not work. The empirical study to cite is Wright, Kleiman, and Sundhar, "Overwriting Hard Drive Data: The Great Wiping Controversy" (2008): across thousands of measurements they found the probability of correctly recovering a single overwritten bit via magnetic microscopy was about 56% — barely better than flipping a coin — and the probability of recovering a meaningful run of bytes was vanishingly small. NIST Special Publication 800-88 Rev. 1, Guidelines for Media Sanitization (2014), codifies the consensus: for modern ATA drives, a single overwrite ("Clear") is adequate; the elaborate multi-pass schemes provide no additional security on current media.

Why This Matters. As a recovery technician, this controls your expectations and your client conversation. If a drive region has been overwritten even once with zeros or random data, you cannot get it back with software, and no clean-room or "deep recovery" service can either — the multi-pass mythology sometimes leads desperate clients to believe a magnetic-microscopy lab can resurrect a single-pass-wiped file. It cannot, at any price. As a forensic examiner, it controls your conclusions: a wiped region is wiped, and "the data was overwritten and is unrecoverable" is the honest, final finding.

Why SSDs change the picture entirely

Everything above assumes a spinning hard drive where logical block addresses map to fixed physical locations. On SSDs and flash media, that assumption collapses, as Chapter 9 explains in depth. The flash translation layer (FTL) remaps logical blocks to physical NAND pages for wear-leveling, so when a wiping tool "overwrites LBA 5,000,000," the controller may write the new data to an entirely different physical cell and leave the old cell's contents intact (just unmapped) until garbage collection erases it. Consequences cut both ways:

  • A software multi-pass overwrite on an SSD is both unnecessary and unreliable — it hammers the drive with writes without guaranteeing the original physical cells are touched.
  • The correct way to sanitize flash is at the controller level: the ATA SECURITY ERASE UNIT (Secure Erase) command, or better, a cryptographic erase (SANITIZE crypto-scramble) on a self-encrypting drive, which destroys the internal key and renders all cells instantly unreadable.
  • TRIM complicates recovery independently: when a file is deleted on a TRIM-enabled SSD, the OS tells the controller those blocks are free, and the controller may zero them in the background within seconds. This is not anti-forensics — it is normal SSD behavior — but it produces the same result, and you must not mistake TRIM-induced loss for deliberate wiping. (See Chapter 9 — SSD and Flash Recovery for the full treatment.)

Detecting that a wipe happened

You usually cannot recover wiped data — but you can very often detect that wiping occurred, and dated, attributed evidence of wiping is itself a powerful finding. The tells:

Anomalous regions. A zero-wipe produces long, perfectly uniform runs of 00; a random-wipe produces high-entropy noise with no file structure. Both are anomalous against the mixed, structured data of a normally-used drive. Compare these two raw views:

Zero-wiped region (free-space wipe with zeros) — entropy ≈ 0.0 bits/byte
0x0A3C0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0x0A3C0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
   ... continues for hundreds of megabytes of contiguous unallocated space ...

Random-wiped region (single pass of PRNG data) — entropy ≈ 8.0 bits/byte
0x1F800000  3A C1 90 7E 22 D4 6B 08  EE 4F A9 15 7C 33 B0 D9   :..~".k..O..|3..
0x1F800010  91 5D 2C E7 48 12 FA 86  0B 9C 71 3E DF 64 A0 27   .],.H.....q>.d.'
   ... no headers, no footers, no carvable structure: deliberate, not natural ...

The distinction matters: random-wiped space can look like encrypted space (both approach 8.0 bits/byte), so entropy alone does not tell you which. You corroborate with the tool artifacts below.

Surviving metadata — the inverted theme. Wiping destroys content, but it frequently leaves metadata behind. The MFT entry for a securely deleted file may still hold its name, original size, and $STANDARD_INFORMATION`/`$FILE_NAME timestamps even though every content cluster is now zero. Many wiping tools also rename a file to a junk pattern before overwriting and deleting it, so you find deleted MFT entries with names like ZZZZZZZZ.ZZZ or AAAA0001.tmp and a zeroed data run — a signature of tool-driven secure deletion. The "wipe free space" function leaves an especially loud trace: the tool creates one or more enormous temporary files that fill the volume's free space with zeros or random data, then deletes them, leaving a vast contiguous wiped region plus a freshly deleted MFT entry for the temp file. So here the first theme inverts: destroyed content, surviving metadata — and the metadata tells you a file once existed and was deliberately erased, with a name, a size, and a time.

The tool's own artifacts. This is the decisive category and it gets its own section next, because it is where the anchor case turns.

Recovery vs. Forensics. A wiped region reads identically to both disciplines, but it triggers opposite responses. For the 💾 recovery technician, recognizing a single-pass-wiped region means stop — the data is unrecoverable, and the professional move is to document it and manage the client's expectations honestly rather than burn hours and hope. For the 🔍 forensic examiner, that very same region, especially with a surviving ZZZ-pattern MFT entry and a wiping tool's prefetch nearby, is an affirmative finding of intentional destruction with a timestamp. Same bytes; one reads them as a dead end, the other as a smoking gun.

Evidence-destruction tools and the artifacts they leave

Wiping tools are the most common anti-forensic technology you will encounter, precisely because they are mass-market and easy to run. The irony at the heart of this chapter is that running one of these tools is itself a logged, dated, attributable program execution — and Windows records executions in places the tools do not clean. Let us catalog the common tools and, more importantly, the artifacts each leaves behind.

COMMON EVIDENCE-DESTRUCTION TOOLS AND THE TRACES THEY LEAVE
┌──────────────┬───────────────────────────┬────────────────────────────────────┐
│ Tool         │ What it does              │ Artifacts of ITS OWN execution       │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ CCleaner     │ clears browser/MRU/temp,  │ SOFTWARE\Piriform\CCleaner key +    │
│ (Piriform)   │ "wipe free space"         │ config; CCLEANER64.EXE-*.pf;        │
│              │                           │ Amcache SHA-1; UserAssist; install  │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ Eraser       │ scheduled secure delete,  │ install keys; Eraser.exe prefetch;  │
│              │ renames before wiping     │ Task Scheduler entries; ZZ-renames  │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ BleachBit    │ cross-platform cleaner,   │ prefetch; AppData config/INI;       │
│              │ free-space wipe           │ on Linux: ~/.config/bleachbit       │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ SDelete      │ Sysinternals CLI wipe     │ prefetch; EULA-accept registry key; │
│ (sdelete)    │ (in-place overwrite)      │ Amcache SHA-1; download in Recent   │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ cipher /w    │ built-in Windows free-    │ no install (native); but prefetch   │
│              │ space wipe                │ CIPHER.EXE-*.pf; the wiped region   │
├──────────────┼───────────────────────────┼────────────────────────────────────┤
│ DBAN /       │ whole-disk boot wipe      │ leaves NOTHING on the wiped disk —  │
│ nwipe        │ (HDD)                     │ but the boot media + purchase trail │
└──────────────┴───────────────────────────┴────────────────────────────────────┘

Note the spectrum. At one end, a tool like DBAN that boots from external media and wipes the entire disk leaves nothing on that disk — but it also leaves the disk conspicuously, anomalously blank (a finding in itself), and the investigation moves to the boot media, the purchase or download record, and other devices. At the other end, an in-OS cleaner like CCleaner cannot wipe the artifacts of its own execution because those artifacts are being written by the operating system as the tool runs, in locations the tool's authors never enumerated.

The anchor: CCleaner convicts itself

Return to jrivera. The detection of the cleaner is a clean three-step corroboration, each step independent of the others:

Step 1 — the tool was installed and configured to wipe. The registry hive SOFTWARE contains Piriform\CCleaner, with the option to wipe free space enabled and a last-write timestamp. The mere presence of this key, parsed with RECmd, establishes that the tool existed and how it was configured. (Cross-reference Chapter 16 — Windows Forensics for the registry mechanics.)

Step 2 — the tool ran, when, and how many times. The Prefetch directory holds CCLEANER64.EXE-A1B2C3D4.pf. Parsed with PECmd, it reports a run count of 3 and a last run of Saturday 09:14:22 — the morning after the Friday-evening device connection. Prefetch proves execution, not mere presence:

PECmd.exe -f "CCLEANER64.EXE-A1B2C3D4.pf"

Executable name: CCLEANER64.EXE
Run count:       3
Last run:        2024-03-16 09:14:22   (Saturday)
Other run times: 2024-03-12 18:02:55, 2024-03-09 08:41:10
Files referenced (excerpt):
  \PROGRAM FILES\CCLEANER\CCLEANER64.EXE
  \USERS\JRIVERA\APPDATA\LOCAL\TEMP\...

Step 3 — this user ran it. UserAssist in jrivera's NTUSER.DAT shows CCleaner64.exe launched via the GUI by that account, last execution Saturday 09:14, and AmcacheParser confirms the binary's presence with its SHA-1 hash. Three independent artifacts — registry config, prefetch, UserAssist — agree on the same tool, the same user, and the same minute. That is a finding robust to any single tool's parsing quirk.

The decisive insight: the cleaner cleaned everything its authors anticipated and nothing they did not. It cleared browser history and MRU lists; it did not, and could not, delete its own prefetch record, its own Amcache hash entry, its own UserAssist execution count, or its own installation key — because Windows wrote those about CCleaner, in subsystems CCleaner does not manage. Running the anti-forensic tool created the very artifacts that prove the anti-forensic act.

Reading the gaps the cleaner left

Beyond convicting itself by running, the cleaner leaves a second, subtler signature: the dated holes where data used to be. This is theme #3 in its purest form — the absence of a trace is itself a trace.

  • Browser history that ends abruptly. The browser databases (Chapter 18's domain) show normal activity for months and then stop at Saturday 09:14 — not tapering off as a user would naturally, but cut clean at the exact minute the cleaner ran.
  • MRU lists that are empty but recently written. Several NTUSER.DAT most-recently-used keys (RecentDocs, TypedURLs, RunMRU) contain no values yet carry a key last-write time of Saturday 09:14. An MRU that was never used would have an old last-write time; an MRU that is empty with a fresh last-write time was emptied. Emptiness plus a recent timestamp equals deletion.
  • Recycle Bin metadata that survived. Two $I` records in `$Recycle.Bin\<jrivera-SID>\ record TurbineHousing_v7.sldprt and a sibling deleted Saturday 09:12 — minutes before the cleaner ran. Even where the $R` content is gone, the `$I metadata gives original path, size, and deletion time. The deletions and the wipe line up to the same two-minute window.
THE DATED GAP — CCleaner's footprint on WS-ENG-04 (user jrivera)
RecentDocs\.sldprt   values: (none)     last-write: 2024-03-16 09:14   ← emptied, dated
TypedURLs            values: (none)     last-write: 2024-03-16 09:14   ← emptied, dated
Browser history      last entry:        2024-03-16 09:14   ← cut clean at the same minute
$Recycle.Bin $I      deleted:           2024-03-16 09:12   ← 2 min before the wipe
Prefetch CCLEANER    last run:          2024-03-16 09:14:22 ← the act itself

War Story. A real insider case turned on exactly this and one detail the suspect never imagined. He had wiped free space, cleared his browser history, emptied the Recycle Bin, and shut down satisfied. He did not know that the act of running the cleaner wrote a prefetch file with a run count and timestamp, that Amcache recorded the binary's SHA-1, that UserAssist tallied his GUI launch of it, or that the $I metadata of the files he "deleted" survived in the per-SID Recycle Bin folder. On the stand, the timeline was devastating not because it showed the theft — the access artifacts did that — but because it showed the cover-up, minute by minute, in his own account's name. The jury did not need to understand CAD files. They understood that he tried to erase it.

Tool Tip. When you find one cleaner, look for the others. People who run CCleaner often also run Eraser, BleachBit, or sdelete, and Task Scheduler frequently holds a recurring secure-delete job that runs unattended — itself an artifact with a creation time and an author SID. Check C:\Windows\System32\Tasks\, the SOFTWARE Uninstall keys, the Prefetch directory, and Amcache for the full inventory of anti-forensic tooling before you write your report. The set of tools present is itself characterizing evidence.

Timestomping: forging the clock

If wiping attacks the data, timestomping attacks the timeline — the examiner's most powerful analytical structure. The goal is to alter file timestamps so that an investigator who orders events chronologically builds a false story: a file copied last Friday is made to look two years old, a tool dropped during an intrusion is given the timestamps of a legitimate system file so it blends in. Timestomping is the single most common trail-obfuscation technique, and, fortunately, one of the most reliably detectable — because of how NTFS stores time.

Two clocks, one of them honest

As Chapter 4 established, every file on NTFS carries two independent sets of timestamps in its MFT record:

  • $STANDARD_INFORMATION` (`$SI, attribute type 0x10) holds four FILETIMEs — Modified, Accessed, C (MFT-entry-modified/metadata-change), Born (created): the "MACB" set. Crucially, $SI is settable through normal Windows APIs (SetFileTime, NtSetInformationFile). This is the set Explorer displays, and the set every timestomping tool writes.
  • $FILE_NAME` (`$FN, attribute type 0x30) holds its own four MACB FILETIMEs. $FN is maintained by the kernel when the file name/MFT record is created and updated on rename or move; it is not exposed to the ordinary user-mode API. Explorer never shows it; most users do not know it exists.

That asymmetry is the gift. A user with a timestomping utility can rewrite $SI` trivially, but `$FN keeps the kernel's record. When $SI` and `$FN disagree in impossible ways, you are almost certainly looking at manipulation.

MFT RECORD — the two timestamp sets (FILE record, signature "FILE" = 46 49 4C 45)
┌────────────────────────────────────────────────────────────────────────┐
│ $STANDARD_INFORMATION (type 0x10)   ← USER-SETTABLE (Explorer shows this)│
│    M  Modified      A  Accessed     C  MFT-modified   B  Born(created)   │
├────────────────────────────────────────────────────────────────────────┤
│ $FILE_NAME (type 0x30)              ← KERNEL-SET (hidden from the API)   │
│    M  Modified      A  Accessed     C  MFT-modified   B  Born(created)   │
├────────────────────────────────────────────────────────────────────────┤
│ $DATA (type 0x80)   ...the file content...                              │
└────────────────────────────────────────────────────────────────────────┘
Timestomp tools rewrite the TOP set. The BOTTOM set usually keeps the truth.

Detection method 1 — $SI` vs `$FN comparison

The foundational check: extract both timestamp sets and compare. Two contradictions are diagnostic:

  1. $SI` older than `$FN. A file cannot have been created ($SI` Born) before its name record was *born* (`$FN Born). If $SI` Created reads 2022 while `$FN Created reads 2024, the 2022 value was forged. This is the anchor's exact signature:
TIMESTAMP CONTRADICTION — TurbineHousing_v7.sldprt (jrivera's Desktop copy)
                     Created (Born)        Modified
$STANDARD_INFO :  2022-02-11 10:00:00   2022-02-11 10:00:00   ← Explorer shows this (FORGED)
$FILE_NAME     :  2024-03-15 18:58:13   2024-03-15 18:58:13   ← kernel-set (TRUTH)
                  ^ a file cannot be born in 2022 if its name record was born in 2024
                  ^ and 2024-03-15 18:58 matches USB last-arrival + the Jump List access
  1. $SI` Modified earlier than `$SI Born within the same set. A file modified before it was created is logically impossible; some clumsy tools produce exactly this when an operator sets fields independently.

The istat output from The Sleuth Kit shows both sets side by side — here for the anchor file (MFT record 84120, illustrative):

istat -o 2048 WS-ENG-04.E01 84120

$STANDARD_INFORMATION Attribute Values:
  Created:        2022-02-11 10:00:00.0000000   ← forged (note .0000000 sub-second)
  File Modified:  2022-02-11 10:00:00.0000000   ← forged
  MFT Modified:   2024-03-16 09:13:58.6042217   ← REAL: the moment the stomp itself ran
  Accessed:       2022-02-11 10:00:00.0000000   ← forged

$FILE_NAME Attribute Values:
  Created:        2024-03-15 18:58:13.4471902   ← truth (real sub-second precision)
  File Modified:  2024-03-15 18:58:13.4471902
  MFT Modified:   2024-03-15 18:58:13.4471902
  Accessed:       2024-03-15 18:58:13.4471902

Notice a bonus tell in that output: the $SI` **MFT-Modified** time reads `2024-03-16 09:13:58` even though the other three `$SI fields were forged to 2022. Many timestomping tools rewrite Created/Modified/Accessed but cannot prevent the act of writing those values from updating the entry's metadata-change time — so the $SI "C" field often leaks the real time the stomp occurred. Here it lands one minute before the CCleaner run: the suspect backdated the file and then wiped, in the same ten-minute spree.

Detection method 2 — sub-second precision patterns

Genuine FILETIMEs carry sub-second precision down to 100-nanosecond ticks; in practice the low-order digits are effectively random. Many timestomping tools — notably the classic Metasploit timestomp — set times only to whole-second granularity and zero the sub-second fraction. So a forged timestamp reads ...10:00:00.0000000 while real timestamps on the same volume read ...18:58:13.4471902. When $SI` sub-seconds are all zeros and `$FN (or neighboring files') sub-seconds are not, that pattern alone is a strong manipulation indicator — visible in the istat output above.

Detection method 3 — MFT sequence anomalies

MFT records are allocated sequentially: as files are created, they take the next available record number, so record numbers correlate with creation order. A file claiming a 2022 birth date but sitting at a high MFT record number, surrounded by records for files genuinely created in 2024, is anomalous — its neighbors prove when it was really born. The same logic applies to USN journal sequence numbers and $LogFile LSNs (log sequence numbers): the file's change records sit among 2024 entries, not 2022 ones.

Detection method 4 — the change journal never forgets

NTFS maintains a change journal, $Extend\$UsnJrnl:$J`, that records every file change — create, rename, data-overwrite, delete — with a reason flag and a *reliable, kernel-stamped timestamp.* Timestomping rewrites the file's MFT timestamps but does not (and generally cannot, through the normal API) rewrite the historical USN records. So the journal holds a `FILE_CREATE` record for `TurbineHousing_v7.sldprt` stamped 2024-03-15 18:58, flatly contradicting the forged 2022 `$SI. The $LogFile (NTFS transaction log) similarly retains recent metadata operations. Parse the journal with MFTECmd:

MFTECmd.exe -f "$J" --csv .\out     ← USN journal: reason flags + reliable timestamps

UpdateTimestamp        Name                          UpdateReasons
2024-03-15 18:58:13    TurbineHousing_v7.sldprt      FileCreate
2024-03-15 18:58:13    TurbineHousing_v7.sldprt      DataExtend|Close
2024-03-16 09:12:41    TurbineHousing_v7.sldprt      RenameOldName       ← into Recycle Bin
2024-03-16 09:13:58    TurbineHousing_v7.sldprt      BasicInfoChange     ← the timestomp itself

That BasicInfoChange record at 09:13:58 is the timestomp event, stamped by the kernel at the real moment it happened.

Detection method 5 — independent corroborating clocks

Finally, timestomping changes one file's MFT timestamps; it does not touch the dozen other artifacts that independently recorded the file's life. The LNK file and Jump List entry (Chapter 16) carry the access time 2024-03-15 19:04 and the volume serial of the source device. Prefetch carries the application's run times. Event logs carry logon and device-connect times. The registry MountPoints2 last-write carries the mount time. Every one of these is a separate clock the suspect did not know to forge, and all of them place the activity in March 2024, not February 2022. When one timestamp contradicts ten, the one is the lie.

Limitation. $FN` is far harder to forge than `$SI, but it is not absolutely immune. Advanced tools (for example, SetMACE) can manipulate $FN` by exploiting move/rename semantics or by direct MFT editing, and a determined adversary with kernel-level access can do more. So do not rest a conclusion on `$SI vs $FN` alone when the stakes are high — corroborate with the USN journal, `$LogFile, and the independent artifact clocks above. The full mechanics of MACB timestamps, timeline construction, and timestomping detection live in Chapter 21 — Timeline Analysis; the NTFS attribute structures behind $SI` and `$FN are defined in Chapter 4 — File Systems and tabulated in Appendix G — File System Reference.

Log wiping and tampering

Event logs are the system's signed statements about what happened, and they are a natural target for anyone trying to erase a trail. There are two broad attacks — clearing an entire log, and surgically deleting individual records — and each has its own detection signature.

Clearing a whole log

Clearing a log is the blunt approach: wevtutil cl Security, PowerShell's Clear-EventLog, or the "Clear Log" button in Event Viewer. The blunt approach defeats itself immediately, because Windows logs the clearing:

  • Clearing the Security log writes event 1102 ("The audit log was cleared"), recording the SID and account name of who cleared it and the time.
  • Clearing any other log writes event 104 ("The event log file was cleared") to the System log.

So the first thing you do with a suspiciously short log is look for 1102 and 104. Finding one tells you the log was cleared, by whom, and when — turning the destruction into a dated, attributed event. Finding the absence of expected events plus a 1102 is conclusive.

But even a full clear leaves structural tells beyond the 1102/104 event:

  • A "clean start." After a clear, the log begins fresh; its earliest record's timestamp equals the clear time, and there is a conspicuous gap before it on a machine that was demonstrably running (boot/shutdown events in the System log, prefetch, registry last-writes all prove the machine was up during the missing window). A Security log whose oldest entry is "this morning" on a workstation that has run for months is anomalous on its face.
  • Cross-log contradiction. Logons recorded in one log have no counterpart where you would expect them; a service start appears with no corresponding stop; the System log shows boots that the Security log does not span.

Surgical record deletion and the EventRecordID gap

The subtler attack edits the .evtx file to remove individual records — say, the specific 4624 logons that would reveal an intruder's sessions — while leaving the rest intact, so no 1102 fires. This is harder, and it leaves a precise fingerprint, because of how .evtx is structured. Recall the format from Chapter 16: the file begins with the signature ElfFile\0 (45 6C 66 46 69 6C 65 00), is divided into 64-KiB chunks marked ElfChnk\0 (45 6C 66 43 68 6E 6B 00), and each record begins with 2A 2A 00 00 and carries a monotonically increasing 8-byte EventRecordID.

Two integrity checks expose surgical deletion:

  1. EventRecordID gaps. The IDs increment by exactly one. If records are removed, the surviving IDs skip — ...184413, [184414–184902 missing], 184903... — and that gap is unexplained by any legitimate operation.
  2. Chunk header mismatches. Each chunk header stores its FirstEventRecordNumber, LastEventRecordNumber, a record count, and CRC32 checksums over the chunk and header. Deleting records without recomputing these (which crude tools do not) leaves the stored counts and checksums inconsistent with the actual chunk contents — a verifiable corruption.
EVENTRECORDID GAP — Security.evtx (records sorted by ID)
... 184411   184412   184413   ┊   184903   184904   184905 ...
                               ┊
                    489 IDs (184414–184902) absent between two adjacent on-disk records
   chunk header LastEventRecordNumber / record count / CRC32 do not reconcile
   → surgical deletion, NOT a normal clear (no 1102 present)

You can also carve deleted event records from the log's own free space, from unallocated clusters, and from memory: each record still begins with 2A 2A 00 00, so a record removed from the active log may persist as a carvable fragment elsewhere. And a live-response memory capture (see Chapter 22 — Memory Forensics) often holds buffered event records the Event Log service had not yet, or had just, written.

Linux and the binary-log traps

The same logic applies on Linux, with different files (Chapter 17's domain):

  • /var/log/ text logs (auth.log, syslog, secure, messages) get truncated, shred-ded, or edited. Detect via rotation/sequence gaps, mismatched inode times, and the same "the machine was clearly up but the log is silent" reasoning.
  • wtmp/utmp/btmp (binary login records) are edited to remove a session. They are not human-readable; parse with utmpdump and look for zeroed or structurally broken entries among intact ones.
  • ~/.bash_history is the classic target: history -c, unset HISTFILE, export HISTSIZE=0, or symlinking the history file to /dev/null. An active account with an empty or missing history, or a ~/.bash_history -> /dev/null symlink, is itself the finding.
  • systemd journald stores a binary journal with internal sequence numbers; journalctl --verify checks integrity, and if Forward Secure Sealing (FSS) was enabled, tampering after the fact is cryptographically detectable.

Why This Matters. Across every platform the pattern is identical and it is theme #3 again: you cannot delete the record of deletion without leaving a record of deletion. A cleared log announces itself (1102/104); a surgically edited log breaks its own sequence and checksums; a wiped history leaves an empty file with a recent timestamp on a busy account. The log tamperer is trying to subtract from a system designed to add, and subtraction leaves a hole the exact shape of what was removed.

Data hiding: keeping the data but burying it

Not every adversary wants to destroy data — sometimes they want to keep it, but where you won't look. NTFS in particular offers two famous hiding places, and the broader storage stack offers several more.

NTFS alternate data streams (ADS)

NTFS files are not single blobs of content; each file can carry multiple $DATA` attributes**. The default, unnamed `$DATA stream is "the file" as you know it. But you can attach named** streams — report.docx:hidden — and these named streams are invisible to dir, to Explorer (which reports only the unnamed stream's size), and to most tools. An executable, an archive, or a document can ride along inside another file's alternate stream, the host file looking entirely ordinary.

Mechanically, the MFT record simply contains a second $DATA (type 0x80) attribute whose name length is non-zero:

MFT record for report.docx — TWO $DATA attributes
Attr  Type   Name        Meaning
$10   0x10   —           $STANDARD_INFORMATION
$30   0x30   report.docx $FILE_NAME
$80   0x80   —           $DATA  (unnamed) → the visible 18 KB document
$80   0x80   hidden      $DATA  (NAMED)   → report.docx:hidden  ← invisible to dir/Explorer

Named $DATA attribute header (excerpt):
80 00 00 00  ...  01  ...  06 00  ...      type=0x80, non-resident=01, name len=0x06
68 00 69 00 64 00 64 00 65 00 6E 00         "h.i.d.d.e.n."  (UTF-16LE)

Detection is, happily, trivial once you know to look:

# Enumerate alternate data streams (work on a mounted image, read-only)
Get-ChildItem -Path 'E:\evidence\C\Users\jrivera' -Recurse -File |
  ForEach-Object { Get-Item -LiteralPath $_.FullName -Stream * } |
  Where-Object { $_.Stream -ne ':$DATA' } |
  Select-Object FileName, Stream, Length

C:\> dir /r                       (the /r switch lists alternate data streams)
   18,432 report.docx
      612 report.docx:Zone.Identifier:$DATA      ← benign mark-of-the-web
1,144,320 report.docx:hidden:$DATA               ← anomalous: a 1.1 MB hidden payload

The Sysinternals streams.exe, The Sleuth Kit (fls lists named $DATA` as `file:stream`; `istat` enumerates the attributes), and every major forensic suite flag ADS automatically. One stream you will see constantly and must **not** cry wolf over is `:Zone.Identifier:$DATA — the "mark-of-the-web" that Windows attaches to downloaded files to record their security zone. It is ubiquitous and benign; in fact it is useful, because it tells you a file was downloaded and sometimes from where. The anomaly is a large, named, non-Zone.Identifier stream attached to an innocuous-looking document.

Recovery vs. Forensics. ADS serves both lenses. For the 🔍 examiner, a named stream is a hiding place to enumerate and extract as evidence. For the 💾 recovery technician, alternate streams can hold recoverable user data the client forgot existed (some applications legitimately stash thumbnails, metadata, or autosave content in streams), and a stream-aware copy is the only way to preserve them — a naive file copy drops every alternate stream silently, which is also a chain-of-custody hazard to avoid when handling evidence.

Slack space

As Chapter 2 established, file systems allocate storage in clusters, and a file rarely fills its last cluster exactly. The leftover — from the logical end of the file to the end of its last allocated cluster — is slack space, and it normally contains remnants of whatever previously occupied those sectors. Slack is therefore a recovery and forensic source (old data hides there by accident) and an anti-forensic destination (data can be hidden there on purpose, since the file system does not account for it and ordinary tools never read it).

CLUSTER SLACK (4 KiB cluster, 3,200-byte file)
┌──────────────────────────────┬───────────────────────────────────────────┐
│ file content (3,200 bytes)   │ SLACK (896 bytes) — old data or hidden data│
└──────────────────────────────┴───────────────────────────────────────────┘
 logical EOF ─────────────────►┘                          end of cluster ───►┘

Related hiding places include MFT slack (unused space in a resident-capable MFT record), $Boot slack, volume slack (between the file system's end and the partition's end), and partition slack (sectors not covered by any partition). Extract and examine slack with The Sleuth Kit:

# Extract only the slack space of a volume, then carve/strings it
blkls -s -o 2048 WS-ENG-04.E01 > slack.raw      # -s = slack only
strings -t d slack.raw | less                    # human-readable remnants
foremost -i slack.raw -o slack_carved/           # carve files hidden in slack

Cross-reference Chapter 7 — File Carving for carving the contents of slack, and Chapter 2 — How Data Is Stored for the cluster/sector model that makes slack exist.

Hidden areas of the physical disk: HPA and DCO

Two ATA features let a host hide sectors from the operating system entirely:

  • The Host Protected Area (HPA) reserves sectors at the end of the disk, set via SET MAX ADDRESS; the OS sees a smaller drive and never touches the hidden region.
  • The Device Configuration Overlay (DCO) reduces the reported capacity below even the HPA, hiding sectors that most tools never suspect exist.

A naive image that copies only the OS-visible LBAs misses anything stashed in an HPA/DCO. Detect and (temporarily) unlock them at acquisition time:

hdparm -N /dev/sdX          # native vs. accessible max sectors → HPA present if they differ
hdparm --dco-identify /dev/sdX   # report a Device Configuration Overlay

A proper hardware imager and many write-blockers detect and reveal HPA/DCO automatically, and you should compare the manufacturer's labeled capacity against the reported capacity as a sanity check. See Chapter 3 — Storage Technology and Chapter 14 — Forensic Acquisition for the acquisition workflow that captures these regions.

Hiding in plain sight: extension and signature mismatch

The laziest hiding technique is also common: rename secrets.zip to vacation.jpg so it does not draw the eye. It defeats nobody who runs signature analysis — comparing each file's content magic number against its claimed extension. A ".jpg" whose first bytes are 50 4B 03 04 is a ZIP archive, not an image. Autopsy's "Extension Mismatch Detected" module and the Unix file command do this automatically; the magic-number reference is Appendix A — File Signatures Reference.

file vacation.jpg
vacation.jpg: Zip archive data, at least v2.0 to extract     ← not a JPEG at all

Header bytes:
0x00  50 4B 03 04 14 00 ...    "PK.." → ZIP local file header (claimed ext: .jpg)

Try This. On a practice image (see Appendix J — Practice Images and Lab Setup), run a recursive ADS enumeration with Get-Item -Stream * and a signature-mismatch scan with file across a directory tree. Plant a named stream and a mis-extensioned archive yourself first, then prove your own detection catches them. The habit you are building is never trusting the file name — not its extension, not its size in Explorer, not its timestamps.

Data transformation: encryption and obfuscation as anti-forensics

Strong encryption is the most effective anti-forensic technique that exists, and Chapter 29 is devoted to it. Here we treat it only as it appears as concealment within an otherwise readable system — the encrypted container hiding among ordinary files — and we treat the tell that detects it even when you cannot open it: entropy.

Entropy as the tell

Shannon entropy measures the unpredictability of a byte stream in bits per byte, from 0.0 (perfectly uniform — a zero-wipe) to 8.0 (perfectly random). Ordinary content sits well below the ceiling: English text is around 4.0–4.5, executables around 6.0–6.5, already-compressed data (JPEG, ZIP, MP4) high but with recognizable structure and headers. Encrypted data approaches 8.0 with no structure, no header, and no carvable signature — by design, good ciphertext is indistinguishable from random noise. A high-entropy blob with no file signature, often a suspiciously round size, sitting where no such file should be, is a candidate encrypted container.

import math, sys

def shannon_entropy(block: bytes) -> float:
    if not block:
        return 0.0
    counts = [0] * 256
    for b in block:
        counts[b] += 1
    n = len(block)
    return -sum((c / n) * math.log2(c / n) for c in counts if c)   # 0.0 .. 8.0

# Slide a 64 KiB window across a raw image; flag wiped (~0) and encrypted/random (~8) regions.
WINDOW = 1 << 16
with open(sys.argv[1], "rb") as f:
    offset = 0
    while (chunk := f.read(WINDOW)):
        h = shannon_entropy(chunk)
        if h < 0.5:
            print(f"{offset:#018x}  entropy={h:0.2f}  ZEROED / WIPED")
        elif h > 7.97:
            print(f"{offset:#018x}  entropy={h:0.2f}  ENCRYPTED / COMPRESSED ?")
        offset += len(chunk)

The ambiguity to respect: high entropy alone cannot distinguish encrypted from random-wiped from compressed. Entropy is a lead, not a verdict. You disambiguate with the application artifacts: a VeraCrypt or TrueCrypt blob is corroborated by the VeraCrypt program being installed (registry, prefetch, Amcache), by a "recently mounted volumes" MRU in the registry, by mounted-volume traces, and by keys or headers recoverable from memory, pagefile, or hibernation (Chapter 22, Chapter 29).

VeraCrypt and TrueCrypt support a hidden volume: a second encrypted volume concealed within the free space of an outer volume, so that the outer volume's free space and an unused hidden volume are cryptographically indistinguishable. This is plausible deniability by design — and it means you genuinely cannot prove a hidden volume exists from the disk image alone. You can show that a container exists, that its size leaves room for one, and that the application capable of creating one was used; you cannot, from entropy, demonstrate the hidden volume is there.

Legal Note. Compelling a suspect to disclose a password or decryption key collides with the Fifth Amendment's protection against self-incrimination in the United States (and with key-disclosure statutes elsewhere, such as the UK's RIPA Part III, which criminalizes refusal). Whether a custodian can be ordered to produce a key is an unsettled, jurisdiction-dependent question turning on the "foregone conclusion" doctrine. This is decided by counsel and the court, never improvised at the keyboard. Your job is to document what the artifacts show — that a container exists and that the tool was used — and to leave the legal compulsion question to Chapter 25 — The Legal Framework. Full encrypted-device technique is in Chapter 29 — Encrypted Device Forensics.

Steganography

Steganography hides data inside an innocuous carrier — typically least-significant-bit (LSB) embedding in the pixels of a lossless image (BMP, PNG) or samples of audio, or DCT-coefficient embedding in JPEGs (as F5, JSteg, and OutGuess do). The carrier looks and opens like a normal photo; the payload rides in statistical noise. Steganography is the hardest anti-forensic technique to defeat head-on, and honesty about that limit matters.

Steganalysis — statistical detection — exists: the chi-square attack and RS analysis detect the statistical fingerprints that LSB embedding leaves, and tools such as StegExpose, zsteg (PNG/BMP), stegdetect (JSteg/JPHide/OutGuess), and ML-based Aletheia automate it. But low-payload, passphrase-protected, well-implemented steganography can be statistically undetectable. In practice, you far more often catch steganography by its surroundings than by cracking the carrier:

  • the steganography tool installed (prefetch, Amcache, registry) — why is OpenStego or Steghide on a sales manager's laptop?
  • candidate carriers — a folder of large, oddly uniform images, or images whose size is anomalous for their visible content;
  • a pristine original to compare — if you have the un-modified source image (from a camera, a website, a backup), a hash mismatch or pixel diff against the suspect copy is decisive;
  • a passphrase or payload artifact recovered elsewhere (notes, password managers, memory).
zsteg suspicious.png
b1,rgb,lsb,xy   .. text: "BEGIN PGP MESSAGE ..."   ← LSB plane carries hidden text

Limitation. Detecting steganography is probabilistic, and extracting the payload usually requires the embedding tool and the passphrase. "I detected a high likelihood of LSB steganography in these files but could not extract the payload without the passphrase" is a complete and professional finding. Do not overstate statistical steganalysis as certainty, and do not claim a payload you cannot produce.

Counter-attribution: Tor, VPNs, and their endpoint traces

The last family hides not the data but the person — who did it and from where. Anonymity tools are designed to leave few traces on the wire and, for the better ones, few on disk. "Few" is not "none," and the traces they do leave are precisely what the examiner harvests.

Tor

The Tor Browser is built to minimize disk artifacts: it runs largely from a self-contained folder, disables history and disk caching, and routes traffic through a multi-hop encrypted circuit so that no single relay knows both source and destination. Even so, use of Tor is detectable on a dead-box image:

  • The Tor Browser folder and installer — the Tor Browser directory itself (often in Downloads or on the Desktop), and the downloaded installer .exe, with its :Zone.Identifier ADS recording the download.
  • Execution artifacts — Prefetch entries for firefox.exe/tor.exe run from the Tor Browser path (the path hash in the .pf filename betrays the unusual location), plus UserAssist, BAM, and a Start-Menu/Desktop LNK.
  • Tor's own state files — under ...\Tor Browser\Browser\TorBrowser\Data\Tor\: the state file (records last-run time and the persistent guard relays), torrc/torrc-defaults (configuration, bridges), and the cached-certs/cached-microdescs/cached-microdesc-consensus files (the relay consensus, with last-modified times proving when Tor last ran).
  • Browser and registry breadcrumbs — history of visiting torproject.org to download the bundle (in the default browser, before Tor was used), and registry MRUs/OpenSavePidlMRU for the download.
  • Memory — while Tor runs, RAM holds .onion addresses, circuit information, keys, and the local SOCKS proxy port (9150); a live capture (Chapter 22) is often the richest Tor evidence you will get.
Tor on-disk tells (dead-box)
Prefetch\FIREFOX.EXE-XXXXXXXX.pf      ← run from \Tor Browser\... (anomalous path hash)
...\TorBrowser\Data\Tor\state         ← last-run time + guard nodes
...\TorBrowser\Data\Tor\cached-certs  ← consensus last-modified ≈ last Tor use
Downloads\tor-browser-windows-*.exe   ← installer + :Zone.Identifier (where downloaded)

On the network side (Chapter 23), an enterprise or ISP cannot read Tor content but can see TLS connections to known Tor guard/entry relays (the public relay list) or to bridges, with a distinguishable handshake. The use is observable even when the content is not.

VPNs

A VPN client is heavier and leaves more on disk than Tor:

  • The installed client — Program Files, an Uninstall registry key, prefetch, Amcache;
  • Configuration — .ovpn/.conf profiles naming the server, embedded or referenced certificates/credentials, and connection logs (e.g., under %ProgramData%\<vendor>\log\) that frequently record connect/disconnect times and the assigned IP;
  • The virtual network adapter — a TAP-Windows or WireGuard adapter registered under SYSTEM\CurrentControlSet\Enum\... and in the network configuration, persisting even when disconnected;
  • Autostart — many VPNs launch at boot (a Run key or service);
  • Network — a tunnel to the VPN endpoint IP on a characteristic port (OpenVPN 1194/udp, WireGuard 51820/udp, IKEv2 500/4500).

Recovery vs. Forensics. Anonymity-tool artifacts are almost purely a 🔍/🛡️ concern, but the reframe is the lesson for everyone: with Tor and VPNs you will rarely recover content, yet the fact of use, the times of use, and the destinations contacted are themselves artifacts — and timing correlation (this VPN connected at 02:14; this internal file was accessed at 02:15; this cloud upload completed at 02:18) can rebuild a story the encryption was meant to hide. You investigate the edges of the encrypted tunnel, not its inside.

Limitation. The disciplined adversary defeats dead-box analysis here. A user who boots Tails (or another amnesic live OS) from USB, runs everything in RAM, routes through Tor, and writes nothing to the internal disk leaves essentially no host artifacts — and powering the machine off erases the memory that held the only evidence. Against that posture your leverage shifts entirely to network capture (if you had it running) and live memory acquisition (if you reached the machine while powered on). If you arrive after shutdown, the honest finding may be that the internal disk contains no evidence of the activity — which loops us to the deepest idea in this chapter.

The meta-method: the absence of an expected artifact is a finding

Every technique above converges on a single, powerful mode of reasoning, and it is worth isolating because it is what separates a senior examiner from a tool operator. A normally-used system has an expected baseline of artifacts. When that baseline is conspicuously missing, the absence is itself evidence.

A Windows workstation in daily use for months will have: browser history spanning that period; hundreds of prefetch files; populated MRU lists; a continuous event-log timeline; $Recycle.Bin entries; Volume Shadow Copies / restore points; LNK files and jump lists. When you image such a machine and find an empty Prefetch folder, MRU lists that are empty but freshly time-stamped, a browser history that begins yesterday, an event log whose earliest entry is this morning (with a 1102 to explain it, or worse, without one), and vast contiguous regions of zeros in unallocated space, you are not looking at a clean machine — you are looking at a cleaned one. The shape of the hole matches the shape of what was removed, and often the hole is dated.

This is "negative evidence," and it is admissible and persuasive when handled rigorously — but it demands discipline, because absence has innocent explanations:

ABSENCE — competing hypotheses you MUST address before concluding "anti-forensics"
Observation                        Anti-forensic cause        Innocent cause(s)
Empty Prefetch                     wiped                       Prefetch disabled (servers/SSD); fresh install
No deleted-file remnants (SSD)     secure-wiped                TRIM (normal SSD behavior — Ch.9)
Short event log                    cleared (look for 1102)     small max log size; recent reimage
Sparse browser history             cleared                     privacy mode; new browser; new profile
Many zeroed clusters               free-space wipe             new/repurposed disk; sparse files
Empty $Recycle.Bin                 emptied                     "delete permanently" habit; group policy

The professional posture: treat anti-forensic activity as a hypothesis you test, not a conclusion you assume. The empty Prefetch folder is a lead. You confirm it by checking whether EnablePrefetcher was actually on (registry), whether the machine is the kind that disables it, whether the timing of the emptiness aligns with other suspicious events, and whether a wiping tool's own artifacts are present. When the corroboration converges — empty-but-dated MRUs at 09:14, a cleaner's prefetch at 09:14, a free-space wipe, a $SI`/`$FN contradiction, a $I deletion at 09:12 — the absence becomes a finding you can defend. When it does not converge, the honest report says "consistent with, but not conclusive of, deliberate wiping; innocent explanation X cannot be excluded." Both are professional outcomes; an overstated one is not.

Why This Matters. This is the chapter's thesis and one of the book's six themes in its sharpest form: every action leaves a trace, and the absence of a trace is itself a trace. The examiner who only knows how to read present artifacts can be defeated by deletion. The examiner who also reads absence — who knows what should be there and notices what is missing, dates the hole, and corroborates — cannot be defeated by deletion alone, because deletion is an action, and actions leave traces, including the shaped void where the data used to be.

Tool demonstration: an anti-forensics detection pass

There is no single "anti-forensics tool"; detection is a pass you run with the tools you already know, asking the concealment questions explicitly. A repeatable workflow against your verified image:

ANTI-FORENSICS DETECTION PASS
1. WIPING        entropy scan (zeroed/random regions) ─ Python window scan / Autopsy
                 surviving ZZZ-pattern deleted MFT entries ─ MFTECmd / fls
                 wiping-tool artifacts ─ PECmd, AmcacheParser, RECmd (Piriform/Eraser keys)
2. TIMESTOMPING  $SI vs $FN ─ istat / MFTECmd ; sub-second zeros ; USN $J ─ MFTECmd
3. LOG TAMPERING 1102/104 ─ EvtxECmd ; EventRecordID gaps ; chunk CRC ; carve **\0\0
4. HIDING        ADS ─ Get-Item -Stream * / dir /r / streams / fls
                 slack ─ blkls -s | strings | foremost
                 HPA/DCO ─ hdparm -N / --dco-identify (at acquisition)
                 signature mismatch ─ file / Autopsy Extension Mismatch
5. ENCRYPTION    entropy blobs + container-app artifacts (VeraCrypt key/MRU)
6. ATTRIBUTION   Tor/VPN install + state files + memory + network correlation

The $SI`/`$FN check and USN parse with MFTECmd:

MFTECmd.exe -f "$MFT" --csv .\out        ← exports BOTH $SI and $FN MACB columns
   → filter where SI_Created < FN_Created  (impossible: forged)
   → filter where SI sub-seconds == .0000000 but FN sub-seconds != 0  (tool tell)
MFTECmd.exe -f "$J" --csv .\out          ← USN journal: kernel-stamped change times

ADS and signature checks at the shell:

fls -o 2048 -r WS-ENG-04.E01 | grep ':'        # named $DATA streams appear as file:stream
icat -o 2048 WS-ENG-04.E01 84120-128-5 | file -    # pull a stream, identify its true type

Event-log integrity with EvtxECmd, then inspect for the three tells — any 1102/104, EventRecordID gaps, and an anomalously recent earliest record:

EvtxECmd.exe -f "Security.evtx" --csv .\out
  → search EventId == 1102  (log cleared: who + when)
  → sort by EventRecordId, find non-monotonic gaps
  → check earliest TimeCreated against System-log boot history (was the box up earlier?)

For an integrated view, Autopsy ships ingest modules that automate much of this pass: an Encryption Detection module (entropy-based), an Extension Mismatch Detected module (signature analysis), Interesting-Files rules you can point at wiping-tool names, and ADS surfacing in the file tree. Run them as a fast first sweep, then confirm load-bearing findings with the CLI tools above — and, as always, corroborate any conclusion with at least two independent tools (a Daubert expectation; see Chapter 27 — Expert Testimony). The reusable Python helpers (the entropy scanner, an $SI`/`$FN comparator) live in Appendix B — Python Forensics Toolkit; the full tool landscape is Chapter 36 — The Forensic Toolkit and Appendix C — Tool Reference.

Chain of Custody. Every command in this pass runs against a verified working copy, never the original (theme #2 — the original is sacred). Extract artifacts from the hashed image, hash each extracted file, and log the source: "Parsed $MFT` extracted from `WS-ENG-04.E01` (SHA-256 `a3f1…`), working-copy MD5 `b9c2…`, with `MFTECmd v1.x`; corroborated `$SI/$FN contradiction on record 84120 with istat (TSK 4.x)." A detection finding is only as defensible as the custody behind the bytes that produced it. Templates are in Appendix F.

Worked example: detecting the cover-up in anchor case #2

Chapter 16 used WS-ENG-04 to show how the theft surfaces. Here we use the same image to show how each act of concealment is detected — the anti-forensics pass, applied. Counsel already has the access evidence; what makes the case formidable is proving the suspect tried to bury it.

Concealment act 1 — backdating the local copies (timestomping). Explorer shows C:\Users\jrivera\Desktop\TurbineHousing_v7.sldprt with a Modified date of February 2022 — implausibly old for a current design. The $SI`/`$FN comparison (method 1) exposes it instantly: $FN` Created reads `2024-03-15 18:58:13` with genuine sub-second precision, while `$SI reads 2022-02-11 10:00:00.0000000 — zeroed sub-seconds (method 2) and a birth date predating its own name record, which is impossible. The $SI MFT-Modified field leaks the real stomp time, 2024-03-16 09:13:58, and the USN journal (method 4) holds a BasicInfoChange record at that same instant. Five independent confirmations; the 2022 date is a forgery.

Concealment act 2 — wiping with CCleaner. The three-step corroboration from earlier: SOFTWARE\Piriform\CCleaner present with "wipe free space" on; CCLEANER64.EXE-A1B2C3D4.pf showing run count 3, last run Saturday 09:14:22; UserAssist and Amcache binding the run to jrivera. The free-space wipe shows up directly in the entropy scan as a vast contiguous low-entropy (zeroed) region of unallocated space, plus a freshly deleted MFT entry for the temp file the wipe created.

Concealment act 3 — emptying the Recycle Bin (defeated by surviving metadata). Two $I` records under `$Recycle.Bin\<jrivera-SID>\ survived, recording TurbineHousing_v7.sldprt and a sibling deleted Saturday 09:12 — original path, size, and deletion time intact even though the $R content is gone.

Concealment act 4 — the dated gaps (absence as evidence). Browser history ends clean at Saturday 09:14; multiple MRU keys are empty but carry a 09:14 last-write; the holes are dated to the same minute as the cleaner's execution. Tested against innocent hypotheses — Prefetch was enabled (registry confirms), the machine had run for months (System-log boots prove it), the timing aligns precisely with the tool run — the absences corroborate rather than mislead.

Assembled, the concealment timeline overlays the theft timeline exactly:

WS-ENG-04 — CONCEALMENT TIMELINE (UTC), user jrivera
Fri 18:58  TurbineHousing_v7.sldprt created on Desktop   [$FN truth; $SI later forged to 2022]
Sat 09:12  File + sibling sent to Recycle Bin            [$I metadata survived emptying]
Sat 09:13:58  Timestomp applied to local copy            [$SI MFT-Modified + USN BasicInfoChange]
Sat 09:14:22  CCleaner run #3, "wipe free space" on      [Prefetch/UserAssist/Amcache]
Sat 09:14   Browser history cut; MRUs emptied-but-dated  [absence = dated trace]
Sat 09:14   Free space zeroed                            [entropy scan: contiguous low-entropy]
CONCLUSION: every concealment act is dated, attributed, and corroborated.
            The cover-up did not hide the theft — it documented itself.

Every line is sourced to an artifact, every artifact comes from the hashed image, and the concealment acts cluster into a ten-minute Saturday-morning window in jrivera's account. The suspect's attempts to wipe, backdate, and empty did not weaken the case; they added an entire second case — spoliation — on top of the first.

Ethics Note. Findings of concealment are grave, and the sixth theme governs how you state them. "The local copy's $STANDARD_INFORMATION` timestamps were altered to 2022-02-11; the kernel-maintained `$FILE_NAME timestamps, the USN journal, and three independent artifacts place the file's creation at 2024-03-15 18:58" is a finding. "He timestomped the file to cover his tracks because he knew he was stealing" imputes a state of mind you cannot read from an MFT record and must not assert. Report the manipulation; let the trier of fact infer intent. Keep findings and inferences rigorously separate, as Chapter 26 — The Forensic Report requires.

Common mistakes

  • Mistaking normal behavior for anti-forensics. TRIM on an SSD zeroes deleted blocks automatically; privacy-mode browsing leaves no history; group policy can disable Prefetch and force permanent deletion; a freshly reimaged machine has a short log. Each of these mimics wiping or clearing. Always test innocent hypotheses before alleging deliberate concealment, and say which you excluded and how.
  • Reading a single timestamp set as truth. Explorer shows $SI`, which any user can forge. Never anchor a timeline on `$SI alone when it matters; compare $FN`, the USN journal, `$LogFile, and the independent artifact clocks. The contradiction is the evidence.
  • Believing the multi-pass wiping mythology — in either direction. Telling a client a single-pass-wiped file is recoverable "by a good lab" is false and cruel; insisting a suspect "must have" used a 35-pass Gutmann wipe to be thorough is equally naive. A single overwrite destroys data on modern drives; recognize it and move on.
  • Treating high entropy as proof of encryption. Random-wiped space, compressed data, and ciphertext all approach 8.0 bits/byte. Entropy locates candidates; the container application's artifacts (or a recoverable header/key) confirm encryption.
  • Copying evidence with stream-blind tools. A naive file copy silently drops alternate data streams — losing hidden payloads and breaking custody of the originals. Use stream-aware, forensically sound acquisition, and enumerate streams explicitly.
  • Forgetting the absence. Examiners trained only to read present artifacts get defeated by deletion. Build the habit of asking "what should be here that isn't?" — empty-but-dated MRUs, a browser history that begins too recently, a Prefetch folder too sparse for the machine's age.
  • Overstating a steganalysis or wiping result. "Likely LSB steganography, payload not extractable without passphrase" and "consistent with, but not conclusive of, deliberate wiping" are honest findings. Inflating them into certainties is how examinations fall apart on cross.
  • Imputing intent. "Timestomped" describes an action; "to cover his tracks" describes a mind. Report the action; leave the motive to the trier of fact.

Limitations: knowing when to stop

Anti-forensics detection is powerful, but theme #5 — know your limitations — applies with special force here, because the entire subject is an arms race and the determined, disciplined adversary can win.

The honest limits. A region overwritten even once on a modern drive is genuinely unrecoverable; detecting that it was wiped is often the only thing you can do, and "the data was destroyed and cannot be recovered" is the final, professional finding. A self-encrypting drive that was crypto-erased is gone in milliseconds, with no region to carve. Steganalysis is statistical, not certain — competent low-payload steganography can be undetectable, and even detected, the payload usually needs the embedding tool and a passphrase to extract. A VeraCrypt hidden volume cannot be proven to exist from the disk image; plausible deniability is real. The disciplined operator of an amnesic live OS (Tails) over Tor, writing nothing to the internal disk and powering off afterward, can leave a dead-box image with essentially nothing — at which point your only leverage is network capture or live memory you may not have.

And the subtlest limit: the absence of an expected artifact has innocent explanations, and you must never let "I cannot rule out wiping" harden into "they wiped it." Negative evidence is admissible and persuasive only when corroborated and when alternatives are addressed. When corroboration converges — dated holes aligned with a wiping tool's own execution — you have a defensible finding. When it does not, the professional answer is the one this book returns to again and again: "the available evidence is insufficient to determine whether deliberate concealment occurred." That sentence has ended fewer careers than the confident conclusion the data could not support. Know what your detection can carry, state its limits as plainly as its findings, and stop there.

Progressive project: detect anti-forensic activity in your case

Continue building your Forensic Case File. You have acquired and verified the image (Chapters 5, 14–15), recovered deleted files, examined metadata and Windows/OS artifacts (Chapter 16–17), and begun a timeline (Chapter 21 will consolidate it). This chapter you run a dedicated anti-forensics detection pass and add its results — including any negative findings — to the file:

  1. Hunt for wiping. Run an entropy scan across your image (the Appendix B scanner or Autopsy's Encryption Detection module) and flag contiguous zeroed and random regions. Search the $MFT for deleted entries with junk-pattern names and zeroed data runs. Inventory wiping-tool artifacts: Prefetch, Amcache, and registry keys (Piriform\CCleaner, Eraser, BleachBit, SDelete EULA key) — and check Task Scheduler for recurring secure-delete jobs.
  2. Hunt for timestomping. Export $SI` and `$FN MACB sets with MFTECmd and filter for $SI` Created earlier than `$FN Created, and for $SI` sub-seconds of `.0000000` against non-zero `$FN. Confirm any hit against the USN journal ($J) and at least one independent clock (prefetch, LNK, event log).
  3. Hunt for log tampering. Run EvtxECmd and search for events 1102 and 104; sort by EventRecordID and look for gaps; compare each log's earliest timestamp against System-log boot history.
  4. Hunt for hidden data. Enumerate alternate data streams (Get-Item -Stream * / dir /r / fls), extract and strings/carve slack (blkls -s), run a signature-mismatch scan (file / Autopsy), and note any high-entropy blobs that suggest encrypted containers (plus the container app's artifacts).
  5. Reason from absence — carefully. For every conspicuous absence (sparse Prefetch, empty-but-dated MRUs, a too-recent browser history, zeroed free space), write both the anti-forensic hypothesis and the innocent alternative, and state which the corroborating evidence supports. Mark findings you can defend versus leads you cannot yet confirm.
  6. Write it up with limits intact. Add an "Anti-Forensic Indicators" section to your case file: each indicator, the artifact and tool behind it, the timestamp, and an explicit limitation where one applies. Flag the spoliation implications for counsel.

Save the outputs and your indicators table into the case-file folder. The capstone, Chapter 38 — The Capstone Investigation, folds this pass into the complete report — and a case where the suspect attempted concealment is a stronger case, provided you documented the attempts rigorously.

Summary

Anti-forensics is the craft of trying to defeat an examination, and this chapter taught you that the craft almost always fails against a thorough examiner — because the attempt to hide evidence is itself evidence. You learned the five families: data destruction, data hiding, data transformation, trail obfuscation, and counter-attribution. You saw that secure wiping genuinely destroys data, that a single overwrite suffices on modern drives (the multi-pass DoD and Gutmann standards are obsolete folklore on current media), that SSDs require controller-level erase rather than software passes, and that even an unrecoverable wipe leaves detectable tells — anomalous zeroed/random regions, surviving junk-named MFT metadata, and, above all, the wiping tool's own Prefetch, Amcache, UserAssist, and registry artifacts. You watched anchor case #2's CCleaner convict itself: installed-and-configured, executed three times at 09:14 by jrivera, betrayed by the dated holes it left in MRUs, browser history, and the surviving $Recycle.Bin` `$I records. You learned to detect timestomping through the asymmetry of NTFS's two clocks — user-settable $SI` versus kernel-maintained `$FN — using $SI`/`$FN contradiction, zeroed sub-second fractions, MFT and USN sequence anomalies, the leaked $SI MFT-Modified stomp time, and independent corroborating artifacts. You learned to expose log tampering by the self-announcing 1102/104 clear events, EventRecordID gaps and chunk-CRC mismatches from surgical deletion, and the cross-platform truth that you cannot delete the record of deletion without leaving a deletion-shaped hole. You learned the hiding places — NTFS alternate data streams (enumerated in one dir /r), slack space, HPA/DCO, steganography (detectable statistically but often caught by its surroundings), and signature/extension mismatch — and how entropy flags encrypted containers you may not be able to open. You surveyed the endpoint traces of Tor and VPNs, where content hides but use does not. And you isolated the meta-method that ties it all together and forms the book's third theme: a normally-used system has an expected baseline of artifacts, and the conspicuous, dated absence of an expected artifact is itself a finding — provided you test it against innocent explanations and state its limits. Technology changes and tools evolve, but the method is constant: understand the concealment, image the evidence, detect systematically, corroborate across independent sources, and report each finding — and each limit — exactly as the data supports it.

You can now: - Recognize and classify the five families of anti-forensic technique, and explain why a single overwrite suffices on modern drives while SSDs need controller-level erase. - Detect secure wiping from entropy anomalies, surviving junk-named MFT metadata, and the wiping tool's own execution artifacts — and identify common tools (CCleaner, Eraser, BleachBit, SDelete) by the traces they leave. - Detect timestomping by $SI`/`$FN contradiction, zeroed sub-second patterns, MFT/USN sequence anomalies, and corroborating independent clocks. - Detect log clearing and surgical record deletion via 1102/104 events, EventRecordID gaps, and chunk-checksum mismatches, on Windows and the equivalents on Linux. - Find hidden data in alternate data streams, slack space, HPA/DCO, steganographic carriers, and mis-extensioned files, and flag encrypted containers by entropy plus application artifacts. - Reason from the absence of expected artifacts as an affirmative finding — while rigorously testing innocent explanations and stating every limitation.

What's next. Chapter 31 — Cloud Forensics — moves the investigation off the endpoint entirely, to data that lives on someone else's servers: where the artifacts you have learned to read are replaced by API logs, provider records, and legal process, and where the very location of the evidence becomes a jurisdictional question — proof, once more, that technology changes, principles don't.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.