T1480.002: Mutual Exclusion
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.[1]
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.[1] By creating a unique system mutex associated with a particular malware, adversaries can verify whether or not a system has already been compromised.[2]
In Linux environments, malware may instead attempt to acquire a lock on a mutex file. If the malware is able to acquire the lock, it continues to execute; if it fails, it exits to avoid creating a second instance of itself.[3][4]
Mutex names may be hard-coded or dynamically generated using a predictable algorithm.[5]
Analyst context for executives and security teams
Mutual Exclusion is a stealth guardrail where malware checks for a mutex or lock file so it can decide whether to run, avoid duplicate execution, or infer that a host is already compromised. For leaders, the value is less about blocking mutexes and more about whether SOC and IR teams can see these execution guardrails when investigating suspicious processes across Windows, Linux, and macOS.
Executive priority
Treat this as an incident-readiness and detection-quality issue. The ATT&CK relationships show this behavior across multiple malware categories, including remote access tools, backdoors, stealers, and ransomware families. Because ATT&CK lists “Do Not Mitigate” for this technique, executives should not expect a simple preventive control; they should ask whether endpoint telemetry, malware analysis, and response playbooks can use mutex or lock-file evidence to confirm infection scope, avoid missed hosts, and support audit-ready investigation records.
Technical view
This sub-technique belongs to Execution Guardrails under the stealth tactic. Defenders should validate coverage for Windows system mutex artifacts and Linux-style mutex or lock-file behavior, with macOS considered in endpoint process and file telemetry where applicable. Since ATT&CK provides no official detection text, use relationship context from DET0132, Detection of Mutex-Based Execution Guardrails Across Platforms, as the validation direction: confirm whether EDR, sandboxing, memory/artifact collection, and malware triage workflows expose named synchronization objects, lock files, process start/exit behavior, and extracted hard-coded or predictably generated mutex names.
Likely telemetry
- Endpoint process creation, termination, and parent-child context around suspicious binaries
- Windows named mutex or system synchronization object artifacts where available from EDR, memory analysis, or sandbox execution
- Linux file activity for mutex or lock files, including creation, open, and lock-acquisition related evidence where collected
- Static and dynamic malware-analysis output showing hard-coded or algorithmically generated mutex names
- Host forensic artifacts that correlate mutex or lock-file presence with the same malware across multiple systems
Detection direction
- Do not rely on mutex names alone; legitimate software commonly uses mutexes and other locking mechanisms for single-instance execution.
- Prioritize suspicious context: unusual executable location, unexpected process lineage, newly observed mutex or lock-file names, and correlation with known malware analysis from the incident.
- Validate cross-platform visibility separately. Windows mutex visibility may differ from Linux lock-file visibility, and macOS coverage may depend heavily on endpoint tooling and forensic collection depth.
- Tune for relationship-driven risk: related ATT&CK software includes RATs, backdoors, stealers, loaders, and ransomware, so mutex evidence may be useful for scoping and clustering even when it is not the first alert.
- Account for blind spots: mutexes can be transient, dynamically generated, or only visible during execution, so sandbox timing and live-response collection matter.
Mitigation priorities
- Follow ATT&CK’s mitigation relationship: do not try to broadly block mutex or locking mechanisms, because they are normal operating-system and application behavior.
- Invest first in detection, monitoring, malware triage, and incident-response collection procedures for mutex and lock-file artifacts.
- Ensure endpoint controls and response tooling can preserve process, file, and memory context needed to interpret these artifacts.
- Use discovered mutex or lock-file indicators as supporting evidence for containment and scoping, not as standalone proof without process and host context.
- In post-incident reviews, add confirmed mutex or lock-file indicators to internal detection content and threat-intelligence records where they are reliable.
Analyst notes and limits
The object is a sub-technique of Execution Guardrails and is explicitly tied to stealth. Its practical importance is that mutex or lock-file behavior can help malware avoid duplicate execution and can help responders identify already affected systems. Relationship context includes APT38, Kimsuky, and numerous software entries, but those relationships should be used as context rather than as proof of local exposure or active exploitation.
ATT&CK provides no official detection text for this object. Specific mutex names, lock-file paths, collection methods, and reliable detections must come from local telemetry, malware samples, sandbox results, or incident evidence. The supplied technique platforms are Linux, macOS, and Windows; broader platform claims should not be inferred from related software entries alone.
Mutual Exclusion
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.[1]
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.[1] By creating a unique system mutex associated with a particular malware, adversaries can verify whether or not a system has already been compromised.[2]
In Linux environments, malware may instead attempt to acquire a lock on a mutex file. If the malware is able to acquire the lock, it continues to execute; if it fails, it exits to avoid creating a second instance of itself.[3][4]
Mutex names may be hard-coded or dynamically generated using a predictable algorithm.[5]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1480 | Execution Guardrails | This object subtechnique of Execution Guardrails. |
Groups, software, and campaigns
G0094: Kimsuky
Kimsuky is a Democratic People's Republic of Korea (DPRK)-based cyber espionage group that has been active since at least 2012. The group initially targeted South Korean government agencies, think tanks, and subject-matter experts in various fields. Its operations expanded to include the United Nations and organizations in the government, education, business services, and manufacturing sectors across the United States, Japan, Russia, and Europe. Kimsuky has focused collection on foreign policy and national security issues tied to the Korean Peninsula, nuclear policy, and sanctions. Kimsuky operations have overlapped with those of other North Korean state-sponsored cyber espionage actors as a result of ad hoc collaborations or other limited resource sharing.[1][2][3][4][5][6]
Kimsuky was assessed to be responsible for the 2014 Korea Hydro & Nuclear Power Co. compromise; other notable campaigns include Operation STOLEN PENCIL (2018), Operation Kabar Cobra (2019), and Operation Smoke Screen (2019).[7][8][9] In 2023, Kimsuky was observed using commercial large language models (LLMs) to assist with vulnerability research, scripting, social engineering and reconnaissance.[10]
DPRK threat actor cluster boundaries overlap in open source reporting, with some security researchers consolidating all attributed North Korean state-sponsored cyber activity under Lazarus Group, rather than tracking operationally distinct subgroups.
G0082: APT38
APT38 is a North Korean state-sponsored threat group that specializes in financial cyber operations; it has been attributed to the Reconnaissance General Bureau.[1] Active since at least 2014, APT38 has targeted banks, financial institutions, casinos, cryptocurrency exchanges, SWIFT system endpoints, and ATMs in at least 38 countries worldwide. Significant operations include the 2016 Bank of Bangladesh heist, during which APT38 stole $81 million, as well as attacks against Bancomext [2] and Banco de Chile [2]; some of their attacks have been destructive.[1][2][3][4]
North Korean group definitions are known to have significant overlap, and some security researchers report all North Korean state-sponsored cyber activity under the name Lazarus Group instead of tracking clusters or subgroups.
S1247: Embargo
Embargo is a ransomware variant written in Rust that has been active since at least May 2024.[1][2] Embargo ransomware operations are associated with “double extortion” ransomware activity, where data is exfiltrated from victim environments prior to encryption, with threats to publish files if a ransom is not paid.[1][2] Embargo ransomware has been known to be delivered through a loader known as MDeployer which also leverages a malware component known as MS4Killer that facilitates termination of processes operating on the victim hosts.[2] Embargo is also reportedly a Ransomware as a Service (RaaS).[2]
S1242: Qilin
Qilin is a ransomware family operated as a ransomware-as-a-service (RaaS) that has been active since at least 2022. It includes variants written in Go and Rust capable of targeting Windows, Linux, and VMware ESXi environments. Qilin shares functionality overlaps with Black Basta, REvil, and BlackCat ransomware. Qilin affiliates have targeted multiple entities worldwide with the majority of victims in the US, France, Canada, and the UK, primarily in the manufacturing, technology, financial services, and healthcare sectors.[1][2][3][4][5]
S9019: PureCrypter
PureCrypter is a fully-featured malware loader, developed by a threat actor called “PureCoder," that has been in use since at least 2021 to distribute a variety of remote access trojans and information stealers.[1]
S1161: BPFDoor
BPFDoor is a Linux based passive long-term backdoor used by China-based threat actors. First seen in 2021, BPFDoor is named after its usage of Berkley Packet Filter (BPF) to execute single task instructions. BPFDoor supports multiple protocols for communicating with a C2 including TCP, UDP, and ICMP and can start local or reverse shells that bypass firewalls using iptables.[1][2]
S0013: PlugX
S1202: LockBit 3.0
LockBit 3.0 is an evolution of the LockBit Ransomware-as-a-Service (RaaS) offering with similarities to BlackMatter and BlackCat ransomware. LockBit 3.0 has been in use since at least June 2022 and features enhanced defense evasion and exfiltration tactics, robust encryption methods for Windows and VMware ESXi systems, and a more refined RaaS structure over its predecessors such as LockBit 2.0.[1][2][3][4]
S9023: HiddenFace
HiddenFace is a modular backdoor developed and used exclusively by MirrorFace since at least 2021. HiddenFace can communicate both actively and passively and has been used against political and academic targets.[1][2][3]
S0632: GrimAgent
GrimAgent is a backdoor that has been used before the deployment of Ryuk ransomware since at least 2020; it is likely used by FIN6 and Wizard Spider.[1]
S0496: REvil
REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service (RaaS) since at least April 2019. REvil, which as been used against organizations in the manufacturing, transportation, and electric sectors, is highly configurable and shares code similarities with the GandCrab RaaS.[1][2][3]
S0012: PoisonIvy
S1236: CLAIMLOADER
CLAIMLOADER is a malware variant that frequently accompanies legitimate executables that are used for DLL side-loading known to be leveraged by Mustang Panda and was first observed utilized in 2021.[1][2]
S1196: Troll Stealer
Troll Stealer is an information stealer written in Go associated with Kimsuky operations. Troll Stealer has typically been delivered through a dropper disguised as a legitimate security program installation file. Troll Stealer features code similar to AppleSeed, also uniquely associated with Kimsuky operations.[1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 9d67ae36ff55… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft Mutexes
Microsoft. (2022, March 11). Mutexes. Retrieved September 19, 2024.
Open source URL -
[2]
Sans Mutexes 2012
Lenny Zeltser. (2012, July 24). Looking at Mutex Objects for Malware Discovery & Indicators of Compromise. Retrieved September 19, 2024.
Open source URL -
[3]
Intezer RedXOR 2021
Joakim Kennedy and Avigayil Mechtinger. (2021, March 10). New Linux Backdoor RedXOR Likely Operated by Chinese Nation-State Actor. Retrieved September 19, 2024.
Open source URL -
[4]
Deep Instinct BPFDoor 2023
Shaul Vilkomir-Preisman and Eliran Nissan. (2023, May 10). BPFDoor Malware Evolves – Stealthy Sniffing Backdoor Ups Its Game. Retrieved September 19, 2024.
Open source URL -
[5]
ICS Mutexes 2015
Lenny Zeltser. (2015, March 9). How Malware Generates Mutex Names to Evade Detection. Retrieved September 19, 2024.
Open source URL -
[6]
mitre-attack T1480.002Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.