🔍 Miner Hunter

Crypto-miner detection, removal, and hardening toolkit for Linux servers.

Built from real-world incident response — detects miners that hide from ps, top, htop, and btop using rootkit techniques.

📦 Installation

git clone https://gitlab.com/abdom.seada/security-checks.git
cd security-checks
sudo bash setup.sh

🔀 Branch: master — This toolkit lives on the master branch. Other security scripts may be added on separate branches in the future.

⚙️ Setup

⚠️ Run setup.sh once right after cloning — skipping this is the #1 cause of errors.

sudo bash setup.sh

setup.sh handles everything automatically:

Expected output when setup succeeds:

✅ Setup complete — all checks passed!

  Next steps:
    sudo ./miner-hunter scan        # Safe read-only scan
    sudo ./miner-hunter full        # Scan → Kill → Harden

💡 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

sudo ./miner-hunter scan            # ✅ Safe — read-only, zero changes
sudo ./miner-hunter full            # ⚠️  Full pipeline: Scan → Kill → Harden
sudo ./miner-hunter scan --dry-run  # 👁️  Preview mode — shows what would happen

📋 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.

# Step 1: Run a safe scan first — confirm what's there before touching anything
sudo ./miner-hunter scan

What you'll see if a miner is present:

🚨 [CRITICAL]  CPU anomaly: 97% user CPU but top shows max 2% per process
🚨 [CRITICAL]  perf detected 4 hidden threads consuming ~94% total CPU
🚨 [CRITICAL]  Active connection to 185.x.x.x:9200 (known mining port)
🚨 [CRITICAL]  Fake kernel thread PID=3421 NAME=[kworker/0:1] EXE=/tmp/.x/miner

# Step 2: Kill the miner and block its pool
sudo ./miner-hunter kill

# Step 3: Harden the server so it can't come back
sudo ./miner-hunter harden

🟡 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.

# Run a full scan — completely safe, read-only, zero changes
sudo ./miner-hunter scan

# Then read the structured report
sudo ./miner-hunter report

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.

sudo ./miner-hunter scan

Look for these in the output:

⚠️  [WARN]     Suspicious cron entry: * * * * * /tmp/.x/update
🚨 [CRITICAL]  Malicious systemd service: /etc/systemd/system/update-check.service
🚨 [CRITICAL]  PM2 process 'app-worker' has 8432 restarts — likely miner respawn loop
🚨 [CRITICAL]  Shell profile backdoor detected in /root/.bashrc

# kill removes ALL persistence artifacts — not just the running process
sudo ./miner-hunter kill

# Then harden to install the watchdog so you're alerted if anything respawns
sudo ./miner-hunter harden

💡 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.

# Run harden standalone — no scan or kill needed
sudo ./miner-hunter harden

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:

⚠️  MINER MAY HAVE RESPAWNED
CPU: 89% | Mining conns: 1
Firewall blocks are in place — miner can't reach pool
Consider a REBOOT or OS REINSTALL

# 1. Firewall blocks are already in place — miner CANNOT reach its pool
#    Confirm blocks are active:
iptables -L OUTPUT -n | grep DROP

# 2. Run a second scan to see what survived
sudo ./miner-hunter scan

# 3. Check for a kernel module rootkit hiding the process
lsmod | grep -iE 'diamorphine|reptile|kovid|rootkit'

# 4. Non-zero taint = out-of-tree kernel modules loaded (rootkit indicator)
cat /proc/sys/kernel/tainted

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:

# Watch the alert log in real time
tail -f /var/log/miner_hunter/watchdog_alerts.log

# Confirm the watchdog cron job is registered
cat /etc/cron.d/miner-watchdog

# Check for /usr/bin binary changes since your baseline was taken
md5sum --check /var/lib/miner_hunter/usrbin_baseline.md5 --quiet

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

security-checks/               ← repo root (master branch)
├── miner-hunter               # Entry point — this is what you run
├── setup.sh                   # ⚙️ First-time setup — run once after cloning
├── lib/
│   ├── common.sh              # Shared utilities: logging, colors, helpers
│   ├── detect_hidden.sh       # Hidden process & rootkit detection
│   ├── detect_cpu.sh          # CPU profiling via perf & /proc
│   ├── detect_network.sh      # Mining pool connection detection
│   ├── detect_persistence.sh  # Persistence mechanism detection
│   ├── kill_miner.sh          # Process killing & artifact removal
│   └── harden.sh              # Post-incident hardening
├── README.md
└── LICENSE

📋 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