Abstract
EDRKillShifter è un toolkit impiegato da affiliati ransomware per neutralizzare soluzioni Endpoint Detection & Response (EDR) e altri controlli di sicurezza prima di eseguire fasi distruttive quali cifratura dei dati o esfiltrazione. Questo articolo fornisce una panoramica tecnica, indicatori di compromissione (IoC), strategie di rilevamento (hunting), contromisure e un playbook operativo per la risposta a incidente.
1. Contesto e sintesi
EDRKillShifter si colloca nella famiglia di strumenti che sfruttano tecniche consolidate — in particolare il caricamento di driver vulnerabili (BYOVD, Bring Your Own Vulnerable Driver) — per ottenere privilegi kernel e alterare il comportamento dell’EDR. Piuttosto che inventare nuovi exploit zero-day, gli autori del toolkit sfruttano componenti firmati o legacy con vulnerabilità note, permettendo operazioni di sabotaggio del security stack.
Perché è rilevante: il toolkit è modulare, riutilizzabile e stato osservato in più campagne ransomware, aumentando il rischio operativo per le organizzazioni che non hanno un inventario driver aggiornato o protezioni anti-tamper efficaci.
2. Obiettivi e vettori d’attacco
Obiettivi del toolkit:
- Disabilitare/neutralizzare l’EDR locale (servizi, processi, driver di filtro).
- Mascherare o rimuovere tracce (log, voci di registro).
- Consentire la successiva fase di cifratura o esfiltrazione senza interferenze.
Vettori tecnici principali:
- Caricamento di driver kernel vulnerabili (BYOVD) per ottenere accesso a funzioni kernel.
- Termination/forzatura dello stop di servizi EDR tramite chiamate kernel/IOCTL.
- Modifiche al registro e cancellazione di log per impedire il ripristino automatico o la ricostruzione delle tracce.
3. Tecniche tecniche (deep dive)
BYOVD (Bring Your Own Vulnerable Driver)
Gli attaccanti portano e caricano un driver che espone funzionalità kernel abusive o che ha vulnerabilità note che consentono escalation/operazioni arbitrarie. Poiché i driver girano in kernel-mode, il loro abuso permette di manipolare strutture sensibili (process table, callback, filtri di rete/file system).
Manipolazione servizi/driver EDR
Attraverso IOCTL o API kernel, il toolkit può:
- Fermare processi/servizi EDR o provocarli in crash.
- Rimuovere filtri kernel (es. minifilter file system) che intercettano operazioni sospette.
- Intercettare e alterare chiamate di monitoraggio o di auditing.
Cancellazione e tampering di tracce
Azioni su chiavi di registro critiche, rimozione di log locali e cancellazione di file temporanei correlati all’EDR per complicare l’analisi forense.
4. Indicatori di compromissione (IoC)
- Caricamento inusuale di driver kernel (nomi o path anomali, driver con timestamp recenti su host inattivi).
- Eventi di stop/terminate o crash ripetuti dei processi correlati all’EDR.
- Chiamate a NtLoadDriver/NtUnloadDriver non usuali o provenienti da contesti anomali.
- Modifiche a chiavi di registry critiche dell’EDR immediatamente prima di attività malevole.
Nota: gli IoC specifici (nomi file, hash, IOCTL numbers) variano con le varianti del toolkit; mantenere aggiornati i feed di intelligence e le regole YARA/Sigma del vendor.
5. Rilevamento e hunting (configurazioni pratiche)
Telemetria da abilitare
- Sysmon: ImageLoad, ProcessCreate, CreateRemoteThread, Driver load events (se supportato).
- Windows Event Forwarding / centralizzazione dei log EDR.
Esempio KQL (Microsoft Sentinel) — ricerca rapide
// Cerca processi che hanno caricato driver da path non standard
DeviceImageLoadEvents
| where FileName endswith ".sys"
| where FolderPath !in ("C:\\Windows\\System32\\drivers","C:\\Windows\\SysWOW64\\drivers")
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName
Esempio Sigma (semplificato)
title: Suspicious driver load from non-standard folder
detection:
selection:
EventID: 6 # ImageLoad (Sysmon)
Image: '*\\*.sys'
condition: selection
level: high
Validare queste query nel proprio ambiente per ridurre i falsi positivi (alcuni driver hardware legittimi possono essere caricati da path non standard).
6. Contromisure e hardening (pratiche raccomandate)
- Tamper protection EDR: abilitare funzioni anti-tamper e limitare la possibilità di stop/disable anche per utenti con privilegi elevati.
- Secure Boot e Code Integrity: abilitare Secure Boot e HVCI/Memory Integrity per ridurre la possibilità di caricamento di driver non attendibili.
- Inventory e blocklist driver: mantenere un inventario centralizzato dei driver installati; aggiornare o rimuovere driver legacy e usare blocklist/allowlist gestite.
- Least privilege per installazione driver: limitare gli account con permessi di installare driver e monitorare cambi di policy locali.
- Difesa in profondità: combinare EDR con NDR, controllo integrità file e monitoraggio centrale dei log.
7. Playbook sintetico di risposta a incidente (IR)
- Isolamento immediato dell’host compromesso dalla rete.
- Acquisizione forense: memoria e disco (immagini) prima di eseguire azioni invasive.
- Analisi dei driver caricati: elencare driver recenti e correlare con timeline degli eventi EDR.
- Containment e remediation: bloccare indicatori a livello di rete e endpoint; se l’EDR è compromesso considerare reimage dell’host.
- Hunt su rete e altri endpoint: cercare artefatti simili e applicare mitigation su host potenzialmente colpiti.
8. Checklist operativa rapida (da stampare)
- Abilitare Tamper Protection su tutti gli endpoint.
- Abilitare Secure Boot e HVCI quando possibile.
- Inventario completo dei driver; rimuovere/aggiornare driver legacy.
- Centralizzare Sysmon ed EDR telemetry.
- Creare e testare playbook IR (reimage test compreso).
9. Conclusione
EDRKillShifter è l’esempio pratico di come tecniche riconosciute possano essere pacchettizzate e diffuse come toolkit riutilizzabili: la difesa efficace richiede inventario, hardening del kernel-level, telemetria centralizzata e playbook IR provati.
