Rootkit Kernel: Kernel Modules and Extensions (T1547.006)

Un esercizio red team che simula T1547.006 richiede sempre laboratorio isolato, snapshot delle VM e comunicazione preventiva con il blue team, perché un rootkit kernel mal scritto porta facilmente a kernel panic e perdita del sistema.

Su Linux la catena tipica parte da un accesso già privilegiato (root o capability CAP_SYS_MODULE). Il modulo di test si compila contro gli header del kernel bersaglio con un semplice Makefile che invoca make -C /lib/modules/$(uname -r)/build M=$(pwd) modules. Il caricamento avviene con insmod ./modulo.ko oppure modprobe modulo se il file è stato copiato in /lib/modules/$(uname -r)/extra/ e si è rigenerata la cache con depmod -a. Per la verifica si usano lsmod, cat /proc/modules e modinfo modulo.ko. Se il kernel target ha Secure Boot attivo o module.sig_enforce=1, il modulo deve essere firmato con la chiave MOK importata tramite mokutil --import.

Come riferimento didattico per comprendere le tecniche di hooking delle syscall e nascondimento di processi esistono progetti open source come Diamorphine (open source, GitHub) e Reptile (open source, GitHub, corrispondente al software MITRE S1219). Sono esplicitamente pensati per ricerca e vanno usati solo in lab.

Su macOS il flusso è più rigido. Un kext è un bundle .kext con Info.plist e binario Mach-O; il caricamento avviene con sudo kextload /percorso/modulo.kext e la rimozione con sudo kextunload. Su versioni recenti kmutil load -p /percorso/modulo.kext è il comando corretto e richiede reboot per l'attivazione. Senza un Developer ID con entitlement kernel rilasciato da Apple, il kext non si carica a SIP attivo: in laboratorio si disabilita SIP da recovery con csrutil disable solo su macchine dedicate.

Per post-exploitation e persistenza in scenari di simulazione, framework come Metasploit Framework (open source) e Sliver (open source) includono moduli per il deployment di payload post-root, ma il modulo kernel vero e proprio va scritto ad hoc o adattato da progetti pubblici.

La catena d'attacco realistica prevede: accesso iniziale, escalation a root tramite exploit locale o credenziali, drop del .ko firmato o non firmato in /tmp, caricamento, poi cancellazione delle tracce con dmesg -C e manipolazione di /var/log/kern.log. Il modulo tipicamente installa hook su sys_kill per ricevere comandi tramite segnali speciali e su sys_getdents per nascondere file e processi.

La detection di T1547.006 si gioca quasi interamente sulla telemetria kernel, perché una volta caricato un LKM ben scritto la visibilità user space è compromessa. Il paradigma è quindi detect early, detect at load time.

Su Linux la sorgente primaria è auditd con regole mirate sui syscall init_module, finit_module e delete_module. Una regola tipo -a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k MODULE_LOAD genera eventi SYSCALL correlabili con l'utente reale (auid), il processo padre e il path del .ko. Sysmon for Linux (open source, Microsoft) offre l'EventID 1 per process creation, utile per catturare invocazioni di insmod, modprobe, kmod, depmod fuori dai change window autorizzati.

Le query osquery (open source) sulle tabelle kernel_modules e kernel_info consentono baseline periodica: qualsiasi differenza rispetto allo snapshot precedente merita triage. Un'altra fonte da non trascurare è il monitoraggio dei file in /lib/modules/$(uname -r)/, /etc/modules-load.d/ e /etc/modprobe.d/, dove persistenze silenziose vengono spesso piazzate.

Gli indicatori comportamentali di alto valore includono: moduli caricati da utenti diversi da root o da account di servizio non previsti, moduli senza firma quando il sistema ha CONFIG_MODULE_SIG atteso, comparsa di header kernel e toolchain (gcc, make) su server di produzione, download di file .ko via curl o wget seguiti a breve da eventi init_module.

Su macOS la telemetria si basa su Unified Log filtrata su subsystem com.apple.kext e su eventi kextload, kmutil, insieme a query osquery sulla tabella kernel_extensions. Segnali di allerta sono modifiche al database KextPolicy, comparsa di Developer ID non presenti nell'allowlist aziendale, tentativi di caricare legacy extensions da percorsi non standard e qualsiasi transizione di stato SIP osservabile.

Sul fronte controlli preventivi allineati alla mitigazione M1038, l'attivazione di SELinux in enforcing o AppArmor con profili restrittivi, unita a sysctl kernel.modules_disabled=1 dopo il boot su sistemi che non necessitano moduli aggiuntivi, riduce drasticamente la superficie. La mitigazione M1018 su macOS si traduce in policy MDM che gestiscono com.apple.syspolicy.kernel-extension-policy per bloccare qualsiasi kext non approvato.

I falsi positivi principali arrivano da: aggiornamenti kernel legittimi con ricarica moduli, agenti EDR che installano propri LKM (CrowdStrike Falcon, SentinelOne), moduli hardware caricati a runtime (webcam, VPN client, driver GPU NVIDIA). L'allowlist per hash e signer dei moduli attesi in ambiente è la contromisura standard.

L'analisi forense di un compromesso T1547.006 parte dal presupposto che il sistema live è potenzialmente non affidabile: un LKM rootkit può filtrare l'output di lsmod, ps, netstat e persino modificare /proc. La regola operativa è acquisire prima memoria fisica, poi disco, e infine confrontare con una baseline offline.

Su Linux l'acquisizione di memoria si esegue con LiME (open source) via insmod lime.ko "path=/mnt/evidence/mem.lime format=lime", sempre da media esterno write-locked. L'analisi in Volatility 3 (open source) con i plugin linux.lsmod, linux.check_syscall, linux.check_modules e linux.hidden_modules rivela discrepanze tra la lista pubblica dei moduli e le strutture module effettivamente linkate nel kernel: una tipica firma di rootkit come Diamorphine o REPTILE è proprio la presenza di un modulo agganciato ma assente da /proc/modules.

Lato disco gli artefatti chiave sono: file .ko in /lib/modules/, /tmp, /dev/shm o home directory sospette; entry in /etc/modules-load.d/, /etc/modprobe.d/, /etc/rc.local e unit systemd in /etc/systemd/system/ che invocano modprobe; presenza di initramfs modificato in /boot/. L'utility find /lib/modules -name ".ko" -newer /etc/hostname* permette di isolare moduli comparsi dopo l'installazione del sistema. Il confronto degli hash dei .ko con la baseline del pacchetto tramite rpm -V kernel o dpkg --verify identifica file non appartenenti alla distribuzione.

La timeline si costruisce con plaso/log2timeline (open source) partendo da auditd, /var/log/kern.log, /var/log/syslog, journal systemd e MAC times del filesystem. Eventi chiave da correlare: comparsa del .ko, prima esecuzione di insmod o modprobe, righe kernel: modulo: loading out-of-tree module nel dmesg, eventuali taints del kernel visibili in /proc/sys/kernel/tainted.

Per scan mirati anti-rootkit su copia forense montata read-only si usano rkhunter (open source) e chkrootkit (open source), consapevoli che rootkit moderni sono spesso progettati per evadere queste firme. LKRG (open source) e Tracee (open source, Aqua Security) forniscono telemetria runtime utile in fase di contenimento post-incident.

Su macOS gli artefatti risiedono in /Library/Extensions/, /System/Library/Extensions/ (protetta da SIP), /Library/StagedExtensions/, nel database KextPolicy in /var/db/SystemPolicyConfiguration/KextPolicy e nei log unificati esportati con log collect. Il comando kmutil showloaded su copia live e kextstat offrono la lista dei kext residenti; incrociarli con codesign -dv --verbose=4 rivela signer sospetti.

Nel caso di Operation CuckooBees (C0012), attribuita ad attori affiliati a Winnti Group, APT41 e BARIUM tra dicembre 2019 e maggio 2022, i ricercatori hanno documentato l'uso di un rootkit kernel firmato per persistenza aggiuntiva contro aziende tecnologiche e manifatturiere in Asia orientale, Europa occidentale e Nord America. Questo dettaglio è forensicamente rilevante: la firma valida bypassa i controlli di sig_enforce e sposta l'indagine sull'analisi della catena di certificati e sulla provenienza del signer.

Il panorama threat intelligence attorno a T1547.006 è dominato da attori con capacità di sviluppo elevate, perché scrivere un rootkit kernel stabile richiede competenze specialistiche in programmazione kernel, gestione delle strutture dati interne di Linux o XNU e, sempre più spesso, accesso a certificati di firma validi.

La campagna documentata nei dati MITRE è Operation CuckooBees (C0012), attiva da almeno dicembre 2019 fino ad almeno maggio 2022, attribuita ad attori affiliati a Winnti Group, APT41 e BARIUM. Questi tre nomi rappresentano cluster di attività sovrapposti riconducibili all'ecosistema cyber cinese, con forte focus su spionaggio industriale. L'obiettivo dichiarato è il furto di informazioni proprietarie, documenti di ricerca e sviluppo, codice sorgente e blueprint tecnologici da aziende technology e manufacturing in Asia orientale, Europa occidentale e Nord America. L'uso di un rootkit kernel firmato è l'elemento distintivo: implica accesso a un certificato di code signing valido, ottenuto tramite compromissione di catena di fornitura o abuso di programmi di firma legittimi.

Sul fronte software, i dati censiscono tre famiglie di rilievo. Skidmap (S0468) è un malware Linux orientato al cryptomining che installa multipli LKM per nascondere il proprio miner, alterare statistiche di CPU e mantenere backdoor. La caratteristica di installare più moduli in sequenza serve a ridondare la persistenza: rimuovendone uno, gli altri restano attivi.

Drovorub (S0502) è un rootkit Linux di alto profilo, la cui esistenza è stata pubblicamente attribuita in un advisory congiunto a APT28 (noto anche come Fancy Bear, riconducibile al GRU russo). Utilizza un LKM per persistenza combinato con moduli di implant, agent, client e server con capacità C2. Rappresenta l'archetipo del rootkit kernel state-sponsored: modulare, con protocolli di comunicazione custom e progettato per resistere ad analisi forense di lunga durata.

REPTILE (S1219) è un rootkit open source implementato come LKM, ampiamente adottato e adattato da diversi attori proprio perché il codice pubblico abbassa la barriera d'ingresso. La sua presenza in un incident non implica automaticamente un attore specifico ma indica riuso di codice pubblico, spesso associato a gruppi meno sofisticati o a operazioni dove l'attribuzione viene volutamente offuscata.

Il pattern strategico che emerge combina due filoni: da un lato APT statali (cinesi con Winnti/APT41/BARIUM, russi con APT28) che sviluppano rootkit custom firmati per campagne di spionaggio prolungate, dall'altro criminalità cyber e miner che riusano codice open source come REPTILE e varianti Skidmap per monetizzazione. Il denominatore comune è la vittimologia enterprise Linux, in particolare server di produzione con uptime elevati dove un rootkit non rilevato può sopravvivere anni.

Il trend osservabile è la crescente ricerca di certificati di firma legittimi per superare module signature enforcement su distribuzioni enterprise moderne, un cambiamento diretto rispetto all'era in cui il caricamento di moduli non firmati era la norma.

MITRE ATT&CK: T1547.006 Kernel Modules and Extensions; tattiche TA0003 Persistence, TA0004 Privilege Escalation. Software: S0468 Skidmap, S0502 Drovorub, S1219 REPTILE. Campagna: C0012 Operation CuckooBees (Winnti Group, APT41, BARIUM). Mitigazioni: M1018, M1026, M1038, M1049. Detection: DET0450 (AN1243 Linux, AN1244 macOS). MITRE D3FEND per artefatti Kernel Module e tecniche detect. Comandi, tool open source (LiME, Volatility 3, osquery, Sysmon for Linux, LKRG, Tracee, rkhunter, chkrootkit, Diamorphine) e procedure operative integrati da conoscenza professionale di cybersecurity.