Cancellazione Log di Sistema Linux/macOS: Clear Linux or Mac System Logs (T1685.006)
La tecnica T1685.006 descrive la cancellazione o l'alterazione dei log di sistema su ambienti Linux e macOS con l'obiettivo di rimuovere le tracce di un'intrusione. Si colloca nella tattica TA0112 (Defense Impairment), categoria che raggruppa le azioni finalizzate a degradare la fiducia e l'efficacia dei controlli difensivi, tipicamente eseguite nelle fasi tardive di una kill chain — quando l'attaccante ha già ottenuto persistenza e privilegi elevati e vuole prolungare la propria permanenza nel sistema.
Su sistemi Unix-like la maggior parte del logging nativo risiede sotto /var/log/, con sottocartelle dedicate a categorie specifiche: messages per eventi generali, auth.log o secure per l'autenticazione, wtmp/utmp/btmp per il tracciamento delle sessioni, kern.log per il kernel, cron.log per lo scheduler, maillog per il mail server e httpd/ per i web server. La rimozione o il troncamento selettivo di questi file compromette sia il monitoraggio in tempo reale sia la ricostruzione forense post-incidente.
I dati MITRE ATT&CK associano alla tecnica 4 gruppi APT (Rocke, TeamTNT, Sea Turtle, Salt Typhoon), 4 famiglie malware (Proton, MacMa, UPSTYLE, JumbledPath) e 3 mitigazioni primarie centrate su restrizione permessi, forwarding remoto e cifratura degli eventi. L'assenza di campagne mappate riflette la natura trasversale della tecnica, impiegata come step ricorrente in intrusioni molto diverse per obiettivo e vettore iniziale.
In un ingaggio red team autorizzato la simulazione di T1685.006 serve a validare la resilienza della pipeline di logging e la capacità del SOC di rilevare il log tampering prima che l'evidenza scompaia. Prima di operare, verifica sempre di avere autorizzazione scritta e un ambiente di laboratorio isolato: la rimozione di log su sistemi in produzione senza rules of engagement esplicite è distruttiva e non riproducibile.
Le primitive utilizzate dagli attaccanti reali sono banali dal punto di vista sintattico e proprio per questo insidiose. Un operatore con privilegi di root può azzerare un file di log senza cancellarlo — mantenendo l'inode e ingannando controlli superficiali — con una redirezione nulla:
: > /var/log/auth.log
oppure con truncate -s 0 /var/log/wtmp. La rimozione completa avviene con rm -f /var/log/syslog, mentre per cancellare selettivamente sessioni dai binari utmp/wtmp/btmp si usano storicamente tool come utmpdump (parte di util-linux, open source) in combinazione con editing e rescrittura, oppure utility dedicate come wtmp-cleaner e varianti presenti nei toolkit post-exploitation.
Per la history della shell, gli attaccanti disabilitano il tracciamento con unset HISTFILE o export HISTFILE=/dev/null prima di operare, oppure ripuliscono a posteriori con history -c && history -w. Su macOS il sistema di logging unificato introdotto con Sierra rende meno efficace la cancellazione dei file testuali sotto /var/log/: il comando log (nativo) legge da un ring buffer binario. Malware come MacMa e Proton puliscono comunque i file classici sotto /var/log e /Library/Logs per rimuovere tracce applicative.
Per strutturare un esercizio realistico puoi usare Atomic Red Team (open source) di Red Canary, che include test allineati alle tecniche ATT&CK inclusa la manipolazione dei log, e Caldera (open source) di MITRE per orchestrare catene end-to-end. Un flusso tipico prevede: initial access simulato, escalation a root, esecuzione del payload di interesse, cancellazione mirata dei log delle ultime N ore, verifica lato SIEM che l'evento di tampering sia stato correlato.
Annota tempi esatti, comandi eseguiti e utente utilizzato: il report deve permettere al blue team di ricostruire quali detection hanno funzionato e quali gap emergono nelle regole di correlazione sul log source integrity.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo