Mutex come Guardrail: Mutual Exclusion (T1480.002)

L'obiettivo di un esercizio red team su questa tecnica è dimostrare come un impianto possa usare un mutex per evitare multi-istanza e ridurre la propria impronta sul sistema. La simulazione è semplice da implementare e offre un ottimo pretesto per validare le capacità di detection del Blue Team.

Su Windows, il modo più diretto è un piccolo eseguibile C o uno script PowerShell che invoca le API native. Con PowerShell puoi sfruttare il tipo .NET System.Threading.Mutex per creare un mutex di sistema con nome arbitrario:

$mutex = New-Object System.Threading.Mutex($true, "Global\LoadUpOnGunsBringYourFriends", [ref]$false)

Se $false viene restituito nel terzo parametro, significa che il mutex esisteva già — il malware in produzione a quel punto terminerebbe. In laboratorio puoi stampare un messaggio e uscire, simulando il comportamento di Embargo, che usa esattamente quel nome hardcoded. Per simulare LockBit 3.0, che deriva il nome del mutex dall'hash del MachineGUID, puoi leggere il valore dal registro e calcolarne l'hash:

$guid = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Cryptography").MachineGuid $hash = [System.BitConverter]::ToString((New-Object System.Security.Cryptography.SHA256Managed).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($guid))).Replace("-","")

Usa poi $hash come nome del mutex. Questo esercizio dimostra al Blue Team la differenza tra mutex statici (facilmente rilevabili con firma) e dinamici (che richiedono analisi comportamentale).

Su Linux, la simulazione replica il meccanismo di BPFDoor. Crea uno script bash che tenta di acquisire un lock esclusivo su un file:

exec 200>/var/run/initd.lock flock -n 200 || exit 1

Il comando flock (open source, parte del pacchetto util-linux) tenta un lock non bloccante; se fallisce, lo script termina. Esegui due istanze in parallelo per verificare che la seconda esca immediatamente.

Su macOS puoi usare lo stesso approccio con flock oppure scrivere un piccolo programma Swift/C che utilizzi flock() su un file in /tmp/. Per il reporting, lo strumento Handle di Sysinternals (gratuito) su Windows permette di enumerare tutti i mutex aperti da un processo specifico:

handle.exe -a -p <PID>

Filtrando l'output per "Mutant" ottieni la lista dei mutex attivi. In alternativa, Process Explorer (gratuito, Sysinternals) mostra i mutex nella vista "Handles" del lower pane. Su Linux, il comando lslocks (open source, parte di util-linux) elenca tutti i lock attivi sul sistema, facilitando la verifica post-esercizio.

La detection dei mutex malevoli si gioca su un equilibrio sottile: i mutex sono onnipresenti in qualsiasi sistema operativo, e un approccio puramente basato sulla creazione di mutex genererebbe un volume di falsi positivi insostenibile. La strategia vincente combina indicatori statici noti con analisi comportamentale.

Windows — Sysmon come pilastro. La log source primaria è WinEventLog:Sysmon. Sysmon (gratuito, Sysinternals) non ha un EventID nativo dedicato esclusivamente ai mutex, ma la correlazione passa attraverso la catena di eventi di processo. L'analisi di detection AN0372 suggerisce di intercettare la chiamata a CreateMutexW seguita da terminazione condizionale del processo o da un percorso di esecuzione alternativo. In pratica, configura regole che correlino EventCode 1 (Process Create) con EventCode 5 (Process Terminate) entro una finestra temporale breve — un processo che nasce e muore in pochi secondi dopo aver creato un mutex è sospetto.

Per i mutex con nomi noti, mantieni una watchlist aggiornata con i valori hardcoded documentati:

• LoadUpOnGunsBringYourFriends e IntoTheFloodAgainSameOldTrip (Embargo)
• {12d61a41-4b74-7610-a4d8-3028d2f56395} (SUNSPOT)
• {531511FA-190D-5D85-8A4A-279F2F592CC7} (Gazer)
• dsajdhas.0 (Black Basta)
• mymutex (GrimAgent, valore di fallback)

Queste stringhe possono alimentare regole Sigma (open source) o detection SIEM. Integra con strumenti di EDR che tracciano le chiamate API: la maggior parte delle soluzioni enterprise (CrowdStrike Falcon, a pagamento; Microsoft Defender for Endpoint, a pagamento; Elastic Security, freemium) logga la creazione di named mutex come telemetria.

Il tuning è cruciale. Filtra i mutex con nomi a bassa entropia o appartenenti a software legittimo noto. Concentra l'alerting su processi con parent-child relationship anomale — un mutex creato da un eseguibile lanciato da cmd.exe in una directory temporanea merita attenzione, uno creato da un servizio di sistema noto no.

Linux — auditd come base. La log source è auditd:SYSCALL. L'analisi AN0373 indica di monitorare le syscall open() seguite da flock() o lockf() su percorsi sospetti come /tmp/.lock* o /var/run/*lock. Configura regole auditd (open source) per tracciare gli accessi a questi path:

-w /var/run/initd.lock -p rw -k mutex_lock

Correla con exit code specifici (1 o 2) che segnalano il fallimento dell'acquisizione del lock. Il comando lslocks può essere integrato in script di monitoraggio periodico.

macOS — Unified Log. La log source è macos:unifiedlog. L'analisi AN0374 suggerisce di monitorare l'uso di flock() o NSDistributedLock su file in /tmp/ o /private/tmp/, con particolare attenzione a processi non associati a utenti interattivi che tentano lock e terminano rapidamente.

L'analisi forense di un mutex è un esercizio di ricostruzione indiretta: il mutex stesso è un oggetto volatile del kernel che scompare al reboot. L'obiettivo è dimostrare che un processo specifico ha creato un mutex con un nome noto, correlare questa azione con altri artefatti e inserire tutto in una timeline coerente.

Windows — artefatti chiave. I log Sysmon sono il punto di partenza. L'EventCode 1 fornisce il comando completo, l'hash dell'eseguibile e la catena parent-child. Se il processo ha terminato rapidamente (secondo istanza che trova il mutex già presente), l'EventCode 5 chiude la storia. Cerca la correlazione tra i due eventi con lo stesso ProcessGuid in una finestra di pochi secondi.

Per recuperare il nome del mutex dall'eseguibile, l'analisi statica con strumenti come Strings di Sysinternals (gratuito) o FLOSS di Mandiant (open source) è il metodo più rapido. FLOSS è particolarmente efficace perché deoffusca stringhe codificate, recuperando mutex che non appaiono con un semplice strings. Per Embargo, cerca le stringhe LoadUpOnGunsBringYourFriends o IntoTheFloodAgainSameOldTrip; per SUNSPOT e Gazer, cerca i rispettivi GUID tra parentesi graffe.

Il Prefetch (su sistemi client, in C:\Windows\Prefetch) documenta l'esecuzione del binario con timestamp dell'ultimo run e conteggio delle esecuzioni. Se il conteggio è 1 e il processo è durato pochissimo, potrebbe indicare la seconda istanza che ha trovato il mutex già acquisito. L'Amcache (C:\Windows\appcompat\Programs\Amcache.hve) registra hash SHA1 e percorso originale dell'eseguibile, utile per correlare campioni tra macchine diverse.

Per LockBit 3.0 la ricostruzione richiede un passaggio in più: recupera il MachineGUID dal registro (HKLM\SOFTWARE\Microsoft\Cryptography) e calcola l'hash per ottenere il nome del mutex atteso. Confrontalo con eventuali stringhe estratte dalla memoria o dal dump del processo, se disponibile.

Linux — artefatti chiave. Per BPFDoor, il lock file /var/run/initd.lock è l'artefatto primario. Verifica con stat i timestamp MAC del file. I log auditd, se configurati per monitorare le syscall flock, registrano PID, UID e percorso del file coinvolto. Ricostruisci la sequenza: quale processo ha creato il file, quando ha acquisito il lock, se altri processi hanno tentato e fallito.

La timeline si costruisce allineando: timestamp di creazione del lock file → log auditd delle syscall → log di rete per eventuali callback C2 successivi all'acquisizione del mutex. Un mutex acquisito con successo è il "via libera" per l'impianto — tutto ciò che segue cronologicamente è attività post-compromissione attiva.

La tecnica T1480.002 è adottata da un ecosistema eterogeneo che spazia dallo spionaggio statale al cybercrime finanziario, con una concentrazione significativa nel settore ransomware. Comprendere chi la usa e come permette di anticipare pattern di compromissione.

APT38 è il gruppo più rilevante tra quelli documentati. Legato alla Corea del Nord e focalizzato su operazioni di furto finanziario contro istituzioni bancarie e piattaforme di criptovaluta, APT38 utilizza mutex per evitare esecuzioni duplicate dei propri impianti. Questa scelta operativa riflette la cautela tipica di un gruppo che conduce operazioni a lungo termine su reti bancarie ad alta visibilità, dove un'anomalia — come un processo duplicato — potrebbe innescare un'indagine.

Il panorama software rivela pattern interessanti. Il cluster ransomware è dominante: Embargo, LockBit 3.0, REvil, Black Basta e Qilin utilizzano tutti mutex come meccanismo anti-duplicazione. La logica è operativa — in una campagna ransomware, eseguire due istanze del cifratore sullo stesso host è controproducente perché rallenta il sistema, genera errori e aumenta la probabilità di detection. I nomi dei mutex variano da valori coloriti (la stringa Nirvana di Embargo) a GUID statici (SUNSPOT), fino ad hash derivati da identificativi macchina (LockBit 3.0). Questa evoluzione riflette una maturazione dell'OPSEC: i nomi statici finiscono rapidamente nelle firme, mentre i nomi dinamici richiedono reverse engineering per essere identificati.

Nel segmento spionaggio, PlugX e PoisonIvy — due famiglie con radici storiche nel panorama APT cinese — implementano mutex con approcci diversi. PoisonIvy offre un valore custom o di default, indicando un framework configurabile distribuito a più operatori. TONESHELL utilizza mutex per evitare duplicati, allineandosi al comportamento di impianti modulari progettati per persistenza a lungo termine. Gazer, con il suo GUID hardcoded, segue un pattern simile.

Il caso SUNSPOT merita attenzione speciale: questo malware era progettato per monitorare il processo di build di SolarWinds e iniettare codice malevolo — un contesto in cui istanze multiple avrebbero causato corruzione del build e scoperta immediata. Il mutex era quindi un requisito funzionale, non solo un'accortezza difensiva.

StrelaStealer introduce un'evoluzione degna di nota: i nomi dei mutex sono derivati dal nome del sistema vittima, impedendo il riuso della stessa firma tra macchine diverse. GrimAgent adotta un approccio ibrido: calcola il nome dai byte finali del binario, con fallback sul generico mymutex — un pattern che crea un indicatore fragile ma comunque utile per il pivoting tra campioni.

La classificazione come Do Not Mitigate indica che il valore difensivo risiede interamente nell'intelligence e nella detection, non nella prevenzione. Per un TI analyst, i nomi dei mutex hardcoded restano tra gli IoC più stabili e facilmente condivisibili attraverso piattaforme di threat sharing.

Framework MITRE ATT&CK v16 — Tecnica T1480.002 (Mutual Exclusion), Tattica TA0005, Mitigazione M1055, Detection DET0132 (AN0372, AN0373, AN0374). Gruppi: G0082. Software: S1247, S1242, S1161, S0013, S1202, S0632, S0496, S0012, S1236, S1196, S0562, S1239, S1183, S0168, S1070. Integrato con conoscenza professionale per tool e procedure operative.