WordPress-Websites werden angegriffen, nur weil sie online sind: 356 Angriffe in 7 Stunden
Eine WordPress-Website braucht weder Besucher noch Inhalte oder Backlinks, um angegriffen zu werden. Am 6. September 2026 verzeichneten 21 neue WordPress-Honeypots, von denen niemand wusste, innerhalb von sieben Stunden 356 Angriffe von 84 IP-Adressen, und der erste Angriff kam 15 Minuten nach dem Go-live.
Warnung für alle Website-Betreiber: Niemand wusste, dass diese 21 Websites existieren. Kein Link, keine Suchmaschine, kein Besucher. Trotzdem wurden alle 21 angegriffen, jede etwa 17 Mal an einem Nachmittag. Ihre Website bekommt denselben Verkehr ab dem Tag, an dem sie online geht. Schützen Sie wp-login.php, xmlrpc.php und die REST API am Tag der Installation.
Keine der 21 Domains war verlinkt, bei einer Suchmaschine eingereicht oder irgendwo erwähnt. Die einzige öffentliche Spur war ein frisch ausgestelltes TLS-Zertifikat. Wenn Sie denselben Verkehr auf Ihrem eigenen Server beobachten möchten, folgen Sie der Anleitung zum Honeypot Server.
Wie schnell finden Angreifer eine neue WordPress-Website?
Die Angreifer fanden die neuen Websites innerhalb von 15 Minuten. Die Flotte ging zwischen 12:30 und 12:45 UTC online, und die erste Erkennung auf einem der neuen Hosts wurde um 12:49:57 UTC protokolliert. In der Stunde ab 13:00 UTC folgte eine erste Welle. Die stärkste Stunde des Tages war die ab 16:00 UTC mit 150 Angriffen.
Woher wusste überhaupt jemand, dass es die Hosts gibt? Jedes von Let’s Encrypt ausgestellte Zertifikat erscheint binnen Sekunden in öffentlichen Certificate-Transparency-Logs. Scanner abonnieren diese Log-Feeds und prüfen jeden neuen Hostnamen, sobald er auftaucht. Das ist hier der wahrscheinlichste Weg: keine Backlinks, kein Sitemap-Ping, kein Crawler-Besuch vor der Ausstellung des Zertifikats und ein vollständiger Scan 15 Minuten später.
Wie sehen 356 Angriffe auf eine neue WordPress-Website aus?
Alle Zahlen beziehen sich auf den 6. September 2026, 00:00 bis 19:30 UTC, über alle 21 Hosts. Zwanzig Hosts gingen am Mittag online; einer lief schon seit Monaten und kam an diesem Tag zur Flotte hinzu. Die IPs unseres eigenen Monitorings und Setups sind herausgerechnet.
| Pfad | Treffer | Worauf die Anfrage zielt |
|---|---|---|
/?rest_route=/batch/v1 | 64 | REST-Batch-Exploit wp2shell (CVE-2026-63030) |
/xmlrpc.php | 28 | XML-RPC-Missbrauch und Multicall-Loginversuche |
/author/admin/ | 23 | Ermittlung von Benutzernamen |
/wp-login.php?action=lostpassword | 22 | Missbrauch der Passwort-Zurücksetzung |
/wp-config.php.bak | 15 | Sicherungskopie der WordPress-Konfiguration |
/.git/config | 11 | Offen liegendes Git-Repository |
/wp-content/debug.log | 11 | Debug-Log mit Pfaden und Stacktraces |
Die Umgebungsdatei /.env wurde mehr als 40 Mal abgerufen, und drei Varianten (.env.local, .env.example, .env.production) kamen auf weitere 10 Treffer. Die Zahlen stammen aus den Logs der Honeypots selbst. Die zentrale ReportedIP-Datenbank zeigt denselben Tag als 116 Reports von 76 Adressen, weil wiederholte Treffer einer Adresse innerhalb eines kurzen Zeitfensters zu einem Report zusammengefasst werden.
Zum Vergleich: Unser erster Honeypot meldet seit Ende Februar 2026 und hatte bis zum Wechsel in die Flotte 36.206 Reports geschickt. Die Quartalszahlen für das gesamte Netzwerk stehen im WordPress-Angriffsbericht.
Warum ist wp2shell der häufigste Angriff auf neue WordPress-Websites?
Der REST-Batch-Exploit hinter wp2shell war die häufigste einzelne Erkennung: 69 Erkennungen in sieben Stunden, auf Hosts, die noch keinen Tag existierten. WordPress hat die Lücke am 17. Juli 2026 geschlossen, und Scanner probieren sie trotzdem auf jeder neuen Website aus, die sie finden. Sie lag vor dem klassischen .env-Abruf, XML-RPC-Missbrauch (27 Erkennungen) und Brute Force auf wp-login (24). Die Angriffskette und die Firewall-Regeln dagegen beschreibt der Beitrag zu wp2shell.
Nach ReportedIP-Bedrohungskategorien verteilt sich der Tag so:
- WP REST API Abuse + WP Core Exploit (34, 37): 58 Reports
- Port Scan + Hacking + WP Config Exposure (14, 15, 58): 53 Reports
- Port Scan + Hacking (14, 15): 30 Reports
- Brute-Force + WP Login Brute Force (18, 31): 24 Reports
- Bad Web Bot (Kategorie 19): Scanner, die an ihrem User-Agent erkannt wurden
Wie viele Websites trifft ein einzelner Scanner?
33 der 84 Angreifer-IPs (39 Prozent) trafen mehr als einen Host. Eine Adresse, 157.143.67.218, erreichte 20 der 21 Hosts. 130.12.180.117 deckte 17 Hosts ab, und drei Adressen aus einem OVH-Netz (158.69.55.148, 158.69.117.45, 158.69.55.82) kamen zusammen auf 46 Treffer.
- 51 IPs trafen genau einen Host
- 15 IPs trafen zwei Hosts
- 7 IPs trafen drei Hosts
- 11 IPs trafen zwischen 4 und 20 Hosts
Eine einzelne Website sieht einen Zugriff und kann eine verirrte Anfrage nicht von einer Kampagne unterscheiden. Viele Websites, die dieselbe Adresse innerhalb weniger Minuten sehen, können es. Im gesamten Netzwerk belohnt der Confidence Score genau das: Eine Adresse, die mehrere unabhängige Melder gemeldet haben, steigt schneller als eine, die eine einzige Quelle oft gemeldet hat.
Wie entlarvt eine Spider Trap scannende Bots?
Eine Spider Trap ist eine Köderadresse, die ein Mensch nie sieht und ein anständiger Crawler nie abruft. Dort landet nur ein Bot, der jeden Link aus dem HTML zieht und allen folgt. Am ersten Tag passierte das 16 Mal, und jeder Treffer ging mit der Kategorie Spider Trap hinaus. Hive nutzt dasselbe Prinzip auf produktiven Websites mit Köderpfaden.
Die User-Agents bestätigen das Bild. 192 Anfragen trugen einen gekürzten, gefälschten Chrome-String (Windows NT 10.0 ohne Chrome-Token), die größte einzelne Scanner-Flotte des Tages. 28 kamen von einem Android-Nexus-5-String (ein Smartphone von 2013), 5 von l9scan (leakix.net). 32 Anfragen trugen ClaudeBot/1.0, einen KI-Crawler, der Links zu xmlrpc.php und zur Login-Seite folgte und dieselben Analyzer auslöste wie ein Scanner.
Was bedeutet das für Ihre eigene WordPress-Website?
Die 21 Honeypots sind gewöhnliche WordPress-Frontends hinter gewöhnlichen Domains. Nichts an ihnen hat die Scanner angelockt außer ihrer Erreichbarkeit. Scanner, die die Zertifikats-Logs lesen, behandeln Ihre Website genauso. Drei Konsequenzen:
- Sichern Sie die Website, bevor sie Besucher hat. Die Angriffe beginnen vor dem ersten Besucher. Login, XML-RPC und der REST-Batch-Endpunkt brauchen Schutz ab dem Tag der Installation.
- Sperren Sie bekannte Angreifer anhand ihrer Reputation. 39 Prozent der Angreifer-IPs trafen mehrere Hosts. Eine Adresse, die andere Websites schon gemeldet haben, lässt sich sperren, bevor sie Ihr Login-Formular erreicht. ReportedIP Hive erledigt das mit den Community-Daten.
- Setzen Sie Ihr eigenes Monitoring auf die Whitelist. Ein Uptime-Check per curl sieht genauso aus wie ein Scanner. Tragen Sie seine IPs ein, bevor er läuft, sonst melden Sie sich selbst.
Wie betreiben Sie Ihren eigenen WordPress-Honeypot?
Alle 21 Hosts laufen mit dem ReportedIP Honeypot Server, am Tag der Messung in Version 1.3.10; aktuell ist Version 1.4.1. Er ist eine eigenständige PHP-Anwendung, die eine WordPress-, Drupal- oder Joomla-Installation nachbildet. Er braucht PHP 8.2 mit pdo_sqlite und curl, hat keine Composer-Abhängigkeiten, speichert alles in SQLite und bringt ein Dockerfile mit. Der Quellcode ist unter der Business Source License 1.1 einsehbar: Der produktive Einsatz ist erlaubt, solange Sie ihn nicht verkaufen oder als gehosteten Dienst für andere betreiben, und am 1. März 2030 wechselt die Lizenz auf Apache 2.0.
- 40 Threat Analyzers für SQL-Injection, Path Traversal, Brute Force, Credential Stuffing, XML-RPC-Missbrauch, Plugin-Exploits, Zugriffe auf Konfigurationsdateien, Webshell-Proben und den REST-Batch-Exploit wp2shell
- Honeytokens: gefälschte Konfigurationslecks enthalten Köder-Zugangsdaten je IP; wer eines davon benutzt, ist nachweislich bösartig
- Fallen: eine Spider Trap, ein Tarpit für Blind-SQLi und ein falscher Admin-Bereich, der hochgeladene Plugin-Payloads aufzeichnet
- Automatische Meldung an die ReportedIP-API mit Rate Limiting und exponentiellem Backoff, dazu Webhooks für Ihr SIEM, Slack oder AbuseIPDB
- Admin-Dashboard für Angriffe, Payloads, ausgelöste Honeytokens und Whitelists
Für die Meldungen brauchen Sie einen Community Access Key. Jedes ReportedIP-Konto enthält einen: kostenloses Konto anlegen, dann den Key aus Ihrem Dashboard kopieren. Ein Detail der Einrichtung zählt mehr als alle anderen: Leiten Sie jede Anfrage, auch Dotfiles und robots.txt, an public/index.php weiter. Verwaltete Hosting-Panels beantworten /.env oft mit einem 403 des Webservers, und dann lösen die Fallen nie aus.
Honeypot-Reports fließen in denselben Datenbestand wie die Reports von Hive-geschützten Websites: den Confidence Score je IP und die Dynamic Blacklist, die Hive-Installationen, fail2ban und Firewalls beziehen.
Häufige Fragen
Wie haben Scanner Domains gefunden, die nie veröffentlicht wurden?
Die Scanner haben sie höchstwahrscheinlich über Certificate-Transparency-Logs gefunden. Jedes öffentlich vertrauenswürdige TLS-Zertifikat wird dort protokolliert, und die Logs lassen sich in Echtzeit mitlesen. Ein neuer Hostname mit frischem Zertifikat ist für jeden sichtbar, der den Feed beobachtet; deshalb kam der erste Zugriff 15 Minuten nach dem Go-live.
Ist eine Anfrage nach /.env auf meiner WordPress-Website ein Angriff?
Eine Anfrage nach /.env ist immer feindlich. Kein Browser, kein Plugin und keine Suchmaschine hat einen Grund, diese Datei abzurufen. Am 6. September 2026 wurde sie in der Flotte mehr als 40 Mal abgerufen, dazu 10 Mal in Varianten. Sorgen Sie dafür, dass Ihr Webserver dafür nichts Brauchbares ausliefert.
Meldet der Honeypot meine eigenen Uptime-Checks?
Der Honeypot meldet Ihre Uptime-Checks, solange Sie sie nicht auf die Whitelist setzen. Tragen Sie die IPv4- und IPv6-Adressen Ihrer Monitoring- und Admin-Systeme bei der Installation ein, bevor der erste Statuscheck läuft. Ein Uptime-Check per curl sieht für die Analyzer wie ein Scanner aus und wird wie einer gemeldet.