Windows 11 Black Screen After the September Update – explorer.exe Fails to Start

After installing the September Windows updates, I came across an interesting issue in a Windows 11 VDI environment.

User authentication completed successfully. The Citrix session was established and the Windows logon process appeared to complete normally.

But instead of the desktop, the user was left with a persistent black screen.

At first glance, this looked like a typical Citrix, HDX, or user profile issue. However, troubleshooting eventually pointed in a very different direction:

Windows Shell, AppX, and XAML initialization.

And there was another interesting observation:

Removing the Windows update did not resolve the issue.

Re-registering several Windows Shell/AppX components did.

Windows 11 Black Screen After Logon – The Symptoms

The affected systems were Windows 11 VDI machines.

The actual user logon succeeded:

User Authentication
↓
Citrix Session Established
↓
Windows Logon
↓
explorer.exe Does Not Start
↓
BLACK SCREEN

The important part was that the session itself was not dead or disconnected.

From Task Manager, I could manually start: explorer.exe

Immediately afterwards, the desktop, taskbar, and Start menu appeared and the session could be used normally.

This is an important distinction when troubleshooting the issue.

If manually starting explorer.exe results in a fully functional desktop, there is little reason to immediately assume that ICA/HDX, VDA registration, or the basic Citrix session establishment is the actual problem.

The more interesting question becomes:

Why isn’t the Windows Shell starting correctly during the normal logon process?

Initially, Everything Points to Citrix or the User Profile

With a black screen on a Citrix VDA, there are several obvious suspects:

  • Citrix VDA
  • HDX
  • Citrix Profile Management
  • FSLogix
  • Group Policies
  • AppX packages
  • Start menu
  • explorer.exe
  • Shell extensions

User profile management becomes particularly suspicious if existing users are affected while users with newly created profiles can log on successfully.

However, a similar behavior can also occur outside Citrix environments.

That makes a purely Citrix-specific problem much less likely.

The common denominator appears to be closer to:

Windows 11 + VDI + persistent user state + Windows Shell.

Removing the Windows Update Did Not Fix the Problem

Considering the timing of the issue, one of the obvious troubleshooting steps was to test the system without the recently installed Windows update.

The expectation was simple:

Update Installed
↓
Black Screen

Update Removed
↓
Problem Resolved

That, however, is not what happened.

Even after uninstalling the update, the black screen remained.

This is an important observation.

Apparently, returning the Windows binaries to their previous state was not sufficient.

If an inconsistent state had already been created within the user profile or Windows Shell registration during or after the update, that state could potentially remain even after uninstalling the update.

That would also explain why simply rolling back the Windows update did not repair the affected users.

The Important Test: Start explorer.exe Manually

A very simple test helped narrow down the issue significantly.

While the user was stuck on the black screen:

Task Manager → Run new task → explorer.exe

If the taskbar, Start menu, and desktop immediately appear afterwards, we already know quite a lot:

  • The Citrix session is working.
  • The user has successfully logged on.
  • The user profile is fundamentally available.
  • Windows can display the desktop.
  • explorer.exe itself can run.

The problem therefore appears to be specifically related to the initial launch or initialization of the Windows Shell during the logon sequence.

That changes the direction of troubleshooting considerably.

The Trail Leads to Windows AppX and the Shell

The workaround that eventually made the difference was to re-register three Windows components in the user context:

These components are associated with modern Windows Shell functionality and the XAML infrastructure.

For testing, they can be re-registered using PowerShell:

And this is where things became interesting:

After re-registering the AppX/Shell packages, the normal logon started working again in my test environment.

explorer.exe launched automatically and the desktop appeared as expected.

Why This Is Technically Interesting

This paints a very different picture from a traditional Citrix black-screen issue.

A simplified version of the failing sequence could look something like this:

User Logon
↓
User Profile Loaded
↓
Windows Shell Packages
↓
AppX / XAML / Shell State
↓
Initialization Fails
↓
explorer.exe Does Not Start Correctly
↓
BLACK SCREEN

After re-registering the affected components:

User Logon
↓
Shell Packages Registered
↓
Client.CBS
UI.Xaml.CBS
Client.Core
↓
Shell State Initialized
↓
explorer.exe
↓
DESKTOP

This does not prove the exact Microsoft-side root cause.

However, the behavior provides a strong indication that the issue is located somewhere around Windows Shell/AppX/XAML initialization, rather than being a traditional Citrix HDX problem.

Why Profile Management Is Still Relevant

I would not completely remove Citrix Profile Management or FSLogix from the investigation.

Not necessarily because either product caused the issue, but because profile management may be responsible for persisting the problematic state.

This is particularly interesting in non-persistent VDI environments.

The machine itself may be reset during reboot or recompose:

Golden Image
↓
MCS / PVS Machine
↓
Clean Machine State

But the user’s profile returns:

User Logon
↓
Existing UPM / FSLogix Profile
↓
Persistent User State
↓
Windows Shell

If the problematic state exists within the user context, recomposing the machine may not help at all.

This could also explain why removing the Windows update did not resolve the issue in my test.

The problematic state was potentially already present.

Test an Existing Profile Against a New Profile

Another useful troubleshooting step is comparing an affected user with a completely new user profile.

For example:

User A
Existing Profile
→ Black Screen

User B
New Profile
→ Desktop Works

If you see this pattern, I would not immediately delete User A’s profile.

That affected profile is potentially extremely valuable for further root-cause analysis.

Instead, I would first create a backup of the affected UPM profile or FSLogix container and use it to reproduce and investigate the issue.

Resetting the profile may remove the symptom, but it may also destroy exactly the state required to determine what actually happened.

How I Would Troubleshoot This Today

If a customer reported black screens on Windows 11 VDAs following Windows patching, reinstalling the VDA would definitely not be my first step.

My troubleshooting flow would look roughly like this:

Windows 11 VDI
↓
Black Screen After Logon
↓
Open Task Manager
↓
Start explorer.exe Manually
↓
Does the Desktop Appear?
│
├── NO
│ ↓
│ Investigate Other Causes
│
└── YES
↓
Investigate Windows Shell
↓
Compare Existing vs. New Profile
↓
Check AppX / Shell Registration
↓
Re-register Shell Packages
↓
Test Logon Again

If explorer.exe works when launched manually and the normal logon starts working again after re-registering the Shell packages, I would not immediately start tearing apart ICA, HDX, or the VDA installation.

The evidence points somewhere else.

The Working Workaround

In my test environment, the successful workaround was re-registering the three Windows Shell packages during user logon.

For example, this can be implemented using a synchronously executed GPO user logon script:

Timing matters here.

The goal is not to re-register these components at some arbitrary point after the desktop has already initialized.

The required components should be correctly registered during the logon sequence before the Windows Shell completes its initialization.

I would also strongly recommend testing this workaround with a small pilot group first rather than deploying it immediately to every user.

A working workaround is useful, but it is not the same thing as a confirmed permanent fix.

What I Would Not Do

I would not immediately:

Delete all affected user profiles.

I would also not automatically:

Declare FSLogix or Citrix Profile Management to be the root cause.

And based on my testing, I would definitely not assume:

Windows Update removed = problem solved.

That was simply not the case here.

Removing the update did not change the behavior.

Only after re-registering the Windows Shell components did the normal logon start working again.

What This Tells Us About VDI Troubleshooting

This case is a good reminder that a black screen in a Citrix environment is not automatically a Citrix problem.

Citrix sits on top of a fairly complex Windows stack:

Citrix HDX
↓
Windows Session
↓
User Profile
↓
AppX / XAML
↓
Windows Shell
↓
Explorer

A failure somewhere in that chain can present exactly the same symptom to the end user:

A black screen.

So the important troubleshooting question isn’t necessarily:

Why is Citrix showing a black screen?

It is:

Which part of the Windows logon sequence actually failed?

In this case, explorer.exe provided the critical clue.

Conclusion

Finding in the Wild: Following the September Windows updates, users in Windows 11 VDI environments may successfully log on but remain stuck on a persistent black screen because explorer.exe does not start correctly during the logon process.

Based on my testing, three observations were particularly important:

Removing the Windows update did not resolve the issue.

Manually starting explorer.exe immediately restored a functional desktop.

Re-registering MicrosoftWindows.Client.CBS, Microsoft.UI.Xaml.CBS, and MicrosoftWindows.Client.Core restored the normal logon behavior.

This does not yet establish the definitive root cause, but it provides a strong indication that the problem is related to Windows Shell/AppX/XAML initialization rather than the Citrix session itself.

Until a definitive root cause and permanent fix are available, I would test the workaround carefully, preserve affected profiles for further analysis, and retest the behavior after subsequent Windows updates.

Finding in the Wild – exactly the kind of issue where the black screen is only the visible symptom, while the actual problem is hiding several layers deeper.

NetScaler CVE Checklist: Updates, Security Assessment and Incident Response

Critical vulnerabilities in NetScaler ADC and NetScaler Gateway require a structured approach: assess exposure, select a secure target version, update affected systems, and then determine whether there are any indications of compromise.

This checklist summarizes the key steps for dealing with new NetScaler CVEs. The current vendor security bulletin, supported firmware builds, and the specifics of your own environment should always be considered authoritative. Do not assess only the current patch status. CVE-specific prerequisites, the period during which the appliance was publicly exposed, and potential indicators of an earlier compromise must also be taken into account.

Important: The commands listed in this article are intended to identify investigation leads. A match is not automatically an Indicator of Compromise (IOC) and must always be evaluated in the context of the affected CVE, the installed build, and your individual NetScaler configuration.

Latest Citrix findings: eight NetScaler vulnerabilities

Updated 28 September 2026: Citrix has published Security Bulletin CTX697096 covering eight vulnerabilities in NetScaler ADC and NetScaler Gateway: CVE-2026-88771 through CVE-2026-88778. Citrix confirms that exploitation of CVE-2026-88771 and CVE-2026-88772 has been observed. Affected systems should be updated to a fixed build as soon as possible.

CVESummaryCitrix precondition
CVE-2026-88771Unauthenticated remote code execution (RCE)All deployments; no additional feature required
CVE-2026-88772Memory 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-88773HTTP request smugglingHTTP configuration enabled
CVE-2026-88774Policy bypassHTTP URL-based policy expression configured
CVE-2026-88775Memory overflow that may cause unexpected behavior or DoSGateway or AAA virtual server
CVE-2026-88776Memory overflow that may cause unexpected behavior or DoSOracle load-balancing virtual server
CVE-2026-88777Memory overflow that may cause unexpected behavior or DoSNon-HTTP Layer 7 feature enabled on an LB/CS or CGNAT-LSN/NAT64 appliance
CVE-2026-88778TCP Initial Sequence Number (ISN) predictionTCP configuration enabled; Citrix recommends an additional ISN configuration change

Citrix fixed-build thresholds:

  • 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

The configuration preconditions help assess exposure before the update. If the appliance is already running a fixed build for the relevant product variant, a matching virtual server or enabled feature does not, by itself, mean the appliance remains vulnerable to these CVEs. However, patching does not remove evidence of possible earlier exposure or prove that the appliance was not compromised before the update. The timeline and a security assessment still matter.

Additional investigation indicators

When investigating a suspected incident or the period before patching, correlate CVE-specific configuration prerequisites with system and log evidence, including:

  • Unexpected reboots or cold starts; correlate their timestamps with HTTP access logs and other reboot events.
  • Changes to /etc/httpd.conf, or the httpd.conf path used by that build, compared with a trusted baseline.
  • Unexpected changes to /bin/sh permissions.
  • Unknown .dot files under LogonPoint/custom.
  • Suspicious b64decode strings in available HTTP or system logs.
  • New or modified files in security-relevant directories, including /var/vpn/, /var/netscaler/logon/, /var/python/, and /netscaler/ns_gui/.
  • Unknown PHP, Perl, Python, JavaScript, or ELF files and possible webshells.
  • Suspicious HTTP requests, unusual POST requests, and requests for unexpected resources.
  • Unusual shell, Bash, Gateway, or VPN log entries, as well as log gaps or unexpected log rotation.
  • New or modified files with the SUID bit set and unusual processes, including processes running as nobody.
  • Unexpected cron entries or changes to /flash/nsconfig/rc.netscaler and /etc/monitrc.
  • HA synchronization issues or unexpected changes to nsfsyncd.
  • Unusual NSPPE crashes, core dumps, processes, or sustained resource usage.
  • Unusual outbound connections, internal scans, or other unexpected network activity from the appliance.

A match is an investigation lead, not proof of compromise. A search with no matches does not prove that the appliance is clean: logs may have rotated or been modified, and automated checks only cover the paths and patterns they scan.

For CVE-2026-88778, Citrix also specifies an Enhanced ISN Generation configuration change for affected systems. Check the current vendor instructions and the live appliance configuration.

Automated NetScaler security check

For an initial technical assessment, download the script below and run it on the relevant appliance. Version 9.9 compares the firmware build with the fixed-build thresholds in CTX697096, searches the saved configuration for CVE preconditions, and checks selected files, directories, and logs for potential indicators. A match is an investigation lead, not proof of compromise.

The script is read-only: it does not change the NetScaler configuration, restart services, or remove files. It writes a plain-text report to /var/tmp and prints the report path when it finishes.

Security/netscaler-ioc-check.sh at main · Deyda/Security
Security assessment, hardening and incident response scripts for NetScaler, Citrix and enterprise infrastructure. – Deyda/Security

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.

Timestamp installer files

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.

Suspicios files webshells

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.

Important: A firmware update does not remove webshells or persistence mechanisms that have already been deployed, nor does it invalidate credentials or keys that may already have been stolen. If suspicious artifacts are identified, preserve the evidence before cleanup and initiate a structured Compromise Assessment. Potentially affected credentials, certificates, keys, and active sessions must then be included in the incident response process.

Get your NetScaler security professionally assessed

Do you need support with firmware updates, assessing critical vulnerabilities, or investigating potential indicators of a security incident?

Deyda Consulting can support you with a NetScaler Security Readiness assessment — structured, traceable, and based on real-world NetScaler experience.

Explore NetScaler Security Readiness

NetScaler ADC Firmware Upgrade

Regular firmware updates are one of the most important maintenance tasks in a NetScaler ADC infrastructure. In addition to new features, current firmware releases include important bug fixes and security-related patches. Especially in the case of security advisories or actively exploited vulnerabilities, firmware updates should be scheduled promptly.

Because a firmware upgrade can affect production services such as NetScaler Gateway, Load Balancing, Content Switching, AAA, GSLB, or SSL Offloading, it should never be performed without proper preparation. A structured approach reduces downtime and minimizes the risk of unexpected issues.

This article describes the recommended upgrade process for production NetScaler ADC environments.

Continue reading “NetScaler ADC Firmware Upgrade”

Install new Microsoft Teams (version 2) in Citrix

The new version of Microsoft Teams (often referred to as “Teams 2.0”) has been the new standard since July 1, 2024.

For VDI environments, this means:

  • October 1, 2024 → End of Support (Classic Teams in VDI)
  • July 1, 2025 → End of Availability

In short:
There is no way back.

Timeline VDI Clients
Continue reading “Install new Microsoft Teams (version 2) in Citrix”

Citrix License Activation Service (LAS): Goodbye License Files

If you’re a Citrix customer and thinking “next week…” right now — understandable. But starting April 15, 2026, file-based Citrix license files will no longer work. This is not a warning; it’s a hard shutdown date.

That means: if you haven’t migrated to LAS by then, you risk real outages (apps, desktops, or features depending on the component and version).

LAS is not a migration of your workloads to the cloud. Your site continues to run on-premises (DDCs, StoreFront, VDAs, etc.).
The only thing that changes is the activation and licensing mechanism.

Continue reading “Citrix License Activation Service (LAS): Goodbye License Files”