UnknownPublished 13 Dec 2025

tlp clear · BRICKSTORM Backdoor - MAR-251165.c1.v1

Affects tlp clearSource CIRCL OSINT Feed

TLP:CLEAR, disclosure is not limited

Description

BRICKSTORM Backdoor - MAR-251165.c1.v1

Impact

For European organizations, BRICKSTORM poses a risk primarily to confidentiality and integrity of sensitive data due to its backdoor capabilities. Successful deployment could allow attackers to maintain long-term access, conduct espionage, or disrupt operations. Critical infrastructure, government agencies, and high-tech industries are especially vulnerable given their strategic importance. The lack of known exploits in the wild suggests limited current impact, but the potential for future targeted attacks remains. The stealthy nature of backdoors complicates detection and remediation, increasing the risk of prolonged compromise. Additionally, the geopolitical context of Chinese threat actors targeting Europe elevates the threat level for entities involved in international trade, research, or diplomatic activities. The absence of patches means organizations must rely on detection and containment rather than remediation through updates. Overall, the impact could range from data theft and intellectual property loss to operational disruption if the backdoor is leveraged effectively.

Defensive guidance

European organizations should implement advanced endpoint detection and response (EDR) solutions capable of identifying anomalous behaviors indicative of backdoor activity, such as unusual network connections or command execution patterns. Network segmentation and strict access controls can limit lateral movement if a system is compromised. Conducting regular threat hunting exercises focused on detecting unknown or custom backdoors is critical, especially in high-risk sectors. Employing threat intelligence feeds to update detection rules and indicators, even if sparse, can improve early warning capabilities. Multi-factor authentication (MFA) should be enforced to reduce the risk of initial compromise. Organizations should also ensure comprehensive logging and monitoring of privileged accounts and remote access tools. Incident response plans must include procedures for backdoor detection and eradication. Given the lack of patches, proactive defense and rapid containment are essential. Collaboration with national cybersecurity centers and sharing intelligence on emerging threats like BRICKSTORM can enhance collective defense.

Indicators of compromise

Hashes 64

8e4c88d00b6eb46229a1ed7001451320
9bf4c786ebd68c0181cfe3eb85d2fd202ed12c54
aaf5569c8e349c15028bc3fac09eb982efb06eabac955b705a6d447263658e38
5e654776e9c419e11e6f93a452415a601bd9a2079710f1074608570e498a9af37b81bb57c98cb8bb626c5ee4b3e35757d3ae8c1c3717f28d9f3fe7a4cebe0608
8e4c88d00b6eb46229a1ed7001451320
9bf4c786ebd68c0181cfe3eb85d2fd202ed12c54
aaf5569c8e349c15028bc3fac09eb982efb06eabac955b705a6d447263658e38
5e654776e9c419e11e6f93a452415a601bd9a2079710f1074608570e498a9af37b81bb57c98cb8bb626c5ee4b3e35757d3ae8c1c3717f28d9f3fe7a4cebe0608
0a4fa52803a389311a9ddc49b7b19138
97001baaa379bcd83677dca7bc5b8048fdfaaddc

Yara 4

'namespace'='CISA_Consolidated.yara' rule_name=CISA_251165_02 rule_content=rule CISA_251165_02 : BRICKSTORM backdoor installs_other_components communicates_with_c2 exfiltrates_data { meta: author = "CISA Code & Media Analysis" incident = "251165" date = "2025-09-29" last_modified = "202051001_1008" actor = "n/a" family = "BRICKSTORM" capabilities = "installs-other-components communicates-with-c2 exfiltrates-data" malware_type = "backdoor" tool_type = "unknown" description = "Detects Go-Based BRICKSTORM backdoor samples" sha256_1 = "aaf5569c8e349c15028bc3fac09eb982efb06eabac955b705a6d447263658e38" strings: $s0 = { 6D 61 69 6E 2E 73 74 61 72 74 4E 65 77 } $s1 = { 6D 61 69 6E 2E 73 65 6C 66 57 61 74 63 68 65 72 } $s2 = { 6D 61 69 6E 2E 73 65 74 53 65 72 76 69 63 65 43 66 67 } $s3 = { 73 6F 63 6B 73 2E 48 61 6E 64 6C 65 53 6F 63 6B 73 52 65 71 75 65 73 74 } $s4 = { 77 65 62 2E 57 65 62 53 65 72 76 69 63 65 } $s5 = { 63 6F 6D 6D 61 6E 64 2E 48 61 6E 64 6C 65 54 54 59 52 65 71 75 65 73 74 } $s6 = { 77 65 62 73 6F 63 6B 65 74 2E 28 2A 57 53 43 6F 6E 6E 65 63 74 6F 72 29 2E 43 6F 6E 6E 65 63 74 } $s7 = { 66 73 2E 28 2A 57 65 62 53 65 72 76 65 72 29 2E 52 75 6E 53 65 72 76 65 72 } $s8 = { 68 74 74 70 73 3A 2F 2F 31 2E 30 2E 30 2E 31 2F 64 6E 73 2D 71 75 65 72 79 } $s9 = { 68 74 74 70 73 3A 2F 2F 31 2E 31 2E 31 2E 31 2F 64 6E 73 2D 71 75 65 72 79 } $s10 = { 68 74 74 70 73 3A 2F 2F 38 2E 38 2E 34 2E 34 2F 64 6E 73 2D 71 75 65 72 79 } $s11 = { 68 74 74 70 73 3A 2F 2F 38 2E 38 2E 38 2E 38 2F 64 6E 73 2D 71 75 65 72 79 } $s12 = { 68 74 74 70 73 3A 2F 2F 39 2E 39 2E 39 2E 39 2F 64 6E 73 2D 71 75 65 72 79 } condition: 8 of them }This artifact is a malicious 64-bit ELF executable written in the Go programming language. The binary has been identified as a backdoor variant named BRICKSTORM that uses several advanced techniques to evade detection. The backdoor uses SOCKS proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor combines several sophisticated techniques, including DoH, nested TLS encryption, and the abuse of a legitimate cloud service to evade detection. The backdoor contains the authentication key, HTTPS and WebSocket addresses as part of its sophisticated, multi-layered C2 evasion technique. --Begin Elements-- [Redacted] ==> authentication key https://[redacted].com ==> HTTPS address constructed at runtime wss://[redacted].com/api ==> WebSocket address --End Elements-- The hard-coded domain has been redacted from this report. As of the release of this report, there has been no reuse of C2 domains across victims. Upon execution, the backdoor initiates the "main_startNew" function to configure environment variables. The backdoor then checks for the "VMware" environment variable to determine if it is running as a child process. If "VMware" is not set (indicating not a child process), the backdoor verifies its current execution path by attempting to load the file contents from "/etc/sysconfig/vmsrc". If not running from the specified file path "/etc/sysconfig/vmsrc", the backdoor terminates its code execution. If the backdoor executes from the specified file path, the backdoor copies itself to "/opt/vmware/sbin/vmware-sphere". The backdoor then prepends "/opt/vmware/sbin/" to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor executes the copied backdoor named "vmware-sphere" due to the PATH modification and terminates its own execution. If "VMware" is set (indicating a child process), the backdoor continues its main code execution. As part of this continued execution, the temporary copy of the backdoor at "/opt/vmware/sbin/vmware-sphere" is deleted. The backdoor uses the "main_selfWatcher function" to ensure its continued operation and maintain persistence on the compromised system. This self-preservation mechanism checks if the backdoor is running as an intended process and, if not, the backdoor re-installs and re-executes itself. The "main_selfWatcher" function first checks for the "Sphere" environment variable and confirms the existence of a process named "vmware-sphere". If the checks return a "false" value ("Sphere" is not set ), indicating the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/vmsrc" to a new location: "/opt/vmware/sbin/vmware-sphere". The backdoor then prepends "/opt/vmware/sbin/" to the PATH environment variable and the newly copied backdoor file "vmware-sphere" is executed. The parent backdoor then terminates its own execution, allowing the new process to continue running. If the initial checks confirm that the backdoor is running as intended ("Sphere" is set), the "main_selfWatcher" function allows the code to continue its normal malicious operations. The backdoor configures its service by disabling its logger and setting two different sleep time parameters before applying these configurations using the "main_setServiceCfg" function. The program contains a hard-coded list of public DoH servers to facilitate communications. ---Begin DoH Addresses--- 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) ---End DoH Addresses--- The backdoor relies on internal, low-level function calls from a custom Go package "wssoft2" to handle its network connections and command processing. The backdoor uses DoH to resolve the addresses of its C2 servers. The backdoor creates a DNS query for the C2 domain. The backdoor encrypts this query by encapsulating it within a standard HTTPS request. The backdoor sends the encrypted HTTPS request to a legitimate public DoH resolver operated by Cloudflare or Google or Quad9 to process the query. Analysis indicates that if the requested domain is not found in the public DoH resolver cache, the legitimate public DoH resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the TA's DNS server, which is the authoritative server for the malicious domain. The TA's DNS server will respond with the correct IP address for the C2 domain, and this response is sent back through the legitimate DoH resolver to the backdoor. The backdoor receives the encrypted response, decrypts it to get the C2 server's IP address, and establishes a connection. The backdoor uses multiple layers of encryption for its C2 communications. The backdoor communicates over HTTPS to the cloud platform, then upgrades these sessions to WebSockets with an additional layer of TLS encryption. The backdoor sends HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: "wss://[redacted].com/api". The backdoor nests additional layers of TLS encryption within the WebSocket session. The backdoor performs a series of nested TLS handshakes within the established WebSocket tunnel. The first TLS handshake is the standard TLS handshake for the initial HTTPS request to the Cloudflare platform. A second TLS handshake occurs within the WebSocket tunnel. During this step, the backdoor authenticates itself to the C2 server using a static authentication key, which has been redacted from this report. If authentication is successful, the backdoor proceeds to set up the multiplexing layer. The backdoor handles 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 (Figure 6). This method makes the TA's activities difficult to detect, as multiple commands and network tunnels are multiplexed and hidden within a single, encrypted network stream. Once the connection is established with the C2 server via WebSockets, the backdoor receives commands that are directed to specific handlers to perform tasks on the compromised system. Displayed below are the three core handlers and their functions: --Begin Core Handlers-- a. "wssoft2/core/handler/socks.HandleSocksRequest" (socks.HandleSocksRequest) ==> This handler establishes a SOCKS relay, which facilitates lateral movement within a compromised network and routes C2 traffic (Figure 2). This handler is a SOCKS proxy handler that attempts to parse incoming requests as JSON-formatted SOCKS arguments. Depending on the success of this parsing, it either responds with an error or delegates the handling to a SOCKS handling mechanism "wssoft2/core/handler/socks.SocksWithLocalAddr" (socks.SocksWithLocalAddr). The handler "socks.SocksWithLocalAddr" performs SOCKS relaying and network tunneling over Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). b. "wssoft2/core/handler/web.WebService" (web.WebService) ==> This handler establishes covert C2 communication by making the backdoor appear as a legitimate web server (Figure 3). The extension uses the Go programming language, leveraging the "net/http package" and "gorilla/mux" library, to create a web server on the compromised system. A dedicated Application Programming Interface (API) "/api/" endpoint is created to receive and execute commands from the TA's C2 server (Figure 5). This provides the TA with extensive control over the victim's file system, allowing the TA to browse, view, create, delete, upload, and download files and folders. To blend in and evade detection, the backdoor serves static web files (Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript) from a designated directory. This makes the malicious web server appear to be a standard web application. c. "wssoft2/core/handler/command.HandleTTYRequest" (command.HandleTTYRequest) ==> This handler is used to execute shell commands on the compromised system, granting the TA interactive command-line access (Figure 4). The handler initiates a request through its covert communication channels, parse a JSON payload into the a specific structure, extracts and executes an external command, specifically establishing a pseudo-terminal connection to it, enabling interactive control and data exchange with the running command. --End Core Handlers-- Displayed below are file management commands within the backdoor: --Begin File Management Commands-- "file-md5": Calculates the MD5 checksum of a specified file to verify the integrity of the file. "get-file": Downloads a file from the compromised system to the TA's C2 server. "list-dir": Lists the contents of a directory on the compromised system (browse the file system). "put-file": Uploads a file from the TA's C2 server to the compromised system. "slice-up": To read and download specific, partial sections of a file. --End File Management Commands--
'namespace'='CISA_Consolidated.yara' rule_name=CISA_251155_02 rule_content=rule CISA_251155_02 : BRICKSTORM backdoor installs_other_components communicates_with_c2 exfiltrates_data { meta: author = "CISA Code & Media Analysis" incident = "251155" date = "2025-09-15" last_modified = "20250916_1511" actor = "n/a" family = "BRICKSTORM" capabilities = "installs-other-components communicates-with-c2 exfiltrates-data" malware_type = "backdoor" tool_type = "unknown" description = "Detects Go-Based BRICKSTORM backdoor samples" sha256_1 = "320a0b5d4900697e125cebb5ff03dee7368f8f087db1c1570b0b62f5a986d759" sha256_1 = "dfac2542a0ee65c474b91d3b352540a24f4e223f1b808b741cfe680263f0ee44" sha256_1 = "b91881cb1aa861138f2063ec130b2b01a8aaf0e3f04921e5cbfc61b09024bf12" sha256_1 = "bfb3ffd46b21b2281374cd60bc756fe2dcc32486dcc156c9bd98f24101145454" strings: $s0 = { 04 30 0F B6 54 04 2C 31 D1 88 4C 04 34 48 FF C0 } $s1 = { 48 83 F8 04 7C E7 48 C7 04 24 } $s2 = { 48 8D 44 24 34 48 89 44 24 08 48 C7 44 24 10 04 } $s3 = { 48 89 44 24 48 48 89 4C 24 50 48 8B 6C 24 38 48 } $s4 = { 48 83 EC 40 48 89 6C 24 38 48 8D 6C 24 38 C7 44 24 } $s5 = { 83 EC 38 48 89 6C 24 30 48 8D 6C 24 30 C6 44 24 } $s6 = { 4C 24 20 48 89 44 24 40 48 89 4C 24 48 48 8B 6C } $s7 = { 64 48 8B 0C 25 F8 FF FF FF 48 3B 61 10 0F 86 81 } $s8 = { 64 48 8B 0C 25 F8 FF FF FF 48 3B 61 10 0F 86 91 } condition: all of them }This artifact is a malicious 64-bit ELF executable written in the Go programming language. The binary has been identified as a backdoor variant named BRICKSTORM that uses several advanced techniques to evade detection. The backdoor uses SOCKS proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor combines several sophisticated techniques, including DoH, nested TLS encryption, and the abuse of a legitimate cloud service to evade detection. The backdoor contains the authentication key, HTTPS and WebSocket addresses as part of its sophisticated, multi-layered C2 evasion technique. --Begin Elements-- hkigbLKHR_Pby6t6P ==> authentication key https://[redacted].com ==> HTTPS address wss://[redacted].com/cls ==> WebSocket address --End Elements-- The backdoor uses XOR cipher encryption to hide key strings, such as its IPv4 addresses of public DoH servers and other strings within its code. Upon execution, the backdoor initiates the obfuscated function "main_startNew" to configure environment variables. The backdoor then checks for the "[redacted]NET6" environment variable to determine if it is running as a child process. If "[redacted]NET6" is not set, indicating not a child process, the backdoor verifies its current execution path by attempting to load the file contents from "/etc/sysconfig/viocli". If not running from the specified file path "/etc/sysconfig/viocli", the backdoor terminates its code execution. If the backdoor executing from the specified file path, the backdoor copies itself to "/usr/java/jre-vmware/bin/updatemgr". The backdoor then prepends "/usr/java/jre-vmware/bin/" to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor executes the copied backdoor named "updatemgr" due to the PATH modification and terminates its own execution. If "[redacted]NET6" is set, indicating a child process, the backdoor continues its main code execution. As part of this continued execution, the temporary copy of the backdoor at "/usr/java/jre-vmware/bin/updatemgr" is deleted. The backdoor uses the obfuscated function "main_selfWatcher" to ensure its continued operation and maintain persistence on the compromised system. This self-preservation mechanism checks if the backdoor is running as an intended process and, if not, the backdoor re-installs and re-executes itself. The "main_selfWatcher" function first checks for the "[redacted]NET5" environment variable and confirms the existence of a process named "updatemgr". If the checks return a "false" value, indicating"[redacted]NET5" is not set, the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/viocli" to a new location: "/usr/java/jre-vmware/bin/updatemgr". The backdoor then prepends "/usr/java/jre-vmware/bin/" to the PATH environment variable. The newly copied backdoor file "updatemgr" is executed. The parent backdoor then terminates its own execution, allowing the new process to continue running. If the initial checks confirm that the backdoor is running as intended, indicating "[redacted]NET5" is set, the "main_selfWatcher" function allows the code to continue its normal malicious operations. The backdoor uses an XOR operation to decrypt the IPv4 addresses for the DoH servers below: --Begin DoH Addresses-- https://8.8.8.8/dns-query (Google) https://8.8.4.4/dns-query (Google) https://9.9.9.9/dns-query (Quad9) https://45.90.28.160/dns-query (NextDNS) https://45.90.30.160/dns-query (NextDNS) https://149.112.112.112/dns-query (Quad9) https://9.9.9.11/dns-query (Quad9) https://1.1.1.1/dns-query (Cloudflare) https://1.0.0.1/dns-query (Cloudflare) https://149.112.112.11/dns-query (Quad9) --End DoH Addresses-- The backdoor relies on internal, low-level function calls from a custom Go package to handle its network connections and command processing. The backdoor uses DoH to resolve the addresses of its C2 servers. The backdoor creates a DNS query for the malicious C2 domain "[redacted].com". The backdoor encrypts this query by encapsulating it within a standard HTTPS request. The backdoor sends the encrypted HTTPS request to a legitimate public DoH resolver operated by Cloudflare, Google, Quad9 or NextDNS to process the query. Analysis indicates that if the requested domain is not found in the public DoH resolver cache, the legitimate public DoH resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the TA's DNS server, which is the authoritative server for the malicious domain. The TA's DNS server will respond with the correct IP address for the C2 domain, and this response is sent back through the legitimate DoH resolver to the backdoor. The backdoor receives the encrypted response, decrypts it to get the C2 server's IP address, and establishes a connection. The backdoor uses multiple layers of encryption for its C2 communications. The backdoor communicates over HTTPS to the cloud platform ("https://[redacted].com"), then upgrades these sessions to WebSockets with an additional layer of TLS encryption. The backdoor sends HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: "wss://[redacted].com/cls". The backdoor nests additional layers of TLS encryption within the WebSocket session. The backdoor performs a series of nested TLS handshakes within the established WebSocket tunnel. The first TLS handshake is the standard TLS handshake for the initial HTTPS request to the cloud platform. A second TLS handshake occurs within the WebSocket tunnel. During this step, the backdoor authenticates itself to the C2 server using a static authentication key: "hkigbLKHR_Pby6t6P". An innermost TLS layer encrypts the actual C2 commands and data, securing them even if the outer layers are bypassed or decrypted. The backdoor uses the "HashiCorp Yamux" library to create multiple streams within a single innermost TLS-encrypted WebSocket tunnel. This method makes the TA's activities difficult to detect, as multiple commands and network tunnels are multiplexed and hidden within a single, encrypted network stream. After establishing a secure and covert connection, the backdoor leverages its obfuscated core "task.DoTask" (/core/task.DoTask) function and four obfuscated extensions (modules) "socks.Socks", "web.WebService", "command.Command", and "command.CommandNoContext". These extensions define the malicious functionality that the backdoor should execute, allowing the TA to carry out various tasks on the compromised systems. These modules enable C2 communication, lateral movement, and command execution on the compromised system. Displayed below are the four extensions and their functions: --Begin Extensions-- a. The Socks extension enables network tunneling through a SOCKS proxy, which facilitates lateral movement within a compromised network and routes C2 traffic. b. The WebService extension module establishes covert C2 communication by making the backdoor appear as a legitimate web server. The extension uses the Go programming language, leveraging the "net/http package" and "gorilla/mux" library, to create a web server on the compromised system. A dedicated API "/api/" endpoint is created to receive and execute commands from the TA's C2 server. This provides the TA with extensive control over the victim's file system, allowing the TA to browse, view, create, delete, upload, and download files and folders. To blend in and evade detection, the backdoor serves static web files (HTML, CSS, JavaScript) from a designated directory. This makes the malicious web server appear to be a standard web application. c. The Command extension executes commands on the compromised system with a specific security context. d. The CommandNoContext extension executes commands on the compromised system without using an explicit security context. --End Extensions-- The backdoor maintains a persistent connection to the C2 server unless a specific termination command is received or the C2 server terminates the connection.
'namespace'='CISA_Consolidated.yara' rule_name=CISA_251186_02 rule_content=rule CISA_251186_02 : BRICKSTORM backdoor installs_other_components communicates_with_c2 exfiltrates_data { meta: author = "CISA Code & Media Analysis" incident = "251186" date = "2025-11-17" last_modified = "n/a" actor = "n/a" family = "BRICKSTORM" capabilities = "installs-other-components communicates-with-c2 exfiltrates-data" malware_type = "backdoor" tool_type = "unknown" description = "Detects Go-Based BRICKSTORM backdoor samples" sha256_1 = "57bd98dbb5a00e54f07ffacda1fea91451a0c0b532cd7d570e98ce2ff741c21d" strings: $s0 = { 31 F7 40 88 7C 04 4C 48 FF C0 } $s1 = { 44 01 C7 40 88 7C 14 30 48 FF C2 0F 1F 00 } $s2 = { 41 89 F0 31 FE 01 D6 66 90 49 83 F8 11 } $s3 = { 48 8B 44 24 08 48 8B 5C 24 10 48 8B 4C 24 18 } $s4 = { 48 89 C1 48 89 DF 48 8D 05 0F 6F 15 00} $s5 = { 48 8D 3D 9A 6D 15 00 4D 89 C1 49 89 F0 } $s6 = { 81 39 49 43 4D 50 74 0C } $s7 = { E8 FB E6 FF FF E8 76 D0 FF FF E8 91 C0 FF FF 48 8B 05 EA BF 53} condition: all of them }This artifact is a malicious 64-bit ELF executable written in the Go programming language. The binary has been identified as a backdoor variant named BRICKSTORM that uses several advanced techniques to evade detection. The backdoor uses SOCKS proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor combines several sophisticated techniques, including DoH, nested TLS encryption, and the abuse of a legitimate cloud service to evade detection. The backdoor contains the authentication key, HTTPS and WebSocket addresses as part of its sophisticated, multi-layered C2 evasion technique. --Begin Elements-- "os235tfg_2ys872o.droso" ==> authentication key "hxxps[:]//[redacted].dev" ==> HTTPS address generated "wss://[redacted].dev/update" ==> WebSocket address --End Elements-- The backdoor key strings, such as its IPv4 addresses of public DoH servers and other strings within its code are encrypted. The backdoor symbolic debugging information, such as function names and variable names, has been removed from the executable to evade detection and hinder analysis. Upon execution, the backdoor decrypts and sets the appropriate environment variables that are used to gain privileged access, hide its operations, and commands execution. The backdoor then checks for the "CZePMeGj" environment variable to determine if it is running as a child process. If "CZePMeGj" is not set, indicating not a child process, the backdoor verifies its current execution path by attempting to load the file contents from "/etc/sysconfig/network/if-up". If not running from the specified file path "/etc/sysconfig/network/if-up", the backdoor terminates its code execution. If the backdoor executes from the specified file path, the backdoor copies itself to "/etc/applmgmt/appliance/vami". The backdoor then prepends "/etc/applmgmt/appliance/" to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor executes the copied backdoor named "vami" due to the PATH modification and terminates its own execution. If "CZePMeGj" is set, indicating a child process, the backdoor continues its main code execution. As part of this continued execution, the temporary copy of the backdoor at "/etc/applmgmt/appliance/vami" is deleted. The backdoor uses a function to ensure its continued operation and maintain persistence on the compromised system. This self-preservation mechanism checks if the backdoor is running as an intended process and, if not, the backdoor re-installs and re-executes itself. The function first checks for the "rcMJVF" environment variable and confirms the existence of a process named "vami". If the checks return a "false" value ("rcMJVF" is not set ), indicating the backdoor is not running correctly, the backdoor reinstalls itself from "/etc/sysconfig/network/if-up" to a new location: "/etc/applmgmt/appliance/vami". The backdoor then prepends "/etc/applmgmt/appliance/" to the PATH environment variable and the newly copied backdoor file "vami" is executed. The parent backdoor then terminates its own execution, allowing the new process to continue running. If the initial checks confirm that the backdoor is running as intended, indicating "rcMJVF" is set, the function allows the code to continue its normal malicious operations. The backdoor configures its service by disabling its logger and setting two different sleep time parameters. The program utilizes public DoH servers to facilitate communications. Displayed below are sample DoH servers utilized by the backdoor: ---Begin DoH Addresses--- hxxps[:]//1.0.0.1/dns-query (Cloudflare) hxxps[:]//1.1.1.1/dns-query (Cloudflare) hxxps[:]//8.8.4.4/dns-query (Google) hxxps[:]//8.8.8.8/dns-query (Google) hxxps[:]//9.9.9.9/dns-query (Quad9) ---End DoH Addresses--- The backdoor relies on internal, low-level function calls from a custom Go package to handle its network connections and command processing. The backdoor uses DoH to resolve the addresses of its C2 servers. The backdoor creates a DNS query for the C2 domain "[redacted].dev". The backdoor encrypts this query by encapsulating it within a standard HTTPS request. The backdoor sends the encrypted HTTPS request to a legitimate public DoH resolver operated by Cloudflare, Google, or Quad9 to process the query. Analysis indicates that if the requested domain is not found in the public DoH resolver cache, the legitimate public DoH resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the TA's DNS server, which is the authoritative server for the malicious domain. The TA's DNS server will respond with the correct IP address for the C2 domain, and this response is sent back through the legitimate DoH resolver to the backdoor. The backdoor receives the encrypted response, decrypts it to get the C2 server's IP address, and establishes a connection. The backdoor uses multiple layers of encryption for its C2 communications. The backdoor communicates over HTTPS to the cloud platform ("hxxps[:]//[redacted]dev"), then upgrades these sessions to WebSockets with an additional layer of TLS encryption. The backdoor sends HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: "wss://[redacted].dev/update". The backdoor nests additional layers of TLS encryption within the WebSocket session. The backdoor performs a series of nested TLS handshakes within the established WebSocket tunnel. The first TLS handshake is the standard TLS handshake for the initial HTTPS request to the Cloudflare platform. A second TLS handshake occurs within the WebSocket tunnel. During this step, the backdoor authenticates itself to the C2 server using a static authentication key: "os235tfg_2ys872o.droso". If authentication is successful, the backdoor proceeds to set up the multiplexing layer. The backdoor handles 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. This method makes the TA's activities difficult to detect, as multiple commands and network tunnels are multiplexed and hidden within a single, encrypted network stream. Once the connection is established with the C2 server via WebSockets, the backdoor receives commands that are directed to specific handlers to perform tasks on the compromised system. Displayed below are the four core handlers and their functions: --Begin Core Handlers-- a. The Socks handler establishes a SOCKS relay, which facilitates lateral movement within a compromised network and routes C2 traffic (Figure 2). This handler is a SOCKS proxy handler that attempts to parse incoming requests as JSON-formatted SOCKS arguments. Depending on the success of this parsing, it either responds with an error or delegates the handling to a SOCKS handling mechanism "wssoft2/core/handler/ socks.SocksWithLocalAddr" (socks.SocksWithLocalAddr). The handler "socks.SocksWithLocalAddr" performs SOCKS relaying and network tunneling over TCP, UDP, and ICMP. b. The WebService handler establishes covert C2 communication by making the backdoor appear as a legitimate web server (Figure 3). The handler uses the Go programming language, leveraging the "net/http package" and "gorilla/mux" library, to create a web server on the compromised system. A dedicated API "/api/" endpoint is created to receive and execute commands from the TA's C2 server (Figure 5). This provides the TA with extensive control over the victim's file system, allowing the TA to browse, view, create, delete, upload, and download files and folders. To blend in and evade detection, the backdoor serves static web files HTML, CSS, JavaScript from a designated directory. This makes the malicious web server appear to be a standard web application. c. The Command handler executes shell commands on the compromised system with a specific security context, granting the TA interactive command-line access. The handler initiates a request through its covert communication channels, parse a JSON payload into the a specific structure, extracts and executes an external command, specifically establishing a pseudo-terminal connection to it, enabling interactive control and data exchange with the running command. d. The CommandNoContext handler executes shell commands on the compromised system without using an explicit security context. --End Core Handlers--
'namespace'='CISA_Consolidated.yara' rule_name=CISA_251186_01 rule_content=rule CISA_251186_01 : BRICKSTORM backdoor installs_other_components communicates_with_c2 exfiltrates_data { meta: author = "CISA Code & Media Analysis" incident = "251186" date = "2025-11-17" last_modified = "n/a" actor = "n/a" family = "BRICKSTORM" capabilities = "installs-other-components communicates-with-c2 exfiltrates-data" malware_type = "backdoor" tool_type = "unknown" description = "Detects Go-Based BRICKSTORM backdoor samples" sha256_1 = "013211c56caaa697914b5b5871e4998d0298902e336e373ebb27b7db30917eaf" strings: $s0 = { 41 89 F8 31 F7 8D 3C 39 8D 7F } $s1 = { 41 31 FA 44 88 14 30 46 88 0C 00 48 83 C1 02 } $s2 = { BA 61 6D 64 36 81 FA 61 6D 64 36 } $s3 = { 41 89 F0 31 FE 01 CE 01 D6 49 83 F8 1F } $s4 = { 4D 89 CA 49 83 F1 5B 41 29 F0 49 83 F9 44 } $s5 = { 48 89 F7 48 83 F6 45 48 83 FE 48 } $s6 = { B8 11 C6 F3 EB 48 BB 31 46 42 BB 0E DD CF F2 } $s7 = { 41 89 F8 31 F7 01 CF 48 83 FE 11 } condition: all of them }This artifact is a malicious 64-bit ELF executable written in the Go programming language. The binary has been identified as a backdoor variant named BRICKSTORM that uses several advanced techniques to evade detection. The backdoor uses SOCKS proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor combines several sophisticated techniques, including DoH, nested TLS encryption, and the abuse of a legitimate cloud service to evade detection. The backdoor symbolic debugging information, such as function names and variable names, has been removed from the executable to evade detection and hinder analysis. The backdoor contains the authentication key, HTTPS and WebSocket addresses as part of its sophisticated, multi-layered C2 evasion technique. --Begin Elements-- "hkigbLKHR_Pby6t6P" ==> authentication key "hxxps[:]//[redacted].com" ==> HTTPS address "wss://[redacted].com/akamai" ==> WebSocket address --End Elements-- The backdoor uses XOR cipher encryption to hide key strings, such as its Internet Protocol version 4 (IPv4) addresses of public DoH servers and other strings within its code. Upon execution, the backdoor initiates a function to configure environment variables. The backdoor then checks for the "[redacted]NET4" environment variable to determine if it is running as a child process. If "[redacted]NET4" is not set, indicating not a child process, the backdoor verifies its current execution path by attempting to load the file contents from "/etc/sysconfig/vnetd". If not running from the specified file path "/etc/sysconfig/vnetd", the backdoor terminates its code execution. If the backdoor executing from the specified file path, the backdoor copies itself to "/usr/java/jre-vmware/bin/updatemgr". The backdoor then prepends "/usr/java/jre-vmware/bin/" to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor executes the copied backdoor named "updatemgr" due to the PATH modification and terminates its own execution. If "[redacted]NET4" is set, indicating a child process, the backdoor continues its main code execution. As part of this continued execution, the temporary copy of the backdoor at "/usr/java/jre-vmware/bin/updatemgr" is deleted. The backdoor uses a function" to ensure its continued operation and maintain persistence on the compromised system. This self preservation mechanism checks if the backdoor is running as an intended process and, if not, the backdoor re-installs and reexecutes itself. The function first checks for the "[redacted]NET3" environment variable and confirms the existence of a process named "vnetd". If the checks return a "false" value, then "[redacted]NET3" is not set, indicating the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/vnetd" to a new location: "/usr/java/jre-vmware/bin/updatemgr". The backdoor then prepends "/usr/java/jre-vmware/bin/" to the PATH environment variable. The newly copied backdoor file "updatemgr" is executed. The parent backdoor then terminates its own execution, allowing the new process to continue running. If the initial checks confirm that the backdoor is running as intended, indicating "[redacted]NET3" is set, the function allows the code to continue its normal malicious operations. The backdoor uses an XOR operation to decrypt the IPv4 addresses for the DoH servers below: --Begin DoH Addresses-- hxxps[:]//8.8.8.8/dns-query (Google) hxxps[:]//9.9.9.9/dns-query (Quad9) hxxps[:]//9.9.9.11/dns-query (Quad9) hxxps[:]//1.1.1.1/dns-query (Cloudflare) hxxps[:]//1.0.0.1/dns-query (Cloudflare) hxxps[:]//45.90.28.160/dns-query (NextDNS) hxxps[:]//45.90.30.160/dns-query (NextDNS) hxxps[:]//149.112.112.112/dns-query (Quad9) hxxps[:]//149.112.112.11/dns-query (Quad9) --End DoH Addresses-- The backdoor relies on internal, low-level function calls from a custom Go package to handle its network connections and command processing. The backdoor uses DoH to resolve the addresses of its C2 servers. The backdoor creates a DNS query for the malicious C2 domain "[redacted].com". The backdoor encrypts this query by encapsulating it within a standard HTTPS request. The backdoor sends the encrypted HTTPS request to a legitimate public DoH resolver operated by Cloudflare, Google, Quad9 or NextDNS to process the query. Analysis indicates that if the requested domain is not found in the public DoH resolver cache, the legitimate public DoH resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the TA's DNS server, which is the authoritative server for the malicious domain. The TA's DNS server will respond with the correct IP address for the C2 domain, and this response is sent back through the legitimate DoH resolver to the backdoor. The backdoor receives the encrypted response, decrypts it to get the C2 server's IP address, and establishes a connection. The backdoor uses multiple layers of encryption for its C2 communications. The backdoor communicates over HTTPS to the cloud platform ("hxxps[:]//[redacted].com"), then upgrades these sessions to WebSockets with an additional layer of TLS encryption. The backdoor sends HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: "wss://[redacted].com/akamai". The backdoor nests additional layers of TLS encryption within the WebSocket session. The backdoor performs a series of nested TLS handshakes within the established WebSocket tunnel. The first TLS handshake is the standard TLS handshake for the initial HTTPS request to the Cloudflare platform. A second TLS handshake occurs within the WebSocket tunnel. During this step, the backdoor authenticates itself to the C2 server using a static authentication key: "hkigbLKHR_Pby6t6P". If authentication is successful, the backdoor proceeds to set up the multiplexing layer. The backdoor uses the "HashiCorp Yamux" library to create multiple streams within a single innermost TLS-encrypted WebSocket tunnel. This method makes the TA's activities difficult to detect, as multiple commands and network tunnels are multiplexed and hidden within a single, encrypted network stream. Once the connection is established with the C2 server via WebSockets, the backdoor receives commands that are directed to specific handlers to perform tasks on the compromised system. Displayed below are the four core handlers and their functions: --Begin Core Handlers-- a. The Socks handler establishes a SOCKS relay, which facilitates lateral movement within a compromised network and routes C2 traffic. b. The WebService handler establishes covert C2 communication by making the backdoor appear as a legitimate web server. The handler uses the Go programming language, leveraging the "net/http package" and "gorilla/mux" library, to create a web server on the compromised system. A dedicated Application Programming Interface ( API) "/api/" endpoint is created to receive and execute commands from the TA's C2 server. This provides the TA with extensive control over the victim's file system, allowing the TA to browse, view, create, delete, upload, and download files and folders. To blend in and evade detection, the backdoor serves static web files (Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript) from a designated directory. This makes the malicious web server appear to be a standard web application. c. The Command handler executes shell commands on the compromised system with a specific security context, granting the TA interactive command-line access. d. The CommandNoContext handler executes shell commands on the compromised system without using an explicit security context. --End Core Handlers--

Text 52

eset
unknown
a variant of Linux/BrickStorm.A trojan
sophos
unknown
Linux/Brick-B
This artifact is a malicious 64-bit ELF executable written in the Go programming language. The binary has been identified as a backdoor variant named BRICKSTORM that uses several advanced techniques to evade detection. The backdoor uses SOCKS proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor combines several sophisticated techniques, including DoH, nested TLS encryption, and the abuse of a legitimate cloud service to evade detection. The backdoor contains the authentication key, HTTPS and WebSocket addresses as part of its sophisticated, multi-layered C2 evasion technique. --Begin Elements-- [Redacted] ==> authentication key https://[redacted].com ==> HTTPS address constructed at runtime wss://[redacted].com/api ==> WebSocket address --End Elements-- The hard-coded domain has been redacted from this report. As of the release of this report, there has been no reuse of C2 domains across victims. Upon execution, the backdoor initiates the "main_startNew" function to configure environment variables. The backdoor then checks for the "VMware" environment variable to determine if it is running as a child process. If "VMware" is not set (indicating not a child process), the backdoor verifies its current execution path by attempting to load the file contents from "/etc/sysconfig/vmsrc". If not running from the specified file path "/etc/sysconfig/vmsrc", the backdoor terminates its code execution. If the backdoor executes from the specified file path, the backdoor copies itself to "/opt/vmware/sbin/vmware-sphere". The backdoor then prepends "/opt/vmware/sbin/" to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor executes the copied backdoor named "vmware-sphere" due to the PATH modification and terminates its own execution. If "VMware" is set (indicating a child process), the backdoor continues its main code execution. As part of this continued execution, the temporary copy of the backdoor at "/opt/vmware/sbin/vmware-sphere" is deleted. The backdoor uses the "main_selfWatcher function" to ensure its continued operation and maintain persistence on the compromised system. This self-preservation mechanism checks if the backdoor is running as an intended process and, if not, the backdoor re-installs and re-executes itself. The "main_selfWatcher" function first checks for the "Sphere" environment variable and confirms the existence of a process named "vmware-sphere". If the checks return a "false" value ("Sphere" is not set ), indicating the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/vmsrc" to a new location: "/opt/vmware/sbin/vmware-sphere". The backdoor then prepends "/opt/vmware/sbin/" to the PATH environment variable and the newly copied backdoor file "vmware-sphere" is executed. The parent backdoor then terminates its own execution, allowing the new process to continue running. If the initial checks confirm that the backdoor is running as intended ("Sphere" is set), the "main_selfWatcher" function allows the code to continue its normal malicious operations. The backdoor configures its service by disabling its logger and setting two different sleep time parameters before applying these configurations using the "main_setServiceCfg" function. The program contains a hard-coded list of public DoH servers to facilitate communications. ---Begin DoH Addresses--- 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) ---End DoH Addresses--- The backdoor relies on internal, low-level function calls from a custom Go package "wssoft2" to handle its network connections and command processing. The backdoor uses DoH to resolve the addresses of its C2 servers. The backdoor creates a DNS query for the C2 domain. The backdoor encrypts this query by encapsulating it within a standard HTTPS request. The backdoor sends the encrypted HTTPS request to a legitimate public DoH resolver operated by Cloudflare or Google or Quad9 to process the query. Analysis indicates that if the requested domain is not found in the public DoH resolver cache, the legitimate public DoH resolver forwards the request to the next server in the DNS hierarchy, ultimately reaching the TA's DNS server, which is the authoritative server for the malicious domain. The TA's DNS server will respond with the correct IP address for the C2 domain, and this response is sent back through the legitimate DoH resolver to the backdoor. The backdoor receives the encrypted response, decrypts it to get the C2 server's IP address, and establishes a connection. The backdoor uses multiple layers of encryption for its C2 communications. The backdoor communicates over HTTPS to the cloud platform, then upgrades these sessions to WebSockets with an additional layer of TLS encryption. The backdoor sends HTTP upgrade request to convert the initial encrypted HTTPS connection into a persistent WebSocket connection: "wss://[redacted].com/api". The backdoor nests additional layers of TLS encryption within the WebSocket session. The backdoor performs a series of nested TLS handshakes within the established WebSocket tunnel. The first TLS handshake is the standard TLS handshake for the initial HTTPS request to the Cloudflare platform. A second TLS handshake occurs within the WebSocket tunnel. During this step, the backdoor authenticates itself to the C2 server using a static authentication key, which has been redacted from this report. If authentication is successful, the backdoor proceeds to set up the multiplexing layer. The backdoor handles 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 (Figure 6). This method makes the TA's activities difficult to detect, as multiple commands and network tunnels are multiplexed and hidden within a single, encrypted network stream. Once the connection is established with the C2 server via WebSockets, the backdoor receives commands that are directed to specific handlers to perform tasks on the compromised system. Displayed below are the three core handlers and their functions: --Begin Core Handlers-- a. "wssoft2/core/handler/socks.HandleSocksRequest" (socks.HandleSocksRequest) ==> This handler establishes a SOCKS relay, which facilitates lateral movement within a compromised network and routes C2 traffic (Figure 2). This handler is a SOCKS proxy handler that attempts to parse incoming requests as JSON-formatted SOCKS arguments. Depending on the success of this parsing, it either responds with an error or delegates the handling to a SOCKS handling mechanism "wssoft2/core/handler/socks.SocksWithLocalAddr" (socks.SocksWithLocalAddr). The handler "socks.SocksWithLocalAddr" performs SOCKS relaying and network tunneling over Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). b. "wssoft2/core/handler/web.WebService" (web.WebService) ==> This handler establishes covert C2 communication by making the backdoor appear as a legitimate web server (Figure 3). The extension uses the Go programming language, leveraging the "net/http package" and "gorilla/mux" library, to create a web server on the compromised system. A dedicated Application Programming Interface (API) "/api/" endpoint is created to receive and execute commands from the TA's C2 server (Figure 5). This provides the TA with extensive control over the victim's file system, allowing the TA to browse, view, create, delete, upload, and download files and folders. To blend in and evade detection, the backdoor serves static web files (Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript) from a designated directory. This makes the malicious web server appear to be a standard web application. c. "wssoft2/core/handler/command.HandleTTYRequest" (command.HandleTTYRequest) ==> This handler is used to execute shell commands on the compromised system, granting the TA interactive command-line access (Figure 4). The handler initiates a request through its covert communication channels, parse a JSON payload into the a specific structure, extracts and executes an external command, specifically establishing a pseudo-terminal connection to it, enabling interactive control and data exchange with the running command. --End Core Handlers-- Displayed below are file management commands within the backdoor: --Begin File Management Commands-- "file-md5": Calculates the MD5 checksum of a specified file to verify the integrity of the file. "get-file": Downloads a file from the compromised system to the TA's C2 server. "list-dir": Lists the contents of a directory on the compromised system (browse the file system). "put-file": Uploads a file from the TA's C2 server to the compromised system. "slice-up": To read and download specific, partial sections of a file. --End File Management Commands--
backdoor
trojan
eset

Ssdeep 8

49152:9lDeYNeYunc1S3/U05q+CIKUbwgBfd1Vww/uUJSZina/TokDDko0n8oQhEoAgsUJ:O3lcE380sIDbdB11p3i/TokEIowlb/r
49152:BgClz8/9cMSThwhWyh/zypzOzRzqm9hRp6FY+fAn/bkNqr+HfHF2xkdpb3gAiDli:W08/9I6WMzUcRz9zvn//Z5D
98304:dzB06b0KX4Mnb+sJf+AjBzH3MF4m1d4U2TuAJ5VGY3glknTSk2nH:dFQKIsJBBzXMum83RJ5VGY3gS2nH
98304:78Se5lqfYMKDdopPx0E4j+dM/GLaCXNwqYL6wt/5APUnU:78Se54fYMUaiE4j+dM/GLaCXNmLP+
98304:78Se5lqfYMKDdopPx0E4j+dM/GLaCXNwqYL6wt/5APUnb:78Se54fYMUaiE4j+dM/GLaCXNmLP+
196608:GbkKsdDjru3WUIOsW5SYVRk/Qvk1LzK3RMxy2wBW:GwKMjr3Os4k/QiLzERMMdW
49152:6XUQ9anktEg7z/QbPB83A+FQGQzqufqCjt2F81jh+eS53OOwJylHJHuxkdqz3gHG:mVankxn2Pe3JQGQz57t2Y4f3TwrQHAz
49152:uP9kPWdmrJl+9zxKsSJ32ssUZGHZ9ECKDfvCb3XKRbaYJcRHMH9xkdgY3gqF2HxR:yqWdmd4x5SgssUZ0OCKDfvChYrRq

File 9

vmsrc
b3b6a992540da96375e4781afd3052118ad97cfe60ccf004d732f76678f6820a
57bd98dbb5a00e54f07ffacda1fea91451a0c0b532cd7d570e98ce2ff741c21d
73fe8b8fb4bd7776362fd356fdc189c93cf5d9f6724f6237d829024c10263fe5
39b3d8a8aedffc1b40820f205f6a4dc041cd37262880e5030b008175c45b0c46
013211c56caaa697914b5b5871e4998d0298902e336e373ebb27b7db30917eaf
f7cda90174b806a34381d5043e89b23ba826abcc89f7abd520060a64475ed506
22c15a32b69116a46eb5d0f2b228cc37cd1b5915a91ec8f38df79d3eed1da26b
MAR-251165.c1.v1.CLEAR_stix2.json

Size in bytes 8

7692288
6311936
15511700
8332689
8332689
26603668
6311936
6303744

Boolean 8

Community reviews

Loading reviews…