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

Per comprendere come gli attaccanti operano, è fondamentale replicare le tecniche in ambiente controllato. Su Linux, il comando più immediato è history -c che svuota completamente la cronologia della sessione corrente. Questo non elimina però il file persistente ~/.bash_history, che richiede un'azione separata.

La sequenza tipica su sistemi Linux prevede prima l'esecuzione dei comandi malevoli, poi la pulizia delle tracce:

rm ~/.bash_history
history -c

Su Windows con PowerShell, la situazione è più articolata. Il comando Clear-History pulisce solo la cronologia della sessione corrente, mentre il file persistente richiede un'eliminazione manuale:

Remove-Item $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
Clear-History

Per i sistemi ESXi, l'approccio è diverso. Gli attaccanti manipolano direttamente il file di log:

echo "" > /var/log/shell.log

Sui dispositivi di rete, i comandi variano ma seguono pattern simili. Cisco utilizza clear logging e clear history, mentre altri vendor hanno sintassi specifiche ma concettualmente equivalenti.

Un approccio più sofisticato prevede la manipolazione della variabile d'ambiente HISTFILE su Linux. Impostandola su /dev/null prima di eseguire comandi, si impedisce la registrazione ab origine:

export HISTFILE=/dev/null
# comandi malevoli qui
unset HISTFILE

Gli attaccanti esperti combinano queste tecniche con timestamp manipulation per rendere l'analisi ancora più complessa. La sequenza operativa include sempre verifiche pre e post cancellazione per assicurarsi dell'effettiva rimozione delle tracce.

La detection di questa tecnica richiede un approccio multi-livello che vada oltre il semplice monitoraggio dei comandi. Il primo layer di difesa consiste nel tracciare le syscall attraverso auditd su Linux, monitorando specificamente le operazioni su file come ~/.bash_history.

Su Windows, il monitoraggio deve coprire sia gli eventi PowerShell (EventID 4104) che le operazioni file tramite Sysmon (EventID 11). La chiave sta nell'identificare pattern comportamentali sospetti piuttosto che singoli eventi.

Un alert efficace deve considerare il contesto temporale. La cancellazione della cronologia subito dopo login o escalation di privilegi è altamente sospetta. Configurate finestre temporali di 5-10 minuti post-autenticazione come periodo critico.

Per ridurre i falsi positivi, implementate whitelist basate su:

• Account di servizio che legittimamente non mantengono cronologia
• Script di manutenzione schedulati che puliscono log
• Utenti amministrativi durante attività di troubleshooting documentate

La correlazione tra eventi diversi aumenta drasticamente l'efficacia. Ad esempio, combinare:

Nuovo login SSH + Esecuzione comandi privilegiati + Cancellazione history = Alert critico

Per ESXi, monitorate le modifiche a /var/log/shell.log attraverso l'API vSphere o agenti dedicati. La truncation del file o modifiche massive sono indicatori affidabili.

Sui dispositivi di rete, il syslog centralizzato è essenziale. Configurate alert per comandi come clear history eseguiti fuori dalle window di manutenzione pianificate.

L'automazione della risposta può includere il backup immediato dei file di cronologia prima che vengano cancellati, utilizzando tool come osquery per snapshot periodici dello stato del sistema.

Quando la cronologia comandi è stata cancellata, la ricostruzione richiede creatività e conoscenza approfondita degli artefatti alternativi. Su Linux, anche se ~/.bash_history è vuoto, esistono tracce residue in memoria, file di swap e journal di systemd.

Il comando strings applicato alla memoria dump può rivelare comandi recenti:

strings /proc/[PID]/mem | grep -E "^(sudo|ssh|wget|curl)"

Windows offre maggiori opportunità forensi grazie alla verbosità del sistema. Anche con ConsoleHost_history.txt cancellato, verificate:

• Prefetch files che mostrano esecuzione di powershell.exe
• Registry keys in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
• Windows Timeline database per attività recenti

APT41 è noto per cancellare bash history ma spesso dimentica i log di sudo in /var/log/secure. Questo pattern è comune: gli attaccanti puliscono selettivamente, lasciando tracce in location meno ovvie.

Su ESXi, anche con /var/log/shell.log vuoto, esaminate:

• VMkernel logs per operazioni amministrative
• Backup automatici in /var/log/shell.log.old
• vCenter logs se il sistema è gestito centralmente

La timeline reconstruction deve integrare multiple fonti. Create una matrice temporale che includa:

1. Ultimo timestamp valido nella cronologia
2. Eventi di autenticazione dai log di sistema
3. Modifiche ai file di configurazione
4. Traffico di rete anomalo nello stesso timeframe

TeamTNT tipicamente esegue history -c dopo installazione di cryptominer, ma i log di rete mostrano download da pool di mining. Questa discrepanza temporale è un indicatore affidabile di compromissione.

L'analisi dei gruppi che utilizzano questa tecnica rivela pattern operativi distintivi. Lazarus Group integra la cancellazione logs nei propri tool automatizzati, utilizzando logrotate per pulizie programmate su router compromessi. Questa sofisticazione indica operazioni a lungo termine con necessità di mantenere accesso persistente.

Magic Hound mostra preferenza per ambienti Microsoft, cancellando specificamente PowerShell execution logs con Wevtutil e rimuovendo export request da Exchange. Il focus su infrastrutture email suggerisce obiettivi di spionaggio e data exfiltration.

APT5 si distingue per il targeting di ambienti virtualizzati, specificamente ESXi. La cancellazione della command history su hypervisor indica operazioni mirate a compromettere intere infrastrutture virtuali, possibilmente per ransomware o distruzione dati.

Aquatic Panda e APT41 mostrano sovrapposizioni tecniche interessanti. Entrambi operano prevalentemente su Linux, ma APT41 tende a cancellazioni più selettive mentre Aquatic Panda opta per pulizie complete post-operazione.

Il malware Kobalos rappresenta l'evoluzione automatizzata: rimuove command history su tutti gli host compromessi come parte del proprio ciclo operativo. Hildegard, focalizzato su container, usa history -c specificamente in ambienti Kubernetes.

I pattern geografici emergono chiaramente: gruppi Asia-Pacific preferiscono Linux/ESXi, mentre attori Middle East come Magic Hound si concentrano su Windows/Exchange. Questa specializzazione riflette i target primari nelle rispettive regioni.

Le previsioni per evoluzione tattica includono:

• Maggiore automazione nella pulizia selettiva di log
• Targeting di nuovi interpreter (zsh, fish) man mano che guadagnano popolarità
• Integrazione con tecniche di timestomping per mascherare meglio le timeline

Framework MITRE ATT&CK T1070.003. Documentazione delle campagne di Lazarus Group, APT41, TeamTNT e Magic Hound. Risorse di detection da Elastic, Splunk e Microsoft per configurazioni SIEM. Guide di hardening da CIS e NIST per protezione dei sistemi.