File Cifrati e Offuscati: Encrypted/Encoded File (T1027.013)

L'obiettivo in un esercizio red team è dimostrare che i controlli di sicurezza dell'organizzazione falliscono nel rilevare payload cifrati su disco. Il punto non è la complessità dell'algoritmo: spesso basta un XOR single-byte per superare firme statiche mal configurate.

Partiamo dal caso più semplice. Su Linux, generare un payload XOR-offuscato è questione di pochi byte di Python:

python3 -c "import sys; key=0x53; data=open(sys.argv[1],'rb').read(); open(sys.argv[2],'wb').write(bytes([b^key for b in data]))" payload.bin payload.enc

La chiave 0x53 non è casuale: è la stessa documentata nella configurazione di RedLeaves. In un test realistico, usare chiavi osservate in-the-wild dimostra al blue team che le minacce reali adottano schemi elementari che troppo spesso sfuggono alla detection.

Per scenari più sofisticati, il framework Donut (open source) genera shellcode cifrato e compresso da assembly .NET, PE ed EXE, con supporto per AES-256 e compressione LZNT1. L'output è un modulo che si decifra interamente in memoria, senza mai scrivere il payload in chiaro su disco. In laboratorio è il modo più diretto per testare se l'EDR rileva l'unpacking in-memory.

Con Sliver (open source), la cifratura delle stringhe avviene a compile-time: il beacon viene generato con stringhe offuscate di default, senza bisogno di wrapper aggiuntivi. Questo replica il comportamento di famiglie come GoldMax, che scrive su disco file di configurazione cifrati con AES e codificati Base64.

Per simulare l'uso di archivi SFX protetti da password — tecnica impiegata da BITTER con RAR SFX dropper e da TA505 con documenti Word protetti — si può creare un archivio auto-estraente con WinRAR o 7-Zip contenente un eseguibile benigno di test:

7z a -sfx -pTestPassword123 payload_sfx.exe beacon_test.exe

Su macOS, per replicare il comportamento di XCSSET che usa xxd per codificare moduli attraverso strati multipli di decodifica esadecimale:

xxd -p payload.bin | xxd -p > payload.hex.hex

Il blue team dovrebbe rilevare la catena di decodifica inversa. Infine, per testare la detection di Base64, il classico:

certutil -encode payload.exe payload.b64

su Windows genera un file codificato che molti EDR dovrebbero intercettare sia in scrittura che nella decodifica successiva tramite certutil -decode. Se non lo fanno, il report del penetration test ha già un finding critico.

La difficoltà nel rilevare file cifrati su disco è intrinseca: un file offuscato è, per definizione, indistinguibile da dati binari legittimi fino al momento della decodifica. La detection efficace si concentra quindi su due momenti: la creazione del file e la sua decodifica/esecuzione.

Su Windows, le sorgenti log principali sono Sysmon e il Security Event Log. La strategia di detection AN0237 identifica processi che caricano o decodificano file cifrati in memoria per poi eseguirli o iniettarli. I processi da monitorare includono certutil.exe, powershell.exe e mshta.exe quando appaiono con argomenti contenenti stringhe Base64 o esadecimali lunghe nella command line. Una regola Sysmon basata su EventCode 1 (Process Create) che filtra per command line con pattern Base64 di lunghezza superiore a 200 caratteri è un buon punto di partenza, ma richiede tuning: il path dell'immagine e il contenuto della riga di comando variano significativamente tra ambienti.

La combinazione di EventCode 11 (File Create) con EventCode 1 in una finestra temporale ristretta è particolarmente efficace: se un processo scrive un file con estensione insolita (.enc, .bin, .tmp in directory temp) e subito dopo un processo figlio lo legge e avvia attività di rete o injection, il pattern è altamente sospetto.

Su Linux, la detection AN0238 si appoggia su auditd e Sysmon for Linux (richiede installazione separata). L'attenzione va posta sull'uso di base64, openssl e gpg in catene di pipe seguite da esecuzione diretta. Una regola auditd che traccia le SYSCALL execve per questi binari, correlata con il contesto utente e la process lineage, cattura scenari come:

echo <blob_base64> | base64 -d | sh

Il tuning è fondamentale: l'uso legittimo di base64 e openssl varia enormemente per ruolo utente e tipo di server. Creare una baseline di utilizzo normale nei primi 30 giorni è indispensabile per ridurre i falsi positivi.

Su macOS, la detection AN0239 sfrutta l'Unified Log e l'Endpoint Security framework. Gli script che invocano xxd o base64 in catene di decodifica multiple — il pattern a tre strati usato da XCSSET — dovrebbero generare alert quando la catena termina con l'esecuzione di un comando shell o di un modulo AppleScript.

Per i controlli preventivi, la mitigazione M1040 raccomanda l'attivazione delle Attack Surface Reduction (ASR) rules su Windows 10+ per bloccare l'esecuzione di script potenzialmente offuscati. La mitigazione M1049 prevede che l'antivirus sia configurato per analizzare le proprietà di encoding dei file e rilevare anomalie come entropia elevata, un indicatore statistico che il contenuto è cifrato o compresso.

Come indicatore rapido, monitorare file con entropia Shannon superiore a 7.5 nelle directory temporanee è un segnale ad alta fedeltà: i file di testo e i binari standard raramente raggiungono quel valore.

Nell'analisi post-incidente, i file cifrati rappresentano sia un ostacolo sia un'opportunità: l'ostacolo è ovviamente il contenuto opaco, ma l'opportunità risiede nel fatto che la fase di decodifica lascia tracce precise nella timeline.

Il primo artefatto da cercare su Windows è la creazione del file cifrato su disco. I metadati NTFS — timestamp $STANDARD_INFORMATION e $FILE_NAME nel record MFT — fissano il momento in cui il payload è stato depositato. Tool come MFTECmd di Eric Zimmerman (open source) permettono di estrarre rapidamente questi dati. Confrontando il timestamp di creazione del file .enc o .bin con i log di processo Sysmon (EventCode 11), si identifica il processo responsabile del drop.

Il secondo momento critico è la decodifica. Su sistemi Windows, la Prefetch cache registra l'esecuzione di certutil.exe, powershell.exe o del loader custom che decifra il payload. Ogni entry Prefetch contiene fino a 8 timestamp di esecuzione e la lista dei file referenziati, offrendo una correlazione diretta tra il decoder e il file cifrato. Lo strumento PECmd (open source) analizza questi artefatti in modo strutturato.

Per i file cifrati con chiavi hardcoded — un pattern estremamente comune che si osserva in PlugX (XOR con chiave 123456789), RedLeaves (XOR con 0x53), HOMEFRY (XOR con 0x56), Smoke Loader (XOR single-byte) e decine di altre famiglie — il forensic analyst può tentare il decrittamento diretto una volta identificata la famiglia. Le chiavi hardcoded, per loro natura, non cambiano tra le infezioni della stessa variante.

Su Linux, gli artefatti principali sono la bash history (se non cancellata), i log di auditd con le syscall execve che mostrano la catena di decodifica, e il contenuto di /tmp e /dev/shm dove spesso risiedono payload intermedi. La campagna ShadowRay (C0045) ha utilizzato codice Python codificato Base64 per sfruttare la vulnerabilità CVE-2023-48022 nel framework Ray: in quel caso i file Python decodificati transitavano attraverso directory temporanee dell'applicazione.

Per ricostruire la timeline completa, correlare quattro elementi chiave:

1. File creation — timestamp MFT o ext4 del file cifrato
2. Process execution — Prefetch/Sysmon/auditd del processo che ha scritto il file
3. Decode event — esecuzione del decoder o del loader che decifra in memoria
4. Post-decode activity — connessioni C2, injection, lateral movement

Nella campagna APT41 DUST (C0040), i payload cifrati venivano decifrati ed eseguiti interamente in memoria tramite DUSTPAN e DUSTTRAP, rendendo il punto 3 visibile solo attraverso artefatti di memoria volatile. In questi casi, l'acquisizione RAM con tool come AVML (open source, per Linux) o WinPmem (open source, per Windows) diventa essenziale per recuperare il payload in chiaro.

L'offuscamento di file è talmente pervasivo che la scelta dell'algoritmo crittografico diventa un indicatore di profilazione: non tutti i gruppi usano gli stessi schemi, e i pattern si stabilizzano nel tempo.

Lazarus Group rappresenta l'esempio più eclettico: il gruppo impiega AES, Caracachs, RC4, XOR, Base64 e alias per i nomi delle funzioni Native API. Nella campagna Operation Dream Job (C0022), il malware DRATzarus era cifrato con XOR e le DLL con Base64. Questa stratificazione multipla è una firma operativa del gruppo, che combina schemi semplici e complessi nello stesso intrusion set.

APT28 mostra un approccio analogo, cifrandono payload DLL con RTL e un algoritmo custom, oltre a offuscarli con Base64, XOR e RC4. La varietà di schemi suggerisce team di sviluppo con competenze diversificate e toolkit modulare, dove il metodo di offuscamento viene selezionato in base al vettore di delivery.

OilRig adotta un profilo più conservativo: Base64 ed encoding semplice come schema primario, con varianti offuscate nelle VBS dropper osservate nella campagna Outer Space (C0042). Il gruppo israeliano è un bersaglio ricorrente, e il pattern minimalista di OilRig suggerisce che il gruppo privilegia la semplicità operativa e la rapidità di deploy rispetto alla resistenza all'analisi.

Sul fronte ransomware, Qilin, RansomHub, LockBit 3.0, BlackByte e Embargo cifrano i propri payload con schemi che vanno da RC4 ad AES, un trend che riflette la necessità degli operatori ransomware di evadere la detection pre-detonazione. Embargo in particolare usa RC4 per cifrare sia il deployer (MDeployer) sia il killer di servizi (MS4 Killer), un pattern che i difensori possono sfruttare come pivot di hunting.

Sul piano delle campagne di supply chain e infrastrutturali, la 3CX Supply Chain Attack (C0057) è emblematica: AppleJeus cifrava le DLL con RC4 usando una chiave specifica (3jB(2bsG#@c7), un indicatore altamente specifico che ha permesso il tracciamento retroattivo dell'infezione. Analogamente, nella campagna RedPenguin (C0056), UNC3886 ha generato file codificati Base64 nell'ambiente FreeBSD dei router Juniper compromessi, dimostrando che la tecnica si estende ben oltre i sistemi desktop.

Un pattern geografico emerge chiaramente: i gruppi con nexus in Cina — come Threat Group-3390 con shikata_ga_nai di Metasploit, Putter Panda con RC4 e XOR a 16 byte, APT32 con il framework DKMC e AES-256 CBC, e i threat actor dietro Night Dragon (C0002) — tendono a combinare encoder pubblici con layer custom, creando una complessità analitica che rallenta il reverse engineering senza richiedere sviluppo crittografico originale.

Framework MITRE ATT&CK v16 — T1027.013 Encrypted/Encoded File, TA0005 Defense Evasion. Campagne: C0045, C0002, C0006, C0040, C0047, C0016, C0042, C0022, C0057, C0056, C0005, C0029. Detection: Sysmon, auditd, macOS Unified Log. Mitigazioni: M1049, M1040. Integrato con conoscenza professionale per tool e procedure operative.