Fala com um especialista
PreçosNotíciasFala com um especialista
Voltar à sala de imprensa
Ameaças

Bronze Sandcastle Abuses Sandboxie DLL Sideloading to Plant Stealthy Backdoors

A China-aligned espionage cluster is hijacking signed apps like Sandboxie, Java and Sysinternals tools to load encrypted, in-memory backdoors across Asia and Africa. Here's how it works and how to detect it.

4T4Tify Team4Tify
Oct 21, 2026·5 min de leitura
Bronze Sandcastle Abuses Sandboxie DLL Sideloading to Plant Stealthy Backdoors

Bronze Sandcastle Turns Trusted Windows Apps Into Backdoor Launchers

A newly profiled China-aligned espionage cluster, tracked as Bronze Sandcastle, has been quietly compromising organizations in Asia and Africa by abusing something defenders usually trust: legitimate, signed software. Its main trick is DLL sideloading through a renamed Sandboxie executable. Seven other well-known applications serve the same purpose.

What happened

Sophos X-Ops researchers say the group has been active since mid-2025. Between August 2025 and August 2026, they tied intrusions to victims in the Philippines, Taiwan, Afghanistan and Namibia, and probably South Korea. Activity clusters around the UTC+8 time zone. The researchers describe the group as China-aligned, which is a regional and operational assessment. It does not name a specific state unit.

The attack chain follows a familiar pattern, but it is well executed:

  1. A genuine Sandboxie component (SandboxieWUAU.exe) is dropped on the host next to a malicious sbiedll.dll.
  2. When the trusted program starts, Windows' DLL search order makes it load the attacker's DLL instead of the real one.
  3. The DLL reads an encrypted config.ini, decrypts it in memory and runs the backdoor as shellcode. No clean payload ever lands on disk.

Sandboxie is not the only lure. The same approach has been seen with seven other host/DLL pairs:

  • javaw.exe → jli.dll (Java)
  • Krita.exe → Krita.dll (Krita)
  • NvdaHelper.exe → NvdaHelperRemote.dll (NVDA screen reader)
  • Jcef_helper.exe → Libcef.dll (Java Chromium Embedded Framework)
  • Vmmap.exe → version.dll (Sysinternals VMMap)
  • LineAppMgr.exe → msvcp140.dll (LINE messenger)
  • bginfo64.exe → snmpapi.dll (Sysinternals BgInfo)

The backdoor itself (versions 1.1.5 and 1.1.7 identified so far) maps the local network and user accounts and collects system details, running processes, keystrokes and screenshots. For tasking and staging it has used file-sharing and messaging services (file.io, gofile.io, ably.net, ably.io). Version 1.1.5 used look-alike C2 domains made to resemble well-known airline and logistics brands. Version 1.1.7 pulled encrypted configs from a GitHub repository through the API. That account has since been taken down.

Why it matters

DLL sideloading works because the process that runs the malicious code is trusted and often digitally signed. Allow-lists, reputation checks and many antivirus engines let it through. If the host program runs with elevated rights, the implant inherits them. If it starts on boot, the attacker gets persistence without needing a dedicated autorun entry.

Bronze Sandcastle adds two layers that make life harder for defenders:

  • Encrypted payloads and configs, decoded only at runtime, defeat static file signatures.
  • Configuration-driven behavior lets operators change what the implant does without replacing the DLL, so hash-based IOCs go stale quickly.

Abusing Sandboxie is not new either. Another China-nexus actor sideloaded a Sandboxie-signed binary in 2024. Defenders should treat "signed security or utility tool running from an odd path" as a recurring pattern, not a one-off.

What to do

  • Hunt for behavior, not hashes. Alert when a DLL reads a local file and then immediately allocates and executes memory. Decode-and-stage activity like that is a much stronger signal than any single file hash.
  • Watch where trusted binaries run from. Sandboxie, Java, Krita, NVDA, LINE, VMMap or BgInfo executables running from ProgramData, AppData, temp folders or other user-writable paths, especially if the software isn't deployed in your estate, deserve a close look.
  • Check DLL load paths. Use EDR or Sysmon (Event ID 7) to flag signed processes loading sbiedll.dll, jli.dll, version.dll, msvcp140.dll, snmpapi.dll and similar from outside their expected install directories.
  • Tighten application control. WDAC or AppLocker rules that block execution from user-writable locations shut down most sideloading setups.
  • Review egress. Unexpected endpoint traffic to file-sharing services, real-time messaging APIs or raw GitHub API calls from non-developer machines is worth investigating.
  • Validate your detection, don't assume it. Signed-binary abuse is the kind of gap that only shows up when someone actually tries it. 4Tify's penetration testing team can safely emulate techniques like DLL sideloading in a controlled engagement, so you can confirm whether your EDR and SOC would catch them before a real intruder tests it for you.

Original research: Sophos X-Ops. Reported by The Hacker News. This article is 4Tify's own summary and analysis.

PARTILHAR