Another process's /proc memory named on a Linux command line

Siemphony@siemphonymediumT1003.007unverified

Matches a process launched with the /proc memory interface of a numbered PID in its arguments — /proc/<pid>/mem, /proc/<pid>/maps or /proc/<pid>/smaps — which is the shape AN1631 describes when it talks about multi-step access to another process's memory to scrape credential material. The match sits on CommandLine and not on Image on purpose: the published tooling for this is shell and Python (mimipenguin ships as both, and the technique description itself is a grep-and-cut one-liner), so on any process-creation feed the executable is /bin/bash or /usr/bin/python3 and a selector keyed on a tool name would never fire. MITRE supplies the `AccessedFilePath` knob; restricting it to a numeric PID is authored here, because /proc/self/mem and /proc/self/maps are self-inspection performed constantly by language runtimes, container sandboxes and CI test suites, and the credential case in this analytic is one process reading a *different* process's address space. The three auditd log sources in the brief were not used. auditd file watches are inode-based and /proc's per-PID entries are created and destroyed with every process, so there is no stable path to watch; the syscall-filter form (-F dir=/proc -F perm=r) does load but then records every read of /proc, which on any host means every ps, top, monitoring agent and container-runtime poll. The ptrace and process_vm_readv leg is a SYSCALL record carrying exe and a numeric syscall value but no path at all, so it cannot say whose memory was read and could not carry MITRE's `AccessedFilePath` knob. Two limits follow from using process creation: a compiled implant that opens /proc/<pid>/mem through a path it builds at runtime puts nothing in argv and is invisible here, and MITRE's `UserContext` knob is not applied, since root reading /proc is also how most legitimate agents work. Prerequisite: Sysmon for Linux is a separate agent that no distribution installs by default, so a host running stock auditd alone produces nothing this rule can read. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0593, 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(CommandLine, "/proc/[0-9]+/(mem|maps|smaps)")

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="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)/proc/[0-9]+/(mem|maps|smaps)</field>    <description>Another process's /proc memory named on a Linux command line</description>    <mitre>      <id>T1003.007</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":"sysmon"}), 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: sysmon / linux
Level: medium
Category: credential_dump
Sigma status: experimental
Backends: 2 of 4 rendered
Updated: 30 Aug 2026
Rule ID: f551e20a-6713-4d62-b628-369668c57f83

ATT&CKT1003.007

T1003.007Proc Filesystem

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.

Lessoncredential dump

credential dumpAI draft — unreviewed

01 · What this rule detects

AN1631 describes multi-step access to another process's memory through the /proc filesystem to scrape credential material. This rule takes the cheapest observable form of that: a process launched with /proc/<pid>/mem, /proc/<pid>/maps or /proc/<pid>/smaps somewhere in its arguments. A hit is a command line that named another process's memory interface — not proof anything was read, and not proof the reader was hostile. The credential case and the debugging case are the same string.

02 · Telemetry you need

product: linux, service: sysmon, copied verbatim from AN1631. Sysmon for Linux is a separate agent that no distribution installs by default; a host running stock auditd alone produces nothing this rule can read.
The brief's three auditd sources were all rejected. File watches are inode-based and /proc's per-PID entries die with every process, so there is no stable path to watch; the syscall-filter form (-F dir=/proc -F perm=r) records every ps, top and monitoring poll on the host; and the ptrace/process_vm_readv leg carries no path at all, so it cannot say whose memory was read.
Two of four backends refuse this rule: Sentinel has no table modelled for the mandated logsource, and Elastic ES|QL rejects the |re modifier. Those renderings have to be written by hand.

03 · How the logic works

One selection, one field: CommandLine|re: '/proc/[0-9]+/(mem|maps|smaps)'. The match sits on CommandLine rather than Image deliberately. The published tooling for this technique is shell and Python — mimipenguin ships as both, and the technique description is itself a grep-and-cut one-liner — so on a process-creation feed the executable is /bin/bash or /usr/bin/python3. A selector keyed on a tool name would validate clean and never fire. MITRE supplies the AccessedFilePath knob. Restricting it to a numeric PID is the pipeline's own choice, and it is the load-bearing part: /proc/self/mem and /proc/self/maps are self-inspection performed constantly by language runtimes, container sandboxes and CI suites, while the analytic is about one process reading a different process's address space. That gate is also why the regex cannot be softened to |contains: '/proc/' to please Elastic. smaps is an authored widening past AN1631, which names only mem and maps. It is worth reconsidering: smaps is a memory-accounting view with no credential material in it, and it is where most of this rule's noise comes from. Two blind spots. A compiled implant that builds the path with sprintf and calls open() puts nothing in argv. And shell redirection — while read l < /proc/1234/maps — execs nothing at all, so there is no EventID 1 record to match. That second one needs no tooling whatsoever.

04 · Common false positives

Diagnostic and support-bundle collection is the highest-volume source by a wide margin. sosreport, vendor support scripts and container-runtime debug bundles walk the whole process table running cat or awk over maps and smaps, so one collection run produces a burst of matches per host. That is why the level is medium.
Then: hand-run leak hunting (grep heap /proc/12345/maps), separated from the attack only by the account; shell-wrapper monitoring such as smem and ps_mem, polling smaps by numeric PID; and profiling helpers reading a target's maps before capturing a dump.

05 · Detection maturity

tier_1: . Machine-derived from a MITRE scaffold containing no query logic, and never executed against a log line. Nothing here has been shown to fire, and the volume estimates above are reasoning, not measurement.
tier_2: is running it read-only, ranking hits by parent command and account, and deciding from real data whether `smaps` earns its place.
tier_3: ** is pairing it with a ptrace-syscall signal so the alert means memory was read, not merely named.

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

Narrow the regex to /proc/[0-9]+/(mem|maps). That drops the highest-rate
Exclude sosreport and support-bundle tooling by parent process, not by
MITRE's UserContext knob is unapplied here, because root reading /proc is
MITRE's TimeWindow knob wants this correlated with process creation or

Declared by the author

Diagnostic and support-bundle collection that walks the whole process table. sosreport, vendor support scripts and container-runtime debug bundles run cat or awk over /proc/<pid>/maps and /proc/<pid>/smaps in a loop, so a single collection run produces a burst of matches on every host it touches. This is the highest-volume source this rule has and is why the level is medium.
Memory-accounting and leak-hunting work done by hand — grep heap /proc/12345/maps, awk over /proc/<pid>/smaps to total PSS for a leaking daemon, or dd if=/proc/<pid>/mem while capturing a region for analysis. The command is identical to the one this rule is written for and only the operator account separates them.
Monitoring and capacity tooling shipped as shell wrappers rather than compiled agents, such as smem, ps_mem and per-container memory reporters, which read /proc/<pid>/smaps by numeric PID on every polling interval under a service account.
Crash and profiling helpers that read a target's maps before capturing a dump, including core-dump pipe handlers, gcore-style wrapper scripts and profiler launch scripts that resolve a PID and then inspect its address space.

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 T1003.007, evaluated against their — events.

Share this rule

/u/siemphony/f551e20a-6713-4d62-b628-369668c57f83

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.

Another process's /proc memory named on a Linux command line

The detection

detection.yml

Splunk · SPL

Wazuh · XML rule

Sentinel · KQL

Elastic · ES|QL

Community

Verdicts from engineers who deployed it