Kategorie: Citrix 49 Beiträge

Kritische Schwachstellen in NetScaler ADC und NetScaler Gateway erfordern ein strukturiertes Vorgehen: Betroffenheit bewerten, eine sichere Zielversion auswählen, Systeme aktualisieren und anschließend prüfen, ob Hinweise auf eine Kompromittierung vorliegen.

Diese Checkliste bündelt die wichtigsten Schritte für neue NetScaler-CVEs. Maßgeblich bleiben immer das aktuelle Security Bulletin des Herstellers, die unterstützten Firmwarestände und die Besonderheiten deiner eigenen Umgebung. Betrachte dabei nicht nur den aktuellen Patch-Status, sondern auch CVE-spezifische Voraussetzungen, den Zeitraum der öffentlichen Erreichbarkeit und mögliche Hinweise auf eine bereits erfolgte Kompromittierung.

Aktuelle Citrix-Erkenntnisse: acht NetScaler-Schwachstellen

Aktualisiert am 28. September 2026: Citrix hat im Security Bulletin CTX697096 acht Schwachstellen für NetScaler ADC und NetScaler Gateway veröffentlicht: CVE-2026-88771 bis CVE-2026-88778. Citrix bestätigt, dass CVE-2026-88771 und CVE-2026-88772 bereits ausgenutzt wurden. Betroffene Systeme sollten so schnell wie möglich auf einen behobenen Build aktualisiert werden.

CVE	Kurzbeschreibung	Voraussetzung laut Citrix
CVE-2026-88771	Unauthentifizierte Remote Code Execution (RCE)	Alle Deployments; keine zusätzliche Funktion erforderlich
CVE-2026-88772	Speicherfehler mit möglicher RCE oder Dienstverweigerung	DTLS aktiv; auf VPN-vServern standardmäßig aktiv, sofern nicht ausdrücklich deaktiviert
CVE-2026-88773	HTTP Request Smuggling	HTTP-Konfiguration aktiviert
CVE-2026-88774	Umgehung einer Richtlinie	HTTP-URL-basierte Policy Expression konfiguriert
CVE-2026-88775	Speicherfehler mit möglichem Fehlverhalten oder DoS	Gateway- oder AAA-vServer
CVE-2026-88776	Speicherfehler mit möglichem Fehlverhalten oder DoS	Oracle-LB-vServer
CVE-2026-88777	Speicherfehler mit möglichem Fehlverhalten oder DoS	Nicht-HTTP-Layer-7-Funktion bei LB/CS oder CGNAT-LSN/NAT64
CVE-2026-88778	Vorhersagbarkeit der TCP Initial Sequence Number	TCP-Konfiguration; Citrix empfiehlt eine zusätzliche Änderung an der ISN-Konfiguration

Behobene Mindestversionen laut Citrix:

• NetScaler 14.1: 14.1-73.37 oder neuer
• NetScaler 13.1: 13.1-64.23 oder neuer
• 14.1 FIPS: 14.1-73.37 FIPS oder neuer
• 13.1 FIPS/NDcPP: 13.1-37.279 oder neuer

Die im Bulletin genannten Konfigurationsvoraussetzungen helfen dabei, die Exposition vor dem Update einzuordnen. Läuft die Appliance bereits auf einem für die jeweilige Variante behobenen Build, bedeutet ein passender vServer oder eine aktivierte Funktion für sich genommen nicht, dass sie für diese Schwachstellen weiterhin verwundbar ist. Der Patch beseitigt jedoch nicht rückwirkend eine mögliche frühere Exposition und beweist nicht, dass das System vor dem Update unangetastet blieb. Deshalb bleiben Zeitachse und Sicherheitsprüfung wichtig.

Zusätzliche Prüfhinweise für die Untersuchung

Bei einem konkreten Verdacht oder einer Untersuchung des Zeitraums vor dem Update sollten neben den CVE-spezifischen Konfigurationsvoraussetzungen auch System- und Protokollhinweise korreliert werden. Dazu gehören insbesondere:

• unerwartete Reboots oder Cold Starts; Zeitpunkte mit HTTP-Zugriffen und möglichen Neustartereignissen abgleichen
• Änderungen an /etc/httpd.conf beziehungsweise der auf dem System verwendeten httpd.conf mit einer vertrauenswürdigen Baseline vergleichen
• unerwartete Änderungen an Berechtigungen von /bin/sh
• unbekannte .dot-Dateien unter LogonPoint/custom
• auffällige b64decode-Strings in verfügbaren HTTP- oder Systemprotokollen
• geänderte oder neu angelegte Dateien in sicherheitsrelevanten Verzeichnissen, insbesondere unter /var/vpn/, /var/netscaler/logon/, /var/python/ und /netscaler/ns_gui/
• unbekannte PHP-, Perl-, Python-, JavaScript- oder ELF-Dateien sowie mögliche Webshells
• verdächtige HTTP-Anfragen, ungewöhnliche POST-Aufrufe und Zugriffe auf nicht erwartete Ressourcen
• auffällige Einträge in Shell-, Bash-, Gateway- und VPN-Protokollen; außerdem Protokolllücken oder ungewöhnliche Logrotation
• neue oder veränderte Dateien mit gesetztem SUID-Bit sowie ungewöhnliche Prozesse, etwa im Kontext des Benutzers nobody
• unerwartete Cron-Einträge oder Änderungen an /flash/nsconfig/rc.netscaler und /etc/monitrc
• HA-Synchronisationsprobleme oder unerwartete Änderungen am Prozess nsfsyncd
• ungewöhnliche NSPPE-Abstürze, Core Dumps, Prozesse oder dauerhaft hohe Ressourcennutzung
• auffällige ausgehende Verbindungen, interne Scans und ungewöhnliche Netzwerkaktivität der Appliance

Ein Treffer ist ein Untersuchungshinweis, kein eigenständiger Kompromittierungsnachweis. Umgekehrt beweist eine Suche ohne Treffer nicht, dass keine Kompromittierung stattgefunden hat: Protokolle können rotiert oder verändert worden sein und automatisierte Prüfungen decken nur die jeweils erfassten Pfade und Muster ab. Sichere bei begründetem Verdacht zunächst relevante Beweise und Protokolle, bevor du bereinigst oder neu startest.

Für CVE-2026-88778 nennt Citrix zusätzlich eine Änderung an der Enhanced-ISN-Generation-Konfiguration für betroffene Systeme. Prüfe dafür die aktuelle Herstelleranleitung und den Live-Zustand der Appliance.

Automatisierte NetScaler-Sicherheitsprüfung

Für eine erste technische Einordnung kannst du den folgenden Code kopieren und auf der jeweiligen Appliance ausführen. Die aktuelle Fassung prüft den Firmwarestand gegen die Mindestversionen aus CTX697096, durchsucht die gespeicherte Konfiguration nach Hinweisen auf CVE-Voraussetzungen und sucht an ausgewählten Stellen nach Indikatoren wie b64decode, .dot-Dateien unter LogonPoint/custom sowie auffälligen Metadaten zu httpd.conf und /bin/sh.

Übertrage das Skript auf die Appliance, zum Beispiel nach /var/tmp.

Das Skript verändert keine NetScaler-Konfiguration und startet keine Dienste neu. Es legt einen Textbericht unter /var/tmp ab.

[OK] bedeutet, dass im jeweils geprüften Bereich kein passender Treffer gefunden wurde. Das ist kein Beweis dafür, dass die Appliance nicht kompromittiert ist.
[ACTION] kennzeichnet einen möglichen relevanten Fund, der untersucht werden muss.
[CHECK] weist auf eine nötige manuelle Prüfung oder eine Begrenzung der automatisierten Suche hin. In einem interaktiven Terminal werden die Status zusätzlich farbig dargestellt.

Die Prüfung ersetzt weder einen Abgleich mit der laufenden Konfiguration noch die Analyse des Zeitraums vor dem Update. Die CVE-Prüfungen lesen die gespeicherte ns.conf; diese muss nicht dem aktuellen Laufzeitzustand entsprechen. Das Skript führt auch keinen File-Integrity-Monitoring-Scan aus; dieser muss separat nach Herstellervorgabe ausgeführt werden. Ergebnisse sollten mit HTTP-Zugriffsprotokollen, Neustartzeitpunkten und einer bekannten System-Baseline abgeglichen werden.

Script auf der Appliance starten

Wechsle in die NetScaler-Shell durch Eingabe von shell und starte das Skript:

Auf der Appliance versucht das Skript, die Firmwareversion automatisch zuerst aus dem Header von /nsconfig/ns.conf und danach über nsconmsg zu ermitteln. Enhanced ISN Generation wird aus /nsconfig/ns.conf gelesen. Fehlt dort die Einstellung, wertet das Skript sie als DISABLED (Citrix-Standardwert). Nur wenn die benötigten Werte nicht ermittelt werden können, fordert das Skript zur Eingabe auf.

Die Prüfung ist schreibgeschützt und startet keine Dienste neu. Der Textbericht wird unter /var/tmp abgelegt; der genaue Dateiname wird am Ende ausgegeben.

Werte optional direkt übergeben

Wenn du Werte ausdrücklich vorgeben möchtest, kannst du sie beim Start als Argumente mitgeben. Explizit übergebene Werte haben Vorrang vor der automatischen Ermittlung:

Ersetze die Beispielversion und ENABLED durch die Werte deiner Appliance. Wenn das Skript nach einem Wert fragt, kannst du den Befehl bei Bedarf in der NetScaler-CLI ausführen:

Die vollständige Ausgabe des ISN-Befehls oder nur ENABLED beziehungsweise DISABLED kann eingegeben werden.

CVE bewerten und Update vorbereiten

Bei der Bewertung einer NetScaler-Appliance darf nicht ausschließlich der aktuell installierte Firmwarestand betrachtet werden. Entscheidend ist zusätzlich, ob die Appliance während eines verwundbaren Zeitraums öffentlich erreichbar war und ob die für die jeweilige Schwachstelle notwendigen Konfigurationsbedingungen erfüllt waren.

Aktuell erfordert insbesondere CVE-2026-19490 besondere Aufmerksamkeit. Die kritische Authentication-Bypass-Schwachstelle (CVSS 9.3) betrifft abhängig vom eingesetzten Build NetScaler-Systeme mit Gateway- beziehungsweise AAA-vServer-Konfiguration und teilweise zusätzlich einer konfigurierten SAML Action. Inzwischen wurden Exploit-Versuche in freier Wildbahn gemeldet und ein öffentlicher Proof of Concept ist verfügbar.

Betroffene Systeme müssen mindestens auf 14.1-73.32, 13.1-63.21, 14.1-FIPS 73.32 beziehungsweise 13.1-FIPS/NDcPP 37.277 aktualisiert werden. Citrix nennt keinen Workaround.

Neben dem Firmwarestand solltest du deshalb auch die relevanten Voraussetzungen in der ns.conf prüfen:

Der erste Befehl sucht nach Gateway- und AAA-vServern. Der zweite prüft, ob eine SAML Action konfiguriert ist. Beide Treffer müssen im Zusammenhang mit dem betroffenen CVE bewertet werden.

Besonders bei öffentlich erreichbaren Gateway- oder AAA-vServern solltest du Firmwarestand, relevante Konfiguration und den Zeitraum der öffentlichen Erreichbarkeit gemeinsam bewerten. Ein heute gepatchtes System kann bereits während eines früheren verwundbaren Zeitraums angegriffen worden sein.

Ein aktueller Patch-Status sagt weder etwas über eine frühere Exposition noch über eine mögliche Kompromittierung aus.

Dokumentiere bei CVE-2026-8452 zusätzlich, ob und in welchem Zeitraum die Appliance als Gateway oder AAA Virtual Server öffentlich erreichbar war. Halte den damals eingesetzten Build und den genauen Upgrade-Zeitpunkt fest. Laut Citrix sind unter anderem NetScaler ADC und NetScaler Gateway vor 14.1-72.61 beziehungsweise vor 13.1-63.18 betroffen.

Besonderheit bei CVE-2026-13474: Hier reicht die Prüfung des Firmwarestands allein nicht aus. Citrix weist darauf hin, dass zusätzlich die HTTP/2-Konfiguration berücksichtigt werden muss. Wird kein HTTP Strict Profile verwendet, kann http2SmallWndTimeout weiterhin auf 0 stehen. In diesem Fall ist die Schwachstelle durch das Firmwareupdate allein nicht vollständig adressiert.

Dies ist insbesondere für automatisierte Security-Checks relevant: Ein korrigierter Firmwarestand darf bei CVE-2026-13474 nicht automatisch zu einem positiven Prüfergebnis führen, ohne die relevante Konfiguration einzubeziehen.

• Prüfe das aktuelle Security Bulletin und identifiziere die betroffenen Produktversionen.
• Dokumentiere den aktuellen Build, HA-Status, vorhandene Partitionen und die eingesetzten Funktionen.
• Prüfe die unterstützte Zielversion sowie bekannte Probleme und den vorgesehenen Upgrade-Pfad.
• Sichere Konfiguration und relevante Systemdateien und lege einen belastbaren Rollback-Plan fest.
• Setze von Citrix veröffentlichte Workarounds bis zum Update um und dokumentiere die vorgenommenen Änderungen.

Firmware aktualisieren

Aktualisiere alle betroffenen NetScaler-Systeme auf einen von Citrix freigegebenen Firmwarestand. Bei HA-Paaren solltest du das Update kontrolliert und unter Berücksichtigung von Synchronisation, Failover und Erreichbarkeit der veröffentlichten Dienste durchführen. Veraltete oder nicht mehr unterstützte Versionen solltest du auf einen unterstützten Release-Zweig migrieren.

Ein Firmwareupdate allein beweist nicht, dass das System vor der Aktualisierung unberührt war. Bei kritischen Schwachstellen gehört deshalb eine anschließende Sicherheitsprüfung zum Ablauf.

Überprüfung der Systeme

Auch bereits aktualisierte Systeme solltest du einer eingehenden Sicherheitsprüfung unterziehen. Insbesondere bei kritischen oder aktiv ausgenutzten Schwachstellen lässt sich allein anhand des aktuellen Firmwarestands nicht feststellen, ob eine Appliance zuvor angegriffen oder kompromittiert wurde.

Die folgenden Prüfungen basieren auf Herstellerinformationen, veröffentlichten Sicherheitsanalysen, Community-Hinweisen und eigenen Erfahrungen aus untersuchten NetScaler-Umgebungen.

Sichere bei einem konkreten Verdacht vor einem Neustart, Update oder einer Bereinigung mindestens einen VPX-Snapshot beziehungsweise ein geeignetes forensisches Abbild, Systemzeit, Zeitzone und NTP-Konfiguration, ein Technical Support Bundle sowie lokale und zentrale Protokolle. Je nach Vorfall kann zusätzlich die Sicherung vorhandener NSPPE-Core-Dumps sinnvoll sein. Citrix beschreibt das grundsätzliche Vorgehen in CTX694799.

Ein einzelner Treffer ist nicht automatisch ein Beweis für einen erfolgreichen Angriff. Umgekehrt schließt ein unauffälliger Befund eine Kompromittierung nicht aus, da Protokolle rotieren und Angreifer Spuren verändern können. Bewerte Auffälligkeiten deshalb immer im zeitlichen und technischen Kontext des jeweiligen Security Bulletins.

Zeitpunkt des letzten Firmwareupdates ermitteln

Veränderte Zeitstempel können einen ersten Hinweis auf eine Manipulation liefern. Es muss jedoch gemeinsam mit Dateien, Protokollen, Prozessen, Core Dumps und Netzwerkaktivitäten bewertet werden.

Als zeitliche Referenz solltest du zunächst den Zeitpunkt des letzten NetScaler-Firmwareupdates ermitteln. Einen geeigneten Anhaltspunkt liefern die unter /var/nsinstall/ vorhandenen Installationsverzeichnisse.

Die folgenden Prüfungen führst du über eine administrative SSH-/CLI-Sitzung auf dem NetScaler durch. Melde dich hierzu mit einem administrativen Konto an und wechsle, sofern für den jeweiligen Befehl erforderlich, in die BSD-Shell.

Im Beispiel wurde das zuletzt installierte NetScaler-Update-Paket am 19.07.2023 entpackt. Dieses Datum dient als zeitliche Referenz für die folgenden Prüfungen. Verwende für zeitbasierte Suchen als Startdatum den darauffolgenden Tag im Format YYYYMMDD – im Beispiel also 20230720.

Reboots und Cold Starts

Prüfe außerdem die Reboot- und Shutdown-Historie auf unerwartete Neustarts und Cold Starts. Ein auffälliger Neustart ist allein kein Nachweis einer Ausnutzung. Halte den Zeitpunkt fest und gleiche ihn mit HTTP-Zugriffen, Systemmeldungen, Core Dumps und anderen verfügbaren Ereignissen ab. Fehlende Einträge in der Reboot-Historie schließen einen Neustart nicht sicher aus, da Protokolle unvollständig sein oder rotiert worden sein können.

Veränderte Dateien

Prüfe anschließend, ob seit dem letzten Firmwareupdate Dateien in sicherheitsrelevanten Verzeichnissen neu angelegt oder verändert wurden. Ein entsprechender Treffer stellt noch keinen Nachweis einer Kompromittierung dar, kann jedoch ein relevantes Untersuchungsindiz sein.

Berücksichtige dabei bewusst vorgenommene Änderungen, beispielsweise an Logon-Seiten oder Themes, und gleiche deren legitimen Änderungszeitpunkt mit den gefundenen Zeitstempeln ab.

Eine in Angriffen beobachtete Webshell wurde unter dem Namen a.php im Verzeichnis /var/netscaler/logon/ abgelegt. Eine unbekannte Datei mit diesem Namen ist ein kritischer Untersuchungsbefund. Bewerte jedoch zusätzlich Inhalt, Eigentümer, Berechtigungen, Zeitstempel und die dazugehörigen Protokolle, da der Dateiname allein noch keine Kompromittierung beweist.

Beachte, dass sich Zeitstempel von Dateien unter /netscaler/ns_gui/ nicht ausschließlich durch Firmwareupdates, sondern auch durch Neustarts verändern können. Ein neuerer Zeitstempel ist in diesem Verzeichnis deshalb nicht automatisch verdächtig.

Alternativ kannst du die Prüfung mit folgendem Python-Befehl durchführen:

Werden keine unerwarteten Änderungen gefunden, reduziert dies den konkreten Verdacht in diesem Prüfbereich. Eine Kompromittierung kann dadurch jedoch nicht ausgeschlossen werden.

Neue Dateien und Webshells

Prüfe zusätzlich auf unbekannte PHP-, Perl-, Python-, JavaScript- oder ELF-Dateien in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /tmp/ und /var/tmp/.

Untersuche zusätzlich typische Web- und Portalverzeichnisse auf unbekannte Dateien. Neue Dateien können auf eine abgelegte Webshell oder andere Manipulationen hinweisen, sind für sich allein jedoch noch kein Kompromittierungsnachweis.

Bei der Untersuchung im Zusammenhang mit CVE-2026-8452 solltest du insbesondere /var/vpn/theme/, /var/vpn/ und /netscaler/ns_gui/ auf unbekannte PHP-Dateien prüfen. Bei beobachteten Angriffen wurden unter anderem Webshells mit Namen wie x.php und z.php abgelegt. Diese konkreten Dateinamen ersetzen jedoch keine vollständige Suche nach anderen neu angelegten oder veränderten Dateien.

Prüfe auch das Verzeichnis LogonPoint/custom auf unbekannte Dateien mit der Endung .dot. Auf der Appliance entspricht der zu prüfende Pfad beispielsweise /var/netscaler/logon/LogonPoint/custom. Untersuche gefundene Dateien anhand von Inhalt, Zeitstempel, Eigentümer und Berechtigungen und gleiche den Fund mit geplanten Änderungen ab. Ein unbekanntes .dot-Artefakt sollte gesichert und weiter untersucht werden; der Dateityp allein bestätigt keine Kompromittierung.

HTTP-Fehlerprotokolle

Angriffsversuche oder eine erfolgreiche Ausnutzung können Spuren in den HTTP-Fehlerprotokollen hinterlassen. Achte insbesondere auf unerwartete Aufrufe unbekannter Ressourcen, ungewöhnliche POST-Anfragen, für den Zeitraum untypische User-Agents sowie Abstürze oder Core Dumps nahe dem vermuteten Angriffszeitpunkt.

Mit den folgenden Befehlen kannst du zusätzlich nach Referenzen auf Shell-, PHP- oder Perl-Dateien suchen:

Im Beispiel liefert die Suche nach .sh einen Treffer. Öffne den betreffenden Logeintrag anschließend beispielsweise mit vi, um den vollständigen Kontext zu prüfen.

Der gezeigte Treffer wurde von mir zu Testzwecken erzeugt und stellt keinen tatsächlichen Angriff dar.

Beziehe bei CVE-2026-8452 insbesondere auffällige Aufrufe von SAML-, VPN-, Theme- und PHP-Ressourcen ein. Gleiche die Zeitstempel verdächtiger HTTP-Anfragen mit neu angelegten Dateien, Prozessabstürzen und dem Upgrade-Zeitpunkt ab.

Durchsuche verfügbare HTTP-Zugriffs- und Fehlerprotokolle zusätzlich nach der Zeichenfolge b64decode. Bewerte jeden Treffer im vollständigen Kontext und gleiche den Zeitstempel mit auffälligen HTTP-Anfragen, Reboots oder Cold Starts ab. Ein Treffer ist ein Untersuchungsindikator, aber für sich genommen kein Beweis einer erfolgreichen Ausnutzung. Auch eine Suche ohne Treffer schließt eine Kompromittierung nicht aus.

Shell- und Bash-Protokolle

Bei einer erfolgreichen Ausnutzung können außerdem verdächtige Befehle oder andere Spuren in den Shell- und Bash-Protokollen vorhanden sein.

Die im Screenshot sichtbaren Einträge stammen ausschließlich aus meinen Tests und stellen keinen Angriff dar.

Suche außerdem nach ausgeführten Discovery-Kommandos wie id oder echo sowie nach Download-, Datei- und Shell-Befehlen. Solche Kommandos wurden bei öffentlich dokumentierten Exploit-Versuchen gegen CVE-2026-8452 beobachtet.

Weitere Protokolldateien

Achte außerdem auf Protokolllücken, ungewöhnlich frühe Logrotationen sowie Zeitstempel, die nicht zu Systemzeit, Zeitzone, NTP-Konfiguration oder dem übrigen Ereignisverlauf passen.

Mit der folgenden Suche kannst du die Protokolldateien auf ausgewählte verdächtige Befehle und Artefakte prüfen:

Integrität von httpd.conf und /bin/sh

Prüfe die auf dem jeweiligen Build verwendete httpd.conf, beispielsweise /etc/httpd.conf, auf unerwartete Änderungen. Dateizeitstempel allein reichen dafür nicht aus: Vergleiche Inhalt und Metadaten mit einer vertrauenswürdigen Baseline derselben NetScaler-Version und berücksichtige dokumentierte administrative Änderungen.

Kontrolliere außerdem Eigentümer und Berechtigungen von /bin/sh. Vergleiche die Werte mit einer bekannten, unveränderten Appliance auf demselben Build. Eine unerwartete Abweichung ist ein Anlass zur Untersuchung; die Sollwerte können je nach Version abweichen.

Veränderte Dateien mit gesetztem SUID-Bit

Kopierte Shells, neu angelegte SUID-Dateien sowie ungewöhnliche Eigentümer und Berechtigungen sind besonders kritisch. Gleiche entsprechende Funde immer mit dem bekannten Sollzustand der Appliance ab.

Bei CVE-2026-8452 solltest du besonders prüfen, ob /bin/sh, eine kopierte Shell oder eine andere ungewöhnliche Datei unerwartet mit gesetztem SUID-Bit vorhanden ist. Ein solcher Befund ist hochkritisch und muss forensisch eingeordnet werden.

Prozesse des Benutzers nobody

Bei Angriffen wurden auch ungewöhnliche Prozesse im Kontext des Benutzers nobody beobachtet. Da dieser Account ebenfalls von legitimen NetScaler-Komponenten verwendet wird, ist ein entsprechender Prozess nicht automatisch verdächtig. Gleiche unbekannte Prozesse deshalb mit dem Sollzustand deiner Appliance ab.

Der folgende Screenshot zeigt zum Vergleich einen kompromittierten Server. Die oberste Zeile zeigt den dabei identifizierten Schadprozess.

Cron-Konfiguration auf neue Einträge prüfen

Kontrolliere neben den Crontabs auch /flash/nsconfig/rc.netscaler und /etc/monitrc. Verdächtig sind insbesondere Befehle, die Webshells nach einem Neustart erneut anlegen, das SUID-Bit setzen oder überwachte Prozesse ausblenden beziehungsweise beenden.

Mit dem folgenden Befehl kannst du die aktuelle Crontab überprüfen. Vergleiche die Einträge mit dem bekannten Sollzustand und den auf der Appliance verwendeten Funktionen.

Prüfe zusätzlich, ob für den Benutzer nobody eine Crontab vorhanden ist und ob deren Einträge für deine Konfiguration plausibel sind:

Aus Community-Rückmeldungen und dem Vergleich verschiedener Umgebungen sind unter anderem folgende legitime Einträge bekannt. Ob sie auf deiner Appliance erwartet werden, hängt von den tatsächlich eingesetzten Funktionen ab:

• /netscaler/adss-licexp.sh –> Bei Testlizenzen
• 0/5 * * * * root /netscaler/iprep –> Wenn IP Reputation im Einsatz ist
• */5 * * * * root /var/python/bin/python /netscaler/aslearn_health_monitor.py –> Wenn App Firewall genutzt wird
• */5 * * * * root /bin/pgrep -f /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py; [ $? != 0 ] && /var/python/bin/python /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py –> Wenn App Firewall genutzt wird

NetScaler-HA-Systeme

Unerklärliche HA-Synchronisationsfehler sowie gestoppte oder veränderte Monitor- und Synchronisationsprozesse können ebenfalls auf Manipulationen hinweisen.

Bei dokumentierten Angriffen wurde unter anderem der für die HA-Dateisynchronisation zuständige Prozess nsfsyncd manipuliert beziehungsweise beendet. Prüfe deshalb, ob der Prozess auf deinen HA-Knoten erwartungsgemäß läuft.

Auf einer Standalone-Appliance ist nsfsyncd dagegen nicht zwingend zu erwarten. Der Screenshot zeigt den Sollzustand eines funktionierenden HA-Systems.

Untersuche bei einem HA-Paar immer beide Knoten separat. Ein unauffälliger Knoten schließt eine Kompromittierung des Partners nicht aus.

Gateway- und VPN-Zugriffsprotokolle

Prüfe Gateway- und AAA-Sitzungen zusätzlich auf wechselnde Quell-IP-Adressen, Länder oder User-Agents innerhalb derselben Sitzung sowie auf Sitzungen, die trotz Kennwortänderung oder MFA-Maßnahmen weiterverwendet werden.

Mit der folgenden Suche kannst du erfolgreiche Webzugriffe auf potenziell unbekannte Ressourcen näher untersuchen:

Suche zusätzlich nach Zugriffen mit HeadlessChrome als User-Agent:

NSPPE-Core-Dumps

Suche in Core Dumps und angrenzenden Artefakten nach Hinweisen, dass ns.conf, .F1.key, .F2.key, Zertifikate oder private Schlüssel in Web-, Theme-, Template- oder temporäre Verzeichnisse kopiert wurden.

Speicherfehler oder Abstürze der NetScaler Packet Processing Engine (NSPPE) können Core Dumps erzeugen. Ungewöhnliche Dumps im relevanten Untersuchungszeitraum solltest du deshalb genauer analysieren. Ein Core Dump allein ist jedoch kein Nachweis einer erfolgreichen Ausnutzung.

Untersuche bei CVE-2026-8452 ungewöhnliche Abstürze, Core Dumps und Neustarts des nsppe-Prozesses. Korreliere diese Ereignisse zeitlich mit verdächtigen SAML- oder HTTP-Anfragen und neu angelegten Dateien.

Perl- und Python-Skripte

Unbekannte oder manipulierte Perl- und Python-Skripte können zur Ausführung von Schadcode oder als Persistenzmechanismus verwendet werden.

Gleiche unbekannte Prozesse und Skripte mit dem dokumentierten Sollzustand, den installierten NetScaler-Funktionen und der Herstellerdokumentation ab. Prüfe Dateipfad, Eigentümer, Startzeitpunkt, Kommandozeile und Hashwert.

Die im Screenshot gezeigten Skripte sind in dieser Azure-basierten NetScaler-Umgebung legitim.

Wenn du den StoreFront-Monitor verwendest, kann außerdem dauerhaft ein entsprechender Perl-Prozess sichtbar sein.

Ungewöhnliche Prozesse und Krypto-Miner

Ich habe bereits kompromittierte NetScaler-Appliances untersucht, die anschließend für Crypto-Mining missbraucht wurden. Eine dauerhaft hohe CPU-Auslastung kann jedoch auch andere Ursachen haben und ist allein kein Kompromittierungsnachweis.

Prüfe deshalb die laufenden Prozesse und ordne eine ungewöhnlich hohe CPU-Auslastung immer dem verursachenden Prozess zu. Neben Crypto-Minern können kompromittierte Systeme beispielsweise auch für Proxying, Tunneling oder andere missbräuchliche Aktivitäten verwendet werden.

Im gezeigten Beispiel ist die hohe Auslastung der NSPPE-Prozesse erwartbar. Entscheidend sind zusätzliche oder unbekannte Prozesse mit ungewöhnlich hoher beziehungsweise dauerhafter Ressourcennutzung.

Netzwerk- und Firewall-Logs prüfen

Ergänze die lokale Untersuchung der Appliance durch eine Analyse der Netzwerk- und Firewall-Protokolle. Untersuche insbesondere ungewöhnlichen Verkehr von der NSIP, interne Scans, auffällige ausgehende Verbindungen und Abweichungen vom üblichen Kommunikationsprofil.

Achte insbesondere auf:

• Scans vom NetScaler in interne Subnetze über HTTP, HTTPS oder SMB (80, 443, 445)
• ungewöhnlich hohe LDAP-/LDAPS-, DNS- oder Kerberos-Aktivität (389, 636, 53, 88 usw.)
• unerwartete RDP- oder Netzwerk-Logons
• größere ausgehende Datenübertragungen
• ungewöhnliche DNS-Ziele oder externe Verbindungen
• auffällige AD-Ereignisse wie 4624 und 4625

Korreliere entsprechende Auffälligkeiten mit Webserver-, Shell-, Authentifizierungs- und Firewall-Protokollen sowie dem vermuteten Angriffszeitraum.

Gegenmaßnahmen bei betroffenen Systemen

Wenn eine Kompromittierung bestätigt wurde oder aufgrund der vorliegenden Artefakte nicht ausreichend ausgeschlossen werden kann, solltest du abhängig vom Befund unter anderem folgende Maßnahmen einleiten:

• Isoliere die betroffene NetScaler-Appliance kontrolliert vom Netzwerk.
• Ändere die Kennwörter aller auf dem NetScaler verwendeten LDAP-, AD- und sonstigen Service- beziehungsweise Netzwerkkonten.
• Ersetze potenziell kompromittierte SSL-Zertifikate einschließlich der zugehörigen privaten Schlüssel.
• Widerrufe kompromittierte Zertifikate, sofern dies für die jeweilige PKI beziehungsweise CA erforderlich ist.
• Invalidiere beziehungsweise beende bestehende Sitzungen, sofern eine Übernahme von Sessions nicht ausgeschlossen werden kann.
• Prüfe abhängige Systeme und Identitäten auf mögliche Folgeaktivitäten.

Bei einer VPX-Appliance kann ein Snapshot aus einem nachweislich vor dem möglichen Kompromittierungszeitraum liegenden Zustand bei der Wiederherstellung unterstützen. Das Alter eines Snapshots allein ist jedoch kein Sicherheitsnachweis. Ein Restore ersetzt weder die Ursachenanalyse noch die Rotation potenziell kompromittierter Zugangsdaten, Zertifikate und Schlüssel.

Bei einer bestätigten Kompromittierung sollte abhängig vom Befund ein kontrollierter Neuaufbau gegenüber der bloßen Wiederherstellung eines nicht zweifelsfrei vertrauenswürdigen Systems bevorzugt werden.