SonicWall Firewall Sicherheitslücke: Ransomware trifft Gen 7

Krankenhäuser und Kliniken setzen SonicWall-Firewalls häufig als Perimeterschutz und VPN-Konzentrator ein – ein Vertrauensanker, der seit Sommer 2025 unter erheblichem Druck steht. Am 4. August 2025 bestätigte SonicWall aktive Ransomware-Angriffe auf Gen-7-Firewalls mit aktiviertem SSLVPN. Die Angreifergruppe Akira nutzte dabei eine Kombination aus bekannter Schwachstelle, migrationsbedingt übernommenen Altpasswörtern und über-privilegierten Konten – ein klassisches Zusammenspiel aus technischem Versagen und organisatorischer Nachlässigkeit. Für ISB und IT-Leitungen im Gesundheitswesen ist das kein abstraktes Sicherheitsbulletin: Es ist ein konkreter Handlungsauftrag.

Was ist passiert: Chronologie der SonicWall-Angriffe

Ende Juli 2025 begannen die Sicherheitsanbieter Arctic Wolf und Huntress, gehäufte Kompromittierungen von SonicWall Gen 7 Firewalls zu dokumentieren. Bemerkenswert war dabei der initiale Befund: Betroffene Systeme wiesen aktuelle Patch-Stände auf und hatten Multi-Faktor-Authentisierung (MFA) aktiviert. Das ließ zunächst auf eine Zero-Day-Schwachstelle schließen.

Am 4. August 2025 meldete sich SonicWall selbst zu Wort und bestätigte die beobachteten Angriffe – ohne die Zero-Day-Hypothese zu diesem Zeitpunkt zu bestätigen. Die BSI-Cybersicherheitswarnung 2025-271036-1032 (Kritikalität 2) griff diesen Stand am 7. August 2025 auf.

Das Update zur BSI-Mitteilung (Version 1.1) lieferte die entscheidende Klarstellung: Mit hoher Wahrscheinlichkeit lag keine neue Zero-Day-Schwachstelle zugrunde. Stattdessen identifizierte SonicWall die bereits seit 2024 bekannte Sicherheitslücke CVE-2024-40766 als maßgeblichen Einfallsvektor. Verschärfend kam hinzu: Viele betroffene Instanzen waren im Rahmen einer Migration von Gen-6- auf Gen-7-Firewalls entstanden – wobei entgegen der expliziten Herstellerempfehlung die lokalen Benutzerpasswörter nach der Migration nicht geändert worden waren.

Angriffskette im Überblick

  1. Initialzugang über CVE-2024-40766 und/oder kompromittierte, unveränderter Migrationskredentiale via SSLVPN
  2. Credential Harvesting – Entwendung weiterer Zugangsdaten aus dem kompromittierten System
  3. Privilege Escalation über über-privilegierte lokale Konten
  4. Persistenz durch Anlage neuer Nutzerkonten, Etablierung von SSH-Zugängen und zusätzlicher Tooling-Installation
  5. Defense Evasion durch gezieltes Deaktivieren von Sicherheitsfunktionen auf der Firewall selbst
  6. Lateral Movement ins interne Netz
  7. Ransomware-Deployment (Akira)

Dieses Muster ist aus Krankenhaus-Incidents der letzten Jahre bekannt. Neu und besonders kritisch: Die Angriffe gelangen auch auf Systemen mit aktivierter MFA – ein klares Signal, dass MFA allein kein hinreichendes Schutzkonzept für exponierte VPN-Gateways darstellt.

Warum Krankenhäuser besonders exponiert sind

Für Einrichtungen im Gesundheitswesen potenziert sich das Risiko aus mehreren Richtungen:

Hohe SSLVPN-Nutzung: Telearbeit für Verwaltung, klinisches Personal und externe Dienstleister hat die VPN-Nutzung in Kliniken seit 2020 strukturell erhöht. SonicWall-Geräte sind in diesem Segment weit verbreitet.

Migrationsstau: Viele Häuser haben die Gen-6-auf-Gen-7-Migration in den vergangenen 12–18 Monaten durchgeführt, oft unter Zeitdruck und mit Fokus auf Funktionsfähigkeit statt auf Post-Migration-Härtung. Genau dieser Kontext ist laut SonicWall der häufigste Vorfallauslöser.

Regulatorischer Druck erhöht Handlungspflicht: Krankenhäuser mit mehr als 30.000 vollstationären Fällen pro Jahr fallen unter §391 SGB V und sind verpflichtet, branchenspezifische Sicherheitsstandards (B3S Krankenhaus) umzusetzen. Der B3S Krankenhaus fordert explizit die regelmäßige Überprüfung und Aktualisierung von Zugangsdaten sowie ein dokumentiertes Patch-Management. Darüber hinaus gelten seit dem NIS2UmsuCG für viele Gesundheitseinrichtungen verschärfte Anforderungen nach §30 BSIG (technische und organisatorische Maßnahmen) sowie Meldepflichten nach §32 BSIG bei erheblichen Sicherheitsvorfällen.

Verfügbarkeitsanforderungen: Ein erfolgreicher Ransomware-Angriff über das Netzwerk-Gateway kann innerhalb von Stunden zu einem vollständigen Betriebsausfall führen – mit direkten Auswirkungen auf die Patientenversorgung, die nach BSI-Einschätzung als kritische Infrastruktur zu schützen ist.

Sofortmaßnahmen: Was jetzt zu tun ist

Die nachfolgende Maßnahmenliste richtet sich nach dem Schweregrad und der Dringlichkeit. ISB sollten diese intern priorisieren und dokumentieren – sowohl für die eigene Nachvollziehbarkeit als auch für etwaige Nachweise gegenüber Aufsichtsbehörden.

Priorität 1 – Sofort (innerhalb 24–48 Stunden)

Patch-Status verifizieren: Stellen Sie sicher, dass CVE-2024-40766 durch den entsprechenden SonicWall-Patch geschlossen ist. Laut SonicWall-Advisory wurde die Schwachstelle mit SONICWALL-SA-1005 adressiert. Prüfen Sie, ob Ihr Firmware-Stand diesen Fix enthält.

Passwörter aller lokalen Konten zurücksetzen: Insbesondere wenn eine Migration von Gen 6 auf Gen 7 stattgefunden hat, müssen alle lokalen Benutzerkonten neue, starke Passwörter erhalten. Keine Ausnahmen für vermeintliche Servicekonten oder Integrationsnutzer.

SSLVPN-Zugang temporär einschränken: Sofern operativ vertretbar: Beschränken Sie den SSLVPN-Zugang auf dedizierte, bekannte IP-Adressen oder -Bereiche. Prüfen Sie, ob eine temporäre Deaktivierung für nicht zwingend benötigte Nutzergruppen möglich ist.

Log-Analyse initiieren: Analysieren Sie rückwirkend die Authentifizierungs- und Administrationslogs der SonicWall-Instanzen auf Anomalien ab Ende Juli 2025. Achten Sie insbesondere auf: - Neue, unbekannte Nutzerkonten - SSH-Verbindungen von unbekannten Quellen - Konfigurationsänderungen außerhalb regulärer Wartungsfenster - Deaktivierung von Sicherheitsfunktionen

Priorität 2 – Kurzfristig (innerhalb einer Woche)

Über-privilegierte Konten identifizieren und bereinigen: Überprüfen Sie das lokale Kontenmodell Ihrer Gen-7-Firewalls nach dem Least-Privilege-Prinzip. Jedes Konto mit Administrationsrechten ohne aktive operative Notwendigkeit ist zu deaktivieren oder zu löschen.

MFA-Konfiguration überprüfen: MFA hat die Angriffe in diesem Fall nicht verhindert – möglicherweise, weil sie auf kompromittierten Firewall-Sessions aufsetzte oder weil der Angreifer über administrative Konten MFA-Policies anpassen konnte. Überprüfen Sie, ob Ihre MFA-Konfiguration gegen einen Angreifer mit lokalen Admin-Rechten auf der Firewall resistent ist.

Netzwerksegmentierung und Firewall-Nachgelagerte Segmentierung prüfen: Wenn ein Angreifer das VPN-Gateway kompromittiert, ist die entscheidende Frage: Wie weit kann er von dort lateral bewegen? Im Krankenhaus-Kontext sollten medizinische Gerätenetzwerke, klinische Systeme (KIS/RIS/PACS) und administrative Netze durch Segmentierung getrennt sein, sodass ein kompromittiertes Gateway nicht direkt alle Segmente erreicht.

Incident-Response-Readiness prüfen: Stellen Sie sicher, dass Ihr IR-Plan für einen Firewall-Kompromittierungsfall aktuell ist. Ist klar, wer im Ernstfall die Firewall isolieren darf und kann? Gibt es eine Offline-Dokumentation der Netzwerktopologie?

Priorität 3 – Mittelfristig (innerhalb eines Monats)

Migrationsprotokoll standardisieren: Wenn in Ihrer Einrichtung weitere Migrationen von Netzwerkkomponenten anstehen, etablieren Sie eine Checkliste, die Post-Migration-Härtungsschritte (Passwortänderung, Konfigurationsreview, Deaktivierung unnötiger Dienste) als Pflichtpunkte definiert – analog zu den Anforderungen in BSI IT-Grundschutz-Baustein NET.3.2 (Firewall).

Vulnerability-Management-Prozess evaluieren: CVE-2024-40766 war zum Zeitpunkt der Angriffe keine neue Schwachstelle. Die Frage, warum Systeme mit bekannten, gepatchten Schwachstellen dennoch kompromittiert wurden, lässt auf Lücken im Patch-Management oder in der Verifikation des Patch-Status schließen. Überprüfen Sie Ihren Prozess.

Meldepflichten und regulatorische Implikationen

Stellen Sie eine Kompromittierung fest, greifen in Deutschland mehrere Meldepflichten gleichzeitig:

BSIG §32 (NIS2UmsuCG): Erhebliche Sicherheitsvorfälle sind dem BSI zu melden – bei KRITIS-Betreibern und wichtigen bzw. besonders wichtigen Einrichtungen nach NIS2. Die Meldefrist beträgt 24 Stunden für eine Erstmeldung (Frühwarnung), 72 Stunden für einen detaillierten Bericht. Viele Krankenhäuser fallen seit dem Inkrafttreten des NIS2UmsuCG unter diese Pflichten.

§391 SGB V / B3S Krankenhaus: Krankenhäuser, die unter §391 SGB V fallen, haben gegenüber dem BSI bei erheblichen IT-Sicherheitsvorfällen ebenfalls Meldepflichten. Halten Sie Eskalationswege und Meldeformulare bereit.

DSGVO Art. 33 DSGVO / §65 BDSG: Wenn im Rahmen des Angriffs personenbezogene Patientendaten abgeflossen sind oder ein Risiko dafür besteht, ist die zuständige Datenschutzaufsichtsbehörde innerhalb von 72 Stunden zu informieren.

Dokumentieren Sie jeden Schritt Ihrer Incident-Response lückenlos. Dies ist nicht nur für Meldezwecke, sondern auch für eventuelle Nachweispflichten gegenüber Zertifizierungsstellen (ISO 27001, B3S-Auditoren) und Kostenträgern relevant.

Hinweis: Dieser Artikel ersetzt keine Rechtsberatung. Für die Beurteilung Ihrer spezifischen Meldepflichten und rechtlichen Handlungspflichten wenden Sie sich an einen auf IT- und Gesundheitsrecht spezialisierten Anwalt.

Lehren für das ISMS: Was dieser Vorfall strukturell zeigt

Der SonicWall-Vorfall ist kein Einzelfall – er ist Symptom eines wiederkehrenden Musters, das ISB kennen sollten:

Patch ist nicht gleich sicher: CVE-2024-40766 war gepatcht – und dennoch wurden Systeme kompromittiert, weil ein anderer Angriffsvektor (Migrationskredentiale) offen blieb. Ein ISMS, das Patch-Management als alleiniges Sicherheitskriterium betrachtet, greift zu kurz. Härtung, Zugangsdaten-Management und Konfigurationskontrolle sind eigenständige Kontrollbereiche.

MFA ist kein Allheilmittel an exponierten Gateways: Wenn ein Angreifer mit gestohlenen Credentials administrativen Zugriff auf die Firewall selbst erhält, kann er MFA-Einstellungen manipulieren. MFA schützt den Zugang – aber nicht vor einem Angreifer, der bereits im System ist. Netzwerksegmentierung und Monitoring sind die notwendige Ergänzung.

Migrationen sind Sicherheitsereignisse: Jede Migration einer sicherheitsrelevanten Komponente muss im ISMS als sicherheitsrelevantes Ereignis behandelt werden – mit definierter Post-Migration-Härtungspflicht, Vier-Augen-Prinzip und Abnahme durch den ISB.

Visibility ist entscheidend: Mehrere der betroffenen Einrichtungen hatten laut Arctic Wolf und Huntress keine ausreichende Log-Visibility auf ihren Firewall-Systemen. Ein SIEM, das Firewall-Logs systematisch einbindet und auf Anomalien (neue Konten, Konfigurationsänderungen, ungewöhnliche SSH-Sessions) alertiert, hätte die Angriffe früher erkennbar gemacht.

Wenn Sie prüfen möchten, wie gut Ihr ISMS und Ihre technischen Kontrollen für Szenarien wie dieses aufgestellt sind, bietet ISMShield.ai unter ismshield.bpcgmbh.com/assessment/ eine strukturierte Selbstbewertung an.

  • **BSI Cybersicherheits
Kostenlose NIS2-Bestandsaufnahme starten →
Weitere Artikel im Wissensbereich Aktuelle Sicherheitswarnungen für das Gesundheitswesen