What “Nothing Found” Actually Licenses You to Say

"Nothing found" is a statement about your method, your scope and your data — not about the world. It licenses you to say that no artifacts of a described kind were present in the data you examined, using the methods you used. Getting from there to "it did not happen" requires showing that the artifact the act would necessarily produce was enabled, retained and intact. On real systems you can rarely show all three, and the honest report says so.

What are the actual categories of anti-forensics?

Five, and they fail in different ways:

Destruction — overwriting or cryptographically erasing data so it cannot be recovered. Hiding — encryption, containers, steganography, and abuse of filesystem features. Artifact manipulation — timestomping, log clearing, editing records in place. Trail obfuscation — anonymisers, shared accounts, borrowed infrastructure. Tool attacks — malformed structures that crash or mislead a parser, and crafted collisions aimed at hash-based processes.

Only the first is often complete. The others usually leave the fact of the attempt, which is frequently more probative than what was hidden. Dan Farmer and Wietse Venema made the general argument in Forensic Discovery and it holds: acting on a system leaves traces of the acting.

What survives a wipe?

Distinguish the cases, because they are not close to each other.

Whole-device overwrite. On magnetic media, a single full overwrite renders the prior content unrecoverable in practice. NIST's guidance on media sanitization distinguishes Clear, Purge and Destroy and describes media-specific methods with their verification requirements — read the current revision, noting that Revision 2, published in 2025, supersedes Revision 1. The residue is not data; it is a drive whose entire surface carries a single uniform or patterned value, which is itself a finding: an entropy profile across the device that is inconsistent with normal use, with no filesystem, and no partition history.

Cryptographic erase — the mobile case. A modern iOS or Android "erase all content and settings" discards the key material protecting the data. This is not partial. Recovery is not a question of better tools, it is arithmetically foreclosed. The operational consequence is important and frequently misstated: recovering nothing from a reset phone is the expected result and on its own supports no inference of concealment whatsoever. Whether a reset occurred, and when, is often answerable from elsewhere — carrier records, cloud account activity, backup timestamps, an MDM or Find My log — and that is where the effort belongs.

Selective deletion and targeted wiping. This is the common case and the one that leaves the most. On NTFS, the $UsnJrnl change journal records file deletion events with names and parent references for days or weeks; $LogFile records the index changes for hours; MFT entries persist as unallocated records until reused. Beyond the filesystem, a deleted file's existence is recorded in a scattered set of places that do not get cleaned up together: shortcut and jump list entries, shell bags recording folder access, recent-document lists, application MRU keys, thumbnail caches, browser download history, and — on Windows client builds — prefetch files. Windows Registry Forensics and RegRipper cover the registry side; Eric Zimmerman's tools parse most of the rest.

Evidence of the wiping tool itself. Uninstall registry keys, application directories, and execution artifacts. Two cautions here that matter and are often got wrong. Application compatibility cache entries evidence that the operating system saw a file path; they are not proof of execution. Amcache records file presence, and how much its fields support an execution inference varies by Windows build — check the build before relying on it. Prefetch files do evidence execution, with a run count and recent run times, but prefetch is commonly disabled on server builds and its behaviour has varied across configurations. Say which artifact you relied on and what it supports.

Courts treat wiping as conduct rather than a technical curiosity. In Genger v. TR Investors the Delaware Supreme Court affirmed findings of spoliation where a party caused deletion of files and the wiping of unallocated free space on a work computer, held him in contempt of a status quo order, and upheld a multi-million-dollar fee and expert-cost award — while cautioning that the affirmance should not be read beyond its narrow facts. In Victor Stanley v. Creative Pipe a sustained pattern of deletion and wiping-software use produced a recommendation of default judgment on one count plus a contempt finding and fee shifting. In Calsep A/S v. Dabral the Fifth Circuit affirmed a default judgment where a trade-secret defendant destroyed electronic evidence including material in a source-code control system, in violation of court orders. And in Jones v. Riot Hospitality Group the Ninth Circuit affirmed dismissal under Rule 37(e)(2) where the plaintiff deleted text messages and coordinated with witnesses to delete theirs, holding that intent may be proved by circumstantial evidence and that the rule requires no separate prejudice finding.

The pattern across all four: what was proved was not the content of the destroyed material. It was the destruction.

How do you detect timestomping without overclaiming?

Four indicators, in descending strength:

1. $LogFile holding a prior $STANDARD_INFORMATION image. The journal's redo data frequently contains previous versions of MFT attributes, which means the original timestamps themselves may still be recoverable. This is the strongest form of evidence available and also the shortest-lived.
2. A $UsnJrnl record noting a basic-information change with no accompanying data write. The manipulated value sits in $MFT; the journal records the real moment of the manipulation from the system clock.
3. $STANDARD_INFORMATION diverging from $FILE_NAME. Tools that set times through the documented Windows interfaces affect the first set and not the second.
4. Internal implausibility. Sub-second fields that are exactly zero across all four timestamps; a creation date years older than the files occupying adjacent MFT record numbers; a creation time later than the last modification time.

Every one of these has benign causes, and an examiner who states them first is far more persuasive than one who is made to concede them. Archive extraction restores stored modification times. Installers and package managers set timestamps deliberately. File copies across volumes carry times from elsewhere. Sync clients write server-side times. Backup restores bring an entire tree of foreign timestamps. Virtual machine snapshot restores move the whole system's clock. So the correct form is: this pattern is consistent with deliberate timestamp modification and with the following alternative explanations, of which the following have been excluded on the following basis. File System Forensic Analysis is the reference for why the structures behave this way.

What can you say about encryption and hiding?

Full-disk encryption. Without a key, the realistic outcome is nothing at all, and there is no honourable way to dress that up. The routes that do exist are organisational rather than cryptographic: a recovery key escrowed in a directory service, a cloud account or an MDM platform; key material recovered from a memory capture taken while the volume was unlocked; and password attacks, which succeed against weak passphrases and not otherwise — Hashcat and John the Ripper will tell you quickly which case you are in. Plan the collection to preserve the live, unlocked state where that is lawfully available, because that decision cannot be revisited.

Encrypted containers. You generally cannot prove from content alone that a file is an encrypted container, because a well-formed container is designed to be indistinguishable from random data. What you have is inference: a large file with uniformly high entropy and no recognisable header, plus evidence the software was installed, plus mount or MRU artifacts, plus a driver trace. State it as inference. Hiding Behind the Keyboard is the practical treatment of these techniques and their traces.

Hidden volumes. Designs offering plausible deniability are built so that the absence of a second volume is unprovable. If you are asked whether a hidden volume exists and you have no key, the answer is that the question cannot be resolved from the data. That is a complete and correct answer.

Alternate data streams. NTFS streams hide a file's content from a directory listing and from naive copying, but they are trivially enumerable with dir /r, The Sleuth Kit, or any competent forensic suite. Effective against a casual look, not against an examination.

Steganography. Detection is unreliable and highly dependent on the carrier, the embedding method and the payload size. A negative steganalysis result licenses essentially nothing. Say that rather than reporting a clean result as a finding.

What about attacks on the tools?

Real, and mostly a quality-assurance problem rather than a detection problem. Malformed filesystem structures, deliberately corrupt containers, pathological path depths and compression bombs can crash a parser or make it report the wrong thing. Crafted hash collisions can defeat processes that make decisions from a single digest — deduplication and known-file elimination in particular.

The defences are procedural. Parse anything load-bearing with two independent tools and compare. Validate your tooling against data with known answers; CFReDS exists for this. Record tool names and versions per finding. SWGDE's minimum requirements for testing tools states what to record, and ISO/IEC 27041 is the standard that frames tool assurance as part of showing the method was fit for the question. Compute two digests in one pass, which removes the crafted-collision line of attack entirely.

What does "nothing found" actually license you to say?

Three rungs. Know which one you are on, and never step up without the showing.

Rung one — always available if true. No artifacts of the described kind were identified within the data examined, using the described methods, over the described scope. This requires you to have described the method and the scope. It is not a weak statement; it is the statement that is defensible, and it is the one an opposing expert cannot dismantle.

Rung two — available only with a showing. The described activity did not occur on this device during this period. This requires demonstrating, for at least one artifact the activity would necessarily produce, that the artifact was (a) enabled in the relevant configuration, (b) retained across the whole relevant period, and (c) intact and unmodified. Log retention windows, default-off auditing, circular journals and reused MFT entries mean you will usually fail at least one of the three. When you can make the showing, make it explicitly and show the retention arithmetic.

Rung three — essentially never available from one device. The activity did not occur. Data moves; accounts are used from several devices; there are cloud and server-side records you never saw. One endpoint cannot carry this.

Keep three formulations in the report and use them literally:

• Account, not person. Authentication and file ownership evidence accounts and identifiers. Placing a human behind them is a separate argument needing separate evidence — Brett Shavers' Placing the Suspect Behind the Keyboard is the book-length treatment of why.
• Access, not exfiltration. A file opened is not a file taken, and a connection is not a payload.
• Absence of evidence, not evidence of absence. With the retention window stated, so the reader can see why.

How should the limits be expressed?

Not as a disclaimer at the end. As part of each finding. The ENFSI guideline on evaluative reporting, ISO 21043-4 on interpretation and ISO 21043-5 on reporting all structure the finding as a proposition assessed against alternatives, and ISO/IEC 27042 takes the same line on analysis and interpretation. Casey's papers on error and uncertainty and on expressing preliminary evaluative opinions are the shortest practical introduction. NIST's scientific foundation review is the document to have on hand when the reliability of the discipline itself is raised.

There is also a straightforwardly tactical reason. Where forensic analysis has decided a case, it has usually done so by showing that a party's account was inconsistent with the data — Rossbach v. Montefiore Medical Center, where the produced photograph could not have been made on the device claimed to have received the messages, and Cat3, LLC v. Black Lineage, where the produced emails were altered and the natives were gone. In both, the examiner's finding was narrow, specific, and about what the data could not support. That is the shape of a finding that holds.

For structured practice at this, GCFA and GCFE both test anti-forensic artifact reasoning, 13Cubed covers the NTFS-level indicators in depth, and if the eventual audience is lawyers rather than examiners, the digital forensics for lawyers track is built around exactly this distinction between what was found and what it means.