Predictable lock file created under tmp or run as an execution guardrail

Siemphony@siemphonylowT1480.002unverified

AN0373 describes malware acquiring a lock on a predictable path such as /tmp/.lock123 and diverging behaviour on success or failure. This rule takes the file-access leg: an auditd PATH record naming a hidden or lock-suffixed path under /tmp, or a lock-suffixed path under /var/run, which is MITRE's `lockfile_path_regex` knob populated with the two examples the analytic itself gives. A fourth selection matches on the audit `key` field so that a watch loaded with an explicit `-k` tag (for example `mutex_lock`) still catches paths the two path patterns miss, the same defense-in-depth pattern used elsewhere in this corpus for unpredictable path spellings. AN0373's other half — correlating the lock attempt with a rapid `exit_group` or specific exit code within a short window — is not implemented. lib/sigma has no join across two auditd records and no timeframe, so this rule matches the lock-file touch alone, without knowing whether the process that touched it then exited early or ran on normally. AN0372, the Windows leg of this analytic, is not attempted. It asks for `CreateMutexW` and equivalent named-object creation, but the brief's own log sources for it are Sysmon EventID 1 (process creation) and EventID 11 (file creation) — neither of which is the shape of a mutex-creation event, and Sysmon emits no event for named kernel object creation at all. Inventing a mutex field on either source would produce a rule that renders and matches nothing. AN0374, the macOS leg, is not attempted either: its unifiedlog source has no standardised Sigma field names, and inventing them the way AN0372 would have to is the same failure mode. Prerequisite: neither /tmp nor /var/run/lock is audited by default. This needs explicit watch rules — `-w /tmp -p wa -k mutex_lock` and `-w /var/lock -p wa -k mutex_lock` (the conventional destination of the /var/run/lock symlink) — loaded before this returns any rows; without them, zero rows means the sensor is blind, not that the host is clean. `-p wa` matters for noise: adding read permission makes every process that merely checks whether a lock exists match as well. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0132, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 2 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* | where ((match(type, "(?i)^PATH$") AND match(name, "/tmp/\\.[^/]*lock[^/]*$")) OR (match(type, "(?i)^PATH$") AND match(name, "/var/(run|lock)/[^/]*lock[^/]*$")) OR match(key, "(?i)^mutex_lock$"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 3 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)/tmp/\.[^/]*lock[^/]*$</field>    <description>Predictable lock file created under tmp or run as an execution guardrail (1/3)</description>    <mitre>      <id>T1480.002</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)/var/(run|lock)/[^/]*lock[^/]*$</field>    <description>Predictable lock file created under tmp or run as an execution guardrail (2/3)</description>    <mitre>      <id>T1480.002</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="key" type="pcre2">(?i)^mutex_lock$</field>    <description>Predictable lock file created under tmp or run as an execution guardrail (3/3)</description>    <mitre>      <id>T1480.002</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

Elastic · ES|QL

Run this as a search.

Elastic cannot express this construct. ES|QL RLIKE uses Lucene regexp syntax, which has no case-insensitive flag, and Sigma regexes are case-insensitive. Use |contains/|startswith/|endswith, or write the ES|QL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: obfuscated_payloads
Sigma status: experimental
Backends: 2 of 4 rendered
Updated: 30 Aug 2026
Rule ID: cb6a47f6-c944-4379-8747-7d1956b36e11

ATT&CKT1480.002

T1480.002Mutual Exclusion

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonobfuscated payloads

obfuscated payloadsAI draft — unreviewed

01 · What this rule detects

Execution Guardrails: Mutual Exclusion (T1480.002) — malware that checks for a predictable lock, mutex, or marker file before running, so it executes only once per host or only outside a sandbox that lacks the expected artifact. This rule covers the Linux file-access leg of MITRE's AN0373: an attempt to acquire a lock on a predictable path such as /tmp/.lock123.

02 · Telemetry you need

Linux auditd, with explicit watch rules loaded — -w /tmp -p wa -k mutex_lock and -w /var/lock -p wa -k mutex_lock (the conventional target of the /var/run/lock symlink). Neither /tmp nor /var/run/lock is audited by default, so without these watches the rule returns zero rows, and that silence means the sensor is blind, not that the host is clean.

03 · How the logic works

Three selections joined with 1 of selection*, so any one alone fires the rule. selection_hidden_tmp_lock matches a PATH record with name|re: '/tmp/\.[^/]*lock[^/]*$' — a hidden, lock-suffixed filename directly under /tmp. selection_var_run_lock matches name|re: '/var/(run|lock)/[^/]*lock[^/]*$', covering the same pattern under /var/run or /var/lock. Both regexes are MITRE's lockfile_path_regex knob, populated here with the two path examples the analytic itself gives — not an exhaustive enumeration MITRE provided. selection_watch_key matches on the auditd key field alone, for example mutex_lock, so a watch loaded with that explicit -k tag still catches lock paths the two regexes miss — a defense-in-depth pattern for unpredictable path spellings. This third selector is the pipeline's own addition, not something MITRE specified. AN0373's other half — correlating the lock attempt with a rapid exit_group or specific exit code within a short window, which is what actually distinguishes "guardrail tripped, malware exits" from "lock acquired, malware proceeds" — is not implemented. lib/sigma has no join across two auditd records and no timeframe, so this rule matches the lock-file touch alone, blind to what happened next. The Windows leg (AN0372, CreateMutexW) and macOS leg (AN0374, unifiedlog) are not attempted: neither brief source can carry a mutex-creation event without inventing fields that would never match anything real.

04 · Common false positives

Three concrete sources are named. Starting any X11 session creates /tmp/.X0-lock (and .X1-lock, etc.) at every login on any Linux desktop or GUI session — this matches the hidden-tmp-lock pattern exactly and is the single loudest source on any workstation fleet. Normal use of /var/lock — init scripts, setserial, mail-spool locking, and similar system tooling — creates and removes lock files there as everyday service start/stop. Terminal multiplexers like screen and tmux place a lock-suffixed session file under /tmp for every session. level: low reflects that these three sources fire constantly on any live Linux estate.
A reviewer also noted the selection_watch_key selector has no type constraint, so it matches any audit record tagged with that key regardless of syscall — if a site reuses the same -k tag across unrelated watch rules, this fires on that activity too.

05 · Detection maturity

tier_1: This rule has never been run against a log line. It sits at the lowest DeBMM maturity tier until it has been run against real auditd data from a host with the prerequisite watches actually loaded.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Use -p wa exactly, not -p rwa: adding read permission makes every process that merely checks whether a lock exists match as well, which is most of the noise above. Document that the -k mutex_lock label must be dedicated to this watch and not shared with other -w rules elsewhere in the audit config, or drop selection_watch_key and rely on the two path regexes alone.

Declared by the author

Starting an X11 session. The X server itself creates /tmp/.X0-lock (and .X1-lock, .X2-lock, etc., one per display) at every login on any Linux desktop or GUI session, which matches the hidden-tmp-lock pattern exactly and is the single loudest source of matches on any workstation fleet.
Normal use of /var/lock (the conventional target of the /var/run/lock symlink), the standard Linux location for subsystem and serial-port lock files — init scripts, setserial, mail-spool locking and similar system tooling create and remove lock files there as part of everyday service start and stop.
Terminal multiplexers and session managers such as screen and tmux, which place their own session lock files under /tmp with a lock-suffixed name for every session started.

Noise checkdid not run

The Sigma source did not build into an evaluable rule, so the check did not run. this rule uses a regular expression, which is not evaluated here — an untrusted pattern can be made to run for a very long time

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1480.002, evaluated against their — events.

Share this rule

/u/siemphony/cb6a47f6-c944-4379-8747-7d1956b36e11

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Predictable lock file created under tmp or run as an execution guardrail

The detection

detection.yml

Splunk · SPL

Wazuh · XML rule

Sentinel · KQL

Elastic · ES|QL

Community

Verdicts from engineers who deployed it