Cybersecurity Research: Advanced Topics¶

Table of Contents¶

1. Rootkit Attacks - Real Examples¶

What is a Rootkit?¶

A rootkit is malware designed to hide its presence by intercepting and modifying system calls. Think of it as a dishonest accountant who alters the books - when you ask “show me all files,” the rootkit filters the output to hide malicious files and processes.

Famous Rootkit Attacks¶

Sony BMG Rootkit (2005) - The Scandal That Shocked the World¶

What happened: - Sony BMG embedded rootkits on over 22 million music CDs as copy protection (DRM) - When users played these CDs on their computers, the rootkit silently installed itself - The rootkit hid any file starting with “sys” from users

The Rootkit’s Role: 1. Concealment: Made the DRM software invisible to users and antivirus programs 2. Security Risk: Created vulnerabilities that other malware could exploit 3. System Instability: Slowed down computers and caused crashes 4. Privacy Violation: Sent user listening habits and IP addresses back to Sony without consent

Discovery & Consequences: - Security researcher Mark Russinovich discovered it on October 31, 2005 using his rootkit detection tool (RootkitRevealer) - Sony President’s infamous quote: “Most people don’t even know what a rootkit is, so why should they care about it?” - Result: Class-action lawsuits, FTC investigation, CD recalls, and a massive PR disaster - Security researchers criticized antivirus vendors for failing to detect it

Key Lesson: This incident brought rootkits into public consciousness and showed that even “legitimate” companies could introduce dangerous malware.

Stuxnet (2010) - The Cyber Weapon¶

What happened: - Discovered in 2010, believed to be developed by the US and Israel - Targeted Iran’s uranium enrichment facility at Natanz nuclear plant - Infected over 200,000 computers and destroyed approximately 1,000 centrifuges

The Rootkit’s Role: 1. Stealth Operations: The rootkit component hid all files and processes from detection 2. Deception: Faked normal sensor readings so operators saw no problems 3. Persistence: Remained undetected for months while sabotaging centrifuges 4. Protection: Prevented antivirus software from detecting the worm

Technical Details: - Kernel-mode rootkit that modified Windows kernel functions - Targeted Siemens Step7 software controlling PLCs (Programmable Logic Controllers) - Altered centrifuge speeds to tear them apart while displaying normal readings - Used multiple zero-day vulnerabilities and sophisticated propagation methods

Significance: - First known cyberweapon to cause physical damage - Demonstrated that rootkits could be used in nation-state cyber warfare - Changed the landscape of critical infrastructure security

Flame / Flamer (2012) - The Espionage Tool¶

What happened: - Discovered in 2012, targeting Middle Eastern governments - Used for espionage in Iran, Lebanon, Syria, Sudan, and Israel - Believed to be created by the same nation-state actors behind Stuxnet

The Rootkit’s Role: 1. Comprehensive Spying: - Turned on microphones to record conversations - Activated webcams to take photos - Logged keystrokes to steal passwords - Took screenshots of sensitive documents

Modularity: The rootkit supported at least 20 modules that could be swapped on-the-fly
Deep Concealment: Hid itself inside system files, evading antivirus detection
Network Interception: Monitored and captured network traffic

Sophistication Level: - Approximately 20MB in size (huge for malware) - Could spread via USB drives and network shares - Remained undetected for approximately 5 years

Rustock (2006) - The Spam King¶

What happened: - Created one of the largest botnets in history - Infected between 150,000 and 2.4 million computers - Used primarily for sending spam emails

The Rootkit’s Role: 1. Botnet Management: Hid the botnet client software from users 2. Resource Theft: Secretly used infected computers to send spam 3. Persistence: Made removal extremely difficult 4. Command & Control: Maintained hidden communication channels with attackers

Alureon/TDL-4 (2011) - The MBR Rootkit¶

What happened: - Sophisticated rootkit that infected the Master Boot Record (MBR) - Made it nearly impossible to remove without specialized tools

The Rootkit’s Role: 1. Boot-Level Persistence: Loaded before the operating system 2. Deep System Control: Could modify kernel operations 3. Data Theft: Stole banking credentials and personal information 4. Backdoor Creation: Allowed remote attacker access

Why MBR rootkits are dangerous: - Load before antivirus software starts - Survive OS reinstallation - Require special boot-time tools to detect and remove

Common Pattern Across All Rootkit Attacks¶

All these attacks follow a similar pattern:

Initial Compromise: Rootkit gets installed (via CD, USB, exploit, or social engineering)
Hide & Conceal: Rootkit intercepts system calls to hide files, processes, and network connections
Maintain Access: Rootkit ensures persistence even after reboots
Execute Payload: Carry out the actual malicious goal (spying, destruction, spam, etc.)
Evade Detection: Continuously hide from antivirus and security tools

2. Side-Channel Attacks - Meltdown & Spectre¶

Understanding the Foundation: Speculative Execution¶

Modern CPUs use speculative execution to improve performance:

Like a chef preparing popular dishes before orders come in
The CPU guesses which code will run next and executes it early
If the guess is wrong, results are discarded
If correct, time is saved!

The Critical Assumption (that turned out to be wrong): CPU designers assumed that discarded speculative results leave NO traces. But they DO leave traces in the CPU cache, and these traces can be detected through timing attacks.

Why This is “Side-Channel”¶

A side-channel attack extracts information indirectly by observing the side effects of computation rather than directly reading the data.

Analogy: Imagine a secure vault where you can’t see inside: - Direct attack: Try to break the lock (blocked by security) - Side-channel attack: Listen to the clicking sounds the lock makes and deduce the combination

In Meltdown/Spectre:

Direct attack: Try to read kernel memory (blocked by permissions)
Side-channel attack: Trick the CPU into speculatively accessing kernel memory, then measure cache timing to deduce what was accessed

Meltdown: Reading Kernel Memory from User Mode¶

How Meltdown Works (Step-by-Step)¶

The Vulnerability: Intel processors read memory BEFORE checking permissions during speculative execution.

The Attack Process:

Step 1: Attacker's Code (User Mode)
  ↓
  Try to read kernel memory address (e.g., 0xFFFF...)
  ↓
Step 2: CPU Speculation
  ↓
  Permission check hasn't happened yet
  CPU speculatively reads the kernel memory
  Data gets loaded into CPU cache
  ↓
Step 3: Permission Check (Finally Happens)
  ↓
  "Wait! User mode can't access kernel memory!"
  CPU raises an exception
  Speculative results are discarded
  ↓
Step 4: Side-Channel Attack
  ↓
  Although results were discarded, the DATA is still in cache
  Attacker uses timing attack to detect what's in cache
  ↓
Step 5: Data Extracted!
  ↓
  Attacker now knows kernel memory contents

Key Insight: The CPU read the protected memory during speculation. Even though the operation was cancelled, the cache was modified, creating a detectable side effect.

The Flush+Reload Technique¶

This is how attackers detect what’s in the cache:

1. Prepare a "probe array" in memory
   array[0], array[1], array[2], ... array[255]

2. Flush all array elements from cache

3. Trigger speculative execution to read kernel byte
   The speculative code does: probe_array[kernel_byte * 256]

4. Time how long it takes to access each array element
   - If array[X] is FAST → it's in cache → kernel byte was X
   - If array[Y] is SLOW → not in cache → kernel byte wasn't Y

5. Repeat to read more bytes

Why It Works: - Cached data: ~5-10 CPU cycles to access - Uncached data: ~200+ CPU cycles to access - This timing difference is easily measurable

Spectre: Tricking Programs Into Leaking Secrets¶

How Spectre Differs from Meltdown¶

Meltdown	Spectre
Exploits out-of-order execution	Exploits branch prediction
Reads kernel memory	Tricks programs into revealing their own secrets
Specific to Intel (mostly)	Affects Intel, AMD, ARM
Can be patched by separating kernel/user page tables	Much harder to fix

Spectre Variant 1: Bounds Check Bypass¶

The Setup: Programs often have code like this:

if (x < array_size) {    value = array[x];    // Do something with value}

The Attack:

Step 1: Training Phase
  ↓
  Attacker calls this code many times with valid x values
  CPU's branch predictor learns: "x < array_size is usually TRUE"
  ↓
Step 2: Attack Phase
  ↓
  Attacker provides x = 1000 (way out of bounds)
  CPU predicts: "x < array_size will be TRUE" (wrong guess!)
  ↓
Step 3: Speculative Execution
  ↓
  Before checking x < array_size, CPU speculatively executes:
    value = array[1000]  // Reading out-of-bounds!
  ↓
Step 4: Side Channel
  ↓
  The out-of-bounds data gets into cache
  Attacker uses timing attack to extract it
  ↓
Step 5: CPU Realizes Mistake
  ↓
  "Wait! x >= array_size, the branch was wrong!"
  Results are discarded, but cache still modified

Real-World Impact: This works in web browsers! JavaScript code on a malicious website can use Spectre to read data from other tabs or browser memory.

Spectre Variant 2: Branch Target Injection¶

This variant manipulates the Branch Target Buffer (BTB), which predicts where indirect jumps will go.

The Attack: 1. Attacker trains the BTB to mispredict an indirect jump 2. CPU speculatively jumps to attacker-chosen code 3. That code accesses sensitive data 4. Side-channel extracts the data

Why These Attacks Don’t Trigger Privilege Violations¶

The Genius of Meltdown/Spectre:

They exploit the fact that modern CPUs operate in two “realities”:

Architectural State (What programs can see)
- Privilege checks are enforced here
- Speculative results that failed checks are discarded
- No privilege violation occurs at this level
Microarchitectural State (Internal CPU state)
- Cache contents, timing behavior
- Speculative execution affects this state
- Changes here are NOT discarded

Mitigations¶

Software Mitigations¶

KPTI (Kernel Page Table Isolation)
- Formerly called KAISER
- Separates kernel and user page tables
- Kernel memory not mapped in user space at all
- Cost: 5-30% performance hit
Retpoline
- Replaces indirect jumps with returns
- Prevents BTB manipulation
- Mitigates Spectre Variant 2
Site Isolation (Browsers)
- Chrome puts each website in separate process
- Limits what Spectre can access

Hardware Mitigations¶

New processors include:

Hardware barriers that prevent speculation
Better permission checking during speculation
Reduced speculative execution windows

Why These Are Called “Side-Channel” Attacks¶

Summary:

No Direct Access: Attackers never directly read protected memory
Observe Side Effects: They observe timing differences in cache access
Infer Secret Data: From timing patterns, they deduce the actual data
No Privilege Escalation: Technically, no security boundary is crossed at the architectural level

The attacks exploit the gap between what the CPU architecturally promises (security) and what it microarchitecturally does (speculation + caching).

3. DMA Attacks - Direct Memory Access¶

What is DMA (Direct Memory Access)?¶

Normal Memory Access:

Device → CPU → MMU (checks permissions) → RAM

DMA Access:

Device → RAM (bypasses CPU and OS entirely!)

Why DMA Exists: DMA is a legitimate performance feature that allows peripheral devices to access RAM directly without involving the CPU. This is essential for: - Network cards (receiving packets at high speed) - Graphics cards (rendering textures) - Storage devices (reading/writing data) - Audio devices (streaming sound)

The Problem: If a malicious device gets DMA access, it can read and write ANY part of RAM, including: - Kernel memory - Password databases - Encryption keys - Other users’ data

How DMA Attacks Work¶

The Attack Process¶

Step 1: Physical Access
  ↓
  Attacker plugs malicious device into DMA-capable port:
  - Thunderbolt
  - FireWire (IEEE 1394)
  - ExpressCard
  - PCIe slots
  - USB 4.0 (in some cases)
  - M.2 connectors
  ↓
Step 2: DMA Initialization
  ↓
  Device identifies itself to the system
  Requests (and gets) DMA access
  ↓
Step 3: Direct Memory Access
  ↓
  Device can now READ and WRITE anywhere in physical RAM
  Bypasses:
    ✗ Operating system security
    ✗ User permissions
    ✗ Login screens
    ✗ Encryption (if keys are in memory)
  ↓
Step 4: Attacker Actions
  ↓
  Options include:
  - Read memory to steal passwords/keys
  - Write memory to inject malware
  - Modify kernel structures to gain control
  - Bypass authentication screens

Real-World DMA Attack Example: PCILeech¶

PCILeech is a tool created by Ulf Frisk that demonstrates DMA attacks.

What PCILeech Can Do:¶

Dump Memory
- Read entire system memory at 150MB/s
- Extract passwords, encryption keys, documents
Bypass Login Screens
- Patch kernel memory to skip authentication
- Works on locked Windows, Linux, macOS systems
Install Backdoors
- Inject kernel modules
- Install persistent malware
Mount File System
- Access all files as if logged in

Attack Scenario: Unlocking Windows 10¶

1. Attacker's Setup:
   - Laptop with PCILeech software
   - USB3380 device (DMA-capable adapter)
   - Physical access to target computer

2. Connection:
   - Plug adapter into Thunderbolt/M.2/PCIe port
   - PCILeech detects system memory

3. Run Command:
   pcileech.exe patch -sig unlock_win10x64

4. What Happens:
   - PCILeech scans memory for Windows login structures
   - Finds and modifies the authentication check
   - Changes it from "if (password == correct) allow"
     to "allow" (bypasses check entirely)

5. Result:
   - Any password now works!
   - Attacker gains full system access

Why This is So Dangerous¶

Bypasses Everything¶

Traditional Security Layers (All Bypassed):

❌ User/Kernel Mode Separation
   - DMA doesn't care about CPU rings

❌ Memory Protection
   - DMA has full physical memory access

❌ ASLR (Address Space Layout Randomization)
   - Can scan all memory to find targets

❌ DEP/NX (Non-Executable Memory)
   - Can write executable code anywhere

❌ Full Disk Encryption
   - Encryption keys are in RAM!

❌ Login Passwords
   - Can patch authentication code

❌ Antivirus/EDR
   - Operates below their detection level

Types of DMA Attacks¶

1. Pre-Boot DMA Attacks¶

Target: Systems before OS loads - UEFI Secure Boot can’t stop them - BIOS protections ineffective - Steal encryption keys before OS starts

Example: FileVault password extraction on locked Macs (CVE-2016-7585)

2. Post-Boot DMA Attacks¶

Target: Running systems - Bypass login screens - Read live memory - Inject malware into running kernel

3. Remote DMA (RDMA) Attacks¶

Target: Networked systems in data centers

Throwhammer Attack: - Exploits RDMA over high-speed networks - Attacker sends network packets - Triggers Rowhammer bit flips remotely - Gains code execution without local access

Vulnerable Ports and Connections¶

High-Risk DMA Ports:¶

Thunderbolt (1, 2, 3, 4)
- Direct PCIe access
- High-speed data transfer
- Most powerful for attacks
FireWire (IEEE 1394)
- Legacy but still present
- Direct memory access by design
- Often enabled by default
ExpressCard
- PCIe interface
- Laptop expansion slot
USB 4.0
- Can tunnel PCIe
- Potentially DMA-capable
M.2 / PCIe Slots
- Internal but accessible if case opened
- Direct motherboard connection

Defense Against DMA Attacks¶

1. IOMMU (Input/Output Memory Management Unit)¶

What it does: - Creates “virtual memory” for DMA devices - Restricts which memory addresses devices can access - Like a firewall for DMA

Intel: VT-d AMD: AMD-Vi

How to enable:

1. Enter BIOS/UEFI settings
2. Find "Virtualization" or "IOMMU" settings
3. Enable VT-d (Intel) or AMD-Vi (AMD)
4. Save and reboot

2. Thunderbolt Security Levels¶

Modern systems have Thunderbolt security settings:

Legacy Mode: ❌ NO PROTECTION - allows all DMA
User Authorization: ✅ Prompts before allowing new devices
Secure Connect: ✅ Requires cryptographic authentication
Display Port Only: ✅ Disables PCIe tunneling

3. Kernel DMA Protection (Windows)¶

Windows 10/11 feature:

Enabled by default on new systems
Blocks DMA until OS fully boots
Uses IOMMU to restrict access

4. Physical Security Measures¶

Best practices: - Disable unused DMA ports in BIOS - Use port locks on sensitive systems - Set strong BIOS passwords - Epoxy-fill unused ports (extreme cases) - Monitor physical access to systems

5. Software Protections¶

Operating System Level: - Keep OS updated - Enable Secure Boot - Enable Trusted Boot - Use pre-boot authentication (TPM)

Additional Measures: - Deploy EDR (Endpoint Detection & Response) - Monitor for unusual DMA device connections - Use ECC memory (can detect memory tampering)

Detection Difficulty¶

Why DMA attacks are hard to detect:

Below OS visibility: Operates at hardware level
No software traces: Doesn’t execute code traditionally
Fast execution: Can be completed in seconds
Looks legitimate: DMA is a normal hardware feature

Forensic indicators: - Unexpected system reboots - Suspicious device connection logs - Changes in system behavior after physical access

4. SUID Mitigation Strategies¶

Understanding the SUID Risk¶

Why SUID is dangerous: - Allows temporary privilege escalation to root - If a SUID program has ANY vulnerability, attacker gets root - Many programs not designed to be secure with SUID

Common SUID attack vectors:

SUID-enabled program that:
1. Allows arbitrary command execution (find, vim, nano)
2. Allows arbitrary file writes (cp, mv, dd)
3. Allows arbitrary file reads (cat, less, more)
4. Has buffer overflow vulnerabilities
5. Uses insecure PATH handling
6. Follows symlinks unsafely

Comprehensive Mitigation Strategies¶

1. Minimize SUID Binary Usage¶

Principle: If you don’t need SUID, don’t use SUID!

Best Practices:

# Find all SUID filesfind / -perm -4000 -type f -ls 2>/dev/null
# Remove SUID bit from unnecessary programschmod u-s /path/to/program
# Example: Remove SUID from find (if not needed)chmod u-s /usr/bin/find

Review checklist: - ✅ Only keep SUID on essential programs (passwd, sudo, su, mount) - ✅ Remove SUID from file editors (nano, vim, less, more) - ✅ Remove SUID from utilities (find, nmap, cp, mv) - ✅ Remove SUID from custom/third-party programs

2. Use Linux Capabilities Instead¶

What are capabilities? Fine-grained privileges instead of all-or-nothing root access.

Example: Instead of making ping SUID root (which gives full root powers), give it only the capability it needs:

# Remove SUID bitchmod u-s /bin/ping
# Add only the capability needed (send raw packets)setcap cap_net_raw+ep /bin/ping
# Verifygetcap /bin/ping
# Output: /bin/ping = cap_net_raw+ep

Common useful capabilities: - CAP_NET_RAW: Send raw network packets (ping, traceroute) - CAP_NET_BIND_SERVICE: Bind to ports < 1024 (web servers) - CAP_DAC_READ_SEARCH: Read files regardless of permissions - CAP_SYS_TIME: Set system time

3. Regular SUID Audits¶

Automated audit script:

#!/bin/bash# audit_suid.sh - Check for suspicious SUID binaries# Get list of current SUID binariesfind / -perm -4000 -type f 2>/dev/null > /tmp/current_suid.txt
# Compare with baseline (create baseline first time)if [ ! -f /etc/security/suid_baseline.txt ]; then    cp /tmp/current_suid.txt /etc/security/suid_baseline.txt
    echo "Baseline created"else    # Check for new SUID binaries    diff /etc/security/suid_baseline.txt /tmp/current_suid.txt
    if [ $? -ne 0 ]; then        echo "WARNING: SUID binaries changed!"        echo "New/Changed binaries:" | mail -s "SUID Alert" admin@company.com
    fifi

Run this: - Daily via cron - After software installations - After system updates

4. Enhanced Monitoring & Logging¶

Monitor SUID execution:

# Using auditd to monitor SUID execution# Add this rule to /etc/audit/rules.d/suid.rules# Watch all SUID binary execution-a always,exit -F arch=b64 -S execve -F perm=u+s -k suid_execution
-a always,exit -F arch=b32 -S execve -F perm=u+s -k suid_execution
# Reload rulessudo auditctl -R /etc/audit/rules.d/suid.rules
# Query logsausearch -k suid_execution

What to monitor: - Unusual SUID binary execution - SUID execution by unexpected users - Multiple rapid SUID executions (may indicate attack) - SUID binaries executing at odd hours

5. SELinux / AppArmor Mandatory Access Control¶

SELinux: Even if attacker exploits SUID, SELinux policies can restrict what they can do.

# Check SELinux statussestatus# Enable SELinux# Edit /etc/selinux/configSELINUX=enforcing
# Create policy for SUID program# Only allow it to access specific files/directories

AppArmor (Ubuntu/Debian):

# Check AppArmor statussudo aa-status
# Create profile for SUID binarysudo aa-genprof /usr/bin/program
# Enforce profilesudo aa-enforce /usr/bin/program

6. Secure SUID Program Development¶

If you MUST create a custom SUID program:

Security checklist:

// Example: Secure SUID program template#include <stdio.h>#include <unistd.h>#include <sys/types.h>#include <stdlib.h>int main(int argc, char **argv) {    // 1. Clear environment variables    clearenv();    // 2. Set secure PATH    setenv("PATH", "/usr/bin:/bin", 1);    // 3. Validate all inputs    if (argc != 2) {        fprintf(stderr, "Invalid arguments\n");        return 1;    }    // 4. Drop privileges ASAP after necessary operations    uid_t real_uid = getuid();    setuid(real_uid);  // Drop SUID privileges    // 5. Never call system() or exec() with user input    // WRONG: system(argv[1]);  // NEVER DO THIS!    // 6. Validate file paths (no symlinks, no ../)    char *file = argv[1];    if (strstr(file, "..") || strstr(file, "/etc/")) {        fprintf(stderr, "Invalid path\n");        return 1;    }    return 0;}

Key principles: - ✅ Validate ALL inputs - ✅ Use whitelist approach (not blacklist) - ✅ Drop privileges immediately after needed - ✅ Never execute user-provided commands - ✅ Use full paths for executables - ✅ Check for symlinks before file operations

7. sudo with Restricted Commands¶

Instead of SUID, use sudo with restrictions:

# /etc/sudoers configuration# Allow user to run specific command with specific arguments onlyjohn ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2
# Allow reading logs only (no write/execute)webadmin ALL=(root) NOPASSWD: /usr/bin/tail -f /var/log/apache2/*# Prevent shell escapesengineer ALL=(root) NOPASSWD: !/bin/bash, !/bin/sh, /usr/local/bin/deploy.sh

Advantages over SUID: - More granular control - Better logging (sudo logs everything) - Can restrict arguments - Easier to audit

8. Filesystem Restrictions¶

Mount options to restrict SUID:

# /etc/fstab# Mount /tmp with nosuid option (SUID won't work here)tmpfs /tmp tmpfs defaults,nosuid,nodev,noexec 0 0
# Mount home directories with nosuid/dev/sda5 /home ext4 defaults,nosuid,nodev 0 2

This prevents: - Users creating SUID programs in their home directories - Attackers planting SUID backdoors in /tmp

9. Detection Tools¶

Automated security scanning:

# Lynis security auditsudo lynis audit system
# Checks for:# - Unusual SUID binaries# - World-writable SUID files# - Weak file permissions# rkhunter (rootkit hunter)sudo rkhunter --check# Detects suspicious SUID binaries# OSSEC (open-source HIDS)# Monitors SUID binary changes in real-time

10. Training and Policy¶

Administrative policies:

Change Management
- Document all SUID changes
- Require approval before setting SUID
- Security review for all custom SUID programs
Least Privilege
- Don’t grant SUID “just in case”
- Re-evaluate periodically
- Remove SUID when no longer needed
Security Training
- Educate developers about SUID risks
- Show examples of SUID exploits
- Teach secure alternatives

Summary: Defense in Depth¶

Layer 1: Prevention - Minimize SUID usage - Use capabilities instead - Secure development practices

Layer 2: Detection - Audit SUID binaries regularly - Monitor SUID execution - Use automated scanning tools

Layer 3: Containment - SELinux/AppArmor policies - Filesystem mount options (nosuid) - Restricted sudo rules

Layer 4: Response - Incident response procedures - Regular backup and recovery - Security patches and updates

Quick Reference: Commands for SUID Management¶

# Find all SUID binariesfind / -perm -4000 -type f -ls 2>/dev/null
# Remove SUID bitchmod u-s /path/to/file
# Add SUID bit (use carefully!)chmod u+s /path/to/file
# Check file permissionsls -l /path/to/file
# Look for 's' in user permissions: -rwsr-xr-x# Use capabilities insteadsetcap cap_net_raw+ep /bin/ping
getcap /bin/ping
# Monitor SUID execution (auditd)auditctl -w /usr/bin/suspicious_program -p x -k suid_watch
ausearch -k suid_watch
# List capabilities of binarygetcap -r / 2>/dev/null

Conclusion¶

SUID is a powerful but dangerous feature. The key to securing it is:

Use it sparingly - only when absolutely necessary
Audit regularly - know what has SUID on your systems
Monitor actively - detect suspicious SUID usage
Layer defenses - SELinux, capabilities, file system restrictions
Educate users - awareness prevents misconfigurations

Remember: The best SUID mitigation is not using SUID at all! Explore alternatives like capabilities, sudo, or redesigning the application.

Additional Resources¶

Rootkits¶

Mark Russinovich’s RootkitRevealer tool
“Rootkits: Subverting the Windows Kernel” by Greg Hoglund
SANS Institute: Rootkit Detection and Prevention

Side-Channel Attacks ¶

Original Meltdown paper: https://meltdownattack.com/meltdown.pdf
Original Spectre paper: https://spectreattack.com/spectre.pdf
Intel’s mitigation guide: https://software.intel.com/

DMA Attacks¶

PCILeech GitHub: https://github.com/ufrisk/pcileech
Ulf Frisk’s blog: http://blog.frizk.net/
Eclypsium’s DMA research: https://eclypsium.com/

SUID Security¶

GTFOBins (SUID exploit techniques): https://gtfobins.github.io/
Linux capabilities man page: man capabilities
SELinux documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/

Document prepared for cybersecurity education purposesLast updated: November 2024