Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
security checks — Linux-Sicherheitsprüfungen | Kitploit
Tools/GitLabGitLab/abdom.seada/security-checks
DefensivwerkzeugeSpeicherforensikSchwachstellenanalyseNetzwerkforensikKonfigurationsprüfungForensikMalware-AnalyseDigitale ForensikEinbruchserkennungIncident ResponseLog-Analyse
8vor 5 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
GitLab
abdom.seada/security-checks

security checks

Linux-Sicherheitsprüfungen

Repository anzeigen
Teilen

🔍 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

root@kitploit:~
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.

Tool herunterladen
root@kitploit:~
sudo bash setup.sh

setup.sh erledigt alles automatisch:

SchrittBeschreibung
✅ Berechtigungenchmod +x auf miner-hunter und alle lib/*.sh-Skripte
✅ VerzeichnisseErstellt /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
✅ SelbsttestFührt ./miner-hunter --version aus, um zu bestätigen, dass alles korrekt eingerichtet ist

Erwartete Ausgabe bei erfolgreicher Einrichtung:

root@kitploit:~
✅ 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

root@kitploit:~
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

BefehlBeschreibungÄndert System?
scanVollständiger Erkennungsscan – versteckte Prozesse, CPU, Netzwerk, Persistenz✅ Nein
killErkannte Miner töten, Pool-IPs blockieren, Artefakte entfernen⚠️ Ja
hardenHärtung nach dem Vorfall – SSH, Firewall, Watchdog, Integritätsbasis⚠️ Ja
fullFührt scan → kill → harden mit Bestätigungsabfragen zwischen den Phasen aus⚠️ Ja
reportZeigt den neuesten Scanbericht an✅ Nein

Optionen

OptionBeschreibung
-d, --dry-runAlle Aktionen in der Vorschau anzeigen, ohne Änderungen vorzunehmen
-e, --evidence DIRBeweise in einem benutzerdefinierten Verzeichnis speichern anstatt in /root/miner_evidence_*
-h, --helpHilfe anzeigen
-v, --versionVersion 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.

root@kitploit:~
# 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:

root@kitploit:~
🚨 [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
root@kitploit:~
# 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.

root@kitploit:~
# 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.

root@kitploit:~
sudo ./miner-hunter scan

Achten Sie auf diese in der Ausgabe:

root@kitploit:~
⚠️  [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
root@kitploit:~
# 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.

root@kitploit:~
# 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:

root@kitploit:~
⚠️  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
root@kitploit:~
# 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:

root@kitploit:~
# 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

TechnikWas erfasst wird
/proc vs ps-VergleichProzesse, die für Userspace-Tools unsichtbar sind
LD_PRELOAD-HijackingBösartige Shared Libraries, die libc hooken, um Prozesse zu verstecken
Kernel-Modul-RootkitsDiamorphine, Reptile, Kovid und andere bekannte Rootkits
Gefälschte Kernel-ThreadsMiner, die sich als [kworker], [kthreadd], [kswapd] tarnen
Modifizierte SystembinärdateienErsetzte ps, top, ls, ss, netstat

CPU-Profiling

TechnikWas erfasst wird
perf Hardware-PMC-ProfilingVerborgene CPU-Verbraucher – Rootkits können Hardwarezähler nicht fälschen
/proc-Delta-AbtastungDirekte CPU-Abrechnung auf Kernel-Ebene pro PID
CPU-AnomalieerkennungHohe %user-CPU ohne sichtbaren Prozess, der sie erklärt

Netzwerkanalyse

TechnikWas erfasst wird
Direktes Lesen von /proc/net/tcpAktive Verbindungen – umgeht gehackte ss/netstat
Erkennung von Mining-PortsPorts 3333, 4444, 5555, 7777, 9200, 14433, 14444, 45560
Auflösung von Mining-DomänenLöst bekannte Pool-Domänen auf und kreuzprüft aktive Verbindungen
Socket-zu-PID-ZuordnungVerfolgt, welcher Prozess jede Mining-Verbindung besitzt

Persistenzmechanismen

SpeicherortWas geprüft wird
Cron/etc/cron*, /var/spool/cron/, alle Benutzer-Crontabs
SystemdAlle Unit-Dateien und Timer auf verdächtige Einträge
Udev-RegelnHardware-getriggerte Ausführung bei Geräteereignissen
PM2Einträge des Node.js-Prozessmanagers mit extremen Neustartzahlen
Shell-Profile.bashrc, .bash_profile, /etc/profile, /etc/profile.d/*
SSHAlle authorized_keys-Dateien aller Benutzer
WebshellsPHP-Dateien in Node.js-Projektverzeichnissen
XMRig-Konfigurationenconfig.json in üblichen Miner-Ablageorten

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

AktionDetail
Firewall-PersistenzSystemd-Dienst, um iptables-Mining-Blockaden bei jedem Neustart wiederherzustellen
SSH-ÜberprüfungÜberprüft PermitRootLogin, PasswordAuthentication, MaxAuthTries – zeigt empfohlene Werte an
Fail2ban-PrüfungÜberprüft, ob das sshd-Gefängnis aktiv ist, und meldet aktuell gesperrte IPs
Miner-WatchdogCron-Job alle 5 Minuten – prüft CPU-Anomalie, LD_PRELOAD, Mining-Ports, PHP-Webshells
/usr/bin-BaselineErstellt MD5-Prüfsummen aller Binärdateien in /usr/bin zur zukünftigen Erkennung von Manipulationen

📁 Projektstruktur

root@kitploit:~
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

AnforderungDetail
BetriebssystemLinux – getestet auf Ubuntu 24.04 LTS, Debian 13
BerechtigungenMuss als root (sudo) ausgeführt werden
Automatisch installiert von setup.shperf, mpstat (sysstat), bc, strings (binutils)
Empfohlenfail2ban – wird als fehlend markiert, nicht automatisch installiert
Erforderlich (nicht automatisch installiert)iptables – muss für die kill/harden-Phasen vorhanden sein

📤 Ausgabedateien

AusgabeSpeicherortInhalt
Beweisverzeichnis/root/miner_evidence_YYYYMMDD_HHMMSS/Erfasste Binärdateien, perf-Berichte, Miner-Konfigurationen
Logdatei/var/log/miner_hunter/run_YYYYMMDD_HHMMSS.logVollständiger, mit Zeitstempel versehener Ausführungslog
Berichtevidence_dir/report.txtStrukturierte Zusammenfassung der Ergebnisse mit Schweregraden
Watchdog-Warnungen/var/log/miner_hunter/watchdog_alerts.logLaufende Warnungen nach harden
Integritätsbasis/var/lib/miner_hunter/usrbin_baseline.md5/usr/bin-Prüfsummen nach harden

🌍 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