SonicWall SSLVPN: Sicherheitslücken breit ausgenutzt

[English]Die Sicherheitsexperten von Huntress beobachten seit dem 4. Oktober 2025 einen sprunghaften Anstieg von kompromittierten SonicWall SSLVPN-Instanzen. Die Art der Angriffe und die Schnelligkeit, mit der die Angreifer in die Systeme eindringen, lässt die Vermutung zu, dass diesen gültige Anmeldedaten bekannt sind. Ergänzung: Und es gibt eine beunruhigende Leser-Entdeckung, dass die Firewalls wohl "eigenständig" Backups in der Cloud angelegt haben könnten.

Der Cloud-Backup-Vorfall

Kürzlich gab es bei SonicWall einen Sicherheitsvorfall, bei dem Backup-Dateien der Firewall-Konfiguration offengelegt wurden. Unbefugte konnten diese Informationen per Internet einsehen. SonicWall hatte den Vorfall am 17. September 2025 durch den Support-Beitrag MySonicWall Cloud Backup File Incident offen gelegt. Ich hatte im Beitrag MySonicWall Cloud Backup File Incident: Backup der Konfiguration offen gelegt berichtet.

Inzwischen ist bekannt, dass alle Kunden, die MySonicWall Cloud Backup genutzt haben, von diesem Vorfall betroffen sind (siehe MySonicWall Cloud Backup File Incident: Alle Kunden betroffen). Zudem ist bekannt, dass die Ransomware-Gruppe Akira SonicWall VPN-Konto hackt und auch eine MFA-Absicherung umgehen kann (siehe Akira hackt SonicWall VPN-Konten (auch mit MFA-Absicherung)). So viel als Vorbemerkung zu nachfolgenden Abschnitten.

Angriffe auf SonicWall SSLVPN-Instanzen

Sicherheitsanbieter Huntress beobachtet seit dem 4. Oktober 2025 eine Kampagne erfolgreicher Angriffe auf SonicWall SSLVPN-Instanzen, die bis zum 10. Oktober 2025 anhielt. Das geht aus nachfolgendem Tweet vom 11. Oktober 2025 hervor.

Die Angreifer authentifizieren sich schnell über verschiedene Geräte hinweg, wodurch Huntress schließt, dass dabei gültige Anmeldedaten verwendet werden und die Kompromittierung nicht auf Brute-Force-Angriffe zurück geht.

• • Bis zum 10. Oktober 2025 wurden über 100+ SSLVPN-Konten kompromittiert.
  • Es sind 16 Organisationen von diesen erfolgreichen Angriffen betroffen.
  • Die Aktivitäten begannen ab dem 4. Oktober 2025 von der IP: 202.155.8[.]73

Es wurden teilweise passive Zugriffe beobachtet. Weitere Aktivitäten der Aktivitäten umfassten Scans und Zugriff auf Windows-Konten.

Was man tun sollte

Huntress gibt in nachfolgendem Tweet einige Ratschläge, was Administratoren von SonicWall SSLVPN-Instanzen dringend tun sollten. Dazu gehören folgende Maßnahmen:

• • den WAN-/Fernzugriff  zu sperren
  • SSLVPN, HTTP/S, SSH bis zur Zurücksetzung der Anmeldedaten deaktivieren
  • ALLE Anmeldedaten + Geheimnisse zurücksetzen
  • Automatisierungsschlüssel, DNS- und SMTP-Anmeldedaten widerrufen
  • MFA überall durchsetzen

Und vor allem sollten die Log-Dateien auf fremde Aktivitäten untersucht werden. Huntress hat diesen Beitrag zum Thema veröffentlicht. Der Artikel hier greift den Gedanken, dass die Angreifer aus den Backups auf die Zugangsdaten schließen konnten und das nun missbrauchen, ebenfalls auf.

Noch eine Lesermeldung mit einer kruden Beobachtung

Ergänzung: Kurz nach Veröffentlichung des Beitrags hat sich ein Leser per Mail bei mir gemeldet und schrieb: "zu dem Artikel möchte ich noch einen Fakt loswerden, der mir großes Unbehagen bereitet". Einer seiner Kunden ist direkt betroffen (bis hin zur Totalverschlüsselung, heißt es). Was dem Blog-Leser beim Einfallstor, also dem "SonicWall-Backup-Desaster" aufstößt ist folgendes:

Bei SonicWall gibt es eine Anleitung, um das Cloud Backup zu nutzen:  How can I create cloud backup of SonicWall settings? Der Leser schreibt dazu, dass bei den meisten der Kunden, die das Unternehmen betreut, der Schalter zwar auf Aktiv gesetzt war. Es wurde aber nie ein aktives Backup eingerichtet (d.h. die Option Create Backup -> Cloud Backup war niemals benutzt worden). Auch die lokale Web-Oberfläche zeigte bei diesen Kunden kein Backup an.

Ein Blick ins MySonicwall-Portal und Blick auf das Gerät unter dem Reiter Cloud Backups zeigen ein anderes Bild (siehe obigen Screenshot). Dort finden sich erstellte Backups der diversen Geräte. Der Leser schrieb, dass diese Einträge durchweg bei allen Firewalls mit gleichem Datum auftauchen. Danach wurde nichts mehr in der Liste angezeigt.

Für den Leser bzw. dessen Arbeitgeber stellt sich nun uns die Frage, wenn kein Task eingerichtet ist, wie wurden scheinbar zentral alle SonicWall-Instanzen angewiesen, ein Backup zu erstellen und dies in die Cloud zu laden? Der Leser schließt: Es bleibt aktuell ein Gefühl, das noch nicht alles offengelegt ist (wissentlich oder unwissentlich)

Ähnliche Artikel:
MySonicWall Cloud Backup File Incident: Backup der Konfiguration offen gelegt
Akira hackt SonicWall VPN-Konten (auch mit MFA-Absicherung)
SonicWall SMA 100 Firmware-Update um Rootkits zu entfernen
Vorzeitige Beendigung des Supports für SonicWall SMA 100
MySonicWall Cloud Backup File Incident: Alle Kunden betroffen