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]
2 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has utilized a mutex to detect whether its malware is actively running on the victim host.12 Kimsuky has leveraged PowerShell to store the Process ID (PID) of the currently running malicious PowerShell script into a file named pid.txt which is saved locally on the victim host in the %TEMP% Directory and is queried prior to execution of subsequent PowerShell script to prevent duplication.2
Has created a mutex to avoid duplicate execution.1
All 2 groups for this technique
18 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has fixed a buffer overflow vulnerability (CVE-2025-0282) by hooking the strncpy function and limiting the size to 256 to prevent other actors from leveraging the exploit.1 SPAWNCHIMERA has converted its process name to hexadecimal and verifies an added value which is triggered when the first byte of the source copied to the fixed strncpy function matches 0x04050203.1
Can create a mutex to ensure only one instance is running at a time.1
Code contains a global mutex.1
Has utilized a hardcoded mutex name of “LoadUpOnGunsBringYourFriends” using the CreateMutexW() function.1 Embargo has also utilized a hardcoded mutex name of “IntoTheFloodAgainSameOldTrip."2
Can create a mutex to ensure only one instance is running.1
Has created a mutex to avoid duplicate execution.1
All 18 software entries for this technique · 6 newest in this preview
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
AN0372 · Windows
Adversary-created named mutex using system APIs (e.g., CreateMutexW) followed by conditional process termination or alternate code path indicating malware avoiding reinfection.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| mutex_name_entropy_threshold | Filter out common benign mutex names; highlight suspicious high-entropy/dynamic names. |
| parent_process_path | Limit alerting to non-standard parent-child relationships indicative of malware staging or self-spawning. |
| TimeWindow | Correlate mutex creation + rapid process exit or lack of further activity within a short timeframe. |
AN0373 · Linux
File lock acquired via open() + flock() or lockf() on predictable path (e.g., /tmp/.lock123) followed by conditional early exit or divergent process behavior.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process TerminationDC0033 | auditd:SYSCALL | exit_group |
| File AccessDC0055 | auditd:SYSCALL | open, flock, fcntl, unlink |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| lockfile_path_regex | Detect patterns like /tmp/.lock*, /var/run/*lock used by malware. |
| exit_code | Track specific exit codes (e.g., 1, 2) that signal lock acquisition failure. |
| TimeWindow | Correlate lockfile access + early process termination within N seconds. |
AN0374 · macOS
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.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| OS API ExecutionDC0021 | macos:unifiedlog | flock|NSDistributedLock|FileHandle.*lockForWriting |
| Process TerminationDC0033 | macos:unifiedlog | process.*exit.*code |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| lockfile_path | Path to mutex file (e.g., /tmp/*, /private/tmp/*), tune per environment. |
| user_context | Flag non-user processes using these APIs. |
| TimeWindow | Detection correlation across short time intervals between lock attempt and process exit. |
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.
No detection rules are mapped to this technique yet.
Loading detections...
| Select | Title | Description | Category | Status | Event | Product | MITRE ATT&CK | CVEs | Severity | Author | Created | Updated | ID | Refs |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|