How to Perform Compromise Assessments on NetScaler / Citrix ADC Appliances Using THOR

by Jul 20, 2023

In today’s interconnected world, cyber adversaries are increasingly targeting and exploiting Internet-facing appliances and devices with unconventional or restricted operating systems. A pressing concern for users is whether it’s possible to perform a compromise assessment scan on these systems using the YARA rules used in THOR.

In light of recent events surrounding the unauthenticated remote code execution vulnerability of Internet-facing Citrix Netscaler (CVE-2023-3519), this blog post aims to explore methods for conducting remote scans on devices like Citrix Netscaler using THOR or the free THOR Lite YARA and IOC scanners. This approach can also extend to scanning other devices that may not be supported by real-time Antivirus engines or EDRs, such as ESX servers. Let’s delve into the details of this powerful method.

Therefore, our approach involves mounting the remote file system using SSH (SSHFS) and subsequently instructing THOR to conduct the scan on the mounted remote filesystem. This method allows us to effectively assess the security of the remote system without the need for direct physical access.


  • Access to Port 22/tcp
    Ensure that you can reach port 22/tcp on the target system. This is essential for establishing an SSH connection, which is necessary for the remote file system mounting process.
  • Source System with SSHFS Support
    You’ll need a source system that supports sshfs. If you’re using Debian, you can install sshfs by running the following command: sudo apt install sshfs.
  • THOR Lite or Full THOR with Lab License
    Obtain either THOR Lite or the full THOR version with a valid lab license. This license is necessary to use the scanning capabilities of THOR effectively.
  • Modified /etc/ssh/sshd_config on NetScaler Appliance
    It is crucial to modify the /etc/ssh/sshd_config file on the NetScaler appliance to allow for SSH mounting. Ensure that the necessary changes are made to facilitate the process. (see configuration details below)

SSHD Config Changes

To enable remote mounting of the NetScaler file system, it is imperative to modify the configuration of the SSH daemon. The default configuration lacks support for ssh mounts through the sftp-server. Consequently, adjustments are required to allow for this functionality. (please refer to the provided banner and error message below for more details)

1. We change the following line in the file /etc/ssh/sshd_config:

Subsystem sftp /usr/lib/openssh/sftp-server


Subsystem sftp internal-sftp

2. Restart the SSH service to apply the changes

kill -HUP `cat /var/run/`

Optional: To persist the changes we copy /etc/ssh/sshd_config to /nsconfig/sshd_config

cp /etc/ssh/sshd_config /nsconfig/sshd_config

Mounting the Remote File System via SSH

First we create a new folder and mount the remote file system to that local folder:

sudo mkdir -p /mnt/ns
sudo sshfs -o reconnect,allow_other /mnt/ns

The -o reconnect option makes sure to reconnect the session on unstable networks.

Scanning the Mount Point with THOR Lite

With THOR Lite we can now run a so-called “Filescan” on the mounted drive.

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/ns

The following scan is much more intense as it scans every single file regardless of its extension or type. Scanning every file usually leads to much longer scan times and higher network load (be careful when using the --intense flag).

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/ns --intense

Scanning the Mount Point with THOR

With a full featured THOR and a so-called Lab license we can use the –virtual-map flag to virtually map the folder /mnt/ns to / internally. This means that signatures and filename patterns that make use of the virtual and not the actual path. We can also define a hostname that will appear in the log file using the -j flag. Otherwise the log would always contain the hostname of the scanning workstation.

sudo ./thor-linux-64 -a FileScan --alldrives -p /mnt/ns

Using the full version, we would use a different flag combination for a more intense scan of the remote system. The full version with a lab license allows us to use the --lab flag.

sudo ./thor-linux-64 --lab -p /mnt/ns --virtual-map /mnt/ns:/ -j my-ns-hostname

The --lab flag automatically activates the intense scan mode that checks every file, multi-threaded scanning, deactivates resource control and some other flags that can be useful in a lab scanning scenario.

Example Match

The provided screenshot demonstrates an illustrative match of a web shell discovered on systems impacted by CVE-2023-3519 exploitation. Some of this attack’s specific rules and indicators of compromise (IOCs) are available in THOR but not in the free THOR Lite version. However, it’s worth noting that the free THOR Lite version includes many generic rules that successfully detected all of the known dropped web shells. (including the one shown below)

Other Notes

  • Test scans on our customer’s NetScaler systems took between 30 and 60 minutes
  • A network disconnect only pauses the scan, a forced “umount” crashes the scanner.
  • We tested network disconnects of 1 and 5 minutes. After a reconnect THOR just resumes the scan where it left off. 


As the frequency and complexity of cyberattacks continue to rise, ensuring the security of Internet-facing devices becomes paramount. By incorporating YARA rules from THOR into compromise assessment scans, users can bolster their cybersecurity defense and remotely identify potential threats on devices like Citrix Netscaler and others.

Additionally, the ability to extend this coverage to unsupported devices opens up new possibilities for safeguarding critical systems. Adopting these cutting-edge cybersecurity practices will undoubtedly prove instrumental in mitigating risks and protecting digital assets in an ever-evolving threat landscape.

Advantages of the full THOR version

Apart from the usual advantages of the full THOR version over THOR Lite, there are a few more reasons to use the full version in this scenario:

  • Use multiple instances on a single source system to scan many different remote systems at the same time
  • Use virtual drive mapping to allow for additional detection opportunities
  • Set a custom host name that appears in the log files (helpful when you scan many different targets)

If you’re interested in the full version, contact us using the “Get Started” button in the upper right corner. 

About the author:

Christian Burkard


New blog posts
(~1 email/month)

GDPR Cookie Consent with Real Cookie Banner