Published on

💀 Weaponizing the Kernel’s Heart: Abusing Linux SysRq for Evil

Authors

👋 Intro

SysRq is one of those features you rarely think about — until it crashes your box.

Originally designed as a panic button for Linux admins, the magic SysRq key gives direct low-level access to the kernel, even when everything else is frozen. But what happens when attackers get root access and start scripting these commands?

In this post, I’ll walk you through how adversaries can weaponize SysRq to crash systems, wipe memory, kill user processes, bypass EDRs, and generally make your life miserable — all while staying under the radar.

🔍 What is SysRq?

SysRq (System Request) is a kernel-level interface that allows privileged users to send specific commands to the kernel using:

  • A keyboard combo: Alt + SysRq + <command>
  • A command-line write:
echo <command> > /proc/sysrq-trigger

These commands bypass user-space, letting you:

  • Reboot or power off instantly
  • Kill all processes
  • Dump memory
  • Remount disks
  • Trigger kernel panics

💣 Weaponizing SysRq: Attacker Use Cases

Once an attacker gains root on a Linux system, they can unleash SysRq’s power to silently disrupt, evade, or cover their tracks.

🔥 1. Crash the System on Demand

Force a hard reboot (no clean shutdown):

echo b > /proc/sysrq-trigger

Power off the machine instantly:

echo o > /proc/sysrq-trigger

💥 Result: No logs are flushed. No alerts go out. Just instant chaos.

🧹 2. Wipe Volatile Evidence (Anti-Forensics)

Chain SysRq commands to sync disk, remount as read-only, and reboot — a classic memory wipe:

echo s > /proc/sysrq-trigger   # Sync filesystem
echo u > /proc/sysrq-trigger   # Remount read-only
echo b > /proc/sysrq-trigger   # Reboot immediately

Perfect for erasing traces of an implant, shellcode loader, or EDR tampering before a memory dump can be taken.

💀 3. Kill All Processes on Current TTY

echo k > /proc/sysrq-trigger

Silently wipes out processes — including monitoring agents, terminal sessions, or forensic tools running interactively.

👻 4. Bypass EDR and Logging

SysRq lives in the kernel. That means:

  • No bash history
  • No logging in syslog or journalctl
  • No visibility to most userland EDR tools

Red teamers can use this to mask activity or hide cleanup actions.

🧠 5. Maintain Persistence (Or Enable It)

Enable SysRq permanently:

echo 1 > /proc/sys/kernel/sysrq 
echo "kernel.sysrq = 1" >> /etc/sysctl.conf

This ensures the interface remains accessible across reboots — potentially useful for persistence or scheduled disruption.

🛡️ Defensive Mitigations

DefenseCommand or Tip
Disable SysRq at runtimeecho 0 > /proc/sys/kernel/sysrq
Make it permanentAdd kernel.sysrq = 0 to /etc/sysctl.conf and reload
Restrict accessUse AppArmor/SELinux to protect /proc/sysrq-trigger
Hide sensitive procfsUse mount -o hidepid=2 /proc for user isolation
Monitor for abuseAudit echo > /proc/sysrq-trigger via auditd or eBPF

🚀 Red Team Use Cases

If you're testing endpoint visibility or practicing post-exploitation, SysRq can be useful for:

  • Triggering system crashes to simulate destructive malware
  • Evading forensic memory captures
  • Killing defensive agents without shell interaction
  • Erasing shellcode or indicators in RAM before reboot

Just don’t forget: this stuff is volatile and destructive.

🧾 Summary

SysRq is a trusted tool — but also a silent killer. It bypasses userland defenses, avoids logging, and gives attackers control over the deepest layers of the OS. If you’re a defender, lock it down. If you’re on offense, know when and how to use it for chaos or cover.

💬 Got cool SysRq tricks, kernel-mode mischief, or detection bypasses? Let’s connect — I’m always down to swap notes.

Discuss on Twitter • View on GitHub