[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).
Was steckt im Backup?
Ergänzung 2: Ich habe keine Erfahrung, was im Backup abgelegt wird. Aber ich bin auf diesen Kommentar gestoßen, nach dem sich ein Backup auf einer anderen Firewall importieren lässt. Danach könne man sich mit dem "Standard-Passwort" anmelden und die Konfiguration inspizieren. Zudem gibt es vermutlich die Möglichkeit, OTP Seeds und auch Passwörter mit genügend Energie zu extrahieren.
Dann ist mir noch obiger Tweet untergekommen, dass die Konfigurationsdatei mit Base64 encodiert ist. Die Geheimnisse sind aber individuell verschlüsselt, mit AES-256 oder 3DES, je nach SonicWall OS-Version.
Ä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
MVP: 2013 – 2016
Unsere SonicWall zeigt die Cloud-Backups in der lokalen GUI derzeit nicht mehr an – früher waren sie dort sichtbar. Wenn der Schalter auf „Aktiv" gesetzt war, wurden die Cloud-Backups aktiviert.
Ich hoffe, dass alle IT-Kollegen inzwischen die im Backup hinterlegten Credentials neu gemacht haben oder zumindest alle Remote-Zugäng vorübergehend deaktiviert wurden.
Wir haben allen Mitarbeitern (es sind nicht viele, unter 100) zwangsweise ein neues Passwort vergeben und die 2FA neu eingerichtet.
PS: Wenn möglich einschalten, Geo-Blocking hält viel ab …
Warum setzt ihr nicht Securepoint ein?
Die speichern Backups zwar auch in einer Cloud, aber zumindest primär in Deutschland.
Inwiefern schützt ein in Deutschland eingerichteter Cloud-Server vor Hacking des Anbieters im Vergleich zu einem Server in Peru?
Der Ergänzung des Lesers schließe ich mich an. In meinem Fall sehe ich dort ein Backup vom 10. September, obwohl kein Cloud-Backup konfiguriert war, lediglich der Schalter war aktiv.
Bei uns zeigt sich das gleiche Bild. Der Schalter für Cloudbackup war aktiv, aber man sieht auf der Firewall keine Backups. Allerdings existieren in MySonicwall dann doch jede Menge Backups. In einem anderen Forum haben Betroffene berichtet, dass bei ihnen die Backups IN der Firewall erst seit einiger Zeit "verschwunden" wären und nur noch in MySonicwall sichtbar sind. Im ersten Augenblick sieht das dann so aus, als ob das Cloudbackup zwar eingeschaltet ist, aber keine Backups in die Cloud gemacht werden. Mehr als trügerisch..
Der Hammer bei der Sache ist allerdings, dass Sonicwall angeblich am 09.10. alle seine Kunden und Partner informiert hätte, dem ist zumindest bei uns nicht so. Wir haben dazu nichts erhalten. Keine Info, keine Warnung, gar nichts.
"All our customer and partners were made aware of the incident and were also presented with remediation KB articles. An email was sent on 9th October to all registered mysonicwall.com account holders. Please check all folders of the negistered email ID of your NSAxxxx device."
Diese Aussage hört sich danach an, das man zu doof wäre, in seinen Spamfilter zu schauen….aber immerhin sind wir so schlau in unsere Maillogs zu schauen.
Seit dem 08.10. werden unsere Firewalls immerhin im MySonicwall unter Issues gelistet. Wehe dem, der da nicht täglich reinschaut.
Mittlerweile gibt es für mich ein Bild. Als ich gelesen hatte, dass VPN-Konten inkl. MFA missbraucht wurden, kam mir das schon sehr komisch vor. JETZT gibt es auf jeden Fall ein Bild. Sicherlich kann man aus den gestohlenen Configs auch die MFA-Seeds auslesen und voilá…bin ich schon drin ?
Tatsächlich glaube ich aktuell, dass Sonicwall da sehr sparsam und zögerlich mit Informationen umgeht. Ich befürchte der Vorfall ist größer als man zugeben möchte. Ich finde das nicht sehr vertrauenserweckend was da gerade abläuft. Nach den letzten Supporterfahrungen haben wir bereits darüber nachgedacht, den Vendor spätestens mit Auslaufen der Lizenz rauszuwerfen. Jetzt muss ich darüber nicht mehr nachdenken sondern die Entscheidung steht fest. Klar gibt es bei jedem Firewall-Hersteller Kritikpunkte aber Sonicwall bekleckert sich gerade nicht mit Ruhm.
Leider kann ich nicht mehr nachvollziehen, ob das Cloudbackup bei uns in der Vergangenheit bewusst aktiviert wurde oder ob es mit Einführung des Features per Default aktiv wurde. In MySonicwall waren bei uns Backups von 2023 zu sehen., daher gehe ich davon aus dass es zu diesem Zeitpunkt bei uns auch aktiv wurde.
Da wir kein VPN über die Sonicwalls machen, keine AD-Anbindung etc. und diese nur als Perimeter-Firewalls einsetzen, scheint der Schaden für uns nach aktuellem Stand eher gering zu sein. Wir haben alle empfohlenen und nach unserer eigenen Einschätzung notwendigen Maßnahmen durchgeführt und werden die Sache genaustens beobachten.
Ein kleines Systemhaus, zu deren Geschäftsführer ich früher aufgesehen hatte, hat den ganzen Mist hier eingesetzt.
VMware, SonicWall, MS Exchange (März 2021 *hust*). Alles Top Produkte, hat er gesagt. Mittlerweile sehe ich nicht mehr zu ihm auf…
Puh, würde ich jetzt nicht so pauschalisieren. Auch andere Hersteller haben Schwächen. Ich erinnere mich noch an eine Lücke bei Fortinet, bei dem es erst Monate später ein Update gab.
Dinge passieren.
Grundsätzlich sind es keine schlechten Produkte, wenn man weiß, wie man sie zu administrieren und viel wichtiger zu warten hat.
Auf mysonicwall.com sehe ich bei unserem Modell ebenfalls die im Screenshot gezeigten drei Backups gleichen Datums vom Typ "automatic". Hatte gehofft, dass es mitunter ein Anzeigeproblem sei, ggf. durch Anpassungen an deren API, aber das schließe ich mehr und mehr aus. Die Seriennummer im Dateinamen ist korrekt und der Download wird mit folgendem Hinweis quittiert:
"CAUTION: Preference Files created before 17 September 2025 may be affected by the MySonicWall Cloud Backup File Incident. After restoring these backups, immediately update all credentials and review sensitive configuration settings to prevent potential security exposure. Refer to the Essential Credential Reset KB for thorough remediation guidelines."
Konnten die Angreifer es tatsächlich über die API schaffen, die Geräte anzuweisen, Backups in die Cloud zu laden? In unserem Fall war definitiv kein Scheduled Backup angeschaltet und zu den drei Zeitpunkten hat aus den eigenen Reihen niemand ein Backup angestoßen.
Eine Benachrichtung haben wir von SonicWall ebenso nicht erhalten und wir können ebenso auf die SMTP-Receive-Logs zugreifen. Da war bislang nichts von denen dabei – zumindest nichts hierzu – andere Emails wurden reibungslos erhalten. Ich vermute, man wollte, aber ist beim Versand in irgendein gescriptetes Problem der Automatik gestoßen und vieles wurde einfach nicht übermittelt.
Das Cloud-Backup war soweit ich mich erinnern kann immer automatisch aktiv, sobald dies in der Lizenz inkludiert war. Und das war recht schnell inkludiert – was grundsätzlich Sinn macht, es niederpreisig anzubieten. Hatten wir sogar benutzt und uns auch teilweise darauf verlassen…
Als der Vorfall vorgefallen ist, hat man – so meine Vermutung – die Schnittstelle der Firewall zur Cloud getrennt – und zwar auf der Serverseite. Sonst würden bereits "korrigierte" Aktionen, wie neue Passwörter wieder in der Cloud landen. Da scheint der Vorfall wohl noch nicht vollständig behoben zu sein. Auf der Firewall kann dies nicht von Außen und somit von SonicWall her deaktiviert werden.
Daher ist aktuell das Cloud-Backup aktiv (wie immer), aber der Inhalt von der Cloud kann nicht abgefragt und dargestellt werden und neue Backups können nicht hochgeladen werden. Hier sieht man je nach Konfiguration in den Logs sogar eine Warnung.
Die Einstellungen aus Cloud oder sonst wo sind zwar kodiert, aber können mittels Webseite des Herstellers lesbar umgewandelt werden. Via Knowledge-Artikel war das zumindest in der Vergangenheit möglich. Macht teilweise Sinn, wenn man von älteren Backups Einstellungen benötigt, die in der aktuellen Einstellung nicht mehr vorhanden sind und die alte wegen diverser anderer neuerer Einstellung nicht einfach importiert werden kann. Ich hatte das u.a. mal für DHCP Reservierungen verwendet.
Fakt ist, da sind alle Kennwörter lesbar, die nicht vom externen Quellen wie RADIUS oder LDAP kommen. Der Benutzer und das Kennwort um aber auf den RADIUS oder LDAP zu kommen, ist dann klarerweise betroffen. Ebenso alle lokalen Nutzer, deren TOTP Wert und Kennwörter. Also schützt MFA hier nicht mehr, da der Hacker sich das generieren kann. Site-2-Site VPN und WLAN mit Pre-Share Keys ist ebenso lesbar.
Generell ist es nicht sinnvoll, die Backups intern auf einen Netzwerkordner oder so zu lagern. Da würde ich mittlerweile nur mehr Passwort-Manager oder ähnliches vorschlagen. Denn die Umwandlung in lesbaren Text wird höchstwahrscheinlich nicht nur bei SonicWall in deren Webanwendung gehen – ich könnte mir vorstellen, das wurde auch anderweitig nachgebaut. Automatisch und täglich oder zumindest wöchentlich geht das wohl schwerer umzusetzen. Da war das mit den Cloud-Backups durchaus hilfreich. Aktuell würde ich eher dies deaktivieren und soviel wie möglich manuelle Backups gesichert ablegen.
Achja, kleiner Nachtrag. Der Vorfall dürfte um den 10. September 2025 passiert sein bzw. ab da aufgefallen sein. Seit diesem Datum wurden keine automatischen Cloud-Backups mehr erstellt – sprich, das letzte Cloud Backup ist vom 10 September.
Zudem ist mir aufgefallen, das via Firewall gelöschte Cloud-Backups in der Cloud weiter vorhanden sind.
Noch ein Nachtrag: SonicWall hat unter https://www.sonicwall.com/firewall-config-analysis-tool ein Online-Tool verfügbar gemacht. Steht aber auch in der korrekten Knowledge-Base von SonicWall. Darin kann man die Einstellung hochladen und es wird angezeigt, wo man überall ansetzen sollte bzw. müsste.
Das Tool soll rein im Webbrowser laufen. Bei den Cloud-Backups eigentlich egal und das reicht ja für den Upload. Zumindest muss kein aktualisiertes genutzt werden, denn der genaue Inhalt ist weniger wichtig, sondern nur wo was konfiguriert wird.
Habe aber erst eben bemerkt, zum Cloud Backup war hier auch ganz ein eigener Artikel…
Das aktuell keine Backups in der Firewall unter der Oberfläche zu finden sind ist nicht überraschend, da SonicWall seine Schnittstelle für den Up- und Download abgeschalten hat und deshalb die Firewall keine Verbindung zu der Übersicht herstellen kann.
Den Status dazu findet man auch unter:
https://status.sonicwall.com/
SonicWall hat auch immer nur die betroffenen Kunden informiert und nicht allgemein an alle geschrieben bis letzte Woche. Weshalb in der ersten Welle am 17.9. auch nicht alle informiert wurden, da man zu dem Zeitpunkt davon ausgegangen ist es seien nicht alle Cloud-Backups betroffen.
Eine neue Info-Mail kam am 9.10. in der informiert wurde das alle Geräte mit Cloud-Backup betroffen sind.
Man konnte auf MySonicWall unter "Product Management > Issue List" immer nachschauen ob man aktuell zu den betroffenen Kunden zählt.
Unter https://www.sonicwall.com/firewall-config-analysis-tool gibt es ein Tool um zu prüfen welche Maßnahmen der Hersteller empfiehlt, wenn man betroffen ist.
Weil es hier einige schreiben: Wenn der Schalter unter Cloud-Backup an war, dann war auch ein automatischer Uploadplan konfiguriert, anders funktioniert das nicht. Den kann man unter "Create Backup" > "Schedule Backup" abrufen.
Die aktuellen Infos zum Vorfall vom Hersteller:
https://www.sonicwall.com/support/notices/mysonicwall-cloud-backup-file-incident/250915160910330
Infos zum Vorfall von Huntress mit Dingen die man überprüfen sollte auf lokalen Servern, Angreifer-IPs, usw.:
https://www.huntress.com/blog/exploitation-of-sonicwall-vpn
Der Artikel den man dann großteils durcharbeiten darf, wenn man betroffen ist:
https://www.sonicwall.com/support/knowledge-base/essential-credential-reset/250909151701590
Ein Script was ich kurz zusammengeschrieben habe um in einer AD-Umgebung zu prüfen ob einer der bekannten Indikatoren aufgetreten ist:
https://github.com/DanielBallmann/Sonicwall-Exploitation-Check
Zitat:
"Zugriff auf Windows-Konten"
—
Warum kann man auf Windows-Konten zugreifen, wenn man durch die Firewall kommt?
Hat der Admin das selbe Passwort für Firewall und Windows-Konten vergeben?
Dann ist das der Fehler des Admins und nicht von SonicWall.
2.
Zitat:
"bis hin zur Totalverschlüsselung"
—
Dann war Applocker nicht aktiv.
Wieder Fehler des Admins und nicht von SonicWall.
Ein "Besucher", der durch die Firewall durchgekommen ist, sollte trotzdem keine Schreibrechte und keine Ausführungsrechte haben.
Die Ransomware konnte also nur durch Fahrlässigkeit des Admins gestartet werden.
3.
Zitat:
"Die Geheimnisse sind aber individuell verschlüsselt, mit AES-256 oder 3DES"
—
Mit welchem Schlüssel verschlüsselt?
Seriennummer oder Login-Credentials?
Ein Verschlüsselungsverfahren macht nur dann Sinn, wenn man den Schlüssel selber ändern kann und diesen auch kennt. Das ist hier aber nicht der Fall. Der Admin kennt diesen Crypto-Key nicht. Falls die Standard-Login-Credentials nicht geändert wurden ("admin", "password") und diese gleichzeitg den Crypto-Key bilden, dann kennt der Angreifer den Key.
Falls es fest kodiert ist, dann muss man nur die Firmware einer anderen MySonicwall analysieren, um die Quelle des Crypto-Keys zu extrahieren und dann reduziert sich der Aufwand zum Knacken drastisch.
Zugriff auf Windows Konten wäre denkbar, wenn LDAP oder SSO in Verwendung ist. Denn hier hat der Hacker durch das Cloud-backup den Benutzer und das Kennwort mit dem die Firewall auf das AD zugreift. Warum also ein Fehler des Admin?
Applocker setzt bestimmte Lizenzen voraus. Hat auch nicht jeder und zudem lässt sich das (leider) mittlerweile umgehen.
Applocker setzt keine bestimmten Lizenzen voraus, sondern ist bereits mit der normalen Home Version freigeschaltet.
Ohne Gruppenrichtlinieneditor ist das allerdings etwas schwierig einzurichten.
Prinzipiell kann das aber jeder benutzen.
Bei Windows 7 braucht man noch die "Ultimate" Variante, aber bei Windows 10 (ab v2004 mit KB5024351) und Win11 nicht mehr.
Applocker schützt so gut, das sollte jeder benutzen.
Oh, nach Win 10 1809 steht offiziell. Wenn es lokal sein soll, dann über den lokale Sicherheitsrichtlinien (secpol.msc). Damit ist es doch nicht schwierig…
Wie ist das denn mit den Zugangsdaten für MySonicwall / NSM?
Sind die auch kompromittiert worden?