Was nach Codeausführung möglich ist
- weitere PHP-Dateien ablegen oder verändern
- Administratoren und Anwendungspasswörter anlegen
- Datenbankinhalte und Weiterleitungen manipulieren
- WordPress- oder serverseitig geplante Aufgaben einrichten
- Zugangsdaten und Konfiguration auslesen
Das Plugin kann Eintrittsweg, Nutzlast oder nur ein zufälliger Fundort sein. Zeitstempel, Logs und bekannte Schwachstellen helfen bei der Einordnung, sind aber nicht immer vollständig.
Das Verschwinden einer Scanner-Warnung beweist nicht, dass keine zweite Hintertür existiert.
Sauberer Ersatz und Abnahme
Die betroffene Komponente wird aus einer verifizierten Quelle neu installiert oder dauerhaft entfernt. Danach folgen die Prüfung von Dateien, Datenbank, Konten und geplanten Aufgaben, die Erneuerung betroffener Zugangsdaten und ein Funktionstest. Der Abschlussbericht hält fest, was verifiziert wurde und wo Vergleichsdaten fehlten.
War das Plugin Eintrittsweg oder nur Fundort?
Das lässt sich nur über Version, bekannte Schwachstellen, Anfragen, Dateiänderungen und weitere Spuren eingrenzen. Ein Angreifer kann Schadcode nach erfolgreicher Anmeldung in ein beliebiges Pluginverzeichnis schreiben. Umgekehrt kann eine verwundbare Erweiterung der Eintrittsweg sein, obwohl die spätere Webshell an anderer Stelle liegt.
Sichern Sie deshalb Pluginversion, Quelle, Prüfsummen, Zeitstempel und verdächtige Anfragen. Die Aussage „Plugin X war schuld“ ist erst belegt, wenn die zeitliche Abfolge den Ausnutzungsweg stützt. Eine veröffentlichte Schwachstelle allein genügt nicht.
Welche Bereiche müssen danach geprüft werden?
Kontrollieren Sie WordPress-Kerndateien, andere Plugins, Designvorlagen, Must-use-Plugins, Uploads, Zwischenspeicher, Datenbankoptionen, Administratoren, Anwendungspasswörter und geplante Aufgaben. Beziehen Sie übergeordnete Hostingverzeichnisse und weitere Websites im selben Hostingkonto ein. Besonders wichtig sind Zugangsdaten und Schlüssel aus wp-config.php, Bereitstellungsprozessen und Hosting, weil ausgeführter PHP-Code sie lesen konnte.
Die Übersicht zu Webshells und Persistenz erklärt diese Ebenen im Zusammenhang.
Wann ist der Ersatz vertrauenswürdig?
Installieren Sie die passende Version aus dem offiziellen Verzeichnis oder einer verifizierten Herstellerquelle neu. Übernehmen Sie keine unbekannten Dateien aus dem kompromittierten Ordner. Individueller Code braucht eine kontrollierte Quellcodeverwaltung oder einen geprüften Vergleichsstand.
Nach dem Ersatz folgen Funktionsprüfung, erneute Suche nach Angriffsspuren und das Erneuern betroffener Zugangsdaten. Bleibt die Ursache offen, wird das ausdrücklich dokumentiert und enger überwacht.