In Hunting Citrix NetScaler Zero-Days with Corelight, we explored how network evidence from Corelight’s Open Network Detection and Response (NDR) Platform can help identify candidate NetScaler appliances, observe DTLS use and hunt for suspicious activity. This follow-up examines a clue recorded by an existing DTLS analyzer from the Zeek® Project (a non-profit project that maintains an open-source software platform which generates compact, high-fidelity transaction logs, file content, and fully customizable outputs), and shows how defenders can use it within Corelight Open NDR to investigate potential exploitation attempts. For teams retaining the relevant analyzer logs, this investigation can extend to historical traffic—including activity recorded before the vulnerability was disclosed.
CVE-2026-88772 is a memory overflow vulnerability in Citrix NetScaler’s DTLS processing. watchTowr's technical analysis describes a mismatch between how NetScaler accounts for handshake fragments and how much received data it retains and later copies. The crafted records describe small fragments while carrying substantially more data. The vulnerable processing path can accumulate that data and overflow a fixed-size buffer.
The relevant handshake bytes in the tested capture are visible before encryption protects subsequent traffic, allowing Corelight Open NDR to analyze them without decrypting application data.
We replayed a loopback proof-of-concept capture associated with CVE-2026-88772 through Zeek in an offline test. Zeek metadata is a key part of the forensic-grade network evidence that powers Corelight Open NDR.
Selected fields from the offline replay’s analyzer.log record, reformatted for readability; the unique ID (UID) from Zeek metadata is redacted.
The check compares the length of the handshake data available to Zeek’s NDR parser with the fragment length declared in the handshake header. The resulting diagnostic gives defenders a concrete starting point for searching retained logs for similar inconsistencies.
The related ssl.log record, linked by the same connection UID, provided additional context:
Selected fields from the offline replay logs, reformatted for readability.
A matching diagnostic warrants investigation.
Start with analyzer.log. The sensor must have observed enough of the relevant traffic to analyze it, and these records must be exported and retained in your search platform. The following LogScale example uses #path=analyzer and the fields shown in our replay. Check the path and field mapping in your deployment before using it operationally:
For deployments that retain these events under different log paths, the following alternative searches both analyzer and dpd and accepts either cause="violation" or proto="udp". Use it where those fields are present and the analyzer name is stored as analyzer_name; older native dpd.log records use analyzer, so their field mapping requires adjustment.
Start by establishing whether the suspicious DTLS traffic reached a NetScaler listener. Use the discovery searches in Part 1: Hunting Citrix NetScaler Zero-Days with Corelight to gather supporting evidence from TLS names, certificates, observed DTLS sessions and, where visible, HTTP fingerprints and high-availability communications. Reconcile those findings with your asset inventory and virtual IP mappings, then check the appliance’s software version and configuration against the vendor’s advisory.
With the destination understood, examine the session that produced the diagnostic. Use the analyzer record’s connection identifier, UID, to find related conn.log and ssl.log records from the same sensor and time window. These records help establish who communicated with the destination, whether replies were observed and how far the handshake progressed. If packet capture is available, inspect the associated traffic to examine the record and fragment layout and look for subsequent application traffic.
Next, search for other matching diagnostics involving the same source or destination. This helps establish whether the observed activity involves repeated connections to one appliance or traffic directed at several systems. For relevant NetScaler destinations, correlate the timing with appliance errors, process restarts and unexpected subsequent connections. Those observations can help assess impact; the DTLS diagnostic alone does not establish the outcome.
A normal DTLS cookie exchange can include a client ClientHello, a server HelloVerifyRequest and another client ClientHello carrying the cookie. Zeek metadata may represent that sequence as CvC in ssl_history. The sequence alone does not indicate exploitation or establish that the server accepted the cookie and completed the handshake.
In the tested loopback capture, Corelight’s Open NDR Platform recorded ssl_history=CvCl, including a server-side alert after the opening sequence. The last recorded alert was protocol_version, and Corelight did not mark the session as established. An alert description such as protocol_version or unexpected_message provides context, but the last_alert field alone does not identify the sender, establish fatal severity or prove exploitation.
This laboratory replay demonstrates how Corelight Open NDR records the malformed DTLS traffic via Zeek metadata and provides related handshake context. Assessing the impact on a NetScaler requires correlating those observations with evidence from the appliance.
When new vulnerability research lands, existing protocol logs become hunting leads. In this case, existing Zeek logic produced a searchable diagnostic from a tested NetScaler PoC capture without a new CVE-specific package.
For Corelight users with the relevant logs available, that provides another investigation path alongside asset discovery, packet inspection and other detections. According to the NetScaler security bulletin, continued remediation is required as a useful hunt does not replace patching.
Found this blog helpful? You can read other Zeek blogs here.
