NetScaler (CTX697096): dacă dai patch primul, s-ar putea să nu afli niciodată că ai fost compromis

Când Citrix a publicat CTX697096, o vulnerabilitate critică deja exploatată, fără soluție temporară și fără indicatori de compromitere publicați, ordinea corectă de lucru nu e „dă patch”, ci „verifică întâi dacă ai fost deja compromis, apoi dă patch”. Braincap a lucrat cu mai mulți clienți care rulează NetScaler ADC și Gateway pe exact acest scenariu. Acest articol descrie ordinea de lucru pe care o folosește echipa, ce caută pe echipamente și ce găsește aproape de fiecare dată.

Pe 27 septembrie 2026, după-amiaza, Citrix a publicat buletinul CTX697096 pentru NetScaler ADC și NetScaler Gateway. Buletinul acoperă opt vulnerabilități. Două dintre ele erau deja exploatate în momentul publicării, iar cea mai gravă, CVE-2026-88771, permite executarea de cod de la distanță fără autentificare, pe orice configurație, inclusiv cea implicită.

Pentru cine administrează NetScaler, combinația e cea mai proastă posibilă. Nu există o setare care să închidă vulnerabilitatea până la upgrade. Nu se știe exact pe ce cale se exploatează. Nu există indicatori de compromitere oficiali. Singura remediere e patch-ul, iar patch-ul nu spune nimic despre ce s-a întâmplat înainte de el.

CTX697096, pe scurt

CVE	Tip	CVSS 4.0	Condiție
2026-88771	RCE fără autentificare · exploatat	9.5	Orice configurație
2026-88772	Memory overflow, RCE/DoS · exploatat	9.5	DTLS activ (implicit pe VPN vserver)
2026-88773	HTTP request smuggling	9.3	Vserver HTTP sau SSL (LB, CS, VPN, AAA)
2026-88774	Ocolirea politicilor pe URL	7.0	Politici bazate pe URL
2026-88775…77	Memory overflow, DoS	8.8	Gateway/AAA, LB ORACLE, FTP, LSN, DNS64, NAT64
2026-88778	ISN TCP predictibil	8.8	Vservere TCP fără Enhanced ISN Generation

Build-uri corectate: 14.1-73.37, 13.1-64.23 și 13.1-37.279 (FIPS/NDcPP). Linia 13.0 nu apare în buletin: e end-of-life și nu va primi patch.

Actualizare, 30 septembrie 2026: au apărut indicatori oficiali

La momentul primelor verificări nu existau IoC publicați. Pe 30 septembrie, Google Threat Intelligence Group și Mandiant au publicat o analiză cu indicatori și tehnici, iar GreyNoise a confirmat exploatare încă de pe 24 septembrie. Unit 42 (Palo Alto) a mers și mai în urmă: a observat activitate de fingerprinting încă din 21 august, iar exploatarea pre-dezvăluire s-a desfășurat între 21 august și 24 septembrie — atacatorii sondau infrastructura cu aproape cinci săptămâni înainte de buletin. A fost, deci, un zero-day real, folosit mult înainte de patch. Iată ce s-a confirmat.

Amploarea campaniei. Potrivit Censys, pe 28 septembrie erau expuse pe internet peste 42.000 de host-uri NetScaler ADC și Gateway. Google Threat Intelligence Group și Mandiant descriu un val de exploatare în masă început tot pe 28 septembrie, cu zeci de organizații afectate din administrație, servicii financiare, tehnologie, educație și servicii juridice, în America de Nord și Europa. Cele două vulnerabilități exploatate sunt CVE-2026-88771 (RCE fără autentificare, livrat prin User-Agent Base64) și CVE-2026-88772 (memory overflow în procesarea DTLS).

Ce lasă atacatorii pe echipament. Au fost numite două familii de malware: WHIPSHOT, un web shell PHP care ascunde comenzi Base64 în anteturi HTTP, și SLAPSHOT, un tunel scris în Python pentru mișcare în rețeaua internă. GreyNoise a documentat separat și un web shell mascat drept fișier al portalului (.ctxs.receiver, cu alias-uri de tip receiver.min.css).

Persistență și anti-forensics confirmate. Atacatorii modifică httpd.conf ca să execute drept PHP extensii care nu sunt PHP (de exemplu .deb sau .sig), maschează web shell-urile drept cereri de imagine (.ico redirecționate către scripturi), pun bitul SUID pe /bin/sh, repornesc echipamentul, apoi șterg din loguri urmele căilor de instalare. Ultima parte confirmă de ce snapshot-ul și trimiterea logurilor în SIEM, dinainte, nu sunt opționale: logurile locale pot fi curățate de atacator.

Semne de detecție noi. Pe lângă verificările din acest articol, indicatorii publicați permit acum căutări țintite:

• artefacte SLAPSHOT: fișierele /tmp/.uxdport și /tmp/.uxdlock;
• configurație de server web modificată: grep -Eni 'application/x-httpd-php|php_flag|AliasMatch' /etc/httpd.conf;
• /bin/sh cu bitul SUID (și SGID) setat (chmod 6555);
• anteturi de C2 în cereri: HTTP_NSC_LDAP, HTTP_NSC_CLIENTTYPE, HTTP_X_UX;
• în loguri, eșecuri de handshake DTLSv1.0 pe UDP 443 și crash-uri de proces NSPPE, corelate cu exploatarea prin DTLS;
• lanțul de exploatare CVE-2026-88771 prin log poisoning: grep -i 'pitboss PPE missed too many heartbeats NSPPE' /var/log/ns.log, plus un User-Agent cu payload Base64 în httpaccess-vpn.log (stagiul inițial, injectat în log și executat ulterior);
• web shell .ctxs.receiver activat prin cookie: cereri care poartă CsrfToken împreună cu NSC_TASS (canalul de comandă).

Mandiant a publicat și reguli YARA și de detecție pentru aceste artefacte, plus adresele IP de scanare și de exploatare. Listele complete și amprentele sunt în sursele de la finalul articolului; folosiți-le ca semnături, nu ca listă exhaustivă.

Măsuri compensatorii dacă nu poți da patch pe loc. Dezactivează DTLS unde e posibil sau restricționează UDP 443 la firewall, fiindcă acolo se livrează exploit-ul. Rotește certificatele, parolele de administrator, cheile SSH și conturile de serviciu, și invalidează sesiunile active.

De ce HTTPS nu te protejează

Prima reacție pe care echipa o aude des de la clienți: „managementul e accesibil doar din rețeaua internă, iar aplicațiile sunt publicate doar pe HTTPS”. Pentru această clasă de vulnerabilități, argumentul nu ține. NetScaler-ul este cel care termină TLS-ul. Cererea atacatorului e decriptată și ajunge la motorul HTTP vulnerabil exact ca o cerere legitimă. Cât timp vectorul exact al lui CVE-2026-88771 nu e public, fiecare VIP publicat pe internet trebuie tratat ca o cale posibilă de atac.

Iar miza e mare. Un NetScaler compromis înseamnă cheile private TLS ale tuturor site-urilor din spatele lui, credențialele din configurație (conturi LDAP de serviciu, monitoare), traficul decriptat și un punct de pornire spre serverele interne.

Ordinea de lucru: incident, nu mentenanță

Echipa tratează un astfel de buletin ca incident, nu ca mentenanță programată. Ordinea contează: dacă faci întâi upgrade și abia apoi te întrebi dacă ai fost compromis, e posibil să fi șters exact urmele pe care le cauți.

Inventar și expunere, doar în citire, prima oră. Un cont dedicat, limitat la comenzi show și stat, și un script care citește prin API-ul NITRO versiunea, hardware-ul și configurația curentă, apoi aplică condițiile din buletin pe fiecare echipament. Rezultatul e o matrice echipament pe CVE, cu „vulnerabil”, „nu se aplică” sau „patch aplicat”.

Verificarea de compromitere, înainte de patch, circa 20 de minute pe nod. Pe fiecare nod al fiecărei perechi HA, separat. Detaliile sunt în secțiunea următoare.

Upgrade pe perechea HA, în aceeași fereastră. Întâi nodul secundar, apoi failover, apoi fostul primar. Pe secundar, înainte de failover, se compară configurația salvată înainte de upgrade cu cea încărcată după, ca să se vadă dacă noua versiune a pierdut obiecte la încărcare. Apoi setările recomandate de buletin, de exemplu set ns tcpParam -enhancedISNGeneration ENABLED, și rularea din nou a scriptului de verificare, până apare PATCHED.

Echipamentele fără patch: migrare, nu upgrade. Pentru echipamentele pe linia 13.0 nu există patch. Serviciile active se mută pe un NetScaler actualizat, aplicație cu aplicație, fără schimbarea IP-urilor publice sau a DNS-ului: trecerea se face pe firewall, cu posibilitate de revenire în sub un minut. După fiecare mutare, verificare din internet. Echipamentele vechi nu mai au nimic publicat și se decomisionează.

Cum cauți indicatori când nu există IoC oficiale

La primele verificări nu existau indicatori publicați pentru CVE-2026-88771 (au apărut ulterior, vezi actualizarea de mai sus), așa că baza rămâne tiparele compromiterilor NetScaler din anii trecuți, seria CitrixBleed și campaniile din 2023…2025. Ce se caută: web shell-uri în directoarele web, cod JavaScript injectat în pagina de login a Gateway-ului pentru furtul de credențiale, persistență prin cron sau scripturi de boot, chei SSH adăugate, procese și conexiuni anormale.

Trei reguli înainte de prima comandă. Faceți snapshot VM pentru fiecare nod. Lucrați doar în citire: un fișier suspect nu se șterge și nu se mută, e probă. Înregistrați sesiunea și calculați hash-ul fișierului la final.

Cea mai bună referință e celălalt nod al perechii. Fișierele Citrix sunt identice pe nodurile aceleiași perechi, pe același build. Un atacator compromite de obicei un singur nod, așa că orice diferență între noduri care nu are o explicație devine „de investigat”. Toate comenzile de mai jos se rulează în shell-ul NetScaler și nu modifică nimic.

1. Scripturi în directoarele web

find /var/netscaler/logon /var/vpn /var/netscaler/ns_gui -type f \( -name '*.php' -o -name '*.pl' \
  -o -name '*.py' -o -name '*.sh' -o -name '*.xhtml' \) -exec ls -la -T {} \; 2>/dev/null

Normal: de regulă un singur fișier, themes/EULA/eula_upgrade.pl, script Citrix, identic pe ambele noduri.

Alarmă: orice alt .php, .pl, .py sau .sh, mai ales sub /var/netscaler/logon sau /var/vpn.

2. Integritatea paginii de login

grep -o '<script[^>]*src=”[^”]*”' /var/netscaler/logon/LogonPoint/index.html | sort -u
find /var/netscaler/logon -type f \( -name '*.js' -o -name '*.html' -o -name '*.pl' -o -name '*.php' \) \
  -exec sha256 -r {} + | sort -k2 | sha256

A doua comandă produce o singură amprentă pentru tot portalul. Rulată pe ambele noduri, dacă amprentele coincid, portalul e identic. Dacă nu, se listează fișier cu fișier și se compară.

Normal: surse de scripturi cu căi relative; custom/script.js e șablonul Citrix, cu exemplul comentat.

Alarmă: un script încărcat de pe alt domeniu; fetch, XMLHttpRequest, atob, eval sau referințe la câmpul de parolă în scripturile portalului.

3. Persistență: cron, scripturi de boot, binare setuid

grep -v '^#' /etc/crontab; ls -la /var/cron/tabs/; cat /var/cron/tabs/* 2>/dev/null
cat /flash/nsconfig/rc.netscaler 2>/dev/null
find /var /tmp /flash/nsconfig -type f -perm -4000 -exec ls -la -T {} \; 2>/dev/null

Normal: aceleași intrări cron pe ambele noduri; rc.netscaler gol sau cu setări cunoscute; niciun binar setuid în aceste directoare.

Alarmă: curl, wget, nc, perl sau python spre adrese externe; intrări pe care nu le explică nimeni din echipă.

4. Chei SSH autorizate

ssh-keygen -lf /root/.ssh/authorized_keys 2>/dev/null
ssh-keygen -lf /flash/nsconfig/ssh/authorized_keys 2>/dev/null
ls -lc -T /root/.ssh/authorized_keys /flash/nsconfig/ssh/authorized_keys 2>/dev/null

Se compară amprentele cheilor autorizate cu cheile private existente pe echipament (cheia de comunicare HA a perechii). O cheie autorizată pentru care nu există pereche privată cunoscută e o ușă pe care cineva a lăsat-o deschisă. Poate fi o rămășiță dintr-o intervenție veche, poate fi altceva: în ambele cazuri trebuie să aibă un proprietar.

5. Procese, conexiuni, erori ale serverului web

ps -axo user,pid,ppid,lstart,command | egrep -i '^(nobody|www)' \
  | egrep -i 'sh |bash|perl|python|php|nc |curl|wget|socat'
netstat -an -p tcp | grep ESTABLISHED
zgrep -hiE 'sh: |/bin/sh|base64|wget|curl|\.php' /var/log/httperror.log* 2>/dev/null | tail -40

Normal: niciun shell pornit de userul serverului web; conexiuni doar spre rețelele interne și între nodurile HA (porturile 3008…3011).

Alarmă: procese sh, perl sau python ca nobody; conexiuni stabilite spre IP-uri publice necunoscute; mesaje de shell în httperror.log. Un proces suspect nu se oprește înainte de salvarea probelor.

6. Useri, accese de management și timestamp-uri falsificate

awk -F: '$3==0 || $7 ~ /sh$/ {print $1”:”$3”:”$7}' /etc/passwd
zgrep -h 'Remote_ip' /var/log/ns.log* | sed 's/.*User \([^ ]*\).*Remote_ip \([0-9.]*\).*/\1 \2/' \
  | sort | uniq -c | sort -rn
ls -la -T <fișier>; ls -lc -T <fișier>

Ultima pereche de comenzi e utilă pentru orice fișier suspect. mtime poate fi dat înapoi cu touch, ctime nu. Un fișier cu data de modificare veche și ctime de săptămâna trecută a fost atins recent de cineva care a vrut să nu se vadă.

7. Dacă rulează Gateway sau AAA

Aici s-au concentrat campaniile din ultimii ani. În plus față de cele de mai sus, se caută în configurație acțiuni rewrite sau responder care inserează <script> ori trimit spre domenii străine, acțiuni de autentificare (LDAP, RADIUS, SAML, OAuth) spre servere nerecunoscute și sesiuni active neobișnuite (show aaa session, show vpn icaconnection). Sesiunile nu se închid în această etapă: e o decizie care vine după escaladare.

Fals pozitive care te pot speria

În prima seară a fiecărui astfel de exercițiu se pierde timp investigând lucruri perfect normale. Le lăsăm aici, ca să nu-l pierzi și tu:

Ce vezi	Explicația
eula_upgrade.pl rescris recent	Daemonul de sincronizare HA (nsfsyncd) reface periodic tot arborele /var/netscaler/logon, deci fișierele apar ca modificate în grup, la aceeași secundă. Hash-ul e același pe toate echipamentele și versiunile.
/tmp/appfw*	Sute sau mii de directoare rămase de la job-urile Application Firewall. Nu sunt un semn de compromitere; se curăță separat.
crontab diferit	NetScaler alege aleatoriu minutul pentru nslog.sh, deci crontab-ul diferă între noduri doar la minut.
biblioteci JS diferite	jQuery sau Hammer cu versiunea în nume, minificate diferit pe cele două noduri, rămase din upgrade-uri vechi și neîncărcate de nicio pagină.
conexiuni 3008…3011	Traficul HA RPC între noduri. Poate apărea spre adrese „publice” dacă perechea folosește intern blocuri de adrese care nu sunt private.

Ce găsește Braincap aproape de fiecare dată

Un audit făcut în grabă, sub presiunea unui buletin critic, scoate la iveală și lucruri fără legătură directă cu vulnerabilitatea, dar care contează la fel de mult. La clienți, se repetă câteva:

• Log-uri locale de două zile. Pe NetScaler, retenția implicită e scurtă, iar pe unele echipamente vechi există scripturi cron care șterg zilnic log-urile de performanță și core dump-urile. Fără forwarding către un SIEM, activitatea de acum o săptămână nu mai poate fi reconstituită.
• Parola RPC implicită între nodurile HA. Cine ajunge pe porturile RPC poate trimite configurație. Se schimbă cu set ns rpcNode ... -secure ON.
• Chei SSH fără proprietar. Rămase din intervenții vechi, sincronizate de HA pe ambele noduri, necunoscute echipei actuale.
• Echipamente EOL uitate. Un NetScaler care nu a mai fost repornit de peste doi ani și care încă publică aplicații pe internet.
• Antete care vorbesc prea mult. Aplicațiile își anunță serverul web, versiunea limbajului, iar uneori chiar IP-ul intern al serverului. Câteva politici rewrite globale le șterg pe toate vserverele.
• Pool-uri fără monitor. Verificarea implicită TCP ține „UP” un server a cărui aplicație răspunde doar cu erori, iar serverul de rezervă nu preia niciodată traficul.

Dacă găsești ceva

• Oprește verificarea și nu modifica nimic. Nu reporni nodul, nu opri procese, nu șterge fișiere.
• Nu face upgrade peste un echipament compromis. Upgrade-ul nu elimină persistența și poate distruge urmele.
• Salvează probele: snapshot nou, sesiunea înregistrată cu hash, copii ale fișierelor suspecte și show techsupport -scope NODE.
• Escaladează. Pentru instituțiile financiare, un incident TIC major are termene scurte de raportare sub DORA; decizia de izolare și raportare aparține organizației.
• Reconstruiește, nu curăța. Echipament nou, dintr-o imagine curată, pe versiunea cu patch. Rotește certificatele TLS, parola nsroot și a administratorilor, conturile de serviciu LDAP sau RADIUS, parolele RPC. Invalidează sesiunile VPN.

Ce nu poate dovedi o verificare curată

Când toate nodurile verificate ies curate, asta nu e o garanție, și e corect s-o spunem deschis. Fără IoC oficiale, se caută doar tiparele cunoscute. Log-urile locale acoperă puține zile. Verificarea surprinde un singur moment: un atacator care și-a șters urmele sau care rulează doar în memorie nu apare. De aceea se păstrează snapshot-urile de dinainte de upgrade, se caută în SIEM pe toată perioada de expunere și se reia verificarea când Citrix sau comunitatea publică indicatori.

Iar un rezultat curat nu închide vulnerabilitatea. Singura remediere rămâne upgrade-ul, iar pentru echipamentele end-of-life singura remediere e să nu mai fie expuse.

Pe scurt

• Tratează un buletin critic cu exploatare activă ca pe un incident: inventar, verificare, abia apoi patch.
• Compară nodurile perechii HA între ele: e cea mai bună referință pe care o ai.
• Trimite log-urile într-un SIEM înainte să ai nevoie de ele.
• Nu upgrada peste un echipament compromis; reconstruiește-l.
• Scoate echipamentele EOL de pe internet, chiar dacă „merg”.

Braincap oferă verificări de compromitere și planuri de remediere pentru NetScaler ADC și Gateway, la clienți din mai multe sectoare. Articolul reflectă informațiile disponibile la 29 septembrie 2026; verifică întotdeauna buletinul Citrix pentru versiunile corectate curente. Ai nevoie de o verificare pe echipamentele tale? Scrie-ne.

Surse

• Citrix: buletinul de securitate CTX697096
• BleepingComputer: Citrix confirmă două zero-day-uri NetScaler exploatate în atacuri
• watchTowr: NetScaler zero-day RCE, întrebări frecvente (CVE-2026-88771 și CVE-2026-88772)
• Tenable: întrebări frecvente despre zero-day-urile Citrix NetScaler
• Google Threat Intelligence Group și Mandiant: apărarea împotriva exploatării active a NetScaler (indicatori și tehnici)
• GreyNoise: exploatarea zero-day-ului Citrix, telemetrie și indicatori
• The Hacker News: atacatorii exploatează în masă vulnerabilitatea NetScaler (amploare, cronologie, sectoare)
• Unit 42 (Palo Alto): zero-day-urile NetScaler exploatate (cronologie din 21 august, lanțul de log poisoning, IoC)