In this module

Anti-Forensics Overview

Module 0 · Free

Operational Objective

Forensic analysis assumes that artifacts exist to be analyzed. Anti-forensics challenges that assumption by destroying, manipulating, or concealing the artifacts that an examiner depends on. An attacker who timestomps a malicious executable defeats timestamp-based timeline analysis. An attacker who clears the Security Event Log eliminates authentication evidence. An attacker who deletes Prefetch files removes execution evidence. An attacker who uses memory-only tools avoids creating disk artifacts entirely. The examiner who does not understand anti-forensic techniques will produce incomplete findings — not because they lack skill, but because they assume the evidence is complete when it is not. Worse, they will fail to recognize the anti-forensic activity itself as evidence: the act of clearing logs, deleting artifacts, and manipulating timestamps is evidence of consciousness of guilt — often more damning than the underlying activity it attempted to conceal. This subsection maps the anti-forensic techniques that affect each artifact category covered in this course, the residual traces each technique leaves behind, and the detection methodology that identifies anti-forensic activity from the artifacts that survive the cleanup.

Deliverable: Complete anti-forensic threat model for Windows forensic artifacts: techniques organized by target artifact category, difficulty and sophistication rating for each technique, residual traces that each technique leaves behind, and the detection indicators that reveal anti-forensic activity. The foundation for the detailed anti-forensic detection methodology in WF10.

Estimated completion: 35 minutes

Figure WF0.9 — Four categories of anti-forensic techniques. Destruction is the most common and leaves the most traces. Avoidance is the most sophisticated and leaves the fewest traces. Every technique leaves some residual indicator — the examiner's job is to know where to look.

Destruction: the most common, the most detectable

The overwhelming majority of anti-forensic activity in real-world incidents is artifact destruction — deleting the evidence. Attackers clear Event Logs, delete Prefetch files, empty the Recycle Bin, clear browser history, and delete their tools after use. These actions are effective against examiners who only analyze what is present. They are largely ineffective against examiners who analyze what is missing and what the destruction itself reveals.

Event Log clearing is the single most common anti-forensic action in enterprise compromises. The command wevtutil cl Security clears the Security Event Log. The irony: clearing the Security log generates Event ID 1102 in the Security log — a record that the log was cleared, including the account that cleared it and the timestamp. If the attacker clears all Event Logs (Security, System, Application, PowerShell), Event ID 104 in the System log records each clearing. Even if all logs are cleared simultaneously, the clearing events for the System log are written before the System log itself is cleared — creating a narrow window where the clearing evidence exists. Additionally, Event Log files that were cleared can sometimes be recovered from Volume Shadow Copies (taken before the clearing), from $LogFile entries (if the clearing is recent enough), and from centralized log collection (SIEM, WEF).

Prefetch deletion removes execution evidence. An attacker who deletes their tools and then deletes the corresponding Prefetch files eliminates both the executable and the execution evidence. The residual traces: the USN Journal records the deletion of the Prefetch file itself (FILE_DELETE reason code for a .pf file in C:\Windows\Prefetch). The MFT may retain the deleted Prefetch file's MFT record (marked as free but containing the filename and timestamps). If the attacker deletes the entire Prefetch folder content, the mass deletion generates a burst of USN Journal entries that is itself a detectable anomaly — hundreds of FILE_DELETE entries for .pf files within seconds.

USN Journal deletion (fsutil usn deletejournal /d C:) destroys the filesystem change log. This eliminates the examiner's ability to reconstruct file operations through the journal. The residual traces: the $UsnJrnl:$J stream's MFT attributes show the journal was deleted and recreated (the journal file's MFT timestamps reflect the recreation time, not the original creation time). The $LogFile may contain NTFS transactions from the journal deletion. And the act of running fsutil generates its own Prefetch file, Event Log entries (process creation if auditing is enabled), and Amcache/Shimcache records.

Expand for Deeper Context

The recursive nature of anti-forensic destruction is 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. To eliminate all traces, the attacker would need to destroy every artifact source simultaneously without generating any new artifacts — which is technically impossible on a running Windows system.

This is why sophisticated attackers increasingly favor avoidance (not creating artifacts in the first place) over destruction (creating artifacts and then trying to destroy them). But even avoidance has limits: living-off-the-land binaries still generate Prefetch entries for the proxy executables (powershell.exe, rundll32.exe, mshta.exe), EDR telemetry still captures process creation and command lines, and network artifacts (SRUM, DNS cache, firewall logs) still record external communication regardless of whether the tool is memory-resident or disk-resident.

Manipulation: harder to detect, harder to execute

Artifact manipulation — changing the evidence rather than deleting it — is more sophisticated than destruction and more difficult to detect because the artifact still exists. The examiner finds evidence that looks normal but contains altered values.

Timestomping is the most common manipulation technique. The attacker modifies $STANDARD_INFORMATION timestamps to make a malicious file appear to have been created months ago, blending it with legitimate system files. The detection is the $SI/$FN timestamp discrepancy described in WF0.4 — $SI timestamps are modifiable via SetFileTime(), $FN timestamps are not. Additional indicators: zero nanoseconds in $SI timestamps (programmatic setting), $SI Created earlier than $FN Created (backdating), and USN Journal entries showing the file was actually created at a different time than $SI claims.

Log injection — inserting fabricated entries into Event Logs — is theoretically possible but rarely seen in practice. The EVTX format includes checksums per chunk that make seamless injection difficult without corrupting the log file. Injecting entries requires either writing to the Event Log via the Windows API (which records the source process) or directly manipulating the binary EVTX file (which risks checksum validation failures). The difficulty of seamless log injection is why most attackers opt for log clearing rather than log manipulation.

Registry manipulation — modifying registry values to hide persistence or alter execution evidence — is straightforward for individual values but difficult to do comprehensively. An attacker who modifies a service's ImagePath to point to a legitimate executable hides the malicious path, but the modification updates the key's last write timestamp and may be recorded in the registry transaction log. Restoring the original ImagePath after execution creates a second timestamp update. The examiner who checks the registry transaction logs can see the modification history.

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.

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.

Decision point

Your analysis reveals the attacker cleared the Prefetch directory, deleted the USN Journal, and timestomped the $SI timestamps on their tools. Event Logs were NOT cleared. The incident commander asks: "How sophisticated is this attacker?"

Your options: (A) Highly sophisticated — they performed three distinct anti-forensic operations targeting different artifact types. (B) Moderately sophisticated with gaps. The attacker understood Prefetch, USN Journal, and $SI timestamps — three common forensic targets documented in DFIR training. But they missed: Amcache (SHA1 hashes preserved), Shimcache (execution evidence preserved), BAM/DAM (user attribution preserved), Event Logs (process creation preserved), and $FN timestamps (real creation times preserved). The selective cleanup pattern — targeting popular forensic artifacts while missing less-publicized ones — is consistent with an attacker who has read DFIR blog posts but lacks deep forensic training. A truly sophisticated attacker would also clear Amcache, manipulate Event Logs, and understand $FN timestamp persistence.

The correct approach is B. The anti-forensic profile reveals the attacker's knowledge level — useful for threat assessment and for knowing which compensating evidence sources to check.

Try It — Identify Anti-Forensic Indicators in KAPE Output

If you have a KAPE collection from a system (your lab VM or a practice image), look for these anti-forensic indicators:

1. Event Log clearing: Open the Security Event Log in Event Log Explorer or EvtxECmd. Search for Event ID 1102. If present, the log was cleared — note the timestamp and the account name. Check the System Event Log for Event ID 104. If both Security and System were cleared, check if any events predate the clearing timestamp — these were generated after the clear and represent the clearing event itself plus any subsequent activity.

2. Prefetch anomalies: List all Prefetch files sorted by creation timestamp. A gap in the timestamp sequence (e.g., no Prefetch files created between March 15 and March 28, then a burst of new files) suggests the Prefetch directory was cleared on approximately March 15. Check for Prefetch files for known cleanup tools: SDELETE.EXE, CCLEANER.EXE, ERASER.EXE, BLEACHBIT.EXE.

3. USN Journal freshness: Check the oldest entry in the USN Journal. If the oldest entry is very recent (within hours or days) on a system that has been running for months, the journal was likely deleted and recreated. Compare the journal's MFT record creation timestamp against the system installation date.

4. Timestomping indicators: Parse the MFT with MFTECmd. Add a calculated column in Timeline Explorer: Created0x10 minus Created0x30. Sort by this column descending. Files where $SI Created is significantly earlier than $FN Created are timestomping candidates. Files where $SI Created has .0000000 nanoseconds surrounded by files with normal sub-second values are programmatic setting candidates.

Document what you find. Even on a clean lab VM, you may discover interesting patterns — Windows itself generates some timestamp behaviors that look suspicious but are legitimate (file tunneling, copy operations, Windows Update timestamps).

Compliance Myth: "Anti-forensics means the investigation is a dead end"

The myth: If the attacker cleared the logs, deleted their tools, and timestomped the remaining artifacts, the forensic examination cannot produce useful findings. Anti-forensics defeats forensic analysis.

The reality: Anti-forensics defeats lazy forensic analysis. Comprehensive artifact analysis across multiple independent sources defeats most anti-forensic techniques because the attacker cannot simultaneously destroy all artifact categories without generating new artifacts in the process. Cleared Event Logs leave Event ID 1102/104 records, USN Journal entries for the EVTX file modifications, and Prefetch evidence for wevtutil.exe. Deleted Prefetch files leave USN Journal entries and MFT orphan records. Timestomped files are detected through $SI/$FN comparison and USN Journal correlation. The examiner who analyzes all artifact categories — not just the obvious ones — finds the evidence the attacker missed. Furthermore, the anti-forensic activity itself is evidence: it demonstrates that the subject had the knowledge, access, and motivation to destroy evidence, which is typically more incriminating than the underlying activity would have been.

Troubleshooting

"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.

Operational Artifact — Anti-Forensic Indicator Checklist

Check for these indicators in every investigation — their presence changes the scope and methodology of the examination. Event Logs: Event ID 1102 in Security log (log cleared). Event ID 104 in System log (any log cleared). Gaps in record ID sequence (selective deletion). Suspiciously recent oldest entry. Prefetch: Gap in Prefetch file creation timestamps. Prefetch files for cleanup tools (SDelete, CCleaner, Eraser, BleachBit). Very few Prefetch files on a system that has been running for months. USN Journal: Journal oldest entry is very recent relative to system age. Journal size is at minimum (recently recreated). $UsnJrnl MFT record created timestamp does not match system install date. Timestamps: $SI Created ≠ $FN Created by more than 10 seconds (timestomping). $SI timestamps with .0000000 nanoseconds (programmatic). $SI Created before $FN Created (backdating). Registry: Deleted keys in slack space for persistence locations (Services, Run, Scheduled Tasks). Transaction log entries showing key creation then deletion in the same session. Filesystem: SDelete execution (leaves zero-filled patterns). Large-scale file deletion in short time windows (USN Journal burst). $Recycle.Bin cleared during investigation timeframe. Document every indicator found. Anti-forensic activity is a finding in its own right — include it in the report with the same evidence documentation standard as any other finding.

During analysis of a compromised Northgate Engineering workstation (INC-NE-2026-1022), you discover the following: the Security Event Log's oldest record is from 2026-03-29 06:14:00 (the system was installed in 2024 and has been running continuously). The Security log contains Event ID 1102 at 2026-03-29 06:13:58 showing the log was cleared by account "NORTHGATEENG\svc-backup". The USN Journal contains a FILE_DELETE entry at 2026-03-29 06:15:12 for "C:\Windows\Prefetch\MIMIKATZ.EXE-1A2B3C4D.pf". Amcache contains an entry for mimikatz.exe with SHA1 hash matching the known tool. What conclusions can you draw?

The investigation is compromised — the attacker cleared the Security log and deleted the Prefetch file, so there is insufficient evidence to determine what happened. The examiner should report that anti-forensic activity prevents conclusive findings.

The svc-backup account legitimately cleared the Security log as part of a backup operation (the account name suggests a backup service), and the Prefetch deletion was part of normal Prefetch maintenance. The Amcache entry for mimikatz.exe may be from a legitimate penetration test. More context is needed before concluding this is malicious.

Multiple findings are supported despite the anti-forensic activity. First, the Security log was cleared on March 29 at 06:13:58 by the svc-backup account — this is itself a finding (legitimate backup services do not clear Security logs). Second, mimikatz.exe was executed on this system — the Amcache entry with matching SHA1 proves installation/first execution, and the Prefetch deletion at 06:15:12 proves a Prefetch file existed (confirming execution) and was deliberately deleted 77 seconds after the log clearing (indicating coordinated cleanup). Third, the cleanup sequence (clear logs → delete Prefetch) and the use of a service account suggest the attacker had compromised the svc-backup credential. The anti-forensic activity itself provides a timeline, an attribution lead (svc-backup account), and evidence of consciousness of guilt.

The Amcache entry alone provides high confidence that mimikatz.exe was executed. The Event Log clearing and Prefetch deletion are secondary findings that don't add forensic value since the Amcache already proves execution. The examiner should focus the report on the Amcache finding and mention the anti-forensics as context.

You've built the foundations of artifact-level forensic analysis.

WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation

Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →