AN0372: Analytic 0372
Adversary-created named mutex using system APIs (e.g., CreateMutexW) followed by conditional process termination or alternate code path indicating malware avoiding reinfection.
Analyst context for executives and security teams
This analytic points to a Windows malware behavior where code creates a named mutex through system APIs and then exits or changes behavior if that mutex already exists. For leaders, the value is not the mutex itself; it is that this pattern can help identify malware families trying to avoid reinfecting the same host or duplicating execution. It is a useful signal for SOC and incident response teams when combined with process, API, and endpoint context.
Executive priority
Prioritize this as a detection engineering and incident triage validation item for Windows endpoint coverage. It can support faster containment decisions when suspicious software appears to be managing its own execution state, but it should not be treated as a standalone proof of compromise. Leaders should ask whether endpoint telemetry can show named mutex creation and related process termination or alternate execution paths, and whether analysts have playbooks for validating suspicious mutex activity without over-escalating legitimate software behavior.
Technical view
Validate whether Windows endpoint telemetry can capture or infer process creation, named mutex creation via system APIs such as CreateMutexW, and the subsequent process behavior described by the analytic: conditional termination or a changed code path. Because no ATT&CK tactic, related technique, or detection logic is supplied, detection should be framed as a behavioral correlation rather than a single indicator. SOC teams should test whether EDR or host telemetry exposes mutex names, owning processes, image paths, command lines, parent processes, signatures, hashes, and near-time termination events.
Likely telemetry
- Windows endpoint/EDR process telemetry
- API or behavioral telemetry showing named mutex creation, where available
- Process termination events and short-lived process execution evidence
- Process lineage, image path, command line, file hash, and signer metadata
- Endpoint investigation artifacts linking mutex activity to the responsible process
Detection direction
- Correlate adversary-suspicious named mutex creation with rapid process exit or divergent execution behavior rather than alerting on mutex creation alone.
- Tune for context: legitimate Windows and third-party applications may use mutexes for normal single-instance behavior.
- Prioritize unusual or poorly trusted processes, unexpected paths, unsigned binaries, suspicious parent-child relationships, or mutex names that appear random or malware-like, if available in local telemetry.
- Confirm whether the current tooling can actually observe mutex creation; many environments may only infer this behavior through EDR behavioral analytics or memory/runtime inspection.
- Use this analytic as supporting evidence in investigations, not as a standalone high-confidence detection because no official detection logic is provided.
Mitigation priorities
- Ensure Windows endpoint monitoring is deployed and configured to retain process lineage and termination evidence relevant to short-lived suspicious processes.
- Validate EDR or host sensor capability for mutex/API visibility or equivalent behavioral detections.
- Build analyst procedures to review suspicious mutex behavior alongside file reputation, execution path, signer status, parent process, and host prevalence.
- Use application control, least privilege, and standard endpoint hardening to reduce unauthorized code execution paths where this behavior would appear.
- Document coverage gaps for audit and incident readiness, especially if mutex-level telemetry is unavailable.
Analyst notes and limits
The supplied object is a detection analytic, not a full ATT&CK technique. It describes a Windows behavior associated with malware avoiding reinfection: creating a named mutex and then terminating or selecting another execution path. With no relationship context and no official detection text, the strongest use is as a validation prompt for endpoint telemetry and correlation logic.
No ATT&CK tactic, related technique, relationship context, malware family, active exploitation claim, or official detection query was supplied. Local endpoint telemetry, tool capabilities, and baselining are required to determine whether this behavior is observable and meaningful in a specific environment.
Analytic 0372
Adversary-created named mutex using system APIs (e.g., CreateMutexW) followed by conditional process termination or alternate code path indicating malware avoiding reinfection.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | 1e1af0a1e08b… |
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]
mitre-attack AN0372Open 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.