Ptrace attach or cross-process memory write on Linux

Siemphony@siemphonylowT1055.008unverified

Matches the two syscalls that carry ptrace-based process injection's actual memory-write primitives: `ptrace`, which covers both the `PTRACE_ATTACH`/ `PTRACE_SEIZE` step and the `PTRACE_POKETEXT`/`PTRACE_POKEDATA`/`PTRACE_SETREGS` calls AN0579 names, and `process_vm_writev`, the newer cross-process memory API that debuggers and injection tooling increasingly use instead of poke-based ptrace because it moves more data per call. `mmap`, the third syscall the brief's logsource note lists, is deliberately left out: every process calls it continually as part of ordinary memory allocation and dynamic linking, so gating on it would make the selection effectively always-true rather than a signal. What this cannot express: AN0579's `TargetProcessNameFilter`, `UserContextMismatch` and `ProcessRelationshipConstraint` knobs all require knowing which process was ptraced and comparing its identity, UID or parent relationship to the tracer's — that identity lives in the syscall's `a1` argument (the target PID) and would need a join against a process table to resolve, which a single auditd SYSCALL record cannot supply. The specific ptrace request (`PTRACE_POKEDATA` vs. read-only `PTRACE_PEEKTEXT` vs. plain `PTRACE_ATTACH`) sits in `a0` as a raw integer that this rule does not decode, so a benign `strace -p` attach and an actual poke-based injection produce the same match. MITRE's `TimeWindowBetweenPtraceAndMemoryWrite` knob is a two-event correlation lib/sigma has no timeframe construct for. The brief's other two logsources are not attempted: `linux:osquery` has no standardised Sigma field vocabulary in this corpus (the same reason `macos:unifiedlog` was skipped for T1027.015's AN0784 — inventing field names would render in four backends and match nothing), and the `process_creation` execve logsource would only see the debugger binary being launched, which is a strictly weaker signal than the syscalls it goes on to make. Prerequisite: neither syscall is audited by default on any major distribution. This rule returns zero rows — meaning blind, not quiet — until a rule such as `-a always,exit -F arch=b64 -S ptrace -S process_vm_writev -k ptrace_inject` is loaded. Second prerequisite specific to the `syscall` field: raw, uninterpreted auditd output records `syscall=` as the architecture-dependent kernel syscall number (`ptrace` is 101 and `process_vm_writev` is 311 on x86_64; both differ on arm64), not the name string this selection matches against. Name resolution is not universal — Elastic's Auditbeat resolves it by default, but a plain-text `audit.log` tail, `ausearch` without `-i`, and Wazuh's default auditd field extraction all pass the number through unresolved, so on those collectors this selection never fires until an interpreting layer (`ausearch -i`, `laurel`, or an equivalent enrichment pipeline) sits in front of it. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0203, 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="SYSCALL" AND syscall="ptrace") OR (type="SYSCALL" AND syscall="process_vm_writev"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "syscall" AND TO_LOWER(syscall) == "ptrace") OR (TO_LOWER(type) == "syscall" AND TO_LOWER(syscall) == "process_vm_writev"))

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)^SYSCALL$</field>    <field name="syscall" type="pcre2">(?i)^ptrace$</field>    <description>Ptrace attach or cross-process memory write on Linux (1/2)</description>    <mitre>      <id>T1055.008</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)^SYSCALL$</field>    <field name="syscall" type="pcre2">(?i)^process_vm_writev$</field>    <description>Ptrace attach or cross-process memory write on Linux (2/2)</description>    <mitre>      <id>T1055.008</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: process_injection
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: a0f849a7-c77f-4da5-a26b-0e7e3a06afa3

ATT&CKT1055.008

T1055.008Ptrace System Calls

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 watches for two Linux syscalls that carry the actual mechanics of ptrace-based process injection: ptrace itself, and process_vm_writev, the newer cross-process memory API that modern debuggers increasingly prefer because it moves more data per call than the classic PTRACE_POKETEXT/PTRACE_POKEDATA path. The condition is 1 of selection* — either syscall alone is enough to match. MITRE's AN0579 describes this as correlating ptrace attach, memory pokes and register manipulation on a target process "not normally debugged by the originator." This rule catches only the raw syscalls, not that correlation — see below.

02 · Telemetry you need

type: SYSCALL records from logsource: linux / auditd. Neither syscall is audited by default on any major distribution; without a loaded audit rule such as -a always,exit -F arch=b64 -S ptrace -S process_vm_writev -k ptrace_inject, this rule returns zero rows — meaning blind, not quiet. There is a second, sharper prerequisite specific to the syscall field itself: raw auditd records that field as the architecture-dependent kernel syscall number (101 for ptrace, 311 for process_vm_writev on x86_64, different on arm64), not the name string this selection matches against. Name resolution isn't universal — Elastic's Auditbeat resolves it by default, but a plain-text audit.log tail, ausearch without -i, and Wazuh's default field extraction all pass the number through unresolved, so on those collectors the rule silently never fires until an interpreting layer (ausearch -i, laurel, or equivalent) sits in front of it.

03 · How the logic works

Two independent selections, selection_ptrace and selection_memwrite, each gate on type: SYSCALL plus a literal syscall name; the condition ORs them. mmap, the third syscall the brief's logsource note lists, is deliberately excluded — every process calls it continually for ordinary memory allocation and dynamic linking, so including it would make the selection effectively always-true rather than a signal. Neither selection decodes syscall arguments: the target PID lives in a1 and the specific ptrace request (PTRACE_POKEDATA vs. read-only PTRACE_PEEKTEXT vs. plain PTRACE_ATTACH) lives in a0, both raw integers this rule leaves untouched.

04 · Common false positives

The rule's own false positives are specific: interactive debugging with gdb, strace, ltrace or valgrind on a dev/build host produces the identical syscalls, since modern gdb itself uses process_vm_writev. gVisor-style sandboxed runtimes (runsc) intercept every syscall of every contained process via ptrace, so one host running that runtime alone can generate a match per process, unrelated to injection. systemd-coredump and similar collectors ptrace-attach to any crashing process to capture its state, firing on every ordinary application crash.

05 · Detection maturity

tier_1: This rule has never been run against a log line and sits at the lowest DeBMM maturity tier by definition — UNVERIFIED, machine-derived from MITRE's analytic prose with no execution evidence behind it. Before it earns any higher tier it needs to be loaded against real auditd output on a host with the ptrace/process_vm_writev audit rule active, confirmed to fire on an actual injection tool, and tuned against the false positives above using real telemetry, not assumption.

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

Because a single auditd SYSCALL record has no process-identity join, MITRE's TargetProcessNameFilter, UserContextMismatch, and ProcessRelationshipConstraint knobs — all of which require knowing which process was ptraced and comparing its UID or parent relationship to the tracer's — cannot be expressed here without external enrichment (e.g., resolving a1 against a process table downstream). MITRE's TimeWindowBetweenPtraceAndMemoryWrite correlation knob has no equivalent either; lib/sigma has no timeframe construct. In practice, tuning this rule means pairing it with an EDR or eBPF layer that can resolve target PID and ptrace-request code, then reserving this Sigma rule as the first-pass, low-confidence trigger.

Declared by the author

Interactive debugging and profiling on development or build hosts: gdb, strace, ltrace and valgrind all attach via ptrace, and modern gdb uses process_vm_writev to poke memory, so a developer debugging a crash produces the same syscalls as the technique.
Sandboxed and gVisor-style container runtimes (runsc) that intercept every syscall of every process they run via ptrace, meaning one or more matches per contained process on any host using that runtime, not just at injection time.
Crash and coredump handling: systemd-coredump and similar collectors attach via ptrace to a crashing process to capture its state before it exits, which fires on every application crash on the host.

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

Share this rule

/u/siemphony/a0f849a7-c77f-4da5-a26b-0e7e3a06afa3

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.

Ptrace attach or cross-process memory write on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it