Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors

File and Backup Scan for BRICKSTORM

YARA rules have proven to be the most effective method for detecting BRICKSTORM binaries on appliances. We are sharing relevant YARA rules in the appendix section of this post. Yara can be difficult to run at scale, but some backup solutions provide the ability to run YARA across the backup data store. Mandiant is aware of multiple customers who have identified BRICKSTORM through this method. 

To aid organizations in hunting for BRICKSTORM activity in their environments, Mandiant released a scanner script, which can run on appliances and other Linux or BSD-based systems. 

Internet Traffic from Edge Devices and Appliances

Use the inventory of appliance management IP addresses to hunt for evidence of malware beaconing in network logs. In general, appliances should not communicate with the public Internet from management IP addresses except to download updates and send crash analytics to the manufacturer. 

Established outbound traffic to domains or IP addresses not controlled by the appliance manufacturer should be regarded as very suspicious and warranting forensic review of the appliance. BRICKSTORM can use DNS over HTTP (DoH), which should be similarly rare when sourced from appliance management IP addresses.

Access to Windows Systems from Appliances

The threat actor primarily accessed Windows machines (both desktops and servers) using type 3 (network) logins, although in some cases the actor also established RDP sessions. Appliances should rarely log in to Windows desktops or servers and any connections should be treated as suspicious. Some examples of false positives could include VPN appliances using a known service account to connect to a domain controller in order to perform LDAP lookups and authenticated vulnerability scanners using a well-known service account. 

In addition to EDR telemetry, Terminal Services logs and Security event logs, defenders should obtain and parse the Windows User Access Log (UAL). The UAL is stored on Windows Servers inside the directory Windows\System32\LogFiles\Sum and can be parsed using open-source tools such as SumECmd. This log source records attempted authenticated connections to Windows systems and often retains artifacts going back much longer than typical Windows event logs. Note that this log source includes successful and unsuccessful logins, but is still useful to identify suspicious activity sourced from appliances.

Access to Credentials and Secrets

Use the forensic capabilities of EDR tools to acquire Windows Shellbags artifacts from Windows workstations and servers. Shellbags records folder paths that are browsed by a user with the Windows Explorer application. Use an open-source parser to extract the relevant data and look for patterns of activity that are suspicious:

• Access to folder paths where the initiating user is a service account, especially service accounts that are unfamiliar or rarely used

• File browsing activity sourced from servers that include a Windows Universal Naming Convention (UNC) path that points to a workstation (e.g., \\bobwin7.corp.local\browsing\path)

• File browsing activity to folder paths that contain credential data, such as:

• Browser profile paths (e.g., %appdata%\Mozilla\Firefox\Profiles)

• Appdata locations used to store session tokens (e.g., Users\\.azure\)

• Windows credential vault (%appdatalocal%\Microsoft\Credentials)

• Data Protection API (DPAPI) keys (%appdata%\Microsoft\Protect\\)

Access to M365 Mailboxes using Enterprise Application

Mandiant has observed this actor use common techniques to conduct bulk email access and exfiltration from Microsoft 365 Exchange Online. Organizations should follow our guidance outlined in our APT29 whitepaper to hunt for these techniques. Although the white paper specifically references APT29, these techniques have become widely used by many groups. In multiple investigations the threat actor used a Microsoft Entra ID Enterprise Application with mail.read or full_access_as_app scopes to access mailboxes of key individuals in the victim organization.

To hunt for this activity, we recommend a phased approach:

1. Enumerate the Enterprise Applications and Application Registrations with graph permissions that can read all mail.

2. For each application, validate that there is at least one secret or certificate configured for it. Record the Application (client) ID

3. Conduct a free text search against the Unified Audit Log or the OfficeActivity table in Sentinel for the client IDs from step 2. This will return the mailitemsaccessed events that recorded the application accessing mail.

4. For each application analyze the source IP addresses and user-agent strings for discrepancies. Legitimate usage of the applications should occur from well-defined IP addresses. Additionally, look for focused interest in key personnel mailboxes across multiple days.

When accessing M365 and other internet-facing services the actor has used multiple commercial VPN and proxy providers. Mandiant has found evidence of the threat actor using PIA, NordVPN, Surfshark, VPN Unlimited, and PrivadoVPN, although there is no reason for these to be the only solutions used. There is also evidence to support that this actor has access to a purpose-built obfuscation network built from compromised small office/home office routers. Mandiant has no knowledge of how these routers are being compromised. The exit nodes for commercial VPNs and obfuscation networks change rapidly and sharing atomic indicators for hunting purposes is unlikely to yield results. Instead, identify the key individuals in the organization, with respect to the organization vertical and likely goals of the threat actor. Fetch mailitemsaccessed logs for those mailboxes for the last year or as long as retention allows. Analyze the SessionID values of the log events and look for IDs that span multiple IP addresses where the IP addresses are not in the user’s typical geographic location.

Cloning of Sensitive Virtual Machines

On VMware vCenter servers, VPXD logs contain valuable information for VM management related tasks such as clone events, powering on and off a VM, and creating snapshots. The threat actor often used the VSPHERE.LOCAL\Administrator account when cloning VMs and targeted VMs that would contain credentials such as password vaults and domain controllers. The threat actor would delete the cloned VM shortly after cloning, and primarily operated between the hours of 01:00 and 10:00 UTC. Investigators should search vCenter VPXD logs for activity that matches the aforementioned criteria and confirm if the cloning activity was intended or not.

Creation of Local vCenter and ESXi Accounts

Mandiant identified evidence the threat actor created a new local account to install BRICKSTORM and then removed the account after they were done. The following logs show the threat actor using the local Administrator account to create a new local account and add it to the BashShellAdministrators group. The threat actor established an SSH connection from a compromised appliance to vCenter using the newly created account and installed the BRICKSTORM backdoor on vCenter. Shortly after, the threat actor deleted the account. Investigators should review audit logs in /var/log/audit/sso-events/audit_events.log for the creation and deletion of local accounts and validate their purpose. In one instance, the threat actor named the account with a similar naming convention as a local service account used for backups on vCenter.