security checks

linux security checks

setup.sh handles everything automatically:

Expected output when setup succeeds:

💡 Why is this needed? Linux won't execute a file unless it has the +x flag. Git and SCP transfers strip this. setup.sh fixes all files in one shot — including the lib/ modules the main script depends on.

🚀 Quick Start

📋 Commands & Options

Commands

Options

🎭 Case Scenarios

Real-world situations and exactly what to run in each one.

🔴 Scenario 1 — "My server CPU is at 100% but top shows nothing"

This is the classic rootkit symptom. The miner is hiding from userspace tools but cannot hide from hardware performance counters.

What you'll see if a miner is present:

🟡 Scenario 2 — "I think I was hacked but I'm not sure"

You noticed something suspicious — unusual outbound traffic, a cron job you didn't create, a process with a weird name — but you're not certain.

The report at /root/miner_evidence_*/report.txt categorizes every finding by severity:

• [CRITICAL] entries → proceed to kill immediately
• [WARNING] entries → review manually before acting
• Empty report → server appears clean

🟠 Scenario 3 — "I killed the miner manually but it keeps coming back"

The miner has a persistence mechanism — a cron job, systemd service, PM2 entry, or shell profile backdoor that respawns it after you kill it.

Look for these in the output:

💡 After kill, the watchdog cron runs every 5 minutes and logs to /var/log/miner_hunter/watchdog_alerts.log — you'll know immediately if something comes back.

🔵 Scenario 4 — "I want to harden a fresh server before anything happens"

Proactive hardening before deploying — no miner, no incident, just locking things down.

This will:

• Audit your SSH config and print the recommended settings
• Verify fail2ban is active with an sshd jail
• Create a /usr/bin integrity baseline (MD5 checksums — so you can detect tampered binaries later)
• Install a cron watchdog that checks every 5 minutes for miner indicators
• Persist any existing iptables rules across reboots via a systemd service

⚫ Scenario 5 — "The miner survived the kill — CPU is still high"

After kill, the verify step reports the miner may still be running:

If the kernel taint value is non-zero or a known rootkit module appears — the miner has kernel-level control. The safest path at this point is a full OS reinstall from a known-clean snapshot.

🟣 Scenario 6 — "I want ongoing monitoring without running scans manually"

After harden, the watchdog cron is already installed. Here's how to work with it:

Any output from the last command means a system binary was modified after your baseline — investigate immediately.

🔬 What It Detects

Hidden Process Detection

CPU Profiling

Network Analysis

Persistence Mechanisms

⚔️ Kill Process — Step by Step

When you run sudo ./miner-hunter kill, this is the exact sequence:

1. 🔥 Block mining pool IPs at firewall — iptables DROP rules applied before killing, so the miner can't reconnect even if it respawns
2. 💀 Kill thread group leader — targets the TGID (thread group leader PID) first with SIGKILL
3. 🧹 Sweep all worker threads — kills every PID in the same thread group across the full PID range
4. 🗑️ Remove artifacts — miner configs, binaries, webshells, and persistence files
5. 🔄 Clean PM2 — removes miner entries from the Node.js process manager and saves the list
6. ✅ Verify — re-runs perf and checks /proc/net/tcp to confirm CPU dropped and connections are gone

🛡️ Post-Incident Hardening — What Gets Applied

📁 Project Structure

📋 Requirements

📤 Output Files

Every run produces:

🌍 Real-World Origin

This tool was built during active incident response against a crypto miner that:

• Renamed itself to next to blend in with Next.js processes on a Node.js server
• Used a thread group leader renamed to kthreadd — an actual kernel thread name
• Deleted its binary from disk while staying running in memory (/proc/PID/exe → (deleted))
• Was completely invisible to ps, top, htop, and btop
• Could only be detected via perf hardware CPU counter profiling

📄 License

MIT