🔍 Miner Hunter

Krypto-Miner-Erkennung, -Entfernung und Härtungstoolkit für Linux-Server.

Entwickelt aus realen Vorfallreaktionen – erkennt Miner, die sich mit Rootkit-Techniken vor ps, top, htop und btop verstecken.

📦 Installation

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

🔀 Branch: master – Dieses Toolkit befindet sich im master-Branch. In Zukunft können weitere Sicherheitsskripte in separaten Branches hinzugefügt werden.

⚙️ Einrichtung

⚠️ Führen Sie setup.sh einmal direkt nach dem Klonen aus – das Überspringen ist die häufigste Fehlerursache.

sudo bash setup.sh

setup.sh erledigt alles automatisch:

Erwartete Ausgabe bei erfolgreicher Einrichtung:

✅ Setup complete — all checks passed!

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

💡 Warum ist das nötig? Linux führt keine Datei aus, solange sie nicht das +x-Flag hat. Git- und SCP-Übertragungen entfernen dieses Flag. setup.sh repariert alle Dateien auf einmal – einschließlich der lib/-Module, von denen das Hauptskript abhängt.

🚀 Schnellstart

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

📋 Befehle und Optionen

Befehle

Optionen

🎭 Fallszenarien

Reale Situationen und genau das, was in jeder ausgeführt werden soll.

🔴 Szenario 1 — "Meine Server-CPU ist bei 100%, aber top zeigt nichts"

Dies ist das klassische Rootkit-Symptom. Der Miner versteckt sich vor Userspace-Tools, kann sich aber nicht vor Hardware-Leistungszählern verstecken.

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

Was Sie sehen, wenn ein Miner vorhanden ist:

🚨 [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

🟡 Szenario 2 — "Ich glaube, ich wurde gehackt, bin mir aber nicht sicher"

Ihnen ist etwas Verdächtiges aufgefallen – ungewöhnlicher ausgehender Datenverkehr, ein Cron-Job, den Sie nicht erstellt haben, ein Prozess mit einem seltsamen Namen – aber Sie sind sich nicht sicher.

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

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

Der Bericht unter /root/miner_evidence_*/report.txt kategorisiert jeden Fund nach Schweregrad:

• [CRITICAL]-Einträge → sofort zu kill übergehen
• [WARNING]-Einträge → manuell prüfen, bevor gehandelt wird
• Leerer Bericht → Server scheint sauber

🟠 Szenario 3 — "Ich habe den Miner manuell getötet, aber er kommt immer wieder zurück"

Der Miner hat einen Persistenzmechanismus – einen Cron-Job, systemd-Dienst, PM2-Eintrag oder Shell-Profil-Hintertür, die ihn nach dem Töten wiederbelebt.

sudo ./miner-hunter scan

Achten Sie auf diese in der Ausgabe:

⚠️  [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

💡 Nach kill läuft der Watchdog-Cron alle 5 Minuten und protokolliert in /var/log/miner_hunter/watchdog_alerts.log – Sie wissen sofort, ob etwas zurückkommt.

🔵 Szenario 4 — "Ich möchte einen frischen Server härten, bevor etwas passiert"

Proaktive Härtung vor der Bereitstellung – kein Miner, kein Vorfall, einfach alles absichern.

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

Dies wird:

• Ihre SSH-Konfiguration überprüfen und die empfohlenen Einstellungen anzeigen
• Überprüfen, ob fail2ban mit einem sshd-Gefängnis aktiv ist
• Eine /usr/bin-Integritätsbasis (MD5-Prüfsummen) erstellen, damit Sie später manipulierte Binärdateien erkennen können
• Einen Cron-Watchdog installieren, der alle 5 Minuten auf Miner-Indikatoren prüft
• Bestehende iptables-Regeln über einen systemd-Dienst nach jedem Neustart persistent machen

⚫ Szenario 5 — "Der Miner hat das Töten überlebt – CPU ist immer noch hoch"

Nach kill meldet der Verifizierungsschritt, dass der Miner möglicherweise noch läuft:

⚠️  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

Wenn der Kernel-Taint-Wert nicht Null ist oder ein bekanntes Rootkit-Modul auftaucht – der Miner hat Kernel-Level-Kontrolle. Der sicherste Weg an diesem Punkt ist eine vollständige Neuinstallation des Betriebssystems von einem bekannten sauberen Snapshot.

🟣 Szenario 6 — "Ich möchte fortlaufende Überwachung, ohne Scans manuell auszuführen"

Nach harden ist der Watchdog-Cron bereits installiert. So arbeiten Sie damit:

# 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

Jede Ausgabe des letzten Befehls bedeutet, dass eine Systembinärdatei nach Ihrer Baseline modifiziert wurde – sofort untersuchen.

🔬 Was es erkennt

Erkennung versteckter Prozesse

CPU-Profiling

Netzwerkanalyse

Persistenzmechanismen

⚔️ Tötungsprozess – Schritt für Schritt

Wenn Sie sudo ./miner-hunter kill ausführen, ist dies die genaue Abfolge:

1. 🔥 Mining-Pool-IPs an der Firewall blockieren – iptables DROP-Regeln werden vor dem Töten angewendet, sodass der Miner sich nicht wieder verbinden kann, selbst wenn er wiederbelebt wird.
2. 💀 Thread-Gruppenleiter töten – zielt zuerst auf die TGID (Thread-Gruppenleiter-PID) mit SIGKILL
3. 🧹 Alle Worker-Threads entfernen – tötet jede PID in derselben Thread-Gruppe über den gesamten PID-Bereich
4. 🗑️ Artefakte entfernen – Miner-Konfigurationen, Binärdateien, Webshells und Persistenzdateien
5. 🔄 PM2 bereinigen – entfernt Miner-Einträge aus dem Node.js-Prozessmanager und speichert die Liste
6. ✅ Verifizieren – führt perf erneut aus und überprüft /proc/net/tcp, um zu bestätigen, dass die CPU gesunken ist und Verbindungen verschwunden sind

🛡️ Härtung nach dem Vorfall – Was angewendet wird

📁 Projektstruktur

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

📋 Anforderungen

📤 Ausgabedateien

🌍 Realer Ursprung

Dieses Tool wurde während einer aktiven Incident-Response gegen einen Krypto-Miner entwickelt, der:

• Sich selbst in next umbenannt hat, um sich auf einem Node.js-Server in Next.js-Prozesse einzufügen
• Einen Thread-Gruppenleiter verwendet hat, der in kthreadd umbenannt wurde – ein tatsächlicher Kernel-Thread-Name
• Seine Binärdatei von der Festplatte gelöscht hat, während es im Speicher lief (/proc/PID/exe → (deleted))
• Für ps, top, htop und btop vollständig unsichtbar war
• Nur über perf-Hardware-CPU-Zähler-Profiling erkannt werden konnte

📄 Lizenz

MIT