The Kill Switch Phase: How Attackers Disable EDR—and How to Catch Them in Time

Executive Summary

EDR-disabling toolkits like NtKiller represent a critical pre-attack phase in modern intrusion campaigns. These tools are designed to eliminate endpoint visibility before ransomware deployment, data exfiltration, or persistent backdoor installation.

Unlike signature-based malware, these toolkits are:

  • Modular and customizable
  • Difficult to fingerprint
  • Increasingly commercialized on underground markets
  • Actively adopted by multiple threat actor groups

Key Finding: Detection cannot rely on hash signatures or known samples. Behavioral detection, kernel-level visibility, and rapid response discipline are the only reliable defenses.


Part 1: Threat Landscape & Context

1.1 Why EDR Killers Matter

EDR killers have evolved from specialized APT tools to commodity threats. Recent campaigns show:

  • RansomHub & Qilin: Using EDRKillShifter (Zemana driver exploit) since mid-2024
  • DeadLock Ransomware: Exploiting CVE-2024-51324 (Baidu Antivirus driver)
  • Cuba Ransomware: Early adopter of BYOVD techniques
  • LockBit, Clop, Kasseika: All incorporated BYOVD into kill chains

This indicates attackers view EDR disablement as mandatory, not optional.

1.2 Attack Chain Context

The typical kill chain where NtKiller-like tools appear:

Initial Access (compromised credentials, phishing)
         ↓
Lateral Movement & Reconnaissance
         ↓
[EDR KILLER DEPLOYED HERE] ← YOU ARE HERE (Detection Opportunity)
         ↓
Defense Evasion (disabling services, deleting logs)
         ↓
Ransomware/Backdoor/Data Exfiltration

Critical: Detection at the EDR killer phase provides your last best window before encryption or exfiltration begins.

1.3 Real-World Variants & Indicators

VariantCVE ExploitedDriver AbusedStatusReal-World Use
EDRKillShifterCVE-2019-9725Zemana (zamguard64.sys)ActiveRansomHub, Qilin
TerminatorCVE-2019-9725ZemanaActive2023+ marketplace listings
Killer UltraCVE-2024-1853ZemanaActiveQilin 2024
EDRGay.exe loaderCVE-2024-51324Baidu AntivirusActiveDeadLock 2025
NtKillerUnknownUnknownEmergingUnderground forums

Part 2: Technical Architecture & Attack Mechanics

2.1 BYOVD (Bring Your Own Vulnerable Driver) Overview

EDR killers typically operate via BYOVD, which follows this pattern:

1. Load legitimately-signed driver with kernel vulnerability
   ↓
2. Exploit vulnerability to gain Ring-0 execution
   ↓
3. Use kernel access to:
   - Disable EDR callbacks
   - Terminate EDR processes
   - Interfere with telemetry
   - Hide malicious activity
   ↓
4. Persist via scheduled tasks, services, or registry

Why BYOVD is effective:

  • Signed drivers pass Windows Driver Signature Enforcement (DSE)
  • Vulnerable but legitimate drivers are trusted by the OS
  • Kernel-level access bypasses user-mode protections
  • Can disable defenses before they log the disablement

2.2 NtKiller Suspected Technical Flow

Based on known EDR killer implementations, NtKiller likely operates in multiple stages:

Stage 1: User-Mode Enumeration

# Attacker's likely approach
Get-Service | Where-Object {$_.Name -match "Defender|Sentinel|CrowdStrike|CarbonBlack"}
Get-Process | Where-Object {$_.ProcessName -match "MSSense|csagent|cb"}

Detection Point: Suspicious service/process enumeration followed by termination

Stage 2: Privilege Escalation / UAC Bypass

Methods likely used:

  • Exploiting COM object auto-elevation (e.g., DiskCleanupManager)
  • Scheduled task abuse via AT.EXE or schtasks.exe
  • Token impersonation via Windows API
  • Trusted binaries executed with elevated context

Detection Point: Non-admin process spawning elevated child processes

Stage 3: Kernel Driver Installation

1. Drop vulnerable .sys file → C:\Windows\System32\drivers\
2. Create service entry pointing to driver
3. Configure service with Boot (0) or System (1) start type
4. Trigger driver load via service start or system reboot
5. Exploit driver vulnerability from Ring-0
6. Disable EDR via kernel callbacks or process termination

Detection Point: Suspicious driver file creation + service registration + EDR shutdown

Stage 4: Persistence & Anti-Analysis

  • Scheduled tasks disguised as system maintenance
  • Registry autoruns in Run/RunOnce keys
  • WMI event subscriptions
  • Anti-debugging checks to prevent reverse engineering

Detection Point: Task scheduler events + registry modifications + EDR telemetry loss


Part 3: Indicators of Compromise (IOCs) – Behavioral Focus

3.1 File System Indicators

High-Priority Files to Hunt

Suspicious .sys Driver Creation:

Location: C:\Windows\System32\drivers\
Characteristics:
  - Created within seconds/minutes before EDR stops
  - Filename generic or obfuscated (e.g., "driver.sys", "sys123.sys", random names)
  - File signed by unknown/expected certificate authority
  - File timestamp is recent (not matching OS install date)
  - No associated software installer running
  - Owner/creator process is unusual (Office app, cmd.exe, powershell.exe)

KQL Query for Driver Creation Detection:

DeviceFileEvents
| where FolderPath contains @"Windows\System32\drivers"
  and FileName endswith ".sys"
  and Timestamp > ago(1h)
| where not (InitiatingProcessFileName in ("dism.exe", "svchost.exe", "TrustedInstaller.exe")
  or InitiatingProcessName matches regex @"Windows Update|Microsoft")
| project Timestamp, DeviceName, FileName, FolderPath, 
          InitiatingProcessFileName, InitiatingProcessCommandLine, FileSize
| order by Timestamp desc

Portable Executable Drops in System Directories:

Locations:
  - C:\Windows\Temp\
  - C:\ProgramData\
  - %APPDATA%\Roaming\
  - User Videos/Downloads (non-standard for .sys files)

Registry Indicators

Critical Registry Keys to Monitor:

  1. Service Installation:
Path: HKLM\SYSTEM\CurrentControlSet\Services\
Look for: New keys created with timestamps matching EDR shutdown
Values to check:
  - ImagePath = newly created .sys file
  - Start = 0 (Boot) or 1 (System)
  - Type = 1 (kernel driver)

PowerShell Registry Hunting:

# Find recently added services
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\* | 
  where-object {$_.PSObject.Properties.Count -lt 10} | 
  select PSPath, ImagePath, Start, Type | 
  where-object {$_.Start -in @(0,1) -and $_.ImagePath -match ".sys"}
  1. Scheduled Tasks (Hidden):
Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\
      TaskCache\Tree\
Look for: Tasks created in minute-by-minute proximity to EDR shutdown
Suspicious names: System Maintenance, Windows Update, NVIDIA Driver, etc.
  1. Run/RunOnce Autoruns:
Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
      HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
      HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Look for: Binaries pointing to recently created files or suspicious locations

KQL for Registry Service Modifications:

DeviceRegistryEvents
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
  and (ValueName == "ImagePath" or ValueName == "Start")
| where Timestamp > ago(1h)
| where not (InitiatingProcessFileName in ("WmiPrvSE.exe", "svchost.exe"))
| project Timestamp, DeviceName, RegistryKey, ValueName, PreviousRegistryValueData, RegistryValueData, InitiatingProcessFileName
| order by Timestamp desc

3.2 Process & Command-Line Indicators

Command Execution Patterns

AV/EDR Service Termination (Critical Detection):

# Direct service stop attempts
sc stop <EDR_SERVICE>
net stop <EDR_SERVICE>

# PowerShell methods
Stop-Service -Name <EDR_SERVICE> -Force
Set-Service -Name <EDR_SERVICE> -StartupType Disabled

# Force kill EDR processes
taskkill /F /IM <edr_process.exe>
wmic process where name="<edr_process.exe>" call terminate

Common EDR Services to Monitor:

Crowdstrike: CsSensor, CSFalconService
Microsoft Defender: WinDefend, Sense
SentinelOne: SentinelAgent
Cybereason: CybereasonService
Trend Micro: TmCCSF, NTRTScan
Carbon Black: CBDefense, CbClientService

KQL for Service Termination Commands:

DeviceProcessEvents
| where ProcessCommandLine matches regex @"(sc\s+stop|net\s+stop|taskkill|Stop-Service|wmic.*terminate)"
  and ProcessCommandLine matches regex @"(CsSensor|WinDefend|Sense|SentinelAgent|TMCCSf|CBDefense)"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessName, AccountName
| where Timestamp > ago(1h)

Suspicious Process Chain Indicators

Red Flag Sequence #1: Office Spawning Service Control

DETECTION:
  ParentProcess: winword.exe | excel.exe | powerpnt.exe
    ↓ spawns
  ChildProcess: cmd.exe OR powershell.exe
    ↓ spawns
  GrandchildProcess: sc.exe OR taskkill.exe OR net.exe
  ↓
  Action: Service stop targeting security product

Red Flag Sequence #2: Script Host Targeting Kernel

DETECTION:
  ParentProcess: wscript.exe | cscript.exe
    ↓ spawns
  ChildProcess: powershell.exe
    ↓ attempts
  Registry modification + Driver installation + System reboot

Red Flag Sequence #3: Installer Disabling Defenses (Risky but Seen)

DETECTION:
  Process: msiexec.exe OR custom installer
    ↓ spawns
  Command execution: Set-MpPreference -DisableRealtimeMonitoring $true
    ↓ followed by
  Unexpected .sys file creation
    ↓
  EDR process termination

KQL for Suspicious Process Chains:

let EDRServices = dynamic(["CsSensor", "WinDefend", "Sense", "SentinelAgent", "TMCCSf", "CBDefense"]);
let SuspiciousParents = dynamic(["winword.exe", "excel.exe", "powerpnt.exe", "wscript.exe", "cscript.exe"]);
DeviceProcessEvents
| where InitiatingProcessFileName in (SuspiciousParents)
| where ProcessName in ("cmd.exe", "powershell.exe", "sc.exe", "taskkill.exe")
| where ProcessCommandLine matches regex @"(stop|terminate|disable|kill)"
| where ProcessCommandLine matches regex @"(CsSensor|WinDefend|Sense|SentinelAgent|TMCCSf|CBDefense)"
| summarize Count=count() by DeviceName, InitiatingProcessFileName, ProcessCommandLine
| where Count > 0

3.3 EDR/AV Telemetry Indicators

Telemetry Loss Patterns

Critical Indicators (Highest Confidence):

  1. Agent/Sensor Process Termination
    • Unexpected exit from EDR agent process
    • Loss of endpoint heartbeat in EDR console
    • Process termination logged by EDR itself (before it dies)
  2. Service Stop Events
    • Event ID 7040: Service start type changed (to Disabled)
    • Event ID 7034: Service crashed unexpectedly
    • Event ID 7026: Boot time driver could not be loaded
  3. Sudden Loss of Endpoint Telemetry
    • No alerts/heartbeats from device > 5 minutes (highly suspicious)
    • Last telemetry timestamp followed by silence
    • No subsequent process creation events
    • No network connections from device

Windows Event Log IOCs:

Event ID 7040 (Service Control Manager):
  - Service: Security product (Defender, CrowdStrike, etc.)
  - Start Type changed to: Disabled (4)
  - Triggered by: Unusual process or System account

Event ID 1022 (Application):
  - Description: EDR Agent Error or Unexpected Shutdown
  - Process: EDR agent executable

Event ID 104 (System):
  - Log: Security
  - Action: Event log cleared (strong indicator of post-exploitation)

KQL for Telemetry Loss Detection:

// Detect loss of heartbeat
DeviceInfo
| where Timestamp > ago(1h)
| summarize LastHeartbeat = max(Timestamp) by DeviceName
| where (now() - LastHeartbeat) > 5m  // No heartbeat in 5+ minutes
| join (
    DeviceProcessEvents
    | where Timestamp > ago(1h)
    | where ProcessCommandLine matches regex @"(sc stop|taskkill|Stop-Service)"
    | distinct DeviceName
) on DeviceName

3.4 Kernel & Driver-Level Indicators

Driver Load Events

Monitor Unexpected Driver Loads:

Event Source: System Event Log
Event ID: 219 (loaded driver)
Event ID: 20001 (HIPS - driver activity)

Suspicious indicators:
  - Driver loaded from unusual path (not System32\drivers)
  - Driver loaded immediately after .sys file creation
  - Driver load followed immediately by EDR process termination
  - Signed driver not in known driver whitelist
  - Driver certificate doesn't match known vendor
  - WHQL signed but unexpected (legitimate but odd)

Known Vulnerable Drivers (Track These):

CVE-2024-51324: Baidu Antivirus (BdApiUtil.sys) - ACTIVE THREAT
CVE-2024-1853:  Zemana Anti-Keylogger driver - ACTIVE THREAT
CVE-2025-8061:  Lenovo MSR IO driver (LnvMSRIO.sys) - NEW
CVE-2025-0289:  Paragon Partition Manager (BioNTdrv.sys) - NEW
CVE-2019-9725:  MSI Board drivers (gdrv.sys, asWarPot.sys) - LEGACY

MAINTAIN BLOCKLIST: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules

KQL for Suspicious Driver Load Patterns:

DeviceDriverLoadEvents
| where Timestamp > ago(1h)
| where not (FolderPath contains @"Windows\System32\drivers"
  or SignatureState == "Valid"
  or SignedBy has_cs ("Microsoft"))
| project Timestamp, DeviceName, DriverName, FolderPath, SignedBy, Signer
| order by Timestamp desc

Part 4: Detection Rules & Queries

4.1 High-Confidence Multi-Signal Detection

RULE #1: EDR Disablement Pattern (CRITICAL)

Trigger Conditions (ALL must occur within 15 minutes):

  1. Security service or process termination detected
  2. New .sys file creation in System32\drivers
  3. New service registry key with Boot/System start type
  4. EDR/Antivirus heartbeat loss
  5. Suspicious parent process (admin tool, Office, script host)

Logic:

let TimeWindow = 15m;
let EDRKillerPattern = 
DeviceProcessEvents
| where Timestamp > ago(TimeWindow)
| where ProcessCommandLine matches regex @"(sc\s+stop|taskkill|Stop-Service)"
  and ProcessCommandLine matches regex @"(WinDefend|CsSensor|Sense|SentinelAgent)"
| join kind=inner (
    DeviceFileEvents
    | where Timestamp > ago(TimeWindow)
    | where FolderPath contains @"System32\drivers" and FileName endswith ".sys"
) on DeviceName
| join kind=inner (
    DeviceRegistryEvents
    | where Timestamp > ago(TimeWindow)
    | where RegistryKey contains "Services"
      and ValueName in ("ImagePath", "Start")
) on DeviceName
| project DeviceName, Timestamp, ProcessCommandLine, FileName, RegistryKey
| summarize AlertCount=count() by DeviceName
| where AlertCount >= 2;
EDRKillerPattern

Alert Severity: CRITICAL (P1)
Response Time: Immediate (<5 min)
Action: Isolate endpoint, preserve memory dump, escalate to IR team


RULE #2: BYOVD Service Registration Pattern

Trigger Conditions:

  1. New service created with kernel driver type
  2. Start type = 0 (Boot) or 1 (System)
  3. ImagePath points to recently created unsigned driver
  4. Service creation timestamp overlaps with suspicious process execution
DeviceRegistryEvents
| where Timestamp > ago(1h)
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
| where ValueName == "ImagePath" and RegistryValueData endswith ".sys"
| where not (RegistryValueData contains @"Windows\System32\drivers")
| join kind=inner (
    DeviceFileEvents
    | where FileName endswith ".sys"
    | where Timestamp > ago(1h)
) on DeviceName
| project Timestamp, DeviceName, RegistryKey, RegistryValueData, FileName, InitiatingProcessFileName

Alert Severity: CRITICAL (P1)
Response Time: Immediate


RULE #3: Unsigned/Unexpected Driver Load

Trigger Conditions:

DeviceDriverLoadEvents
| where Timestamp > ago(1h)
| where (SignedBy !contains "Microsoft" 
  or SignedBy has_cs ("Unknown")
  or not FolderPath contains @"System32\drivers")
| where not (DriverName in 
  ("nvlddmkm.sys", "amdkmpfd.sys", "igdkmd64.sys"))  // Known legit drivers
| project Timestamp, DeviceName, DriverName, FolderPath, SignedBy

Alert Severity: HIGH (P2)
Response Time: Within 30 min


4.2 Medium-Confidence Detection Rules

RULE #4: Service Control/Process Termination (Service Isolation)

Standalone (lower confidence but fast):

DeviceProcessEvents
| where Timestamp > ago(15m)
| where ProcessCommandLine matches regex @"(sc\s+stop|taskkill\s+/F|net\s+stop)"
| where ProcessCommandLine matches regex @"(WinDefend|CsSensor|Sense|SentinelAgent|TMCCSf|CBDefense|MbaeSvc)"
| where not (AccountName contains "SYSTEM"
  or InitiatingProcessFileName in ("winlogon.exe", "services.exe"))
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName

Alert Severity: MEDIUM-HIGH (P2)
Response Time: Within 1 hour
Note: Can have false positives from legitimate admin activity; correlate with other signals


RULE #5: Scheduled Task Targeting Security Tools

DeviceEvents
| where ActionType == "ScheduledTaskCreated"
| where parse_json(AdditionalFields).TaskPath contains "Security"
  or parse_json(AdditionalFields).TaskCommand matches regex @"(taskkill|sc\s+stop|Stop-Service)"
| project Timestamp, DeviceName, parse_json(AdditionalFields).TaskPath, 
          parse_json(AdditionalFields).TaskCommand, InitiatingProcessFileName

Alert Severity: MEDIUM (P2)
Response Time: Within 2 hours


RULE #6: Suspicious UAC Bypass Patterns

DeviceProcessEvents
| where Timestamp > ago(30m)
| where InitiatingProcessCommandLine matches regex @"(CoGetObject|CreateObject.*WinRar|fodhelper)"
  or (ProcessCommandLine matches regex @"UAC|elevation"
    and not InitiatingProcessName == "svchost.exe")
| where ProcessName in ("cmd.exe", "powershell.exe")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine

Alert Severity: MEDIUM (P2)
Response Time: Within 2 hours


4.3 Low-Confidence but Useful Behavioral Rules

RULE #7: Suspicious PowerShell AV Disablement

# Example command attackers might execute
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
Remove-MpPreference -ExclusionPath

KQL Detection:

DeviceProcessEvents
| where ProcessCommandLine matches regex @"Set-MpPreference|Remove-MpPreference"
  and ProcessCommandLine matches regex @"(DisableRealtimeMonitoring|DisableBehaviorMonitoring|ExclusionPath)"
| where not (InitiatingProcessName in ("SecurityHealthService", "WmiPrvSE.exe"))
| project Timestamp, DeviceName, ProcessCommandLine

Alert Severity: MEDIUM (P3)
Response Time: Within 4 hours
Context: Often used as persistence mechanism post-exploit, not pre-exploit


Part 5: Threat Hunting Playbook

5.1 Proactive Threat Hunt #1: “Driver Baseline Deviation”

Objective: Find unexpected kernel drivers loaded on systems

Frequency: Weekly or after suspicious alert

Steps:

  1. Export Driver Baseline:
# On clean reference system
Get-WmiObject Win32_SystemDriver | 
  Where-Object {$_.State -eq "Running"} | 
  Select-Object Name, DisplayName, PathName | 
  Export-Csv -Path "C:\driver_baseline.csv"
  1. Check Live Systems:
# On target systems
$baseline = Import-Csv "C:\driver_baseline.csv"
$current = Get-WmiObject Win32_SystemDriver | 
  Where-Object {$_.State -eq "Running"}

$current | Where-Object {$_.Name -notin $baseline.Name} | 
  Select-Object Name, DisplayName, PathName
  1. Investigate Unknown Drivers:
# For each unknown driver
Get-Item "Path\to\driver.sys" -Force | 
  Select-Object FullName, CreationTime, LastWriteTime, Attributes
Get-AuthenticodeSignature "Path\to\driver.sys"

Expected Output: List of running drivers not in baseline + their signatures

High-Risk Findings:

  • Recently created drivers (< 7 days old)
  • Unsigned drivers
  • Drivers from unexpected vendors
  • Drivers in non-standard paths

5.2 Proactive Threat Hunt #2: “Service Anomaly Detection”

Objective: Find unexpected Windows services with suspicious configurations

Frequency: Bi-weekly

Steps:

  1. Query Anomalous Services:
Get-Service | 
  Where-Object {
    ($_.StartType -in @("Automatic", "Boot", "System")) -and
    ($_.Status -eq "Running") -and
    ($_.Name -notin @("WinDefend", "Sense", "ShellHWDetection", "sppsvc"))
  } | 
  ForEach-Object {
    $service = $_
    $key = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\$($service.Name)"
    if ($key.ImagePath -like "*.sys" -and $key.ImagePath -notlike "*System32*") {
      Write-Host "ALERT: Suspicious service $($service.Name) -> $($key.ImagePath)"
    }
  }
  1. Check Service File Timestamps:
foreach ($service in Get-Service) {
  $imagePath = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\$($service.Name)" -ErrorAction SilentlyContinue).ImagePath
  if ($imagePath) {
    $file = $imagePath.Split('"')[0].Trim()
    if (Test-Path $file) {
      $age = (Get-Date) - (Get-Item $file).CreationTime
      if ($age.Days -lt 30) {
        Write-Host "ALERT: Recent service file: $file (Age: $($age.Days) days)"
      }
    }
  }
}
  1. Correlate with Registry Modifications:
# Check registry modification times
$regKey = Get-Item "HKLM:\SYSTEM\CurrentControlSet\Services\<SuspiciousService>"
"Service $($regKey.Name) last modified: " + $regKey.PSChildName

High-Risk Findings:

  • Services with Boot/System start type + .sys files
  • Recently created services
  • Services pointing to non-standard paths
  • Services with suspicious names (generic, obfuscated)

5.3 Proactive Threat Hunt #3: “Parent-Child Process Anomalies”

Objective: Identify suspicious process spawning relationships targeting security products

Frequency: Weekly

Steps:

  1. Hunt for Unusual Parents of sc.exe:
DeviceProcessEvents
| where ProcessName == "sc.exe"
  and Timestamp > ago(7d)
| distinct InitiatingProcessName, InitiatingProcessCommandLine
| where InitiatingProcessName !in ("cmd.exe", "powershell.exe", "services.exe", "svchost.exe", "explorer.exe")
  1. Hunt for Office Apps Spawning Service Tools:
DeviceProcessEvents
| where InitiatingProcessFileName in ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| where ProcessName in ("cmd.exe", "powershell.exe", "sc.exe", "taskkill.exe", "net.exe")
| where Timestamp > ago(7d)
  1. Hunt for Script Hosts Modifying System:
DeviceProcessEvents
| where InitiatingProcessFileName in ("wscript.exe", "cscript.exe")
| where ProcessCommandLine contains @"System32\drivers"
  or ProcessCommandLine contains "Start=0"
  or ProcessCommandLine contains "taskkill"
| where Timestamp > ago(7d)

High-Risk Findings:

  • Any unexpected parent of sc.exe, taskkill.exe, net.exe
  • Office applications spawning system administration tools
  • Script hosts with kernel-level access attempts

5.4 Proactive Threat Hunt #4: “EDR Beacon Loss Analysis”

Objective: Find endpoints that had sudden communication loss with EDR platform

Frequency: Daily (automated)

Steps:

  1. Query EDR Console for Offline Devices:
Filter: Device Status = Offline, Last Seen > 1 hour ago, Last Seen < 24 hours ago
Sort by: Time since last heartbeat (most recent first)
Export: List of affected devices
  1. Cross-Reference with Process Events:
let OfflineDevices = externaldata(DeviceName: string) 
  [@"https://your-edr-export/offline_devices.csv"] 
  with (format="csv");
OfflineDevices
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(24h)
    | where ProcessCommandLine matches regex @"(sc\s+stop|taskkill|Stop-Service)"
) on DeviceName
| project DeviceName, Timestamp, ProcessCommandLine
  1. Check for Log Deletion Events:
let OfflineDevices = /* list of offline devices */;
SecurityEvent
| where Computer in (OfflineDevices)
| where EventID == 1102  // Event log cleared
| where Timestamp > ago(24h)

High-Risk Findings:

  • Endpoints offline immediately after service termination commands
  • Log deletion events preceding beacon loss
  • Multiple endpoints going offline at same time (coordinated attack)

Part 6: Incident Response Procedures

6.1 Immediate Actions (First 5 Minutes)

Upon Detection of EDR-Killer Activity:

  1. DO NOT Attempt Live Remediation First
    • Malware may delete evidence
    • Kernel compromise is permanent in current session
    • Restart/reboot will undo manual fixes
  2. Isolate Endpoint Immediately:
# Disconnect from network (if possible remotely)
Disable-NetAdapter -InterfaceAlias "Ethernet" -Confirm:$false

# Or via Group Policy / network segmentation
# Ensure endpoint can't reach C2, Internet, or other internal hosts
  1. Preserve Volatile Evidence:
# Run memory capture (if EDR still accessible)
& "C:\Program Files\CrowdStrike\tools\dump-memory.exe"  # Example

# Or use 3rd party tool
& "C:\Tools\DumpIt.exe" -o C:\memdump.raw
  1. Document Initial Findings:
  • Time of first detection
  • Compromised user account
  • Source of initial access (if known)
  • Systems potentially lateral-moved to
  • Last EDR/security tool heartbeat timestamp

6.2 Investigation Phase (5-30 Minutes)

Parallel Tasks:

Task 1: Prevent Lateral Movement

# Identify compromised user
$user = "domain\username"

# Force logout across domain
Get-ADUser -Identity $user | 
  ForEach-Object {
    Get-ADComputer -Filter "LoggedOnUser -eq $_" | 
    ForEach-Object { Invoke-GPUpdate -Computer $_.DNSHostName -Force }
  }

# Reset credentials
Reset-ADUserPassword -Identity $user -NewPassword (ConvertTo-SecureString "TempPassword123!" -AsPlainText -Force)

Task 2: Preserve Logs and Evidence

# From isolated system (if accessible):
# 1. Export Windows Event Logs
wevtutil epl System C:\System_Log.evtx /overwrite:true
wevtutil epl Security C:\Security_Log.evtx /overwrite:true
wevtutil epl Application C:\Application_Log.evtx /overwrite:true

# 2. Export registry hives
reg save HKLM\SYSTEM C:\SYSTEM_hive
reg save HKLM\HARDWARE C:\HARDWARE_hive
reg save HKLM\SOFTWARE C:\SOFTWARE_hive

# 3. Dump service configurations
sc query type=driver > C:\drivers_config.txt

Task 3: Identify Scope of Compromise

Questions to answer:
1. How many endpoints affected?
2. What user accounts compromised?
3. What systems did attacker lateral move to?
4. When did attack begin (first EDR kill vs. first compromise)?
5. What is attacker's presumed goal (ransomware, espionage, persistence)?

6.3 Remediation Phase (30 Min – 4 Hours)

Rebuild Affected Endpoints:

1. Isolate endpoint from network
2. Boot to clean Windows installation media
3. Backup user data (if needed) to isolated drive
4. Perform clean Windows installation
5. Restore from known-good backup (if available)
6. Install latest patches + EDR agent
7. Restart and verify EDR connectivity
8. Restore user data from isolated backup
9. Return to network

Why Full Rebuild?

  • Kernel compromise means system cannot be trusted
  • Malware may have modified boot sector, MBR, UEFI
  • Partial remediation will miss persistent mechanisms
  • Cost of rebuild < cost of re-compromise

Do NOT attempt:

  • Deleting suspicious drivers while system running (won’t work, needs reboot)
  • Re-enabling EDR and hoping it detects malware (already disabled for reason)
  • Patching underlying vulnerability (new one probably already exploited)

6.4 Forensic Analysis (Parallel to Remediation)

Evidence to Collect:

  1. Memory Dump:
    • Volatility analysis for hidden processes
    • Rootkit detection
    • Network connections at time of compromise
  2. Disk Analysis: # Using Autopsy/EnCase or open-source tools # Timeline analysis of: # - .sys file creation # - Service registry modifications # - Scheduled task creation # - File access patterns
  3. Network Artifacts:
    • NetFlow logs during attack window
    • Firewall logs for C2 communication
    • DNS requests from compromised endpoint
    • Lateral movement traffic patterns
  4. Windows Event Logs:
    • Event ID 7040 (service start type changes)
    • Event ID 1102 (log clearing)
    • Event ID 4688 (process creation)
    • Sysmon (if installed)

Part 7: Defensive Posture Hardening

7.1 Preventive Controls

Mandatory Controls:

  1. Enable Virtualization-Based Security (VBS) + HVCI:
# Enable with PowerShell
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 1 /f

# Verify
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Impact: Prevents unsigned or modified kernel code execution; blocks most BYOVD attacks
Performance Impact: 5-15% on older systems; negligible on modern CPUs (Intel Kaby Lake+, AMD Zen 2+)

  1. Enable Secure Boot + DMA Protection:
Firmware Configuration (UEFI):
  - Secure Boot: Enabled
  - Boot DMA Protection: Enabled (if available)
  - UEFI Secure Boot Keys: Microsoft + OEM signed only

Impact: Prevents bootkit/rootkit installation before OS loads

  1. Implement Kernel Driver Enforcement:
# Use Windows Defender Application Control (WDAC)
# Block known vulnerable drivers proactively
$driverBlocklist = Get-Content "https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules"
# Apply via Group Policy

Impact: Blocks exploitation of known vulnerable drivers before they’re exploited

  1. Enable EDR Tamper Protection + Lock Down Admin Privileges:
EDR Console:
  - Tamper Protection: Enabled & Locked
  - Admin Override: Disabled or require MFA
  - Delete Protection: Enabled
  - Service Disable: Prevent via Group Policy (if possible)

Strongly Recommended Controls:

  1. Restrict Local Administrator Rights:
Group Policy:
  - User Rights Assignment: Deny local admin to non-IT staff
  - Services: Set EDR services to "Local System" with no stop permissions
  - Elevation: Disable UAC bypass vulnerabilities via patches
  1. Enable Audit Policy:
auditpol /set /category:* /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
auditpol /set /subcategory:"Registry" /success:enable /failure:enable
  1. Deploy Sysmon for Detailed Logging:
<!-- Monitor driver loads, service creation, process execution -->
<!-- Sysmon config: https://github.com/SwiftOnSecurity/sysmon-config -->
<Sysmon schemaversion="4.30">
  <EventFiltering>
    <RuleGroup name="" groupRelation="or">
      <!-- Log all driver creation -->
      <DriverLoad onmatch="include">
        <ImageLoaded condition="contains">drivers</ImageLoaded>
      </DriverLoad>
      <!-- Log all registry access to Services -->
      <RegistryEvent onmatch="include">
        <TargetObject name="Services" condition="contains">Services</TargetObject>
      </RegistryEvent>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

7.2 Detection-Level Controls

SIEM Tuning:

  1. Create Alert on Multiple Suspicious Signals:
    • Severity: CRITICAL if 3+ signals in 5 minutes
    • Severity: HIGH if 2 signals in 15 minutes
    • Severity: MEDIUM if any single signal in isolation
  2. Create Baseline of “Normal” Service Activity:
    • Services that NEVER change start type
    • Services that NEVER get terminated
    • Services that NEVER receive admin commands
    • Deviations = Alert
  3. Centralize Logging:
    • Ensure all endpoints send logs to central SIEM
    • Attackers cannot delete local logs if they can’t reach collector
    • Use log forwarding that cannot be disabled by user-mode malware
  4. Enable Immutable Logging (if available):
    • Azure Sentinel: Diagnostic Setting with retention lock
    • Splunk: Index with frozen buckets
    • Prevents log tampering post-compromise

7.3 Operational Controls

  1. Incident Response Plan (Have It Documented):
    • Who to contact on detection
    • Decision tree: rebuild vs. remediate
    • Communication plan (IR team, management, affected teams)
    • Timeline/SLA for each phase
  2. Regular Threat Hunting Schedule:
    • Weekly: Driver anomalies
    • Weekly: Parent-child process anomalies
    • Daily: EDR beacon loss analysis
    • Monthly: Full service baseline re-baseline
  3. Backup & Recovery Strategy:
    • Offline backups disconnected from network
    • Test restore regularly
    • Immutable backup retention (30+ days)
    • Separate backup credentials from admin creds

Part 8: Threat Intelligence Integration

8.1 Monitored Intelligence Feeds

Subscribe to these threat intelligence sources:

  1. Microsoft Driver Blocklist:
    • https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules
    • Update frequency: Monthly
    • Action: Add new CVEs to blocklist immediately
  2. CISA Alerts:
    • https://www.cisa.gov/alerts
    • Search: “EDR”, “ransomware”, “BYOVD”
    • Subscribe to advisories
  3. Security Research Blogs:
    • Sophos Labs (EDR bypass research)
    • Cisco Talos (vulnerable driver analysis)
    • Elastic Security Labs (EDR killer campaigns)
    • SANS Internet Storm Center (daily logs)
  4. Ransomware-Specific Intel:
    • Ransomware advisory boards (LockBit, Qilin, DeadLock, etc.)
    • Victim leak site monitoring
    • Attack pattern tracking

8.2 Correlation with Known Campaigns

Known EDR Killer Usage:

Group/CampaignToolTarget EDRStatusDetection Window
RansomHubEDRKillShifterCrowdStrike, Microsoft DefenderActive1-5 minutes
QilinKiller UltraZemana, Microsoft DefenderActive1-5 minutes
DeadLockEDRGay.exeGeneric EDR targetsActiveSeconds
CubaBYOVD (custom)MultipleHistoric2-10 minutes
BlackByteEDR bypass (custom)Sophos, OthersHistoricMinutes

Attack Pattern: All known campaigns follow same sequence:

  1. Initial access (credentials, phishing, exploit)
  2. Lateral movement to priv level > 0
  3. Enumerate running security services
  4. Deploy and execute EDR killer
  5. Disable security services
  6. Deploy payload (ransomware, backdoor, etc.)

Part 9: Checklist & Quick Reference

9.1 Pre-Incident Checklist

  • [ ] EDR agents deployed to all Windows endpoints
  • [ ] EDR tamper protection enabled globally
  • [ ] VBS + HVCI enabled on all compatible systems
  • [ ] Secure Boot enabled + DMA protection (where available)
  • [ ] Driver blocklist applied via WDAC / Group Policy
  • [ ] Sysmon deployed for detailed monitoring
  • [ ] SIEM configured with critical driver/service alerts
  • [ ] Baseline of normal driver loads documented
  • [ ] Baseline of normal service configurations documented
  • [ ] Offline backups verified (30+ day retention)
  • [ ] IR playbook documented and distributed
  • [ ] IR contacts defined (escalation path clear)

9.2 Incident Detection Checklist

If Any of These Triggers, Escalate Immediately:

  • [ ] Service stop command targeting AV/EDR
  • [ ] .sys file creation in System32\drivers within 10 min of service stop
  • [ ] New service with Boot/System start type + kernel driver
  • [ ] EDR agent offline for > 5 minutes after suspicious activity
  • [ ] Unsigned/unexpected driver load detected
  • [ ] PowerShell Set-MpPreference commands disabling Defender
  • [ ] Process from Office/script host spawning sc.exe or taskkill.exe
  • [ ] Event log clearing (Event ID 1102) during work hours
  • [ ] Multiple endpoints offline simultaneously
  • [ ] Loss of SIEM heartbeat from endpoint cluster

9.3 First Response Checklist (0-5 Minutes)

  • [ ] Alert received and severity confirmed
  • [ ] Incident responder assigned
  • [ ] Endpoint isolated from network
  • [ ] Memory dump initiated (if possible)
  • [ ] EDR logs exported (before agent shutdown)
  • [ ] Team lead notified (escalation started)
  • [ ] Incident ticket created
  • [ ] Preliminary scope assessment (how many endpoints affected?)

9.4 Investigation Checklist (5-30 Minutes)

  • [ ] Windows Event Logs collected (System, Security, Application)
  • [ ] Registry hives exported (SYSTEM, SOFTWARE, SECURITY)
  • [ ] Service configurations documented
  • [ ] Driver files identified and preserved
  • [ ] Compromised user account identified
  • [ ] Lateral movement paths analyzed (via EDR logs)
  • [ ] C2 communication (if any) identified
  • [ ] Timeline of attack reconstructed
  • [ ] Other potentially compromised endpoints identified

9.5 Recovery Checklist (30 Min – 4 Hours)

  • [ ] Rebuild plan approved by change control
  • [ ] Backup isolated/verified as clean
  • [ ] Clean Windows media prepared
  • [ ] Latest patches available
  • [ ] EDR agent installer ready + pre-configured
  • [ ] Endpoint rebuilt + patches applied
  • [ ] EDR agent installed + verified connectivity
  • [ ] User data restored (from isolated backup)
  • [ ] Endpoint returned to network
  • [ ] User credentials reset/changed
  • [ ] Verification that EDR is operational + collecting logs

Part 10: Lessons Learned & Future Outlook

10.1 Key Takeaways

  1. Signature Detection is Insufficient:
    • EDR killers evolve faster than signatures
    • Behavioral detection is mandatory
    • Response speed matters more than detection perfection
  2. Kernel Compromise is Terminal:
    • System cannot be trusted after kernel exploit
    • Rebuild, don’t remediate
    • Prevention (VBS/HVCI) is better than detection
  3. Centralized Logging Saves Lives:
    • Attacker cannot blind central SIEM
    • Offline backups provide audit trail
    • Logging is prerequisite to detection
  4. Speed Matters:
    • 5-minute detection window
    • Automated isolation + memory capture critical
    • Manual response = too slow

10.2 Emerging Threats

Monitor for evolution of EDR killers:

  1. EDR-Freeze-like techniques (September 2025)
    • Uses Windows Error Reporting + MiniDumpWriteDump
    • Suspends AV/EDR processes instead of terminating
    • User-mode only (no driver needed)
    • Harder to detect (process still running)
  2. HVCI/VBS Bypass Attempts
    • SafeBreach research (2024-2025) shows VBS can be disabled
    • Requires elevated privileges + specific Windows version
    • Monitor for: VBS disablement attempts, ci.dll modification
  3. Firmware-Level Attacks
    • UEFI rootkits (emerging, not yet mainstream)
    • DMA attacks bypassing OS protections
    • Requires physical access (currently)
  4. Gaming Driver Exploitation
    • Vulnerabilities in GPU drivers (NVIDIA, AMD, Intel)
    • Popular among threat actors (legitimate + widely deployed)
    • Example: GHOSTENGINE campaign using GPU drivers

10.3 Recommended Future Posture

  • Year 1 (Now): Implement all controls in Section 7.1 (VBS, Secure Boot, WDAC)
  • Year 2: Deploy EDR with kernel-level callback monitoring
  • Year 3: Evaluate firmware security (fTPM, Secure Boot + Mandatory flag)
  • Ongoing: Monthly threat intelligence updates + quarterly threat hunting exercises

Tool References

1 Detection & Hunting Tools

ToolPurposeCostRecommendation
Splunk EnterpriseSIEM + hunting platformCommercialEnterprise standard; excellent for KQL adaptation
Microsoft SentinelAzure-native SIEMCommercialGood for Microsoft-centric orgs; native EDR integration
osqueryEndpoint query toolOpen sourceLightweight; good for distributed hunting
SysmonDetailed process/registry loggingFree (Microsoft)Mandatory; unmatched visibility
VelociraptorEndpoint responderFree + commercialGood for live response + evidence collection
KAPEAutomated forensic collectionFreeFast evidence collection at scale
Volatility 3Memory forensicsOpen sourceAnalysis of memory dumps for rootkits
AutopsyDisk image forensicsFree + commercialTimeline + artifact analysis
WinAuditBeatWindows log forwarderFreeSecure log forwarding to SIEM
DumpItMemory captureCommercialFast, reliable memory dumps

2 Hardening Tools

ToolPurposeCost
Group Policy Editor (gpedit.msc)Configure security baselinesFree (Windows)
DISA STIGsHardening baselinesFree (DoD)
Harden Windows SecurityGUI hardening toolFree (GitHub)
Microsoft Endpoint ManagerCentralized device managementCommercial
ConfigMgr (SCCM)Large-scale OS deployment + patchingCommercial
Windows Defender Application Control (WDAC)Application + driver controlFree (Windows)
BitlockerFull-disk encryptionFree (Windows Pro/Enterprise)

3 Documentation & Baselines

  • Microsoft Recommended Driver Block List: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules
  • NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
  • Mitre ATT&CK (EDR Disablement): https://attack.mitre.org/techniques/T1562/001/
  • DISA Windows 11 STIG: https://dl.dod.cyber.mil/articles/windows/
  • Sysmon Config (SwiftOnSecurity): https://github.com/SwiftOnSecurity/sysmon-config

Sample KQL Queries

1 Complete Multi-Signal Detection Query

// === EDR KILLER DETECTION: Multi-Signal Correlation ===
// Purpose: Detect coordinated EDR disablement attempt
// Adjust TimeWindow to match your organization's response time (default 15min)

let TimeWindow = 15m;
let EDRServices = dynamic(["CsSensor", "WinDefend", "Sense", "SentinelAgent", "TMCCSf", "CBDefense", "MbaeSvc"]);
let HighRiskProcesses = dynamic(["cmd.exe", "powershell.exe", "sc.exe", "taskkill.exe", "net.exe"]);

let ServiceTermination = DeviceProcessEvents
  | where Timestamp > ago(TimeWindow)
  | where ProcessName in (HighRiskProcesses)
    and ProcessCommandLine matches regex @"(stop|terminate|disable|kill)"
    and ProcessCommandLine matches regex @"(CsSensor|WinDefend|Sense|SentinelAgent|TMCCSf|CBDefense)"
  | project DeviceName, Timestamp as ServiceStopTime, ProcessCommandLine, ProcessName, AccountName;

let DriverCreation = DeviceFileEvents
  | where Timestamp > ago(TimeWindow)
  | where FolderPath contains @"Windows\System32\drivers"
    and FileName endswith ".sys"
  | project DeviceName, Timestamp as DriverCreateTime, FileName, FileSize;

let ServiceRegistration = DeviceRegistryEvents
  | where Timestamp > ago(TimeWindow)
  | where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
    and (ValueName in ("ImagePath", "Start"))
  | where RegistryValueData endswith ".sys" or RegistryValueData == "0"
  | project DeviceName, Timestamp as ServiceRegTime, RegistryKey, ValueName, RegistryValueData;

// Correlate all three signals
ServiceTermination
  | join kind=inner DriverCreation on DeviceName
  | join kind=inner ServiceRegistration on DeviceName
  | where (DriverCreateTime - ServiceStopTime) between (-2m to 2m)
    and (ServiceRegTime - ServiceStopTime) between (-2m to 2m)
  | project DeviceName, ServiceStopTime, DriverCreateTime, ServiceRegTime, 
            ProcessCommandLine, FileName, RegistryKey
  | extend AlertSeverity = "CRITICAL", AlertName = "EDR Killer Pattern Detected"

2 Isolated Driver Load Detection

// === SUSPICIOUS DRIVER LOAD ===
DeviceDriverLoadEvents
  | where Timestamp > ago(24h)
  | where (
      (SignedBy !contains "Microsoft" and SignedBy !contains "Intel" and SignedBy !contains "NVIDIA" and SignedBy !contains "AMD")
      or SignedBy has_cs ("Unknown")
      or isempty(SignedBy)
    )
  | where not (
      DriverName in ("nvlddmkm.sys", "amdkmpfd.sys", "igdkmd64.sys", "atikmpag.sys")
      or FolderPath contains "Windows\System32\drivers"
    )
  | project Timestamp, DeviceName, DriverName, FolderPath, SignedBy, InitiatingProcessFileName
  | order by Timestamp desc

3 EDR Heartbeat Loss Correlation

// === EDR HEARTBEAT LOSS DETECTION ===
// Assumes table: DeviceInfo (contains device status + last heartbeat)
// Adjust frequency thresholds to match your EDR's normal heartbeat interval

let TimeWindow = 10m;
let HeartbeatThreshold = 5m;  // Alert if no heartbeat for 5+ minutes

let OfflineDevices = DeviceInfo
  | where Timestamp > ago(TimeWindow)
  | summarize LastHeartbeat = max(Timestamp) by DeviceName
  | where (now() - LastHeartbeat) > HeartbeatThreshold;

// Cross-reference with recent security product termination attempts
OfflineDevices
  | join kind=inner (
      DeviceProcessEvents
      | where Timestamp > ago(TimeWindow)
      | where ProcessCommandLine matches regex @"(sc\s+stop|taskkill|Stop-Service)"
        and ProcessCommandLine matches regex @"(WinDefend|CsSensor|Sense|SentinelAgent)"
    ) on DeviceName
  | project DeviceName, LastHeartbeat, Timestamp as ActivityTime, ProcessCommandLine
  | extend MinsOffline = datetime_diff('minute', now(), LastHeartbeat)

4 Suspicious Service Creation Pattern

// === NEW SERVICE WITH SUSPICIOUS CHARACTERISTICS ===
DeviceRegistryEvents
  | where Timestamp > ago(7d)
  | where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
  | where ValueName in ("ImagePath", "Type", "Start")
  | summarize 
      Types = makeset(RegistryValueData),
      AllValues = make_bag(pack(ValueName, RegistryValueData)),
      FirstSeen = min(Timestamp)
      by DeviceName, RegistryKey
  | where AllValues["Type"] == "1"  // Kernel driver
    and AllValues["Start"] in ("0", "1")  // Boot or System
    and AllValues["ImagePath"] endswith ".sys"
    and (now() - FirstSeen) < 1h  // Recently created
  | project DeviceName, RegistryKey, AllValues, FirstSeen
  | order by FirstSeen desc

Response Workflow Diagram

┌─────────────────────────────────────────────────────────┐
│          ALERT: EDR/AV Service Termination              │
├─────────────────────────────────────────────────────────┤
│ Severity: CRITICAL | Action: IMMEDIATE                  │
└────────────┬────────────────────────────────────────────┘
             │
             ▼
┌─────────────────────────────────────────────────────────┐
│   PHASE 1: IMMEDIATE CONTAINMENT (0-5 min)             │
│                                                         │
│ ✓ Page on-call IR lead                                 │
│ ✓ Acknowledge in incident system                       │
│ ✓ Isolate endpoint (disable network adapter)           │
│ ✓ Attempt memory dump if EDR accessible                │
│ ✓ Export EDR logs (live response)                      │
│ ✓ Notify management/security leadership                │
└────────────┬────────────────────────────────────────────┘
             │
             ▼
        ┌────────────┐
        │ IR CALL    │
        │ INITIATED  │
        └────────┬───┘
                 │
        ┌────────┴──────────┐
        │                   │
        ▼                   ▼
  MULTI-ENDPOINT?    SINGLE ENDPOINT?
        │                   │
        │                   ▼
        │          ┌──────────────────┐
        │          │ PHASE 2: ANALYSIS │
        │          │ (5-30 min)        │
        │          │                  │
        │          │ ✓ Collect logs   │
        │          │ ✓ Scope check    │
        │          │ ✓ LA timeline    │
        │          │ ✓ User account   │
        │          │   analysis       │
        │          └────────┬─────────┘
        │                   │
        │                   ▼
        │          ┌─────────────────┐
        │          │ REBUILD OR      │
        │          │ CONTAIN?        │
        │          │                 │
        │          │ → Rebuild       │
        │          │ → Full evidence  │
        │          └────────┬────────┘
        │                   │
        └───────────┬───────┘
                    │
                    ▼
        ┌──────────────────────────┐
        │ PHASE 3: REMEDIATION     │
        │ (30 min - 4 hours)       │
        │                          │
        │ ✓ Rebuild OS             │
        │ ✓ Latest patches         │
        │ ✓ EDR re-install         │
        │ ✓ Return to network      │
        │ ✓ Verify EDR operational │
        └────────────┬─────────────┘
                     │
                     ▼
        ┌──────────────────────────┐
        │ PHASE 4: INVESTIGATION   │
        │ (ongoing, days)          │
        │                          │
        │ ✓ Forensic analysis      │
        │ ✓ Attack timeline        │
        │ ✓ Root cause analysis    │
        │ ✓ Kill chain mapping     │
        │ ✓ Lessons learned        │
        │ ✓ Hardening improvements │
        └────────────┬─────────────┘
                     │
                     ▼
        ┌──────────────────────────┐
        │ INCIDENT CLOSED          │
        │ Post-incident review doc │
        └──────────────────────────┘

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.