29. Mai 2026, 17:04 Uhr. Zwei IP-Adressen von der Elfenbeinküste haben sich mit dem Multify-Proxyserver verbunden. In den nächsten 90 Sekunden haben sie fast 100 URLs durchsucht und 100 Ablehnungen erhalten.
Dies ist die typische Arbeitsweise eines Schwachstellenscanners. Kein gezielter Hack, sondern eine automatische Aufklärung. Solche Scanner arbeiten ununterbrochen und durchsuchen Millionen von Websites auf der Suche nach einem: einer offenen Datei mit Schlüsseln, Passwörtern oder Konfigurationen oder einer bekannten Schwachstelle in einem CMS. Es spielt keine Rolle, worauf die Website basiert – WordPress, Drupal, Joomla oder eine selbst entwickelte Engine. Der Scanner prüft alles systematisch nach einem Standardwörterbuch.
Multify als Reverse-Proxy übernimmt den gesamten eingehenden Traffic. Der Scanner klopft an die Multify-Infrastruktur und nicht direkt an die Kundenwebsite. Der Schutz des Proxys ist somit der Schutz der Kundenwebsites.
Was der Scanner sucht
Hier ist eine Liste aus einem echten Log:
`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``
Dies ist keine zufällige Sammlung, sondern ein Standardwörterbuch, das aus realen Lecks zusammengestellt wurde. Jede Datei in dieser Liste wurde irgendwann einmal auf einem Produktionsserver im offenen Zugriff gefunden.
Was genau gesucht wird
Umgebungsvariablen – .env-Dateien und ihre Varianten. Darin speichern Entwickler API-Schlüssel, Datenbankpasswörter, Token von Zahlungssystemen. Eine solche Datei verschafft einem Angreifer vollen Zugriff auf die Infrastruktur ohne Spuren eines Einbruchs. Laut GitGuardian wurden im Jahr 2024 über 12 Millionen Geheimnisse in öffentlichen Repositories entdeckt, wobei .env zu den drei häufigsten gehörte. Der Entwickler fügt die Datei zu .gitignore hinzu, aber auf dem Server bleibt sie nach dem Deployment im öffentlichen Verzeichnis, und niemand überprüft sie.
CMS- und Framework-Konfigurationen – wp-config.php (WordPress), Joomla-, Drupal-, Laravel-, Symfony-, Rails-Konfigurationen. Der Scanner weiß nicht, womit die Website erstellt wurde, daher prüft er alle gängigen Optionen nacheinander.
Cloud-Schlüssel – gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. Ein Treffer bedeutet Zugriff auf das Cloud-Konto mit allen Daten und potenziellen Rechnungen in Höhe von Zehntausenden von Dollar.
Verschlüsselungsschlüssel – private.key, server.key, rails/master.key. Ein offener privater Schlüssel ermöglicht die Entschlüsselung des gesamten Datenverkehrs oder die Fälschung von Signaturen.
Logs und Dumps – error.log, debug.log, database.sql, dump.sql. Logs enthalten oft Benutzerdaten, Dateipfade, manchmal Passwörter im Klartext.
Infrastrukturkonfigurationen – nginx.conf, docker-compose.yml, web.config. Daraus lässt sich die interne Netzwerktopologie ableiten und der nächste Einstiegspunkt finden.
CMS-Schwachstellen – eine separate Kategorie. Sobald ein neues CVE veröffentlicht wird, beginnen Scanner, alle Websites nacheinander zu überprüfen, oft innerhalb weniger Stunden. Laut Google Project Zero beträgt der Median von der Veröffentlichung eines CVE bis zu den ersten Angriffen 15 Tage, aber bei Schwachstellen mit einem öffentlichen PoC verkürzt sich diese Zeit auf wenige Stunden. Ein Beispiel, das derzeit aktiv ausgenutzt wird: CVE-2026-9082, eine SQL-Injection in Drupal Core auf PostgreSQL (Versionen 8.0 bis 11.3.9). Die Schwachstelle liegt darin, wie Drupal SQL-Abfragen über JSON:API erstellt: Der Angreifer übergibt im Filterparameter einen Array-Schlüssel mit eingebettetem SQL, Drupal fügt ihn ohne Bereinigung in die Abfrage ein. Ohne Autorisierung, über eine normale HTTP-Anfrage. Ergebnis: Datenbank-Dump, Erstellung eines Admin-Kontos, in einigen Konfigurationen Ausführung von beliebigem Code. CVSS 9.8, kritisch (zum Vergleich: Log4Shell, der 2021 die Hälfte des Internets lahmlegte, erhielt 10.0). Der Patch wurde am 20. Mai veröffentlicht, ein funktionierender PoC erschien weniger als eine Stunde später auf GitHub. Am 22. Mai wurde die Schwachstelle in den CISA Known Exploited Vulnerabilities-Katalog aufgenommen. In den ersten 48 Stunden wurden über 15.000 Ausnutzungsversuche auf fast 6.000 Websites in 65 Ländern registriert.
Der Angriff vom 29. Mai war genau so. Die WAF reagierte auf die OWASP CRS-Signaturen, CrowdSec fügte beide IPs zur Liste der blockierten hinzu. Der Kunde erfuhr nichts davon.
Der Scanner durchlief alle Kategorien sofort, in 90 Sekunden.
Zwei IPs – ein Scanner
Der Scanner startete gleichzeitig von zwei Adressen. Moderne Scanner verteilen die Last auf mehrere IPs, um unter der Schwelle einfacher Rate-Limit-Regeln zu bleiben. Wenn der Schutz auf „mehr als 10 Anfragen pro Minute von einer IP“ reagiert, macht der Scanner einfach 5 von jeder. Dabei haben die IPs selbst meist nichts mit dem tatsächlichen Angreifer zu tun – es sind gemietete VPS, gehackte Server oder Botnet-Maschinen weltweit. Die Elfenbeinküste ist hier eine zufällige Geografie und nicht der Ort, von dem aus eine Person tatsächlich arbeitet.
Ein interessantes Detail aus dem Log: Die erste Anfrage der zweiten IP lieferte 200 – der Scanner überprüfte zuerst die Startseite, vergewisserte sich, dass die Website aktiv war, und begann erst dann mit dem Brute-Force-Angriff. Dies ist ein Zeichen für ein Tool und keinen zufälligen Traffic.
Wie der Proxy einen Angriff blockiert
WAF
Ein WAF (Web Application Firewall) ist eine Firewall auf Anwendungsebene. Im Gegensatz zu einer Netzwerk-Firewall, die auf IPs und Ports achtet, liest ein WAF den Inhalt einer HTTP-Anfrage: URL, Header, Body. Er analysiert jede Anfrage, bevor sie die Website erreicht.
Die Grundlage der Regeln ist das OWASP Core Rule Set (CRS), ein offener Satz von Angriffssignaturen, der von der gemeinnützigen OWASP-Stiftung unterstützt wird. CRS deckt Konfigurationsdateien-Bruteforce, SQL-Injections, XSS und andere gängige Angriffsvektoren ab. Anfragen an .env, .sql, .key, wp-config.php und Dutzende anderer Erweiterungen werden sofort blockiert. Der WAF weiß nicht, ob die Datei auf dem Server existiert – er blockiert anhand des Anfragenamens, und der Scanner erhält eine Ablehnung, bevor er überhaupt etwas erfahren kann.
CrowdSec
CrowdSec ist eine offene Engine für Verhaltensanalysen. Der WAF arbeitet mit jeder Anfrage einzeln, CrowdSec betrachtet die Sequenz: Was genau fragt diese IP in den letzten Minuten an.
Eine einzelne Anfrage an .env könnte ein Fehler im Link sein. Zehn Anfragen an .env, .env.production, .env.local, .envrc innerhalb von 30 Sekunden – das ist kein normaler Benutzer mehr. CrowdSec erkennt dieses Muster anhand von Szenarien (Verhaltensregeln) und blockiert die IP. Blockierte Adressen gelangen in eine gemeinsame Bedrohungsdatenbank, die von Tausenden von Servern weltweit genutzt wird. Ein auf einer Website entdeckter Scanner wird sofort überall zu einem unerwünschten Gast.
Angriff in Zahlen
Der Scanner hat das Standardwörterbuch in anderthalb Minuten abgearbeitet und ist mit leeren Händen gegangen. Die Website des Kunden hat keine einzige bösartige Anfrage erhalten.
Warum das genau so funktioniert
Wenn eine Website mit Multify verbunden wird, läuft der gesamte eingehende Traffic über einen Proxy. Der Kunde hat Multify zur Lokalisierung und nicht zum Schutz angeschlossen. Da der Proxy jedoch vor der Website steht, erstreckt sich der gesamte Schutz der Multify-Infrastruktur automatisch auf sie.
Lecks durch offene Dateien sind einer der häufigsten Angriffsvektoren. Sie entstehen nicht durch komplexe Exploits, sondern durch banale Fehler: Der Entwickler hat das Projekt bereitgestellt und vergessen, .env zu entfernen. Er hat einen Test-Datenbank-Dump in einen öffentlichen Ordner gelegt. Er hat eine Konfigurationsdatei mit Passwörtern auf dem Server gelassen. Scanner finden solche Dateien innerhalb weniger Stunden, lange bevor jemand aus dem Team den Fehler bemerkt.
Häufig gestellte Fragen
Schützt Multify vor CVE-2026-9082?
Wenn die Website des Kunden auf Drupal mit PostgreSQL läuft, blockiert die WAF auf Proxy-Ebene charakteristische Anfragemuster: komplexe Filterparameter für /jsonapi, Anfragen an /user/login?_format=json mit nicht standardmäßigen Bodies. Der Scanner erreicht die Website nicht. Dies ist jedoch kein Ersatz für einen Patch: Wenn die Website direkt unter Umgehung des Proxys zugänglich ist, gibt es keinen Schutz.
Warum zwei IPs und nicht eine?
Moderne Scanner verteilen Anfragen auf mehrere Adressen, um unter der Schwelle einfacher Rate-Limit-Regeln zu bleiben. CrowdSec achtet auf das Verhalten und nicht auf die Anzahl der Anfragen von einer IP, daher ist diese Technik nicht hilfreich.
Hat der Scanner etwas über die Website des Kunden erfahren?
Nein. Die WAF blockiert Anfragen anhand des Pfadnamens, bevor sie die Anwendung erreichen. Der Scanner weiß nicht, ob die Datei auf dem Server existiert – er erhält eine Ablehnung auf Proxy-Ebene.
Was ist, wenn der Angriff kein Scanner, sondern ein gezielter Einbruch ist?
Ein gezielter Angriff ist komplexer: Der Angreifer kennt das Ziel, verwendet nicht standardmäßige Vektoren und arbeitet langsam, um nicht in Verhaltensmuster zu geraten. WAF und CrowdSec reduzieren die Angriffsfläche, bieten aber keine hundertprozentige Garantie. Für kritische Websites sind Penetrationstests und Anomalieüberwachung erforderlich.
Ist die Elfenbeinküste wichtig?
Nein. Die Geolokalisierung der Scanner-IP ist die Geolokalisierung des verwendeten Computers, nicht die des Angreifers. Eine Blockierung nach Land ist sinnlos: Der nächste Angriff kommt aus Brasilien, den Niederlanden oder Russland.