Kurz gesagt: Verdächtige Prozesse auf Linux-Servern erkennen Sie an wenigen Merkmalen: Programmdatei gelöscht oder in /tmp, /dev/shm oder einem Web-Verzeichnis, Name ahmt einen Systemprozess nach, ungewöhnlicher Benutzer, dauerhafte Netzwerkverbindungen oder hohe Last ohne Grund. Prüfen Sie mit lesenden Befehlen, ob die Programmdatei zu einem installierten Paket gehört, und sichern Sie Funde, bevor Sie etwas beenden.
Was „verdächtig“ bei einem Prozess bedeutet
Auf einem Webserver laufen Hunderte Prozesse. Die meisten gehören zum Betriebssystem, zum Webserver, zur Datenbank oder zu PHP. Ein Angreifer, der über eine Lücke wie PHP2Shell Code ausführen konnte, versucht, dazwischen nicht aufzufallen. Er wählt unauffällige Namen und legt Programme dort ab, wo der Webserver-Benutzer schreiben darf.
Für die Prüfung hilft es, den Normalzustand zu kennen. Wer weiß, welche Dienste auf einem Server laufen sollen, unter welchen Benutzern und mit welcher Last, erkennt Abweichungen viel schneller. Fehlt dieses Wissen, lohnt es sich, die Prozessliste eines gleichartigen, unverdächtigen Servers zum Vergleich heranzuziehen.
Ein einzelnes Merkmal ist noch kein Beweis. Entscheidend ist das Zusammenspiel. Ein Prozess mit dem Namen eines Kernel-Threads, der unter www-data läuft, aus /dev/shm gestartet wurde und eine Verbindung ins Ausland hält, ist ein klarer Fall. Wie Sie den Sonderfall einer Shell unter dem Webserver prüfen, beschreibt Warnsignal: Der Webserver startet eine Shell.
Erster Überblick in fünf Befehlen
Alle Befehle lesen nur. Führen Sie sie als root aus, damit Sie alle Prozesse sehen, und speichern Sie die Ausgaben in einer Datei außerhalb des Webverzeichnisses.
# 1. Alle Prozesse mit Benutzer, Eltern-PID, Startzeit, CPU und Kommandozeile
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Prozesse, deren Programmdatei gelöscht wurde
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Prozesse, die aus temporären oder Web-Verzeichnissen laufen
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Prozesse mit Netzwerkverbindungen
ss -tunap
# 5. Prozesse der Webserver-Benutzer im Überblick
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Benutzernamen weichen je Distribution und Panel ab; Plesk und andere Panels führen PHP oft unter dem Benutzer des jeweiligen Kunden aus. Passen Sie die Liste an Ihre Umgebung an.
Lesen Sie die Ausgaben mit Blick auf die Startzeit. Prozesse, die seit dem letzten Neustart des Servers laufen, gehören meist zum System. Prozesse, die mitten in der Nacht oder in den Tagen nach dem 17. Oktober gestartet wurden und zu keinem Dienst passen, verdienen Aufmerksamkeit. Vergleichen Sie auch die Zahl der PHP-Prozesse mit dem, was Ihre Pool-Konfiguration erlaubt; deutlich mehr Prozesse unter einem Webserver-Benutzer sind ein Hinweis.
Verdächtige Prozesse unter Linux: typische Merkmale
| Merkmal | Warum es auffällt | Harmlose Erklärung möglich? |
|---|---|---|
| Programmdatei „(deleted)“ | Angreifer löschen Dateien nach dem Start | ja, nach Paket-Updates bis zum Neustart |
Startort /tmp, /dev/shm, Upload-Ordner |
dort darf jeder oder der Webserver schreiben | selten |
Name in eckigen Klammern wie [kworker] |
ahmt Kernel-Threads nach | nein, wenn eine Programmdatei dahintersteht |
| Dauerhaft hohe CPU-Last ohne Anlass | typisch für Kryptominer | ja, bei Batch-Jobs oder Indexierung |
| Elternprozess 1 und Webserver-Benutzer | vom Webserver gelöst, läuft eigenständig weiter | selten |
| Verbindung zu unbekanntem Ziel | Steuerung oder Datenabfluss | ja, bei Updates und APIs |
Echte Kernel-Threads haben keine Programmdatei; ls -l /proc/PID/exe liefert bei ihnen keinen Pfad. Zeigt ein Prozess mit Kernel-Namen auf eine Datei, ist er getarnt. Bei hoher Last ohne erkennbaren Grund hilft der Beitrag Kryptominer auf dem Webserver weiter.
Gegenprobe: Gehört die Programmdatei zu einem Paket?
Fast alle legitimen Programme auf einem Server stammen aus der Paketverwaltung. Eine Programmdatei, die keinem Paket gehört, ist nicht automatisch bösartig, verdient aber einen genauen Blick.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: zu welchem Paket gehört die Datei?
rpm -qf "$EXE" # RHEL-Familie
sha256sum /proc/$PID/exe # Prüfsumme, funktioniert auch bei gelöschter Datei
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # Umgebungsvariablen
Ist die Programmdatei gelöscht, liest sha256sum /proc/$PID/exe sie trotzdem aus dem laufenden Prozess. Diese Prüfsumme gehört in die Dokumentation. Eine Kopie der Datei sollte nur jemand anlegen, der weiß, wie man sie sicher verwahrt.
Grenzen der Prüfung am laufenden System
Alle Befehle oben vertrauen dem System, das Sie gerade prüfen. Bei einem gewöhnlichen Einbruch über die Website mit den Rechten des Webserver-Benutzers ist das vertretbar. Hat ein Angreifer Root-Rechte erlangt, kann er Prozesse verstecken und Ausgaben verfälschen. Dann zeigt der Server nur, was der Angreifer zulässt.
Hinweise darauf sind Widersprüche: Last ohne sichtbaren Prozess, Verbindungen, die die Firewall sieht, ss aber nicht, oder veränderte Systemprogramme. In solchen Fällen gehört die Prüfung an ein gesichertes Abbild. Bei laufenden Systemen kommt oft eine Sicherung des Arbeitsspeichers hinzu, denn manche Schadprogramme existieren nur dort und hinterlassen auf der Festplatte kaum Spuren. Diese Sicherung muss vor einem Neustart erfolgen und verlangt passende Werkzeuge und Erfahrung. Warum Sie dieses vor einer Neuinstallation anlegen sollten, erklärt Beweise sichern, bevor Sie neu aufsetzen.
Beenden Sie verdächtige Prozesse nicht als ersten Schritt. Häufig startet ein Cronjob oder ein Dienst sie neu, und mit dem Prozess verschwinden Kommandozeile, Verbindungen und die gelöschte Programmdatei aus dem Speicher.
Autostarts prüfen und nächste Schritte
Ein Schadprozess, der nach einem Neustart verschwunden bliebe, wäre für Angreifer wertlos. Deshalb gehört zu jedem Prozessfund die Frage, was ihn startet. Neben Cronjobs kommen vor allem systemd-Dienste in Frage, die ein Angreifer mit Root-Rechten anlegen kann. Auffällig sind Dienste mit generischen Namen, deren Programmdatei in einem ungewöhnlichen Verzeichnis liegt, und Unit-Dateien, die nach dem 17. Oktober entstanden sind.
# Laufende Dienste und kürzlich geänderte Unit-Dateien
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Wird eine Bibliothek in jeden Prozess eingeschleust? Die Datei existiert normalerweise nicht.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Ein Eintrag in /etc/ld.so.preload ist auf normalen Webservern selten und ein starkes Indiz für Manipulation mit Root-Rechten. Wie Sie geplante Aufgaben vollständig prüfen, beschreibt Versteckte Cronjobs als Hintertür erkennen.
Danach folgen die nächsten Schritte in dieser Reihenfolge:
- Ausgaben und Prüfsummen mit Uhrzeit sichern.
- Persistenz suchen: Cronjobs, systemd-Dienste und Timer, SSH-Schlüssel.
- Herkunft klären: Logs ab dem 20. Oktober, neue Dateien im Webverzeichnis.
- Server isolieren und Bereinigung oder Neuaufbau planen.
Einen Überblick über alle typischen Anzeichen nach PHP2Shell gibt Bin ich schon kompromittiert?.
Wie hilft PHP SOS konkret?
- Prozesse bewerten: Wir prüfen Prozessliste, Programmdateien und Verbindungen und ordnen jeden Fund ein.
- Gerichtsfest sichern: Mit der IT-Forensik sichern wir Arbeitsspeicher und Datenträger, bevor etwas verändert wird.
- Persistenz finden: Wir suchen nach Mechanismen, die Schadprozesse neu starten.
- Abschließen: Wir bereinigen oder bauen neu auf und dokumentieren den Vorfall bis zum Abschluss.
Häufige Fragen
Woran erkenne ich einen verdächtigen Prozess unter Linux?
Typische Merkmale sind eine gelöschte Programmdatei, ein Startort in /tmp oder /dev/shm, ein Name, der einen Systemprozess nachahmt, ein ungewöhnlicher Benutzer und dauerhafte Netzwerkverbindungen. Einzelne Merkmale sind Hinweise, mehrere zusammen ein ernster Verdacht.
Was bedeutet „(deleted)“ bei /proc/PID/exe?
Die Programmdatei des Prozesses wurde nach dem Start gelöscht. Das passiert legitim nach Paket-Updates, bis der Dienst neu startet. Bei Prozessen aus temporären Ordnern oder unter dem Webserver-Benutzer ist es ein typisches Tarnverhalten.
Kann ich mich auf die Ausgabe von ps verlassen?
Bei einem gewöhnlichen Einbruch meist ja. Hat ein Angreifer jedoch Root-Rechte erlangt, kann er Werkzeuge und Ausgaben manipulieren. Dann ist eine Prüfung von außen, etwa an einem gesicherten Abbild, verlässlicher.
Soll ich einen verdächtigen Prozess mit kill beenden?
Nicht als erstes. Sichern Sie zuerst Kommandozeile, Programmdatei, Verbindungen und Startzeit. Ein beendeter Prozess verrät nichts mehr, und häufig startet ihn ein Cronjob oder Dienst ohnehin neu.