Chapter 18

Anti-Forensics Detection

Anti-forensics is the deliberate destruction, concealment, or falsification of evidence. This chapter covers how to detect timestomping, log clearing, secure deletion, tool obfuscation, and other attacker cleanup attempts — and why these attempts themselves become evidence of attacker sophistication and intent.

Scenario

A threat actor attributed to a nation-state group has compromised a defense contractor. After establishing persistent access and exfiltrating their objectives, they ran a cleanup script: timestomped all their dropped tools to match surrounding system files, cleared Windows Event Logs, ran a secure deletion tool over their staging directory, and deleted VSS snapshots. The live system looks largely clean. But the anti-forensics activity itself left traces: the timestomping created $SI/$FN discrepancies, the log clearing is itself logged in System log Event 104, the secure deletion tool appears in BAM and Amcache, and the VSS deletion appears in process creation logs that were forwarded to the SIEM before the local log was cleared. The cleanup created as much evidence as the initial intrusion.

Timestomping Detection

Indicator	How to detect	What it means
$SI created timestamp precedes $FN created timestamp	MFTECmd SI_LT_FN=1 flag in CSV output	Primary timestomping indicator — $SI was changed but $FN wasn't updated to match
$SI timestamps have suspicious precision (round minutes, midnight)	Filter for timestamps ending in :00:00 or at midnight in MFT CSV	Automated timestomping tools often set to round values
$SI timestamps predate OS installation	Compare against SOFTWARE hive InstallDate key; any file with SI created before OS install is suspicious	System files with pre-install dates are expected; non-system-path executables with pre-install dates are not
MFT record sequence number inconsistent with timestamps	Sort MFT by record number and by timestamp separately — mismatches indicate timestomped records	Record numbers are sequential; a high record number with an old timestamp means the file was created recently but stamped with an old date
Prefetch/Amcache timestamp contradicts $SI timestamp	Cross-reference execution timestamps from Prefetch with $SI Modified timestamp	If Prefetch shows a binary ran at T+5 but $SI shows the file last modified at T-100days, the timestamps were changed

Log Clearing Detection

PowerShelllog-clearing-detection.ps1

# Detect event log clearing
# Event 1102: Security log cleared (Security log)
# Event 104:  Any log cleared (System log)

# From EvtxECmd CSV output
$evtx = Import-Csv "D:\analysis\evtx\evtx-all.csv"

$evtx | Where-Object { $_.EventId -in @("1102", "104") } |
    Select-Object TimeCreated, EventId, PayloadData1 |
    Sort-Object TimeCreated |
    Format-Table -AutoSize

# 1102 includes the account that cleared the log
# 104 includes which log was cleared

# From SIEM — even if local log was cleared, the SIEM may have the clearing event
# SIEM query example (Splunk):
# index=windows EventCode=1102 OR EventCode=104 host=COMPROMISED-HOST
# | table _time, host, EventCode, Message

Secure Deletion and Wiping Indicators

  Secure Deletion Detection Indicators
  ═══════════════════════════════════════════════════════════════════

  Tool-based detection:
    Secure deletion tools appear in:
    ├── Prefetch: SDELETE.EXE-*, ERASER-*, CIPHER-*
    ├── BAM/Amcache: binary execution records
    ├── Event 4688: process creation with tool path
    └── PowerShell ScriptBlock: Remove-Item + DoNotPreserve param

  Common secure deletion tool signatures:
    sdelete.exe (Sysinternals) — writes Z's then removes file
    cipher /w                  — wipes free space (native Windows)
    Eraser                     — GUI wiping tool
    BCWipe / FileShredder      — commercial alternatives

  Disk-level indicators:
    Overwritten clusters with uniform patterns:
    ├── All zeros: single-pass zero-wipe
    ├── All 0xFF: another wipe pattern
    ├── Random bytes: multi-pass DOD-style wipe
    └── Alternating 0x00/0xFF: specific tool signatures

  Detecting wiped areas with hex editor:
    In the disk image, navigate to clusters where deleted files were
    (using MFT entry to find cluster numbers).
    If clusters contain uniform patterns instead of realistic file data
    → wiping was performed → content is unrecoverable

  Pattern detection in bulk_extractor output:
    bulk_extractor -e find -S find_list='\x00{4096}' image.dd
    → Finds large blocks of zeros (zeroed clusters)

VSS Deletion Detection

PowerShellvss-deletion-detection.ps1

# Detect VSS deletion in event logs and process creation records
# vssadmin.exe delete shadows = ransomware/attacker cleanup indicator

# In SIEM (Splunk):
# index=windows EventCode=4688
# (CommandLine="*vssadmin*delete*" OR CommandLine="*wmic*shadowcopy*delete*"
#  OR CommandLine="*wbadmin*delete*")

# In EvtxECmd CSV output
$evtx = Import-Csv "D:\analysis\evtx\evtx-all.csv"

$evtx | Where-Object {
    $_.EventId -eq "4688" -and (
        $_.PayloadData1 -match "vssadmin.*delete" -or
        $_.PayloadData1 -match "wmic.*shadowcopy.*delete" -or
        $_.PayloadData1 -match "wbadmin.*delete.*catalog" -or
        $_.PayloadData1 -match "bcdedit.*recoveryenabled.*no"  # disabling boot recovery
    )
} | Select-Object TimeCreated, PayloadData1 | Format-Table -AutoSize

# Check if VSS snapshots currently exist
$shadows = Get-WmiObject Win32_ShadowCopy
if ($shadows.Count -eq 0) {
    Write-Warning "NO VSS SNAPSHOTS FOUND — may indicate deliberate deletion"
}

# Verify: was VSS disabled entirely?
$vssService = Get-Service VSS -ErrorAction SilentlyContinue
$vssStartType = (Get-WmiObject Win32_Service -Filter "Name='VSS'").StartMode
Write-Host "VSS service state: $($vssService.Status), StartType: $vssStartType"

Tool Obfuscation Detection

Obfuscation technique	Detection method
Renamed executable (mimikatz.exe → svchost32.exe)	Amcache PE metadata — Publisher field still says original vendor. Prefetch loaded DLL list — unusual DLLs for the claimed binary name. Hash lookup on VT.
Extension changed (.exe → .txt)	Autopsy "File Type Mismatch" detection — checks file header against extension. PE header in a .txt file = renamed executable.
Base64 encoded PowerShell (-EncodedCommand)	Event 4104 Script Block Log — Windows decodes the base64 before logging the script block. The DECODED content is in the log.
Packed/obfuscated PE	High entropy in sections (>7.5 bits/byte) is a packing indicator. Tools: FLOSS (extracts decoded strings from packed binaries), Detect-It-Easy (packer identification), Capa (capability detection despite packing).
Alternate Data Streams (ADS)	See Chapter 30 (ADS forensics). dir /r, Get-Item -Stream *, NTFS-aware tools detect hidden ADS. Zone.Identifier stream reveals download source.

Why anti-forensics activity is its own evidence category

When you document anti-forensics activity in an investigation report, you're establishing two things: the attacker was sophisticated enough to perform cleanup, and the attacker was aware they needed to conceal their activity — which implies intent. A ransomware group that deletes VSS snapshots has deliberately obstructed recovery. A state-sponsored actor that timestomps tools and clears logs is deliberately concealing their presence. These actions are not neutral — they're evidence of knowledge that what they were doing was unauthorized, and they can be used to establish willfulness in legal proceedings. Document every anti-forensics indicator you find as a named section in your report: it strengthens both the security case ("this was a sophisticated, targeted attack") and the legal case ("the attacker knew what they were doing and tried to hide it").

Q & A

Q: The attacker appears to have done a thorough cleanup — most artifacts are gone. How do you build an evidentiary timeline from remnants?

Start with what can't easily be cleaned: (1) SIEM logs forwarded before cleanup — these are your most reliable source; the attacker can't reach back into your SIEM. (2) $FN timestamps in the MFT — timestomping tools typically only modify $SI, leaving $FN intact with real creation timestamps. (3) Amcache/BAM — often overlooked by attackers; the SHA-1 hashes for their tools may still be present. (4) The cleanup activity itself — log clearing events, vssadmin processes, secure deletion tools in Amcache — these are a timeline of when the cleanup occurred. (5) Adjacent systems — the attacker may have cleaned the compromised workstation but not the authentication logs on the DC, or the network flow data that shows lateral movement. Build your timeline from these independent sources, acknowledge the gaps explicitly, and note that the gaps themselves are evidence of active evidence destruction. "The attacker's cleanup is itself a data point in establishing the sophistication and intent behind this intrusion."