Cancellazione della Cronologia Comandi: Clear Command History (T1070.003)

La simulazione di questa tecnica in laboratorio è tra le più dirette del framework: non richiede exploit complessi, ma una comprensione granulare di dove ogni sistema operativo conserva la cronologia. L'obiettivo del red teamer è dimostrare che la cancellazione funziona — e, soprattutto, verificare se il blue team la rileva.

Linux e macOS. Il metodo classico è il comando history -c, che svuota la cronologia della sessione corrente in memoria. Tuttavia, questo da solo non elimina il file su disco. Per una pulizia completa durante un engagement, la catena operativa è:

history -c && history -w && rm -f ~/.bash_history

Il flag -w forza la scrittura dello stato (ora vuoto) sul file, e il rm rimuove fisicamente l'artefatto. Per Zsh, il target diventa ~/.zsh_history. Un approccio più sottile consiste nel manipolare la variabile d'ambiente per disabilitare il logging fin dall'inizio della sessione:

unset HISTFILE

oppure

export HISTFILE=/dev/null

Questi comandi impediscono che qualsiasi comando successivo venga registrato. In un red team assessment realistico, è buona pratica eseguire unset HISTFILE come primo comando dopo l'accesso, simulando il comportamento documentato di gruppi come TeamTNT e APT41.

Windows PowerShell. La cronologia di sessione si cancella con:

Clear-History

Ma il vero bersaglio è il file persistente di PSReadLine. Per eliminarlo come ha fatto Medusa Group:

Remove-Item (Get-PSReadlineOption).HistorySavePath

Per disabilitare il logging futuro nella sessione corrente, utile durante l'engagement:

Set-PSReadlineOption -HistorySaveStyle SaveNothing

ESXi. Su server VMware ESXi, il target è il file /var/log/shell.log. La cancellazione può avvenire con un semplice troncamento:

> /var/log/shell.log

oppure con la rimozione selettiva di righe specifiche tramite sed, per un approccio più chirurgico che simula operazioni di APT5.

Dispositivi di rete. Sulla CLI di router e switch, i comandi sono diretti:

clear history clear logging

Per il framework di test, Atomic Red Team (open source) fornisce test atomici pre-confezionati per questa tecnica, eseguibili con il modulo PowerShell Invoke-AtomicRedTeam (open source). I test coprono Linux, macOS, Windows e permettono di validare le detection in modo ripetibile.

Rilevare la cancellazione della cronologia comandi richiede un approccio stratificato: non basta un singolo alert, serve una combinazione di log source che copra il momento dell'azione e il contesto in cui avviene.

Linux — auditd come fondamento. La detection primaria si basa su regole auditd che monitorano le syscall di accesso ai file di cronologia. La logica è intercettare qualsiasi operazione di scrittura, troncamento o cancellazione su percorsi come ~/.bash_history e ~/.zsh_history. Una regola efficace monitora le chiamate unlink, rename e open con flag di troncamento su questi percorsi. Il log source è auditd:SYSCALL.

Il tuning è cruciale: le finestre temporali contano. Un utente che cancella la propria history durante un normale housekeeping è diverso da una sessione root che esegue history -c pochi minuti dopo un accesso SSH. Correla l'evento con il login recente — se la cancellazione avviene entro 5-10 minuti dall'autenticazione, la priorità dell'alert sale.

Le sessioni elevate meritano attenzione speciale: un account root o una sessione sudo priva di cronologia al logout è un segnale forte. Configura un check periodico che verifichi la dimensione dei file history per utenti privilegiati.

Windows — tre log source complementari. Per PowerShell, abilita il Script Block Logging (EventCode 4104) e il Module Logging per intercettare invocazioni di Clear-History e Remove-Item sul percorso PSReadLine. Sysmon (EventCode 23 — FileDelete) cattura la cancellazione del file ConsoleHost_history.txt. Il Security Event Log fornisce il contesto di chi ha effettuato l'operazione.

Il pattern da cercare è duplice: il comando PowerShell stesso e l'operazione filesystem che ne consegue. Un alert che combina entrambi riduce i falsi positivi generati da script di manutenzione legittimi. Per il tuning, mantieni una whitelist degli account di servizio autorizzati a interagire con questi file e focalizza la detection sugli utenti interattivi, specialmente quelli a basso privilegio che cancellano la history — un comportamento quasi sempre anomalo.

ESXi e dispositivi di rete. Per ESXi, il monitoraggio di /var/log/shell.log tramite il log source esxi:shell deve cercare troncamenti o modifiche al file, specialmente dopo login recenti o escalation di privilegi. Sui dispositivi di rete, il syslog deve intercettare i pattern clear history e clear logging — questi comandi non hanno quasi mai un uso legittimo in produzione, quindi il tasso di falsi positivi è naturalmente basso.

Mitigazione preventiva. Implementa il Remote Data Storage (M1029): inoltra la cronologia a un SIEM centralizzato tramite strumenti come Splunk (a pagamento), Graylog (open source) o Wazuh (open source). Se l'attaccante cancella il file locale, la copia remota persiste. Inoltre, proteggi la variabile HISTFILE rendendola read-only tramite Environment Variable Permissions (M1039) e limita i permessi sui file history con Restrict File and Directory Permissions (M1022).

L'analista forense si trova spesso davanti a un paradosso: la cancellazione della cronologia è essa stessa un artefatto. L'assenza di dati, combinata con le tracce residue dell'operazione, racconta la storia dell'intruso.

Linux — ricostruire dai metadati. Anche quando ~/.bash_history è stato cancellato, il filesystem conserva informazioni preziose. Il timestamp di modifica (mtime) del file — o la sua assenza dall'inode table se rimosso — fornisce il momento esatto dell'azione. Se il sistema utilizza ext4, lo strumento debugfs (open source, incluso in e2fsprogs) può recuperare inode orfani e ricostruire il contenuto parziale del file eliminato.

Le regole auditd, se erano attive prima dell'intrusione, conservano nel log audit.log le syscall che hanno toccato il file history. Cerca record con name="/home/<utente>/.bash_history" e syscall unlink o open con flag O_TRUNC. La correlazione temporale tra l'ultimo accesso SSH registrato in auth.log (o secure su RHEL/CentOS) e la cancellazione della history crea un segmento di timeline solido.

Un artefatto spesso trascurato è il file ~/.bash_logout: se l'attaccante ha inserito un comando di pulizia automatica in questo file, la modifica risulterà nel suo mtime. Verifica anche /etc/profile e ~/.bashrc per iniezioni di unset HISTFILE o redirect a /dev/null.

Windows — PSReadLine e oltre. Il file ConsoleHost_history.txt è il target primario. Se eliminato, verifica la presenza nel cestino o nelle Volume Shadow Copy tramite vssadmin (incluso in Windows). Il percorso completo sotto APPDATA permette di attribuire l'azione a uno specifico profilo utente.

L'Event Log di PowerShell è il secondo pilastro. Se lo Script Block Logging era attivo, l'EventCode 4104 potrebbe contenere il testo esatto del comando Clear-History o Remove-Item. Sysmon EventCode 23 (FileDelete) registra l'hash e il percorso del file eliminato.

Per costruire la timeline, allinea questi eventi: autenticazione dell'utente (Security EventCode 4624), avvio sessione PowerShell (EventCode 400/403 nel log PowerShell), eventuali comandi catturati dal Script Block Logging, e infine l'operazione di cancellazione. Lo strumento Hayabusa (open source) è particolarmente efficace per parsare rapidamente grandi volumi di EVTX e identificare pattern di evasione.

ESXi. Se /var/log/shell.log è stato modificato o troncato, verifica i log di hostd.log e vpxa.log per ricostruire l'attività sulla piattaforma. I timestamp di login SSH su ESXi sono registrati separatamente e possono colmare il gap lasciato dalla cancellazione della shell history — un pattern coerente con le operazioni documentate di APT5.

Network device. Per router e switch, i log syslog inoltrati a un collector remoto sono l'unica fonte affidabile post-cancellazione. Se il forwarding era attivo, cerca le entry corrispondenti ai comandi clear logging e clear history, come nel caso di Lazarus Group che eliminava log su router compromessi.

La cancellazione della cronologia comandi attraversa l'intero spettro delle minacce: dal cryptojacking opportunistico allo spionaggio strategico. Gli 8 gruppi documentati rivelano pattern operativi distinti che aiutano a profilare l'avversario e anticipare le sue mosse.

TeamTNT (G0139) rappresenta il profilo del threat actor cloud-native. Il loro uso di history -c è parte di una catena di evasione più ampia focalizzata su ambienti containerizzati e workload cloud. Quando si osserva questa tecnica associata a compromissioni di Docker o Kubernetes, TeamTNT è un candidato primario. Il malware Hildegard (S0601), attribuito a questo gruppo, automatizza la cancellazione con lo stesso comando, integrando l'evasione direttamente nel payload.

APT41 (G0096) adotta un approccio simile su Linux, eliminando le Bash history, ma il contesto è radicalmente diverso: spionaggio e intrusioni supply-chain. La cancellazione della cronologia per APT41 è un tassello di operazioni multi-fase che coinvolgono tipicamente exploitation di applicazioni web-facing. Quando si rileva la pulizia della history in ambienti enterprise Linux, la sovrapposizione con APT41 merita un'analisi approfondita.

Aquatic Panda (G0143) condivide con APT41 il focus su ambienti Linux e l'attenzione alla pulizia delle tracce. L'analista TI dovrebbe considerare questi due gruppi come possibili candidati alternativi quando si osserva cancellazione di history in intrusioni mirate ad organizzazioni del settore tecnologico o delle telecomunicazioni.

APT5 (G1023) introduce un vettore specializzato: la cancellazione della history su server ESXi. Questo targeting infrastrutturale è coerente con il profilo del gruppo, orientato alla compromissione di ambienti virtualizzati. Quando si osserva manipolazione di /var/log/shell.log, APT5 è il riferimento prioritario per l'attribuzione.

Lazarus Group (G0032) estende la tecnica ai dispositivi di rete, con eliminazione routinaria dei log su router compromessi e persino automazione tramite logrotate. Questo pattern di persistenza su network infrastructure è una firma distintiva del gruppo nordcoreano.

Medusa Group (G1051) e Magic Hound (G0059) operano su Windows. Medusa Group utilizza il comando PowerShell specifico per eliminare il file PSReadLine, mentre Magic Hound si concentra sulla rimozione di richieste di esportazione mailbox su server Exchange — un'applicazione più mirata della stessa logica di pulizia tracce. menuPass (G0045) sfrutta wevtutil per rimuovere i log di esecuzione PowerShell, combinando la cancellazione della history con la pulizia dei log di sistema.

Sul fronte malware, Kobalos (S0641) e J-magic (S1203) automatizzano la pulizia: il primo cancella l'intera cronologia comandi sugli host compromessi, il secondo sovrascrive gli argomenti della command line per offuscare l'attività. Entrambi indicano un trend verso l'integrazione dell'evasione nel codice malevolo, riducendo la dipendenza dall'operatore umano.

Il pattern emergente è chiaro: la cancellazione della history è universale, ma il dove e il come differenziano il threat actor. Linux con history -c suggerisce TeamTNT, APT41 o Aquatic Panda. ESXi punta ad APT5. PowerShell/PSReadLine indica Medusa Group. Router e dispositivi di rete sono territorio di Lazarus Group.

Framework MITRE ATT&CK v16 — T1070.003 (Clear Command History), TA0005 (Defense Evasion). Gruppi: G0143, G1051, G0139, G0045, G0059, G0032, G1023, G0096. Software: S1203, S0641, S0601. Mitigazioni: M1029, M1022, M1039. Detection: DET0165, AN0467–AN0471. Tool di detection: auditd, Sysmon, Wazuh, Graylog, Hayabusa, Atomic Red Team. Integrato con conoscenza professionale per tool e procedure operative.