VPN-Gateway gepatcht — aber war vorher schon jemand drin?

/01Kompromittiert heißt nicht ungepatcht: worum es geht

Ein VPN-Gateway gilt als kompromittiert, wenn ein Angreifer darauf Befehle ausgeführt, Daten gelesen oder Zugangsdaten entnommen hat. Ob die Lücke heute geschlossen ist, spielt dafür keine Rolle: Das Update verhindert den nächsten Einbruch, macht den letzten aber nicht ungeschehen. Wer bei einer ausgenutzten Lücke nur patcht, beantwortet die falsche Frage.

Gemeint sind hier Geräte, die aus dem Internet erreichbar sind und Fernzugriff vermitteln: SSL-VPN-Portale wie Ivanti Connect Secure, NetScaler Gateway, die IPsec-Gegenstellen von Firewalls wie WatchGuard Firebox. Sie stehen offen im Netz, weil sie es müssen. Sie prüfen Anmeldungen und halten dafür Zugangsdaten zum Active Directory oder zu einem Identitätsanbieter. Und sie haben einen Fuß im internen Netz, denn dorthin sollen die Tunnel ja führen.

Nicht gemeint ist der Grundsatzvergleich zwischen klassischem VPN und Zero Trust; den haben wir im Beitrag VPN vs. Zero Trust Network Access geführt. Hier geht es um die Woche nach dem Patch.

Irrelevant ist das Thema, wenn Sie keines der genannten Produkte im Einsatz haben und Ihr Fernzugang nicht aus dem Internet erreichbar ist. Dann lohnt allenfalls Abschnitt /07, denn die Rotationsliste gilt für jedes Gateway mit AD-Anbindung.

/02Herbst 2026: welche Gateway-Lücken ausgenutzt werden

Die folgende Übersicht stützt sich auf den KEV-Katalog der US-Behörde CISA (Stand 21.10.2026) und die Einträge der NVD. Aufgenommen wird dort nur, was nachweislich ausgenutzt wird. Eine CVE ohne KEV-Eintrag ist deshalb nicht harmlos, aber eine mit Eintrag ist es sicher nicht.

Eine Sonderrolle hat CVE-2026-107406 im NetScaler, veröffentlicht am 08.10.2026 mit CVSS 9.5. Sie betrifft nur Geräte, die als SAML-Dienstanbieter oder SAML-IdP konfiguriert sind, und war bei Redaktionsschluss nicht als ausgenutzt bekannt. Behoben ist sie laut Citrix-Bulletin CTX697191 ab 14.1-73.46 und 13.1-64.29; Builds von 14.1-73.37 bis 14.1-73.41 und 13.1-64.23 bis 13.1-64.28 sind nur noch als SAML-IdP betroffen. Ob Ihr Gerät SAML nutzt, zeigt die Konfiguration: Zeilen mit add authentication samlAction oder add authentication samlIdPProfile.

Ivanti Connect Secure und NetScaler waren schon 2024 und 2025 Ziel von Zero-Day-Angriffen. Der Ablauf aus diesem Beitrag gehört deshalb fest in Ihr Patch-Managements.

/03Die ersten 72 Stunden: erst sichern, dann patchen

Bei einer bereits ausgenutzten Lücke zerstört der Reflex „sofort updaten" die Spuren. Ein Neustart leert den Arbeitsspeicher, in dem sich bei Ivanti die Angreiferbefehle abgespielt haben. Die kanadische Cybersicherheitsbehörde rät im NetScaler-Hinweis deshalb, Beweise wo möglich vor Abschalten, Neustart, Patch und Neuaufbau zu sichern.

Die CISA hat im Juni 2026 für US-Bundesbehörden einen Ablauf für solche Fälle beschrieben. Der Zeitplan ist dort ausdrücklich nicht verpflichtend, taugt aber als Gerüst für den Mittelstand. Wir haben ihn auf die Lage eines Unternehmens mit einem Gateway und ohne eigenes Forensik-Team übertragen:

In der Praxis hakt es selten am Patch, sondern an Schritt zwei: Viele Gateways schreiben ihre Logs nur lokal, und die lokalen Logs sind genau das, was Angreifer löschen. Ohne externe Kopie bleibt „War jemand drin?" unbeantwortbar. Wie man Logs dauerhaft außerhalb des Geräts hält, beschreibt unser Beitrag Managed Detection mit Wazuh und OPNsense.

/04Prüfliste Ivanti Connect Secure

Volexity hat die Angriffe mit CVE-2026-104935 untersucht und die Arbeitsweise genau beschrieben. Sie erklärt, warum eine einfache Prüfung hier nicht reicht: Die Angreifer installierten weder Schadsoftware noch eine Webshell. Für jeden einzelnen Befehl liefen sie die gesamte Angriffskette erneut durch, und der Exploit entfernte anschließend die zugehörigen Einträge aus /home/runtime/dlogs/debuglog und /var/log/audit/audit.log. Die dritte Stufe der Kette, eine Rechteausweitung auf root, war bei Veröffentlichung noch nicht gepatcht.

Was die Angreifer wollten

Laut Volexity entnahmen sie die auf dem Gerät gespeicherten Domänen-Zugangsdaten für die LDAP-Anbindung. Mit dem AD-Dienstkonto des Gateways fragten sie dann LAPS-Passwörter, BitLocker-Wiederherstellungsinformationen, die Attribute userPassword und unixUserPassword sowie Pfade von Anmeldeskripten ab. Dazu kamen Kerberoasting und Password Spraying. Das eigentliche Ziel war das Verzeichnis hinter dem Gateway.

Prüfschritte

• Version: 22.8R2.5, 25.1.1.2 oder 25.1.3.0 bzw. 25.1.3.1 und neuer (Liste aus dem Ivanti-Advisory, zitiert nach Rapid7). 22.7.x ist nicht betroffen.
• Integrity Checker Tool: laufen lassen, Ergebnis dokumentieren — aber nicht als Entwarnung lesen. Das Werkzeug sucht unerwartete Dateiänderungen auf der Platte; die Kette verändert laut Volexity Bibliothekscode nur im Arbeitsspeicher und setzt Konfigurationsdaten zurück. Die CISA stellte schon 2024 fest, dass interner und externer Checker Einbrüche übersehen hatten.
• Externe Webzugriffs-Logs (Reverse Proxy, Load Balancer, falls vorhanden): auffällig viele Anfragen an /dana-na/auth/url_default/welcome.cgi mit einem Header X-DSCGI-PATH, besonders wenn dessen Pfad nicht zur aufgerufenen URL passt.
• Dateispuren (nur über Systemabbild bzw. Herstellersupport): Dateien wie ml.py, rq5.py, sp_out.txt, spray_hits.json in /tmp, Skripte ics-root-run-inband-*.pl in /home/runtime/tmp, ein Prozess dsstatmond aus /data/.icscap — laut Volexity ein umbenanntes tcpdump.
• Netz: Verbindungen zur von Volexity genannten Adresse 108.165.147[.]64.
• Active Directory: Anmeldungen und Abfragen des Gateway-Dienstkontos ab dem 03.10.2026, siehe Befehle unten.

# Wann und von wo hat sich das Gateway-Dienstkonto angemeldet? (Domänencontroller)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime='2026-10-03'} |
  Where-Object { $_.Properties[5].Value -eq 'svc-vpn-ldap' } |
  Select-Object TimeCreated, @{n='Quelle';e={$_.Properties[18].Value}} |
  Group-Object Quelle | Sort-Object Count -Descending

# Kerberoasting-Spur: Dienstticket-Anfragen mit RC4 (0x17) ab Ausnutzungsbeginn
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime='2026-10-03'} |
  Where-Object { $_.Properties[5].Value -eq '0x17' } |
  Select-Object TimeCreated, @{n='Konto';e={$_.Properties[0].Value}}, @{n='Dienst';e={$_.Properties[2].Value}}

Den Kontonamen svc-vpn-ldap ersetzen Sie durch Ihr Bind-Konto. Erwartet werden Anmeldungen nur von der internen Adresse des Gateways; andere Adressen oder ein Anstieg in der Nacht sind ein Befund. Bei 4769 sind RC4-Tickets in modernen Domänen selten; Häufungen für mehrere Dienstkonten von einem Konto aus sind das typische Bild von Kerberoasting. Die Ereignisse stehen nur so weit zurück, wie das Sicherheitsprotokoll reicht; bei unveränderter Protokollgröße sind das auf belebten Domänencontrollern erfahrungsgemäß nur Tage.

/05Prüfliste NetScaler ADC und Gateway

Für die ausgenutzten Lücken vom September hat Citrix im Bulletin keine Dateipfade oder Indikatoren veröffentlicht. Der KEV-Eintrag und die kanadische Behörde verweisen auf die IOC-Prüfung in der NetScaler Console. Für den Verdachtsfall nennt Citrix in CTX694799: Support-Bundle und Speicherabbild der Packet Engine sichern, externe Logs aufbewahren, Gerät isolieren, Dienstkonten, Zertifikate und Schlüssel ersetzen, neu aufsetzen, mindestens 90 Tage beobachten.

Prüfschritte

• Version und Konfiguration: Build feststellen, SAML-Nutzung prüfen (wegen CVE-2026-107406).
• IOC-Prüfung in der NetScaler Console ausführen und das Ergebnis sichern.
• Persistenz: laufende Prozesse, offene Verbindungen, Startskripte und geplante Aufgaben festhalten — Prüffelder der kanadischen Behörde.
• Dateien in Web-, VPN-, Anmelde- und Python-Verzeichnissen, die nach dem letzten Update entstanden sind, sowie neue setuid-Dateien — die Befehle stammen aus der CISA-Warnung AA23-201A zur Webshell-Welle 2023, nicht aus einem Citrix-Bulletin von 2026.
• Sitzungen beenden nach dem Update, damit keine gestohlene Sitzung weiterläuft.

> show ns version
> show ns runningConfig | grep -i saml
add authentication samlAction ...         # Gerät ist SAML-Dienstanbieter
add authentication samlIdPProfile ...     # Gerät ist SAML-IdP

> shell
# Prüfmuster aus CISA AA23-201A; Datum = letzte Installation
find /netscaler/ns_gui/ -type f -name '*.php' -newermt 20260901 -exec ls -l {} \;
find /var/vpn/ /var/netscaler/logon/ /var/python/ -type f -newermt 20260901 -exec ls -l {} \;
find /var -perm -4000 -user root -not -path '/var/nslog/*' -newermt 20260901 -exec ls -l {} \;
# Auffällige Prozesse und ausgehende Verbindungen
ps -auxww
netstat -an | grep ESTABLISHED
exit

# nach dem Update aller Knoten: Sitzungen beenden
> kill aaa session -all
> kill icaconnection -all
> kill pcoipConnection -all

Die Verzeichnisliste ist ein Ausgangspunkt, keine vollständige Suche; PHP- oder Shell-Dateien, die nicht zum Update-Datum passen, sind ein Befund. kill aaa session -all beendet laut NetScaler-Befehlsreferenz alle AAA-TM- und VPN-Sitzungen; Nutzer müssen sich danach neu anmelden. Die beiden ICA- und PCoIP-Befehle hat Citrix 2025 im Bulletin CTX693420 empfohlen, ausdrücklich erst nach dem Update aller Knoten eines HA-Paars oder Clusters.

/06Prüfliste WatchGuard Firebox

Die Lücke CVE-2025-14733 im IKEv2-Dienst der Firebox ist älter, aber nicht erledigt: Die CISA führt sie mit bekannter Nutzung durch Ransomware-Gruppen, und WatchGuard hat den Hinweis zuletzt im August 2026 aktualisiert. Betroffen sind Geräte mit Mobile-VPN über IKEv2 oder Branch-Office-VPN über IKEv2 zu einer dynamischen Gegenstelle. Laut NVD kann eine Firebox auch dann noch verwundbar sein, wenn solche Konfigurationen gelöscht wurden und nur noch ein Branch-Office-VPN zu einer statischen Gegenstelle besteht.

Prüfschritte

• Version: Fireware 2025.1.4, 12.11.6, für T15/T35 12.5.15, für FIPS 12.3.1+728352 oder neuer.
• Logmeldung des iked-Prozesses über eine Zertifikatskette mit mehr als acht Zertifikaten — laut WatchGuard ein mittelstarkes Indiz.
• IKE_AUTH-Anfragen mit einer CERT-Nutzlast über 2.000 Byte (Protokollstufe Info) — laut WatchGuard ein starkes Indiz.
• Hängender iked-Prozess bei weiterlaufenden Tunneln: starkes Indiz; ein Absturz allein ist schwach, weil er andere Ursachen haben kann.
• Ausgehende Verbindungen zu den sechs Adressen aus dem WatchGuard-Hinweis: 45.95.19[.]50, 51.15.17[.]89, 172.93.107[.]67, 199.247.7[.]82, 38.252.8[.]14, 94.249.197[.]106.

Der wichtigste Satz im WatchGuard-Hinweis steht weiter unten: Angreifer haben die aktive Konfiguration abgezogen, in einer zweiten Variante zusammen mit der lokalen Benutzerdatenbank der Verwaltung. Bei einem Treffer sind deshalb alle lokal gespeicherten Geheimnisse zu wechseln — Pre-Shared Keys der Tunnel, lokale Administratorkennwörter, Zugangsdaten für LDAP oder RADIUS.

/07Zugangsdaten und Sitzungen: was rotiert werden muss

Die CISA formuliert es seit dem Ivanti-Fall von 2024 ohne Umschweife: Benutzer- und Dienstkonten, die auf einer betroffenen Appliance gespeichert waren, gelten als wahrscheinlich kompromittiert. Bei begründetem Verdacht ist die Rotation keine Kür. Die Liste ist aus den beschriebenen Angriffen abgeleitet:

# Windows LAPS: Ablauf für alle Rechner einer OU sofort setzen
Get-ADComputer -Filter * -SearchBase 'OU=Clients,DC=firma,DC=local' |
  ForEach-Object { Set-LapsADPasswordExpirationTime -Identity $_.DistinguishedName }

# BitLocker: Wiederherstellungsschlüssel auf einem Rechner erneuern
manage-bde -protectors -get C: -Type RecoveryPassword
manage-bde -protectors -delete C: -Type RecoveryPassword
manage-bde -protectors -add C: -RecoveryPassword
manage-bde -protectors -adbackup C: -id '{NEUE-ID}'

# Dienstkonten mit SPN auflisten (Kerberoasting-Ziele)
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet

LAPS wechselt mit dem nächsten Richtliniendurchlauf, nicht sofort; die BitLocker-Befehle müssen auf jedem Gerät laufen. Dienstkonten mit Kennwörtern, die seit Jahren nicht geändert wurden, sind das, was Kerberoasting in der Praxis knackt; PasswordLastSet zeigt, wo Sie anfangen. Wer an dieser Stelle den Zugang grundsätzlich neu ordnen will, findet die Grundlagen im Beitrag Multi-Faktor-Authentifizierung richtig einführen.

Ehrlich: Eine vollständige Rotation dauert nach unserer Erfahrung bei rund 120 Arbeitsplätzen eher Tage als Stunden — eine Einschätzung, keine Messung. Der Aufwand steckt in den Dienstkonten, deren Kennwörter in Anwendungen eingetragen sind. Genau deshalb wird sie gern verschoben, und ein nicht gewechseltes Kennwort bleibt für den Angreifer gültig, bis jemand es ändert.

/08Patchen oder neu aufsetzen: die Entscheidungstabelle

Am Ende der 72 Stunden steht nicht „gepatcht ja oder nein", sondern: Vertrauen wir diesem Gerät noch?

„Neu aufsetzen" heißt: Werkszustand bzw. frisches Image vom Hersteller, aktuelle Version, Konfiguration nicht blind zurückspielen, sondern Zeile für Zeile gegen eine Sicherung von vor dem Ausnutzungsbeginn prüfen. Bei Hardware gilt eine unbequeme Grenze: Die CISA hat 2024 für Ivanti festgehalten, dass Angreifer unter Umständen Persistenz auf root-Ebene über einen Werksreset hinaus erreichen können. Wer einen bestätigten Einbruch hatte und auf Nummer sicher gehen will, tauscht das Gerät.

/09Wo die Prüfung an Grenzen stößt

Keine der Prüflisten beweist, dass ein Gerät sauber ist. Sie zeigen, ob die bekannten Spuren der bekannten Angriffe vorhanden sind. Drei Grenzen sollten Sie kennen, bevor Sie einen Befund „unauffällig" abzeichnen.

• Spuren im Arbeitsspeicher. Volexity empfiehlt bei Verdacht Netzwerk- und Speicherforensik. Die meisten Mittelständler können ein Speicherabbild einer Appliance weder ziehen noch auswerten; sie sind auf den Herstellersupport oder einen Forensikdienstleister angewiesen, und das braucht Tage.
• IOC-Listen veralten. Eine zweite Gruppe, die dieselbe Lücke nutzt, hinterlässt andere Spuren. Prüfungen auf Verhalten — ein Dienstkonto, das plötzlich LAPS-Attribute liest — tragen weiter.
• Das Verzeichnis protokolliert Lesezugriffe nicht von selbst. Ob jemand LAPS-Kennwörter gelesen hat, sehen Sie im AD nur, wenn auf den Attributen eine Überwachung (SACL) eingerichtet war. Fehlt sie, bleibt nur die Annahme, dass gelesen wurde.

Dazu kommt: Jemand muss Firewall-Verbindungsdaten, AD-Ereignisse und Gateway-Logs zusammen lesen. Dafür gibt es ein SOC; ohne eines bleibt es bei der Stichprobe. Wie die ersten Schritte eines Vorfalls organisiert werden, beschreibt der Beitrag Cyberangriff: Die ersten 60 Minuten.

/10Gateway ersetzen? OPNsense, WireGuard und ZTNA ehrlich eingeordnet

Nach dem dritten Notfallwochenende stellt sich die Frage, ob das Gerät das richtige ist. Mitten im Vorfall wechselt man aber nicht: erst bereinigen, dann planen.

Was für einen Wechsel spricht

Die ausgenutzten Lücken der letzten Monate sitzen fast alle in dem Teil, der vor der Anmeldung antwortet: Webportale, Anmeldeskripte, SAML- und IKE-Verarbeitung. Ein SSL-VPN-Portal muss jedem im Internet eine Webanwendung zeigen. WireGuard verfolgt das Gegenteil: Laut Protokollbeschreibung antwortet der Server einem nicht berechtigten Absender überhaupt nicht. Wer den Schlüssel nicht hat, sieht keinen offenen Dienst, an dem er etwas ausprobieren könnte. Eine OPNsense mit WireGuard für Standorte und Homeoffice hat damit eine deutlich kleinere Angriffsfläche vor der Anmeldung als ein Webportal. Ein ZTNA-Ansatz wie NetBird geht einen Schritt weiter und erlaubt Zugriffe je Gruppe statt je Netz; die Einzelheiten stehen im Beitrag NetBird: Mesh-VPN auf WireGuard-Basis.

Was dagegen spricht

• Auch OPNsense hat Lücken. Die NVD führt 2026 unter anderem CVE-2026-44195, mit der sich die Sperre nach Fehlanmeldungen umgehen ließ, und CVE-2026-63442 in der Anmeldung der Weboberfläche, behoben in 26.1.11. Beide setzen voraus, dass die Weboberfläche erreichbar ist — sie gehört deshalb nie ans Internet. Eine Firewall ist nur so sicher wie ihr Update-Takt.
• Funktionen fehlen. Wer ein Portal ohne Client braucht, veröffentlichte Citrix-Anwendungen über ICA-Proxy betreibt oder Gerätezustandsprüfungen vor dem Tunnelaufbau voraussetzt, findet das in WireGuard nicht. Dann bleibt der Hersteller — mit der Disziplin aus diesem Beitrag.
• WireGuard-Schlüssel sind keine Identität. Ohne Anbindung an Entra ID oder einen anderen IdP fehlt die Kopplung an Konto und MFA. Die liefert erst eine Schicht wie NetBird, und die muss ebenfalls betrieben werden.

Unsere Einordnung: Wo der Fernzugang aus Laptops im Homeoffice und ein paar Standorttunneln besteht, ist eine betreute OPNsense mit WireGuard die nüchternere Wahl — weniger Angriffsfläche, keine Lizenzspirale, und das Regelwerk lässt sich lesen. Wer Portal-Funktionen tatsächlich nutzt, behält sein Gateway und investiert in externe Logs, feste Patchfenster und die Prüfroutine. Der Plattformwechsel ist nicht die Lösung; der Betrieb ist es.

/11Häufige Fragen