netscaler-quickcheck
Prüfen. Bewerten. Entscheiden.
Sicherheits-Triage für Citrix NetScaler ADC und Gateway, direkt auf der Appliance.
Ein Lauf prüft den Build gegen die Citrix-Bulletins, sucht Angriffsspuren und Kompromittierungszeichen und endet mit einem eindeutigen Verdict. Open Source unter Apache 2.0, entwickelt von ceterion.
Validiert auf NetScaler 14.1
Befunde auf Deutsch
13.1 und FIPS: Beta
Apache License 2.0
Warum nicht einfach grep?
Muster. Zusammenhang. Entscheidung.
Eine einzelne Logzeile beweist selten etwas. Der Quickcheck setzt Zeilen, Adressen und Zeiträume in Zusammenhang und sagt, was davon zählt.
Den Schläfer finden
Der Sprayer, der montags vier Konten probiert, pausiert und freitags wiederkommt, bleibt unter jeder Lockout-Schwelle. Die kumulierte Adressliste sieht die Wiederkehr.
Das Spraying finden
Dutzende Maschinen, tausend Kontonamen, je ein Versuch: nach /24 gruppiert, mit Takt und Konten, und mit der entscheidenden Frage, ob eine davon hineingekommen ist.
Das Konto unter Beschuss finden
Brute Force auf einen Namen ist ein anderer Angriff mit einer anderen Antwort. Er bekommt einen eigenen Befund und ein eigenes „diese Person anrufen“.
Den Treffer finden
Eine erfolgreiche Anmeldung nach einer Fehlserie ist Rot, mit Konto, Adresse und den drei Befehlen, die zuerst laufen sollten.
Die Sondierung vor der Shell finden
Anfragen nach bekannten Webshell-Namen in jedem Theme-Ordner, mit der echten Quelle aus dem Access-Log, und eine rote Zeile, falls ein Webshell-Pfad je mit 200 geantwortet hat.
Die Lücke finden
Fehlende Logs, fehlende Regeln, unlesbare Dateien: Das Verdict lautet dann INVESTIGATE und nennt, was nicht geprüft werden konnte. Nie OK aus Mangel an Beweisen.
Die stille Änderung finden
Ein Angreifer, der die laufende Config ändert, ohne zu speichern, hinterlässt keine Datei für das nächste Backup. Der Quickcheck vergleicht laufende, gespeicherte und vorherige Config (ns.conf, ns.conf.0). Ungespeicherte Änderungen sind ein Befund, ebenso jede sicherheitsrelevante Abweichung: neue System-User, Policies, Listener, Management-Zugriff.
Ein Lauf, ein Verdict
Lesen. Einordnen. Handeln.
Am Ende jedes Laufs stehen eine ACTION-Zeile, eine maschinenlesbare RESULT-Zeile und unter jedem Befund, was zu tun ist. In Klartext und auf Deutsch, damit Administratoren, IT-Leitung und Prüfer denselben Report lesen können.
OK
Exit 0
Build gefixt, kein bekannter Indikator, keine Spuren im Fenster.
INVESTIGATE
Exit 1
Befunde einordnen oder Prüflücke schließen.
UPDATE
Exit 2
Build verwundbar, Update einplanen.
FORENSICS_FIRST
Exit 2
Kompromittierungszeichen. Nicht rebooten, nicht upgraden, erst sichern.
== 5 Kompromittierungs-Schnellcheck == [ROT] Bekannter Payload-Pfad existiert: /netscaler/ns_gui/vpn/c88771.json - Quelle: sygnia 2026-10-01 [ROT] Crontab fuer Benutzer nobody vorhanden (1 Zeilen) - bekannte Persistenz [ROT] Listener von Interpreter/Shell-Prozessen auf erreichbaren Adressen: | perl nobody *:4444 [GELB] Lokale System-User neben nsroot: sec_monitor - jeden bestaetigen [ROT] System-User sec_monitor = bekannte Backdoor (LevelBlue) [ROT] 2 gespeicherte Config-Aenderung(en) an User, Auth, EPA oder Management ... - jede bestaetigen: | [neu] add ns ip 192.0.2.10 255.255.255.0 -type SNIP -mgmtAccess ENABLED | [neu] add system user sec_monitor ... == 6 Verdict == ACTION: FORENSICS_FIRST Kompromittierungszeichen gefunden. Nicht rebooten, nicht upgraden, bevor gesichert ist: 1. Appliance isolieren (Failover auf gepatchten Knoten oder Firewall), HA-File-Sync pruefen, Peer ebenfalls pruefen. 2. Sichern: show techsupport, /var/log, /var/core, die genannten Dateien, RAM wenn moeglich (CTX694799). 3. Citrix Support einbinden, offiziellen IoC-Scan anfordern. Danach Rebuild, alle Secrets inkl. KEK rotieren, Zertifikate widerrufen. RESULT host=gw-01 build=14.1-73.41 mode=offline ... compromise=1 red=13 yellow=6 coverage=full action=FORENSICS_FIRST ...
Gekürzter Auszug aus einem Offline-Lauf gegen das Test-Fixture compromised aus dem Repository (synthetische Testdaten, keine Kundendaten).
Was es prüft
Sechs Blöcke. Ein Ergebnis.
Von der Build-Nummer bis zur aktiven Verbindung: jede Prüfung mit dokumentierter, einstellbarer Schwelle.
1 Build
Abgleich gegen jede CVE-Zeile der Regeldatei mit Fix-Builds je Train und Bedingungen wie SAML. End-of-Life-Trains, ungespeicherte Config.
2 Exposure und Mitigation
SAML, DTLS, Management-Zugriff auf SNIPs, Responder-Policies: ob sie an den richtigen vServern gebunden sind und ob ihre Hit-Counter sich bewegen.
3 und 4 Angriffsspuren
Injection-Versuche mit Download-Host und Quelle, nsaaad-Crashes, Dropper-Anfragen, Webshell-Sondierung, Zugriffe von außen, Angriffe auf Gateway-Konten.
5 Kompromittierungs-Schnellcheck
Payload-Pfade, geänderte Web-Dateien, Cron, Listener, System-User, verdächtige Prozesse, aktive Verbindungen zu Angreifer-Adressen, Config-Diff.
Betreiberkontext
Sperrliste, Whitelist und eigene Indikatoren in einer Custom-Datei, die jedes Update überlebt. Sie kann die Bewertung nur strenger machen, nie milder.
6 Verdict und Ausgaben
Report, JSON, Adresslisten je Lauf und kumuliert nach Kategorie für Firewall und SOC, anonymisierte Fassungen zur Weitergabe.
Gebaut für den Ernstfall
Nichts anfassen. Alles belegen.
Das Werkzeug läuft während eines Incidents, ohne Teil davon zu werden.
- Nur lesend. Keine Netzverbindung, keine Änderung an Konfiguration oder Systemdateien, kein Agent, kein Python. Geschrieben wird nur in die eigenen Verzeichnisse.
- Least Privilege. Die optionale CLI-Ebene nutzt einen Service-User, den eine Command Policy auf
showundstatbegrenzt. Kein Passwort in Script oder Report. Ohne Service-User prüft der Quickcheck die gespeicherte Config und sagt im Report, dass er die laufende nicht sehen konnte. - Offline-fähig. Läuft in der FreeBSD-Shell der Appliance oder gegen ein Snapshot-Set, auch für eine Appliance, die bereits neu aufgesetzt ist.
- Sprechende Befunde. Jeder Befund sagt, was gefunden wurde, warum es zählt und was als Nächstes zu tun ist. Die Texte sind bewusst deutsch: Das Werkzeug ist mit und für Betreiber im DACH-Raum entstanden, und ein Befund, der erst übersetzt werden muss, kostet Zeit in der Situation, in der Zeit zählt.
- Herkunft je Indikator. Jeder Wert in der Regeldatei nennt seinen Erstveröffentlicher mit Fundstelle und Datum. Werte ohne Primärquelle bleiben inaktiv. Nachzulesen in CREDITS.md und im Herkunftsprotokoll.
- Getestet vor jedem Release. Testlogs je CVE, Fixtures mit erwarteten Verdicts und Plattform-Lints für die NetScaler-Shell.
- Methode im Repository. Die zwei Prompts, mit denen Regeln aus einem neuen Bulletin entstehen, liegen offen. Jeder Patch durchläuft dieselbe Lint-, Herkunfts- und Dublettenprüfung.
Schnellstart
Zwei Dateien. Ein Befehl.
Für eine Appliance werden nur
ns_quickcheck.sh und ns_quickcheck.rules aus dem aktuellen Release benötigt.# Appliance, als root. Upload per SCP im Modus Binary. mkdir -p /var/nssnapshot && cd /var/nssnapshot # nur bei der ersten Einrichtung: cp ns_quickcheck.conf.example ns_quickcheck.conf; cp ns_quickcheck.whitelist.example ns_quickcheck.whitelist chown root:wheel ns_quickcheck* && chmod 700 ns_quickcheck.sh && chmod 600 ns_quickcheck.conf ns_quickcheck.rules ns_quickcheck.whitelist sh ns_quickcheck.sh # Report und JSON unter /var/nssnapshot/quickcheck/ echo EXIT=$? # 0 OK, 1 INVESTIGATE, 2 UPDATE oder FORENSICS_FIRST, 3 Abbruch
Zuerst die letzten Zeilen lesen: ACTION und RESULT. Vor dem ersten Lauf auf einer neuen Appliance den Abschnitt zum ersten Lauf (7a) in der Dokumentation lesen; beim ersten Lauf sind zwei bis fünf Regel- oder Whitelist-Einträge je Appliance-Typ zu erwarten.
Was ein OK bedeutet
OK heißt: Build gefixt, kein bekannter Indikator getroffen, keine Spuren im Fenster. Es heißt nicht, dass die Appliance sauber ist.
Der Quickcheck ist musterbasiert. Ein Angreifer mit Pfaden oder Namen, die noch niemand veröffentlicht hat, bleibt für jede regelbasierte Prüfung unsichtbar. War die Appliance vor dem Fix exponiert, empfehlen wir den IoC-Scan des Herstellers als unabhängige zweite Meinung: die Funktion Indicators of Compromise der NetScaler Console oder, ohne Console, den Scanner des Citrix Supports.
Weitere Grenzen: Stock-Zustände in Block 5 stammen aus 14.1, auf 13.1 und FIPS sind beim ersten Lauf gelbe Befunde zu erwarten.
NetScaler Integrity Baseline
Prüfen. Festhalten. Vergleichen.
Der Quickcheck ist Teil 1 von 3. Er läuft eigenständig. Snapshot und Collector erweitern ihn um Zeitreihe und zentrale Auswertung und sind auf Anfrage erhältlich.
VERFÜGBAR
netscaler-quickcheck
Triage auf der Appliance mit Verdict. Mit --compare der Vergleich gegen den letzten Snapshot: Web-Dateien, Cron, Listener, Config.
AUF ANFORDERUNG
netscaler-snapshot
Täglicher Datei-Snapshot je Appliance mit Manifest und SHA-256, Zustand von Prozessen, Listenern, Cron und laufender Config. Lab-validiert auf 14.1.
BETA
netscaler-collector
In Entwicklung. PowerShell-7-Collector außerhalb der Appliance: Import, Tagesdiff mit Klassifizierung, Ampel-Report, IoC-Nachscan über 90 Tage.
Das Projekt
Vier Bulletins. Vier Wochen. Ein Werkzeug.
netscaler-quickcheck ist im Oktober 2026 entstanden. Ab dem 7. Oktober lief es als Beta auf Lab- und Kundengateways, am 21. Oktober folgte die Veröffentlichung auf GitHub.
Ende September 2026 begann für NetScaler-Betreiber eine Serie kritischer Sicherheitsmeldungen:
- 27.09. CTX697096
u. a. CVE-2026-88771, Pre-Auth RCE, CVSS 9.5, aktiv ausgenutzt; CVE-2026-88772, DTLS RCE - 03.10. CTX697174
CVE-2026-88779, SAML DoS, im CISA-Katalog ausgenutzter Schwachstellen - 08.10. CTX697191
CVE-2026-107406, SAML Memory Overflow, CVSS 9.5, kein Workaround - 22.10. CTX697263
CVE-2026-109618 und 109619, PHP im Management-Portal - laufend neue Updates
Ein Update beantwortet nur eine Frage: Ist die Lücke jetzt geschlossen? Ob vorher schon jemand auf der Appliance war, sagt es nicht. Für diese zweite Frage ist der Quickcheck entstanden.
Gebaut für das nächste Bulletin. Das Ziel war, beim nächsten Mal besser vorbereitet zu sein. Deshalb liegen die beiden KI-Prompts, mit denen Regeln entstehen, offen im Repository. Damit können auch Betreiber ohne tiefes NetScaler-Wissen aus einem neuen Bulletin schnell eine Regel erstellen. Jeder Regel-Patch durchläuft dieselben Prüfungen wie unsere: Syntax, Herkunft je Wert, Dubletten, Testlogs.
Design, Code, Testdaten und Dokumentation sind mit einem KI-Assistenten (Claude von Anthropic) als Arbeitspartner entstanden. Das war Absicht: Wir wollten zeigen, dass Verteidiger im selben Tempo arbeiten können wie die Angreifer, die dieselben Werkzeuge nutzen.
Was die KI nicht entschieden hat: was als Beleg zählt. Jeder Indikator in der Regeldatei ist auf seinen Erstveröffentlicher zurückgeführt. Jede Änderung läuft durch die Testsuite. Jeder hier beschriebene Befund wurde auf echten Appliances geprüft, bevor er zur Regel wurde.
The Force is not only strong with the dark side.
May the Force be with you, and with your gateways.
Jens Miltenberger
Autor und Maintainer
Director Consulting Services, ceterion AG. Seit 2004 mit Citrix-Appliances befasst, vom Net6 Access Gateway bis zu den heutigen ADC- und Gateway-Builds. Der Quickcheck läuft täglich auf Lab- und Kundengateways; die Befunde hinter Regeln und Testdaten stammen aus diesen Läufen.
Unterstützung durch ceterion
Einführen. Einordnen. Betreiben.
Der Quickcheck funktioniert vollständig ohne uns. Wenn Sie Erfahrung und Zeit dazu brauchen, unterstützen wir Sie an drei Stellen.
EINFÜHRUNG
„Wir wollen den Quickcheck einsetzen.“
Wir richten den Read-only-Service-User ein, begleiten den ersten Lauf je Appliance-Typ und ordnen jede rote und gelbe Zeile mit Ihnen ein. Bestätigte Zustände landen in Ihrer Whitelist. Sie erhalten eine Zusammenfassung für IT-Leitung und Management.
Festpreis-Paket, Umfang nach Anzahl der Appliances
EINORDNUNG
„Der Quickcheck zeigt Rot oder Gelb.“
Wir bewerten Ihre Befunde anhand der anonymisierten Reports, geben eine klare Handlungsempfehlung und stimmen uns im Verdachtsfall mit dem Citrix Support ab. Ist eine forensische Untersuchung nötig, binden wir spezialisierte Partner ein.
Pauschale je Einordnung oder als Kontingent
BETRIEB
„Wir wollen das dauerhaft.“
Täglicher Snapshot, zentrale Auswertung mit dem Collector, Regelpflege bei neuen Citrix-Bulletins und ein monatlicher Ampel-Report. Dokumentiert und wiederholbar, auch als Nachweis gegenüber Revision und Aufsicht.
Laufender Vertrag
Kostenlose Ersteinordnung: Senden Sie uns den anonymisierten Report Ihres ersten Laufs (_anon.txt, _anon.json). Wir melden uns mit einer kurzen Einschätzung, einmal je Organisation. Originaldaten Ihrer Appliances brauchen wir dafür nicht.
Bitte vor dem Versand eine Stichprobe prüfen: Fremde Host- und Benutzernamen in Logzeilen bleiben Klartext.
DIREKTER KONTAKT
Wir antworten persönlich
Fragen und Erstlauf-Reports:
netscaler-integrity@ceterion.com
Bitte nur die anonymisierten Fassungen senden (_anon.txt, _anon.json), nie den Original-Report.
Sicherheitsdefekte im Script:
security@ceterion.com, nie als öffentliches Issue
Fehlalarme und übersehene Indikatoren:
Issue auf GitHub
Ein Verdict ist keine Freigabe. Auch nach unserer Einordnung gilt: OK heißt, kein bekannter Indikator wurde getroffen. Es heißt nicht, dass die Appliance sauber ist.
Fragen? Wir helfen gerne weiter.
Hier finden Sie schnelle Antworten – oder kontaktieren Sie uns auch gerne direkt.
Nichts. Das Werkzeug ist Open Source unter der Apache License 2.0 und darf auch kommerziell eingesetzt werden. Es wird "AS IS" bereitgestellt, ohne Gewährleistung.
Nein. Es baut keine Netzverbindung auf, ändert weder Konfiguration noch Systemdateien und schreibt nur in seine eigenen Verzeichnisse unter /var/nssnapshot/.
Validiert auf NetScaler 14.1 (73.41 und 73.46). 13.1 und FIPS sind Beta: CVE-Tabelle und Logprüfungen gelten unverändert, für die Stock-Zustände in Block 5 sind beim ersten Lauf gelbe Befunde zu erwarten.
Nein. Er ergänzt ihn. Bei einer vor dem Fix exponierten Appliance empfehlen wir beide: den Quickcheck für Triage und Zeitreihe, den IoC-Scan des Herstellers als unabhängige zweite Meinung. Ein Verdict ersetzt keine forensische Untersuchung.
Bei neuen Citrix-Bulletins erscheint ein neuer Regelstand im Repository. Eigene Indikatoren und Fix-Builds pflegen Betreiber in einer Custom-Datei, die beim Update nicht ersetzt wird.
Ja, aber nur die anonymisierten Fassungen. Jeder Lauf erzeugt sie automatisch: Konten- und Hostnamen maskiert, Angreiferwerte erhalten, mit stabiler Zuordnung je Appliance. Die Zuordnungstabelle bleibt auf der Appliance und wird nie weitergegeben. Vor dem Versand eine Stichprobe prüfen: Fremde Host- und Benutzernamen in Logzeilen bleiben Klartext.
Feldnamen, Verdicts und die RESULT-Zeile sind sprachneutral und englisch dokumentiert, damit SIEM, SOC und nicht deutschsprachige Leser damit arbeiten können. Eine englische Ausgabe der Befundtexte ist geplant.
netscaler-quickcheck wird von der ceterion AG unter der Apache License 2.0 veröffentlicht und „AS IS“ ohne Gewährleistung bereitgestellt (Disclaimer). Ein Verdict ersetzt weder eine forensische Untersuchung noch eine Aussage des Herstellers.
Citrix und NetScaler sind Marken der Cloud Software Group, Inc. netscaler-quickcheck ist kein Produkt der Cloud Software Group und wird von ihr weder unterstützt noch geprüft.