{
	"id": "fa71df58-64f7-4327-ac41-48e4ccc2acaf",
	"created_at": "2026-04-06T00:07:54.093593Z",
	"updated_at": "2026-04-10T03:37:17.23736Z",
	"deleted_at": null,
	"sha1_hash": "59b4660c9819d21d97621fadcac9e93be556164c",
	"title": "Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 333138,
	"plain_text": "Another BRICKSTORM: Stealthy Backdoor Enabling Espionage\r\ninto Tech and Legal Sectors\r\nBy Mandiant, Google Threat Intelligence Group\r\nPublished: 2025-09-24 · Archived: 2026-04-05 17:16:46 UTC\r\nWritten by: Sarah Yoder, John Wolfram, Ashley Pearson, Doug Bienstock, Josh Madeley, Josh Murchie, Brad\r\nSlaybaugh, Matt Lin, Geoff Carstairs, Austin Larsen\r\nIntroduction\r\nGoogle Threat Intelligence Group (GTIG) is tracking BRICKSTORM malware activity, which is being used to\r\nmaintain persistent access to victim organizations in the United States. Since March 2025, Mandiant Consulting\r\nhas responded to intrusions across a range of industry verticals, most notably legal services, Software as a Service\r\n(SaaS) providers, Business Process Outsourcers (BPOs), and Technology. The value of these targets extends\r\nbeyond typical espionage missions, potentially providing data to feed development of zero-days and establishing\r\npivot points for broader access to downstream victims.\r\nWe attribute this activity to UNC5221 and closely related, suspected China-nexus threat clusters that employ\r\nsophisticated capabilities, including the exploitation of zero-day vulnerabilities targeting network appliances.\r\nWhile UNC5221 has been used synonymously with the actor publicly reported as Silk Typhoon, GTIG does not\r\ncurrently consider the two clusters to be the same. \r\nThese intrusions are conducted with a particular focus on maintaining long-term stealthy access by deploying\r\nbackdoors on appliances that do not support traditional endpoint detection and response (EDR) tools. The actor\r\nemploys methods for lateral movement and data theft that generate minimal to no security telemetry. This, coupled\r\nwith modifications to the BRICKSTORM backdoor, has enabled them to remain undetected in victim\r\nenvironments for 393 days, on average. Mandiant strongly encourages organizations to reevaluate their threat\r\nmodel for appliances and conduct hunt exercises for this highly evasive actor. We are sharing an updated threat\r\nactor lifecycle for BRICKSTORM associated intrusions, along with specific and actionable steps organizations\r\nshould take to hunt for and protect themselves from this activity.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 1 of 20\n\nFigure 1: BRICKSTORM targeting\r\nThreat Actor Lifecycle\r\nThe actor behind BRICKSTORM employs sophisticated techniques to maintain persistence and minimize the\r\nvisibility traditional security tools have into their activities. The section is a review of techniques observed from\r\nmultiple Mandiant investigations, with customer details sanitized.\r\nInitial Access\r\nA consistent challenge across Mandiant investigations into BRICKSTORM intrusions has been determining the\r\ninitial intrusion vector. In many cases, the average dwell time of 393 days exceeded log retention periods and the\r\nartifacts of the initial intrusion were no longer available. Despite these challenges, a pattern in the available\r\nevidence points to the actor's focus on compromising perimeter and remote access infrastructure.\r\nIn at least one case, the actor gained access by exploiting a zero-day vulnerability. Mandiant has identified\r\nevidence of this actor operating from several other edge appliances early in the lifecycle, but could not find\r\ndefinitive evidence of vulnerability exploitation. As noted in our previous blog post from April 2025, Mandiant\r\nhas identified the use of post-exploitation scripts that have included a wide range of anti-forensics functions\r\ndesigned to obscure entry.\r\nEstablish Foothold\r\nThe primary backdoor used by this actor is BRICKSTORM, as previously discussed by Mandiant and others.\r\nBRICKSTORM includes SOCKS proxy functionality and is written in Go, which has wide cross-platform\r\nsupport. This is essential to support the actor’s preference to deploy backdoors on appliance platforms that do not\r\nsupport traditional EDR tools. Mandiant has found evidence of BRICKSTORM on Linux and BSD-based\r\nappliances from multiple manufacturers. Although there is evidence of a BRICKSTORM variant for Windows,\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 2 of 20\n\nMandiant has not observed it in any investigation. Appliances are often poorly inventoried, not monitored by\r\nsecurity teams, and excluded from centralized security logging solutions. While BRICKSTORM has been found\r\non many appliance types, UNC5221 consistently targets VMware vCenter and ESXi hosts. In multiple cases, the\r\nthreat actor deployed BRICKSTORM to a network appliance prior to pivoting to VMware systems. The actor\r\nmoved laterally to a vCenter server in the environment using valid credentials, which were likely captured by the\r\nmalware running on the network appliances.\r\nOur analysis of samples recovered from different victim organizations has found evidence of active development\r\nof BRICKSTORM. While the core functionality has remained, some samples are obfuscated using Garble and\r\nsome carry a new version of the custom wssoft library. Mandiant recovered one sample of BRICKSTORM with\r\na “delay” timer built-in that waited for a hard-coded date months in the future before beginning to beacon to the\r\nconfigured command and control domain. Notably, this backdoor was deployed on an internal vCenter server after\r\nthe victim organization had begun their incident response investigation, demonstrating that the threat actor was\r\nactively monitoring and capable of rapidly adapting their tactics to maintain persistence.\r\nAs previously reported, BRICKSTORM deployments are often designed to blend in with the target appliance,\r\nwith the naming convention and even the functionality of the sample being designed to masquerade as legitimate\r\nactivity. Mandiant has identified samples using Cloudflare Workers and Heroku applications for C2, as well as\r\nsslip.io or nip.io to resolve directly to C2 IP addresses. From the set of samples we’ve recovered, there has been\r\nno reuse of C2 domains across victims.\r\nEscalate Privileges\r\nAt one investigation, Mandiant analyzed a vCenter server and found the threat actor installed a malicious Java\r\nServlet filter for the Apache Tomcat server that runs the web interface for vCenter. A Servlet Filter is code that\r\nruns every time the web server receives an HTTP request. Normally, installing a filter requires modifying a\r\nconfiguration file and restarting or reloading the application; however, the actor used a custom dropper that made\r\nthe modifications entirely in memory, making it very stealthy and negating the need for a restart. The malicious\r\nfilter, tracked by Mandiant as BRICKSTEAL, runs on HTTP requests to the vCenter web login Uniform Resource\r\nIndicators (URIs) /web/saml2/sso/* . If present, it decodes the HTTP Basic authentication header, which may\r\ncontain a username and password. Many organizations use Active Directory authentication for vCenter, which\r\nmeans BRICKSTEAL could capture those credentials. Often, users who log in to vCenter have a high level of\r\nprivilege in the rest of the enterprise. Previously shared hardening guidance for vSphere includes steps that can\r\nmitigate the ability of BRICKSTEAL to capture usable credentials in this scenario, such as enforcement of multi-factor authentication (MFA). \r\nVMware vCenter is an attractive target for threat actors because it acts as the management layer for the vSphere\r\nvirtualization platform and can take actions on VMs such as creating, snapshotting, and cloning. In at least two\r\ncases, the threat actor used their access to vCenter to clone Windows Server VMs for key systems such as Domain\r\nControllers, SSO Identity Providers, and secret vaults. This is a technique that other threat actors have used. With\r\na clone of the virtual machine, the threat actor can mount the filesystem and extract files of interest, such as the\r\nActive Directory Domain Services database ( ntds.dit ). Although these Windows Servers likely have security\r\ntools installed on them, the threat actor never powers on the clone so the tools are not executed. The following\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 3 of 20\n\nexample shows vCenter VPXD logs of the threat actor using the local vSphere Administrator account to clone a\r\nVM.\r\n2025-04-01 03:37:40 [vim.event.TaskEvent] [info] [VSPHERE.LOCAL\\Administrator] [\u003cvCenter inventory object\u003e] [\u003cu\r\n2025-04-01 03:37:49 [vim.event.VmBeingClonedEvent] [info] [VSPHERE.LOCAL\\Administrator] [\u003cvCenter inventory obje\r\n2025-04-01 03:42:07 [vim.event.VmClonedEvent] [info] [VSPHERE.LOCAL\\Administrator] [\u003cvCenter inventory object\u003e]\r\n2025-04-01 04:05:40 [vim.event.TaskEvent] [info] [VSPHERE.LOCAL\\Administrator] [\u003cvCenter inventory object\u003e] [\u003cun\r\n2025-04-01 04:05:47 [vim.event.VmRemovedEvent] [info] [VSPHERE.LOCAL\\Administrator] [\u003cvCenter inventory object\u003e]\r\nIn one instance the threat actor used legitimate server administrator credentials to repeatedly move laterally to a\r\nsystem running Delinea (formerly Thycotic) Secret Server. The forensic artifacts recovered from the system were\r\nconsistent with the execution of a tool, such as secret stealer, to automatically extract and decrypt all credentials\r\nstored by the Secret Server application.\r\nMove Laterally \r\nTypically, at least one instance of BRICKSTORM would be the primary source of hands-on keyboard activity,\r\nwith two or more compromised appliances serving as backups. To install BRICKSTORM, the actor used\r\nlegitimate credentials to connect to the appliance, often with SSH. In one instance the actor used credentials\r\nknown to be stored in a password vault they previously accessed. In another instance they used credentials known\r\nto be stored in a PowerShell script the threat actor previously viewed. In multiple cases the actor logged in to\r\neither the ESXi web-based UI or the vCenter Appliance Management Interface (VAMI) to enable the SSH service\r\nso they could connect and install BRICKSTORM. The following are example VAMI access events that show the\r\nthreat actor connecting to VAMI and making changes to the SSH settings for vCenter.\r\n::ffff:\u003cSource IP\u003e \u003cvCenter IP\u003e:5480 - [\u003ctimestamp\u003e] \"GET / HTTP/1.1\" 200 1153 \"-\" \"\u003cUser Agent\u003e\"\r\n::ffff:\u003cSource IP\u003e \u003cvCenter IP\u003e:5480 - [\u003ctimestamp\u003e] \"POST /rest/com/vmware/cis/session HTTP/1.1\" 200 60 \"https:\r\n::ffff:\u003cSource IP\u003e \u003cvCenter IP\u003e:5480 - [\u003ctimestamp\u003e] \"PUT /rest/appliance/access/ssh HTTP/1.1\" 200 0 \"https://10\r\nEstablish Persistence\r\nTo maintain access to victim environments, the threat actor modified the init.d , rc.local , or systemd files\r\nto ensure BRICKSTORM started on appliance reboot. In multiple cases, the actor used the sed command line\r\nutility to modify legitimate startup scripts to launch BRICKSTORM. The following are a few example sed\r\ncommands executed by the actor on vCenter.\r\nsed -i s/export TEXTDOMAIN=vami-lighttp/export TEXTDOMAIN=vami-lighttp\\n\\/path/to/brickstorm/g /opt/vmware/etc/\r\nsed -i $a\\SETCOLOR_WARNING=\"echo -en `/path/to/brickstorm`\\\\033[0;33m\" /etc/sysconfig/init\r\nThe threat actor has also created a web shell tracked by Mandiant as SLAYSTYLE on vCenter servers.\r\nSLAYSTYLE, tracked by MITRE as BEEFLUSH, is a JavaServer Pages (JSP) web shell that functions as a\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 4 of 20\n\nbackdoor. It is designed to receive and execute arbitrary operating system commands passed through an HTTP\r\nrequest. The output from these commands is returned in the body of the HTTP response.\r\nComplete Mission\r\nA common theme across investigations is the threat actor’s interest in the emails of key individuals within the\r\nvictim organization. To access the email mailboxes of target accounts, the threat actor made use of Microsoft\r\nEntra ID Enterprise Applications with mail.read or full_access_as_app scopes. Both scopes allow the\r\napplication to access mail in any mailbox. In some cases, the threat actor targeted the mailboxes of developers and\r\nsystem administrators while in other cases, they targeted the mailboxes of individuals involved in matters that\r\nalign with PRC economic and espionage interests.\r\nWhen the threat actor exfiltrated files from the victim environment, they used the SOCKS proxy feature of\r\nBRICKSTORM to tunnel their workstation and directly access systems and web applications of interest. In\r\nmultiple cases the threat actor used legitimate credentials to log in to the web interface for internal code stores and\r\ndownload repositories as ZIP archives. In other cases the threat actor browsed to specific directories and files on\r\nremote machines by specifying Windows Universal Naming Convention (UNC) paths.\r\nIn several cases the BRICKSTORM samples deployed by the threat actor were removed from compromised\r\nsystems. In these cases, the presence of BRICKSTORM was observed by conducting forensic analysis of backup\r\nimages that identified the BRICKSTORM malware in place.\r\nHunting Guidance\r\nMandiant has previously discussed the diminishing usefulness of atomic IOCs and the need to adopt TTP-based\r\nhunting. Across BRICKSTORM investigations we have not observed the reuse of C2 domains or malware\r\nsamples, which, coupled with high operational security, means these indicators quickly expire or are never\r\nobserved at all. Therefore, a TTP-based hunting approach is not only an ideal practice, but a necessity to detect\r\npatterns of attack that are unlikely to be detected by traditional signature-based defenses. The following is a\r\nchecklist of the minimal set of hunts Mandiant recommends organizations conduct to search for BRICKSTORM\r\nand related activities.\r\nStep Hunt Data Sources\r\n0\r\nCreate or update asset inventory that includes edge\r\ndevices and other appliances\r\nN/A\r\n1 File and backup scan for BRICKSTORM Appliance file system, backups\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 5 of 20\n\n2 Internet traffic from edge devices and appliances\r\nFirewall connection logs, DNS logs, IDS/IPS,\r\nnetflow\r\n3\r\nAccess to Windows servers and desktops from\r\nappliances\r\nEDR telemetry, Security Event Logs, Terminal\r\nService Logs, Windows UAL\r\n4 Access to credentials and secrets Windows Shellbags, EDR telemetry\r\n5\r\nAccess to M365 mailboxes using Enterprise\r\nApplication\r\nM365 UAL\r\n6 Cloning of sensitive virtual machines vSphere VPXD logs\r\n7 Creation of local vCenter and ESXi accounts VMware audit events\r\n8 SSH enablement on vSphere platform VMware audit events, VAMI logs\r\n9 Rogue VMs VMware audit events, VM inventory reports\r\nCreate or Update Asset Inventory\r\nFoundational to the success of any threat hunt is an asset inventory that includes devices not covered by the\r\nstandard security tool stack, such as edge devices and other appliances. Because these appliances lack support for\r\ntraditional security tools an inventory is critical for developing effective compensating controls and detections.\r\nEspecially important is to track the management interface addresses of these appliances, as they act as the default\r\ngateway that malware and threat actor commands will egress out of.\r\nMandiant recommends organizations take a multi-step approach to building or updating this inventory:\r\n1. Known knowns: Begin with the appliance classes that all organizations use: firewalls, VPN concentrators,\r\nvirtualization platforms, conferencing systems, badging, and file storage.\r\n2. Known unknowns: Work across teams to brainstorm appliance classes that may be more specialized to\r\nyour organization, but the security organization likely lacks visibility into.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 6 of 20\n\n3. Unknown unknowns: These are the appliances that were supposed to be decommissioned but weren’t,\r\nsales POVs, and others. Consider using network visibility tools or your existing EDR to scan for “live” IP\r\naddresses that do not show in your EDR reports. This has the added benefit of identifying unmanaged\r\ndevices that should have EDR but don’t.\r\nFigure 2: Asset inventory\r\nFile and Backup Scan for BRICKSTORM\r\nYARA rules have proven to be the most effective method for detecting BRICKSTORM binaries on appliances. We\r\nare sharing relevant YARA rules in the appendix section of this post. Yara can be difficult to run at scale, but some\r\nbackup solutions provide the ability to run YARA across the backup data store. Mandiant is aware of multiple\r\ncustomers who have identified BRICKSTORM through this method. \r\nTo aid organizations in hunting for BRICKSTORM activity in their environments, Mandiant released a scanner\r\nscript, which can run on appliances and other Linux or BSD-based systems. \r\nInternet Traffic from Edge Devices and Appliances\r\nUse the inventory of appliance management IP addresses to hunt for evidence of malware beaconing in network\r\nlogs. In general, appliances should not communicate with the public Internet from management IP addresses\r\nexcept to download updates and send crash analytics to the manufacturer. \r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 7 of 20\n\nEstablished outbound traffic to domains or IP addresses not controlled by the appliance manufacturer should be\r\nregarded as very suspicious and warranting forensic review of the appliance. BRICKSTORM can use DNS over\r\nHTTP (DoH), which should be similarly rare when sourced from appliance management IP addresses.\r\nAccess to Windows Systems from Appliances\r\nThe threat actor primarily accessed Windows machines (both desktops and servers) using type 3 (network) logins,\r\nalthough in some cases the actor also established RDP sessions. Appliances should rarely log in to Windows\r\ndesktops or servers and any connections should be treated as suspicious. Some examples of false positives could\r\ninclude VPN appliances using a known service account to connect to a domain controller in order to perform\r\nLDAP lookups and authenticated vulnerability scanners using a well-known service account. \r\nIn addition to EDR telemetry, Terminal Services logs and Security event logs, defenders should obtain and parse\r\nthe Windows User Access Log (UAL). The UAL is stored on Windows Servers inside the directory\r\nWindows\\System32\\LogFiles\\Sum and can be parsed using open-source tools such as SumECmd . This log source\r\nrecords attempted authenticated connections to Windows systems and often retains artifacts going back much\r\nlonger than typical Windows event logs. Note that this log source includes successful and unsuccessful logins, but\r\nis still useful to identify suspicious activity sourced from appliances.\r\nAccess to Credentials and Secrets\r\nUse the forensic capabilities of EDR tools to acquire Windows Shellbags artifacts from Windows workstations\r\nand servers. Shellbags records folder paths that are browsed by a user with the Windows Explorer application. Use\r\nan open-source parser to extract the relevant data and look for patterns of activity that are suspicious:\r\nAccess to folder paths where the initiating user is a service account, especially service accounts that are\r\nunfamiliar or rarely used\r\nFile browsing activity sourced from servers that include a Windows Universal Naming Convention (UNC)\r\npath that points to a workstation (e.g., \\\\bobwin7.corp.local\\browsing\\path)\r\nFile browsing activity to folder paths that contain credential data, such as:\r\nBrowser profile paths (e.g., %appdata%\\Mozilla\\Firefox\\Profiles )\r\nAppdata locations used to store session tokens (e.g., Users\\\u003cusername\u003e\\.azure\\ )\r\nWindows credential vault ( %appdatalocal%\\Microsoft\\Credentials )\r\nData Protection API (DPAPI) keys ( %appdata%\\Microsoft\\Protect\\\u003cSID\u003e\\ )\r\nAccess to M365 Mailboxes using Enterprise Application\r\nMandiant has observed this actor use common techniques to conduct bulk email access and exfiltration from\r\nMicrosoft 365 Exchange Online. Organizations should follow our guidance outlined in our APT29 whitepaper to\r\nhunt for these techniques. Although the white paper specifically references APT29, these techniques have become\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 8 of 20\n\nwidely used by many groups. In multiple investigations the threat actor used a Microsoft Entra ID Enterprise\r\nApplication with mail.read or full_access_as_app scopes to access mailboxes of key individuals in the\r\nvictim organization.\r\nTo hunt for this activity, we recommend a phased approach:\r\n1. Enumerate the Enterprise Applications and Application Registrations with graph permissions that can read\r\nall mail.\r\n2. For each application, validate that there is at least one secret or certificate configured for it. Record the\r\nApplication (client) ID\r\n3. Conduct a free text search against the Unified Audit Log or the OfficeActivity table in Sentinel for the\r\nclient IDs from step 2. This will return the mailitemsaccessed events that recorded the application\r\naccessing mail.\r\n4. For each application analyze the source IP addresses and user-agent strings for discrepancies. Legitimate\r\nusage of the applications should occur from well-defined IP addresses. Additionally, look for focused\r\ninterest in key personnel mailboxes across multiple days.\r\nWhen accessing M365 and other internet-facing services the actor has used multiple commercial VPN and proxy\r\nproviders. Mandiant has found evidence of the threat actor using PIA, NordVPN, Surfshark, VPN Unlimited, and\r\nPrivadoVPN, although there is no reason for these to be the only solutions used. There is also evidence to support\r\nthat this actor has access to a purpose-built obfuscation network built from compromised small office/home office\r\nrouters. Mandiant has no knowledge of how these routers are being compromised. The exit nodes for commercial\r\nVPNs and obfuscation networks change rapidly and sharing atomic indicators for hunting purposes is unlikely to\r\nyield results. Instead, identify the key individuals in the organization, with respect to the organization vertical and\r\nlikely goals of the threat actor. Fetch mailitemsaccessed logs for those mailboxes for the last year or as long as\r\nretention allows. Analyze the SessionID values of the log events and look for IDs that span multiple IP\r\naddresses where the IP addresses are not in the user’s typical geographic location.\r\nCloning of Sensitive Virtual Machines\r\nOn VMware vCenter servers, VPXD logs contain valuable information for VM management related tasks such as\r\nclone events, powering on and off a VM, and creating snapshots. The threat actor often used the\r\nVSPHERE.LOCAL\\Administrator account when cloning VMs and targeted VMs that would contain credentials\r\nsuch as password vaults and domain controllers. The threat actor would delete the cloned VM shortly after\r\ncloning, and primarily operated between the hours of 01:00 and 10:00 UTC. Investigators should search vCenter\r\nVPXD logs for activity that matches the aforementioned criteria and confirm if the cloning activity was intended\r\nor not.\r\nCreation of Local vCenter and ESXi Accounts\r\nMandiant identified evidence the threat actor created a new local account to install BRICKSTORM and then\r\nremoved the account after they were done. The following logs show the threat actor using the local Administrator\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 9 of 20\n\naccount to create a new local account and add it to the BashShellAdministrators group. The threat actor\r\nestablished an SSH connection from a compromised appliance to vCenter using the newly created account and\r\ninstalled the BRICKSTORM backdoor on vCenter. Shortly after, the threat actor deleted the account. Investigators\r\nshould review audit logs in /var/log/audit/sso-events/audit_events.log for the creation and deletion of local\r\naccounts and validate their purpose. In one instance, the threat actor named the account with a similar naming\r\nconvention as a local service account used for backups on vCenter.\r\n2025-04-01T06:45:32 {\"user\":\"Administrator@VSPHERE.LOCAL\",\"client\":\"\",\"timestamp\":\"04/01/2025 06:45:32 GMT\",\"de\r\n2025-04-01T06:45:55 {\"user\":\"Administrator@VSPHERE.LOCAL\",\"client\":\"\",\"timestamp\":\"04/01/2025 06:45:55 GMT\",\"des\r\n2025-04-01T06:46:23 {\"user\":\"Administrator@VSPHERE.LOCAL\",\"client\":\"\",\"timestamp\":\"04/01/2025 06:46:23 GMT\",\"des\r\n2025-04-01T06:52:03 \u003cvcenter_hostname\u003e sshd[36952]: Postponed keyboard-interactive/pam for \u003caccount_name\u003e@vspher\r\n2025-04-01T06:52:30 \u003cvcenter_hostname\u003e sudo: pam_unix(sudo:session): session opened for user root\r\n2025-04-01T06:53:39 Creation of BRICKSTORM on vCenter\r\n2025-04-01T06:56:18 \u003cvcenter_hostname\u003e sudo: pam_unix(sudo:session): session closed for user root\r\n2025-04-01T06:56:25 \u003cvcenter_hostname\u003e sshd[36952]: pam_unix(sshd:session): session closed for user \u003caccount_nam\r\n2025-04-01T06:56:57 {\"user\":\"Administrator@VSPHERE.LOCAL\",\"client\":\"\",\"timestamp\":\"04/01/2025 06:56:57 GMT\",\"des\r\n2025-04-01T06:58:12 {\"user\":\"Administrator@VSPHERE.LOCAL\",\"client\":\"\",\"timestamp\":\"04/01/2025 06:58:12 GMT\",\"des\r\nSSH Enablement on ESXi and vCenter\r\nFor ESXi servers, monitoring should be set up for SSH logins using local accounts. In most organizations it is\r\nrelatively rare for legitimate direct access to the ESXi hosts over SSH. In many cases the SSH server is disabled\r\nby default. Write rules to alert on log events when SSH is enabled for a vSphere platform appliance.\r\nRogue VMs\r\nOrganizations should review VMWare audit events that track the creation and deletion of new VMs, particularly\r\nusing non-standard ISO images and Operating Systems. Audit events may also record the threat actor\r\ndownloading archived ISO images to the datastore volumes used by vSphere. \r\nHardening Guidance\r\nIt is crucial to maintain an up-to-date inventory of appliances and other devices in the network that do not support\r\nthe standard security tool stack. Any device in that inventory, whether internal or internet-facing, should be\r\nconfigured to follow a principle of least access.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 10 of 20\n\nInternet access: Appliances should not have unrestricted access to the internet. Work with your vendors or\r\nmonitor your firewall logs to lock down internet access to only those domains or IP addresses that the\r\nappliance requires to function properly.\r\nInternal network access: Appliances exposed to the internet should not have unrestricted access to internal\r\nIP address space. The management interface of most appliances does not need to establish connections to\r\ninternal IP addresses. Work with the vendor to understand specific needsLDAP queries to verify user\r\nattributes for VPN logins.\r\nMandiant has previously published guidance to secure the vSphere platform from threat actors. We recommend\r\nyou follow the guidance, especially the forwarding of logs to a central SIEM, enabling vSphere lockdown mode,\r\nenforcing MFA for web logins, and enforcing the execInstalledOnly policy.\r\nOrganizations should assess and improve the isolation of any credential vaulting systems. In many cases if a threat\r\nactor is able to gain access to the underlying Operating System, any protected secrets can be exposed. Servers\r\nhosting credential vaulting applications should be considered Tier 0 systems and have strict access controls\r\napplied to them. Mandiant recommends organizations work with their vendors to adopt secure software practices\r\nsuch as storing encryption keys in the Trusted Platform Module (TPM) of the server.\r\nOutlook and Implications \r\nRecent intrusion operations tied to BRICKSTORM likely represent an array of objectives ranging from\r\ngeopolitical espionage, access operations, and intellectual property (IP) theft to enable exploit development. Based\r\non evidence from recent investigations the targeting of the US legal space is primarily to gather information\r\nrelated to US national security and international trade. Additionally, GTIG assesses with high confidence that the\r\nobjective of BRICKSTORM targeting SaaS providers is to gain access to downstream customer environments or\r\nthe data SaaS providers host on their customers' behalf. The targeting of technology companies presents an\r\nopportunity to conduct theft of valuable IP to further the development of zero-day exploits. \r\nAcknowledgements \r\nThis analysis would not have been possible without the assistance from across Google Threat Intelligence Group,\r\nMandiant Consulting and FLARE. We would like to specifically thank Nick Simonian from GTIG Research and\r\nDiscovery (RAD). We would also like to thank Ryan Tomcik from Mandiant Threat Defense (MTD) for\r\ncontributing network detection content. \r\nIndicators of Compromise\r\nThe following indicators of compromise are available in a Google Threat Intelligence (GTI) collection. Note that\r\nMandiant has not observed instances where the threat actor reused a malware sample and hunting for the exact\r\nindicators is unlikely to yield results.\r\nSHA-256 Hash File Name Description\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 11 of 20\n\n90b760ed1d0dcb3ef0f2b6d6195c9d852bcb65eca293578982a8c4b64f51b035 pg_update BRICKSTORM\r\n2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df spclisten BRICKSTORM\r\naa688682d44f0c6b0ed7f30b981a609100107f2d414a3a6e5808671b112d1878 vmp BRICKSTORM\r\nYARA Detections\r\nG_APT_Backdoor_BRICKSTORM_3\r\nrule G_APT_Backdoor_BRICKSTORM_3 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = { 48 8B 05 ?? ?? ?? ?? 48 89 04 24 E8 ?? ?? ?? ?? 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? 48 89\r\n$str2 = \"regex\" ascii wide nocase\r\n$str3 = \"mime\" ascii wide nocase\r\n$str4 = \"decompress\" ascii wide nocase\r\n$str5 = \"MIMEHeader\" ascii wide nocase\r\n$str6 = \"ResolveReference\" ascii wide nocase\r\n$str7 = \"1157920892103562487626974469494075735299969552241357603424222590610685120443691157920\r\ncondition:\r\nuint16(0) == 0x457F and all of them\r\n}\r\nG_Backdoor_BRICKSTORM_2\r\nrule G_Backdoor_BRICKSTORM_2 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$obf_func = /[a-z]{20}\\/[a-z]{20}\\/[a-z]{20}\\/[a-z]{20}.go/\r\n$decr1 = { 0F B6 4C 04 ?? 0F B6 54 04 ?? 31 D1 88 4C 04 ?? 48 FF C0 [0-4] 48 83 F8 ?? 7C }\r\n$decr2 = { 40 88 7C 34 34 48 FF C3 48 FF C6 48 39 D6 7D 18 0F B6 3B 48 39 CE 73 63 44 0F B6 04\r\n$decr3 = { 0F B6 54 0C ?? 0F B6 5C 0C ?? 31 DA 88 14 08 48 FF C1 48 83 F9 ?? 7C E8 }\r\n$str1 = \"main.selfWatcher\"\r\n$str2 = \"main.copyFile\"\r\n$str3 = \"main.startNew\"\r\n$str4 = \"WRITE_LOG=true\"\r\n$str5 = \"WRITE_LOGWednesday\"\r\n$str6 = \"vami-httpdvideo/webm\"\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 12 of 20\n\n$str7 = \"/opt/vmware/sbin/\"\r\n$str8 = \"/home/vsphere-ui/\"\r\n$str9 = \"/opt/vmware/sbin/vami-http\"\r\n$str10 = \"main.getVFromEnv\"\r\ncondition:\r\nuint32(0) == 0x464c457f and ((any of ($decr*) and $obf_func) or (any of ($decr*) and any of ($\r\n}\r\nG_APT_Backdoor_BRICKSTORM_1\r\nrule G_APT_Backdoor_BRICKSTORM_1 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$ = \"WRITE_LOGWednesday\"\r\n$ = \"/home/vsphere-ui/\"\r\n$ = \"WRITE_LOG=true\"\r\n$ = \"dns rcode: %v\"\r\n$ = \"dns query not specified or too small\"\r\n$ = \"/dev/pts: bad file descriptor\"\r\n$ = \"/libs/doh.Query\"\r\n$ = \"/libs/doh.createDnsMessage\"\r\n$ = \"/libs/doh.unpackDnsMessage\"\r\n$ = \"/core/protocol/websocket.(*WebSocketNetConfig).Dial\"\r\n$ = \"/core/protocol/websocket.(*connection).Read\"\r\n$ = \"/core/protocol/websocket.(*connection).getReader\"\r\n$ = \"/core/protocol/websocket.(*connection).Write\"\r\n$ = \"/core/protocol/websocket.(*connection).Close\"\r\n$ = \"/core/protocol/websocket.(*connection).LocalAddr\"\r\n$ = \"/core/protocol/websocket.(*connection).RemoteAddr\"\r\n$ = \"/core/protocol/websocket.(*connection).SetDeadline\"\r\n$ = \"/core/protocol/websocket.(*connection).SetReadDeadline\"\r\n$ = \"/core/protocol/websocket.(*connection).SetWriteDeadline\"\r\n$ = \"/core/protocol.UnPackHeaderData\"\r\n$ = \"/core/protocol.NewWebSocketClient\"\r\n$ = \"/libs/func1.(*Client).BackgroundRun\"\r\n$ = \"/libs/func1.CreateClient\"\r\n$ = \"/libs/func1.NewService\"\r\n$ = \"/libs/func1.(*Service).Get\"\r\n$ = \"/libs/func1.(*Service).DoTask\"\r\n$ = \"/libs/func1.(*Service).Put\"\r\n$ = \"/core/extends/command.Command\"\r\n$ = \"/core/extends/command.CommandNoContext\"\r\n$ = \"/core/extends/command.ExecuteCmd\"\r\n$ = \"/core/extends/command.RunShell\"\r\n$ = \"/core/extends/socks.UnPackHeaderData\"\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 13 of 20\n\n$ = \"/core/extends/socks.handleRelay\"\r\n$ = \"/libs/fs.(*RemoteDriver).realPath\"\r\n$ = \"/libs/fs.(*RemoteDriver).ChangeDir\"\r\n$ = \"/libs/fs.(*RemoteDriver).Stat\"\r\n$ = \"/libs/fs.(*SimplePerm).GetMode\"\r\n$ = \"/libs/fs.(*SimplePerm).GetOwner\"\r\n$ = \"/libs/fs.(*SimplePerm).GetGroup\"\r\n$ = \"/libs/fs.(*RemoteDriver).ListDir\"\r\n$ = \"/libs/fs.(*RemoteDriver).DeleteDir\"\r\n$ = \"/libs/fs.(*RemoteDriver).DeleteFile\"\r\n$ = \"/libs/fs.(*RemoteDriver).Rename\"\r\n$ = \"/libs/fs.(*RemoteDriver).MakeDir\"\r\n$ = \"/libs/fs.(*RemoteDriver).GetFile\"\r\n$ = \"/libs/fs.(*RemoteDriver).PutFile\"\r\n$ = \"/libs/fs.(*RemoteDriver).UpFile\"\r\n$ = \"/libs/fs.(*RemoteDriver).MD5\"\r\n$ = \"/libs/doh/doh.go\"\r\n$ = \"/core/protocol/websocket/config.go\"\r\n$ = \"/core/extends/command/command.go\"\r\n$ = \"/libs/fs/driver_unix.go\"\r\n$ = \"/libs/fs/perm_linux.go\"\r\ncondition:\r\nuint32(0) == 0x464c457f and 8 of them\r\n}\r\nG_APT_Backdoor_BRICKSTORM_2\r\nrule G_APT_Backdoor_BRICKSTORM_2 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = { 0F 57 C0 0F 11 84 ?? ?? ?? ?? ?? C6 44 ?? ?? 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00\r\n$str2 = { 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ??\r\ncondition:\r\nuint32be(0) == 0x7F454C46 and any of them\r\n}\r\nG_APT_BackdoorWebshell_SLAYSTYLE_1\r\nrule G_APT_BackdoorWebshell_SLAYSTYLE_1 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = /String \\w{1,10}=request\\.getParameter\\(\\\"\\w{1,15}\\\"\\);/ ascii wide nocase\r\n$str2 = \"=new String(java.util.Base64.getDecoder().decode(\" ascii wide nocase\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 14 of 20\n\n$str21 = /String\\[\\]\\s\\w{1,10}=\\{\\\"\\/bin\\/sh\\\",\\\"-c\\\",\\w{1,10}\\+\\\"\\s2\u003e\u00261\\\"\\};/ ascii wide noca\r\n$str3 = \"= Runtime.getRuntime().exec(\" ascii wide nocase\r\n$str4 = \"java.io.InputStream\" ascii wide nocase\r\n$str5 = \"java.util.Base64.getEncoder().encodeToString(org.apache.commons.io.IOUtils.toByteArra\r\ncondition:\r\nfilesize \u003c 5MB and all of them\r\n}\r\nG_APT_BackdoorWebshell_SLAYSTYLE_2\r\nrule G_APT_BackdoorWebshell_SLAYSTYLE_2 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = \"request.getParameter\" nocase\r\n$str2 = \"/bin/sh\"\r\n$str3 = \"java.io.InputStream\" nocase\r\n$str4 = \"Runtime.getRuntime().exec(\" nocase\r\n$str5 = \"2\u003e\u00261\"\r\ncondition:\r\n(uint16(0) != 0x5A4D and uint32(0) != 0x464C457F) and filesize \u003c 7KB and all of them and @str4\r\n}\r\nG_Backdoor_BRICKSTEAL_1\r\nrule G_Backdoor_BRICKSTEAL_1 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = \"comvmware\"\r\n$str2 = \"abcdABCD1234!@#$\"\r\n$str3 = \"ads.png\"\r\n$str4 = \"User-Agent\"\r\n$str5 = \"com/vmware/\"\r\ncondition:\r\nall of them and filesize \u003c 10KB\r\n}\r\nG_Dropper_BRICKSTEAL_1\r\nrule G_Dropper_BRICKSTEAL_1 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 15 of 20\n\n$str1 = \"Base64.getDecoder().decode\"\r\n$str2 = \"Thread.currentThread().getContextClassLoader()\"\r\n$str3 = \".class.getDeclaredMethod\"\r\n$str4 = \"byte[].class\"\r\n$str5 = \"method.invoke\"\r\n$str6 = \"filterClass.newInstance()\"\r\n$str7 = \"/websso/SAML2/SSO/*\"\r\ncondition:\r\nall of them\r\n}\r\nG_Dropper_BRICKSTEAL_2\r\nrule G_Dropper_BRICKSTEAL_2 {\r\nmeta:\r\nauthor = \"Google Threat Intelligence Group (GTIG)\"\r\nstrings:\r\n$str1 = /\\(Class\u003c\\?\u003e\\)\\smethod\\.invoke\\(\\w{1,20},\\s\\w{1,20},\\s0,\\s\\w{1,20}\\.length\\);/i ascii\r\n$str2 = \"(\\\"yv66vg\" ascii wide\r\n$str3 = \"request.getSession().getServletContext\" ascii wide\r\n$str4 = \".getClass().getDeclaredField(\" ascii wide\r\n$str5 = \"new FilterDef();\" ascii wide\r\n$str6 = \"new FilterMap();\" ascii wide\r\ncondition:\r\nall of them\r\n}\r\nNetwork Detections\r\nGoogle SecOps customers have access to these broad category rules and more under the Mandiant Front-Line\r\nThreats rule pack. The following are YARA-L 2.0 rules for use in Google Security Operations; however, their\r\nlogic can be replicated into other formats for use in other security products.\r\nMultiple DNS-over-HTTPS Services Queried\r\nrule hunting_t1071_001_multiple_dns_over_https_services_queried {\r\n meta:\r\n rule_name = \"Multiple DNS-over-HTTPS Services Queried\"\r\n severity = \"Low\"\r\n tactic = \"TA0011\" // Command and Control\r\n technique = \"T1071.001\" // Application Layer Protocol: Web Protocols\r\n reference = \"https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\"\r\n description = \"Detects on requests by a source IP address to DNS-over-HTTPS (DoH) resolver IP addresses asso\r\n events:\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 16 of 20\n\n$e.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $e.target.ip = /^(8\\.8\\.8\\.8|8\\.8\\.4\\.4|9\\.9\\.9\\.9|9\\.9\\.9\\.11|1\\.1\\.1\\.1|1\\.0\\.0\\.1|45\\.90\\.28\\.160|45\\.90\\\r\n (\r\n $e.target.port = 443 or\r\n $e.target.url = /dns-query|:443\\/$|\\d\\.\\d\\.\\d\\.\\d\\/$/ nocase\r\n )\r\n $source_entity = strings.coalesce($e.principal.asset_id,$e.principal.ip)\r\n match:\r\n $source_entity over 2h\r\n outcome:\r\n $risk_score = max(35)\r\n $unique_doh_ips_count = count_distinct($e.target.ip)\r\n condition:\r\n $e and $unique_doh_ips_count \u003e= 5\r\n options:\r\n allow_zero_values = true\r\n}\r\nUnknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services\r\nCommunication\r\nrule hunting_t1071_001_unknown_endpoint_generating_doh_and_web_development_services_communication {\r\n meta:\r\n rule_name = \"Unknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services Communicati\r\n severity = \"Medium\"\r\n tactic = \"TA0011\" // Command and Control\r\n technique = \"T1071.001\" // Application Layer Protocol: Web Protocols\r\n reference = \"https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\"\r\n description = \"Detects on requests by an unknown source IP address to multiple DNS-over-HTTPS (DoH) resolver\r\n events:\r\n $c1.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c1.target.ip = /^(8\\.8\\.8\\.8|8\\.8\\.4\\.4|9\\.9\\.9\\.9|9\\.9\\.9\\.11|1\\.1\\.1\\.1|1\\.0\\.0\\.1|45\\.90\\.28\\.160|45\\.90\r\n $c1.principal.hostname = \"\"\r\n $c1.principal.asset_id = \"\"\r\n (\r\n $c1.target.port = 443 or\r\n $c1.target.url = /dns-query|:443\\/$|\\d\\.\\d\\.\\d\\.\\d\\/$/ nocase\r\n )\r\n $c2.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c2.target.hostname = /\\.workers\\.dev$|\\.herokuapp\\.com$/ nocase\r\n $c2.principal.hostname = \"\"\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 17 of 20\n\n$c2.principal.asset_id = \"\"\r\n $c2.target.port = 443\r\n $source_entity = $c1.principal.ip\r\n $source_entity = $c2.principal.ip\r\n match:\r\n $source_entity over 24h\r\n outcome:\r\n $risk_score = max(65)\r\n $unique_doh_ips_count = count_distinct($c1.target.ip)\r\n condition:\r\n $c1 and $c2 and $unique_doh_ips_count \u003e= 3\r\n options:\r\n allow_zero_values = true\r\n}\r\nUnknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication\r\nrule hunting_t1071_001_unknown_endpoint_generating_google_doh_and_cloudflare_communication {\r\n meta:\r\n rule_name = \"Unknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication\"\r\n severity = \"Medium\"\r\n tactic = \"TA0011\" // Command and Control\r\n technique = \"T1071.001\" // Application Layer Protocol: Web Protocols\r\n reference = \"https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\"\r\n description = \"Detects on requests by an unknown source IP address to Google DNS-over-HTTPS (DoH) resolver s\r\n events:\r\n $c1.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c1.target.ip = /^(8\\.8\\.8\\.8|8\\.8\\.4\\.4)$/ nocase\r\n $c1.principal.hostname = \"\"\r\n $c1.principal.asset_id = \"\"\r\n (\r\n $c1.target.port = 443 or\r\n $c1.target.url = /dns-query|:443\\/$|\\d\\.\\d\\.\\d\\.\\d\\/$/ nocase\r\n )\r\n $c2.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c2.principal.hostname = \"\"\r\n $c2.principal.asset_id = \"\"\r\n $c2.target.ip_geo_artifact.network.carrier_name = /cloudflare/ nocase\r\n $c2.target.port = 443\r\n $source_entity = $c1.principal.ip\r\n $source_entity = $c2.principal.ip\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 18 of 20\n\nmatch:\r\n $source_entity over 1h\r\n outcome:\r\n $risk_score = max(65)\r\n $time_diff = math.abs(min($c1.metadata.event_timestamp.seconds) - min($c2.metadata.event_timestamp.seconds))\r\n condition:\r\n $c1 and $c2 and $time_diff \u003c= 2\r\n options:\r\n allow_zero_values = true\r\n}\r\nUnknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication\r\nrule hunting_t1071_001_unknown_endpoint_generating_google_doh_and_amazon_communication {\r\n meta:\r\n rule_name = \"Unknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication\"\r\n severity = \"Medium\"\r\n tactic = \"TA0011\" // Command and Control\r\n technique = \"T1071.001\" // Application Layer Protocol: Web Protocols\r\n reference = \"https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\"\r\n description = \"Detects on requests by an unknown source IP address to Google DNS-over-HTTPS (DoH) resolver s\r\n events:\r\n $c1.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c1.target.ip = /^(8\\.8\\.8\\.8|8\\.8\\.4\\.4)$/ nocase\r\n $c1.principal.hostname = \"\"\r\n $c1.principal.asset_id = \"\"\r\n (\r\n $c1.target.port = 443 or\r\n $c1.target.url = /dns-query|:443\\/$|\\d\\.\\d\\.\\d\\.\\d\\/$/ nocase\r\n )\r\n $c2.metadata.event_type = \"NETWORK_CONNECTION\"\r\n $c2.principal.hostname = \"\"\r\n $c2.principal.asset_id = \"\"\r\n $c2.target.ip_geo_artifact.network.carrier_name = /amazon/ nocase\r\n $c2.target.port = 443\r\n $source_entity = $c1.principal.ip\r\n $source_entity = $c2.principal.ip\r\n match:\r\n $source_entity over 24h\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 19 of 20\n\noutcome:\r\n $risk_score = max(65)\r\n $time_diff = math.abs(min($c1.metadata.event_timestamp.seconds) - min($c2.metadata.event_timestamp.seconds))\r\n condition:\r\n // As observed by Mandiant IR, the two connection events to DoH and Amazon occurred nearly simultaneously\r\n $c1 and $c2 and $time_diff \u003c= 2\r\n options:\r\n allow_zero_values = true\r\n}\r\nPosted in\r\nThreat Intelligence\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign"
	],
	"report_names": [
		"brickstorm-espionage-campaign"
	],
	"threat_actors": [
		{
			"id": "b2e48aa5-0dea-4145-a7e5-9a0f39d786d8",
			"created_at": "2024-01-18T02:02:34.643994Z",
			"updated_at": "2026-04-10T02:00:04.959645Z",
			"deleted_at": null,
			"main_name": "UNC5221",
			"aliases": [
				"UNC5221",
				"UTA0178"
			],
			"source_name": "ETDA:UNC5221",
			"tools": [
				"BRICKSTORM",
				"GIFTEDVISITOR",
				"GLASSTOKEN",
				"LIGHTWIRE",
				"PySoxy",
				"THINSPOOL",
				"WARPWIRE",
				"WIREFIRE",
				"ZIPLINE"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "6ce34ba9-7321-4caa-87be-36fa99dfe9c9",
			"created_at": "2024-01-12T02:00:04.33082Z",
			"updated_at": "2026-04-10T02:00:03.517264Z",
			"deleted_at": null,
			"main_name": "UTA0178",
			"aliases": [
				"UNC5221",
				"Red Dev 61"
			],
			"source_name": "MISPGALAXY:UTA0178",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "7c969685-459b-4c93-a788-74108eab6f47",
			"created_at": "2023-01-06T13:46:39.189751Z",
			"updated_at": "2026-04-10T02:00:03.241102Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"Red Dev 13",
				"Silk Typhoon",
				"MURKY PANDA",
				"ATK233",
				"G0125",
				"Operation Exchange Marauder"
			],
			"source_name": "MISPGALAXY:HAFNIUM",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e",
			"created_at": "2024-06-04T02:03:07.956135Z",
			"updated_at": "2026-04-10T02:00:03.689959Z",
			"deleted_at": null,
			"main_name": "IRON HEMLOCK",
			"aliases": [
				"APT29 ",
				"ATK7 ",
				"Blue Kitsune ",
				"Cozy Bear ",
				"The Dukes",
				"UNC2452 ",
				"YTTRIUM "
			],
			"source_name": "Secureworks:IRON HEMLOCK",
			"tools": [
				"CosmicDuke",
				"CozyCar",
				"CozyDuke",
				"DiefenDuke",
				"FatDuke",
				"HAMMERTOSS",
				"LiteDuke",
				"MiniDuke",
				"OnionDuke",
				"PolyglotDuke",
				"RegDuke",
				"RegDuke Loader",
				"SeaDuke",
				"Sliver"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "2704d770-43b4-4bc4-8a5a-05df87416848",
			"created_at": "2022-10-25T15:50:23.306305Z",
			"updated_at": "2026-04-10T02:00:05.296581Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"HAFNIUM",
				"Operation Exchange Marauder",
				"Silk Typhoon"
			],
			"source_name": "MITRE:HAFNIUM",
			"tools": [
				"Tarrask",
				"ASPXSpy",
				"Impacket",
				"PsExec",
				"China Chopper"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "a241a1ca-2bc9-450b-a07b-aae747ee2710",
			"created_at": "2024-06-19T02:03:08.150052Z",
			"updated_at": "2026-04-10T02:00:03.737173Z",
			"deleted_at": null,
			"main_name": "IRON RITUAL",
			"aliases": [
				"APT29",
				"Blue Dev 5 ",
				"BlueBravo ",
				"Cloaked Ursa ",
				"CozyLarch ",
				"Dark Halo ",
				"Midnight Blizzard ",
				"NOBELIUM ",
				"StellarParticle ",
				"UNC2452 "
			],
			"source_name": "Secureworks:IRON RITUAL",
			"tools": [
				"Brute Ratel C4",
				"Cobalt Strike",
				"EnvyScout",
				"GoldFinder",
				"GoldMax",
				"NativeZone",
				"RAINDROP",
				"SUNBURST",
				"Sibot",
				"TEARDROP",
				"VaporRage"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb",
			"created_at": "2023-01-06T13:46:38.393409Z",
			"updated_at": "2026-04-10T02:00:02.955738Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"Cloaked Ursa",
				"TA421",
				"Blue Kitsune",
				"BlueBravo",
				"IRON HEMLOCK",
				"G0016",
				"Nobelium",
				"Group 100",
				"YTTRIUM",
				"Grizzly Steppe",
				"ATK7",
				"ITG11",
				"COZY BEAR",
				"The Dukes",
				"Minidionis",
				"UAC-0029",
				"SeaDuke"
			],
			"source_name": "MISPGALAXY:APT29",
			"tools": [
				"SNOWYAMBER",
				"HALFRIG",
				"QUARTERRIG"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "529c1ae9-4579-4245-86a6-20f4563a695d",
			"created_at": "2022-10-25T16:07:23.702006Z",
			"updated_at": "2026-04-10T02:00:04.71708Z",
			"deleted_at": null,
			"main_name": "Hafnium",
			"aliases": [
				"G0125",
				"Murky Panda",
				"Red Dev 13",
				"Silk Typhoon"
			],
			"source_name": "ETDA:Hafnium",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a",
			"created_at": "2022-10-25T15:50:23.548494Z",
			"updated_at": "2026-04-10T02:00:05.292748Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"APT29",
				"IRON RITUAL",
				"IRON HEMLOCK",
				"NobleBaron",
				"Dark Halo",
				"NOBELIUM",
				"UNC2452",
				"YTTRIUM",
				"The Dukes",
				"Cozy Bear",
				"CozyDuke",
				"SolarStorm",
				"Blue Kitsune",
				"UNC3524",
				"Midnight Blizzard"
			],
			"source_name": "MITRE:APT29",
			"tools": [
				"PinchDuke",
				"ROADTools",
				"WellMail",
				"CozyCar",
				"Mimikatz",
				"Tasklist",
				"OnionDuke",
				"FatDuke",
				"POSHSPY",
				"EnvyScout",
				"SoreFang",
				"GeminiDuke",
				"reGeorg",
				"GoldMax",
				"FoggyWeb",
				"SDelete",
				"PolyglotDuke",
				"AADInternals",
				"MiniDuke",
				"SeaDuke",
				"Sibot",
				"RegDuke",
				"CloudDuke",
				"GoldFinder",
				"AdFind",
				"PsExec",
				"NativeZone",
				"Systeminfo",
				"ipconfig",
				"Impacket",
				"Cobalt Strike",
				"PowerDuke",
				"QUIETEXIT",
				"HAMMERTOSS",
				"BoomBox",
				"CosmicDuke",
				"WellMess",
				"VaporRage",
				"LiteDuke"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434074,
	"ts_updated_at": 1775792237,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/59b4660c9819d21d97621fadcac9e93be556164c.pdf",
		"text": "https://archive.orkl.eu/59b4660c9819d21d97621fadcac9e93be556164c.txt",
		"img": "https://archive.orkl.eu/59b4660c9819d21d97621fadcac9e93be556164c.jpg"
	}
}