Kurz gesagt: Ein Kryptominer auf dem Server zeigt sich meist durch dauerhaft hohe CPU-Last ohne erkennbaren Grund, durch fremde Prozesse, oft unter dem Webserver-Benutzer, und durch ausgehende Verbindungen zu unbekannten Zielen. Beenden Sie den Prozess nicht vorschnell: Sichern Sie zuerst Spuren, suchen Sie die Mechanismen, die ihn neu starten, und schließen Sie das Einfallstor. Ein Miner bedeutet, dass jemand Code auf Ihrem Server ausführen konnte.
Wenn die Rechnung des Cloud-Anbieters die erste Warnung ist
Oft fällt ein Kryptominer nicht durch einen Sicherheitsalarm auf, sondern nebenbei. Die Website wird träge, der Hoster meldet eine Überschreitung der Rechenzeit, der Lüfter im eigenen Rechenzentrum läuft ständig, oder die Abrechnung beim Cloud-Anbieter steigt ohne neue Projekte. Für Angreifer ist ein Miner ein einfacher Weg, aus einem kompromittierten Server Geld zu machen.
Mining heißt, die Rechenleistung eines fremden Systems für die Erzeugung von Kryptowährung zu nutzen. Der Schaden scheint überschaubar, weil keine Daten verschlüsselt werden. Das täuscht: Wer einen Miner starten kann, kann auch Zugangsdaten lesen, Datenbanken kopieren und weitere Hintertüren anlegen.
Nach PHP2Shell lohnt die Prüfung besonders. Die Lücken CVE-2026-109618 und CVE-2026-109619 erlauben die Ausführung von Schadcode ohne Anmeldung. Bestätigte Indicators of Compromise gibt es nicht, und ein Miner ist kein spezifisches Zeichen für diese Lücken. Hohe Last durch unbekannte Prozesse gehört aber zu den allgemeinen Anzeichen, die unter Bin ich schon kompromittiert? beschrieben sind.
Anzeichen eines Kryptominers richtig deuten
Hohe Last hat viele harmlose Ursachen. Die Tabelle hilft bei der ersten Einordnung:
| Beobachtung | Harmlose Erklärung möglich | Was Sie prüfen |
|---|---|---|
| CPU dauerhaft nahe Vollauslastung | Backup, Bildverarbeitung, Indexaufbau | Läuft die Last auch nachts und am Wochenende gleichmäßig? |
| Prozess mit Namen wie ein Systemdienst | selten | Liegt die Programmdatei im erwarteten Systempfad? |
Prozess unter www-data, apache oder nginx, der kein PHP ist |
kaum | Wer hat ihn gestartet, aus welchem Ordner? |
Programm in /tmp, /var/tmp oder /dev/shm |
kaum | Seit wann existiert die Datei, wem gehört sie? |
| Dauerhafte ausgehende Verbindung zu einem unbekannten Ziel | Monitoring, Updates | Gehört das Ziel zu einem bekannten Dienst? |
| Last sinkt, sobald Sie sich anmelden | selten | Manche Schadprogramme pausieren, wenn Überwachungswerkzeuge laufen |
Je mehr Zeilen zutreffen, desto wahrscheinlicher ist ein Fund. Dass der Webserver-Benutzer überhaupt fremde Programme startet, ist für sich ein starkes Warnsignal, wie der Beitrag Der Webserver startet eine Shell zeigt.
So prüfen Sie Prozesse und Verbindungen
Die folgenden Befehle lesen nur. Notieren Sie Ergebnis und Uhrzeit, bevor Sie irgendetwas verändern:
# Prozesse nach CPU-Verbrauch, mit Benutzer, Startzeit und vollem Befehl
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Programmdatei und Arbeitsverzeichnis eines verdächtigen Prozesses (PID einsetzen)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Ausgehende Verbindungen mit Prozess
sudo ss -tnp state established
# Ausführbare Dateien in temporären Ordnern
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Zeigt /proc/PID/exe auf eine Datei mit dem Zusatz (deleted), wurde das Programm nach dem Start gelöscht. Das ist ein typischer Tarnversuch. Der Prozess läuft weiter, und solange er läuft, lässt sich die Programmdatei noch über /proc sichern. Das sollte jemand übernehmen, der mit Schadsoftware umgehen kann; führen Sie die Datei nie aus.
Wie Sie Prozesse über den Miner hinaus systematisch durchgehen, beschreibt Verdächtige Prozesse auf Linux-Servern finden.
Warum der Miner immer wiederkommt
Viele Betreiber beenden den Prozess, freuen sich über die sinkende Last und stellen am nächsten Tag fest, dass alles wieder von vorn beginnt. Miner werden fast immer mit einem Neustartmechanismus installiert. Typische Orte sind:
- Cronjobs des Webserver-Benutzers oder systemweit, die alle paar Minuten prüfen, ob der Miner läuft, und ihn sonst nachladen.
- Systemdienste mit unauffälligen Namen, die beim Booten starten.
- Eine Webshell im Webverzeichnis, über die der Angreifer den Miner jederzeit neu startet.
- Geänderte Startskripte oder Profildateien von Benutzern.
- Fremde SSH-Schlüssel, mit denen sich der Angreifer direkt wieder anmeldet.
# Cronjobs des Webserver-Benutzers und systemweite Einträge
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Zuletzt geänderte systemd-Units
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Erst wenn alle Mechanismen gefunden sind, bleibt der Server dauerhaft ruhig. Hatte der Angreifer Root-Rechte, ist ein Neuaufbau auf einem frischen System meist verlässlicher als die Suche nach jedem Versteck.
Die richtige Reihenfolge nach dem Fund
Ein Miner wirkt wie ein technisches Ärgernis, ist aber ein Sicherheitsvorfall. Gehen Sie deshalb geordnet vor:
- Sichern: Prozessliste, Verbindungen, verdächtige Dateien und Logs mit Prüfsumme kopieren, bevor etwas beendet wird.
- Eindämmen: Server isolieren oder ausgehende Verbindungen sperren, wenn das ohne Datenverlust möglich ist.
- Ursache schließen: PHP auf einen behobenen Stand bringen (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder bestätigter Backport), alle Worker neu starten, CMS und Erweiterungen aktualisieren.
- Bereinigen oder neu aufbauen: Miner, Neustartmechanismen und Hintertüren entfernen, im Zweifel neu aufsetzen.
- Folgen prüfen: Konnten Zugangsdaten oder personenbezogene Daten gelesen werden? Dann Datenschutz und gegebenenfalls Meldepflichten klären.
Binden Sie früh Ihren Hoster oder Cloud-Anbieter ein. Viele Anbieter sperren Server mit auffälliger Last oder auffälligem Netzverkehr vorsorglich. Wer den Anbieter selbst informiert und das Vorgehen abstimmt, behält eher die Kontrolle über den Zeitpunkt der Abschaltung. Fragen Sie dabei auch nach den Netzwerk- und Zugriffsprotokollen des Anbieters, denn sie liegen außerhalb Ihres Servers und sind für einen Angreifer schwer zu verändern.
Für die Geschäftsführung ist eine kurze, ehrliche Einordnung wichtig: Der Miner selbst kostet vor allem Rechenzeit und Leistung. Die eigentliche Frage lautet aber, was der Angreifer außerdem gesehen hat. Bis das geklärt ist, sollte der Vorfall nicht als erledigt gelten, auch wenn die Last wieder normal ist.
Ein Kryptominer zeigt, dass Code auf Ihrem Server ausgeführt wurde. Behandeln Sie alle Zugangsdaten, die auf dem Server lagen, als möglicherweise abgeflossen, und erneuern Sie sie nach der Bereinigung.
Wie hilft PHP SOS konkret?
- Wir ordnen die Last ein und unterscheiden zwischen harmlosen Ursachen und fremden Prozessen.
- Wir sichern Prozesse, Dateien und Verbindungen, bevor der Miner beendet wird.
- Wir suchen alle Neustartmechanismen und Hintertüren und bereinigen den Server im Rahmen der Malware-Entfernung oder bauen ihn neu auf.
- Wir schließen das Einfallstor, erneuern Zugänge und richten eine Lastüberwachung ein, die ungewöhnliche Muster früh meldet.
Häufige Fragen
Woran erkenne ich einen Kryptominer auf meinem Server?
Typisch ist eine dauerhaft hohe CPU-Last, die nicht zu Besucherzahlen oder geplanten Aufgaben passt. Dazu kommen Prozesse mit unbekannten oder harmlos klingenden Namen, oft unter dem Webserver-Benutzer, und ausgehende Verbindungen zu fremden Adressen. Ein einzelnes Merkmal ist noch kein Beweis.
Reicht es, den Mining-Prozess zu beenden?
Nein. Miner werden meist über Cronjobs, Systemdienste oder eine Webshell immer wieder gestartet. Wer nur den Prozess beendet, sieht ihn oft kurze Zeit später wieder. Zudem bleibt das Einfallstor offen, über das der Miner auf den Server kam.
Ist ein Kryptominer harmlos, weil er nur Rechenleistung stiehlt?
Nein. Wer einen Miner installieren konnte, konnte Code auf dem Server ausführen. Damit waren in der Regel auch Konfigurationsdateien, Zugangsdaten und Datenbanken erreichbar. Der Miner ist das sichtbare Symptom eines Einbruchs.
Welche harmlosen Ursachen hat eine hohe Serverlast?
Backups, Bildverarbeitung, Suchindex-Aufbau, aggressive Crawler oder eine fehlerhafte Erweiterung können ebenfalls viel Rechenzeit verbrauchen. Diese Ursachen lassen sich meist einem bekannten Prozess und Zeitplan zuordnen. Bleibt die Last ohne Erklärung, sollten Sie genauer prüfen.