T1480.002 — Mutual Exclusion

Tactic: Stealth · Platforms: Linux, macOS, Windows

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,…

Sub-technique of Execution Guardrails (T1480).

Sigma detection rules (3)

title: "T1480.002 Execution Guardrails: Mutual Exclusion"
id: f5dfc241-9b7c-4175-9e15-8d1267f37ffa
description: 'Detection of Mutex-Based Execution Guardrails Across Platforms, scoped to script-based mutex creation (PowerShell/.NET reflection referencing System.Threading.Mutex or the CreateMutex API by name) — a compiled binary calling the WinAPI CreateMutex function will not show that name in its own CommandLine, so this only catches the scripted-loader case. Tune using: mutex_name_entropy_threshold, parent_process_path, TimeWindow.'
references:
  - https://attack.mitre.org/techniques/T1480/002
author: Shahrukh Khan
date: 2026-05-26
license: MIT
tags:
  - attack.stealth
  - attack.t1480.002

logsource:
  category: process_creation
  product: windows
  service: sysmon

detection:
  selection:
    CommandLine|contains:
      - 'System.Threading.Mutex'
      - 'CreateMutex'

  condition: selection

falsepositives:
  - Legitimate PowerShell/.NET scripts using mutexes for single-instance locking; this rule alone is too weak to act on and needs pairing with a known-malicious mutex-name list. Compiled-binary WinAPI CreateMutex calls are not observable this way at all.

level: informational

title: "T1480.002 Execution Guardrails: Mutual Exclusion"
id: b27ce0a6-8b49-4797-91f0-c295274fe8ef
description: 'Detection of Mutex-Based Execution Guardrails via Lock-File Creation on Linux. The prior version flagged creation of any .lock file under /tmp or /var/run, which is extremely common ordinary application behavior (PID files, package-manager locks, browser profile locks), and its own tuning fields promised an exit_code correlation - the actual check-then-exit guardrail signature - that the detection logic never implemented. Narrowed to lock-file naming conventions more consistent with malware mutex checks (single-segment hex/hash-like basenames, or well-known malware-family lock-file names) rather than any .lock file; genuine confirmation of the guardrail behavior (process exits immediately after a failed lock attempt) still requires correlating this event with a subsequent short-lived process exit, which a single file_event rule cannot express. Tune using: lockfile_path_regex, exit_code, TimeWindow.'
references:
  - https://attack.mitre.org/techniques/T1480/002
author: Shahrukh Khan
date: 2026-04-22
license: MIT
tags:
  - attack.stealth
  - attack.t1480.002

logsource:
  category: file_event
  product: linux

detection:
  selection:
    type: PATH
    nametype: CREATE
    name|re: '/(tmp|var/run)/[0-9a-f]{16,}\.lock
    
  



  condition: selection

falsepositives:
  - Some legitimate applications also use long hex-like lock-file identifiers; genuine confirmation of the mutex-guardrail pattern still requires correlating this event with the creating process's own short-lived exit, which this rule alone cannot do.

level: low

title: "T1480.002 Execution Guardrails: Mutual Exclusion"
id: b49dbc86-a825-4f19-aad3-c16aaf39d56b
description: 'Detection of Mutex-Based Execution Guardrails Across Platforms. (Retargeted to the process_termination macOS unified-log telemetry that actually captures this techniques behavior; see logsource below.) Tune using: lockfile_path, user_context, TimeWindow.'
references:
  - https://attack.mitre.org/techniques/T1480/002
author: Shahrukh Khan
date: 2026-03-27
license: MIT
tags:
  - attack.stealth
  - attack.t1480.002

logsource:
  category: process_termination
  product: macos

detection:
  selection:
    Image|contains: '/private/tmp/'
    Image|endswith:
      - '.lock'
      - '.pid'
  condition: selection

falsepositives:
  - Mutual exclusion checks using a lock file are a standard technique used by legitimate daemons and installers to prevent multiple concurrent instances, so this is only a weak signal without knowing the parent binary is unsigned or previously unseen.

level: informational

Related sub-techniques

• T1480.001 Environmental Keying

Explore

• All Sigma rules for MITRE ATT&CK
• Sigma rule format guide
• Full T1480.002 intelligence — ATT&CK Intelligence View
• Official MITRE ATT&CK entry
• Built by Shahrukh Khan