Guardrail del Mutex: Execution Guardrails: Mutual Exclusion (T1480.002)

Per testare la resilienza dei sistemi contro questa tecnica, iniziamo creando un mutex su Windows. Il comando PowerShell più diretto utilizza le API .NET per creare un mutex di sistema:

$mutex = New-Object System.Threading.Mutex($false, "Global\MyUniqueMutex2024")

Questo crea un mutex visibile a livello di sistema. Per verificarne l'esistenza prima di procedere con l'esecuzione, il codice malevolo tipicamente implementa questa logica: if ($mutex.WaitOne(0)) { "Mutex acquired, continuing execution" } else { "Mutex already exists, terminating"; exit }

Su Linux, l'approccio differisce sostanzialmente. Il malware BPFDoor, ad esempio, tenta di creare e bloccare un file specifico:

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

Questa riga tenta di acquisire un lock esclusivo sul file. Se fallisce (perché un'altra istanza detiene già il lock), il processo termina immediatamente. Un approccio più sofisticato in Python potrebbe essere: import fcntl; lockfile = open('/tmp/.mylock', 'w'); fcntl.flock(lockfile.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

Per simulare il comportamento di malware reali come GrimAgent, che calcola il nome del mutex basandosi sugli ultimi 64 byte del binario, possiamo utilizzare questo approccio in PowerShell: $bytes = [System.IO.File]::ReadAllBytes($MyInvocation.MyCommand.Path); $mutexName = [System.BitConverter]::ToString($bytes[-64..-1]).Replace("-","")

Su macOS, l'implementazione può sfruttare NSDistributedLock per coordinamento tra processi: if let lock = NSDistributedLock(path: "/tmp/guard.lock") { if !lock.try() { exit(1) } }

La detection efficace richiede il monitoraggio di pattern comportamentali specifici piuttosto che semplici indicatori statici. Su Windows, Sysmon EventCode 1 cattura la creazione di processi, ma dobbiamo correlarlo con la creazione di file mutex (EventCode 11) per identificare il comportamento sospetto.

Un approccio detection-first si basa sul rilevamento di processi che terminano rapidamente dopo l'avvio. Configurate una regola che triggera quando: un processo nuovo crea o accede a un mutex (visibile tramite handle analysis), seguito da terminazione entro 5 secondi dall'avvio senza generare attività significativa.

Per ridurre i falsi positivi, create una whitelist dei mutex legittimi nel vostro ambiente. Software come Office, browser e applicazioni enterprise utilizzano mutex per coordinamento. Il nome del mutex è fondamentale: valori ad alta entropia o pattern come "{GUID}" sono sospetti.

Su Linux, monitorate le syscall open, flock, fcntl tramite auditd. La sequenza critica da rilevare è: apertura di file in /tmp o /var/run, tentativo di lock esclusivo, terminazione immediata se il lock fallisce. Configurate auditd con: -a always,exit -F arch=b64 -S open,flock,fcntl -F dir=/tmp -F dir=/var/run -k mutex_check

L'analisi comportamentale deve includere il contesto del processo padre. Malware droppato spesso spawna da processi temporanei o da directory non standard. Correlate la creazione del mutex con: origine del processo (download recente?), firma digitale assente o invalida, esecuzione da directory writeable dall'utente.

Per macOS, sfruttate unified log per catturare chiamate a flock() o NSDistributedLock: log stream --predicate 'eventMessage CONTAINS "flock" OR eventMessage CONTAINS "NSDistributedLock"'

L'analisi forense dei mutex richiede la ricostruzione della sequenza temporale precisa. Su Windows, i mutex di sistema lasciano tracce nel kernel che possono essere enumerate anche post-mortem. Utilizzate volatility3 sul memory dump per elencare i mutex attivi: python vol.py -f memory.dmp windows.mutantscan

Gli artefatti principali da esaminare includono i prefetch files, che registrano l'esecuzione rapida e la terminazione anomala. Cercate pattern dove lo stesso eseguibile appare multiple volte con tempi di esecuzione brevissimi. Nel registro, alcuni malware salvano il nome del mutex per riferimento futuro in HKLM\Software o HKCU\Software.

Su Linux, i file di lock persistono spesso anche dopo la terminazione del processo. Esaminate /tmp e /var/run per file con timestamp sospetti. Il comando lsof su sistemi live può rivelare processi che detengono lock: lsof | grep -E "initd.lock|.lock"

La correlazione temporale è cruciale. Malware come Black Basta controlla il mutex "dsajdhas.0" immediatamente all'avvio. Nella timeline, vedrete: creazione del processo, query/creazione mutex (millisecondi dopo), prosecuzione dell'infezione o terminazione immediata.

Per ransomware come LockBit 3.0, che genera il mutex basandosi sul MachineGUID, verificate nel registro: reg query "HKLM\SOFTWARE\Microsoft\Cryptography" /v MachineGuid. Poi calcolate l'hash corrispondente per identificare il mutex utilizzato.

Su macOS, esaminate i log di sistema per tracce di NSDistributedLock. I crash report potrebbero rivelare terminazioni anomale correlate a mutex check falliti. Utilizzate log show --predicate 'processImagePath CONTAINS "suspicious_app"' --info per ricostruire il comportamento.

L'utilizzo dei mutex rivela pattern distintivi per profilare gli attori. APT38 implementa mutex hardcoded nei suoi tool finanziari, suggerendo un approccio meno sofisticato ma efficace per le loro operazioni mirate. Il gruppo utilizza questa tecnica principalmente nel malware bancario per evitare crash durante trasferimenti multipli.

StrelaStealer mostra un'evoluzione interessante: le varianti recenti generano mutex basati sul nome del sistema vittima. Questo indica che gli sviluppatori hanno implementato protezioni contro l'analisi in sandbox, dove i nomi di sistema sono spesso generici.

Il malware Troll Stealer di Kimsuky utilizza mutex durante l'installazione, rivelando la loro metodologia di deployment multi-stage. Prima droppa il loader, poi installa il componente principale solo se il mutex è acquisibile, prevenendo re-infezioni accidentali durante campagne massive.

L'overlap nei tool è significativo. PlugX, utilizzato da molteplici gruppi cinesi, implementa mutex in modo consistente attraverso le varianti. Questo suggerisce condivisione di codebase o sviluppatori comuni nel sottobosco cybercriminale cinese.

I trend geografici mostrano che i gruppi asiatici (specialmente cinesi e nordcoreani) favoriscono mutex hardcoded, mentre i gruppi dell'Europa orientale preferiscono generazione dinamica. I ransomware-as-a-service occidentali tendono verso mutex basati su caratteristiche hardware per massima unicità.

L'evoluzione prevista include mutex che cambiano nel tempo (time-based), rendendo l'analisi statica inefficace. Aspettatevi anche l'uso di mutex multipli in cascata per confondere l'analisi automatizzata.

Framework MITRE ATT&CK T1480.002 documenta questa tecnica con riferimenti dettagliati alle implementazioni malware. Le campagne di APT38 sono analizzate nei report FireEye. I comportamenti specifici di ransomware derivano da analisi di CrowdStrike, Secureworks e ricercatori indipendenti che hanno reverse-engineered i campioni.