Sabotaggio di auditd: Disable or Modify Linux Audit System Log (T1685.004)

In un contesto di red team autorizzato, la simulazione di T1685.004 richiede privilegi di root sull'host target. La prima famiglia di azioni riguarda la sospensione diretta del demone. Su distribuzioni con systemd si può usare systemctl stop auditd seguito da systemctl mask auditd per impedirne la riattivazione automatica. Su sistemi più vecchi o durante esercizi "noisy on purpose", service auditd stop oppure pkill -9 auditd producono lo stesso effetto ma sono più rumorosi perché generano eventi di terminazione osservabili prima dello spegnimento.

Un approccio più chirurgico consiste nel manipolare le regole runtime senza fermare il servizio. Con auditctl -D si eliminano tutte le regole caricate, mentre auditctl -e 0 disabilita l'intero motore di auditing mantenendo però il processo attivo — utile per non far scattare allarmi basati sulla morte del PID di auditd. Per la persistenza tra reboot, la modifica di /etc/audit/audit.rules o dei file drop-in in /etc/audit/rules.d/ rimuove le regole al successivo avvio.

Una variante più sofisticata prevede l'iniezione di regole di esclusione mirate: aggiungere direttive come -a never,exit -F arch=b64 -F exe=/percorso/binario-malevolo fa sì che auditd ignori qualunque syscall proveniente dal proprio impianto offensivo, lasciando intatto il resto del logging e riducendo il rischio di rilevamento comportamentale basato su "assenza totale di log".

Per emulare Ebury, che opera in modo più invasivo, si può ricorrere al hooking delle funzioni della libreria libaudit tramite LD_PRELOAD con una shared object custom. Il progetto Atomic Red Team (open source) contiene test allineati alla tecnica T1562.012 (predecessore di T1685.004) che possono essere adattati; il repository include invocazioni dirette di auditctl e modifiche a audit.rules pronte per esecuzione controllata in laboratorio.

Per verificare l'efficacia della simulazione, il red team dovrebbe generare attività "canary" prima e dopo la manipolazione — ad esempio cat /etc/shadow o l'esecuzione di un binario in /tmp — e confrontare l'output di ausearch -k o l'ispezione diretta di /var/log/audit/audit.log. L'assenza degli eventi attesi conferma il successo. È buona prassi documentare il PID di auditd prima e dopo, lo stato riportato da auditctl -s (che mostra enabled, pid, rate_limit e lost), e ripristinare la configurazione originale al termine dell'esercizio tramite backup pre-esecuzione dei file di regole.

Il rilevamento di T1685.004 si fonda su un principio apparentemente paradossale: monitorare uno strumento di monitoraggio. L'analista SOC deve costruire logica di detection che intercetti sia le azioni esplicite di manipolazione sia i loro effetti indiretti, tipicamente rappresentati da lacune temporali nel flusso di eventi.

Le fonti di log primarie sono lo stesso auditd (record EXECVE, SYSCALL, CONFIG_CHANGE e DAEMON_END), il journal di systemd interrogabile con journalctl -u auditd, e il syslog tradizionale. Un evento DAEMON_END seguito dall'assenza prolungata di record successivi è un pattern ad alta confidenza. Analogamente, i record CONFIG_CHANGE con campo op=remove_rule o op=set su parametro enabled segnalano modifiche runtime alle regole tramite auditctl.

Per costruire regole SIEM efficaci conviene concentrarsi su tre famiglie di segnali. La prima è l'esecuzione di comandi sospetti: catene di processo che includono auditctl -D, auditctl -e 0, systemctl stop auditd, systemctl mask auditd, service auditd stop, oppure kill/pkill con target il PID di auditd. La seconda è la scrittura su file sensibili: qualunque modifica a /etc/audit/audit.rules, /etc/audit/auditd.conf o ai file in /etc/audit/rules.d/ eseguita da utenti diversi dagli account di configuration management noti. La terza è l'anomalia strutturale: gap temporali nella cadenza di eventi auditd correlati a sessioni con privilegi elevati (uid=0 o euid=0 recentemente escalated).

Il framework Sigma (open source) include regole pubbliche per la disabilitazione di auditd che possono essere adattate al proprio SIEM. Strumenti come Wazuh (open source) e Elastic Security (freemium) offrono ruleset preconfezionati per l'integrità delle configurazioni auditd tramite modulo FIM. Per deployment su larga scala, osquery (open source) permette di interrogare periodicamente la tabella processes filtrando su name = 'auditd' e la tabella file per hash dei file di configurazione, generando alert su discrepanze.

Sul fronte dei falsi positivi, le finestre di manutenzione pianificata rappresentano la fonte principale di rumore. È essenziale mantenere una whitelist di change ticket approvati correlata agli utenti autorizzati e agli host in maintenance mode. Aggiornamenti di pacchetti come audit o audit-libs via yum/apt possono legittimamente riavviare il demone; correlare gli eventi con i log del package manager (/var/log/dpkg.log, /var/log/yum.log) permette di distinguere. Come contromisura preventiva, la mitigazione M1047 raccomanda di aggiungere -e 2 come ultima direttiva in audit.rules, rendendo la configurazione immutabile fino al prossimo reboot — qualunque tentativo di modifica successivo verrà rifiutato e registrato.

L'analisi forense di un host sospettato di aver subito T1685.004 parte dalla constatazione che le fonti primarie di evidenza sono, per definizione, potenzialmente compromesse. L'approccio corretto è quindi triangolare tra artefatti di più sottosistemi.

Il primo passo è l'ispezione di /var/log/audit/audit.log e dei file ruotati (audit.log.1, audit.log.2 eccetera in base alla configurazione di max_log_file e num_logs). L'analista cerca la sequenza di eventi terminale: un record type=DAEMON_END con auid diverso da -1 identifica l'utente che ha causato la terminazione. Se il log si interrompe bruscamente senza record DAEMON_END, è probabile che sia stato usato kill -9, che non lascia opportunità al demone di scrivere il proprio evento di shutdown. La differenza tra il timestamp dell'ultimo record e il tempo di sistema attuale quantifica la finestra di cecità.

Gli artefatti di supporto includono il journal di systemd, recuperabile con journalctl --unit=auditd --since= anche da immagine forense montata (puntando a /var/log/journal/). Il journal spesso conserva eventi Stopped Security Auditing Service con il PID e l'utente invocante, indipendentemente dalla manipolazione di auditd stesso. Il file /var/log/wtmp, la history bash degli utenti privilegiati in ~/.bash_history (se non ripulita), e i log di sudo in /var/log/auth.log o /var/log/secure completano la timeline.

Per i file di configurazione, il confronto con backup noti o con la versione del pacchetto — ottenibile tramite rpm -Vf /etc/audit/audit.rules su sistemi RHEL-based o debsums su Debian — evidenzia modifiche non autorizzate. Il timestamp mtime del file, incrociato con ctime (change time dell'inode), aiuta a datare l'alterazione anche quando l'attaccante ha manomesso mtime con touch -t.

In caso di sospetto hooking tramite LD_PRELOAD — tecnica documentata per Ebury (S0377), che disabilita OpenSSH, systemd e auditd quando la backdoor è attiva — l'analista deve esaminare /etc/ld.so.preload, le variabili d'ambiente dei processi sospetti in /proc//environ, e le librerie mappate in /proc//maps. La presenza di shared object in percorsi non standard (/tmp, /dev/shm, /var/tmp) mappati nello spazio di auditd o di processi correlati è un forte indicatore.

Per preservare la catena di custodia, l'acquisizione deve avvenire con strumenti forensi consolidati: dd o dc3dd (open source) per l'imaging dei volumi, LiME (open source) per il dump della memoria fisica utile a recuperare regole auditd runtime non ancora scritte su disco, e Volatility 3 (open source) con profili Linux per analizzare la memoria acquisita. Il modulo linux.pslist e linux.check_modules di Volatility può rivelare rootkit kernel-mode che intercettano le syscall a monte del sottosistema audit.

Il dataset MITRE per T1685.004 non censisce gruppi APT formalmente attribuiti, ma include un caso software di rilievo strategico: Ebury (S0377). Ebury è una backdoor OpenSSH di lunga durata, storicamente associata a campagne di credential harvesting e proxying del traffico su larga scala verso l'ecosistema hosting Linux. La sua caratteristica distintiva rispetto a molte altre famiglie di malware Linux è proprio l'integrazione nativa di capacità anti-forensiche: quando la backdoor è attiva, disabilita simultaneamente OpenSSH logging, systemd journaling e il demone auditd, creando un ambiente di esecuzione operativamente cieco per il difensore.

Dal punto di vista dell'intelligence, il fatto che un singolo software così longevo domini il dataset per questa sottotecnica suggerisce due considerazioni. La prima è che la manipolazione di auditd rimane un'attività di nicchia rispetto alle tecniche equivalenti su Windows (dove la disabilitazione di Event Log è più frequentemente osservata e attribuita), riflettendo la minore penetrazione di EDR e SIEM sui workload Linux server, dove spesso l'assenza di monitoring rende superfluo l'atto stesso di sabotare i log. La seconda è che gli attori che effettivamente implementano questo comportamento tendono a essere operatori sofisticati con obiettivi a lungo termine — server compromission per hosting, cryptomining, proxying — piuttosto che ransomware operator, che preferiscono velocità a stealth.

Il pattern operativo osservabile in Ebury è indicativo del profilo di rischio associato: compromissione iniziale via credenziali SSH deboli o riutilizzate, escalation a root spesso non necessaria perché la compromissione avviene già a livello privilegiato, deployment della backdoor con contestuale neutralizzazione della telemetria. Questo modello è geograficamente agnostico ma statisticamente sovra-rappresentato su infrastrutture di hosting provider, data center e sistemi esposti direttamente su internet.

Sul piano dei trend prospettici, l'adozione crescente di soluzioni EDR Linux commerciali e di framework open source come Falco (open source, sponsorizzato CNCF) e Tracee (open source, Aqua Security) sta introducendo canali di telemetria basati su eBPF che operano indipendentemente da auditd e sono considerevolmente più difficili da manipolare, poiché richiedono privilegi kernel-level e conoscenza specifica dei probe attivi. Ci si può attendere che gli attori più capaci evolvano verso tecniche di kernel-level tampering — unhooking di eBPF program, manipolazione di bpf() syscall — mentre la disabilitazione di auditd rimarrà uno strumento sufficiente contro target meno maturi.

Per il CISO, la lezione strategica è che investire in una singola fonte di telemetria kernel-level è insufficiente: la ridondanza tra auditd, eBPF-based tooling e log applicativi (SSH, sudo, journal) costituisce l'unica difesa robusta contro un avversario che ha già raggiunto privilegi di root.

MITRE ATT&CK: tecnica T1685.004 (Disable or Modify Linux Audit System Log), tattica TA0112 (Defense Impairment), software S0377 (Ebury), mitigazioni M1018 (User Account Management) e M1047 (Audit), detection DET0062 con analytic AN0171. Framework difensivo MITRE D3FEND per artefatti Process e File Modification. Contenuti operativi su comandi auditctl, systemctl, tool Atomic Red Team, Sigma, Wazuh, osquery, Falco, Tracee, Volatility 3, LiME e dc3dd derivano da conoscenza professionale verificabile su repository e documentazione ufficiale dei rispettivi progetti.