File written to a Linux shared-memory directory

Siemphony@siemphonylowT1027.011unverified

AN0974 asks for use of /dev/shm and /run/shm to store obfuscated, encoded or executable content without ever touching disk — the concrete Linux form of this technique's "fileless storage" claim, since files under these paths are tmpfs-backed and mapped straight to RAM. This rule matches the file-write leg directly: an auditd PATH record whose name falls under one of those two directories, using the raw {product: linux, service: auditd} vocabulary (`type`, `name`, `key`) already established elsewhere in this corpus for T1053.003, T1543.002, T1546.017 and T1547.006. MITRE's own list of fileless locations also names /var/run and /var/lock, but those are excluded here on purpose: unlike /dev/shm, both are the default home for ordinary PID and lock files written by essentially every daemon on every Linux host, so a bare path match against them would fire continuously and add nothing a reviewer could act on — over-matching everything is the same silent failure as under-matching nothing, just in the other direction. The `key: 'shm_write'` branch is this rule's own suggested audit-key convention, not one MITRE supplies, offered as a second way to catch the same event if a deployment's watch uses that key. Two of MITRE's three knobs cannot be honestly populated here: PayloadEntropyThreshold has no field to bind to, because a PATH record carries only the filename that was touched and never the bytes written to it — this is the same gap already documented against T1001.001's DNS-label proxy, and there is no substitute proxy on this event either, so the rule does not attempt one; and ExecCorrelationWindow asks for a time-windowed join between this write and a later process execution or network connection from the same file, which lib/sigma has no timeframe or aggregation construct to express — auditd's own PATH/SYSCALL split means even the writing process's `exe` lives on a separate record this selection does not reach. The osquery leg of the same analytic, {product: linux, service: osquery}, is not attempted: no rule in this corpus has an established Sigma field vocabulary for that source. AN0973, the Windows registry/WMI leg of this strategy, is not attempted either. Its logsource maps Security EventID 4657 onto Sigma's `registry_set` category, which is Sysmon-shaped — `TargetObject` carrying the full key-plus-value path and `Details` carrying the data — while native 4657 XML splits those into separate `ObjectName` and `ObjectValueName` fields with no single field holding both; authoring against `TargetObject`/`Details` here would silently assume a normalisation layer the brief does not supply, the same trap AUTHORING.md's guidance on Sysmon-shaped categories over Security event IDs warns against. 4657 is also gated behind more than the usual missing audit policy: it requires the Audit Registry subcategory to be enabled *and* a SACL placed on each individual key a defender wants to watch, so unlike most "off by default" telemetry in this corpus it stays silent on every key until someone enumerates and SACLs the specific keys AN0973 cares about — a materially higher bar than turning on a subcategory. Between a registry leg blocked on both field-mapping and a heavier-than-usual audit prerequisite, and a shared-memory leg with an established vocabulary and a real path to a working watch, this rule takes the latter. Prerequisite: auditd records nothing under /dev/shm or /run/shm by default; a watch such as `-w /dev/shm -p wa -k shm_write` is required first (on most current distributions /run/shm is a symlink to /dev/shm, so one watch typically covers both paths) — zero rows without it means blind, not quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0344, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 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=* ((type="PATH" AND (name="*/dev/shm/*" OR name="*/run/shm/*")) OR key="shm_write")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/dev/shm/*" OR TO_LOWER(name) LIKE "*/run/shm/*")) OR TO_LOWER(key) == "shm_write")

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. -->  <!-- 2 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)(/dev/shm/|/run/shm/)</field>    <description>File written to a Linux shared-memory directory (1/2)</description>    <mitre>      <id>T1027.011</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="key" type="pcre2">(?i)^shm_write$</field>    <description>File written to a Linux shared-memory directory (2/2)</description>    <mitre>      <id>T1027.011</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.

At a glance

Logsource: auditd / linux
Level: low
Category: obfuscated_payloads
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 06cb8f75-7632-47a7-885d-b3093d6d7518

ATT&CKT1027.011

T1027.011Fileless Storage

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

A single Linux auditd PATH record naming a file under /dev/shm/ or /run/shm/, or an auditd record tagged with the audit key shm_write. AN0974 asks for use of these tmpfs-backed, RAM-mapped directories to store obfuscated, encoded or executable content without ever touching disk — the concrete Linux form of this technique's "fileless storage" claim. The rule matches the write itself, not anything about what was written.

02 · Telemetry you need

product: linux, service: auditd — the raw PATH/SYSCALL vocabulary (type, name, key) already used elsewhere in this corpus. Prerequisite the rule states plainly: auditd records nothing under these paths by default. A watch such as -w /dev/shm -p wa -k shm_write has to be loaded first. On most current distributions /run/shm is a symlink to /dev/shm, so one watch typically covers both. Zero rows without that watch means blind, not quiet.

03 · How the logic works

Two independent ways to catch the same event. selection_shm_paths matches on the path itself regardless of what audit key was used. selection_watch_key is this pipeline's own suggested key convention, offered as a second path if a deployment's watch happens to use that key already — not something MITRE specifies. MITRE's fileless-locations list also names /var/run and /var/lock, and the rule deliberately excludes both: they are the default home for ordinary PID and lock files written by nearly every daemon on the box, so a bare path match there would fire continuously and add nothing actionable — the same silent failure as under-matching, in the other direction. Two of AN0974's three knobs go unpopulated, and the rule says so directly. PayloadEntropyThreshold has no field to bind to: a PATH record carries only the filename touched, never the bytes written, so there is no entropy proxy available on this event at all. ExecCorrelationWindow asks for a time-windowed join between this write and a later execution or network connection from the same file — lib/sigma has no timeframe or aggregation construct, and auditd's PATH/SYSCALL split means the writing process's exe lives on a separate record this selection never reaches. PathPrefix is the knob actually implemented, as selection_shm_paths. The rule also declines two adjacent legs of the same strategy: the osquery source (no established Sigma field vocabulary in this corpus), and AN0973, the Windows registry/WMI leg, whose Security EventID 4657 maps onto Sigma's Sysmon-shaped registry_set category without a compatible field layout and carries a heavier-than-usual audit prerequisite (a SACL per watched key).

04 · Common false positives

The false positives are all legitimate /dev/shm tenants: PulseAudio and other audio daemons keeping pulse-shm- prefixed segments rewritten continuously during normal playback; headless Chromium, Electron and Node.js processes — extremely common in CI and browser automation — mapping renderer buffers there by default; PostgreSQL and other databases using POSIX shared memory (sem.*, dsm_*) for routine IPC; and systemd-journald's structured logging buffers under /run/shm, active from boot on essentially every current distribution. level: low reflects that the top entries are routine, always-on system behaviour, not edge cases.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0344, never run against a log line. The path list and the shm_write key convention are unvalidated guesses.
tier_2: needs a week of the two selections against a real host, ranking surviving filenames by writing process to build the daemon allowlist above.

Tuning & false positivesexperimental · 4 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

Suppress the daemons above by process name once the writing exe is correlated in from the paired SYSCALL record — something this Sigma rule cannot do alone, so plan on a SIEM-side join. Watch for a genuinely missing knob: since no rule here can bind entropy or filename shape, a human reviewer still has to eyeball each surviving filename for base64-charset or otherwise suspicious patterns before triaging a hit as interesting.

Declared by the author

PulseAudio and other desktop or container audio daemons that keep persistent shared-memory segments under /dev/shm, named with a pulse-shm- prefix, rewritten continuously during ordinary audio use.
Headless Chromium, Electron and Node.js applications, extremely common in browser-automation and CI pipelines, which map renderer shared-memory buffers into /dev/shm by default — the reason such containers are routinely launched with an enlarged --shm-size.
PostgreSQL and other database engines that use POSIX shared memory and semaphore files (sem., dsm_ segments) under /dev/shm for inter-process coordination during normal operation.
systemd-journald and other systemd-managed services that keep structured logging or IPC buffers under /run/shm on any systemd-managed host, active from boot on essentially every current distribution.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

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.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

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

Recordings of T1027.011, evaluated against their — events.

Share this rule

/u/siemphony/06cb8f75-7632-47a7-885d-b3093d6d7518

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.

File written to a Linux shared-memory directory

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it