wp2shell, ein falscher Chrome und ein Botnet im Trenchcoat: Was meine eigenen Access-Logs über mich ausplaudern

🌐 Auch auf: English · Français · Español

Vor ein paar Tagen machte „wp2shell“ die Runde – eine RCE-Kette in WordPress ohne Authentifizierung, zusammengebastelt aus einer SQL-Injection (CVE-2026-60137) und einem Validierungs-Bypass im REST-Batch-Endpunkt (CVE-2026-63030). 🩸 Jedes WordPress ≥6.8 war betroffen, upstream hat es schließlich in 7.0.2 gefixt. Ein paar Tage lang zum Nägelkauen lief genau dieses Blog mit einem Notfall-Block in nginx auf /wp-json/batch/v1, weil das gepatchte Docker-Image sich schlicht weigerte, schon zu existieren. Klassiker. 🙃 Also tat ich, als das Feuer gelöscht war, natürlich das, was jeder Homelab-Nerd mit etwas Selbstachtung um 2 Uhr nachts tut: Ich bin auf Höhlenexpedition durch meine eigenen Ingress-Logs gegangen. 🕵️‍♂️ Ergebnis: Dem Internet ist es egal, dass du gepatcht hast. Das Internet klopft trotzdem weiter an.

Table of Contents

🔍 Beweisstücke aus dem Access-Log

Beim ersten Durchgang dachte ich, ich hätte eine überschaubare Handvoll Treffer. Dann bin ich mit einem besseren grep noch mal ran (die schlichten Access-Log-Zeilen von nginx wiederholen den Hostnamen nämlich nicht, also hat mein erster Domain-Filter still und leise echte Treffer verschluckt – auch Homelab-Nerds haben mal schlechte Tage 🤦) und musste feststellen: Das war deutlich mehr als eine Handvoll.

🌊 Die erste Flut, 18.–19. Juli – am Tag der Veröffentlichung der CVE leuchteten meine Logs mit Dutzenden Treffern auf, fast alle vom selben herrlich unauffälligen User-Agent, wp2shell.com scanner, der durch eine kleine Armee von IPs hinter Cloudflare rotierte und meist mit 207 landete (verarbeitet, vor der Abwehr). Im Grunde die Sicherheitsforscher des Internets (oder „Forscher“ 🧐), die in dem Moment, als die Lücke öffentlich wurde, eine synchrone Ehrenrunde drehten.
😂 Zugabe vom selben Scanner-UA am 20. Juli: 403, geblockt von meiner Notfallregel. 💪 Und noch mal am 21. Juli, als die Regel zufällig kurz aus war: 207, glatt durchgerauscht. 🎯 (Die eigentliche CVE war zu dem Zeitpunkt schon gepatcht, also – eine Enttäuschung für uns beide.)
🕵️ Mein persönlicher Favorit: eine EC2-Kiste in AWS Tokio (ec2-*.ap-northeast-1.compute.amazonaws.com, ja, ich habe den Reverse-DNS-Lookup gemacht, ja, ich kam mir sehr schlau vor), die einen gefälschten Chrome-User-Agent trug wie ein billiges Halloween-Kostüm. 🎭 Sie rief / auf, wartete exakt eine (1) Sekunde und ging dann direkt auf den Exploit-Endpunkt los. Kein CSS. Kein JS. Kein Favicon. So surft kein Mensch – ein echter Chrome lädt pro Seitenaufruf Assets im Umfang eines kleinen Romans. Netter Versuch, Roboter. 🤖
🆕 Update, während ich diesen Beitrag noch schrieb: ein frischer Besucher aus der Google Cloud (*.bc.googleusercontent.com), zwei Requests, eine Sekunde auseinander, beide 207 – und dieser hat sich sogar die Mühe gemacht, sich mit einem eigenen Tracking-Parameter zu markieren, &_w2s=347b2f52 / &_w2s=b58fad1b. Irgendjemandes Scan-Tool nummeriert seine Versuche jetzt offenbar selbst durch. Effizienz! 📊 Damit schon der dritte große Cloud-Anbieter (hinter Cloudflare, AWS, jetzt GCP) – das Ding hat überall Freunde.

🤔 Schön und gut, aber wer macht so was eigentlich?

Berechtigte Frage, und es lohnt sich, sie für alle auszubuchstabieren, die nicht zum Spaß auf Server-Logs starren: Nicht jeder, der an einer bekannten Lücke herumstochert, ist ein Krimineller. Es gibt hier ein echtes Spektrum, und die Indizien sind wichtig. 🔬

😇 Das gutgläubige Ende: Sicherheitsforschungsfirmen und Scan-Dienste (denk an Shodan, Censys, Projekte im Stil von GreyNoise) durchkämmen ständig das Internet nach bekannten CVEs – mal, um öffentliche Threat-Intel-Feeds aufzubauen, mal, damit betroffene Seitenbetreiber sich selbst nachschlagen und „oh nein“ sagen können. Ein Tool, das sich in seinem eigenen User-Agent wörtlich wp2shell.com scanner nennt, passt gut in dieses Profil: Es hat keinen Grund, sich zu verstecken, und laut zu sagen, wer man ist, ist genau das, was legitime Scanner tun (und oft das, was die Normen für Responsible Disclosure erwarten).
😈 Das bösgläubige Ende: Angreifer, die genau dieselbe Art von Prüfung laufen lassen, nur dass das Ziel nicht „jemandem Bescheid sagen“ ist, sondern „eine Tür finden, durch die ich noch durchkomme“ – um eine Webshell, einen Spam-Injektor oder einen Cryptominer abzulegen oder die Kiste einfach einem Botnet hinzuzufügen. Das sind die, die jeden Anreiz haben, nicht aufzufallen.

Genau deshalb zeige ich immer wieder auf die Fälle mit dem gefälschten Chrome-User-Agent (den aus AWS Tokio, den aus der GCP) als die interessanteren: Ein ehrlicher Scanner muss sich nicht als Browser eines ganz normalen Besuchers verkleiden. Etwas, das sich als Mensch ausgibt, gerade um nicht wie ein Scanner auszusehen, hat einen Grund, sich zu verstecken – und „ich habe gute Absichten“ ist es meistens nicht. 🎭 Ehrliche Zusammenfassung für Laien also: Das ist mit ziemlicher Sicherheit eine Mischung aus beidem, und aus einem Access-Log allein kann ich keine Absicht beweisen – eine 207-Antwort sagt mir, dass der Endpunkt geantwortet hat, nicht, was jemand damit vorhatte. Aber der Scanner, der sich selbst ankündigt, ist wahrscheinlich näher an „Hintergrundstrahlung des Internets / Security-Tooling“, während die verkleideten am ehesten das sind, was ich als „jemand, der wirklich hofft reinzukommen“ bezeichnen würde. Da der zugrunde liegende WordPress-Bug so oder so gepatcht ist, ist hier keines der beiden Lager weit gekommen – aber das Muster selbst sollte man kennen. 🛡️ Volle Transparenz für die Nerds, die zu Hause mitzählen: Meine eigenen curl-Tests – die, mit denen ich geprüft habe, ob der Block wirklich greift – stehen in genau derselben Logdatei, und zwar mehrfach, weil ich anscheinend nicht nur einmal nachsehen konnte. 😅 Technisch gesehen bin ich also auch „eine IP-Adresse, die den verwundbaren Endpunkt abklopft“. Schuldig im Sinne der Anklage, Euer Ehren. 👨‍⚖️ Übrigens nicht nur meine Paranoia: Golem.de hat über genau diese Welle laufender Angriffsversuche ebenfalls berichtet – „Lücken in WordPress: Laufende Schadcode-Attacken gefährden Millionen von Websites“ – das ist also keine isolierte Verschwörungstheorie eines Homelab-Blogs. 📰 Es ist wirklich ein Phänomen, das das ganze Internet betrifft.

🕸️ Bonusrunde: Die Scraper im Trenchcoat

Während ich unten im Log-Bergwerk nach wp2shell suchte, bin ich über etwas viel Größeres und ehrlich gesagt Interessanteres gestolpert: 765 verschiedene IP-Adressen, verteilt auf mindestens 530 verschiedene /16-Netzblöcke (also: überall, nicht ein Rechenzentrum), die jeweils auftauchten, um genau einen oder zwei Requests zu stellen, und dann für immer verschwanden. 👻 Jede einzelne davon präsentierte einen völlig normal aussehenden Desktop-Browser-UA – Chrome oder Edge, Windows oder Mac, das volle Programm. Nichts, was dir auf den ersten Blick auffallen würde. Aber stellst du sie alle nebeneinander, fällt die Maske sofort: Sie riefen ausschließlich meine rund 31 Tag-, Kategorie- und Datumsarchivseiten auf (/tag/ansible, /category/devsecops, /2025/05 und so weiter) und arbeiteten die Liste methodisch ab – und keine einzige hat danach auch nur eine CSS-Datei, JS-Datei oder ein Bild geladen. 🖼️🚫 Ein echter Chrome-Tab lädt pro Seitenaufruf zwei Dutzend Assets, ohne dass du einen Finger rührst. Diese haben kein einziges geladen. Das ist die Handschrift eines Scraping-Botnets über Residential Proxys: Statt die Seite von einer IP aus zu bombardieren (womit du in etwa vier Sekunden gedrosselt oder gebannt bist), mietest du ein paar hunderttausend echte Privatanschluss-IPs und schickst von jeder genau einen höflichen, ganz-bestimmt-ein-echter-Mensch-ehrlich-Request. Tod durch tausend Papierschnitte, nur dass die Papierschnitte von echten Lesern nicht zu unterscheiden sind, solange du nicht weit genug herauszoomst, um das Muster zu sehen. 🔎 Angesichts des Ziels (systematisch jede Archivseite abklappern, also den kompletten Inhaltsindex der Seite, nicht nur die Startseite) tippe ich auf großflächiges Content-Scraping – kann guter alter SEO-Content-Diebstahl sein, kann jemand sein, der einen KI-Trainingsdatensatz aufbaut. So oder so: 765 „Besucher“, die null Wörter gelesen und null Schriftarten geladen haben, waren nie Besucher. 🤖🕶️

🎬 Fazit

Das eigentliche Loch ist schon eine Weile gestopft (hier läuft 7.0.2, seit das überhaupt möglich war). Aber das Scannen nach einer frisch angekündigten CVE hört nicht auf, nur weil irgendwer irgendwo einen Fix ausgeliefert hat. 📡 Die Scan-Bots lesen keine Changelogs. Wenn du ein öffentlich erreichbares WordPress betreibst, ist diese Art von Traffic einfach Hintergrundstrahlung – ein guter Anlass, tatsächlich ab und zu einen Blick in deine Access-Logs zu werfen, statt anzunehmen: „gepatcht == erledigt“. 🛡️