Versteckte Cronjobs als Hintertür erkennen

Kurz gesagt: Ein versteckter Cronjob ist eine der häufigsten Hintertüren auf Linux-Servern: Er lädt Schadcode regelmäßig nach oder startet Prozesse neu, auch nach einem PHP-Update. Prüfen Sie alle Orte für geplante Aufgaben, nicht nur crontab -l: Crontabs aller Benutzer, /etc/crontab, /etc/cron.d, die cron-Ordner, systemd-Timer und at-Aufträge. Sichern Sie Funde, bevor Sie sie entfernen.

Warum Cronjobs als Hintertür so beliebt sind

Nach einem erfolgreichen Einbruch hat ein Angreifer ein Problem: Sein Zugang ist zerbrechlich. Ein Update schließt die Lücke, ein Admin löscht die Webshell, ein Neustart beendet den Prozess. Ein Cronjob löst dieses Problem. Er startet Befehle zu festen Zeiten, ohne dass jemand eingreift, und stellt so verlorene Zugänge wieder her.

Für PHP2Shell gibt es keine bestätigten Indicators of Compromise. Neue Cronjobs gehören aber laut den uns vorliegenden Berichten zu den allgemeinen Warnsignalen nach Einbrüchen über Webanwendungen. Wer bereits nach Webshells gesucht hat, sollte die geplanten Aufgaben gleich mitprüfen. Die übrigen Schritte einer Nachbereitung führt die Checkliste nach einem Hack auf.

Wo sich geplante Aufgaben verstecken können

Linux kennt mehrere Mechanismen für geplante Aufgaben. Viele Prüfungen scheitern, weil nur einer davon angesehen wird.

Wichtig für Webserver: Der Webserver-Benutzer kann in der Regel seine eigene Crontab anlegen, ohne Root-Rechte. Ein Angreifer mit den Rechten von www-data braucht dafür also keine weitere Lücke. Einträge in /etc/cron.d oder systemd-Units deuten dagegen darauf hin, dass er Root-Rechte erlangt hat.

Hosting-Panels wie Plesk oder cPanel bieten eine eigene Oberfläche für geplante Aufgaben. Dahinter stehen in der Regel ebenfalls Crontabs der jeweiligen Systembenutzer. Wer nur in der Oberfläche nachsieht, erkennt deshalb nicht jeden Eintrag, der direkt auf dem Server angelegt wurde. Prüfen Sie im Zweifel beides.

So prüfen Sie alle Orte vollständig

Die folgenden Befehle lesen nur. Führen Sie sie als root aus und sichern Sie die Ausgaben mit Datum.

# Crontabs aller Benutzer ausgeben
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Systemweite Einträge und Änderungszeiten
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# systemd-Timer und at-Aufträge
systemctl list-timers --all
atq 2>/dev/null

# Typische Muster in allen cron-Dateien suchen
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Zwei Tricks verdienen besondere Aufmerksamkeit. Manche Einträge verstecken Befehle hinter vielen Leerzeichen, sodass sie im Editor rechts aus dem Bild laufen. Andere nutzen Steuerzeichen, die bei der Anzeige Text überschreiben. Mit cat -A werden solche Zeichen sichtbar:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

Ein zweiter Blickwinkel sind die Protokolle des cron-Dienstes. Auf vielen Systemen vermerkt cron jede Ausführung mit Benutzer und Befehl. So sehen Sie auch Einträge, die ein Angreifer inzwischen wieder entfernt hat, und erkennen, seit wann ein verdächtiger Befehl läuft:

# Ausgeführte cron-Befehle des Webserver-Benutzers (Debian/Ubuntu bzw. systemd-Journal)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Woran Sie eine Cronjob-Hintertür erkennen

1. Nachladen aus dem Internet: Ein Download, dessen Ergebnis direkt an eine Shell übergeben wird.
2. Kodierte Inhalte: Lange Zeichenketten, die erst zur Laufzeit dekodiert werden.
3. Ungewöhnliche Pfade: Programme in /tmp, /dev/shm, versteckten Ordnern oder Upload-Verzeichnissen.
4. Falscher Benutzer: Aufgaben unter dem Webserver-Benutzer, obwohl die Anwendung keine braucht.
5. Auffälliger Takt: Ausführung jede Minute oder bei jedem Neustart über @reboot.
6. Unpassende Zeitstempel: Datei geändert in einem Zeitraum, in dem niemand am Server gearbeitet hat, etwa nach dem 17. Oktober.

Nicht vergessen: Auch Anwendungen haben eigene Zeitpläne. WordPress etwa verwaltet geplante Aufgaben in der Datenbank. Wie Sie dort prüfen, beschreibt Backdoors in WordPress finden.

Fund sichern, verstehen, dann entfernen

Ein bösartiger Cronjob ist ein wertvolles Beweisstück. Er zeigt die Nachladeadresse, den Zeitpunkt seiner Anlage und oft den Benutzer, über den der Angreifer kam. Sichern Sie die Datei mit Prüfsumme und Zeitstempeln, bevor Sie sie entfernen. Der Zeitstempel hilft später, den Ablauf zu rekonstruieren; wie das geht, zeigt Die Zeitleiste eines Vorfalls erstellen. Auch für eine mögliche Meldung an die Datenschutzaufsicht oder für den Versicherer ist der Fund ein wichtiger Beleg dafür, seit wann ein Angreifer Zugriff hatte.

Entfernen allein genügt nicht. Läuft noch ein Prozess, der den Eintrag neu schreibt, ist er nach der nächsten Minute zurück. Und solange die ursprüngliche Lücke offen ist, kann der Angreifer jederzeit neu ansetzen. Die Reihenfolge lautet deshalb: sichern, Ursache schließen, alle Bestandteile entfernen, Zugänge wechseln, überwachen.

Cronjobs vorbeugend absichern

Damit eine Cronjob-Hintertür gar nicht erst entstehen kann oder schnell auffällt, helfen drei Maßnahmen. Erstens lässt sich festlegen, welche Benutzer überhaupt eine Crontab anlegen dürfen. Existiert die Datei /etc/cron.allow, dürfen nur die dort genannten Benutzer crontab verwenden. Braucht Ihre Anwendung keinen Cronjob unter dem Webserver-Benutzer, gehört dieser Benutzer nicht auf die Liste. Prüfen Sie vorher, welche Aufgaben die Anwendung tatsächlich benötigt, und legen Sie diese bewusst unter einem eigenen Benutzer an.

Zweitens lohnt eine Überwachung der Dateien. Ein Werkzeug zur Integritätsprüfung meldet, sobald sich eine Datei in den cron-Verzeichnissen oder unter /var/spool/cron ändert. Drittens gehören geplante Aufgaben in die Dokumentation des Servers: Wer weiß, welche Einträge es geben soll, erkennt einen fremden sofort.

Wie hilft PHP SOS konkret?

• Vollständig prüfen: Wir untersuchen alle Mechanismen für geplante Aufgaben, auch systemd-Timer, at-Aufträge und Anwendungs-Zeitpläne.
• Funde einordnen: Wir werten verdächtige Einträge aus, ohne sie auszuführen, und leiten weitere Spuren ab.
• Sauber bereinigen: Mit der Malware-Entfernung entfernen wir alle Bestandteile und schließen die Ursache.
• Wiederkehr erkennen: Wir richten eine Überwachung ein, die neue oder geänderte geplante Aufgaben meldet.

Häufige Fragen

Quellen

• BSI: Bundesamt für Sicherheit in der Informationstechnik
• BSI IT-Grundschutz
• OWASP Cheat Sheet Series