Introduction

The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Canadian Centre for Cyber Security (Cyber Centre) assess People’s Republic of China (PRC) state-sponsored cyber actors are using BRICKSTORM malware for long-term persistence on victim systems. Victim organizations are primarily in the Government Services and Facilities and Information Technology Sectors. BRICKSTORM is a sophisticated backdoor for VMware vSphere (specifically VMware vCenter servers and VMware ESXI)¹ and Windows environments.²

The cyber actors have been observed targeting VMware vSphere platforms. Once compromised, the cyber actors can use their access to the vCenter management console to steal cloned virtual machine (VM) snapshots for credential extraction and create hidden, rogue VMs. See CISA’s Alert PRC State-Sponsored APT Actors Employ BRICKSTORM Malware Across Public Sector and Information Technology.

CISA analyzed eight BRICKSTORM samples obtained from victim organizations, including an organization where CISA conducted an incident response engagement.

At the victim organization where CISA conducted an incident response engagement, PRC state-sponsored cyber actors gained long-term persistent access to the organization’s internal network in April 2024 and uploaded BRICKSTORM malware to an internal VMware vCenter server. They also gained access to two domain controllers and an Active Directory Federation Services (ADFS) server. They successfully compromised the ADFS server and exported cryptographic keys. The cyber actors used BRICKSTORM for persistent access from at least April 2024 through at least Sept. 3, 2025.

CISA, NSA, and Cyber Centre urge organizations to use the indicators of compromise (IOCs) and detection signatures in this Malware Analysis Report to identify BRICKSTORM malware samples. If identified, follow the guidance in the Incident Response section.

Download the PDF version of this report: 

For a downloadable copy of IOCs associated with this malware, see: 

For a downloadable copy of the SIGMA rule associated with this malware, see: 

For more information on PRC state-sponsored cyber activity, see CISA’s People’s Republic of China Threat Overview and Advisories webpage.

Malware Summary

BRICKSTORM is a custom Executable and Linkable Format (ELF) Go-based backdoor. The analyzed samples differ in function, but all enable cyber actors to maintain stealthy access and provide capabilities for initiation, persistence, and secure command and control (C2). Even though the analyzed samples were for VMware vSphere environments, there is reporting about Windows versions.

BRICKSTORM initiates by running checks and maintains persistence by using a self-watching function and automatically reinstalls or restarts if disrupted.

For C2, BRICKSTORM uses multiple layers of encryption (HTTPS, WebSockets, nested Transport Layer Security [TLS]) to hide its communications with the cyber actors’ C2 server. It also uses DNS-over-HTTPS (DoH) and mimics web server functionality to blend its communications with legitimate traffic. For remote system control, BRICKSTORM gives cyber actors interactive shell access on the system and allows them to browse, upload, download, create, delete, and manipulate files. In addition, some samples act as a SOCKS proxy, facilitating lateral movement and allowing cyber actors to compromise additional systems.

Malware Delivery

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 18. See Appendix A: MITRE ATT&CK Techniques for tables mapping the cyber actors’ activity to MITRE ATT&CK tactics and techniques.

At the victim organization where CISA conducted an incident response engagement, PRC state-sponsored cyber actors accessed a web server on April 11, 2024. The web server was inside the organization’s demilitarized zone (DMZ), and cyber actors accessed it through a web shell [T1505.003] present on the server. Incident data does not indicate how they obtained initial access to the web server or when the web shell was implanted. On the same day, the cyber actors used service account credentials [T1078] to move laterally using Remote Desktop Protocol (RDP) [T1021.001] from the web server to a domain controller in the DMZ, from which they copied the Active Directory (AD) database (ntds.dit) [T1003.003].

On April 12, 2024, the cyber actors moved laterally from the web server to a domain controller within the internal network using RDP and credentials associated with a second service account. It is unknown how they obtained the credentials. Subsequently, they copied the AD database, obtaining credentials for a managed service provider (MSP) account. Using the MSP credentials, the cyber actors proceeded to move from the internal domain controller to the VMware vCenter server. 

From the web server, the actors also moved laterally using Server Message Block (SMB) to two jump servers and an ADFS server, from which they exfiltrated cryptographic keys. See Figure 1 for a diagram of the cyber actors’ movement.

After gaining access to vCenter, the cyber actors elevated privileges using the sudo command [T1548.003], dropped BRICKSTORM malware in the server’s /etc/sysconfig/ directory [T1105], and modified the system’s init file in /etc/sysconfig/ to run BRICKSTORM.

The modified init file controls the bootup process [T1037] on VMware vSphere systems and executes BRICKSTORM. Typically, this file is used to define certain visual variables for the bootup process. After the setting for visual variables, an additional line was added to the script to execute BRICKSTORM from the hard-coded file path /etc/sysconfig/.

Note: CISA is still completing analysis to understand the malicious activity and full impact of the compromise.

Malware Metadata

See Table 1 through Table 8 for metadata of the analyzed malware.

Malware Functionality

All analyzed samples enable cyber actors to maintain stealthy access and provide capabilities for environment configuration (initiation), persistence, and secure C2. While initiation and persistence functions are similar across the samples, the secure C2 function varies. BRICKSTORM uses custom handlers to set up a SOCKS proxy, create a web server on the compromised system, and execute commands on the compromised system.

Samples 7 and 8 were designed to work in virtualized environments, using a virtual socket (VSOCK) interface to enable inter-VM communication, facilitate data exfiltration, and maintain persistence.

Most samples used Exclusive OR (XOR) cipher encryption to hide key strings, such as the Internet Protocol version 4 (IPv4) addresses of public DoH servers, within their code.

Initiation Capabilities

Upon execution, BRICKSTORM runs checks and can reinstall and restart itself to maintain persistence. BRICKSTORM initiates a function (referred to as main_startNew in some samples) to configure environment variables specific to the compromised environment, enabling it to operate effectively. Following this, BRICKSTORM identifies if it is already in its intended state and proceeds to continue running, copy itself for execution, or terminate based on the following logic:

1. Environment Variable Check: BRICKSTORM checks a specified environment variable (differs by sample; see Table 9) to determine if it is running as a child process (to identify if it is running in its intended state).
   1. If the specified variable is set, indicating it is running as a child process, BRICKSTORM continues its code execution.
   2. If the specified variable is not set (indicating it is not running as a child process), BRICKSTORM checks whether it is executing from /etc/sysconfig/ (Samples 1 through 2 and 4 through 7) or /etc/sysconfig/network/ (Sample 3) by attempting to load file contents from that path.
2. File Path Validation and Copying: If BRICKSTORM is running from the validated path, it copies itself to a specific location with a specific file name.
   1. Next, the parent BRICKSTORM instance modifies the PATH environment variable by appending the copied location’s path [T1574.007]. This ensures the newly copied version of BRICKSTORM will be executed first if any commands or processes attempt to run VMware vSphere.
   2. The parent instance subsequently executes the copied instance of BRICKSTORM with the specified variable set in the context of the child process and terminates its own execution.
3. Termination: If BRICKSTORM is not running from the validated path, it terminates its own execution.

See Figure 2 for the operational flow of the malware.

See Table 9 for checked variables, copied locations, and copied file names of the analyzed samples.

Persistence Capabilities

To ensure its continued operations, BRICKSTORM uses built-in self-monitoring and persistence capabilities while running. Specifically, it has a built-in self-watching function (referred to as main_selfWatcher in some samples) to maintain persistence. This function monitors if BRICKSTORM is running correctly and, if not, BRICKSTORM reinstalls and executes itself, mirroring its initiation capabilities.

The self-watching function begins by checking a specific environment variable (see Table 10) to confirm whether BRICKSTORM is running as an active process. If the check returns a false value (indicating the variable is not set), BRICKSTORM assumes it is not running properly. In response, BRICKSTORM re-installs itself from predefined file path—/etc/sysconfig/ (Samples 1 through 2 and 4 through 8) or /etc/sysconfig/network/ (Sample 3)—to a new location (the file name of the new BRICKSTORM instance and location copied varies by sample; see Table 10). BRICKSTORM then updates the PATH environment variable to include the new file location, ensuring the newly copied backdoor file is executed first. Subsequently, the parent instance terminates its own execution, allowing the new process to take over.

If the initial checks confirm that BRICKSTORM is running as intended (the variable is set), the self-watcher function allows the code to continue its operations.

See Table 10 for details on checked variables, processes, copied locations, and file names associated with the analyzed samples.

Secure Command and Control

After passing initiation checks, BRICKSTORM establishes a connection to a C2 server, secures communications with the server, and enables cyber actors’ full control over the compromised system. This control includes capabilities such as file system management and interactive shell access. In most samples, BRICKSTORM also provides a SOCKS proxy to facilitate tunneling and lateral movement.

The implementation of these capabilities varies across samples, with notable differences in Samples 7 and 8, which specifically target virtualized environments.

Sample 1

Initial Connection to the C2 Server: Sample 1 first creates an encrypted Domain Name System (DNS) query for a hard-coded C2 domain (the domain has been redacted from this report because according to public reporting, the cyber threat actors are not reusing C2 domains).³ The sample uses DoH to resolve the address of its C2 servers by sending an encrypted HTTPS request to one of the following legitimate public DoH resolvers [T1071.001]:

• https[:]//1.0.0[.]1/dns-query (Cloudflare)
• https[:]//1.1.1[.]1/dns-query (Cloudflare)
• https[:]//8.8.4[.]4/dns-query (Google)
• https[:]//8.8.8[.]8/dns-query (Google)
• https[:]//9.9.9[.]9/dns-query (Quad9)

If the C2 domain is not found in the public DoH resolver cache, the legitimate resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the threat actors’ DNS server. The DNS server responds with the correct IP address for the domain. The response is sent back through the legitimate DoH resolver to BRICKSTORM, which receives the encrypted response, decrypts it to get the C2 server’s IP address, and establishes a connection.

Establishing Secure Communications: Sample 1 establishes an encrypted connection to the C2 server using HTTPS, then upgrades the session to WebSockets with an additional layer of TLS encryption. To do this, Sample 1 first communicates over HTTPS with a specific legitimate cloud platform (redacted). The sample then sends an HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: wss://[REDACTED].com/api. Sample 1 nests additional layers of TLS encryption within the WebSocket session and performs a series of nested TLS handshakes within the established WebSocket tunnel. The first handshake is the standard TLS handshake for the initial HTTPS request to the cloud platform. The second TLS handshake occurs within the WebSocket tunnel, during which BRICKSTORM authenticates itself to the C2 server using a hard-coded key.

Upon successful authentication, BRICKSTORM establishes a multiplexing layer, which allows it to send multiple commands and data streams over the same connection. It does this using both Simple Multiplexing (smux) and Yet Another Multiplexer (Yamux) libraries to create virtual streams over a single underlying TLS-secured connection based on client configuration or handshake data. Multiplexing conceals threat actor activity by embedding multiple commands and network tunnels within a single encrypted stream.

See Figure 3 for the applicable decompiler output.

Full System Control: Once the secure connection to the C2 domain is established, Sample 1 uses a custom Go package wssoft2 to manage incoming network connections and to process commands it receives. Commands are directed to one of three handlers based on the function it needs: SOCKS Handler, Web Service Handler, and Command Handler.

The SOCKS Handler sets up a SOCKS proxy [T1090.001] to route C2 traffic and facilitate lateral movement within the victim network. To set up the proxy, the handler parses JSON requests from the C2 server. If the request is valid, the handler delegates request handling to wssoft2/core/handler/socks.SocksWithLocalAddr, which performs SOCKS relaying and network tunneling over Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).

See Figure 4 for the handler’s decompiler output.

The Web Service Handler establishes covert C2 communication by creating a legitimate-appearing web server on the compromised system. It uses the net/http package and gorilla/mux library to create the web server, which includes a hidden Application Programming Interface (API) endpoint for receiving and executing commands from the C2 server. See Figure 5 for the Web Service Handler decompiler output that sets up specific API endpoints.

Through the API, the cyber actors can browse, upload, download, create, delete, and manipulate files and folders on the victim’s system. See Table 11 for file management commands contained in BRICKSTORM.

To evade detection, BRICKSTORM serves seemingly legitimate web file types, such as Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript, from a designated directory.

See Figure 6 for the Web Service Handler decompiler output.

The Command Handler executes shell commands on the compromised system, giving the cyber threat actors full control over the compromised system through interactive command-line access. The handler receives a JSON request from the C2 server, parses it, and extracts it. The handler then sets up a pseudo-terminal (a virtual command-line interface) and runs the command on the victim system.

See Figure 7 for the Command Handler decompiler output.

Samples 2 Through 6

Initial Connection to the C2 Server: Like Sample 1, these samples create an encrypted DNS query for hard-coded C2 domains (redacted) and use DoH to resolve the addresses of their C2 servers by sending an encrypted HTTPS request to one of the following legitimate public DoH resolvers:

• https[:]//1.0.0[.]1/dns-query (Cloudflare)
• https[:]//1.1.1[.]1/dns-query (Cloudflare)
• https[:]//149.112.112[.]11/dns-query (Quad9)
• https[:]//45.90.28.160/dns-query (NextDNS)
• https[:]//8.8.4[.]4/dns-query (Google)
• https[:]//8.8.8[.]8/dns-query (Google)
• https[:]//9.9.9[.]11/dns-query (Quad9)
• https[:]//9.9.9[.]9/dns-query (Quad9)

Note: Some of these samples use XOR encryption to decrypt IPv4 addresses for DoH servers.

Establishing Secure Communications: Like Sample 1, these samples establish WebSocket Secure (WSS) connections with the C2 server and set up a multiplexing layer.

Full System Control: Once the connection is established with the C2 server via WebSockets, these BRICKSTORM samples receive commands that are directed to one of four specific handlers to perform tasks on the compromised system: SOCKS Handler, Web Service Handler, Command Handler, or CommandNoContext Handler. The SOCKS, Web Service, and Command Handlers function similar to the Sample 1 handlers. The CommandNoContext Handler executes shell commands on the compromised system without using an explicit security context.

Sample 7

Initial Connection to the C2 Server: Sample 7 retrieves configuration parameters from environment variables, performs checks, generates a TLS configuration used for secure communication to BRICKSTORM’s client, and starts a network communications routine. This sample also uses a VSOCK interface to enable inter-VM communication, support data exfiltration, and maintain persistence in virtualized environments. 

Upon execution, Sample 7 retrieves the following three configuration values from environment variables using the os_Getenv function:

• listenAddr (listen address and port)
• listenPath (listen path to route requests to the WSS connection)
• password (authentication key)

Establishing Secure Communications: Sample 7 establishes a secure WebSocket server with minimal external dependencies; specifically, all communication is encrypted using in-memory self-signed certificates. This enables encrypted communication without relying on publicly trusted Certificate Authorities (CAs) or storing certificate files on disk. It dynamically generates a self-signed X.509 certificate and a corresponding 2048-bit Rivest–Shamir–Adleman (RSA) private key in memory, which are loaded into a tls.Certificate struct and assigned to the certificate field’s tls.Config object. This allows the server to handle HTTPS/WSS connections using the in-memory self-signed certificate, as standard NET/HTTP servers are configured to use tls.Config.

Sample 7 uses a single, multiplexed connection over secure WebSockets to communicate with a specified C2 address (retrieved from the listenAddr value) and path (retrieved from the listenPath value). During or before the WSS handshake, Sample 7 implements a custom authentication check, involving the specific pre-shared authentication key (retrieved from password value).

Full System Control: Once the WSS connection with the C2 server is established, Sample 7 processes incoming commands through one of four handlers: Web Service Handler, Command Handler, VSOCK-proxy handler, or VSOCK handler.

The Web Service Handler functions similar to Sample 1’s Web Service Handler.

The Command Handler functions similar to Sample 1’s Command Handler.

The VSOCK-proxy Handler performs VSOCK relaying and network tunneling. It implements a proxy with specific configuration arguments to establish a tunneled connection to process JSON payloads. First, the handler unmarshals the payload data and extracts and validates the TunnelAddr, Context ID (CID), Port, and Family configuration arguments. Based on the validated arguments, the handler binds to a specific VSOCK address (defined by the CID and port) and establishes a connection to the destination specified by TunnelAddr. When the connection is completed or terminated, the handler sends an appropriate success or error response back to the client. This functionality enables cyber actors to maintain covert communication channels, evade detection, and pivot within virtualized environments.

The VSOCK Connection Handler creates and connects to VSOCK endpoints to maintain covert connections within the virtual environment. It processes incoming network requests containing a JSON payload with specific configuration arguments for connecting to a VSOCK endpoint. The handler extracts the JSON payload from the request and uses a JSON parser to unmarshal the data into a structured object with fields for Context (CID), Port, and Family. The handler checks the unmarshalled data for validity and, if the configuration is valid, the handler establishes a connection to a VSOCK endpoint using a specified CID and port number. If the virtual socket creation is successful, the handler allocates a new runtime object to hold the CID and port information. If unmarshalling fails, validation fails, or the destination connection cannot be established, the handler returns an appropriate error to the client.

Sample 8

Like Sample 7, Sample 8:

• Retrieves C2 parameters (listenAddr, listenPath, and password) from environment variables,
• Uses a self-signed X.509 certificate and a corresponding 2048-bit RSA private key in memory to facilitate encrypted communications without relying on a CA,
• Establishes a secure WebSocket server for encrypted communication, and
• Directs commands to specific handlers.

Sample 8’s handlers directing commands differ from Sample 7. In addition to a Web Service Handler, Command Handler, VSOCK-proxy Handler, and VSOCK Connection Handler, Sample 8 also has two additional handlers: The SOCKS Handler (which functions similar to Sample 1’s SOCKS Handler) and the CommandNoContext Handler (which functions similar to Samples 2 through 6’s CommandNoContext Handler).

Detection

YARA Rules

Deploy the CISA-created YARA rules in Table 12 to detect malicious activity. See Appendix B: Scanning Guidance on Remote Hosts for guidance on how to identify activity with these rules.

Sigma Rule

Deploy the CISA-created Sigma rule in Table 13 to detect BRICKSTORM.

Note: This rule can be run in an entity’s security information and event management (SIEM) system, but it will only be useful if the SIEM contains the vCenter logs. Additionally, this detection method will not work if run on endpoint detection and response (EDR) logs.

Additional Detection Resources

See the following resources for detecting BRICKSTORM.

Google Mandiant’s tactics, techniques, and procedures (TTPs)-based hunt guidance and YARA detections rules provided in Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors.

Google Mandiant’s BRICKSTORM Espionage Campaign YARA Rules, available at Github.

Google Mandiant’s BRICKSTORM Scanner: BRICKSTORM Indicator of Compromise Scanner.

Use the script by first mounting an image followed by the scan.

To mount the image:

• sudo mkdir -p /mnt/image
• sudo mount -o ro,loop image.001 /mnt/image

To unmount the image:

• sudo umount /mnt/image

The script can also be used by mounting a remote server to your local VM to scan its file system:

• sudo apt update
• sudo apt install -y sshfs
• sudo mkdir -p /mnt/remote-server
• sudo chown $(whoami):$(whoami) /mnt/remote-server
• sudo sed -i ‘s/^# *user_allow_other/user_allow_other/’ /etc/fuse.conf || echo ‘user_allow_other’ | sudo tee -a /etc/fuse.conf
• sudo sshfs root@IPAddress:/ /mnt/remote-server
• sudo ls -la /mnt/remote-server
• sudo yara yara.rule -r /mnt/remote-server
• sudo umount -l /mnt/remote-server
• ls -la /mnt/remote-server

NVISO’s analysis of Windows-based variants with IOCs and detection rules contains YARA and other detection and hunting rules. See NVISO Incident Response BRICKSTORM Backdoor Analysis.

CrowdStrike’s VirtualGHOST PowerShell Script: CrowdStrike / VirtualGHOST

This script can be used to identify unregistered VMware VMs.

To run in the script PowerShell or pwsh, complete the following steps:

1. Set-ExecutionPolicy RemoteSigned
2. Install-Module -Name VMware.PowerCLI -Scope CurrentUser
3. Import-Module VMware.PowerCLI
4. Get-Module -ListAvailable VMware.PowerCLI

To run the script in Windows, use .Detect-VirtualGHOST.ps1.

To run in the script in Linux, use sudo apt install -y powershell.

For vCenter servers, use username@domain.local instead of root. For ESXi Servers, you may use root username.

Incident Response

U.S. organizations: If BRICKSTORM, similar malware, or potentially related activity is detected, CISA and NSA urge organizations to report the activity as required by law and applicable policies. To enable CISA to provide tailored incident response assistance and build a comprehensive picture of this activity, CISA and NSA urge organizations to:

1. Immediately report the findings via CISA’s 24/7 Operations Center (contact@cisa.dhs.gov), 1-844-Say-CISA (1-844-729-2472), or CISA’s Incident Reporting System. Please identify the activity is related to BRICKSTORM, and CISA will reach out with next steps.
2. Use CISA’s Malware Analysis Submission Form to submit a file containing the malicious code. Include the CISA-provided Incident ID number (obtained from reporting the compromise) in the Open Incident ID field.

Canadian organizations: Report incidents by emailing Cyber Centre at contact@cyber.gc.ca or online via the reporting tool Report a Cyber Incident – Canadian Centre for Cyber Security.

Mitigations

CISA, NSA, and Cyber Centre recommend organizations implement the mitigations below to improve organization cybersecurity posture based on the cyber actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

• Upgrade VMware vSphere servers to the latest version [CPG 1.E].
• Harden your VMware vSphere environments by applying VMware’s guidance. For additional guidance on logging [CPG 2.T] and hardening, see From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944.
• Take inventory of all network edge devices [CPG 1.A] and monitor for any suspicious network connectivity originating from these devices.
• Ensure proper network segmentation restricts network traffic from the DMZ to the internal network [CPG 2.F].
• Disable RDP and SMB from the DMZ to the internal network.
• Apply the principle of least privilege and restrict service accounts to only needed permissions.
• Increase monitoring for service accounts, which are highly privileged and have a predictable pattern of behavior (e.g., scans that reliably run at a certain hour of the day).
• Block unauthorized DoH providers and external DoH network traffic to reduce unmonitored communications.

Disclaimer

CISA, NSA, and Cyber Centre do not endorse any commercial entity, product, company, or service, including any entities, products, companies, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA, NSA, or Cyber Centre.

Acknowledgements

VMware contributed to this advisory.

Version History

December 4, 2025: Initial version.

Appendix A: MITRE ATT&CK Techniques

See Table 14 through Table 20 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Appendix B: Scanning Guidance on Remote Hosts

The following tools are designed to support the identification of potentially malicious artifacts and activities but should not be used as standalone detection mechanisms.

Remote YARA Scan Using Nessus

1. Log into Nessus and go to “My Account.”
2. Press “About” tab on the left side.
3. Go to Software Update tab and manually update all components.
4. After the update is done, select “Scans” at the top and press the “New Scan” button.
5. Select “Advanced Scan.”
6. Give a name and description to your scan.
7. In the “Targets” section, input the IP address of the remote server you want to scan.
8. On the left pane under Settings select “Assessment” then “Malware.”
9. Toggle “Scan for malware” on.
10. Scroll down to “Yara Rules” and add your Yara rules file.
11. Select the filesystem and drives to scan.
12. Go back to the top and press “Credentials” tab.
13. Select SSH or Windows and input the credential of the server.
14. Nessus needs credentials to be able to do a Yara scan on the filesystem of the remote server.
15. In the “Plugins” tab, make sure to “Enable All.”
16. Launch the scan.

Remote YARA Scan without Nessus

1. Mount Remote Sever to Kali to Scan the Filesystem
   1. sudo apt update
   2. sudo apt install -y sshfs
   3. sudo mkdir -p /mnt/remote-server
   4. sudo chown $(whoami):$(whoami) /mnt/remote-server
   5. sudo sed -i ‘s/^# *user_allow_other/user_allow_other/’ /etc/fuse.conf || echo ‘user_allow_other’ | sudo tee -a /etc/fuse.conf
   6. sudo sshfs root@IPAddress:/ /mnt/remote-server
   7. sudo ls -la /mnt/remote-server
   8. sudo yara yara.rule -r /mnt/remote-server
   9. sudo umount -l /mnt/remote-server
   10. ls -la /mnt/remote-server

For more information see Tenable’s Threat Hunting with YARA and Nessus.

Notes

¹ Matt Lin et al., “Cutting Edge, Part 4: Ivanti Connect Secure VPN Post-Exploitation Lateral Movement Case Studies,” Google Cloud Blog, April 4, 2024, https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement.

² Maxime, “NVISO analyzes BRICKSTORM espionage backdoor,” NVISO, April 15, 2025, https://www.nviso.eu/blog/nviso-analyzes-brickstorm-espionage-backdoor.

³ Sarah Yoder et al., “Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors,” Google Cloud Blog, September 24, 2025, https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign.