Regole Udev Malevole: Udev Rules (T1546.017)

Per simulare T1546.017 in un ambiente di laboratorio autorizzato, l'operatore red team parte da una shell con privilegi root sulla macchina target. Il flusso tipico prevede la scrittura di un file di regola udev che invoca un payload esterno tramite la direttiva RUN+=, poiché quest'ultima è vincolata a task brevi e non permette direttamente processi long-running.

Un esempio didattico di regola posizionata in /etc/udev/rules.d/70-persistence.rules potrebbe essere:

KERNEL=="random", RUN+="/bin/sh -c '/tmp/.payload &'"

La chiave KERNEL=="random" fa scattare la regola ogni volta che un processo accede al device /dev/random, evento estremamente frequente su qualsiasi sistema Linux (crypto, TLS handshake, generazione UUID). Il costrutto sh -c '... &' esegue il detach del processo figlio, così quando udevd termina il worker dopo pochi secondi il payload continua a girare in background, aggirando il sandbox di systemd-udevd che blocca rete e filesystem al processo diretto.

Dopo la scrittura del file la regola va ricaricata:

udevadm control --reload-rules

udevadm trigger

Il comando udevadm test /dev/random (open source, incluso in systemd) permette di verificare quali regole matcherebbero un dato evento senza attendere l'evento reale, utile per debug in lab.

Varianti più stealth usano SUBSYSTEM=="usb" per attivare il payload solo all'inserimento di una specifica chiavetta identificata via ATTR{idVendor} e ATTR{idProduct}, riducendo la superficie di detection comportamentale. Un'altra variante sfrutta il prefisso numerico del filename per garantire priorità elevata: un file 10-net.rules viene processato prima di 70-persistence.rules.

Per la fase di weaponization il payload esterno può essere un binario ELF statico compilato con musl (open source) per evitare dipendenze da glibc, oppure uno script Python offuscato con PyArmor (freemium). Il framework Metasploit (open source) non offre moduli nativi per questa tecnica, ma Sliver (open source) e Havoc (open source) permettono di generare implant compatibili da chiamare dalla regola.

Per emulazione strutturata, Atomic Red Team (open source) include il test T1546.017 con procedure reversibili. In post-exploitation il gruppo REPTILE (rootkit LKM documentato in MITRE come S1219) ha impiegato udev per mantenere persistenza, offrendo un riferimento realistico per esercizi di purple team.

La detection di T1546.017 ruota attorno al monitoraggio delle directory che ospitano le regole udev e alla correlazione tra scrittura di regole e successive esecuzioni anomale nel contesto di systemd-udevd. La strategia DET0375 di MITRE indica come fonti primarie auditd:SYSCALL e auditd:CONFIG_CHANGE, con focus sulle chiavi RUN+= e IMPORT che invocano binari o script sospetti.

La prima regola auditd essenziale monitora la scrittura nelle directory sensibili:

-w /etc/udev/rules.d/ -p wa -k udev_persistence

-w /lib/udev/rules.d/ -p wa -k udev_persistence

-w /usr/lib/udev/rules.d/ -p wa -k udev_persistence

-w /run/udev/rules.d/ -p wa -k udev_persistence

Ogni evento w o a su questi path va trattato come high-fidelity, perché la modifica legittima avviene quasi solo durante l'installazione di pacchetti (dpkg, rpm, apt). Un tuning efficace correla la scrittura con il processo padre: se il writer non è un package manager noto, l'alert va promosso a incident.

Sulla parte di esecuzione, il SOC deve tracciare processi figli di systemd-udevd (PID accessibile via /proc/*/stat) che non corrispondono al set atteso. Il parametro di tuning [ParentProcess] di DET0375 suggerisce di baselineare i figli legittimi (tipicamente modprobe, systemd-udevd worker, comandi in /usr/lib/udev/) e generare alert su qualsiasi spawn di sh, bash, python, perl, nc, curl, wget con parent systemd-udevd.

La correlazione temporale è cruciale: la strategia MITRE indica una finestra [TimeWindow] tra modifica della regola e prima esecuzione anomala. Una query SIEM tipica cerca un evento CONFIG_CHANGE su rules.d seguito entro 60 secondi da un EXECVE con parent systemd-udevd e comando non whitelistato.

Sysmon for Linux (open source, distribuito da Microsoft) offre EventID 1 (ProcessCreate) e EventID 11 (FileCreate) con visibilità migliore rispetto ad auditd puro, particolarmente utile per catturare il pattern RUN+="/bin/sh -c '... &'" nella command line del processo detachato. La regex del parametro [SuspiciousRunPattern] può essere costruita per matchare shell one-liner con redirection, download da rete, o esecuzione da /tmp, /var/tmp, /dev/shm.

Falsi positivi tipici: aggiornamenti di driver hardware (NVIDIA, VirtualBox guest additions), installazione di stampanti, tool di gestione RAID. Vanno whitelistati per hash del pacchetto sorgente. auditbeat (freemium, con tier Elastic gratuito) e osquery (open source) tramite la tabella file_events sono complementari per shipping verso SIEM.

L'analisi forense di T1546.017 parte dall'enumerazione completa delle directory che ospitano regole udev. Su un'immagine acquisita con dc3dd (open source) o Guymager (open source), il primo passo è elencare ricorsivamente tutti i file .rules in /etc/udev/rules.d/, /run/udev/rules.d/, /usr/lib/udev/rules.d/, /usr/local/lib/udev/rules.d/ e /lib/udev/rules.d/, confrontandone hash e timestamp con quelli attesi dai pacchetti installati.

Su sistemi Debian/Ubuntu il comando dpkg -V verifica l'integrità dei file installati dai pacchetti e segnala modifiche a file di regole gestiti dalla distribuzione; su Red Hat/CentOS l'equivalente è rpm -Va. File .rules presenti nelle directory ma non appartenenti a nessun pacchetto (verificabili con dpkg -S o rpm -qf) sono candidati primari per analisi approfondita.

La timeline forense si costruisce con Plaso/log2timeline (open source) estraendo timestamp MAC dai file system Linux (ext4, xfs, btrfs). L'evento chiave è il ctime del file di regola, che indica il momento di creazione o modifica dell'inode. Correlazioni utili:

• log di auditd in /var/log/audit/audit.log filtrati per la chiave associata al watch su rules.d
• log di package manager (/var/log/dpkg.log, /var/log/yum.log, /var/log/dnf.log) per escludere modifiche legittime
• journal di systemd interrogabile con journalctl -u systemd-udevd per messaggi di reload e trigger
• file /var/log/syslog o /var/log/messages per eventi udev generici

Il contenuto della regola va analizzato riga per riga: le chiavi RUN+=, IMPORT{program}=, PROGRAM= sono i vettori di esecuzione. Il path del binario invocato guida verso il payload vero e proprio, che spesso risiede in /tmp, /var/tmp, /dev/shm o directory nascoste con prefisso punto in home directory di servizio. Il payload va acquisito, hashato (SHA-256) e sottoposto a triage con YARA (open source) usando regole per rootkit Linux noti.

Il caso documentato del rootkit REPTILE (S1219 in MITRE) è un riferimento: si tratta di un LKM che ha impiegato regole udev per garantire il ricaricamento del modulo kernel dopo il reboot, quindi l'analista deve verificare anche /proc/modules, output di lsmod, e integrità di /lib/modules/$(uname -r)/.

Ulteriori artefatti includono la history della shell root (.bash_history, .zsh_history) per il comando di scrittura della regola, e i file in /var/lib/systemd/ che tracciano lo stato dei servizi. Su sistemi con auditd configurato correttamente, il record SYSCALL per openat con flag O_WRONLY|O_CREAT sui path rules.d fornisce PID, UID e comando esatto dell'attore.

Il panorama di threat intelligence per T1546.017 è caratterizzato da un'adozione limitata ma altamente qualificata: la tecnica richiede accesso root preesistente e conoscenza specifica del sottosistema udev, elementi che la rendono appannaggio di operatori sofisticati piuttosto che di commodity malware.

L'unico riferimento documentato nei dati MITRE ATT&CK è il malware REPTILE (S1219), un rootkit Linux basato su Loadable Kernel Module che ha impiegato regole udev come meccanismo di persistenza complementare al caricamento del modulo kernel. REPTILE è noto per capacità di occultamento avanzate (hiding di file, processi, connessioni di rete tramite hook a livello kernel) e per l'uso di reverse shell attivabili tramite pacchetti di rete specifici (port knocking). L'impiego di udev in questo contesto risponde all'esigenza di garantire il ricaricamento automatico del rootkit dopo eventi che potrebbero scaricare il modulo, come reboot o unload manuali.

Il pattern di utilizzo di REPTILE ha visto impieghi in intrusioni attribuite ad attori con motivazioni sia di espionage sia di cybercrime avanzato, tipicamente in ambienti server Linux esposti a Internet (web server, gateway, appliance di rete). L'assenza di attribuzione a gruppi APT specifici nei dati MITRE per questa tecnica non implica assenza di uso operativo, ma piuttosto la difficoltà di detection e attribuzione: una regola udev malevola lascia tracce minimali e spesso viene scoperta solo durante DFIR approfondita successiva a un incident conclamato.

Dal punto di vista dei trend, la tecnica si inserisce in una tendenza più ampia di Linux persistence living-off-the-land, dove gli attori abusano di sottosistemi legittimi (systemd units, cron, motd, PAM modules, SSH authorized_keys) per evitare di depositare artefatti riconoscibili. Il vantaggio operativo di udev rispetto ad altre tecniche è la finestra di innesco: un accesso a /dev/random avviene decine di volte al minuto su un server tipico, garantendo esecuzione praticamente continua senza bisogno di scheduler espliciti.

Per un threat intelligence officer, gli indicatori strategici da monitorare includono: campagne di ransomware Linux (BlackCat, RansomEXX, IceFire) che stanno progressivamente adottando tecniche di persistence più raffinate; intrusioni in ambienti VMware ESXi e Kubernetes, dove udev è presente sui nodi worker; incidenti che coinvolgono rootkit LKM come Symbiote, Syslogk, o le famiglie derivate da progetti open source come Diamorphine e appunto REPTILE.

La raccomandazione TI è mantenere feed dedicati a rootkit Linux e correlare eventuali IOC di REPTILE (hash del modulo kernel, path di installazione, magic packet signatures) con l'ipotesi di regole udev come vettore di persistenza secondario. La condivisione di regole YARA e Sigma tramite piattaforme come MISP (open source) e Sigma HQ (open source) accelera la copertura di detection nel settore.

MITRE ATT&CK T1546.017 (Udev Rules), tattiche TA0003 e TA0004. Software MITRE S1219 (REPTILE). Detection strategy DET0375 con analytic AN1056 su fonti auditd:SYSCALL e auditd:CONFIG_CHANGE. Consultato MITRE D3FEND per mapping difensivo. Per comandi operativi, sintassi udev/udevadm/auditd e riferimenti a tool (Sysmon for Linux, Atomic Red Team, Sliver, Plaso, YARA, MISP) è stata integrata conoscenza professionale di cybersecurity Linux e DFIR, verificata su documentazione ufficiale dei rispettivi progetti open source.