Process opens its own /proc/self/status, a common debugger-presence check

Siemphony@siemphonylowT1622unverified

AN1046 asks for access to `/proc/self/status` with attention to the `TracerPID` field, the standard Linux way of asking "is something tracing me" without calling `ptrace()` directly (a non-zero `TracerPID` means a debugger or strace-like tool is attached). This rule matches an auditd `PATH` record naming that exact path — the literal string a process passes to `open`/`openat` when it queries itself this way, since `/proc/self` is a kernel-resolved symlink to the caller's own PID and so appears verbatim in the syscall argument rather than as a numeric PID. It does not attempt to read `TracerPID` out of the file's contents: auditd's PATH record carries only the name that was opened, never the bytes subsequently read, so this rule can only place "something asked", not "and the answer was non-zero" — a benign self-check and a successful evasion look identical on this log source. The Windows leg AN1045 is not attempted at all: its only log source is Sysmon EventID 1 (process_creation), a launch record with no view into a running process's own calls, and `IsDebuggerPresent()`, `NtQueryInformationProcess()`, the PEB `BeingDebugged` flag and repeated `OutputDebugStringW()` calls MITRE describes are all in-process API calls that create no process and leave nothing on this channel — a selector built from those names would validate clean, render in four backends and never fire once, on any host, against any sample. The macOS leg AN1047 (`ptrace` with `PTRACE_TRACEME`) is not attempted either: its log source is `macos:unifiedlog`, which has no standardised Sigma field vocabulary anywhere in this corpus, the same blocker recorded against it for other techniques. A PATH record for this path requires auditd to already be watching the syscall that opened it; a static `-w` watch cannot target `/proc/self/status` by inode the way it can a real file, since `self` is a different symlink target for every calling process, so this needs a broad `-S openat` (or `open`) audit rule with `-F success=1` rather than a path watch. That is far higher-volume than a watch and is not present in any mainstream default auditd configuration; without it, an empty result means the telemetry is off, not that nothing checked for a debugger. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0371, 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="/proc/self/status")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(type) == "path" AND TO_LOWER(name) == "/proc/self/status")

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/self/status$</field>    <description>Process opens its own /proc/self/status, a common debugger-presence check</description>    <mitre>      <id>T1622</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: discovery_recon
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 2268b629-df9b-4b6a-9ff4-9a7e805ef260

ATT&CKT1622

T1622Debugger Evasion

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.

Lessondiscovery recon

discovery reconAI draft — unreviewed

01 · What this rule detects

This rule flags a process opening /proc/self/status — the standard Linux way of checking whether something is tracing you (via the file's TracerPID field) without calling ptrace() directly. It implements one of AN1046's three legs; the Windows and macOS legs are not attempted, and the reasons matter for reading what a hit actually means.

02 · Telemetry you need

An auditd PATH record. As with any broad self-check like this, it depends on a -S openat (or open) audit rule with -F success=1 already being active — a static -w watch can't target /proc/self/status by inode, since self resolves to a different target for every calling process. That broad syscall watch is far higher-volume than a path watch and is not present in any mainstream default auditd configuration. An empty result means the telemetry is off, not that nothing checked for a debugger.

03 · How the logic works

Two selections, ANDed. selection_path_record gates on type: 'PATH'. selection_target matches name: '/proc/self/status' — the literal string a process passes to open/openat when it makes this check, since /proc/self is a kernel-resolved symlink to the caller's own PID and appears verbatim in the syscall argument rather than as a numeric PID. That is the entire rule; there is no second condition narrowing it further. The rule deliberately does not attempt to read the TracerPID value out of the file's contents — auditd's PATH record carries only the name that was opened, never the bytes subsequently read. That means it can only ever record "something asked", not "and the answer was non-zero": a benign self-check and a successful evasion look identical on this log source, and no amount of tuning within this event type can separate them. The Windows leg, AN1045, is not attempted at all, and it's worth being explicit about why: its only log source is Sysmon EventID 1 (process_creation), a launch record. IsDebuggerPresent(), NtQueryInformationProcess(), the PEB BeingDebugged flag, and repeated OutputDebugStringW() calls — the techniques MITRE describes — are all in-process API calls that create no process and leave nothing on that channel. A selector built from those names would validate clean, render in four backends, and never fire once, on any host, against any sample — the exact silent-failure shape this corpus's authoring rules warn against. The macOS leg AN1047 (ptrace with PTRACE_TRACEME) is skipped because its log source, macos:unifiedlog, has no standardised Sigma field vocabulary anywhere in this corpus.

04 · Common false positives

level is low because the top false positives here are routine and high-volume, not edge cases. Self-monitoring and health-check libraries that report a process's own memory or thread usage by reading /proc/self/status directly — Node's pidusage-style modules, Java and Go diagnostic agents, Prometheus-style self-metrics exporters — do this on a fixed polling interval and will be the dominant match on any host running one. Process supervisors and service managers (systemd units, runit, container-runtime health probes) read their own status file to enforce resource limits as routine supervision. Language runtimes and garbage collectors under memory pressure consult the same file for RSS/VmSize before shrinking a heap, which fires under normal load rather than anything unusual.

05 · Detection maturity

tier_1: Unverified and at the lowest DeBMM tier. This rule has never been run against a log line; it needs execution against real auditd output — ideally including both a known-benign monitoring agent and a controlled anti-debug sample — before its noise profile or its ability to fire at all can be trusted.

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

This is a poor rule to run broadly without a baseline: on most Linux hosts with any monitoring agent, GC-heavy runtime, or systemd resource limits in play, the routine matches will vastly outnumber anything worth an analyst's attention. Baseline per-host or per-process-name polling frequency first, then flag deviations (a process reading this file once, unusually, rather than on a steady interval) rather than treating every match as equal. Correlating with a subsequent ptrace-related syscall from the same PID would sharpen this considerably but is outside what this rule alone does.

Declared by the author

Self-monitoring and health-check libraries that report a process's own memory or thread usage by reading /proc/self/status directly — memory-usage helpers such as pidusage-style Node modules, Java and Go diagnostic agents, and Prometheus-style self-metrics exporters all do this on a fixed polling interval, and on a host running one this is by far the highest-volume match.
Process supervisors and service managers (systemd units, runit, container-runtime health probes) that read their own /proc/self/status to enforce a memory or resource limit as part of routine supervision, not inspection of an external target.
Language runtimes and garbage collectors under memory pressure that consult their own /proc/self/status for RSS or VmSize before deciding to shrink a heap or log a warning, which fires under normal load on long-running services rather than in response to anything unusual.

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

Share this rule

/u/siemphony/2268b629-df9b-4b6a-9ff4-9a7e805ef260

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.

Process opens its own /proc/self/status, a common debugger-presence check

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it