Man muss kein besonders wertvolles Ziel sein, um von einem automatisierten Angriff im großen Stil getroffen zu werden. Man braucht keine wertvollen Daten, muss nicht bekannt sein und nichts falsch gemacht haben. Es reicht, ein öffentlich erreichbares WordPress im Internet zu betreiben. Genau das ist Schritt für Schritt passiert, als eine mit SeenSecure geschützte Seite innerhalb von Sekunden eine Welle von über 300 Anfragen pro Minute erhielt.
Es ist kein Mensch, es ist ein Scanner
Ein solcher Angriff wird fast nie von jemandem gestartet, der am Rechner sitzt und überlegt, was er ausprobieren soll. Es ist ein Skript, das eine Liste mit Tausenden bekannter Pfade abarbeitet — alte Plugin-Ordner, Demo-Dateien, vergessene Testskripte — und sie gegen Millionen von Domains testet, eine nach der anderen, unermüdlich und wahllos. Das Ziel ist nicht “dein” WordPress im Speziellen: Es ist jedes WordPress, das auf einen dieser Pfade mit “Ja” antwortet.
In diesem konkreten Fall enthielten die Anfragen Muster, die jeder mit WordPress-Sicherheitserfahrung sofort wiedererkennt:
- Anfragen an Demo-Dateien von Drittanbieter-Bibliotheken (wie
getid3), die in älteren Plugin-Versionen das Lesen oder sogar Schreiben von Dateien auf dem Server erlaubten. - Verlassene Testskripte von Zahlungs-/CRM-Integrationen (wie Infusionsoft), die manchmal interne Funktionen ohne Authentifizierung offenlegen.
- Path-Traversal-Versuche wie
../../../etc/passwd, um aus dem Seitenordner auszubrechen und Systemdateien zu lesen. - SQL-Injection-Payloads, die testen, ob ein URL-Parameter ungefiltert bis zu einer Datenbankabfrage durchdringt.
Keine dieser Techniken ist neu oder ausgefeilt. Es sind buchstäblich dieselben Fehlerkategorien, die schon der Morris-Wurm 1988 ausnutzte — nur werden sie heute automatisch, kostenlos und ohne jeden Aufwand gegen Millionen Seiten gleichzeitig getestet.
Schicht für Schicht: Was jeden Versuch gestoppt hat
Eine Seite ohne dedizierten Schutz muss darauf vertrauen, dass WordPress selbst, das betroffene Plugin und der Server perfekt aktuell und korrekt konfiguriert sind — eine riskante Wette, wenn eine einzige vergessene Datei ausreicht, um die Tür zu öffnen. So bricht die Kette bei jeder Schicht:
- Rate Limiting: Sobald eine einzelne IP die erlaubte Anzahl Anfragen pro Minute überschreitet, wird sie gekappt — ohne erst zu analysieren, was genau angefragt wird. Das ist die erste Barriere und die günstigste unter hoher Last.
- Firewall-Regeln (WAF): Jede verbleibende Anfrage wird mit bekannten Angriffsmustern verglichen — Path Traversal, SQL-Injection, XSS. Bei einer Übereinstimmung wird sie blockiert, bevor sie WordPress überhaupt erreicht.
- Schutz sensibler Dateien: Pfade zu Demo-Dateien, Backups, Logs oder Abhängigkeits-Manifesten werden bereits auf Serverebene blockiert, ohne dass PHP überhaupt ausgeführt wird.
- Persistente Sperrung: Eine IP, die mehrere dieser Alarme in kurzer Zeit auslöst, wird für eine gewisse Zeit gesperrt — ihre nächsten Anfragen werden gar nicht mehr geprüft, sondern schon im allerersten Schritt abgefangen, praktisch ohne Kosten für den Server.
Das Ergebnis in diesem konkreten Fall: über 300 Anfragen pro Minute, die diese Schichten durchliefen — und null Anfragen, die je nicht autorisierten Code ausgeführt oder eine Datei erreicht haben, die sie nicht sehen sollten.
Warum das kein Einzelfall ist
Das Beunruhigende an dieser Art von Angriff ist nicht ihre Raffinesse — die hat sie nicht — sondern wie normal sie ist. Genau dieses Muster wiederholt sich, mit kleinen Variationen, gegen praktisch jede öffentlich erreichbare WordPress-Seite, jeden Tag, rund um die Uhr. Der Unterschied zwischen einer kompromittierten Seite und einer, die nicht einmal merkt, dass sie gescannt wurde, liegt selten an “mehr Sicherheit” im Abstrakten — sondern daran, Schichten zu haben, die sich ergänzen: eine, die nach Volumen filtert, eine nach Muster, eine nach Reputation, und ein Protokoll von alledem, damit man genau weiß, was passiert ist, falls doch etwas durchrutscht.
Wenn du diese Art von Traffic auf deiner eigenen WordPress-Seite sehen willst — du bekommst ihn wahrscheinlich gerade jetzt, ohne es zu wissen — zeigt der Echtzeit-Traffic-Monitor von SeenSecure jede blockierte Anfrage mit dem genauen Grund in einfacher Sprache, ganz ohne technisches Log-Lesen.