Proactive Defense: A Guide to Hunting the BRICKSTORM Espionage Campaign
Google Threat Intelligence Group (GTIG) is tracking BRICKSTORM malware activity, which is being used to maintain persistent access to victim organizations in the United States. This hunt is based on research released September 2025.
DISCLAIMER
Query.ai did not produce this threat report. All credit goes to Sekoia.io’s Threat Detection and Response (TDR) team which published this blog on September 16, 2025. This Threat Hunt is derived from their research, and a portion of the context and background will be copied here for reference, but the original blog can be referenced HERE
Threat Background
In a recent exposé, Google Cloud's threat intelligence teams, Mandiant and TAG, unveiled a sophisticated, global espionage campaign orchestrated by a North Korean government-backed threat actor tracked as UNC-002. Dubbed the "Brickstorm Espionage Campaign," this operation leverages a previously unknown custom backdoor to infiltrate and spy on organizations across a wide spectrum of industries, including media, technology, finance, and government. The campaign’s primary motive is intelligence gathering, making it a critical threat to national security and corporate intellectual property. As detailed in the Google Cloud article, the adversary demonstrates a high level of operational security and patience, often lurking within networks for extended periods before exfiltrating data.
At the heart of this campaign is the BRICKSTORM backdoor, a versatile malware family designed for stealth and persistence. Typically delivered through trojanized versions of legitimate software, BRICKSTORM provides the attacker with a persistent foothold in the victim's environment. Its capabilities are extensive, allowing for remote command execution, file transfers, and dynamic configuration updates. The malware's authors have gone to great lengths to evade detection, employing techniques like masquerading as legitimate system processes and using dynamic DNS services for their command and control (C2) infrastructure, making traditional, signature-based defenses less effective.
Given the sophisticated and evasive nature of this threat, a passive security posture is insufficient. We cannot simply wait for an alert to fire. Instead, we must proactively hunt for evidence of BRICKSTORM within our networks. Threat hunting is a practice grounded in the assumption that we have already been breached; the goal is to find the adversary before they can complete their objectives. This requires moving beyond simple IOCs and adopting a methodology based on the adversary's known tactics, techniques, and procedures (TTPs).
This guide provides a structured, hypothesis-driven approach to hunting for the Brickstorm Espionage Campaign. We will walk through the key stages of the attack lifecycle—from initial execution and persistence to C2 communications—and provide practical, ready-to-use Federated Search Query Language (FSQL) queries. These queries are designed to be run within the Query.ai platform, enabling your security team to federate searches across all relevant data sources like EDR, DNS logs, and firewall traffic from a single interface. By following these steps, you can transform the threat intelligence from Google's report into actionable defense, empowering your team to proactively uncover and mitigate this potent espionage threat before it causes significant damage.
Query Threat Hunting with FSQL
Query uses FSQL (Federated Search Query Language) to hunt for complex threats in an enterprise environment. FSQL's advantage is that it works with the Query Federated Security Data Mesh, so all activity is normalized to a common schema and can access multiple technologies with a single query. This makes hunting for advanced threats like this quicker than traditional hunting methodologies.
All Query Threat Hunting examples follow the Legacy Sqrrl Threat Hunting Maturity Model (THMM) and process. To that end the following hunt fits this category:
Statement: "We hypothesize that the threat actor UNC-002 has targeted our organization as part of their 'Brickstorm Espionage Campaign.' If so, they have likely deployed their custom backdoor, which would exist on an endpoint with a known-malicious file hash or a specific filename (pg_update, spclisten) identified in recent threat intelligence.".
Adversary: UNC-002
Tactic (MITREATT&CK): TA0002 - Execution
Technique (MITRE ATT&C): T1036 - Masquerading
Test (The Hunt): Execute FSQL Use Cases 1 and 2 to search all endpoints for the file hashes and filenames associated with the campaign. A positive result would validate the hypothesis and indicate a potential compromise.
Statement: "We hypothesize that if an endpoint was compromised by the BRICKSTORM backdoor, the adversary has established persistence on the host to survive a reboot. This would be evident on Linux systems through modifications to startup files like /etc/rc.local or the creation of a new systemd service."
Adversary: UNC-002
Tactic (MITREATT&CK): TA0003 - Persistence
Technique (MITRE ATT&C): T1543 - Create or Modify System Process
Test (The Hunt): Execute FSQL Use Case 3 to search file activity logs across Linux systems for modifications to /etc/rc.local or the /etc/systemd/system/ directory. A positive result would suggest a successful persistence attempt.
Statement: "We hypothesize that if the BRICKSTORM implant is active, it is now communicating with adversary-controlled command and control (C2) infrastructure. This activity would be observable as network traffic destined for dynamic DNS domains (sslip.io, nip.io) used by the actor to resolve C2 IP addresses."
Adversary: UNC-002
Tactic (MITREATT&CK): TA0011 - Command and Control
Technique (MITRE ATT&C): T1568 - Dynamic Resolution
Test (The Hunt): Execute FSQL Use Case 4 to search all network, DNS, and proxy logs for connections or queries related to sslip.io and nip.io domains. A positive result would validate the hypothesis and confirm an active C2 channel.
The set of FSQL queries developed for the "Brickstorm Espionage Campaign" aligns with Level 2 (Procedural) of the Sqrrl Hunting Maturity Model (HMM).
Here's why:
Threat Intelligence Driven: The hunts are not based on random searching but are directly informed by a high-fidelity threat intelligence report (the Google Cloud article).
Repeatable Procedures: The queries are documented in a standardized Use Case format, complete with metadata, MITRE ATT&CK® mapping, and clear investigative goals. This means another analyst could easily pick up and re-run this hunt in the future.
Data Source Awareness: The queries explicitly call out the required data sources (EDR, Sysmon, Firewall, DNS), demonstrating an understanding of the data needed to successfully execute the hunt.
Beyond Simple IOCs: While some queries hunt for basic IOCs (hashes, filenames), others target adversary Tactics, Techniques, and Procedures (TTPs) like specific persistence mechanisms and C2 communication patterns. This is a key indicator of moving beyond HMM1 (Minimal) which is almost exclusively focused on atomic indicators.
This is a very effective and efficient level of maturity. Your team has established procedures for consuming threat intelligence and translating it into repeatable, targeted hunts within your environment using FSQL.
Updated 10 months ago