Angriffsanalyse: Schwachstellenscanner gegen Multify-Proxy

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 ü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.

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.

Umgebungsvariablen – .env-Dateien und ihre Varianten. Darin speichern Entwickler API-Schlüssel, Datenbankpasswörter, Zahlungssystem-Tokens. Eine solche Datei verschafft einem Angreifer vollen Zugriff auf die Infrastruktur ohne Spuren eines Hacks. Laut GitGuardian wurden im Jahr 2024 über 12 Millionen Mal Geheimnisse in öffentlichen Repositories gefunden, 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 es.

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 prü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 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 für Schwachstellen mit einem öffentlichen PoC hat sich diese Zeit auf wenige Stunden verkürzt. Ein Beispiel, das derzeit aktiv ausgenutzt wird: CVE-2026-9082, 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: 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 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. 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.

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.

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 vom gemeinnützigen OWASP-Fonds unterstützt wird. CRS deckt die Enumeration von Konfigurationsdateien, 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 nach dem Namen der Anfrage, und der Scanner erhält eine Ablehnung, bevor er etwas herausfinden kann.

CrowdSec – eine offene Engine für Verhaltensanalysen. WAF arbeitet mit jeder Anfrage einzeln, CrowdSec betrachtet die Abfolge: 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.

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.

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.

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.

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.

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.

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.

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.