BRONZE SANDCASTLE: Signed-App DLL Sideloading, IOCs and Hunts

BRONZE SANDCASTLE is a China-based espionage cluster that copies trusted programs such as a Sandboxie component, a Java launcher and Sysinternals tools into a folder next to a malicious DLL, so the trusted program loads the attacker's code. The payload is a modified Meterpreter backdoor. No software is vulnerable. Hunt for these file pairs and the published hashes now.

A security vendor's report, published on 20 October 2026 alongside an indicator list on GitHub, gave the cluster its name and described victims in the Philippines, Taiwan, Afghanistan and Namibia between August 2025 and August 2026, with the Republic of Korea listed as a likely victim. The group's most distinctive habit is pairing a legitimate Sandboxie executable with a malicious sbiedll.dll. It also abuses at least seven other trusted programs the same way.

This post is for Windows administrators, detection engineers, incident responders and developers who ship Windows software. It covers every published hash and domain, the file pairs to hunt for, PowerShell and Sysmon checks, what to do after a hit on a domain controller, and why "signed" is not the same as "supposed to be here".

One point needs saying up front, because headlines tend to blur it. Sandboxie, Java, Krita, NVDA, LINE, the Java Chromium Embedded Framework helper and the Sysinternals tools named here are not reported as vulnerable, and there is no CVE. The attackers bring their own copies of these legitimate programs and use the normal way Windows finds DLLs. If you run these programs from their proper install folders, you are not exposed through them. What matters is a copy sitting somewhere it should not be, next to a DLL it should not have.

What happened

The research describes a cluster of intrusions that the reporting vendor could not reliably tie to two other China-based groups it tracks, BRONZE PRESIDENT and BRONZE ATLAS. Targeting overlapped with both in Asia and Africa, but the technical traits were different enough to justify a new name. The vendor's threat profile says the group has been active since mid-2025, assesses it as likely working under the direction of the leadership of the People's Republic of China, and gives espionage as the motive.

How the attackers first got in is not described in the report. What is described is what happened once they were on a machine: a trusted program dropped beside a malicious DLL, an encrypted file named config.ini decoded in memory into a backdoor, network and account discovery with Windows net commands, and theft of the Active Directory database through a volume shadow copy.

Timeline

Who is affected

The named targets are in Asia and Africa, but the technique works against any Windows estate and the same trusted programs exist everywhere.

How it works, in plain language

Windows programs rarely contain all their code in one file. They load helper libraries, DLLs, at start-up. When a program asks for a DLL by name without a full path, Windows searches a fixed list of places. According to Microsoft's documentation, with safe DLL search mode on (the default), the folder the application was loaded from is searched before the system folder for most DLLs. Only DLLs on the Known DLLs list, and a few other redirection cases, are resolved earlier.

That ordering is by design. It lets an application ship its own copy of a library. It also means that if you copy a legitimate, signed program into a new folder and put a DLL with the right name next to it, the program will load your DLL. The program's signature is still valid. The program is still the real one. It is simply running somewhere it was never installed, and loading a library its publisher never shipped.

MITRE ATT&CK files this under T1574.001, "Hijack Execution Flow: DLL", which now covers sideloading, search order hijacking, redirection, phantom DLLs and substitution together. A 2020 threat intelligence write-up on DLL misconfigurations notes that attackers look for a standalone signed executable that loads a DLL by relative name, and that the signature helps them get past allowlisting and endpoint tools that trust the signer.

Why this group's design is harder to catch

The report describes three layers.

1. A signed host. A legitimate executable, sometimes renamed (for example a Sandboxie program renamed to Start.exe), starts normally.
2. A thin loader DLL. The malicious DLL is not the backdoor. It reads a file named config.ini from disk, decrypts it and runs it in memory. Its code is protected by control flow flattening: instead of ordinary branches, a state value goes through a custom bit mixing routine that picks the next block from a jump table, and some entries lead nowhere useful, to slow down analysis.
3. An encrypted payload file. config.ini is not a configuration file. Decoded, it is a reflective loader stub followed by a Windows executable that is loaded straight into memory.

The report notes the advantage for the attacker: operators can change behaviour by replacing config.ini without touching the DLL, and the backdoor never needs to exist as a plain file on disk. One sample archive, aez.zip, held exactly three files: javaw.exe, jli.dll and config.ini.

The backdoor

The decoded payload shares traits with stageless Metasploit shellcode, such as position independent code, manual checks of the embedded executable's headers and loading it in memory. It is not stock Metasploit. According to the report:

• It resolves Windows APIs with its own hashing and transformation routines instead of the ROR13 hash that Metasploit uses.
• Its code base is much larger and more complex than typical Metasploit shellcode.
• Parts of COFFLoader, an open source project published on GitHub, appear in memory. COFFLoader is a small loader for Beacon Object Files, compiled object files that run inside an implant. The report suggests the author used custom Beacon Object Files to build post-exploitation features.
• In-memory strings tied to C++ function names point to built-in data stealing functions. The report does not list them.

The Hacker News summary says the backdoor collects keystrokes and screenshots. We did not find that detail in the report text we fetched, which mentions data stealing functions in general terms. Treat keystroke and screenshot capture as reported by secondary coverage, not confirmed in the primary source.

Technical details

Every value in this section comes from the vendor report or its companion indicator CSV unless another source is named. Domains are defanged in prose and written plainly only inside code blocks meant for blocklists and hunts.

Host programs and sideloaded DLLs

Two gaps are worth knowing. The report lists Krita.dll and version.dll as sideloaded DLLs but the CSV has no hashes for them. The CSV lists loaders named CoreFoundation.dll and MSIMG32.dll that do not appear in the report's table of pairs, so their host programs are not public.

Payload versions

Files the report lists in the GitHub repository, described as likely encrypted configurations: main.3ku8inqb.js.map, main.lhxjkkai.js.map, main.y8hnze7q.js.map and README.md. The report also mentions encrypted .ts files, possibly backdoor implants, without naming them. Naming the configs like web build artefacts is a choice that helps them blend into ordinary developer traffic.

The version 1.1.7 check-in, according to the report, carries: hostname, username, a GUID, domain, operating system version (the example given is 10.0.19042), internal IP address, public IP address, a process listing with PID, process name and execution method, working directory, code page, CPU architecture, the implant start time and the implant type, server or client.

Network indicators for blocklists and hunts

dc.cathaypacifice.com
net.dpworldto.com
api.github.com/repos/LatonyCharnleyaW
github.com/LatonyCharnleyaW

The two domains are in the CSV. The GitHub path is in the report text. You will only see the GitHub account name in logs that record full URLs, such as a TLS inspecting proxy. DNS logs will show only api.github.com, which is useless as an indicator on its own.

SHA-256 hashes from the indicator CSV

The CSV, committed on 20 October 2026 at 15:32:01 UTC, holds MD5, SHA-1 and SHA-256 for each file. The SHA-256 values are below in the CSV's own order. Use the CSV itself for MD5 and SHA-1.

That is 21 files: five sbiedll.dll loaders, nine jli.dll loaders, one each for libcef.dll, CoreFoundation.dll, NvdaHelperRemote.dll, MSIMG32.dll, snmpapi.dll and msvcp140.dll, and one config.ini payload. Nine distinct jli.dll builds suggest the Java pairing was the most used, though the report does not say so directly.

A caution about the config.ini hash. Because the design lets operators swap the encrypted payload at will, a single payload hash will match only the sample the vendor saw. The loader hashes are more useful, and behaviour is more useful still.

Detection names from the reporting vendor

The report lists these detection names from its own products, which can help if you are correlating alerts or sandbox reports that use them: ATK/Swrort-Y, ATK/ScLoad-W, ATK/ScLoad-X, ATK/ScLoad-Y, ATK/ScLoad-Z, Troj/Loader-JL and Troj/Loader-JP.

Technique mapping

The threat profile lists no ATT&CK IDs. The mapping below is ours, based on the behaviour the report describes.

What to do now

Work through these in order. Steps 1 to 4 are quick sweeps any Windows team can run. Steps 5 and 6 are for when something turns up.

1. Pull the indicators into your tools

Download the CSV from the vendor's public IoCs repository (linked in Sources) and load the SHA-256 values and the two domains into your blocklists, your EDR custom indicators and your SIEM watchlists. Add the two domains to DNS sinkholes or proxy deny lists. Do not block api.github.com, file.io, gofile.io or ably.io across the estate; alert on them from unusual processes instead.

On a Windows analyst machine, this reads the SHA-256 values from the CSV. Note that the indicator type column in the file carries trailing spaces, so trim before comparing.

$csv = Import-Csv .\BRONZESANDCASTLE_Meterpreter_IOCs.csv
$sha256 = $csv |
  Where-Object { $_.Indicator_type.Trim() -eq 'sha256' } |
  ForEach-Object { $_.Data.Trim().ToLower() }
$domains = $csv |
  Where-Object { $_.Indicator_type.Trim() -eq 'domain' } |
  ForEach-Object { $_.Data.Trim() }
$sha256.Count   # expect 21
$domains        # expect two lookalike domains

2. Sweep endpoints for the published hashes

Run this on suspected machines, or push it through your remote management tool. It hashes DLLs and any config.ini under the folders where attackers usually stage files, and prints matches.

$roots = @("$env:SystemDrive\Users", "$env:ProgramData", "$env:SystemRoot\Temp")
Get-ChildItem -Path $roots -Recurse -Force -File -Include *.dll, config.ini -ErrorAction SilentlyContinue |
  Where-Object { $_.Length -lt 50MB } |
  ForEach-Object {
    $h = (Get-FileHash -LiteralPath $_.FullName -Algorithm SHA256).Hash.ToLower()
    if ($sha256 -contains $h) {
      [pscustomobject]@{ Path = $_.FullName; SHA256 = $h; Modified = $_.LastWriteTimeUtc }
    }
  }

No match is not proof: new loader builds will not share these hashes.

3. Hunt for the file pairs in the wrong places

This is the higher value hunt, because it does not depend on hashes. It looks for the host programs named in the report anywhere under user profiles, ProgramData and the Windows temp folder, then reports whether the paired DLL and a config.ini sit in the same folder, and who signed each file.

$pairs = @{
  'SandboxieWUAU.exe' = 'sbiedll.dll'
  'Start.exe'         = 'sbiedll.dll'
  'javaw.exe'         = 'jli.dll'
  'Krita.exe'         = 'Krita.dll'
  'NvdaHelper.exe'    = 'NvdaHelperRemote.dll'
  'jcef_helper.exe'   = 'libcef.dll'
  'vmmap.exe'         = 'version.dll'
  'vmmap64.exe'       = 'version.dll'
  'LineAppMgr.exe'    = 'msvcp140.dll'
  'bginfo64.exe'      = 'snmpapi.dll'
  'bginfo.exe'        = 'snmpapi.dll'
}
$roots = @("$env:SystemDrive\Users", "$env:ProgramData", "$env:SystemRoot\Temp")
Get-ChildItem -Path $roots -Recurse -Force -File -Include ($pairs.Keys) -ErrorAction SilentlyContinue |
  ForEach-Object {
    $dir = $_.DirectoryName
    $dll = Join-Path $dir $pairs[$_.Name]
    [pscustomobject]@{
      Exe        = $_.FullName
      ExeSigner  = (Get-AuthenticodeSignature -LiteralPath $_.FullName).SignerCertificate.Subject
      PairedDll  = (Test-Path -LiteralPath $dll)
      DllSigner  = if (Test-Path -LiteralPath $dll) { (Get-AuthenticodeSignature -LiteralPath $dll).Status } else { '' }
      ConfigIni  = (Test-Path -LiteralPath (Join-Path $dir 'config.ini'))
    }
  } | Where-Object { $_.PairedDll } | Format-Table -AutoSize

How to read the output:

• A hit where ConfigIni is True deserves immediate attention. A legitimate Java runtime, Sandboxie install or Sysinternals tool does not need a config.ini beside the binary.
• Start.exe with a Sandboxie signer is a strong signal on its own, because the report describes a renamed Sandboxie executable.
• vmmap.exe or bginfo64.exe beside version.dll or snmpapi.dll is suspicious in any folder. Those DLLs belong in System32.
• javaw.exe with jli.dll under a user profile is common for portable Java runtimes and developer tools. Check the folder layout: a real runtime has bin, lib and many other files. A folder holding only the three files from aez.zip does not.
• A paired DLL that is unsigned, or signed by someone other than the host's publisher, is worth a closer look, though some legitimate application DLLs are unsigned.

4. Check DNS, process and image load telemetry

If you run Sysmon, these queries look back through its operational log for the published domains, for the backdoor's credential theft pattern and for loads of the named DLLs from outside their usual homes.

# DNS queries to the lookalike domains (Sysmon Event ID 22)
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -FilterXPath '*[System[EventID=22]]' -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'cathaypacifice\.com|dpworldto\.com' } |
  Select-Object TimeCreated, Message

# Shadow copy creation and ntds.dit access in process command lines (Event ID 1)
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -FilterXPath '*[System[EventID=1]]' -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'vssadmin.*create\s+shadow|ntds\.dit' } |
  Select-Object TimeCreated, Message

# Named DLLs loaded from user profiles, ProgramData or Temp (Event ID 7)
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -FilterXPath '*[System[EventID=7]]' -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'ImageLoaded: .*\\(Users|ProgramData|Temp)\\.*\\(sbiedll|jli|krita|nvdahelperremote|libcef|version|msvcp140|snmpapi|corefoundation|msimg32)\.dll' } |
  Select-Object TimeCreated, Message

Without Sysmon, check the local DNS cache for the domains on a suspect host, and the Security log for process creation if command line auditing is on:

Get-DnsClientCache | Where-Object { $_.Entry -match 'cathaypacifice|dpworldto' }
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4688 } -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'vssadmin|ntds\.dit' }

On domain controllers, list existing shadow copies and compare their creation times with your backup schedule:

vssadmin list shadows

5. Add durable detections

Sysmon's Event ID 7 (image loaded) is off by default and records the loading process, hashes and signature details for each module, according to Microsoft's Sysmon documentation. It is noisy if you log everything, so log only the DLL names that matter here. A starting rule set:

<Sysmon schemaversion="4.82">
  <HashAlgorithms>sha256</HashAlgorithms>
  <EventFiltering>
    <RuleGroup name="bronze-sandcastle-sideload" groupRelation="or">
      <ImageLoad onmatch="include">
        <ImageLoaded condition="end with">\sbiedll.dll</ImageLoaded>
        <ImageLoaded condition="end with">\jli.dll</ImageLoaded>
        <ImageLoaded condition="end with">\NvdaHelperRemote.dll</ImageLoaded>
        <ImageLoaded condition="end with">\libcef.dll</ImageLoaded>
        <ImageLoaded condition="end with">\Krita.dll</ImageLoaded>
        <ImageLoaded condition="end with">\snmpapi.dll</ImageLoaded>
        <ImageLoaded condition="end with">\version.dll</ImageLoaded>
        <ImageLoaded condition="end with">\msimg32.dll</ImageLoaded>
        <ImageLoaded condition="end with">\CoreFoundation.dll</ImageLoaded>
      </ImageLoad>
      <ImageLoad onmatch="exclude">
        <ImageLoaded condition="begin with">C:\Windows\System32\</ImageLoaded>
        <ImageLoaded condition="begin with">C:\Windows\SysWOW64\</ImageLoaded>
        <ImageLoaded condition="begin with">C:\Windows\WinSxS\</ImageLoaded>
      </ImageLoad>
    </RuleGroup>
    <DnsQuery onmatch="include">
      <QueryName condition="contains any">cathaypacifice.com;dpworldto.com</QueryName>
    </DnsQuery>
  </EventFiltering>
</Sysmon>

Test it on a pilot group before rolling it out. jli.dll and libcef.dll load from legitimate application folders all day on developer workstations, so you will want path based exclusions for your known install locations, for example C:\Program Files\. Then alert on what is left, especially loads from user profiles, ProgramData and temp folders.

The report also recommends behavioural detection: a DLL reading a local file and then running code from memory, reflective loading and executable headers in memory. Make sure those detections are not suppressed just because the parent process is signed.

6. If you find a hit

1. Isolate, do not wipe. Keep the host on power and capture memory if you can. The backdoor lives in memory, and a reboot loses most of the evidence.
2. Collect the folder. Copy the host executable, the DLL, config.ini and any archive such as aez.zip, with hashes and timestamps.
3. Scope by account and time. Search for the same file names and hashes across the estate, and look at logons from the affected user account in the same period. The group is most active in UTC+8 working hours, so line up suspicious events against that window.
4. Check domain controllers. The report describes shadow copies and theft of ntds.dit. If there is any sign this reached a domain controller, plan as if every domain password hash was taken. That usually means resetting the krbtgt account password twice with a pause for replication between resets, resetting privileged and service account passwords, and reviewing trusts. Follow Microsoft's current guidance for your forest and get experienced help.
5. Look for persistence. Check scheduled tasks, services and Run keys that point at the folders you found.
6. Report. Organisations in the named countries should contact their national CERT.

What would have helped

There was no patch to apply, so the usual "update faster" advice does not fit. The controls that help here are about where code is allowed to run from and which libraries trusted programs are allowed to load.

Practices any team can use

Block DLLs from user writable folders. AppLocker DLL rules cover .dll and .ocx files. Microsoft's default DLL rules allow everyone to run DLLs from the Windows folder and Program Files and allow administrators to run DLLs from anywhere. A sideloaded DLL dropped into a user's profile by a non-administrative process would fall outside those defaults. Microsoft warns that with DLL rules on, every DLL every allowed app loads must be covered, and that performance may drop on resource constrained computers, so pilot it. App Control for Business (formerly Windows Defender Application Control) can enforce similar rules with publisher and path conditions.

Allow executables by path and publisher, not publisher alone. A rule that trusts anything signed by a well known publisher lets a copied SandboxieWUAU.exe or vmmap.exe run from a download folder. Rules that also require the expected install path stop the copy, even though the signature is valid.

Keep an inventory of expected binary and DLL pairs. For the programs you use, record install locations and the DLLs beside them, with hashes. Approved Sysinternals tools in one admin folder, Java runtimes only from managed packages and no portable copies on servers turn this group's favourite trick into an obvious anomaly.

Log image loads selectively. Sysmon Event ID 7 with a targeted rule set, as above, is cheap and directly shows a trusted program loading a library from the wrong folder.

Treat domain controllers as a separate tier. No general purpose tools, portable runtimes or Sysinternals copies should run on domain controllers. Alert on vssadmin create shadow and on any access to ntds.dit outside the backup system.

Watch developer service traffic from unusual processes. Version 1.1.7 fetched its configuration through the GitHub API. A javaw.exe in a download folder calling api.github.com is unusual even on a developer workstation, and only proxy logs with full URLs show the repository path.

For software publishers, close the door on your own binaries. If you ship a signed Windows executable, someone may one day copy it next to a malicious DLL. Microsoft's DLL security guidance recommends specifying full paths when loading DLLs, using the LOAD_LIBRARY_SEARCH flags with LoadLibraryEx or SetDefaultDllDirectories, and removing the current directory from the search path with SetDllDirectory("") early in start-up. Static imports are resolved before your code runs, so a call in your start-up code does not protect them; use delay loading or the linker options that restrict where dependent DLLs are loaded from, and load system DLLs such as version.dll from System32 explicitly. The same guidance describes using Process Monitor with CreateFile and LoadImage filters to spot DLL loads from unexpected folders during testing. Put that check in your release process.

Do not read "signed" as "safe to run anywhere". The same vendor's earlier analysis of related sideloading cases showed hosts from many well known publishers being abused, and some sideloaded DLLs carrying fake self-signed certificates. Verify certificate chains, but also ask whether the file belongs in that folder at all.

Where Safeguard fits

Safeguard is a software supply chain security platform. It does not run on endpoints, it is not an endpoint detection tool, and it would not have detected or stopped this intrusion. We do not want to stretch the fit, so here is where it does and does not apply.

• Knowing what you ship and run. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output) and shows which projects contain a given component and version. For teams that publish Windows software, an accurate component inventory of each release is the starting point for answering "which of our installers bundle libcef or a Java runtime, and at which versions?" That is useful when you review how your own programs load DLLs, but Safeguard does not analyse DLL search behaviour.
• Policies and gates. Policies evaluated in the platform can fail a build that brings in a component version you have banned, so your release inventory stays the one you approved.
• Help writing and running the hunt. The Safeguard CLI's assistant can write code and run commands on your machine with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to turn the hunts above into a script for your estate and approve each command it runs. You still own the judgement on what the output means.

Where Safeguard does not help: endpoint telemetry, memory forensics, blocking a DLL load, Active Directory recovery or detecting command and control traffic. Those belong to your endpoint, identity and network controls.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. This incident involves no software flaw and no package ecosystem, so it is outside what Zero-Day Discovery is for.

Gold Open Source at gold.safeguard.sh is free and needs no login; it shows CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version for a CVE, through the site, a free read API and a CI gate GitHub Action. There is no CVE here to look up. Gold Registry at registry.safeguard.sh provides hardened components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, a Sigstore signature and an evidence page per artifact. The relevant lesson from this incident is the one Gold is built around: a signature tells you who built a file, provenance tells you how and from what, and neither tells you the file belongs where you found it. Pull signed components with provenance from a curated source, install them in known locations, and treat anything outside those locations as suspect.

Common mistakes

Uninstalling Sandboxie, Java or Sysinternals tools in a panic. These programs are not vulnerable. The attacker brings their own copies. Removing the real install does nothing to a copy in a temp folder.

Hunting only by hash. The loaders exist in many builds, and config.ini can be swapped freely. Hash matches are useful, but the file pair and folder hunt finds builds nobody has published yet.

Searching only for sbiedll.dll. The Sandboxie pairing is the most distinctive, but the CSV has more jli.dll loaders than anything else. Run the full pair list.

Trusting the signer column. In this technique the executable's signature is always valid. The signal is the folder and the neighbour, not the signature.

Forgetting the domain controller. The report describes theft of ntds.dit. If you find a loader on a member server and stop there, you may miss the most damaging step.

Comparing CSV values without trimming. The indicator type column carries trailing spaces, so a strict string comparison silently returns nothing.

What changed since first reports

• The GitHub account is gone. The report names LatonyCharnleyaW as the repository used by version 1.1.7. Secondary coverage on 21 October said it was no longer accessible, and our check on 24 October returned HTTP 404 for both the web profile and the API endpoint. Historical proxy logs are now the only place you will see it.
• Secondary coverage added capability claims. The Hacker News reports keystroke and screenshot collection. The vendor report text we fetched mentions data stealing functions without that detail.

Open questions

• How the attackers got their first foothold. The report does not say, and that is the most useful missing fact for prevention.
• Which sectors were hit. The threat profile names only countries.
• How the config.ini payload is encrypted and whether the key is per victim.
• Whether the encrypted .ts files in the GitHub repository were implants, as the report suggests may be the case.
• Which programs hosted the CoreFoundation.dll and MSIMG32.dll loaders.
• Whether the lookalike domains still resolve or have been taken down. We did not query them.

FAQ

Is Sandboxie vulnerable?

No. Nothing in the report says Sandboxie has a vulnerability. The attackers copy a legitimate Sandboxie executable into their own folder and place a malicious sbiedll.dll beside it. Windows then loads the DLL from the program's folder, as it is designed to do. A normal Sandboxie install is not a way in for this group.

Is there a CVE or patch to apply?

No. There is no CVE because no product flaw is involved. The defences are configuration and detection: application control rules for DLLs, path aware allow rules, targeted image load logging and the hunts above.

Who is BRONZE SANDCASTLE?

A name the reporting vendor gave to a cluster of activity it assesses as China-based and likely working under the direction of the PRC leadership, with espionage as the motive. It is tracked separately from BRONZE PRESIDENT and BRONZE ATLAS because the activity could not be reliably linked to either.

Is this the same as the APT41 Sandboxie case from 2024?

No. In July 2024, reporting described APT41 using a Sandboxie-signed taskhost.exe to sideload a malicious sbiedll.dll that led to the DodgeBox loader and MoonWalk backdoor. The 2026 report describes a different cluster, a different loader and a Meterpreter-based payload. The shared trick shows how reusable a well chosen signed host is.

Does this affect macOS or Linux?

Nothing in the report points beyond Windows. Every host program, DLL and command it describes is Windows specific.

Which indicators matter most if we only have an hour?

The file pair hunt in step 3, then the two domains in DNS logs, then shadow copy activity on domain controllers. Hashes come last because new builds will not match.

What should software publishers take from this?

That their signed program can be used as a host. Load DLLs by full path, restrict the DLL search order with the LOAD_LIBRARY_SEARCH flags, handle static imports with delay loading or linker options, and test with Process Monitor for loads from unexpected folders before each release.

Did Safeguard find this activity?

No. The research comes from a security vendor's threat intelligence team. Safeguard is a software supply chain platform, not an endpoint or threat intelligence product, and it played no part in finding this cluster.

Fix it without waiting for upstream

This incident had no vulnerable package and nothing to patch, so the steps below are not the response to BRONZE SANDCASTLE. They are how we suggest teams handle the vulnerabilities that sit in the open source components and images they build and ship, which is where the next sideloading host or the next backdoor's entry point often begins.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows BRONZE SANDCASTLE, and none of them detects malware on an endpoint. They show how the assistant works with your approval, which is how you would use it to build and run the hunts in this post.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this incident you would instead ask it to write a PowerShell script that reads the published CSV, trims the indicator column and runs the hash and file pair hunts, then approve each command before it touches a machine.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick the folder that holds your Sysmon configuration, ask for the targeted image load rules from this post with exclusions for your own install paths, and approve the file edit before it is saved.

Click through it at your own pace, or open it full screen.

The mobile app demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. If an alert fires at night, the on-call responder could ask an analyst workstation to run the read-only DNS and shadow copy queries above and approve each one from a phone, without granting it anything broader.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. For how the assistant asks before acting, see the Safeguard CLI as a security aware coding assistant. For finding which of your products contain a given component, see using SBOMs to find affected products fast, and for other incidents this month, our October 2026 roundup.

Quick check

Sources

• A security vendor's report: BRONZE SANDCASTLE deploys modified Meterpreter shells
• A security vendor's threat profile: BRONZE SANDCASTLE
• Indicator CSV: BRONZESANDCASTLE_Meterpreter_IOCs.csv
• GitHub API commit history for the indicator CSV
• MITRE ATT&CK T1574.001: Hijack Execution Flow: DLL
• Microsoft Learn: Dynamic-link library search order
• Microsoft Learn: Dynamic-Link Library Security
• Microsoft Learn: DLL rules in AppLocker
• Microsoft Learn: Sysmon
• COFFLoader on GitHub
• Sandboxie on GitHub
• A security vendor's analysis of related DLL sideloading cases
• A 2020 threat intelligence post: Abusing DLL misconfigurations
• The Hacker News: China-aligned Bronze Sandcastle abuses Sandboxie (21 October 2026)
• The Hacker News: APT41 upgrades malware arsenal (July 2024)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.