Threat Intelligence

WordPress-Seiten werden angegriffen, nur weil sie online sind: 422 Angriffe in 7 Stunden

6. September 2026 · Patrick Schlesinger

Eine WordPress-Website benötigt weder Besucher, Inhalte noch Backlinks, um angegriffen zu werden. Es reicht bereits aus, dass sie existiert. Am 6. September 2026 haben wir 21 leere WordPress-Honeypots online gestellt; innerhalb von sieben Stunden wurden sie 422 Mal von 85 IP-Adressen angegriffen, wobei der erste Angriff bereits 15 Minuten nach der Inbetriebnahme erfolgte.

Keine der 21 Domains war verlinkt, bei einer Suchmaschine angemeldet oder irgendwo erwähnt worden. Die einzige öffentliche Spur war ein frisch ausgestelltes TLS-Zertifikat. Um dies auf Ihrem eigenen Server zu beobachten, befolgen Sie die Anleitung zur Einrichtung des Honeypot Server; eine Instanz ist in etwa zehn Minuten betriebsbereit.

Wie schnell entdecken Angreifer eine neue WordPress-Website?

Die Flotte wurde zwischen 12:30 und 12:45 UTC in Betrieb genommen. Die erste Erkennung auf einem brandneuen Host (web00) wurde um 12:49:57 UTC protokolliert. Innerhalb der Stunde um 13:00 Uhr UTC verzeichneten die 21 Hosts 120 Angriffe, die größte Angriffswelle des Tages, bis in der Stunde um 16:00 Uhr UTC ein zweiter Spitzenwert von 150 Angriffen erreicht wurde.

Woher wusste jemand, dass diese Hosts existierten? Jedes von Let’s Encrypt ausgestellte Zertifikat wird innerhalb von Sekunden in öffentlichen „Certificate Transparency“-Protokollen veröffentlicht. Scanner abonnieren diese Protokoll-Feeds und überprüfen jeden neuen Hostnamen, sobald er erscheint. Dies ist in diesem Fall der wahrscheinlichste Ablauf: keine Backlinks, kein Sitemap-Ping, keine Crawler-Anfrage vor der Ausstellung des Zertifikats und ein vollständiger Scan 15 Minuten später.

So sehen 422 Angriffe auf eine neue WordPress-Website aus

Alle Zahlen beziehen sich auf den Zeitraum vom 6. September 2026, 00:00 Uhr bis 19:30 Uhr UTC, über alle 21 Hosts hinweg. Unsere eigenen Überwachungs-IP-Adressen sind dabei nicht berücksichtigt. Die Anforderungszusammensetzung setzte sich aus 335 GET-, 80 POST-, 4 HEAD- und 3 PROPFIND-Anfragen zusammen.

Pfad	Zugriffe	Worum es bei der Anfrage geht
/	91	Abruf der Startseite durch einen Scanner, gekennzeichnet anhand des User-Agents und des Verhaltens
/?rest_route=/batch/v1	64	wp2shell, CVE-2026-63030, REST-Batch-Exploit
/.env	47	Umgebungsdatei mit Datenbank- und API-Zugangsdaten (sowie 10 Treffer zu .env.local, .env.example, .env.production)
/xmlrpc.php	28	Missbrauch von XML-RPC, Anmeldeversuche mit mehreren Aufrufen
/author/admin/	23	User Enumeration
/wp-login.php?action=lostpassword	22	Missbrauch der Passwortzurücksetzung
/secure-vault-q4m8/	16	Spinnenfalle: ein für Menschen unsichtbarer Link (siehe unten)
/wp-config.php.bak	15	Sicherheitskopie der WordPress-Konfiguration
/.git/config	11	Öffentlich zugängliches Git-Repository
/wp-content/debug.log	11	Debug-Protokoll mit Pfaden und Stack-Traces

„wp2shell“ ist die häufigste Angriffsmethode und liegt damit noch vor dem Abgreifen von .env-Dateien

Die mit Abstand häufigste Erkennung betraf den REST-Batch-Exploit hinter „wp2shell“: 69 Erkennungen innerhalb von sieben Stunden auf Hosts, die seit weniger als einem Tag existierten. Damit liegt eine im Juli bekannt gegebene Kernschwachstelle noch vor den klassischen .env-Abfragen (40 Erkennungen; der Pfad selbst wurde 47 Mal abgefragt), den XML-RPC-Missbrauch (27) und Brute-Force-Angriffe auf „wp-login“ (24). Wir haben die Angriffskette und die Firewall Rules, die sie blockieren, im Bericht zu „wp2shell“ behandelt.

Aufgeschlüsselt nach den Threat Categories von ReportedIP ergibt sich für diesen Tag folgende Aufteilung:

• Bad Web Bot (Kategorie 19): 82 Reports
• WP REST API Abuse + WP Core Exploit (34, 37): 58 Reports
• Port Scan + Hacking + Offenlegung der WP-Konfiguration (14, 15, 58): 53 Reports
• Port Scan + Hacking (14, 15): 30 Reports
• Brute Force + WP Login Brute Force (18, 31): 24 Reports

Ein Scanner, 21 Ziele: Warum die flottenweite Korrelation von Bedeutung ist

34 der 85 IP-Adressen der Angreifer (40 Prozent) griffen mehr als einen Host an. Eine IP-Adresse, 159.69.198.144 aus dem Hetzner-Adressbereich, scannte alle 21 Hosts mit insgesamt 66 Anfragen. Eine zweite IP-Adresse, 157.143.67.218, erreichte 20 von 21 Hosts. Die Adresse 130.12.180.117 deckte 17 Hosts ab, und drei Adressen aus einem OVH-Adressbereich (158.69.55.148, 158.69.117.45, 158.69.55.82) erzielten zusammen 46 Treffer.

• 51 IP-Adressen haben genau einen Host erreicht
• 15 IP-Adressen haben zwei Hosts erreicht
• 7 IP-Adressen haben drei Hosts erreicht
• 12 IP-Adressen haben zwischen 4 und 21 Hosts erreicht

Eine einzelne Website erkennt nur eine Sonde und kann eine vereinzelte Anfrage nicht von einer Kampagne unterscheiden. Einundzwanzig Websites, die innerhalb weniger Minuten dieselbe IP-Adresse erkennen, sind dazu jedoch in der Lage. Der Confidence Score belohnt dies durch den Faktor „Meldungsvielfalt“: Eine Adresse, die von mehreren unabhängigen Quellen gemeldet wird, steigt schneller im Wert als eine, die mehrfach von einer einzigen Quelle gemeldet wird.

Die Spinnenfalle: 16 Aufrufe eines Links, den kein Mensch sehen kann

Jede Startseite eines Honeypots enthält einen Link zu /secure-vault-q4m8/, der mit display:none ausgeblendet ist. Ein Nutzer, der die Seite besucht, sieht ihn niemals. Eine Suchmaschine, die die Seite auswertet, ignoriert ihn. Der einzige Client, der ihn abfragt, ist ein Bot, der alle href aus dem HTML extrahiert und ihnen allen folgt. Dies geschah am ersten Tag 16 Mal, und jeder Zugriff wurde mit der Kategorie „honeytoken“ gemeldet. Der Mechanismus wird im Artikel über „Decoy Paths“ beschrieben.

Die User-Agents bestätigen dies. 192 Anfragen enthielten eine verkürzte, gefälschte Chrome-Zeichenkette (Windows NT 10.0 ohne das Chrome-Token), dies war die größte einzelne Scanner-Flotte des Tages. 66 Anfragen stammten von curl/7.74.0, 28 von einer Android-Nexus-5-Zeichenkette (ein Gerät aus dem Jahr 2015) und 5 von l9scan (leakix.net). 32 Anfragen enthielten ClaudeBot/1.0, die der Bot-Klassifikator eher als KI-Agenten denn als Angreifer einstuft.

Kontext: Ein einzelner Host hat 12.357 Angriffe verzeichnet

Einer der 21 Hosts, „web05“, war bereits seit Anfang September als einzelner Honeypot in Betrieb und verzeichnet bislang 12.357 protokollierte Angriffe. Die übrigen 20 befinden sich am ersten Tag. Wir werden die Zahlen der gesamten Flotte erneut veröffentlichen, sobald diese einen vollen Monat abdecken; die Quartalszahlen finden Sie im WordPress Attack Report.

Was dies für Ihre eigene WordPress-Website bedeutet

Bei den 21 Honeypots handelt es sich um gewöhnliche WordPress-Frontends hinter gewöhnlichen Domains. Nichts an ihnen hat die Scanner auf sich aufmerksam gemacht, außer der Tatsache, dass sie erreichbar waren. Dieselben 85 Adressen, die diese Honeypots abgefragt haben, fragen auch jede andere WordPress-Website ab, die sie in den Zertifikatprotokollen finden, einschließlich Ihrer. Daraus ergeben sich drei Konsequenzen für Ihre eigene Website:

• Sichern Sie die Website, bevor sie Besucher verzeichnet. Die Angriffe beginnen bereits, bevor der erste Besucher eintrifft. Der Login-Bereich, XML-RPC und der REST-Batch-Endpoint müssen bereits am Tag der Installation geschützt werden.
• Sperren Sie anhand der Reputation, nicht aufgrund einzelner Vorfälle. 40 Prozent der IP-Adressen von Angreifern greifen mehrere Hosts an. Eine Adresse, die bereits von anderen Websites gemeldet wurde, kann gesperrt werden, bevor sie Ihr Login-Formular erreicht. Genau das leistet ReportedIP Hive mithilfe der Community-Daten.
• Fügen Sie Ihre eigene Überwachung zur Whitelist hinzu. Eine Verfügbarkeitsprüfung mit „curl“ sieht genau wie ein Scanner aus. Tragen Sie diese IP-Adressen vor dem ersten Lauf ein, andernfalls melden Sie sich selbst.

Betreiben Sie Ihren eigenen Honeypot mit dem ReportedIP Honeypot Server

Alle 21 Hosts betreiben den ReportedIP Honeypot Server 1.3.10, eine eigenständige PHP-Anwendung, die eine WordPress-, Drupal- oder Joomla-Installation emuliert. Sie erfordert PHP 8.2 mit pdo_sqlite und curl, hat keine Composer-Abhängigkeiten, speichert alle Daten in SQLite und wird mit einer Dockerfile-Datei ausgeliefert.

• 39 Threat Analyzers für SQL Injection, Path-Traversal, Brute-Force-Angriffe, Credential Stuffing, XML-RPC-Missbrauch, Plugin-Exploits, Zugriff auf Konfigurationsdateien und Webshell-Tests
• Honeytokens: Die gefälschten .env, .git/config sowie phpMyAdmin-Lecks geben IP-spezifische „Canary“-Anmeldedaten preis; wer diese Zugangsdaten später verwendet, ist eindeutig ein Angreifer
• Spider-Falle und Tarpit: versteckte Links, ein „robots.txt“-Köderpfad, ein Blind-SQLi-Tarpit und ein „sticky“ gefälschter Admin-Bereich, der hochgeladene Plugin-Payloads abfängt
• Automatische Meldung an die ReportedIP API mit Rate Limiting und exponentiellem Backoff sowie Webhooks für Ihr SIEM, Slack oder AbuseIPDB
• Administrations-Dashboard für Angriffe, Payloads, ausgelöste Honeytokens und Whitelists

Für die Meldung benötigen Sie einen Community Access Key. Jedes ReportedIP-Konto enthält einen solchen Schlüssel: Registrieren Sie sich und kopieren Sie anschließend den Schlüssel aus Ihrem Dashboard. Ein Einstellungsdetail ist dabei besonders wichtig: Leiten Sie jede Anfrage, auch Dotfiles und robots.txt, an public/index.php weiter. Verwaltete Hosting-Panels beantworten /.env häufig mit einem 403 direkt vom Webserver, die Falle zur Quellenerkennung löst dann nie aus. curl -s https://your-honeypot/.env sollte die gefälschte Datei zurückgeben, nicht eine Fehlerseite.

Honeypot-Meldungen fließen in denselben Pool ein wie Meldungen von durch Hive geschützten Websites: den Confidence Score pro IP-Adresse und die Dynamic Blacklist, auf die Hive-Installationen, fail2ban und Firewalls zurückgreifen.

Häufig gestellte Fragen

Wie haben die Scanner Domains gefunden, die nie veröffentlicht wurden?

Über die Protokolle von „Certificate Transparency“. Jedes öffentlich vertrauenswürdige TLS-Zertifikat wird dort protokolliert, und die Protokolle sind in Echtzeit durchsuchbar. Ein neuer Hostname mit einem neuen Zertifikat ist für jeden sichtbar, der den Feed verfolgt, weshalb die erste Abfrage bereits 15 Minuten nach der Inbetriebnahme einging.

Stellt eine Anfrage nach der Datei „/.env“ auf meiner WordPress-Website einen Angriff dar?

Ja. Kein Browser, kein Plugin und keine Suchmaschine hat einen Grund, diese Datei abzufragen. Am 6. September war dies mit 47 Zugriffen der dritthäufigste Pfad in der gesamten Flotte, dazu kamen 10 für .env-Varianten. Stellen Sie sicher, dass Ihr Webserver für diesen Pfad nichts Verwertbares zurückgibt.

Wird der Honeypot meine eigenen Verfügbarkeitsprüfungen melden?

Ja, sofern Sie diese nicht auf die Whitelist setzen. Fügen Sie die IPv4- und IPv6-Adressen Ihrer Überwachungs- und Verwaltungssysteme während der Installation zur Whitelist hinzu, bevor die erste Statusprüfung durchgeführt wird. Eine auf „curl“ basierende Verfügbarkeitsprüfung wird von den Analyse-Tools als Scanner interpretiert.

• Anleitung zur Einrichtung eines Honeypot Servers
• Wie der Confidence Score berechnet wird
• Verwenden Sie die Dynamic Blacklist auf Ihrer Firewall
• ReportedIP Honeypot Server auf GitHub