Evasione tramite Attività Utente: User Activity Based Checks (T1497.002)
La tecnica T1497.002 – User Activity Based Checks descrive un insieme di controlli che il malware esegue per verificare la presenza di un utente reale prima di attivare il proprio payload. È una forma raffinata di evasione delle sandbox e degli ambienti virtualizzati, perché anziché cercare artefatti tecnici della VM (registri, driver, MAC address) osserva il comportamento umano: movimenti del mouse, click, cronologia del browser, bookmark, quantità di file sul desktop, apertura e chiusura di documenti.
La tecnica è collocata su due tattiche complementari del framework MITRE ATT&CK. Da un lato TA0005 Defense Evasion, perché il malware si sottrae all'analisi automatizzata restando dormiente in assenza di segnali umani; dall'altro TA0007 Discovery, perché la raccolta di informazioni sull'attività dell'utente serve anche a profilare l'ambiente e orientare le fasi successive.
Nella kill chain queste verifiche si collocano tipicamente subito dopo l'Initial Access, come primo gate del loader, oppure durante la Execution di macro e script embedded. Il payload rimane inerte finché non riceve conferma di trovarsi su un endpoint produttivo. L'impatto operativo è significativo: sandbox commerciali con analisi limitata a 2-5 minuti falliscono nel triggerare campioni che attendono tre click, la chiusura di un documento Word o il doppio click su un'immagine incorporata, come documentato per FIN7, Darkhotel, Okrum, Spark e TONESHELL.
In un ingaggio red team la simulazione di T1497.002 serve a validare la capacità della sandbox aziendale di gestire payload ad attivazione differita. L'obiettivo è dimostrare che un loader realistico può bypassare l'analisi automatica e raggiungere l'endpoint dell'utente.
Su Windows il pattern più semplice replica quanto osservato in Okrum: attendere un numero minimo di click del mouse prima di procedere. In C/C++ si usa GetAsyncKeyState(VK_LBUTTON) dentro un loop con Sleep, incrementando un contatore fino alla soglia. In PowerShell si può ottenere lo stesso effetto con la classe .NET System.Windows.Forms.Control interrogando periodicamente MousePosition e attivando il payload solo dopo N variazioni significative delle coordinate, replicando l'approccio Darkhotel.
Per emulare TONESHELL, la chiamata a GetForegroundWindow eseguita due volte a distanza di alcuni secondi permette di distinguere una sessione utente attiva (dove la finestra in foreground cambia) da una sandbox statica. È una check di poche righe che tuttavia neutralizza molti detonatori automatici.
Per la simulazione dello scenario FIN7, si costruisce un documento Office con immagine embedded e macro VBA legata all'evento di doppio click sull'oggetto grafico, non all'AutoOpen. Il tool maldoc-generator e EvilClippy (open source) sono utili per la manipolazione delle proprietà del documento, mentre oletools (open source) serve al red team stesso per verificare che la macro non sia banale da estrarre in analisi statica.
Su Linux si può implementare un check equivalente leggendo ~/.bash_history, contando le voci in ~/Desktop o ~/Documents, oppure interrogando lo stato input di X11 tramite xdotool (open source) con xdotool getactivewindow. Su macOS l'API CGEventSourceSecondsSinceLastEventType restituisce i secondi trascorsi dall'ultimo input utente ed è ideale per un idle-check silenzioso.
Per il testing controllato dei payload, la sandbox Cuckoo Sandbox (open source) e CAPE Sandbox (open source) offrono moduli di simulazione input (human.py) che il red team può usare per verificare quali soglie di interazione il proprio loader supera. Any.Run (freemium) permette il triage manuale con interazione reale, utile per confrontare la resa contro sandbox commerciali. La reportistica finale deve elencare per ogni check quale sandbox aziendale è stata bypassata e con quale tempo di attesa, fornendo al SOC parametri concreti per il tuning.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo