🔍 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:

Schritt	Beschreibung
✅ Berechtigungen	chmod +x auf miner-hunter und alle lib/*.sh-Skripte
✅ Verzeichnisse	Erstellt /var/log/miner_hunter/ und /var/lib/miner_hunter/ (nur root, 700)
✅ Abhängigkeiten	Überprüft perf, mpstat, iptables, fail2ban, bc, strings – installiert fehlende automatisch
✅ Selbsttest	Führt ./miner-hunter --version aus, um zu bestätigen, dass alles korrekt eingerichtet ist

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

Befehl	Beschreibung	Ändert System?
scan	Vollständiger Erkennungsscan – versteckte Prozesse, CPU, Netzwerk, Persistenz	✅ Nein
kill	Erkannte Miner töten, Pool-IPs blockieren, Artefakte entfernen	⚠️ Ja
harden	Härtung nach dem Vorfall – SSH, Firewall, Watchdog, Integritätsbasis	⚠️ Ja
full	Führt scan → kill → harden mit Bestätigungsabfragen zwischen den Phasen aus	⚠️ Ja
report	Zeigt den neuesten Scanbericht an	✅ Nein

Optionen

Option	Beschreibung
-d, --dry-run	Alle Aktionen in der Vorschau anzeigen, ohne Änderungen vorzunehmen
-e, --evidence DIR	Beweise in einem benutzerdefinierten Verzeichnis speichern anstatt in /root/miner_evidence_*
-h, --help	Hilfe anzeigen
-v, --version	Version anzeigen

---

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

---