Security News

BRONZE SANDCASTLE: Sandboxie DLL Sideloading Chain and Detection Checks

Sophos CTU names BRONZE SANDCASTLE, a China-based group that sideloads Sandboxie DLLs. Read the infection chain, nine file pairs and a defender checklist.

6 Min Read

Sophos Counter Threat Unit (CTU) has named a new China-based threat group, BRONZE SANDCASTLE. Its most recognisable habit is placing a rogue sbiedll.dll next to a genuine Sandboxie program, so the trusted program loads the attacker’s code. Sophos analysed incidents from August 2025 to August 2026. This post puts the chain, the targets and the checks a defender can run in one place.

BRONZE SANDCASTLE at a glance
Named by
Sophos Counter Threat Unit (CTU), with SophosLabs
Assessed origin
China-based, per Sophos
Incidents analysed
August 2025 to August 2026
Victim countries
Philippines, Taiwan, Afghanistan, Namibia, and likely the Republic of Korea
Signature technique
Sandboxie DLL sideloading
Payload
Meterpreter-based backdoor decoded in memory from an encrypted config.ini
Aliases
None listed by Sophos

Who Is BRONZE SANDCASTLE?

Sophos describes the group as China-based and lists no aliases. CTU created a new designation because it could not reliably link the activity to BRONZE PRESIDENT or BRONZE ATLAS, even though the geography of the targets overlaps. Sophos bases the China assessment on two points. The group targets organisations in Asia and Africa, which Sophos calls typical of several China-based groups. Its activity also peaks in UTC+8, which the authors say fits the “996” working hours common in China’s tech sector. Sophos adds that the loaders and payload appear specific to BRONZE SANDCASTLE.

Sophos does not name sectors, and it does not describe how the group first gets into a network or how it stays there. Treat both as open questions. Victims are named by country only: the Philippines, Taiwan, Afghanistan and Namibia, with the Republic of Korea listed as likely.

How Does the Infection Chain Work?

Sophos shows a staging archive, a sample named aez.zip. It holds three files: a clean program (javaw.exe), a malicious DLL (jli.dll) and an encrypted payload file (config.ini). The same pattern repeats with Sandboxie files, where the DLL is sbiedll.dll.

From archive to beacon
  1. Archive stagedA ZIP holds a clean program, a rogue DLL and an encrypted config.ini
  2. Trusted program startsThe program loads the DLL from its own folderTechnique T1574.001 (MITRE ATT&CK, opens in a new tab)
  3. DLL decodes the payloadThe DLL reads config.ini and decrypts it
  4. Payload runs in memoryA reflective loader runs the Meterpreter-based backdoor with few disk traces
  5. Beacon and theftA JSON info block goes to the C2 server; the operators then collect Active Directory data

The DLL hides its logic with a flattened control flow, a custom bit-mixing routine and indirect jumps. The decoded payload begins with a position-independent loader that uses its own API hashing rather than the ROR13 hashing found in standard Metasploit shellcode. Because the operators only change config.ini, the DLL can stay the same while the behaviour changes. This is the DLL hijacking and sideloading technique that MITRE ATT&CK lists as T1574.001.

Which Trusted Programs Does It Abuse?

Sandboxie is the group’s signature, but Sophos lists nine program and DLL pairs. A defender can use the table as a lookup list.

Legitimate file Malicious DLL
SandboxieWUAU.exe sbiedll.dll
Start.exe (renamed Sandboxie) sbiedll.dll
javaw.exe jli.dll
Krita.exe Krita.dll
NvdaHelper.exe NvdaHelperRemote.dll
Jcef_helper.exe Libcef.dll
Vmmap.exe Version.dll
LineAppMgr.exe msvcp140.dll
bginfo64.exe snmpapi.dll

Do not treat a file name alone as proof. Every file in the table is a normal program or library when it sits in its proper place. The signal is the combination: a trusted program, a DLL in an unexpected folder and an encrypted config.ini beside them.

What Does the Group Do After the Backdoor Runs?

The backdoor sends a JSON block that includes the host name, user name, domain, operating system version, internal and public IP addresses and a process list. Sophos also saw the operators run Windows net commands to map the network and user accounts. They then create a Volume Shadow Copy with vssadmin.exe and copy ntds.dit, the Active Directory database that holds credentials and domain settings. A copy of that file taken from a domain controller is a serious event. See our entry on OS credential dumping.

For command and control, Sophos reports two domains for payload version 1.1.5. Version 1.1.7 fetches encrypted configuration files from a little-used GitHub repository. Sophos also lists file-sharing and messaging services (file.io, gofile.io and ably.net or ably.io) as possible tasking channels. The full indicator list sits in the SophosLabs GitHub repository, in the file BRONZESANDCASTLE_Meterpreter_IOCs.csv. It holds file hashes for the loaders and payload, plus the two C2 domains.

How Can Defenders Check for It?

Sophos advises focusing on behaviour, because the payload is decoded at runtime and static file-based detection may miss it. Watch for DLLs that read a local file and then run code in memory, for reflective loading, for odd PE headers in memory and for position-independent shellcode. The checks below turn that advice and the table above into hunting steps. The first five follow from the facts Sophos reports. They are our suggestions and not Sophos wording.

Defender checklist
  • Search for the nine pairsLook for any program from the table running from a folder it was not installed in, such as a user profile, Downloads or a temp folder.
  • Compare the DLL and the programA signed program that loads an unsigned DLL from its own folder is the pattern to review first.
  • Look for Sandboxie where nobody uses itTreat SandboxieWUAU.exe or Start.exe on a host without Sandboxie installed as suspect.
  • Read the file hashes in the SophosLabs listMatch the loader and payload hashes against your endpoint data, and add the two C2 domains to DNS and proxy searches.
  • Watch domain controllersAlert on vssadmin.exe creating a shadow copy followed by a copy of ntds.dit, and on bursts of net commands.
  • Use memory-aware detectionFollow Sophos: look for reflective loading and in-memory code run by a DLL that has just read a file.

If you find a match, isolate the host first, then check whether a domain controller was touched. If ntds.dit was copied, plan a credential reset for the domain in line with your incident response process. Our threat hunting and EDR entries explain how these searches fit a normal workflow, and the indicator of compromise entry explains why hashes and domains age quickly.

What Do Brandefense Sources Show?

We searched Telegram, Discord and dark web sources from 21 September to 21 October 2026. Nine posts name BRONZE SANDCASTLE (8 on Telegram, 1 on Discord), all dated 21 October. Nothing earlier in that window names the group, which fits a newly published name. We found no posts for the file name sbiedll.

Frequently Asked Questions.

What is BRONZE SANDCASTLE?

It is the name Sophos Counter Threat Unit gave to a China-based threat group. Sophos tracked it through incidents between August 2025 and August 2026 in Asia and Africa.

How does BRONZE SANDCASTLE use Sandboxie?

The group places a malicious sbiedll.dll next to a genuine Sandboxie program such as SandboxieWUAU.exe. The program loads the DLL, which decodes an encrypted config.ini and runs a Meterpreter-based backdoor in memory.

Does Sophos link it to other groups?

No. Sophos created a new name because it could not reliably link the activity to BRONZE PRESIDENT or BRONZE ATLAS, although the targeted countries overlap.

Where are the indicators of compromise?

Sophos publishes them as BRONZESANDCASTLE_Meterpreter_IOCs.csv in the SophosLabs GitHub repository. They include loader and payload hashes and two C2 domains.

Sources

  1. 1 BRONZE SANDCASTLE deploys modified Meterpreter shells (Sophos)
  2. 2 BRONZE SANDCASTLE Meterpreter IOCs (SophosLabs GitHub)
  3. 3 Hijack Execution Flow: DLL, T1574.001 (MITRE ATT&CK)
Share