Detecting Windows Anti-Forensics: What Survives the Cleanup

Attackers clean up, and most of that cleanup leaves its own fingerprints. By the end of this guide you will be able to recognise the common Windows anti-forensic techniques, map them to MITRE ATT&CK, know exactly which artifacts survive each one, and structure an investigation that treats missing evidence as a finding rather than a dead end.

Why anti-forensics rarely works completely

Anti-forensics on Windows fights a system that records the same activity in many places. Clearing one log does not clear the others, deleting a file writes to the USN journal, and running a wiper creates Prefetch and Amcache entries for the wiper. The attacker has to know every copy, and has to delete it without creating new traces. In practice they rarely manage both.

The mapping below is the frame for the rest of the guide. Technique IDs come from MITRE ATT&CK.

Event log clearing

Clearing is the most common and the easiest to detect. The Event Log service writes a final record when a log is wiped:

• Security log cleared: event 1102 in the Security log, with the account name and logon ID of the user who cleared it.
• Any other log cleared: event 104 in the System log (source Microsoft-Windows-Eventlog), naming the channel and the account.

Both are generated whether the clear came from Event Viewer, wevtutil cl, PowerShell or the API. See the Windows event logs cheat sheet for the other IDs worth knowing and our event log forensics guide for the full workflow.

# Find clearing events on a live system or against exported .evtx files
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}
Get-WinEvent -FilterHashtable @{LogName='System'; Id=104} |
  Select-Object TimeCreated, @{n='Detail';e={$_.Message}}

# Offline, across a folder of collected logs
EvtxECmd.exe -d E:\Triage\C\Windows\System32\winevt\Logs --csv E:\Out --inc 1102,104,1100,4719

A cleared log often starts with 1102 or 104 as its first record, well after the last boot. Also look for:

• Gaps in EventRecordID within a log that was not cleared. Record IDs increase monotonically, so a jump suggests records were removed by a tool that edits the file rather than clearing it.
• Event 1100 in Security, "The event logging service has shut down", outside a normal shutdown sequence.
• The clearing command itself: wevtutil.exe in Prefetch, 4688 process creation (if command-line auditing is on), Sysmon event 1, or PowerShell script block logging (4104).

Disabling logging and audit policy

Quieter than clearing is preventing events from being written in the first place (T1562.002).

• Audit policy changes: auditpol /clear or auditpol /set ... /success:disable produces event 4719 "System audit policy was changed" in Security, listing the subcategory and the change.
• Disabling a channel: wevtutil sl <channel> /e:false sets Enabled to 0 for that channel. Check the channel configuration under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\ and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\.
• Stopping the service: the Event Log service is hard to stop cleanly, so tools such as Invoke-Phant0m kill its worker threads instead. The service stays "running" while nothing is written. The tell is a silent period in every log at once while other artifacts (USN, Prefetch, SRUM) show the machine was busy.
• Shrinking log size: a MaxSize suddenly set very small makes the log roll over quickly. Compare against the default and the domain policy.

Timestomping

Covered in depth in the NTFS forensics guide, so briefly: timestomping rewrites the $STANDARD_INFORMATION times of a file to blend in. Check for a $SI creation time earlier than the $FILE_NAME creation time, sub-second values of .0000000, and a BASIC_INFO_CHANGE reason in the USN journal close to the file's arrival. The $SI versus $FN comparison is a lead; the USN and $LogFile records are the corroboration.

Secure deletion and wiping

Plain deletion leaves the $MFT record and clusters behind. Secure deletion tools try to fix that, but NTFS journals their work.

SDelete

Sysinternals SDelete overwrites the file content, then typically renames the file 26 times, each time to a name of the same length made of a single repeated letter (for example AAAAAAAA.AAA, then BBBBBBBB.BBB, through ZZZZZZZZ.ZZZ), and finally deletes it. In the USN journal that appears as a rapid burst of RENAME_OLD_NAME and RENAME_NEW_NAME pairs on the same file reference, followed by FILE_DELETE. The original name is in the first RENAME_OLD_NAME record.

Other SDelete traces:

• SDELETE.EXE or SDELETE64.EXE in Prefetch, Amcache and ShimCache.
• HKCU\Software\Sysinternals\SDelete with EulaAccepted = 1 in the user's NTUSER.DAT, which ties the use to an account.

# Filter a parsed USN CSV for SDelete-style rename bursts
Import-Csv E:\Out\usn.csv |
  Where-Object { $_.Name -match '^([A-Z])\1+(\.\1+)?$' -and $_.UpdateReasons -match 'Rename' } |
  Select-Object UpdateTimestamp, EntryNumber, Name, ParentPath, UpdateReasons

cipher /w, CCleaner and BleachBit

• cipher /w:C:\ overwrites free space. It is a built-in LOLBin, so look for it in Prefetch and command-line logs, and for a temporary EFSTMPWP folder at the volume root in the USN journal.
• CCleaner leaves an installation, HKCU\Software\Piriform\CCleaner settings (which often reveal what the user chose to clean), UserAssist and Prefetch entries.
• BleachBit is frequently run portable, but still produces Prefetch and Amcache entries, a BleachBit.ini next to the executable, and a USN signature of many deletions across browser and temp paths within seconds.

The cleaning tool's own footprint is usually easier to prove than what it deleted. Report both.

Deleting shadow copies and backups

Deleting volume shadow copies (T1490) is standard in ransomware playbooks because VSS lets victims, and investigators, recover older file versions.

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=401MB
wbadmin delete catalog -quiet
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

What to look for:

• vssadmin.exe, wmic.exe, wbadmin.exe and bcdedit.exe in Prefetch, 4688 and Sysmon, with their command lines.
• Event 524 in the Application log (source Microsoft-Windows-Backup) indicating the backup catalog was deleted, when Windows Server Backup components are present.
• VSS service start and stop events (System 7036) around the time of deletion, and the absence of any snapshot where scheduled restore points were expected.
• WMI-based deletion through Win32_ShadowCopy in PowerShell script block logs.

Deleted snapshot data can sometimes be partially carved from the System Volume Information diff area, but plan on it being gone.

Clearing execution and activity artifacts

• Prefetch: deleting C:\Windows\Prefetch\*.pf shows up as a block of FILE_DELETE records for .pf files in the USN journal. Disabling it sets EnablePrefetcher to 0 under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters. A workstation with a nearly empty Prefetch folder is suspicious on its own.
• ShimCache: the cache is held in memory and written to the SYSTEM hive at shutdown, so tampering usually means editing or deleting the AppCompatCache value. Compare against copies in shadow copies and the hive's transaction logs.
• Command history: deleting ConsoleHost_history.txt (PSReadLine) removes the convenient copy, but 4104 script block events and the file's own USN and MFT records remain.
• Browser history: clearing Chrome or Edge history deletes rows from the History SQLite database, but freelist pages, the -journal or WAL file, cache, Favicons, DNS client events and SRUM network usage often retain traces. See browser artifacts.
• USN journal: fsutil usn deletejournal /d C: removes the journal. A $J that begins minutes before collection on an old system, or a journal ID that changed, is a red flag; fsutil.exe in Prefetch confirms it.

Disabling Microsoft Defender

Defense impairment (T1562.001) against Microsoft Defender is noisy in its own Operational log (Microsoft-Windows-Windows Defender/Operational).

# Typical attacker commands to look for in PowerShell logs and history
Set-MpPreference -DisableRealtimeMonitoring $true
Add-MpPreference -ExclusionPath 'C:\ProgramData\svc'

Registry traces: DisableAntiSpyware or DisableRealtimeMonitoring under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender, and exclusions under HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths, \Extensions and \Processes. Recent Defender platform versions ignore DisableAntiSpyware, and tamper protection blocks many of these changes, but the attempt still matters: an exclusion path is a direct pointer to where the payload lived.

Hiding files and data

• Hidden and system attributes (attrib +h +s) are visible in the $MFT attribute flags and as BASIC_INFO_CHANGE in the USN journal.
• Alternate data streams hide payloads behind a legitimate file. They appear as additional named $DATA attributes in the $MFT and as NAMED_DATA_EXTEND or STREAM_CHANGE in the USN journal. Execution from an ADS can also show in Prefetch with the stream name in the path.

Living off the land

Most of the techniques above use built-in binaries: wevtutil, auditpol, vssadmin, wmic, wbadmin, bcdedit, fsutil, cipher, attrib and PowerShell. That makes them harder to block but no harder to find, because built-in binaries are still logged by Prefetch, 4688, Sysmon and Amcache. Several of these rarely run on a normal workstation, so their mere presence in Prefetch in the incident window is worth a line in the timeline.

Absence of evidence is evidence

Anti-forensics creates holes, and holes have shapes. Questions to ask:

• Does the Security log start after the last boot, with 1102 as its first record?
• Is the Prefetch folder nearly empty on a workstation that has been used for months?
• Does the USN journal cover only a few hours when its size suggests weeks?
• Did every event log go silent for the same two hours while SRUM and the USN journal show activity?
• Are there no shadow copies on a system configured to create them?

A gap is weak evidence alone because retention, misconfiguration and rollover also cause gaps. It becomes strong when the gap is abrupt, aligns with the intrusion window, and coincides with the tool or command that caused it.

What survives each technique

Tools

• EvtxECmd and the site's EVTX Parser for 1102, 104, 4719 and Defender events.
• MFTECmd (or the USN Parser and MFT Parser) for rename bursts, timestomping flags and deletions.
• PECmd, AmcacheParser and AppCompatCacheParser for the cleaning tools' own execution.
• Registry Explorer or RECmd for Piriform, Sysinternals, Defender exclusion and channel keys.
• Velociraptor hunts across many endpoints, including shadow copies, to find the hosts where logs were cleared.
• Hayabusa or Chainsaw with Sigma rules to flag clearing and tampering events at scale.

Common mistakes

• Stopping at "the log was cleared". The clearing event gives you a time and an account; use both to pivot.
• Ignoring shadow copies and SIEM copies. A cleared Security.evtx is often intact in an older snapshot or in forwarded events.
• Over-reading one gap. Confirm log size, retention and boot history before calling a gap deliberate.
• Forgetting the tool's own footprint. The cleaner, wiper or script is itself evidence of intent.
• Running cleanup-like tools during response. Some EDR and triage scripts rotate logs or delete temp files; document everything you ran.

Workflow

1. Preserve first: collect event logs, $MFT, $J, $LogFile, registry hives and shadow copies before anything else rotates. See acquisition and triage with KAPE and Velociraptor.
2. Sweep for explicit indicators: 1102, 104, 1100, 4719, Defender 5001/5007/5013, backup event 524.
3. Check execution of anti-forensic tools and LOLBins in Prefetch, Amcache, ShimCache, 4688 and Sysmon.
4. Parse the USN journal for SDelete rename bursts, mass deletions in Prefetch, browser and temp paths, and BASIC_INFO_CHANGE on suspicious files.
5. Review the $MFT for timestomping flags, hidden attributes and ADS on files of interest.
6. Measure coverage: first and last record of each log and of $J, Prefetch count, snapshot list. Document every abrupt gap.
7. Recover what was removed: older logs and hives from VSS, SIEM data, $LogFile undo data, $I30 slack and carved records.
8. Build one super timeline and report both the cleanup actions and what they tried to hide, with the ATT&CK IDs.