Evasione Temporale: Time Based Checks (T1497.003)
La tecnica T1497.003 — Time Based Checks appartiene alla famiglia della Virtualization/Sandbox Evasion e viene mappata su due tattiche complementari: TA0005 (Defense Evasion) e TA0007 (Discovery). Il principio è semplice ma efficace: il malware misura il tempo che scorre nell'ambiente in cui viene eseguito per capire se si trova su una macchina reale oppure dentro una sandbox che accelera artificialmente il clock o interrompe le chiamate a Sleep per velocizzare l'analisi.
In pratica, l'attaccante usa API come GetTickCount, GetSystemTimeAsFileTime, QueryPerformanceCounter su Windows, oppure syscall clock_gettime e gettimeofday su Linux/macOS, campionando i valori prima e dopo un'operazione di sleep. Se il delta osservato non corrisponde a quello atteso, il codice deduce di essere sotto analisi e termina o rimane dormiente.
Nella kill chain la tecnica si colloca tra Initial Access e Execution: è tipicamente il primo controllo che un loader esegue prima di scaricare il payload finale. I dati MITRE censiscono 45 famiglie malware e 1 campagna documentata (Operation Dream Job di Lazarus Group) che sfruttano varianti di questo approccio. L'impatto operativo è duplice: da un lato riduce drasticamente il rilevamento nelle sandbox commerciali con timeout brevi (2-5 minuti), dall'altro complica la threat hunting perché sposta l'attività malevola oltre la finestra di osservazione automatizzata.
In un esercizio red team la simulazione di T1497.003 serve a validare la resilienza delle sandbox aziendali e la capacità dell'EDR di riconoscere pattern di stalling. La logica di base è banale in C: due chiamate a GetTickCount64() separate da uno Sleep(N), con confronto del delta rispetto al valore atteso. Se il delta è significativamente inferiore, il processo si autoelimina o entra in un ramo benigno.
Un esempio operativo Windows compilabile con MinGW o MSVC:
DWORD64 t1 = GetTickCount64(); Sleep(60000); DWORD64 t2 = GetTickCount64(); if ((t2 - t1) < 55000) ExitProcess(0);
Su Linux la stessa logica sfrutta clock_gettime(CLOCK_MONOTONIC, &ts) con confronto pre/post nanosleep(). Su macOS si usa mach_absolute_time() combinato con mach_timebase_info() per convertire in nanosecondi.
Per emulare la catena vista in famiglie come Ursnif o SUNBURST, il red teamer può concatenare più tecniche: un delay iniziale di 30 minuti (Ursnif) o fino a due settimane (SUNBURST) tramite scheduled task che pianifica l'esecuzione differita, evitando loop attivi facilmente rilevabili. Il comando nativo schtasks /create /tn EvasionTest /tr payload.exe /sc once /st HH:MM è utile in lab per replicare questo comportamento.
Strumenti utili in laboratorio:
- al-khaser (open source) — suite di test anti-analysis con moduli specifici per timing checks, include implementazioni di RDTSC, GetTickCount e NtDelayExecution.
- Pafish (open source) — tool storico di Alberto Ortega per verificare quali indicatori di virtualizzazione una sandbox espone, include check temporali.
- VMDE e InviZzzible (open source) — batterie di test complete per validare la copertura anti-evasion.
- Sliver (open source) e Havoc (open source) — framework C2 moderni con opzioni di sleep jitter configurabili, utili per replicare comportamenti come quelli descritti per S1229 (Havoc) e S1039 (Bumblebee).
- Brute Ratel C4 (a pagamento) — usa NtDelayExecution come documentato in S1063, ma è ristretto a red team accreditati.
Un pattern avanzato consiste nell'API hammering visto in TrickBot (S0266): invece di chiamare Sleep(), il malware esegue milioni di iterazioni di printf o I/O su file temporanei per consumare wall-clock time senza triggerare hook sulle API di sleep. In lab si replica con un ciclo for (int i=0; i<10000000; i++) fprintf(fp, "%d", i);, efficace contro sandbox che intercettano solo Sleep e NtDelayExecution.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo