Linux Process Injection: Techniques & Defense

Understanding Linux Process Injection - How Attackers Hide Inside Processes ​

Process injection is when an attacker inserts malicious code into a running process to evade detection, persist longer, or escalate privileges. Instead of running standalone malware that’s easy to spot, attackers piggyback on trusted processes like sshd, bash, or system daemons to blend in with normal system activity. This makes detection harder and gives the attacker a better chance to stay inside the target environment.

In this thread you’ll get a practical, lab-friendly overview of common Linux injection techniques, how they work, short code examples to try safely in a controlled environment, and concrete defenses you can use to detect and stop them.

---

Why Attackers Use Process Injection​

Attackers rely on process injection because it offers big advantages:

• Stealth - Security tools often treat the host process as legitimate, so malicious code hides in plain sight.
• Persistence - Injected code can survive as long as the host process runs.
• Privilege abuse - The injected code runs with whatever permissions the host process has.
• Monitoring bypass - Simple checks like ps or top don’t reveal the injected payload.

Because of these benefits, injection techniques are common in modern malware and post-exploitation frameworks.

---

Common Linux Injection Techniques (Practical & Explained) ​

Below are the injection methods you’ll most commonly see in real attacks, with short explanations and safe-to-run examples for lab practice.

ptrace Injection​

The ptrace syscall (used by debuggers like gdb) lets one process control another and read/modify its memory and registers. Attackers abuse ptrace to write payloads into another process’s memory and then change instruction pointers to execute that code.

Lab idea: implement a tiny ptrace demo in C that attaches to a child process and reads memory. Only experiment inside isolated VMs.

LD_PRELOAD Hijacking​

Setting the LD_PRELOAD environment variable forces the dynamic loader to load a specific shared library before others. An attacker can supply a malicious .so that overrides library functions (e.g., read, open, or execve) to intercept or change behavior.

Minimal LD_PRELOAD example (C) - safe for labs:

// override.c - compile with: gcc -shared -fPIC -o override.so override.c
#include <stdio.h>
#include <dlfcn.h>
#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count) {
    static ssize_t (*orig_read)(int, void*, size_t) = NULL;
    if (!orig_read) orig_read = dlsym(RTLD_NEXT, "read");
    ssize_t ret = orig_read(fd, buf, count);
    // For demo: print a notice (don't run on production)
    write(1, "LD_PRELOAD read intercepted\n", 29);
    return ret;
}

Run a test binary with LD_PRELOAD=./override.so ./target_binary in your lab.

/proc//mem Injection​

Linux exposes a process’s memory at /proc/<pid>/mem. With proper permissions (or via escalated privileges), an attacker can open that file and overwrite parts of a process’s memory directly. This technique is low-level and noisy but effective when combined with other evasion steps.

Process Hollowing (Memory Replacement)​

Process hollowing means creating or reusing a legitimate process and replacing its memory image with malicious code while keeping the same PID and name. Tools or scripts perform memory unmapping and then write a new executable image into the process space. The running process appears legitimate while executing attacker code.

Signals & Handler-Based Injection​

Attackers can use signals (like SIGTRAP or SIGSEGV) combined with custom handlers to divert execution flow to malicious payloads. This can be used as part of an exploit chain where a fault triggers a controlled handler that loads or runs malicious bytes.

---

Detection & Defense Strategies (Practical Steps) ​

Protecting systems against process injection requires multiple layers of monitoring and restriction.

Use Mandatory Access Controls​

Enable SELinux or AppArmor and configure policies to restrict which processes can open other processes’ memory or call sensitive syscalls. Proper policies significantly limit the attack surface.

Apply Seccomp Filters​

Use seccomp to limit allowed syscalls for high-risk processes. For example, block or restrict ptrace, process_vm_writev, or other syscalls that enable cross-process memory writes.

Monitor /proc Access​

Alert on unusual access patterns to /proc/<pid>/mem or mass reads/writes to /proc. Scripts and intrusion detection rules can flag processes that open many /proc/*/mem files.

Check Loaded Libraries & Environment​

Detect unexpected LD_PRELOAD usage and check for suspicious libraries loaded by trusted processes. Regularly inspect /proc/<pid>/maps and /proc/<pid>/auxv for anomalies.

Behavioral Detection​

Look for suspicious process interactions: a user-level shell attaching to sshd, parent-child relationships that don’t match expected behavior, or processes suddenly allocating and executing writable memory (mmap with PROT_EXEC and PROT_WRITE).

Runtime Integrity​

Use integrity tools that watch memory regions and code pages for unexpected changes. Employing kernel-level monitoring agents helps detect memory tampering earlier than userland checks.

---

Quick Detection Rules (Example Snort/Suricata Ideas)​

• Alert on any user process calling ptrace(PTRACE_ATTACH) on system daemons.
• Flag processes that set LD_PRELOAD in production daemons.
• Alert on unexpected writes to /proc/*/mem or calls to process_vm_writev from non-admin processes.

Lab Tips - How to Practice Safely ​

• Always use isolated VMs or containers with snapshots.
• Keep the lab off your production network. Use NAT or internal-only networks.
• Run demonstrations as non-root until you deliberately escalate in a controlled way.
• Log and document every step - it’s key for learning and for building detection rules later.

Key Takeaways ​

• Process injection is a widely used tactic because it hides malicious activity inside trusted processes.
• Common Linux techniques include ptrace, LD_PRELOAD, /proc memory writes, process hollowing, and signal-based tricks.
• Effective defense combines policy enforcement (SELinux/AppArmor), syscall restrictions (seccomp), and behavioral monitoring.
• Practice in the lab and build detection rules based on real behaviors, not just signatures.