T1480.002sub-technique of T1480 Execution Guardrails

Mutual Exclusion

Linux · macOS · Windowsnothing on this site yetT1480.002 on attack.mitre.org

Adversaries may constrain execution or actions based on the presence of a mutex associated with malware. A mutex is a locking mechanism used to synchronize access to a resource. Only one thread or process can acquire a mutex at a given time. While local mutexes only exist within a given process, allowing multiple threads to synchronize access to a resource, system mutexes can be used to synchronize the activities of multiple processes.

MITRE ATT&CK 19.2, retrieved 2026-09-12

how MITRE says to see it

Detection of Mutex-Based Execution Guardrails Across Platforms

  • Adversary-created named mutex using system APIs (e.g., CreateMutexW) followed by conditional process termination or alternate code path indicating malware avoiding reinfection.
  • File lock acquired via open() + flock() or lockf() on predictable path (e.g., /tmp/.lock123) followed by conditional early exit or divergent process behavior.
  • User-mode application uses flock() or NSDistributedLock to gain exclusive access to a resource file (e.g., /tmp/guard.lock), conditional logic alters execution if already locked.

what reduces it

  • M1055 Do Not Mitigate. Execution Guardrails likely should not be mitigated with preventative controls because it may protect unintended targets from being compromised. If targeted, efforts should be focused on preventing adversary tools from running earlier in the chain of activity and on identifying subsequent malicious behavior if compromised.

the rest of T1480

The description, detection analytics and mitigations are reproduced from MITRE ATT&CK, version 19.2, under its terms of use. The checklists, hunts, labs and everything else linked here are this site’s.