IOC in WordPress: Spuren prüfen, Befunde einordnen

Aktualisiert: 9. September 2026

Ein IOC (Indicator of Compromise) ist ein beobachtbares Merkmal, das auf eine mögliche Kompromittierung hindeutet, etwa eine auffällige Datei, eine bekannte Schadsoftware-Prüfsumme oder eine verdächtige Verbindung. Wie belastbar der Hinweis ist, hängt von seiner Herkunft, Genauigkeit und dem Kontext ab. Ein einzelner Treffer ist nicht automatisch ein bestätigter Angriff.

Symptom, Verdacht, IOC: Beobachtung und Schlussfolgerung trennen

Symptom, Arbeitshypothese und konkreter Indikator helfen dabei, Beobachtung und Schlussfolgerung auseinanderzuhalten.

Ein Symptom ist eine Beobachtung: Die Seite ist langsam, Google zeigt eine Warnung oder Nutzer berichten von unerwarteten Weiterleitungen. Die Ursache ist damit noch nicht bestimmt.

Ein Verdacht ist eine prüfbare Arbeitshypothese, beispielsweise eine ausgenutzte Schwachstelle in einer installierten Komponente. Dazu müssen passende Belege gesucht und alternative Erklärungen geprüft werden.

Ein Indikator kann eine ungewöhnliche PHP-Datei im Upload-Verzeichnis sein. Dateipfad, Inhalt und Prüfsumme lassen sich dokumentieren und mit vertrauenswürdigen Referenzen vergleichen. Erst die Einordnung zeigt, ob ein Sicherheitsvorfall vorliegt.

Dokumentiere auch Symptome, Hypothesen, Zeitpunkte und negative Prüfergebnisse. Wer nur bestätigte Funde festhält, verliert wichtige Informationen für die spätere Rekonstruktion.

Fundstellen: Dateien, Datenbank und Aufgaben

Die folgenden Stellen sind ein möglicher Einstieg, keine vollständige Untersuchung und keine statistisch belegte Rangfolge. Bei einem laufenden Vorfall haben Eindämmung und Beweissicherung Vorrang. Unbekannte Dateien nicht über den Browser aufrufen oder probeweise ausführen.

Ein erster Core-Vergleich mit einer vertrauenswürdigen WP-CLI-Installation:

wp core verify-checksums --include-root

Dieser Befehl vermeidet das Laden von WordPress. Version und Sprachfassung müssen zum untersuchten Bestand passen. Zusätzliche Dateien im Wurzelverzeichnis können legitim sein und sind einzeln einzuordnen.

1. Kernverzeichnisse. Vergleiche Dateien mit der passenden offiziellen WordPress-Version und Sprachfassung. Abweichungen können auf Manipulation, aber auch auf ein unvollständiges Update oder eigene Änderungen hinweisen. Ein erfolgreicher Core-Abgleich prüft weder die gesamte Datenbank noch alle Plugins, Uploads und Servereinstellungen.

2. Upload-Verzeichnis. Ausführbarer Code unterhalb von wp-content/uploads/ verdient Aufmerksamkeit. Eine PHP-Datei allein ist noch kein Beweis; auch legitime Komponenten können dort Dateien erzeugen. Die folgende Suche ist nur ein Filter und erfasst weder alle ausführbaren Endungen noch alle möglichen Speicherorte.

find wp-content/uploads -type f -name "*.php"

3. wp-config.php. Prüfe zusätzliche Includes und Codeänderungen gegen eine vertrauenswürdige Fassung. Zeitstempel sind nur Hinweise: Sie lassen sich verändern oder beim Kopieren erhalten. Zugangsdaten aus der Datei gehören nicht in öffentlich geteilte Befundberichte.

4. Webserver-Konfiguration. Bei Apache auch .htaccess in Unterverzeichnissen auf unerklärte Regeln prüfen. Bei Nginx liegen entsprechende Regeln in dessen Konfiguration. Besucherabhängige Weiterleitungen können auch aus PHP, JavaScript, Datenbankinhalten oder vorgeschalteten Diensten stammen.

5. Datenbank. Große Optionswerte helfen beim Sortieren, beweisen aber keine Infektion. Prüfe Herkunft und Inhalt sowie siteurl und home. Auch Beiträge und andere Tabellen können betroffen sein. Im lesenden SQL-Beispiel ist wp_ durch das tatsächliche Tabellenpräfix zu ersetzen; bei Multisite die richtige Website-Tabelle wählen.

SELECT option_name, LENGTH(option_value) AS groesse
FROM wp_options
ORDER BY groesse DESC
LIMIT 20;

6. Benutzer und Rollen. Vergleiche Konten und tatsächliche Berechtigungen mit dem freigegebenen Bestand. Bei Multisite auch Netzwerkrechte berücksichtigen. Eine kompromittierte Oberfläche ist keine verlässliche alleinige Quelle. Details erklärt Schatten-Admin.

7. Geplante Aufgaben und automatisch geladener Code. Prüfe WordPress-Cron, Systemaufgaben, MU-Plugins und Drop-ins. Unbekannte Namen zunächst einer Komponente zuordnen. wp cron event list lädt WordPress und gehört bei Infektionsverdacht nur in eine isolierte Untersuchung mit kontrolliertem Bootstrap. --skip-plugins überspringt MU-Plugins nicht und schafft keine sichere Sandbox.

Muster und Signaturen gemeinsam bewerten

Scanner können Signaturen, Heuristiken, Integritätsvergleiche und Verhaltensdaten kombinieren. Manuelle Musterprüfungen ergänzen diese Verfahren. Weder ein Signaturtreffer noch ein auffälliges Muster ersetzt die Einordnung.

Zeitstempel. Kürzlich geänderte Dateien können die Untersuchung eingrenzen. Updates und Deployments verändern ebenfalls Dateien; manipulierte Zeitstempel können Spuren verschleiern. Die folgende Abfrage listet PHP-Dateien mit einer Änderungszeit innerhalb der letzten 30 Tage, ohne sie auszuführen.

find . -type f -name "*.php" -mtime -30 -print

Verschleierter Code. Verschachtelte Dekodierungen und zur Laufzeit erzeugter Code sind prüfenswert. Minifizierung, generierte Dateien und kommerzielle Schutzmechanismen können ähnlich aussehen. Entscheidend ist das Verhalten und der Vergleich mit einer vertrauenswürdigen Herstellerfassung.

Ausgehende Verbindungen. Aufrufe an fremde Adressen aus Dateien, die dafür keinen Anlass haben. Ein Bildergalerie-Plugin, das eine unbekannte Domain kontaktiert, ist erklärungsbedürftig.

Falsche Dateinamen. Dateien, die so heißen wie Kerndateien, aber an einer Stelle liegen, an der es sie nicht gibt.

Was ein IOC nicht beweist

Nicht jeder Fund ist ein Angriff. Caching-Plugins legen generierte PHP-Dateien an ungewöhnlichen Stellen ab. Sicherheits-Plugins schreiben Regeln in die .htaccess. Manche kommerziellen Plugins liefern absichtlich verschleierten Code aus, um ihre Lizenzprüfung zu schützen – ärgerlich, aber legitim.

Deshalb gilt: Ein nicht erklärter Fund bleibt zunächst ungeklärt. Erst zusätzliche Belege erlauben eine belastbare Zuordnung. Umgekehrt bedeutet „keine bekannten IOCs gefunden“ nicht, dass die Installation sauber ist.

Die Reihenfolge nach dem Fund

Eindämmen und sichern. Bei aktiver Schädigung den Zugriff begrenzen und mit dem Hoster koordinieren. Möglichst unveränderte Kopien von Dateien, Datenbank und Logs getrennt sichern; Änderungen und Zeitpunkte festhalten.
Dokumentieren. Herkunft, Pfad, Zeitstempel, Größe und Prüfsumme erfassen. Befunde mit Zugangsdaten oder personenbezogenen Informationen geschützt aufbewahren.
Vertrauenswürdigen Zustand herstellen. Betroffene Komponenten aus geprüften Paketen ersetzen, Schadcode und unberechtigte Konten entfernen sowie den Zugriffsweg schließen. Keine pauschale Löschung aller Suchtreffer.
Zugänge absichern. Kompromittierte Zugänge sofort sperren. Zugangsdaten und Schlüssel von einem sauberen System aus erneuern; finale Geheimnisse erst in eine bereinigte Umgebung übernehmen. WordPress-Salts invalidieren Authentifizierungs-Cookies, ersetzen aber keine Passwort- und Schlüsselrotation.
Überwachen. Funktionen, Dateien, Konten und Logs erneut prüfen. Kontrollen nach 24 und 72 Stunden können ein Startpunkt sein; ein fester Zeitraum beweist keine vollständige Bereinigung.

Warum ein Scanner-Ergebnis nur die halbe Arbeit ist

Eine Liste gefundener Dateien beantwortet die Frage, was da ist. Sie beantwortet nicht, wie es hereinkam. Solange das offen bleibt, ist jedes Aufräumen eine Zwischenlösung mit unbekannter Haltbarkeit.

Für die Ursachensuche kommen Zugriffs-, Fehler-, Hosting- und Authentifizierungslogs sowie Deployment- und Updateverläufe zusammen. Zeitstempel, Zeitzonen und Log-Lücken müssen berücksichtigt werden. Gestohlene Zugangsdaten oder ein kompromittiertes Hosting sind ebenfalls mögliche Ursachen; eine zeitlich nahe Anfrage allein beweist den Einstiegsweg nicht.

Bleibt der Umfang unklar, kann ein Neuaufbau aus vertrauenswürdigen Paketen mit geprüften Inhalten sinnvoll sein. Dabei auch Hosting, Zugänge und weitere betroffene Systeme berücksichtigen. Unklarheiten und Restrisiken dokumentieren; Wiederherstellung allein schließt den ursprünglichen Zugriffsweg nicht zwingend.

Mein wp2shell IOC Scanner unterstützt die Untersuchung der wp2shell-Angriffskette mit Indikatoren, Integritätsprüfungen und Befundexporten. Er arbeitet standardmäßig lesend und bietet eine kontrollierte Kontobereinigung. Er entfernt keine Schadsoftware und ersetzt keine vollständige Vorfallanalyse.