Open of another process's /proc mem or maps file on Linux

Siemphony@siemphonylowT1055.009unverified

Matches an auditd PATH record naming `/proc/<pid>/mem` or `/proc/<pid>/maps` for any pid, which is what AN1494 describes: enumerating a target process's memory mappings via `/proc/[pid]/maps` to find gadgets, then overwriting its stack via `/proc/[pid]/mem`. Unlike the static `-w` file watches this corpus uses elsewhere (e.g. T1053.003's cron paths), the pid segment here is dynamic and cannot be named in a `-w` watch, so this rule only matches if the underlying audit configuration is a broad syscall rule on `open`/`openat` rather than a path watch — see the prerequisite note below. The regex is anchored so it only matches the two files under a numeric pid directory, not `/proc/self/...` or `/proc/<pid>/status` and similar metadata files that are read constantly and would swamp the rule. What this cannot see: `write(2)` operates on an already-open file descriptor and carries no path argument, so auditd never attaches a PATH record to it — this rule can only observe the `open`/`openat` of the target file, not the write that follows. That means it cannot distinguish a read-only inspection of `/proc/<pid>/mem` (some debuggers and profilers read it directly instead of using ptrace) from an actual overwrite; the open call's flags argument (`O_RDONLY` vs. `O_WRONLY`/`O_RDWR`) is carried in the SYSCALL record as a raw, unnamed integer this corpus does not decode, so read/write cannot be told apart here — that is a detection limitation, not a false positive. MITRE's `TimeWindowBetweenMapAccessAndMemWrite` and `FileWriteThreshold` knobs both need the write event this rule cannot observe, so they are not applied. The brief's other two logsources are not attempted: the `process_creation` execve logsource covers only the narrower case of `dd` or `sed` invoked directly against these paths, which this open-based selection already subsumes without needing a specific tool list; and `linux:osquery` has no standardised Sigma field vocabulary in this corpus, the same reason `macos:unifiedlog` was skipped for T1027.015's AN0784. Prerequisite: no distribution audits `/proc/*/mem` or `/proc/*/maps` opens by default, and because the path is per-pid, a `-w` watch cannot cover it — this needs a syscall-scoped rule such as `-a always,exit -F arch=b64 -S open -S openat -k procmem_access`, which also logs every other file open on the host and is high-volume by design. Until it is loaded, this rule returns zero rows, meaning blind rather than quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0541, 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, "^/proc/[0-9]+/(mem|maps)$"))

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. -->  <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)^/proc/[0-9]+/(mem|maps)$</field>    <description>Open of another process's /proc mem or maps file on Linux</description>    <mitre>      <id>T1055.009</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: process_injection
Sigma status: experimental
Backends: 2 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 05f179ed-6024-40aa-a2c7-73ed88e11c62

ATT&CKT1055.009

T1055.009Proc Memory

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.

Lessonprocess injection

process injectionAI draft — unreviewed

01 · What this rule detects

This rule matches an auditd PATH record naming /proc/<pid>/mem or /proc/<pid>/maps for any pid. That is the pair of files AN1494 describes as the mechanism of proc-memory injection: enumerating a target process's memory layout via maps to find ROP gadgets, then overwriting its memory via mem. The rule cannot tell the enumeration step from the overwrite step apart — both are just an open of one of these two paths — so a single match means "something opened one of these files," not "an injection happened."

02 · Telemetry you need

type: PATH records from logsource: linux / auditd. No distribution audits /proc/*/mem or /proc/*/maps opens by default. Because the path segment is a dynamic pid, a static -w file watch (the mechanism this corpus's Sigma rules usually rely on, e.g. T1053.003's cron paths) cannot cover it — this needs a broader syscall-scoped rule such as -a always,exit -F arch=b64 -S open -S openat -k procmem_access, which logs every file open on the host, not just these two paths, and is high-volume by design. Until that rule is loaded, this Sigma rule returns zero rows, meaning blind rather than quiet.

03 · How the logic works

A single selection block matches type: PATH with name|re: '^/proc/[0-9]+/(mem|maps)$'. The regex is anchored on both ends specifically so it does not also catch /proc/self/... or metadata files like /proc/<pid>/status, which are read constantly by ordinary tooling and would swamp the rule if the anchor were looser. What this cannot see: write(2) operates on an already-open file descriptor and carries no path argument, so auditd never attaches a PATH record to the write itself — only the open/openat that preceded it. That means the rule cannot distinguish a read-only inspection of /proc/<pid>/mem (some debuggers and profilers read it directly instead of via ptrace) from an actual overwrite. The open call's flags argument (O_RDONLY vs O_WRONLY/O_RDWR) sits in the SYSCALL record as a raw, undecoded integer this rule does not touch — a detection limitation, not a false positive, since it's a permanent structural gap rather than a benign source that happens to match.

04 · Common false positives

Three false positives are named, and the first is explicitly the loudest: monitoring and APM agents — Datadog, New Relic, Prometheus node/process exporters and similar — poll /proc/<pid>/maps for every process on the host on a short interval, making them the highest-volume match by a wide margin, which is why the rule is set to low rather than medium. Diagnostic tools such as pmap, gcore, and JVM memory diagnostics read maps (and, for gcore, mem) to produce heap or memory reports against a process an operator chose deliberately. A developer or SRE running gdb directly against /proc/<pid>/mem instead of through ptrace is a supported, documented technique that is indistinguishable here from the injection case.

05 · Detection maturity

tier_1: UNVERIFIED and at the lowest DeBMM tier — this rule has never been executed against a log line. It needs to run against a host with the broad open/openat audit rule loaded, be confirmed to fire on both benign APM polling and a real proc-memory injection tool, and be reassessed once real match volume is known, before any higher maturity claim is warranted.

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

MITRE's TimeWindowBetweenMapAccessAndMemWrite and FileWriteThreshold knobs both require observing the write itself, which this rule structurally cannot see, so neither is implemented. TargetProcNameRegex and InvokerBinaryAllowlist would need a join against the opening process's identity and the target pid's process name — data this single PATH record doesn't carry. A tuning path worth flagging to the reviewer independently of this lesson: the anchored regex assumes the auditd name= field always holds the full absolute path, but a process that chdir()s into /proc/<pid> first and then opens mem by the relative name defeats the anchor entirely, since the pid segment never appears in that PATH record.

Declared by the author

Monitoring and APM agents that poll /proc/<pid>/maps to compute RSS and memory-map statistics for every process on the host on a short interval — Datadog, New Relic, Prometheus node/process exporters and similar tools do this continuously and are the highest-volume match by a wide margin, which is why this rule is low rather than medium.
Diagnostic and profiling tools such as pmap, gcore and the JVM's own memory diagnostics, which read /proc/<pid>/maps (and, for gcore, /proc/<pid>/mem) to produce a heap or memory report against a target process the operator chose deliberately.
A developer or SRE running gdb or a similar debugger directly against /proc/<pid>/mem instead of through ptrace, which is a supported, documented way to read process memory and is indistinguishable here from the injection case.

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 T1055.009, evaluated against their — events.

Share this rule

/u/siemphony/05f179ed-6024-40aa-a2c7-73ed88e11c62

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.

Open of another process's /proc mem or maps file on Linux

The detection

detection.yml

Splunk · SPL

Wazuh · XML rule

Sentinel · KQL

Elastic · ES|QL

Community

Verdicts from engineers who deployed it