Firma Digitale Contraffatta: Invalid Code Signature (T1036.001)

Per comprendere come gli attaccanti manipolano le firme digitali, iniziamo analizzando un eseguibile legittimamente firmato. Su Windows, il comando signtool verify /pa /v target.exe mostra tutti i dettagli del certificato valido.

Il trucco sta nel copiare questi metadati senza possedere la chiave privata. Gli attaccanti utilizzano tool come PeStudio o script personalizzati per estrarre la sezione Authenticode dal PE header. Una volta estratta, la inseriscono in un malware non firmato mantenendo intatti i riferimenti a Microsoft Corporation o altre aziende rinomate.

Su Linux e macOS l'approccio è simile ma usa certificati diversi. Il comando codesign -dv --verbose=4 malicious.app su macOS rivelerà firme con stato "invalid" o "untrusted". Gli attaccanti spesso utilizzano certificati revocati ma ancora riconosciuti da sistemi non aggiornati.

Per un test pratico in laboratorio:

1. Estrai la firma da un file legittimo con dd if=signed.exe of=signature.bin bs=1 skip=$((0x3c)) count=2048
2. Modifica un eseguibile non firmato aggiungendo i metadati estratti
3. Verifica che Windows mostri il publisher name ma con avviso "firma non valida"

Tool come CFF Explorer permettono di manipolare direttamente le sezioni del PE header. La chiave è mantenere la struttura Authenticode intatta mentre si invalida la catena di verifica crittografica.

La detection di firme contraffatte richiede un approccio multi-livello che va oltre il semplice controllo di validità. I log Sysmon con EventID 7 catturano il caricamento di immagini, inclusi i dettagli sulla firma digitale nel campo SignatureStatus.

Una regola efficace combina tre elementi: processo con firma invalida, esecuzione da path sospetti, e parent process anomalo. Per esempio, un file che dichiara di essere firmato da Microsoft ma viene eseguito da %TEMP% con cmd.exe come parent è altamente sospetto.

Su Windows, correlare eventi PowerShell (EventID 4104) con Windows Defender (EventID 1116) rivela tentativi di esecuzione bloccati. Il campo SignatureValidationResult nei log contiene valori specifici come "expired", "untrusted root", o "invalid" che permettono tuning granulare.

Per macOS, i log unificati catturano messaggi di Gatekeeper e XProtect. La stringa "code signature invalid" nei log di sistema, combinata con esecuzioni da /Users/Shared o /tmp, indica possibili compromissioni. Il framework Endpoint Security fornisce eventi in tempo reale quando processi con firme non valide tentano di eseguire.

La gestione dei falsi positivi richiede whitelist basate su hash piuttosto che su nome file. Software legacy o tool interni spesso hanno certificati scaduti ma legittimi - documentarli riduce il rumore senza compromettere la sicurezza.

Durante l'analisi forense, le firme contraffatte lasciano tracce distintive nel filesystem e in memoria. L'Authenticode hash nel PE header non corrisponderà all'hash calcolato del file, prima indicazione di manipolazione.

Gli artefatti Windows includono le entry nel catalogo di sistema (C:\Windows\System32\catroot2) dove firme valide vengono memorizzate. File con firme false non appariranno qui ma potrebbero avere entry in WinSxS se hanno tentato di mascherarsi come componenti di sistema.

Il timestamp della firma spesso rivela incongruenze temporali. APT37 per esempio utilizzava certificati Tencent con date di compilazione che precedevano l'esistenza del certificato stesso. Questa anomalia temporale, visibile con dumpbin /headers, aiuta a ricostruire quando il malware è stato modificato.

Su macOS, l'analisi del quarantine attribute (xattr -l) mostra se Gatekeeper ha processato il file. File con firme invalide ma senza quarantine flag indicano bypass delle protezioni di sistema, suggerendo privilege escalation o manipolazione diretta del filesystem.

La correlazione tra Prefetch, Amcache e USN Journal rivela il percorso completo: download iniziale, estrazione da archivio, tentativi di esecuzione falliti e eventuale successo dopo disabilitazione delle protezioni. Ogni passaggio lascia timestamp che permettono di ricostruire l'intera catena di compromissione.

APT37 (Lazarus correlato) ha perfezionato l'uso di certificati Tencent contraffatti, targeting specifico contro Corea del Sud e Giappone. La scelta di Tencent non è casuale: l'ubiquità del software Tencent in Asia rende questi file meno sospetti durante i controlli superficiali.

Windshift opera diversamente, preferendo certificati revocati ma tecnicamente validi. Questo gruppo, attivo in Medio Oriente, sfrutta il lag temporale tra revoca e aggiornamento delle CRL nei sistemi target. I loro tool WindTail mantengono firme parzialmente valide che passano controlli automatici basilari.

Il malware Regin, attribuito a Five Eyes, utilizzava certificati contraffatti di Microsoft e Broadcom già nel 2014. La scelta di vendor infrastrutturali suggerisce targeting di sistema profondo piuttosto che applicazioni utente. BADNEWS invece usa certificati generici per sembrare software commerciale standard.

L'evoluzione mostra trend chiari: dai certificati completamente falsi (2010-2015) si è passati a certificati revocati (2016-2019) fino all'attuale uso di certificati validi ma applicati incorrettamente (2020+). Gelsemium rappresenta questa nuova generazione, con DLL firmate che falliscono solo controlli approfonditi.

La geografia delle vittime correla con la scelta dei certificati: gruppi APT asiatici preferiscono vendor locali (Tencent, Baidu), mentre attori occidentali usano certificati Microsoft o Apple. Questa localizzazione aumenta le chance di successo contro target specifici.

Tecnica documentata nel framework MITRE ATT&CK. Informazioni su APT37 e Windshift derivate da report di threat intelligence pubblici. Dettagli tecnici su Regin, BADNEWS e altri malware basati su analisi di campioni depositati in sandbox pubbliche. Best practice di detection ispirate da documenti NSA e CISA sulla sicurezza delle firme digitali.