Anti-Forensics Overview

Four categories of anti-forensic techniques

Destruction: the most common, the most detectable

The overwhelming majority of anti-forensic activity in real incidents is artifact destruction. The attacker's fundamental problem: every destruction action generates new artifacts. Clearing Event Logs generates clearing events. Deleting Prefetch files generates USN Journal entries and MFT records. Deleting the USN Journal generates Prefetch and Event Log evidence for fsutil. Running a cleanup tool generates Prefetch, Amcache, and Shimcache evidence for the cleanup tool itself.

Event Log clearing is the single most common anti-forensic action. wevtutil cl Security clears the Security log but generates Event ID 1102 recording the clearing, including the account and timestamp. Event ID 104 in the System log records each log cleared. Even when all logs are cleared simultaneously, the clearing events for the System log are written before the System log is cleared. Cleared logs can sometimes be recovered from Volume Shadow Copies, $LogFile entries, and centralized log collection (SIEM, WEF).

This is what the log-clearing event looks like. The attacker cleared the Security log, but the clearing itself was recorded:

Log Name:       Security
Source:         Microsoft-Windows-Eventlog
Event ID:       1102                                ◄ The audit log was cleared
TimeCreated:    2026-03-18 02:47:33.0000000 UTC
Subject:
  Security ID:  S-1-5-21-3842749519-...-1104       ◄ Who cleared it
  Account Name: svc_backup                          ◄ Compromised service account
  Domain Name:  NGE
  Logon ID:     0x3E7

The attacker used a compromised service account (svc_backup) to clear the Security log at 02:47 UTC. The clearing itself is evidence: it tells you who did it, when, and with what account. A legitimate administrator clearing logs during maintenance would use their own account during business hours, not a service account at 2:47 AM.

Prefetch deletion removes execution evidence. The residual traces: USN Journal records the .pf file deletions with FILE_DELETE reason codes. The MFT may retain deleted Prefetch file records. Mass deletion of .pf files generates a burst of USN entries that is itself a detectable anomaly.

USN Journal deletion (fsutil usn deletejournal /d C:) destroys the filesystem change log. The residual traces: the $UsnJrnl MFT record shows the journal was deleted and recreated (timestamps reflect recreation, not original creation). The $LogFile may contain transactions from the deletion. And running fsutil generates its own Prefetch, Event Log, Amcache, and Shimcache records.

Manipulation: harder to detect, harder to execute

Manipulation modifies evidence rather than destroying it. The attacker changes what the evidence says rather than removing it entirely. This is harder to detect than destruction because the artifact still exists — it just contains false information.

Timestomping modifies $SI timestamps to make malicious files appear legitimate. An attacker who deploys a ransomware executable at 02:14 AM can set $SI Created to match system files from the original Windows installation. The file appears in directory listings and forensic tool output as an old, legitimate file. Detection: $SI/$FN timestamp discrepancy (the $FN timestamps retain the real creation time), zero nanoseconds in $SI (indicating programmatic timestamp setting), $SI Created earlier than $FN Created (temporal inversion), and USN Journal entries showing BASIC_INFO_CHANGE at the real modification time.

Registry manipulation modifies persistence values after the attacker no longer needs them. Changing a malicious service's ImagePath back to a legitimate value, or deleting a Run key that loaded the implant. The modification updates the key's last write timestamp, and the original value may be recoverable from registry transaction logs (.LOG1, .LOG2 files in the config directory). Registry slack space may also contain fragments of deleted keys and values.

Log injection (inserting fabricated Event Log entries) is theoretically possible but rarely seen in practice. EVTX files use chunk checksums and record numbering that make seamless injection difficult. An injected record with incorrect checksums or out-of-sequence record IDs is detectable by tools that validate EVTX structural integrity. Automated injection is complex enough that most attackers choose destruction (clearing the log) over injection.

Metadata alteration targets document metadata (Office author fields, PDF creation tools, image EXIF data) to remove attribution. The file's NTFS metadata (MFT timestamps, parent path, file size) is unaffected by document-level metadata changes, but the content metadata the examiner uses to attribute authorship or identify tools may be falsified.

Avoidance: the hardest to detect

Sophisticated attackers increasingly favor avoidance over destruction: memory-only execution, reflective DLL injection, .NET in-memory assembly loading, living-off-the-land binaries, and fileless PowerShell payloads. These techniques create minimal disk artifacts. The residual traces: Prefetch entries for proxy executables (powershell.exe, rundll32.exe, mshta.exe), SRUM network transfer data for C2 communication, DNS cache entries, and the aftermath of the in-memory activity (files created, registry keys modified, credentials dumped). Disk artifacts provide the envelope around memory-only execution even when they don't capture the execution itself.

Common analysis issues

"How do I distinguish anti-forensic cleanup from normal system maintenance?" Context and pattern. A user running CCleaner on their personal workstation on a monthly schedule is maintenance. A user running CCleaner for the first time (per Prefetch) on the day after a data loss prevention alert is suspicious. Event Logs clearing on a workstation is almost never legitimate — there is no normal operational reason for a user to clear the Security log. USN Journal deletion is never part of normal system operation. The investigative context — timing relative to the incident, the account that performed the action, the scope of the cleanup — distinguishes maintenance from anti-forensics.

"What about disk encryption — if the whole disk is BitLocker-encrypted, can we still analyze artifacts?" If the system is powered on and the volume is unlocked, yes — KAPE collects from the decrypted logical volume. If the system is powered off, you need the BitLocker recovery key to unlock the volume before analysis. In enterprise environments, BitLocker recovery keys are typically stored in Active Directory or Intune. If the recovery key is available, encryption does not impede forensic analysis. If the recovery key is unavailable and the system is powered off, the disk contents are inaccessible. This is one reason to prioritize live collection from running, unlocked systems before powering them off.

"Sophisticated attackers use memory-only tools: how do we detect those from disk artifacts alone?" You can't always detect memory-only activity from disk artifacts — that's why memory forensics exists as a separate discipline. What you can detect from disk artifacts: the proxy executables used to launch memory-only payloads (Prefetch for powershell.exe, rundll32.exe, mshta.exe), the network communication generated by the in-memory tool (SRUM bytes sent/received, DNS cache entries, browser artifacts if web-based C2), and the aftermath of the in-memory activity (files created, registry keys modified, credentials dumped to disk). The disk artifacts provide the envelope of activity around the memory-only execution, even if they don't capture the execution itself.

Concealment: hiding in plain sight

Concealment techniques hide data rather than destroying or modifying it. The data exists on the system but is not visible through standard examination methods.

Alternate Data Streams store data in named streams attached to files or directories. A file report.docx:payload.exe contains a hidden executable in a named stream that is invisible to standard directory listings. The MFT records ADS as additional $DATA attributes. MFTECmd reports them, and any MFT analysis that checks for multiple $DATA attributes will detect them. Concealment via ADS is easily detected by artifact-aware examiners but can evade examiners who only look at file listings.

Encrypted containers (VeraCrypt, BitLocker non-system volumes) prevent access to content without the decryption key. The container file itself is visible in the MFT and generates USN Journal entries, Prefetch files (for the encryption tool), and ShellBag entries (if the mounted volume was browsed). The examiner can prove the container exists, when it was created and accessed, and what tool was used to mount it. But cannot access the contents without the key. In some jurisdictions, the court can compel the key; in others, the container contents remain inaccessible.

Steganography hides data within image or audio files. A PNG file that visually appears to be a normal photograph can carry kilobytes of hidden data in the least-significant bits of pixel values. Detection requires statistical analysis of the image data (tools like StegDetect, Stegsolve) and is not part of standard filesystem forensics. The examiner should be aware of steganography as a concealment vector when an insider threat investigation involves image files with no apparent business purpose being transferred to external media.

Slack space injection writes data into the unused portions of disk sectors or MFT records. A tool that writes directly to raw disk sectors can place data in the slack space between the end of a file's content and the end of its allocated cluster. This data is invisible to the filesystem and to standard forensic tools that read files through the filesystem API. Detecting slack space injection requires raw disk analysis comparing allocated sizes against used sizes and examining the content of slack regions for structured data. This technique is rare in practice but documented in academic anti-forensics research.

Avoidance: the hardest to detect

Avoidance techniques prevent artifact creation in the first place. Memory-only tools that never write to disk, reflective DLL injection that loads code without creating a file, .NET assemblies loaded directly from network streams into memory, and PowerShell payloads that execute entirely in the PowerShell process without touching the filesystem. All of these avoid creating the disk artifacts that this course teaches you to analyze.

The limitation of avoidance is that it only avoids disk artifacts. It does not avoid memory artifacts (detectable through memory forensics. Covered in the planned Memory Forensics Specialist course), process creation events (detectable through Sysmon and EDR), network communication artifacts (detectable through SRUM, DNS cache, and network logs), and the artifacts created by the proxy executables themselves. A PowerShell fileless payload avoids creating an executable file, but powershell.exe generates a Prefetch file, an Event Log entry (if ScriptBlock logging is enabled the full script content is recorded), and EDR telemetry for the process creation with command-line arguments.