Cancellazione Cronologia Comandi: Prevent Command History Logging (T1690)
La tecnica T1690 – Prevent Command History Logging rientra nella tattica TA0112 (Defense Impairment) e descrive tutte le manipolazioni che un attaccante mette in atto per impedire che i comandi digitati vengano registrati nei file di cronologia della shell. Su sistemi Unix-like la cronologia è governata dalle variabili d'ambiente HISTFILE, HISTCONTROL e HISTFILESIZE, che decidono dove salvare i comandi e quali escludere; su Windows la stessa funzione è svolta dal modulo PSReadLine di PowerShell, che scrive di default in ConsoleHost_history.txt. Anche gli hypervisor ESXi e i network device CLI (Cisco, Juniper, Fortinet) offrono meccanismi analoghi, disattivabili con comandi come no logging.
L'impatto operativo è significativo perché la cronologia rappresenta spesso l'unica traccia post-esecuzione dei comandi interattivi eseguiti dall'attaccante durante fasi di Execution, Discovery e Lateral Movement. I dati MITRE riportano 4 gruppi APT, 6 famiglie di malware e 2 campagne documentate che utilizzano questa tecnica, tra cui APT38, Sea Turtle, UNC3886 e Medusa Group, con impianti sofisticati come BPFDoor, VIRTUALPITA e BRICKSTORM. La tecnica è particolarmente insidiosa perché non genera artefatti evidenti: l'assenza di dati è essa stessa il segnale, e richiede quindi detection basata su correlazione tra sessione attiva e file vuoto.
In un ingaggio red team, la soppressione della cronologia va integrata nella fase iniziale di ogni sessione interattiva post-exploitation. Su Linux e macOS la sequenza tipica prevede l'annullamento immediato delle variabili prima di qualsiasi altro comando:
unset HISTFILE
export HISTFILESIZE=0
export HISTCONTROL=ignorespace
Con HISTCONTROL=ignorespace attivo, qualsiasi comando preceduto da uno spazio non viene registrato — un trucco usato da APT38 per operare in modo invisibile. In alternativa, il redirezionamento su /dev/null con export HISTFILE=/dev/null replica il comportamento osservato in BPFDoor e BRICKSTORM. Ricorda che unset HISTFILE è più elegante ma può essere ripristinato da .bashrc: verifica sempre il contenuto dei profile file prima di operare.
Per MySQL client, imposta export MYSQL_HISTFILE=/dev/null prima di connetterti, come fa BPFDoor per evitare tracce in ~/.mysql_history. Su ESXi la stessa logica si applica alla shell tramite unset HISTFILE, e va combinata con l'arresto di vmsyslogd per impedire il forwarding — pattern osservato in VIRTUALPITA.
Su Windows, PowerShell 5.1+ registra tutto tramite PSReadLine. Le opzioni operative sono due:
Set-PSReadLineOption -HistorySaveStyle SaveNothing
oppure la cancellazione retroattiva usata da Medusa Group:
Remove-Item (Get-PSReadlineOption).HistorySavePath
Attenzione: queste azioni non disabilitano Script Block Logging (Event ID 4104) né Module Logging se attivi via GPO. Per un bypass completo servono tecniche aggiuntive come quelle implementate da SILENTTRINITY (open source), che esegue codice PowerShell unmanaged da memoria evadendo ScriptBlock logging. Per test in laboratorio, framework come Atomic Red Team (open source) forniscono test case pronti per T1562.003, mentre Caldera (open source) di MITRE include payload per simulare la catena completa.
Sui network device, in un lab con GNS3 (open source) o EVE-NG (freemium) puoi simulare no logging monitor, no logging buffered e no logging host su IOS Cisco per replicare l'attività di ArcaneDoor. Su Junos, set system syslog file messages any none produce effetto analogo. Documenta sempre ogni comando eseguito in un log parallelo out-of-band per non compromettere il report finale.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo