t1480-002-mutual-exclusion

# T1480.002 - Mutual Exclusion > [!info] Técnica Pai > Esta é uma sub-técnica de **[[t1480-execution-guardrails|T1480 - Execution Guardrails]]**. Adversários usam mutex como mecanismo de guardrail para controlar em quais ambientes o malware executa e impedir a criação de múltiplas instâncias simultâneas. ## Descrição **Mutual Exclusion** (Exclusão Mútua, ou simplesmente **mutex**) é um primitivo de sincronização do sistema operacional originalmente projetado para coordenar o acesso concorrente a recursos compartilhados por múltiplas threads ou processos. Adversários abusam desse mecanismo legítimo para dois fins distintos no contexto de malware: 1. **Controle de instância única**: garantir que apenas uma cópia do malware estejá em execução ao mesmo tempo, evitando conflitos internos, uso excessivo de recursos e a geração de artefatos duplicados que poderiam ser detectados por ferramentas de segurança. 2. **Verificação de ambiente de execução**: usar a presença ou ausência de um mutex específico como condição para continuar ou abortar a execução - funcionando como um **guardrail** que impede o malware de rodar em ambientes de análise (sandboxes, VMs de pesquisadores) onde o mutex não está presente. No **Windows**, mutexes nomeados do sistema (`CreateMutex` + `OpenMutex` da Win32 API) são visíveis para todos os processos no mesmo contexto de sessão. O malware cria um mutex com nome único (hardcoded ou gerado algoritmicamente) na inicialização. Se outro processo já segura esse mutex, o segundo processo identifica que uma instância já existe e encerra a si mesmo silenciosamente. No **Linux e macOS**, o mecanismo equivalente frequentemente envolve **arquivos de lock** (`/tmp/.lock`, `/var/run/malware.pid`) combinados com `flock()` ou `fcntl()`. Se o lock não puder ser adquirido, o processo assume que já existe uma instância ativa e sai. Algumas famílias de malware Linux utilizam também **semáforos POSIX** ou mutexes de memória compartilhada via `pthread_mutex_t`. Nomes de mutex podem ser **hardcoded** (fáceis de detectar e usar como IoC, mas simples de implementar) ou **gerados dinâmicamente** com base em características do sistema - como ID de hardware, nome do usuário ou GUID do volume - tornando a detecção por assinatura mais difícil. > [!warning] Ponto de Atenção para Analistas > Mutexes hardcoded são excelentes IoCs: uma vez documentado, o nome do mutex pode ser usado para detectar infecções ativas via ferramentas como Process Hacker, Autoruns ou consultas ao Event Log. No entanto, adversários sofisticados como o [[g0082-apt38|APT38]] usam algoritmos de geração baseados em UUID da máquina, inválidando IoCs estáticos. ## Como Funciona O fluxo de execução típico de malware que usa mutex como guardrail segue uma sequência bem definida: **No Windows:** 1. O malware chama `CreateMutex(NULL, TRUE, "NomeMutexÚnico")` na inicialização. 2. Se o retorno for `ERROR_ALREADY_EXISTS`, outra instância está rodando - o processo termina via `ExitProcess(0)`. 3. Se a criação for bem-sucedida, o malware segura o mutex durante todo o ciclo de vida do processo. 4. Ao encerrar, o mutex é liberado automaticamente pelo SO, permitindo nova instância futura. **No Linux:** 1. O malware tenta criar e travar um arquivo de lock em `/tmp/` ou `/var/run/`. 2. Usando `flock(fd, LOCK_EX | LOCK_NB)` (non-blocking exclusive lock). 3. Se `EWOULDBLOCK`, outra instância já existe - processo sai. 4. Escreve seu PID no arquivo lock para facilitar identificação. **Variante como Guardrail Anti-Análise:** Algumas famílias criam intencionalmente um mutex com nome específico antes de executar código malicioso, e verificam se um mutex "bloqueador" (indicador de sandbox) está presente. Ferramentas de análise automatizadas podem ser configuradas para pre-criar mutexes específicos, fazendo o malware desistir de executar em ambientes monitorados. ## Attack Flow ```mermaid graph TB A([Malware Inicia Execução]) --> B{Verificar Mutex Existente?} B -->|Windows: OpenMutex| C[Chamar OpenMutex com nome único] B -->|Linux: flock| D[Tentar flock no arquivo lock] C --> E{Mutex já existe?} D --> F{Lock disponível?} E -->|Sim - ERROR_ALREADY_EXISTS| G([Encerrar Silenciosamente ExitProcess 0]) E -->|Não - Sucesso| H[Criar e Segurar Mutex CreateMutex TRUE] F -->|Não - EWOULDBLOCK| G F -->|Sim - Lock Adquirido| I[Escrever PID no arquivo lock] H --> J{Verificar Mutex Anti-Sandbox?} I --> J J -->|Mutex bloqueador presente| G J -->|Ambiente limpo| K([Continuar Execução Payload Principal]) K --> L[Atividade Maliciosa C2 / Coleta / Cifragem] style A fill:#2d2d2d,color:#fff style G fill:#c0392b,color:#fff style K fill:#27ae60,color:#fff style L fill:#8e44ad,color:#fff style H fill:#e67e22,color:#fff style I fill:#e67e22,color:#fff ``` ## Exemplos de Uso ### APT38 - Lazarus Group (Coreia do Norte) O [[g0082-apt38|APT38]], vinculado ao [[g0032-lazarus-group|Lazarus Group]] norte-coreano, emprega mutexes nomeados como parte da cadeia de execução de implantes bancários. O grupo é especializado em ataques ao sistema financeiro SWIFT, e seus implantes usam mutexes para garantir que apenas uma instância do módulo de interceptação de transações opere por vez, evitando dupla execução que poderia gerar logs anômalos. ### REvil (Sodinokibi) O ransomware [[s0496-revil|REvil]] utilizava mutex com nome hardcoded baseado no ID da vítima para garantir que o processo de cifragem não fosse iniciado múltiplas vezes simultaneamente. A criação duplicada durante o processo de cifragem poderia resultar em corrupção de arquivos já cifrados, comprometendo a operação de extorsão. ### LockBit 3.0 O [[s1202-lockbit-30|LockBit 3.0]] gera nomes de mutex dinâmicamente usando o GUID do volume do disco de sistema. Isso significa que o mesmo sample em máquinas diferentes terá mutexes distintos - eliminando a possibilidade de usar o nome do mutex como IoC estático compartilhado entre incidentes. ### BPFDoor (Linux) O [[s1161-bpfdoor|BPFDoor]], backdoor Linux atribuído a grupos de espionagem chineses, usa arquivo de lock em `/var/run/` para garantir instância única. Por operar como daemon persistente, o arquivo de lock também serve como mecanismo de sobrevivência: após reboot, o arquivo some e o daemon pode reiniciar sem conflito. ### PlugX O [[s0013-plugx|PlugX]], RAT amplamente usado por grupos APT chineses, implementa mutex nomeado com strings ofuscadas ou geradas a partir de características do host. Diferentes variantes do PlugX têm sido documentadas com nomes como `{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}` baseados em UUIDs do sistema. ### PoisonIvy O [[s0012-poisonivy|PoisonIvy]] (RAT utilizado desde 2005) criava mutex hardcoded como `"!IECompatible"` ou variações customizadas pelo operador no momento de build do implante. O nome configurável por operador foi amplamente documentado como IoC em campanhas de espionagem contra alvos governamentais e de defesa. ## Detecção > [!tip] Estrategia de Detecção > A detecção de mutex como guardrail combina três abordagens: monitoramento de criação de mutexes por processos suspeitos, análise comportamental de processos que terminam imediatamente após criar objetos kernel, e threat hunting com listas de mutex conhecidos de famílias de malware documentadas. ### Regra Sigma - Criação de Mutex por Processo Suspeito (Windows) ```yaml title: Suspeito - Criação de Mutex por Binário Incomum id: a4c3d8e1-2b7f-4e9a-8c5d-1f6b3a2e7d4c status: experimental description: > Detecta criação de named mutex por processos fora do contexto esperado de desenvolvimento ou sistema. Pode indicar malware usando mutex para controle de instância ou guardrail anti-análise. author: RunkIntel daté: 2026-03-25 references: - https://attack.mitre.org/techniques/T1480/002/ tags: - attack.defense_evasion - attack.t1480.002 logsource: category: process_creation product: windows detection: selection_mutex_api: EventID: 4656 ObjectType: "Mutant" ProcessName|endswith: - '\powershell.exe' - '\cmd.exe' - '\wscript.exe' - '\cscript.exe' - '\rundll32.exe' - '\regsvr32.exe' - '\mshta.exe' filter_known_good: ObjectName|startswith: - '\Sessions\1\BaseNamedObjects\MSCTF' - '\Sessions\1\BaseNamedObjects\Local\SM' - '\BaseNamedObjects\NLS_' condition: selection_mutex_api and not filter_known_good falsepositives: - Ferramentas legítimas de scripting criando mutexes para controle de instância - Software de automação corporativa level: medium ``` ### Regra Sigma - Processo Encerra Imediatamente Após Criar Mutex ```yaml title: Suspeito - Processo de Curta Duração Criando Mutex Nomeado id: b7e2f5a3-9c1d-4b8e-a6f2-3d5e8b1c4a7f status: experimental description: > Processo que cria um named mutex e encerra em menos de 2 segundos pode indicar malware verificando se já existe instância ativa (padrão de guardrail anti-duplicação). author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1480.002 logsource: product: windows service: sysmon detection: selection_creaté: EventID: 17 PipeName|re: '.*' selection_quick_exit: EventID: 5 UtcTime|lt: "+00:00:02" condition: selection_creaté and selection_quick_exit falsepositives: - Instaladores que verificam instâncias e saem level: low ``` ### Indicadores de Compromisso - Nomes de Mutex Conhecidos | Família | Nome do Mutex | Tipo | Plataforma | |---------|--------------|------|-----------| | REvil | `{UUID baseado na vítima}` | Dinâmico | Windows | | LockBit 3.0 | Derivado do GUID do volume | Dinâmico | Windows | | PoisonIvy | `!IECompatible` (padrão) | Hardcoded | Windows | | BPFDoor | `/var/run/.pid` | Arquivo lock | Linux | | Qilin | Gerado por hash | Dinâmico | Windows | | GrimAgent | String aleatória 16 chars | Gerado | Windows | ## Mitigação | ID | Mitigação | Descrição | Eficácia | |---|-----------|-----------|----------| | M1055 | [[m1055-do-not-mitigaté\|M1055 - Do Not Mitigaté]] | Esta técnica não tem mitigação direta - é abuso de funcionalidade legítima do SO | N/A | > [!note] Por que não há mitigação efetiva? > Mutexes são primitivos fundamentais do SO usados por software legítimo. Bloquear a criação de mutexes quebraria grande parte do software corporativo. O foco deve estar em **detecção** (monitorar quem cria quais mutexes) e **threat hunting** (buscar ativamente por nomes de mutex conhecidos de famílias de malware). ### Compensating Controls - Implementar **allowlisting de mutexes** em ambientes controlados: listar mutexes legítimos conhecidos e alertar para novos - Usar **sandboxes de análise** que pré-criam mutexes conhecidos de ransomware para induzir self-termination antes da cifragem - **Sysinternals Handle** / **Process Hacker**: ferramenta de resposta a incidentes para enumerar mutexes ativos em host comprometido - Correlacionar criação de mutex com **indicadores de comportamento suspeito** (processo sem jánela, comunicação de rede, criação de arquivos em massa) ## Contexto Brasil/LATAM > [!example] Relevância Regional O uso de mutex como guardrail é onipresente no ecossistema de malware que afeta o Brasil e a América Latina, especialmente em famílias de **banking trojans** e **RATs** nacionais e internacionais: **Banking Trojans Brasileiros**: Famílias como Grandoreiro, Guildma e Javali - que historicamente visam instituições financeiras brasileiras - implementam mutex para garantir que apenas uma instância do módulo de captura de tela e keylogger opere por vez. A operação simultânea múltipla poderia degradar a performance do sistema da vítima e gerar alertas de CPU. **Ransomware no Setor Financeiro**: O setor financeiro brasileiro ([[financial|setor financeiro]]) é alvo frequente de grupos como [[s1202-lockbit-30|LockBit 3.0]] e [[s0496-revil|REvil]], que usam mutex dinâmico por vítima para operações de cifragem coordenadas em redes corporativas. Em ataques contra bancos regionais brasileiros em 2024-2025, análises forenses identificaram nomes de mutex únicos por organização. **Grupos APT com Foco LATAM**: O [[g0082-apt38|APT38]] realizou operações contra o sistema financeiro brasileiro visando o sistema SWIFT. O uso de mutex em seus implantes é consistente com a necessidade de manter controle preciso sobre a jánela de execução do ataque, que frequentemente coincide com horários de processamento de transferências bancárias. **Operações de Red Team Nacionais**: Equipes de red team brasileiras documentam abuso de mutex via ferramentas como [[s0363-empire|Empire]] e Cobalt Strike em avaliações de segurança de instituições financeiras - confirmando que a técnica é replicada tanto por agentes maliciosos quanto em exercícios defensivos. A técnica também é relevante no contexto de **ataques a infraestrutura crítica** brasileira: usinas de energia e operadoras de telecomúnicações reportaram incidentes onde implantes usavam mutex para evitar detecção por soluções EDR que identificam processos duplicados como anomalia. ## Referências - [MITRE ATT&CK - T1480.002: Mutual Exclusion](https://attack.mitre.org/techniques/T1480/002/) - [MITRE ATT&CK - T1480: Execution Guardrails](https://attack.mitre.org/techniques/T1480/) - [Microsoft Docs - CreateMutexA function](https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexa) - [Kaspersky - LockBit 3.0 Technical Analysis](https://securelist.com/lockbit-3-0-analysis/) - [Mandiant - APT38 Financial Crime](https://www.mandiant.com/resources/apt38-un-usual-suspects) - [Linux man page - flock(2)](https://man7.org/linux/man-pages/man2/flock.2.html) --- **Técnica Pai:** [[t1480-execution-guardrails|T1480 - Execution Guardrails]] **Técnicas Relacionadas:** [[Sandbox Evasion]] · [[t1622-debugger-evasion|T1622 - Debugger Evasion]] · [[t1480-001-environmental-keying|T1480.001 - Environmental Keying]] **Malware Associado:** [[s1247-embargo|Embargo]] · [[qilin|Qilin]] · [[s1161-bpfdoor|BPFDoor]] · [[s0013-plugx|PlugX]] · [[s1202-lockbit-30|LockBit 3.0]] · [[s0632-grimagent|GrimAgent]] · [[s0496-revil|REvil]] · [[s0012-poisonivy|PoisonIvy]] · [[s1236-claimloader|CLAIMLOADER]] · [[s1196-troll-stealer|Troll Stealer]] **Atores:** [[g0082-apt38|APT38]] · [[g0032-lazarus-group|Lazarus Group]] *Fonte: [MITRE ATT&CK - T1480.002](https://attack.mitre.org/techniques/T1480/002)*