Kurz gesagt: Geänderte Dateien finden Sie unter Linux mit find und einem Zeitfenster, etwa ab dem 17. Oktober 2026, dem laut Medienberichten ersten beobachteten Angriffsversuch auf PHP2Shell. Prüfen Sie dabei nicht nur die Änderungszeit des Inhalts (mtime), sondern auch die der Metadaten (ctime), weil sich erstere leicht fälschen lässt. Verlässlich wird das Ergebnis erst durch den Abgleich mit Paketprüfsummen, Git oder einem Backup.
Warum Zeitstempel ein guter Einstieg sind, aber kein Beweis
Wer Code auf einen Server bringt, verändert Dateien. Neue Webshells, angepasste Konfigurationsdateien, ergänzte Zeilen in vorhandenen Skripten: All das hinterlässt Zeitstempel. Die Suche nach Änderungen im richtigen Zeitfenster ist deshalb einer der schnellsten Wege zu ersten Funden.
Für PHP2Shell bietet sich als Beginn des Fensters der 17. Oktober 2026 an, der Tag des laut Medienberichten ersten beobachteten Angriffsversuchs. Die Patches erschienen am 21. Oktober. Wer seinen Server erst danach aktualisiert hat, sucht bis zum Tag des eigenen Updates und darüber hinaus. Wie Sie Webshells unter den Funden erkennen, beschreibt Webshell erkennen und entfernen. Hier geht es um die Methode der Suche selbst.
Die drei Zeitstempel einer Datei
Linux speichert zu jeder Datei mehrere Zeitpunkte. Für die Suche nach Veränderungen sind zwei entscheidend.
| Zeitstempel | Bedeutung | Fälschbar? |
|---|---|---|
| mtime | letzte Änderung des Inhalts | ja, z. B. mit touch, durch jeden, der die Datei schreiben darf |
| ctime | letzte Änderung von Inhalt oder Metadaten wie Rechten | nicht mit einfachen Mitteln |
| atime | letzter Lesezugriff | oft abgeschaltet oder ungenau, für die Suche wenig geeignet |
Angreifer datieren die mtime gern auf das Datum der Nachbardateien zurück, damit eine neue Datei nicht auffällt. Die ctime verändert sich dabei aber mit. Eine Datei mit alter mtime und frischer ctime ist deshalb ein starkes Indiz für Manipulation.
Achten Sie beim Vergleich auf Zeitzonen. find und ls zeigen die lokale Zeit des Servers, viele Logdateien und Dienste arbeiten dagegen in UTC. Wer Funde aus Dateisystem und Logs nebeneinanderlegt, sollte alle Angaben in dieselbe Zeitzone umrechnen, sonst passen Ereignisse scheinbar nicht zusammen. Die Patches erschienen etwa am 21. Oktober um 14:00 UTC, also um 16 Uhr deutscher Zeit.
Geänderte Dateien unter Linux mit find finden
Alle Befehle lesen nur. Passen Sie Pfad und Datum an.
# Inhalt seit dem 17.10.2026 geändert, sortiert, mit mtime, ctime und Eigentümer
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadaten seit dem 17.10.2026 geändert (findet auch zurückdatierte Dateien)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Bekanntes Rauschen ausblenden: Cache, Logs, Sessions
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Auch außerhalb des Webverzeichnisses nachsehen
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Vergleichen Sie bei jedem Treffer beide Zeitstempel. Ist die ctime deutlich jünger als die mtime, und hat niemand in dieser Zeit Rechte geändert oder Dateien kopiert, gehört die Datei auf die Liste. Achten Sie auch auf Eigentümer: Eine Datei des Webserver-Benutzers zwischen Dateien des Deploy-Benutzers fällt auf.
Vergessen Sie versteckte Dateien und Verzeichnisse nicht. Namen, die mit einem Punkt beginnen, zeigen viele Dateimanager und ein einfaches ls nicht an. Angreifer nutzen das gern, ebenso wie Namen, die echten Dateien zum Verwechseln ähneln.
# Versteckte Dateien und Ordner im Webverzeichnis, ohne bekannte wie .htaccess und .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Gegen eine vertrauenswürdige Quelle abgleichen
Zeitstempel zeigen, wo sich etwas bewegt hat. Ob es eine legitime Änderung war, zeigt erst der Vergleich mit einer Quelle, der Sie vertrauen.
- Paketverwaltung: Für Systemdateien prüfen
dpkg --verify(Debian/Ubuntu) oderrpm -Va(RHEL-Familie) die Dateien gegen die Prüfsummen der installierten Pakete. Konfigurationsdateien weichen legitim ab, Programmdateien nicht. - Git: Liegt die Anwendung in einem Repository, zeigt
git -C /var/www/projekt status --porcelainjede Abweichung vom letzten Commit. - CMS-Prüfsummen: Viele Systeme können ihre Kerndateien gegen die offiziellen Prüfsummen abgleichen, siehe CMS-Kerndateien mit dem Original vergleichen.
- Backup von vor dem Vorfall: Ein Vergleich im Probelauf listet Unterschiede, ohne etwas zu kopieren.
# Unterschiede zwischen Backup-Stand und Live-System nur auflisten (Probelauf, kopiert nichts)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Der Backup-Vergleich setzt voraus, dass das Backup vor dem Vorfall entstand und nicht selbst verändert wurde. Warum getrennt aufbewahrte Sicherungen hier entscheidend sind, erklärt Backups nach der 3-2-1-Regel.
Speichern Sie die Ergebnisse jeder Suche mit Datum in einer Datei außerhalb des Servers. Aus diesen Listen entsteht später die Zeitleiste des Vorfalls, und sie belegen, was Sie wann geprüft haben.
Wenn es weder Backup noch Repository gibt
Bei vielen kleineren Websites existiert keine saubere Vergleichsbasis: kein Git, kein Backup von vor dem Vorfall, Plugins seit Jahren per Hand aktualisiert. Ganz ohne Anhaltspunkt sind Sie trotzdem nicht.
Laden Sie das CMS und die Erweiterungen in genau den installierten Versionen beim Hersteller herunter und vergleichen Sie diese Dateien mit dem Server. Was dort abweicht oder fehlt, verdient einen Blick. Übrig bleiben Ihre eigenen Anpassungen, Uploads und Konfiguration; dort hilft die Zeitstempel-Suche, ergänzt um einen Blick auf Eigentümer und Rechte. Dateien, die als einzige in einem Verzeichnis eine andere Gruppe, andere Rechte oder eine deutlich jüngere ctime als ihre Nachbarn haben, gehören auf die Liste.
Ehrlich gesagt: Ohne Vergleichsbasis bleibt eine Restunsicherheit. Bei Systemen mit sensiblen Daten ist ein Neuaufbau aus sauberen Quellen dann oft verlässlicher als die Suche nach jeder einzelnen veränderten Datei. Für die Zukunft ist die Lehre einfach: ein Repository für den Code und regelmäßige, getrennt aufbewahrte Sicherungen.
Typische Fehlerquellen bei der Suche
- Zu großzügige Ausschlüsse: Cache- und Upload-Ordner sind beliebte Verstecke.
- Nur mtime geprüft: Zurückdatierte Dateien rutschen durch.
- Deployment im Zeitfenster: Ein regulärer Rollout ändert Hunderte Dateien und verdeckt einzelne Funde. Gleichen Sie gegen das Repository ab.
- Dateien bereits geöffnet oder kopiert: Kopien ohne Erhalt der Zeitstempel zerstören Spuren. Sichern Sie mit Werkzeugen, die Zeitstempel erhalten.
- Nur das Webverzeichnis durchsucht: Angreifer legen Werkzeuge auch in
/tmp,/dev/shmoder im Heimatverzeichnis des Webserver-Benutzers ab. - Rechteänderungen übersehen: Eine Datei, deren Rechte plötzlich Schreibzugriff für alle erlauben, ist ein Fund, auch wenn ihr Inhalt unverändert ist.
Wie die Funde zu einem Ablauf zusammengesetzt werden, zeigt Die Zeitleiste eines Vorfalls erstellen.
Wie hilft PHP SOS konkret?
- Systematisch suchen: Wir durchsuchen Webverzeichnisse und Systempfade nach Änderungen im relevanten Zeitfenster und werten mtime und ctime gemeinsam aus.
- Gegen Originale prüfen: Wir gleichen gegen Pakete, Repository, CMS-Prüfsummen und Ihre Backups ab.
- Funde bewerten: Wir trennen reguläre Änderungen von Manipulationen und sichern Beweise.
- Bereinigen: Mit der Malware-Entfernung stellen wir einen sauberen Stand her und dokumentieren ihn.
Häufige Fragen
Wie finde ich alle Dateien, die seit einem bestimmten Datum geändert wurden?
Mit find und der Option -newermt, etwa find /var/www -type f -newermt "2026-10-17". Für Änderungen an den Metadaten nutzen Sie -newerct. Beide Befehle lesen nur und verändern nichts.
Was ist der Unterschied zwischen mtime und ctime?
mtime ist der Zeitpunkt der letzten Inhaltsänderung und lässt sich mit einfachen Mitteln zurückdatieren. ctime ist der Zeitpunkt der letzten Änderung an Inhalt oder Metadaten und lässt sich nicht so einfach fälschen. Weichen beide stark voneinander ab, lohnt ein genauer Blick.
Wie schließe ich Cache-Dateien aus der Suche aus?
Mit -not -path für bekannte Cache-, Log- und Session-Ordner. Schließen Sie aber nicht zu großzügig aus, denn Angreifer legen Dateien gern genau dort ab, wo viele Änderungen normal sind.
Welche Prüfung ist am verlässlichsten?
Der Abgleich gegen eine vertrauenswürdige Quelle: Prüfsummen der Paketverwaltung, ein Git-Repository oder ein Backup von vor dem Vorfall. Zeitstempel sind ein guter Einstieg, aber kein Beweis.