Citrix NetScaler CVE-2026-3055 Forensics: Post-Exploitation Detection for SAML IDP Compromise

The confirmation of large-scale CVE-2026-3055 exploitation on 28 May creates a mandatory forensic review requirement for any NetScaler ADC appliance that:

1. Had the SAML IDP service configured
2. Was accessible from the internet on TCP 443
3. Was not patched before 28 May (or was patched recently after a period of exposure)

This guide covers the available forensic evidence on NetScaler ADC appliances and the indicators that distinguish exploitation attempts from legitimate SAML traffic.

Available Log Sources

NetScaler ADC logging for security forensics draws from several sources:

NetScaler ns.log: The primary application log, typically at /var/log/ns.log. This log records policy matches, session events, AAA authentication events, and system errors. For SAML IDP exploitation, look for:

• Malformed SAML AuthnRequest error entries referencing the SAML IDP virtual server
• Memory allocation errors (ALLOC_FAIL or similar) that may indicate the memory overread triggering unexpected heap behaviour
• High volumes of SAML IDP requests from single source IPs in a short window (automated exploitation scanning)

NSHTTP (HTTP access logs): NetScaler’s HTTP access logs, if enabled, record all HTTP requests including SAML endpoint requests. Enable via: set ns httpProfile -dropInvalReqs ENABLED and check logging via show ns httpProfile. Look for requests to the SAML IDP endpoint (/saml/login or the configured binding URL) from source IPs outside the expected user population.

Syslog and CEF/SIEM forwarding: If the NetScaler is configured to forward logs to a SIEM (as it should be), query the SIEM for:

sourcetype=citrix_netscaler 
event_type=SAML 
SAML_AUTHN_REQUEST 
error OR fail OR malform
| stats count by src_ip, error_message
| where count > 10

Indicators of Exploitation

Authentication bypass indicators: Successful exploitation of CVE-2026-3055 can yield session token material. Post-exploitation, an attacker possessing a valid session token would present it in subsequent authenticated requests — these would appear in logs as authenticated sessions from IP addresses inconsistent with the user’s normal location or device.

Look for:

• Authenticated SAML sessions from IP addresses not associated with the user’s normal device or location
• Multiple authenticated sessions for the same user account from different geographic locations within a short time window
• Sessions established outside business hours for accounts with no travel or remote work history

SAML signing key compromise: If SAML signing key material was extracted via the memory overread, an attacker could forge SAML assertions without touching the NetScaler. This is harder to detect from the NetScaler side — the downstream service provider (the application receiving SAML assertions) would see valid-looking signed assertions from legitimate user accounts.

For detection at the service provider level: look for SAML assertions presented for accounts at times inconsistent with the user’s normal authentication patterns, or for accounts that have not authenticated to the NetScaler SAML IDP in the same session.

Post-Compromise Remediation

If exploitation indicators are found:

1. Rotate SAML signing certificates: Generate new signing certificates for all SAML IDP configurations on the affected appliance and update the metadata at all SAML Service Providers
2. Invalidate active sessions: Force re-authentication for all sessions established on the affected appliance during the exposure window
3. Rotate any credentials cached by the SAML service: If the NetScaler SAML IDP authenticated to back-end LDAP/AD, rotate the service account credentials used for that authentication
4. Review downstream application access logs: For all applications federating through the compromised NetScaler SAML IDP, review access logs for the exposure period for anomalous authenticated activity
5. Notify affected users: If legitimate user session tokens were exfiltrated, those users’ sessions were potentially used by attackers — users should be informed and asked to review their recent account activity

For appliances where compromise is confirmed or cannot be ruled out, consider factory resetting and reconfiguring from a clean baseline rather than attempting remediation in-place.