# linux-process-injection

Use this skill when the user asks about Linux process injection, using ptrace for injection, LD_PRELOAD injection, writing to procfs, remote access via process_vm_writev, seccomp notify injection, PTRACE_POKETEXT, GOT overwrite, remote thread creation on Linux, or bypassing Yama ptrace restrictions.

- **Kind:** skill
- **Source:** https://github.com/SpecterOps/skills
- **Page:** https://forefy.com/skills/b1861175-bba9-4ab3-9b33-87b06f818937
- **API (JSON + files):** https://forefy.com/api/asr/b1861175-bba9-4ab3-9b33-87b06f818937

---

## SKILL.md

---
name: linux-process-injection
description: Use this skill when the user asks about Linux process injection, using ptrace for injection, LD_PRELOAD injection, writing to procfs, remote access via process_vm_writev, seccomp notify injection, PTRACE_POKETEXT, GOT overwrite, remote thread creation on Linux, or bypassing Yama ptrace restrictions.
metadata:
  author: "Outflank"
---

# Linux Process Injection

## Overview

Linux has no direct equivalents of Windows APIs like `VirtualAllocEx`, `VirtualProtectEx`, or `CreateRemoteThread`. Allocation, permission changes, and thread creation must be induced inside the target process rather than performed remotely. All live-process injection methods are gated by the ptrace access-check algorithm, which evaluates credentials, dumpability, capabilities, and LSM policy.

There are two primary injection models:

- Live process: modify an existing image with `ptrace`, `/proc/<pid>/mem`, or `process_vm_writev`. Use the model `overwrite -> execute -> recover`.
- Controlled launch or exec: arrange loading into a new image with `LD_PRELOAD` or seccomp user notification.

Consult the [capability matrix](./references/capability-matrix.md) for feasibility checks.

## Workflow

1. Classify the lifecycle. Decide whether the target is already running or launched under injector control.
2. Profile the target. Identify architecture, ABI, mappings, RELRO, thread state, loader/libc, kernel features, and mitigations.
3. Validate prerequisites. Check ptrace and LSM/Yama policy, loader behavior, or parent-child seccomp support as applicable.
4. Separate staging from execution. Identify both where bytes or objects are placed and how control reaches them.

## Method Rules

- Use `ptrace` for register control, thread stops, or the broadest live-process control.
- Treat `/proc/<pid>/mem` writes through non-writable mappings as kernel-policy dependent.
- Use `process_vm_writev` only for writable memory.
- Treat `LD_PRELOAD` as controlled dynamic-loader behavior; static binaries, secure-execution mode, and environment sanitization can block it.
- Treat seccomp notification as syscall mediation, not remote memory or register control. The seccomp-notify PoC installs a listener before `execve` and substitutes a staged shared-object FD for a selected loader `openat` call.

## References

- [Capability matrix](./references/capability-matrix.md)
- [The Definitive Guide to Linux Process Injection](https://www.akamai.com/blog/security-research/the-definitive-guide-to-linux-process-injection)
- [akamai/Linux-Process-Injection](https://github.com/akamai/Linux-Process-Injection)
- [Seccomp Notify Injection](https://www.outflank.nl/blog/2025/12/09/seccomp-notify-injection/)
- [outflanknl/seccomp-notify-injection](https://github.com/outflanknl/seccomp-notify-injection)

## agents

```

```

## agents/openai.yaml

```yaml
interface:
  display_name: "Linux Process Injection"
  short_description: "Implement or assess feasibility of process injection on Linux."
  icon_small: ./assets/icon.svg
  icon_large: ./assets/icon.png
  brand_color: '#00B36B'
  default_prompt: "Use $linux-process-injection to answer Linux process injection implementation questions."

policy:
  allow_implicit_invocation: true
```

## assets

```

```

## assets/icon.png

```

```

## assets/icon.svg

```

```

## references

```

```

## references/capability-matrix.md

# Linux Process Injection Capability Matrix

Use this file for feasibility checks. Live-process methods modify an existing image; launch-time methods affect a new image during controlled `execve`.

## Overview

| Technique                 | Scope                         | Provides                                       | Key constraints                                                                                              |
| ------------------------- | ----------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `ptrace`                  | Existing image                | Memory and register access; per-thread control | `PTRACE_MODE_ATTACH_REALCREDS`; dumpability, capabilities, LSM/Yama; usually requires ptrace-stops           |
| `/proc/<pid>/mem`         | Existing image                | Remote memory access                           | Open uses `PTRACE_MODE_ATTACH_FSCREDS`; no implicit stop; non-writable VMA access depends on proc-mem policy |
| `process_vm_writev`       | Existing image                | Writes to writable remote memory               | `PTRACE_MODE_ATTACH_REALCREDS`; no register or stop control; partial and non-atomic writes                   |
| `LD_PRELOAD`              | Controlled launch or `execve` | Loader maps a shared object                    | Requires a compatible dynamic loader; static targets, secure execution, or sanitization can block it         |
| Seccomp user notification | Supervised launch             | Mediates selected syscalls and can inject FDs  | Child must install a listener before `execve`; requires supported seccomp operations and controlled launch   |

## Live-Process Primitive Coverage

| Primitive                      | `ptrace`  | `/proc/<pid>/mem`                           | `process_vm_writev`                |
| ------------------------------ | --------- | ------------------------------------------- | ---------------------------------- |
| Write writable memory          | Yes       | Yes                                         | Yes                                |
| Write RX memory                | Generally | Policy-dependent                            | No                                 |
| Modify saved PC/IP             | Yes       | No                                          | No                                 |
| Overwrite current instruction  | Yes       | Policy-dependent                            | Only in writable executable memory |
| Stack or ROP hijack            | Yes       | Yes                                         | Yes                                |
| GOT or function-pointer hijack | Yes       | Yes if writable; otherwise policy-dependent | Only if writable                   |
| Stop thread or write registers | Yes       | No                                          | No                                 |

A `Yes` means the primitive is available, not that staging, synchronization, execution transfer, or recovery is solved.

## Launch-Time Comparison

| Property          | Traditional `LD_PRELOAD`                                                 | seccomp-notify                                                                                           |
| ----------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| Setup             | Supply a shared object through a controlled preload request              | Launch a child, install a listener, pass it to the supervisor, then `execve`                             |
| Trigger           | Loader maps and initializes the object                                   | Loader calls filtered `openat`/`openat2`; supervisor supplies an FD with `SECCOMP_IOCTL_NOTIF_ADDFD`     |
| Main requirements | Dynamic target, compatible ABI and loader, honored preload configuration | Controlled launch, dynamic target for this PoC, filter-install permission, supported notification ioctls |
| Kernel dependency | No dedicated injection API                                               | User notification: 5.0; `ADDFD`: 5.9; `SECCOMP_ADDFD_FLAG_SEND`: 5.14                                    |
| Privilege effect  | Runs in the launched program's resulting security context                | Does not cross the target's UID, namespace, or LSM boundaries                                            |
| Cleanup           | Remove preload configuration and manage library side effects             | Manage staged FDs and the seccomp filter that survives `execve`                                          |

The PoC's `memfd`, loader-open substitution, and IFUNC resolver are implementation choices, not universal seccomp-notify requirements.

## Key Caveats

- All live methods use the ptrace access algorithm. `ptrace` and `process_vm_writev` use real credentials; `/proc/<pid>/mem` uses filesystem credentials.
- Yama may add restrictions: scope `0` adds none, `1` usually requires ancestry or `PR_SET_PTRACER`, `2` requires `CAP_SYS_PTRACE`, and `3` denies attach-gated access.
- Full RELRO blocks writable-only GOT modification. `ptrace` can generally write ordinary private mappings despite page protections; `/proc/<pid>/mem` depends on proc-mem override policy.
- Linux has no direct equivalents of `VirtualAllocEx`, `VirtualProtectEx`, or `CreateRemoteThread`; induce allocation, permission changes, or thread creation inside the target.
- ASLR, PIE, CET/shadow stacks, CFI, PAC, calling conventions, syscall restart behavior, and instruction-cache rules are platform-specific.
- Installing a seccomp listener without `CAP_SYS_ADMIN` in the relevant user namespace normally requires `PR_SET_NO_NEW_PRIVS`. Validate notification IDs before acting on target state.