BRONZE SANDCASTLE deploys modified Meterpreter shells

Counter Threat Unit™ (CTU) and SophosLabs researchers investigated a cluster of incidents attributed to the BRONZE SANDCASTLE threat group. The most distinctive technical marker for BRONZE SANDCASTLE is its consistent use of Sandboxie DLL sideloading.

DLL sideloading details

Across multiple victims’ environments, legitimate Sandboxie executables were placed alongside a malicious sbiedll.dll file, causing the trusted application to load attacker-controlled code at runtime. This consistent pattern functions as a signature for the group, although the threat actors employ several other sideloading file combinations as well (see Table 1).

Table 1: DLL sideloading files used by BRONZE SANDCASTLE

The sideloaded DLLs typically read and execute payloads stored in encrypted config.ini files. This design minimizes static detection and allows operators to adjust behavior without replacing DLL binaries. Renamed legitimate executables are frequently used to blend into victims’ environments, with execution resulting in in-memory shellcode activity rather than additional disk artifacts. Figure 1 shows the components of a sample ZIP archive (aez.zip) on a compromised system: the clean loader (javaw.exe), the sideloaded DLL (jli.dll), and the file containing the encrypted payload (config.ini).

Figure 1: Sample DLL sideloading components deployed in a ZIP archive on a compromised system

The malicious DLL code implements a flattened control-flow dispatcher that obscures program logic by using a virtualized state machine instead of direct branches (see Figure 2).

Figure 2: Core sequence of the DLL’s code obfuscation

A state value indexes a per-state table, and a value from the table is passed through a custom bit-mixing routine using byte swapping, variable rotations, inversion, and negation. The result is used as an index into a jump table of code pointers, and execution continues via an indirect jump. Some indices intentionally resolve to fall-through locations, further complicating static analysis and obscuring the program’s true control flow.

Payload

The decrypted payload is a backdoor program. Once loaded and decoded by the DLL, config.ini superficially resembles a Windows executable in memory (see Figure 3).

Figure 3: Decoded config.ini file in memory

The file header is a position‑independent PE loader and execution stub, often referred to as a reflective loader. The payload exhibits structural similarities to stageless shellcode payloads such as those generated by the Metasploit Framework (MSF), including position-independent execution, manual PE validation, and in-memory loading of an embedded executable. However, several implementation details indicate that this loader is not a standard Metasploit artifact. In particular, the API resolution logic uses non-standard hashing and transformation routines rather than the well-known ROR13 algorithm used by Metasploit, and the codebase is significantly larger and more complex than typical MSF shellcode.

The analyzed samples also contain elements of the well-known COFFLoader project (see Figure 4). The use of standard APIs from this project suggests that the malware author employed a custom Beacon Object File (BOF) to create their own post-exploitation features.

Figure 4: COFFLoader elements observed in compromised systems’ memory

Additional in-memory strings associated with C++ function decorators demonstrate the data-stealing capabilities that BRONZE SANDCASTLE builds into its payload (see Figure 5).

Figure 5: In-memory strings from BRONZE SANDCASTLE's payload

Sophos analysts identified two versions of the payload: 1.1.5 and 1.1.7. Once running, the payload sends a structured JSON object with nested “info” block to its command and control (C2) server (see Figure 6). The following information is included in that block:

• Host identifiers: hostname, username, GUID, domain
• OS version (e.g.,10.0.19042)
• Internal IP address
• Public IP address
• Process listing and metadata (PID, process name, execution method)
• Working directory
• Code page
• CPU architecture
• Implant start time
• Implant type (server/client)

Figure 6: Formatted JSON info block in version 1.1.7

CTU™ researchers observed instances of the payload reaching out to legitimate websites such as file[.]io, gofile[.]io, ably[.]net, and ably[.]io, possibly to receive C2 tasking from the operators. Version 1.1.5 contacted C2 servers dc[.]cathaypacifice[.]com and net[.]dpworldto[.]com. Version 1.1.7 payloads have also been observed communicating with github[.]com repositories to download encrypted config files (see Figure 7).

Figure 7: Payload attempting to download a config file from GitHub

The GitHub repository (hxxps://api[.]github[.]com/repos/LatonyCharnleyaW) has little history, with only a few submissions (see Figure 8).

Figure 8: Overview page of LatonyCharnleyaW GitHub repo

The repository contained multiple files. Analysis suggested that the following files were likely encrypted config files: main.3ku8inqb.js.map, main.lhxjkkai.js.map, main.y8hnze7q.js.map, and README.md. There were also encrypted files with a .ts extension (see Figure 9) that may be implants used by the backdoor.

Figure 9: List of .ts files in the GitHub repository

After a payload is installed in a target environment, the threat actors use it to conduct common survey tasks such as executing Windows “net” commands to enumerate the local network and user accounts. The threat actors have also created Volume Shadow copies via vssadmin.exe prior to copying the Windows ntds.dit file. This Windows file is the central database file of Active Directory that contains user credentials, group policies, security settings, and domain configurations.

Victimology and links to China

CTU researchers have observed BRONZE SANDCASTLE targeting organizations in Asia and Africa, which is typical of several China-based threat groups, including BRONZE PRESIDENT and BRONZE ATLAS. Although the geographic targeting overlaps with that of these groups, the observed activity could not be reliably linked to either group and exhibited distinctive technical characteristics. CTU researchers consequently created the separate BRONZE SANDCASTLE designation to represent the group behind this activity.

CTU analysis of incidents between August 2025 and August 2026 revealed victims in the Philippines, Taiwan, Afghanistan, Namibia, and likely also the Republic of Korea (see Figure 10).

Figure 10: Distribution of BRONZE SANDCASTLE victims in incidents between August 2025 and August 2026

Observations that the threat actors are most active in UTC+8 time (see Figure 11) reinforces attribution to a China-based threat group. The active hours align with the 996 working hour system that is particularly popular in China’s tech sector.

Figure 11: Heatmap of BRONZE SANDCASTLE activity by hour of the day

The details of the observed loaders and the novel Meterpreter-based payload appear to be specific to BRONZE SANDCASTLE.

Recommendations

Organizations at risk of targeting by China’s intelligence-gathering operations should familiarize themselves with BRONZE SANDCASTLE’s tactics, techniques, and procedures (TTPs). The threat group predominantly uses encrypted payload and configuration files that are decoded at runtime, meaning that static file-based detections may be ineffective. Organizations should instead focus on behavioral indicators such as DLLs reading local files followed by immediate in-memory execution, which may indicate decoding and staging activity. Endpoint telemetry and memory-based detection are essential. Security teams should enable monitoring for reflective loading patterns, anomalous PE headers in memory, and processes exhibiting characteristics of position-independent shellcode execution.

Countermeasures and indicators

The following Sophos countermeasures relate to this threat:

• ATK/Swrort-Y
• ATK/ScLoad-W
• ATK/ScLoad-X
• ATK/ScLoad-Y
• ATK/ScLoad-Z
• Troj/Loader-JL
• Troj/Loader-JP

Due to the large number of threat indicators, the full list is available in the SophosLabs GitHub repository.

Acknowledgements

Thanks to Colin Cowie, Jordon Olness, and Morgan Demboski for their analysis and insight into this activity.