Analisi Malware con Sandbox: Detonazione Sicura e Behavioral Analysis

Ci arriva un file sospetto da un cliente. Una mail con allegato .docx che sembra una fattura, ma il macro è offuscato. L’utente ha cliccato. Ora abbiamo un processo sconosciuto in esecuzione sulla rete. Cosa facciamo? Lo eseguiamo sul nostro portatile? No. Lo analizziamo in una sandbox, osserviamo il comportamento e decidiamo il da farsi. L’analisi malware con sandbox – detonazione e behavioral analysis – è il primo passo di un incident response serio. Vediamo come si fa, con gli strumenti giusti e senza improvvisazione.

Perché una Sandbox? Il Problema dell’Isolamento

Il concetto è semplice: esegui un file sospetto in un ambiente controllato, isolato dal resto della rete. Se è malware, si scatena ma non fa danni. Noi, di Meteora Web, abbiamo visto troppi casi in cui un analista per fretta ha lanciato un .exe sulla macchina di lavoro. Risultato: infezione propagata. La sandbox è il primo dispositivo di contenimento. Non serve solo per la ricerca accademica: è uno strumento operativo per chi risponde a incidenti.

Ci sono due approcci: sandbox hardware (un PC fisico dedicato, con snapshot) e sandbox software (macchine virtuali orchestrate come Cuckoo, CAPE, o servizi cloud come Joe Sandbox). Noi preferiamo le soluzioni software per il rapporto costo/automazione. Ma attenzione: i malware moderni rilevano se sono in una VM. Un sandboxing efficace richiede tecniche di anti-evasion.

Tipi di Sandbox e Scelta Operativa

Le sandbox si dividono in tre famiglie principali:

• Sandbox tradizionali (Cuckoo/CAPE): usano QEMU o VirtualBox per eseguire il campione. Rilevano modifiche a file system, registro, processi, rete. Ottime per analisi di behavioral. Richiedono un host Linux e una VM guest Windows (sconsigliato Linux come guest per la maggior parte dei malware).
• Sandbox hardware (Fireeye, Lastline): appliance dedicate, costose, ma con poca evasione possibile. Non sempre accessibili a PMI.
• Sandbox cloud (Joe Sandbox, Hybrid Analysis, Intezer): comode per campioni singoli, ma attenzione alla riservatezza dei dati (non inviare documenti sensibili).

Per un team di incident response che lavora quotidianamente, la scelta migliore è CAPE (Config And Payload Extraction), fork di Cuckoo con maggiore supporto per evasione e dumping di config. Lo usiamo nei nostri progetti di sicurezza, integrato con Splunk o TheHive per correlare gli eventi.

Allestimento di una sandbox CAPE (passi essenziali)

1. Server host: Ubuntu 22.04 LTS, almeno 16 GB RAM, 4 core, SSD. Più VM guest si vogliono eseguire in parallelo, più risorse servono.
2. Installazione CAPE: git clone https://github.com/kevoreilly/CAPEv2; seguire la guida ufficiale. Richiede Python 3.8+, MongoDB per i risultati.
3. VM guest Windows 10: installare Windows 10 Pro (attivato o in trial), disabilitare Windows Defender (per non alterare l'esecuzione), installare gli agenti CAPE (upload via script).
4. Snapshot pulito: creare uno snapshot della VM fresca (base senza tool di analisi interni, tranne i driver CAPE).
5. Configurazione di rete: usare inetsim (simulatore di servizi internet) o mitmproxy per intercettare il traffico. Impostare DNS fittizi per evitare connessioni reali.

Esempio di comando per inviare un campione da linea di comando:

# Invio di un file .exe alla sandbox CAPE in esecuzione su 192.168.1.100
curl -F file=@malware.exe http://192.168.1.100:8090/tasks/create/file

Il risultato è un report JSON con tutte le attività: processi creati, chiavi di registro modificate, file scritti, connessioni di rete.

Behavioral Analysis: Cosa Osservare

La behavioral analysis consiste nell’interpretare il report generato dalla sandbox. Non basta avere i dati: bisogna saper leggere le tracce. Noi partiamo sempre da queste domande:

• Processi: Il malware ha eseguito cmd.exe, powershell, wmic? Ha creato processi figli? Cerca nomi insolito (es. svchost.exe in posizioni anomale).
• File System: Ha scritto file in %APPDATA% o %TEMP%? Ha creato voci di avvio automatico (startup folder, Run registry key)?
• Registro: Modifiche a HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run? Oppure a policy di sicurezza (disable UAC, disable defender)?
• Rete: Ha contattato IP sconosciuti su porte non standard (es. 4444, 8080, 8443)? Ha tentato di risolvere domini appena registrati (DGA)?
• Memoria: Se la sandbox supporta memory dump, analizzare con Volatility per trovare code injection, hooking.

Un esempio concreto: analizzando un ransomware, abbiamo visto che dopo 30 secondi di attesa (sleep) per evitare sandbox, scriveva note.txt in ogni cartella. Una volta individuata la firma, abbiamo creato una regola YARA per riconoscere varianti future.

Strumenti di Behavioral Analysis Integrati

CAPE produce report in JSON. Possiamo estrarre indicatori automaticamente:

import json

with open('report.json') as f:
    report = json.load(f)

# Estrarre tutti i domini contattati
domains = [c['dst'] for c in report['network']['dns'] if c['type'] == 'A']
print('Domini contattati:', list(set(domains)))

Questo snippet è il punto di partenza per alimentare un SIEM o creare feed di IoC (Indicators of Compromise).

Tecniche di Evasione e Come Contrastarle

I malware moderni non cadono nella sandbox con ingenuità. Ecco le evasioni più comuni e come gestirle:

• VM detection: Controllano presenza di driver VMWare/VirtualBox, processi come vmtoolsd. Soluzione: modificare l'hostname della guest, rimuovere tool VM, usare hardware virtuale diverso (es. KVM/QEMU).
• Sleep avversari: Il malware attende X minuti prima di eseguire azioni dannose. Impostare timeout lungo nella sandbox (es. 5 minuti) oppure strumenti come sleepskipping (hook su NtDelayExecution).
• Anti-sandbox tramite API: Chiamano funzioni come IsDebuggerPresent, CheckRemoteDebuggerPresent. Possiamo hookare quelle API per restituire false.
• Human interaction check: Richiedono movimento del mouse o click. Usare script di automazione (ClickOnce, input simulation) nella guest.

CAPEv2 ha già molte di queste protezioni integrate (ad esempio modifiche al kernel per nascondere la VM). Tuttavia, per malware avanzato (APT), serve una sandbox hardware dedicata. Noi, quando incontriamo campioni che superano la sandbox software, passiamo a un'analisi statica o a un debugger su una macchina fisica (con air gap).

Integrazione della Sandbox nel Processo di Incident Response

Una sandbox isolata non basta. Deve essere integrata con gli altri strumenti del SOC. Il nostro flusso tipico:

1. Ricezione alert (es. da EDR) con artefatto sospetto.
2. Copia forense del file (hash, dimensione).
3. Invio automatico a CAPE via API (usando script o TheHive).
4. Attesa report (2-5 minuti).
5. Estrazione IoC: IP, domini, hash, mutex, regole YARA.
6. Correlazione con intelligence (VirusTotal, AlienVault OTX).
7. Decisione: bloccare IoC su firewall/EDR, quarantena host infetto, notifica cliente.

Se il malware è un downloader o un loader, la sandbox può estrarre anche il payload secondario (config, DLL). CAPE ha moduli specializzati per estrarre configurazioni di botnet (Trickbot, Dridex, Emotet). Questo accelera la risposta.

Errori Comuni (e come evitarli)

• Usare la stessa sandbox per tutti i campioni: dopo alcune analisi, il malware potrebbe riconoscere l'ambiente. Rigenerare gli snapshot periodicamente.
• Non monitorare la rete della sandbox: se il malware contatta un C2 e la sandbox ha internet reale, si rischia di essere bloccati dal provider. Usare inetsim o un'altra VM che simula servizi.
• Ignorare i falsi positivi: un installer legittimo può comportarsi in modo sospetto (es. scrivere in registro). Analizzare la reputazione del file (firma digitale, data di compilazione).
• Dimenticare il backup dei report: un incidente può richiedere mesi di analisi. Conservare i report in un database (es. MongoDB con replica).

In Sintesi — Cosa Fare Adesso

1. Allestisci una sandbox CAPE su un server dedicato (o usa un servizio cloud per test iniziali). Non eseguire malware sul tuo PC.
2. Definisci un processo di invio automatico (API + script) per ogni file sospetto rilevato dai tuoi sistemi.
3. Impara a leggere il report: processi, file, rete, registro. Crea regole YARA per la tua organizzazione.
4. Integra la sandbox con il tuo SIEM/SOAR (es. TheHive + Cortex).
5. Aggiorna periodicamente le VM guest e variabili di evasion (patches, nuove tecniche).

La sandbox non è un lusso: è il primo strumento di difesa attiva. Se gestisci la sicurezza di una PMI o di un'azienda medio-grande, una sandbox ben configurata ti dà visibilità immediata sugli attacchi. Noi, di Meteora Web, la utilizziamo nei nostri progetti di incident response e la inseriamo nei piani di sicurezza dei clienti che ci affidano la protezione della rete.

Per approfondire l’ecosistema dell’incident response, leggi la nostra Guida Pillar Definitiva su Incident Response e Forensics Digitale.