RTCore64.sys BYOVD: CVE-2019-16098, EDR bypass e difesa

RTCore64.sys BYOVD: CVE-2019-16098, driver vulnerabile di MSI Afterburner #

RTCore64.sys è un driver di Windows che nasce per una cosa innocua: far funzionare MSI Afterburner, il programma con cui i giocatori overcloccano la scheda video. Oggi è uno dei driver vulnerabili più abusati negli attacchi BYOVD: ransomware come BlackByte lo usano per spegnere antivirus ed EDR prima di cifrare i file. Questa tecnica si chiama BYOVD, Bring Your Own Vulnerable Driver: l’attaccante porta con sé un driver legittimo, firmato e con una falla, e lo usa per scrivere nel kernel.

In questa guida vediamo cos’è RTCore64.sys, cosa rende pericolosa la CVE-2019-16098, come si usa in un engagement di red team, come l’ha sfruttata BlackByte e come rilevarlo e bloccarlo sulla tua rete.

Cos’è RTCore64.sys #

RTCore64.sys è il driver in modalità kernel installato con MSI Afterburner (la versione abusata è la 4.6.2.15658). Serve a leggere e scrivere cose a basso livello dell’hardware, come i registri della GPU, per controllare frequenze e ventole.

Ci sono tre fatti che lo rendono interessante per un attaccante:

è firmato da Micro-Star International con un certificato valido, quindi Windows lo carica senza problemi;
il suo device (\\.\RTCore64) non ha ACL restrittive;
non controlla gli indirizzi che gli arrivano dallo spazio utente.

Il risultato è la CVE-2019-16098: chi riesce a parlare con il driver può leggere e scrivere memoria arbitraria, registri MSR e porte I/O. In pratica, un driver firmato che fa da “telecomando” per il kernel.

Cos’è un attacco BYOVD #

Windows non carica nel kernel driver non firmati (Driver Signature Enforcement). Questa regola blocca un attaccante che prova a caricare un driver malevolo fatto da lui. Il BYOVD aggira il problema in modo semplice: invece di creare un driver, ne prende uno già firmato ma vulnerabile.

Il flusso è sempre lo stesso:

Una cosa importante: per caricare un driver servono già i privilegi di amministratore, o almeno il privilegio SeLoadDriverPrivilege (ne parliamo nell’articolo su SeLoadDriverPrivilege ). Quindi il BYOVD non serve per entrare in un sistema: è una tecnica di post-exploitation che porta l’attaccante da amministratore a kernel. Se vuoi il quadro completo di cosa succede prima, trovi il percorso nella guida alla privilege escalation su Windows .

Cosa può fare il driver #

Il driver espone alcune funzioni, raggiungibili con richieste IOCTL dallo spazio utente. Quelle che contano sono queste:

Capacità	Cosa permette
Lettura memoria	Leggere dati arbitrari, anche del kernel
Scrittura memoria	Modificare strutture del kernel
Lettura e scrittura MSR	Toccare registri speciali della CPU
Lettura e scrittura porte I/O	Parlare direttamente con l’hardware

La seconda riga è quella che fa paura. Con la scrittura arbitraria nel kernel, un processo in user mode può spegnere i controlli di sicurezza dall’interno, senza essere fermato da nessuno.

Perché serve agli attaccanti: accecare l’EDR #

Un EDR controlla il sistema registrando delle kernel callbacks: funzioni che il kernel richiama ogni volta che parte un processo, nasce un thread o viene caricata una DLL. È così che l’EDR “vede” quello che succede.

Se un attaccante scrive nel kernel, può togliere queste callback dalla lista. L’EDR resta installato, il servizio risulta in esecuzione, ma non riceve più nessun evento: è cieco.

È esattamente quello che ha fatto BlackByte, secondo l’analisi di Sophos :

ha scritto RTCore64.sys nella cartella AppData\Roaming;
ha creato e avviato un servizio con CreateServiceW, scegliendo il nome da una lista;
ha riconosciuto la versione del kernel per usare gli offset giusti;
ha azzerato le callback PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine e PspLoadImageNotifyRoutine dei driver di sicurezza presenti in una lista di oltre 1.000 driver;
ha disattivato anche il provider ETW Microsoft-Windows-Threat-Intelligence, da cui dipendono molte difese.

Dopo questo passaggio il resto dell’attacco è senza ostacoli: dump delle credenziali con tool come Mimikatz , movimento laterale, cifratura dei file. Lo stesso driver è usato anche per spegnere la Driver Signature Enforcement e caricare driver non firmati: la demo presentata al CYBERSEC 2023 mostra proprio questo passaggio.

Red Team: usare RTCore64.sys in un engagement #

In un red team con obiettivo “bypass EDR”, RTCore64.sys è uno dei driver più usati perché è firmato, reale e ben documentato. Il cliente capisce subito cosa è successo e può verificare se il proprio stack di sicurezza lo rileva.

Prerequisiti

Serve già avere privilegi di amministratore (o SeLoadDriverPrivilege) sulla macchina target. Non è un modo per entrare: è il passo successivo, da admin a kernel. Il percorso completo è nella guida alla privilege escalation su Windows .

Tool pubblici

Ci sono tool open source che implementano questo attacco:

Tool	Cosa fa
EDRSandBlast	Supporta RTCore64.sys e altri driver; disabilita callback kernel e provider ETW
PPLKiller	Rimuove la protezione PPL dai processi, poi permette il dump di LSASS
KDMapper	Usa iqvw64e.sys per caricare driver non firmati nel kernel

Flusso operativo

Hai già privilegi di amministratore sulla macchina.
Porti o scarichi RTCore64.sys in una cartella temporanea (%TEMP%, AppData\Roaming).
Crei il servizio kernel con sc.exe create o CreateServiceW e lo avvii.
Il tool legge la versione del kernel per calcolare gli offset delle strutture interne.
Apre il device \\.\RTCore64 e invia richieste IOCTL per leggere e scrivere memoria kernel.
Azzera le callback PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, PspLoadImageNotifyRoutine: l’EDR non riceve più eventi.
Disattiva il provider ETW Microsoft-Windows-Threat-Intelligence, usato da molti prodotti di sicurezza.
Esegui il payload: dump LSASS, lateral movement, simulazione ransomware.
Stoppi il servizio, cancelli il driver e il servizio (sc.exe stop, sc.exe delete).

Considerazioni OPSEC

L’evento 7045 logga il nome del servizio: usare un nome simile a un servizio legittimo (es. MSIAfterbrnr) riduce gli alert nei SIEM meno configurati.
Rinominare il file non cambia l’hash: un EDR con regole su hash lo rileva comunque.
Disattivare ETW Threat-Intelligence è un segnale forte e rilevabile anche senza l’EDR, direttamente dal SIEM.
Se gli offset del kernel sono sbagliati (versione non supportata) il driver causa un BSOD: testare in lab prima.
Su sistemi con HVCI attivo, la scrittura nel kernel è bloccata a livello hardware: questa tecnica non funziona.

Nel report di red team

Questa tecnica si documenta come MITRE ATT&CK T1562.001 (Impair Defenses: Disable or Modify Tools). Includi nell’evidenza: hash del driver, nome del servizio, timestamp, evento 7045 catturato. L’impatto: “l’EDR non ha registrato eventi per X minuti durante il test.” La remediation: HVCI, blocklist Microsoft, monitoraggio 7045/4697/Sysmon 6.

Il driver in LOLDrivers #

Il progetto LOLDrivers raccoglie i driver legittimi che gli attaccanti abusano. RTCore64.sys è catalogato come vulnerable driver, mappato su MITRE ATT&CK T1068 (Exploitation for Privilege Escalation) e, al 1 novembre 2026, l’elenco contiene 33 campioni noti con hash diversi. È utile saperlo perché la detection per nome non basta: basta rinominare il file per eluderla.

È lo stesso principio dei LOLBins , ma nel kernel: strumenti legittimi, usati contro chi li ha installati.

Come rilevare RTCore64.sys #

Qui sotto trovi controlli che puoi fare subito su un host Windows. Sono comandi di sola lettura.

1. Cercare il driver nei servizi installati

powershell

# List kernel drivers whose name or path mentions RTCore
Get-CimInstance Win32_SystemDriver |
  Where-Object { $_.Name -like 'RTCore*' -or $_.PathName -like '*RTCore64*' } |
  Select-Object Name, State, StartMode, PathName

2. Cercare il file sul disco e controllare l’hash

powershell

# Find every RTCore64.sys on C: and print its SHA256
Get-ChildItem -Path C:\ -Filter RTCore64.sys -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='SHA256';e={(Get-FileHash $_.FullName -Algorithm SHA256).Hash}}

Confronta l’hash con quelli di LOLDrivers. Uno dei campioni noti è 03e0581432f5c8cc727a8aa387f5b69ff84d38d0df6f1226c19c6e960a81e1e9.

3. Cercare la creazione del servizio nel log di sistema

powershell

# Event 7045 means a new service was installed
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7045 } |
  Where-Object { $_.Message -match 'RTCore64' } |
  Select-Object TimeCreated, Message

Gli eventi utili sono tre: 7045 (nuovo servizio, log System), 4697 (servizio installato, log Security, se l’audit è attivo) e Sysmon Event ID 6 (driver caricato, con l’hash nel campo Hashes).

4. Una regola Sigma basata sull’hash

La regola pubblica di SigmaHQ cerca il nome \rtcore64.sys ed è di livello basso: il nome si cambia in un secondo. Una regola sull’hash è più solida:

yaml

title: RTCore64.sys Driver Load By Hash
id: 241306fb-d6de-4eb9-a901-2370f2480c46
status: experimental
description: Detects the load of known RTCore64.sys samples by SHA256 hash
references:
  - https://www.loldrivers.io/
author: Hackita
date: 2026/11/01
logsource:
  category: driver_load
  product: windows
detection:
  selection:
    Hashes|contains:
      - 'SHA256=03E0581432F5C8CC727A8AA387F5B69FF84D38D0DF6F1226C19C6E960A81E1E9'
      - 'SHA256=0466DAC557EE161503F5DFBD3549F81EC760C3D6C7C4363A21A03E7A3F66ACA8'
      - 'SHA256=077AA8FF5E01747723B6D24CC8AF460A7A00F30CD3BC80E41CC245CEB8305356'
  condition: selection
falsepositives:
  - Legitimate MSI Afterburner installed on gaming workstations
level: high

Se in azienda nessuno deve usare MSI Afterburner, qualsiasi hit di questa regola merita un’indagine.

Provarlo in laboratorio (solo in una VM tua) #

Per verificare che la detection funzioni, in una VM di laboratorio con Sysmon puoi caricare il driver e controllare che gli eventi arrivino al SIEM. Il comando di caricamento è quello pubblicato in LOLDrivers:

cmd

sc.exe create RTCore64.sys binPath=C:\windows\temp\RTCore64.sys type=kernel
sc.exe start RTCore64.sys

Controlla subito dopo che compaiano l’evento 7045 nel log System e l’evento 6 di Sysmon con l’hash. Se non li vedi, la tua copertura ha un buco. Per rimuovere tutto:

cmd

sc.exe stop RTCore64.sys
sc.exe delete RTCore64.sys

Se hai attiva la blocklist di Microsoft (vedi sotto), su un sistema aggiornato il caricamento verrà bloccato: è proprio il risultato che vuoi.

Come difendersi dal BYOVD #

Le difese si dividono in tre livelli: impedire il caricamento, ridurre l’esposizione, rilevare.

Impedire il caricamento

La Microsoft vulnerable driver blocklist contiene i driver noti per essere vulnerabili. È stata introdotta come funzione opzionale in Windows 10 1809, si attiva automaticamente quando è attiva l’HVCI (o in S Mode) ed è attiva di default su tutti i dispositivi da Windows 11 22H2. Con l’aggiornamento di ottobre 2022 (KB5020779) anche i sistemi più vecchi ricevono la stessa lista di Windows 11 22H2. Verifica lo stato così:

cmd

reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable

Se il valore è 0x1 la blocklist è attiva. Se la chiave manca, vale il comportamento predefinito del tuo Windows.

La HVCI (Memory Integrity) attiva in automatico la blocklist e protegge il kernel dal codice non affidabile. Controlla se è in esecuzione:

powershell

# SecurityServicesRunning contains 2 when HVCI is running
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning

La regola ASR “Block abuse of exploited vulnerable signed drivers” di Microsoft Defender blocca la scrittura su disco di driver vulnerabili noti:

powershell

Add-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 -AttackSurfaceReductionRules_Actions Enabled

Con App Control for Business (WDAC) puoi andare oltre e consentire solo i driver che scegli tu.

Ridurre l’esposizione

Togli MSI Afterburner e gli altri tool di overclock dai server e dai PC aziendali: non hanno motivo di esserci.
Fai un inventario dei driver installati, perché un driver vulnerabile può essere già sul sistema e l’attaccante non deve nemmeno scaricarlo.
Limita chi ha privilegi di amministratore o SeLoadDriverPrivilege: senza quelli il BYOVD non parte.

Rilevare

Manda al SIEM gli eventi 7045, 4697 e Sysmon 6.
Segnala ogni nuovo driver mai visto prima nella tua rete.
Usa le liste di LOLDrivers come fonte per le regole su hash, non solo su nome.

Una nota onesta: la blocklist non è applicata ovunque in modo uniforme nelle aziende, quindi non affidarti a una sola difesa. Metti insieme blocklist, HVCI e detection.

Domande frequenti #

RTCore64.sys è un virus? #

No. È un driver legittimo, firmato da Micro-Star International, che arriva con MSI Afterburner. Diventa un problema quando compare dove non dovrebbe, per esempio in AppData\Roaming o in una cartella temporanea, su una macchina dove nessuno usa MSI Afterburner.

Che cos’è un attacco BYOVD? #

È una tecnica in cui l’attaccante porta con sé un driver firmato e vulnerabile e lo carica sul sistema della vittima. Poiché il driver è firmato, Windows lo accetta, e la sua falla dà all’attaccante accesso al kernel.

Serve essere amministratori per sfruttarlo? #

Sì, per caricare il driver servono privilegi di amministratore o SeLoadDriverPrivilege. Il BYOVD è un passaggio successivo alla compromissione iniziale.

La CVE-2019-16098 è stata corretta? #

Installare l’ultima versione di Afterburner sul tuo PC non cambia le cose, perché l’attaccante porta con sé una copia vecchia del driver, che resta firmata e quindi valida. Per questo la difesa è la blocklist di Microsoft, insieme alla detection, non solo l’aggiornamento.

Un antivirus rileva RTCore64.sys? #

Il file è legittimo, quindi molti antivirus lo ignorano. Serve una regola specifica su hash o comportamento: caricamento del driver da un percorso insolito, creazione di un servizio kernel da parte di un processo non attendibile, seguita dalla scomparsa degli eventi dell’EDR.

Quali altri driver si usano con questa tecnica? #

Ne esistono centinaia. L’elenco aggiornato è su LOLDrivers, e ogni driver richiede la propria regola di detection. RTCore64.sys è tra i più noti perché è stato usato da ransomware reali.

Riepilogo operativo #

RTCore64.sys è un driver firmato di MSI Afterburner con la CVE-2019-16098: lettura e scrittura arbitraria di memoria, MSR e porte I/O.
Il BYOVD lo usa per passare da amministratore a kernel e togliere le callback dell’EDR.
BlackByte l’ha usato davvero, copiandolo in AppData\Roaming e avviandolo come servizio.
Cerca gli eventi 7045, 4697 e Sysmon 6, e usa regole su hash, non solo sul nome.
Difenditi con blocklist Microsoft, HVCI, regola ASR e WDAC, e togli i tool di overclock dalle macchine aziendali.

Il BYOVD è un tassello della fase di post-exploitation : capirlo ti aiuta a riconoscere il momento in cui un attaccante smette di essere un utente con privilegi alti e diventa il padrone della macchina.

Fonti principali: l’analisi di Sophos su BlackByte, la scheda di RTCore64.sys su LOLDrivers, la documentazione Microsoft sulla vulnerable driver blocklist (KB5020779) e le regole pubbliche di SigmaHQ.