Anti-VM Checks: System Checks (T1497.001)
La sottotecnica T1497.001 descrive i controlli che il codice malevolo esegue sul sistema ospite per capire se sta girando dentro una macchina virtuale, un sandbox o un ambiente di analisi. Quando questi controlli danno esito positivo, il malware cambia comportamento: si spegne, entra in un loop infinito, nasconde le proprie funzioni principali oppure evita di scaricare payload secondari, riducendo drasticamente la probabilità di essere osservato dagli analisti.
La tecnica si colloca a cavallo di due tattiche. Da un lato TA0005 (Defense Evasion / Stealth), perché l'obiettivo è mimetizzarsi ed evitare l'analisi automatizzata senza toccare i controlli di sicurezza. Dall'altro TA0007 (Discovery), poiché per decidere se disingaggiarsi l'attaccante deve prima raccogliere informazioni su hardware, processi, registro e rete.
Dal punto di vista della kill chain, questi controlli agiscono tipicamente subito dopo l'esecuzione iniziale e prima del dispiegamento del carico utile vero e proprio, funzionando da "gate" condizionale.
L'impatto sull'ecosistema difensivo è ampio: la tecnica è impiegata da 7 gruppi APT, implementata in 61 famiglie di software e osservata in 2 campagne documentate. La varietà degli indicatori esaminati — dal numero di core CPU alla temperatura del sensore hardware, dai driver VMware ai nomi utente tipici dei sandbox — rende questa evasione uno dstacolo ricorrente nei laboratori di analisi malware.
Simulare T1497.001 in un esercizio red team significa replicare la logica di "gate" condizionale che decide se proseguire o abortire. Il modo più pulito e riproducibile è appoggiarsi a al-khaser (open source), un progetto che raccoglie centinaia di controlli anti-VM, anti-debug e anti-sandbox; il malware Nightdoor ne incorpora direttamente il codice, quindi è un riferimento realistico. In laboratorio si compila il progetto e lo si esegue su host bare-metal e su VM per confrontare gli esiti.
Su Windows, la via classica è l'interrogazione WMI del produttore hardware. La logica usata da Kimsuky e da molte famiglie come Snip3 si riproduce con PowerShell:
Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object Manufacturer,Model
Un valore come "VMware, Inc." o "innotek GmbH" tradisce l'ambiente virtuale. Il controllo termico impiegato da OopsIE e GravityRAT si ottiene con:
Get-CimInstance -Namespace root/WMI -ClassName MSAcpi_ThermalZoneTemperature
Su una VM la classe spesso non restituisce dati. Altri controlli semplici: enumerare i processi alla ricerca di vmtoolsd.exe (come fa PlugX), contare i core con la variabile d'ambiente %NUMBER_OF_PROCESSORS%, o verificare la presenza di Sbiedll.dll fra i moduli caricati (Saint Bot).
Su Linux i comandi da concatenare in uno script burst sono nativi: systemd-detect-virt riporta direttamente l'hypervisor rilevato, mentre dmidecode -s system-manufacturer, lscpu e lspci espongono stringhe come QEMU, VirtualBox o Xen (richiede privilegi root per dmidecode).
Su macOS, la strada seguita da OSX_OCEANLOTUS.D e macOS.OSAMiner passa da strumenti di sistema:
sysctl hw.model
system_profiler SPHardwareDataType
Si valutano modello, numero di core e uptime del kernel per distinguere hardware reale da ambiente emulato.
Su ESXi/hypervisor, la simulazione riguarda più la porta di I/O speciale di VMware (sfruttata da Grandoreiro e Attor) e l'istruzione vpcext per Virtual PC: questi si testano con payload nativi che catturano l'eccezione generata su hardware reale.
Per il framework offensivo, la campagna Frankenstein dimostra l'uso di Empire (open source) con script WMI che abortivano se i core erano meno di due. In laboratorio conviene parametrizzare le soglie — RAM sotto 2 GB, meno di quattro CPU, disco piccolo — come fanno Pikabot, Okrum e Mini Shai-Hulud, per verificare quanto il proprio sandbox risulti "credibile" e affinare i profili di detonazione.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo