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 Arbeit eines Schwachstellenscanners. Kein gezielter Hack, sondern eine automatische Erkundung. 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 überprüft alles nach einem Standardwörterbuch.
Multify fungiert als Reverse-Proxy und empfängt den gesamten eingehenden Traffic. Der Scanner greift auf die Multify-Infrastruktur zu und nicht direkt auf die Website des Kunden. Der Schutz des Proxys ist 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 auf einem Produktionsserver im öffentlichen Zugriff gefunden.
Was genau gesucht wird
Umgebungsvariablen — .env-Dateien und ihre Varianten. Darin speichern Entwickler API-Schlüssel, Datenbankpasswörter und Token von Zahlungssystemen. Eine solche Datei verschafft einem Angreifer vollen Zugriff auf die Infrastruktur, ohne Spuren eines Einbruchs zu hinterlassen. Laut GitGuardian wurden im Jahr 2024 über 12 Millionen Mal 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-Konfigurationen, Drupal, Laravel-, Symfony-, Rails-Dateien. Der Scanner weiß nicht, womit die Website erstellt wurde, daher überprüft er alle gängigen Varianten 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.
Infrastruktur-Konfigurationen — nginx.conf, docker-compose.yml, web.config. Daraus lässt sich die interne Netzwerktopologie ableiten und der nächste Einstiegspunkt finden.
CMS-Schwachstellen – eine eigene Kategorie. Sobald ein neues CVE veröffentlicht wird, beginnen Scanner, alle Websites zu überprüfen, oft innerhalb weniger Stunden. Laut Google Project Zero beträgt der Median von der CVE-Veröffentlichung bis zu den ersten Angriffen 15 Tage, aber für Schwachstellen mit öffentlichem PoC hat sich diese Zeit auf wenige Stunden verkürzt. Ein Beispiel, das sich derzeit in aktiver Ausnutzung befindet: CVE-2026-9082, SQL-Injection in Drupal Core auf PostgreSQL (Versionen 8.0 bis 11.3.9). Die Schwachstelle liegt in der Art und Weise, wie Drupal SQL-Abfragen über JSON:API erstellt: Ein 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 das halbe Internet 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 Exploitationsversuche auf fast 6.000 Websites in 65 Ländern registriert.
Der Angriff vom 29. Mai war genau so. WAF arbeitete nach OWASP CRS-Signaturen, CrowdSec fügte beide IPs zur Sperrliste hinzu. Der Kunde erfuhr nichts davon.
Der Scanner durchlief alle Kategorien auf einmal, 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 bei „mehr als 10 Anfragen pro Minute von einer IP“ ausgelöst wird, 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 kein Ort, von dem aus eine Person tatsächlich arbeitet.
Ein interessantes Detail aus dem Log: Die erste Anfrage der zweiten IP lieferte 200 zurück – 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 ein Proxy einen Angriff blockiert
WAF
WAF (Web Application Firewall) – eine Firewall auf Anwendungsebene. Im Gegensatz zu einer Netzwerk-Firewall, die auf IPs und Ports achtet, liest eine WAF den Inhalt der HTTP-Anfrage: URL, Header, Body. Sie analysiert jede Anfrage, bevor sie die Website erreicht.
Die Grundlage der Regeln ist 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 Vektoren ab. Anfragen an .env, .sql, .key, wp-config.php und Dutzende anderer Erweiterungen werden sofort blockiert. Die WAF weiß nicht, ob die Datei auf dem Server existiert – sie blockiert anhand des Anfragenamens, und der Scanner erhält eine Ablehnung, bevor er etwas herausfinden kann.
CrowdSec
CrowdSec – eine offene Engine für Verhaltensanalysen. Die WAF arbeitet mit jeder Anfrage einzeln, CrowdSec betrachtet die Sequenz: Was genau fragt diese IP in den letzten Minuten an.
Eine Anfrage an .env kann ein Fehler im Link sein. Zehn Anfragen an .env, .env.production, .env.local, .envrc innerhalb von 30 Sekunden – das ist kein 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 erhielt keine einzige bösartige Anfrage.
Warum das 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 diese.
Lecks durch offene Dateien sind einer der häufigsten Angriffsvektoren. Sie entstehen nicht durch komplexe Exploits, sondern durch banale Fehler: Ein Entwickler hat ein 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 betrachtet das Verhalten und nicht die Anzahl der Anfragen von einer IP, daher ist diese Technik nicht hilfreich.
Hat der Scanner etwas über die Website des Kunden erfahren?
Nein. WAF blockiert Anfragen nach Pfadnamen, 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, wenn der Angriff kein Scanner, sondern ein gezielter Hack ist?
Ein gezielter Angriff ist komplexer: Der Angreifer kennt das Ziel, verwendet unkonventionelle 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-Monitoring erforderlich.
Ist die Elfenbeinküste wichtig?
Nein. Die IP-Geolocation eines Scanners ist die Geolocation der verwendeten Maschine, nicht die des Angreifers. Eine länderspezifische Blockierung ist sinnlos: Der nächste Angriff kommt aus Brasilien, den Niederlanden oder Russland.