Skip to main content
Threat Radar animated logo
DashboardThreatsMapFeedsAPILifetime Access
reconnecting
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.
Reconnecting to live updates…

BRICKSTORM Backdoor - MAR-251165.c1.v1

0
Medium
Unknownmisp-galaxy:producer="geminiproduction_cma"tlp:clearacs-marking:privilege_action="cisauses"acs-marking:classification="u"acs-marking:formal_determination="information-directly-related-to-cybersecurity-threat"misp-galaxy:stix-2.1-acs-marking="736f6810-1f28-5a7d-81b3-f7a498fb7cc8"misp-galaxy:country="china"type:osintosint:lifetime="perpetual"osint:certainty="50"tlp:whitemisp-galaxy:threat-actor="uta0178"
Published: Sat Dec 13 2025 (12/13/2025, 00:00:00 UTC)
Source: CIRCL OSINT Feed
Vendor/Project: tlp
Product: clear

Description

BRICKSTORM Backdoor - MAR-251165.c1.v1

AI-Powered Analysis

AILast updated: 12/13/2025, 16:21:50 UTC

Technical Analysis

BRICKSTORM is a backdoor malware linked to the Chinese threat actor UTA0178, as reported by the CIRCL OSINT feed. The malware's designation as a backdoor indicates it provides unauthorized remote access and control capabilities to attackers, enabling persistent presence on compromised systems. However, the available information lacks specifics on the attack vectors, affected software products, or versions, which complicates precise technical analysis. No patches or remediation measures are currently available, and there are no known exploits actively observed in the wild, suggesting it may be a newly identified or low-activity threat. The technical details provided are minimal, with only a UUID and an original timestamp, offering limited insight into its internal workings or propagation methods. The threat is tagged with medium severity, reflecting a moderate risk level based on potential unauthorized access and payload installation capabilities. The association with a Chinese threat actor and the presence of privilege escalation markings imply that the malware could be used in targeted espionage or cyber intrusion campaigns. Given the lack of detailed indicators or signatures, detection relies heavily on behavioral analysis and network anomaly monitoring. The threat's classification under 'payload installation' confirms its role in establishing footholds within victim environments. Overall, BRICKSTORM represents a stealthy and persistent threat that requires proactive defense measures despite limited current exploitation evidence.

Potential Impact

For European organizations, BRICKSTORM poses a risk of unauthorized remote access, data exfiltration, and potential disruption of operations due to its backdoor capabilities. The lack of known exploits in the wild reduces immediate risk but does not eliminate the threat of future targeted attacks, especially against critical infrastructure, government entities, and technology firms. The malware's ability to install persistent payloads could facilitate long-term espionage or sabotage campaigns, undermining confidentiality, integrity, and availability of sensitive systems. European entities with supply chain ties to Chinese technology or those operating in sectors of strategic importance may face elevated exposure. The medium severity suggests moderate impact potential, but the stealthy nature of backdoors can lead to prolonged undetected compromises, increasing cumulative damage. Additionally, the absence of patches means organizations must rely on detection and containment rather than remediation. The threat could disrupt trust in digital ecosystems and complicate incident response efforts if leveraged in coordinated cyber operations.

Mitigation Recommendations

1. Implement advanced endpoint detection and response (EDR) solutions capable of identifying anomalous behaviors indicative of backdoor activity, such as unusual network connections or process executions. 2. Enforce strict network segmentation to limit lateral movement opportunities for attackers leveraging backdoors. 3. Conduct regular threat hunting exercises focusing on indicators of compromise related to persistent payload installation and privilege escalation. 4. Integrate threat intelligence feeds, including CIRCL OSINT, to stay updated on emerging indicators and tactics associated with BRICKSTORM and UTA0178. 5. Harden access controls by applying the principle of least privilege and enforcing multi-factor authentication to reduce the risk of unauthorized access. 6. Monitor outbound network traffic for suspicious communications to unknown or high-risk IP addresses, especially those linked to Chinese threat actors. 7. Maintain comprehensive logging and audit trails to facilitate incident investigation and rapid response. 8. Educate security teams on the characteristics of backdoor malware and the specific threat actor profile to improve detection capabilities. 9. Collaborate with national cybersecurity agencies and industry partners to share intelligence and coordinate defense strategies. 10. Prepare incident response plans that include scenarios involving stealthy backdoor intrusions to ensure readiness.

Affected Countries

GermanyGermany
FranceFrance
United KingdomUnited Kingdom
NetherlandsNetherlands
ItalyItaly
SpainSpain
PolandPoland
Need more detailed analysis?Get Pro

Technical Details

Uuid
449f1f02-54d1-4af7-9bd8-beaba99e6d0c
Original Timestamp
1765616210

Indicators of Compromise

Yara

ValueDescriptionCopy
yara'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--
yara'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.
yara'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--
yara'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

ValueDescriptionCopy
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textsophos
—
textunknown
—
textLinux/Brick-B
—
textThis 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--
—
textbackdoor
—
texttrojan
—
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textThis 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.
—
texttrojan
—
textbackdoor
—
texteset
—
textunknown
—
texta variant of Linux/Packed.Obfuscated.B suspicious application
—
textThis 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--
—
textbackdoor
—
texttrojan
—
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textThis 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, which is designed to handle environment variables for connection parameters, set up logging, configure a WebSocket connector, create service instances, and define request handlers for different request types. The backdoor uses the SOCKS proxying, VSOCK proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor uses XOR cipher encryption to hide key strings within its code. The backdoor variables, core functions, and extended arguments are obfuscated using a custom-built sophisticated tool-set to evade detection and hinder analysis. Upon execution, the backdoor retrieves three C2 connection parameters from environment variables below: --Begin Configuration Values-- listenAddr ==> Listen address and port (default: "127.0.0.1:8090"). listenPath ==> Listen path to route requests to a handler function (WSS connection). password ==> Authentication key (AuthKey). --End Configuration Values-- If the environment variables for connection parameters are retrieved, the backdoor initiates a function "main_startNew" to configure environment variables. The backdoor checks the current working directory path and compares it with the value of the retrieved environment variable "VARGS" to determine if the backdoor is running as a child process. If they do not match, indicating a child process is not running, the backdoor copies itself to a new constructed path on the system. The backdoor then prepends the new constructed path to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor starts the new process and terminates its own execution. The backdoor uses the 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 the value of the retrieved environment variable "VREG" and compares it with the current working directory path. If the checks return a "false" value, then "VREG" is not set, indicating the backdoor is not running correctly, the backdoor re-installs itself to a new constructed path on the system. The backdoor then prepends the new constructed path to the PATH environment variable. The newly copied backdoor file 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 that "VREG" is set, the "main_selfWatcher" function allows the code to continue its normal malicious operations. The backdoor attempts to establish a WSS server with minimal external dependencies. This setup allows for encrypted communication without relying on a publicly trusted Certificate Authority or certificate files on disk. The backdoor dynamically generates a self-signed X.509 certificate and a corresponding 2048-bit private key in memory. The in-memory generated certificate and the private key are then loaded into a "tls.Certificate" struct, which is then assigned to the Certificates field of a "tls.Config" object. A standard "net/http" server is configured to use this custom "tls.Config" to handle HTTPS/WSS connections. The backdoor utilizes a single, multiplexed connection over WSS to a specified C2 address (listenAddr) and path (listenPath). The backdoor implements a custom authentication check, involving the specific pre-shared AuthKey (password), during or before the WSS handshake, the connection upgrade process. Once the WSS connection is established, all communication is encrypted. This encryption leverages the in-memory self-signed certificates. 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 six core handlers and their functions: --Begin Core Handlers-- a. The Socks handler (Figure 5) establishes a SOCKS relay, which facilitates lateral movement within a compromised network and routes C2 traffic. 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. The handler performs SOCKS relaying and network tunneling over Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). b. The WebService handler (Figure 6) 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" 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. c. The CommandNoContext handler (Figure 7) executes commands on the compromised system without using an explicit security context. d. The Command handler (Figure 8) executes commands on the compromised system with a specific security context. The handler executes shell commands on the compromised system, 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. e. The VSOCK-proxy handler (Figure 9) implements a proxy that dynamically configures its outgoing connections based on a JSON payload received in the incoming request. The handler processes an incoming network request containing a JSON payload with specific configuration arguments to establish a tunneled connection. The handler unmarshals the JSON data and validates the extracted arguments below: --Begin Configuration Arguments-- TunnelAddr: The destination network address (IP address or hostname) where the proxy will forward data from the VSOCK connection. CID: A unique identifier for a virtual machine or the host within the VSOCK environment. Port: The port number used for the connection Family ==> The address type specified as AF_VSOCK --End Configuration Arguments-- Using the validated arguments, the handler binds to a specific VSOCK address (defined by the CID and Port). It then establishes a connection to the destination specified by "TunnelAddr". The handler relays traffic between the client and the target server. This can be a direct tunnel or a relay via the proxy, depending on the configuration. The VSOCK-proxy can be used to maintain covert communication channels, evade detection, and pivot within virtualized environments. Upon completion or termination of the connection, the handler sends an appropriate success or error response back to the client. f. The VSOCK connection handler (Figure 10) processes an incoming network request containing a JSON payload with specific configuration arguments to connect 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 CID, Port, and Family. The handler checks the unmarshalled data for validity and if the configuration is valid, the handler creates or connects 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. --End Core Handlers--
—
texttrojan
—
textbackdoor
—
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textThis 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, which is designed to handle environment variables for connection parameters, set up logging, configure a WebSocket connector, create service instances, and define request handlers for different request types. The backdoor uses the VSOCK proxying, multi-layered web service communication, and varied command execution to obscure its activities. The backdoor uses Exclusive OR (XOR) cipher encryption to hide key strings within its code. The backdoor variables, core functions, and extended arguments are obfuscated using a custom-built sophisticated tool-set to evade detection and hinder analysis. Upon execution, the backdoor retrieves three C2 connection parameters from environment variables below: --Begin Configuration Values-- listenAddr ==> Listen address and port (default: "127.0.0.1:8090") listenPath ==> Listen path to route requests to a handler function (WebSocket Secure (WSS) connection). password ==> Authentication key (AuthKey). --End Configuration Values-- If the environment variables for connection parameters are retrieved, the backdoor initiates a function to configure environment variables. The backdoor checks the current working directory path and compares it with the value of the retrieved environment variable "VARGS" to determine if the backdoor is running as a child process. If they do not match, indicating that a child process is not running, the backdoor copies itself to a new constructed path on the system. The backdoor will then prepend the new constructed path to the PATH environment variable, ensuring the newly copied backdoor takes precedence in execution. The backdoor starts the new process and terminates its own execution. 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 the value of the retrieved environment variable "VREG" and compares it with the current working directory path. If the checks return a "false" value, then the "VREG" is not set, indicating the backdoor is not running correctly, and the backdoor will re-install itself to a new constructed path on the system. The backdoor then prepends the new constructed path to the PATH environment variable. The newly copied backdoor file 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, then the "VREG" is set, and the function allows the code to continue its normal malicious operations. The backdoor attempts to establish a WSS server with minimal external dependencies. This setup allows for encrypted communication without relying on a publicly trusted Certificate Authority or certificate files on disk. The backdoor dynamically generates a self-signed X.509 certificate and a corresponding 2048-bit private key in memory. The in-memory generated certificate and the private key are then loaded into a "tls.Certificate" struct, which is then assigned to the Certificates field of a "tls.Config" object. A standard "net/http" server is configured to use this custom "tls.Config" to handle HTTPS/WSS connections. The backdoor utilizes a single, multiplexed connection over WSS to a specified C2 address (listenAddr) and path (listenPath). The backdoor implements a custom authentication check, involving the specific pre-shared AuthKey (password), during or before the WSS handshake, the connection upgrade process. Once the WSS connection is established, all communication is encrypted. This encryption leverages the in-memory self-signed certificates. 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 WebService handler (Figure 1) 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" 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. b. The Command handler (Figure 2) executes shell commands on the compromised system, 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. c. The VSOCK-proxy handler (Figure 3) implements a proxy that dynamically configures its outgoing connections based on a JSON payload received in the incoming request. The handler processes an incoming network request containing a JSON payload with specific configuration arguments to establish a tunneled connection. The handler unmarshals the JSON data and validates the extracted arguments below: --Begin Configuration Arguments-- TunnelAddr: The destination network address (IP address or hostname) where the proxy will forward data from the VSOCK connection. Context ID (CID): A unique identifier for a virtual machine or the host within the VSOCK environment. Port: The port number used for the connection Family ==> The address type specified as AF_VSOCK --End Configuration Arguments-- Using the validated arguments, the handler binds to a specific VSOCK address (defined by the CID and Port). It then establishes a connection to the destination specified by "TunnelAddr". The handler relays traffic between the client and the target server. This can be a direct tunnel or a relay via the proxy, depending on the configuration. The VSOCK-proxy can be used to maintain covert communication channels, evade detection, and pivot within virtualized environments. Upon completion or termination of the connection, the handler sends an appropriate success or error response back to the client. d. The VSOCK connection handler (Figure 4) processes an incoming network request containing a JSON payload with specific configuration arguments to connect 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 CID, Port, and Family. The handler checks the unmarshalled data for validity and if the configuration is valid, the handler creates or connects 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. --End Core Handlers--
—
texttrojan
—
textbackdoor
—
texteset
—
textunknown
—
texta variant of Linux/Packed.Obfuscated.B suspicious application
—
textThis 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--
—
textbackdoor
—
texttrojan
—
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textThis 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/cloudapi ==> 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]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/vmckd". If not running from the specified file path "/etc/sysconfig/vmckd", 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 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 another environment variable "[redacted]NET3" and confirms the existence of the process named "updatemgr". If the checks return a "false" value, indicating "[redacted]NET3" is not set, the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/vmckd" 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 "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/cloudapi". 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.
—
texttrojan
—
textbackdoor
—
texteset
—
textunknown
—
texta variant of Linux/BrickStorm.A trojan
—
textThis 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/api ==> 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 "FIOON" environment variable to determine if it is running as a child process. If "FIOON" 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/vts". If not running from the specified file path "/etc/sysconfig/vts", 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 "FIOON" 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 "DIGNN" environment variable and confirms the existence of a process named "updatemgr". If the checks return a "false" value ("DIGNN" is not set ), indicating the backdoor is not running correctly, the backdoor re-installs itself from "/etc/sysconfig/vts" 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 "DIGNN" 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://1.1.1.1/dns-query (Cloudflare) https://1.0.0.1/dns-query (Cloudflare) --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 or Google 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/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 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.
—
texttrojan
—
textbackdoor
—
textSTIX 2.1
—

Hash

ValueDescriptionCopy
hash8e4c88d00b6eb46229a1ed7001451320
—
hash9bf4c786ebd68c0181cfe3eb85d2fd202ed12c54
—
hashaaf5569c8e349c15028bc3fac09eb982efb06eabac955b705a6d447263658e38
—
hash5e654776e9c419e11e6f93a452415a601bd9a2079710f1074608570e498a9af37b81bb57c98cb8bb626c5ee4b3e35757d3ae8c1c3717f28d9f3fe7a4cebe0608
—
hash8e4c88d00b6eb46229a1ed7001451320
—
hash9bf4c786ebd68c0181cfe3eb85d2fd202ed12c54
—
hashaaf5569c8e349c15028bc3fac09eb982efb06eabac955b705a6d447263658e38
—
hash5e654776e9c419e11e6f93a452415a601bd9a2079710f1074608570e498a9af37b81bb57c98cb8bb626c5ee4b3e35757d3ae8c1c3717f28d9f3fe7a4cebe0608
—
hash0a4fa52803a389311a9ddc49b7b19138
—
hash97001baaa379bcd83677dca7bc5b8048fdfaaddc
—
hashb3b6a992540da96375e4781afd3052118ad97cfe60ccf004d732f76678f6820a
—
hash65ebf5dfafb8972ffead44271436ec842517cfaaf3d1f1f1237a32d66e1d280943bd3a69f1d539a1b7aca6152e96b29bc822e1047e2243f6aec8959595560147
—
hash0a4fa52803a389311a9ddc49b7b19138
—
hash97001baaa379bcd83677dca7bc5b8048fdfaaddc
—
hashb3b6a992540da96375e4781afd3052118ad97cfe60ccf004d732f76678f6820a
—
hash65ebf5dfafb8972ffead44271436ec842517cfaaf3d1f1f1237a32d66e1d280943bd3a69f1d539a1b7aca6152e96b29bc822e1047e2243f6aec8959595560147
—
hashdbca28ad420408850a94d5c325183b28
—
hashfb11c6caa4ea844942fe97f46d7eb42bc76911ab
—
hash57bd98dbb5a00e54f07ffacda1fea91451a0c0b532cd7d570e98ce2ff741c21d
—
hash659205fa2cfa85e484c091cc2e85a7ec4e332b196e423b1f39bafdc8fca33e3db712bbe07afcc091ff26d9b4f641fa9a73f2a66dce9a0ced54ebeb8c2be82a7f
—
hashdbca28ad420408850a94d5c325183b28
—
hashfb11c6caa4ea844942fe97f46d7eb42bc76911ab
—
hash57bd98dbb5a00e54f07ffacda1fea91451a0c0b532cd7d570e98ce2ff741c21d
—
hash659205fa2cfa85e484c091cc2e85a7ec4e332b196e423b1f39bafdc8fca33e3db712bbe07afcc091ff26d9b4f641fa9a73f2a66dce9a0ced54ebeb8c2be82a7f
—
hasha02469742f7b0bc9a8ab5e26822b3fa8
—
hash10d811029f6e5f58cd06143d6353d3b05bc06d0f
—
hash73fe8b8fb4bd7776362fd356fdc189c93cf5d9f6724f6237d829024c10263fe5
—
hash8e29aeb3603ffe307b2d60f7401bd9978bebe8883235eb88052ebf6b9e04ce6bf35667480cedea5712c1e13e8c6dcfb34d5fde0ddca6ca31328de0152509bf8f
—
hasha02469742f7b0bc9a8ab5e26822b3fa8
—
hash10d811029f6e5f58cd06143d6353d3b05bc06d0f
—
hash73fe8b8fb4bd7776362fd356fdc189c93cf5d9f6724f6237d829024c10263fe5
—
hash8e29aeb3603ffe307b2d60f7401bd9978bebe8883235eb88052ebf6b9e04ce6bf35667480cedea5712c1e13e8c6dcfb34d5fde0ddca6ca31328de0152509bf8f
—
hasha52e36a70b5e0307cbcaa5fd7c97882c
—
hash44a3d3f15ef75d9294345462e1b82272b0d11985
—
hash39b3d8a8aedffc1b40820f205f6a4dc041cd37262880e5030b008175c45b0c46
—
hashbbe18d32bef66ccfa931468511e8ba55b32943e47a1df1e68bb5c8f8ae97a5bf991201858ae9632fa24df5f6c674b6cb260297a1c11889ca61bda68513f440ce
—
hasha52e36a70b5e0307cbcaa5fd7c97882c
—
hash44a3d3f15ef75d9294345462e1b82272b0d11985
—
hash39b3d8a8aedffc1b40820f205f6a4dc041cd37262880e5030b008175c45b0c46
—
hashbbe18d32bef66ccfa931468511e8ba55b32943e47a1df1e68bb5c8f8ae97a5bf991201858ae9632fa24df5f6c674b6cb260297a1c11889ca61bda68513f440ce
—
hash39111508bfde89ce6e0fe6abe0365552
—
hashf639d9404c03af86ce452db5c5e0c528b81dc0d7
—
hash013211c56caaa697914b5b5871e4998d0298902e336e373ebb27b7db30917eaf
—
hash74b4c6f7c7cae07c6f8edf3f2fb1e9206d4f1f9734e8e4784b15d192eec8cd8a4f59078fc0c56dc4ad0856cdd792337b5c92ffd3d2240c8a287a776df4363bba
—
hash39111508bfde89ce6e0fe6abe0365552
—
hashf639d9404c03af86ce452db5c5e0c528b81dc0d7
—
hash013211c56caaa697914b5b5871e4998d0298902e336e373ebb27b7db30917eaf
—
hash74b4c6f7c7cae07c6f8edf3f2fb1e9206d4f1f9734e8e4784b15d192eec8cd8a4f59078fc0c56dc4ad0856cdd792337b5c92ffd3d2240c8a287a776df4363bba
—
hash18f895e24fe1181bb559215ff9cf6ce3
—
hashc3549d4e5e39a11f609fc6fbf5cc1f2c0ec272b4
—
hashf7cda90174b806a34381d5043e89b23ba826abcc89f7abd520060a64475ed506
—
hash79276523a6a507e3fa1b12b96e09b10a01c783a53d58b9ae7f5780a379431639a80165e81154522649b8e2098e86d1a310efffebe32faafc7b3bc093eec60a64
—
hash18f895e24fe1181bb559215ff9cf6ce3
—
hashc3549d4e5e39a11f609fc6fbf5cc1f2c0ec272b4
—
hashf7cda90174b806a34381d5043e89b23ba826abcc89f7abd520060a64475ed506
—
hash79276523a6a507e3fa1b12b96e09b10a01c783a53d58b9ae7f5780a379431639a80165e81154522649b8e2098e86d1a310efffebe32faafc7b3bc093eec60a64
—
hash82bf31e7d768e6d4d3bc7c8c8ef2b358
—
hashde28546ec356c566cd8bca205101a733e9a4a22d
—
hash22c15a32b69116a46eb5d0f2b228cc37cd1b5915a91ec8f38df79d3eed1da26b
—
hash4c52caf2e5f114103ed5f60c6add3aa26c741b07869bb66e3c25a1dc290d4a8bf87c42c336e8ac8ebf82d9a9b23eaa18c31f7051a5970a8fe1125a2da890340f
—
hash82bf31e7d768e6d4d3bc7c8c8ef2b358
—
hashde28546ec356c566cd8bca205101a733e9a4a22d
—
hash22c15a32b69116a46eb5d0f2b228cc37cd1b5915a91ec8f38df79d3eed1da26b
—
hash4c52caf2e5f114103ed5f60c6add3aa26c741b07869bb66e3c25a1dc290d4a8bf87c42c336e8ac8ebf82d9a9b23eaa18c31f7051a5970a8fe1125a2da890340f
—

Ssdeep

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

File

ValueDescriptionCopy
filevmsrc
—
fileb3b6a992540da96375e4781afd3052118ad97cfe60ccf004d732f76678f6820a
—
file57bd98dbb5a00e54f07ffacda1fea91451a0c0b532cd7d570e98ce2ff741c21d
—
file73fe8b8fb4bd7776362fd356fdc189c93cf5d9f6724f6237d829024c10263fe5
—
file39b3d8a8aedffc1b40820f205f6a4dc041cd37262880e5030b008175c45b0c46
—
file013211c56caaa697914b5b5871e4998d0298902e336e373ebb27b7db30917eaf
—
filef7cda90174b806a34381d5043e89b23ba826abcc89f7abd520060a64475ed506
—
file22c15a32b69116a46eb5d0f2b228cc37cd1b5915a91ec8f38df79d3eed1da26b
—
fileMAR-251165.c1.v1.CLEAR_stix2.json
—

Size in-bytes

ValueDescriptionCopy
size-in-bytes7692288
—
size-in-bytes6311936
—
size-in-bytes15511700
—
size-in-bytes8332689
—
size-in-bytes8332689
—
size-in-bytes26603668
—
size-in-bytes6311936
—
size-in-bytes6303744
—

Boolean

ValueDescriptionCopy
boolean0
—
boolean0
—
boolean0
—
boolean0
—
boolean0
—
boolean0
—
boolean0
—
boolean0
—

Threat ID: 693d8f0cda1dfeffd83d742d

Added to database: 12/13/2025, 4:06:36 PM

Last enriched: 12/13/2025, 4:21:50 PM

Last updated: 12/14/2025, 5:45:49 PM

Views: 14

Community Reviews

0 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Related Threats

ThreatFox IOCs for 2025-12-13

Medium
MalwareSun Dec 14 2025

ThreatFox IOCs for 2025-12-12

Medium
MalwareSat Dec 13 2025

ThreatFox IOCs for 2025-12-11

Medium
MalwareFri Dec 12 2025

ThreatFox IOCs for 2025-12-10

Medium
MalwareThu Dec 11 2025

ThreatFox IOCs for 2025-12-09

Medium
MalwareWed Dec 10 2025

Actions

PRO

Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.

Please log in to the Console to use AI analysis features.

External Links

Search on Google

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats