Bronze Sandcastle Malware: Detect Trusted-App DLL Sideloading

Bronze Sandcastle malware turns a familiar Windows trust signal into cover for espionage. On October 21, 2026, The Hacker News publicly reported that the newly documented China-aligned group repeatedly places malicious libraries beside legitimate Sandboxie executables, causing trusted applications to load attacker code into memory.

The immediate lesson is not to block Sandboxie. Sophos found the same pattern across Java, Krita, NVDA, Sysinternals, LINE, and Chromium-related components. If your defenses trust a signed executable without validating the library it loads, a clean-looking process can still capture keystrokes, take screenshots, enumerate accounts, and receive commands. You need detection that connects file placement, image loading, memory activity, and network behavior.

Key Takeaway: A legitimate executable is evidence about one file, not proof that every module loaded into its process is safe.

What the Bronze Sandcastle malware disclosure reveals

The Hacker News reported the Bronze Sandcastle activity on October 21, making this a same-day public disclosure. The underlying Sophos investigation, published October 20, covers incidents observed from August 2025 through August 2026 and victims in the Philippines, Taiwan, Afghanistan, Namibia, and probably South Korea.

Researchers assess the group as likely operating under the direction of China's leadership, but attribution should not distract from the reusable technique. The strongest technical marker is repeated DLL sideloading through legitimate applications.

Sophos documented multiple executable and library pairs, including:

• SandboxieWUAU.exe with a malicious sbiedll.dll
• javaw.exe with jli.dll
• Krita.exe with Krita.dll
• NvdaHelper.exe with NvdaHelperRemote.dll
• Vmmap.exe with version.dll
• bginfo64.exe with snmpapi.dll

The malicious DLL commonly reads an encrypted config.ini, decodes a payload, and begins in-memory execution. Two identified payload versions, 1.1.5 and 1.1.7, can collect host and user details, enumerate the network, record keystrokes, capture screenshots, inspect running processes, and communicate with external services.

Key Stat: Sophos documented at least eight legitimate executable and malicious DLL combinations, showing that one filename blocklist cannot solve the problem.

The campaign also used common internet services and GitHub for configuration delivery. That makes destination reputation an incomplete signal. A connection to a legitimate cloud service may still be part of malicious command and control when the process, module, account, and timing do not fit the endpoint's role.

Why DLL sideloading defeats shallow trust checks

Windows applications depend on dynamic-link libraries for reusable code. When a program requests a DLL without a safely constrained full path, the operating system searches locations in a defined order. An attacker who can place a malicious library with the expected name in a preferred location can make the legitimate program load it.

Microsoft's DLL security guidance describes the core risk: code from the planted library executes inside the application and inherits that process's user context. The executable may be authentic and digitally signed while the adjacent DLL is neither expected nor trustworthy.

This creates three defensive blind spots:

1. Reputation mismatch: Controls recognize the signed executable and allow it to run.
2. File-memory mismatch: The encrypted payload looks harmless on disk, then becomes executable only after decoding in memory.
3. Context mismatch: A legitimate service such as GitHub, file hosting, or messaging infrastructure carries configuration or tasking that would look suspicious only when connected to the process lineage.

MITRE ATT&CK classifies DLL sideloading as T1574.001 and notes that adversaries use it to mask activity under trusted or elevated processes. Bronze Sandcastle is a current case study in why allowlisting a parent executable without controlling its loaded modules leaves a gap.

Hexon's ShieldCrash endpoint trust guide reaches a related conclusion from a different incident: product reputation and patch status are inputs to trust, not permanent exemptions from behavioral monitoring.

Common Mistake: Blocking only SandboxieWUAU.exe. The campaign used several unrelated host applications, and attackers can change the host while preserving the same loading behavior.

Hunt Bronze Sandcastle malware across four evidence layers

A reliable hunt should connect files, process execution, module loading, and post-load behavior. Any one layer can be noisy. Their sequence is much harder for normal software to imitate accidentally.

1. Find suspicious executable-DLL bundles

Search endpoints for the documented pairs, but add contextual tests. Flag trusted executables running from user-writable folders, temporary paths, archive extraction directories, shared drives, or locations that do not match your software inventory.

For each executable, collect:

• full path, hash, signature, signer, and creation time
• adjacent DLL and configuration filenames
• archive, installer, email, browser, or remote-management origin
• first-seen host and first execution time
• parent process, command line, user, and privilege level

Compare the complete directory against a known-good installation. A signed binary copied out of its normal product directory and placed beside a new DLL deserves review even if both filenames are common.

2. Correlate image loads

Use endpoint detection telemetry, Windows event collection, or Sysmon image-load data to identify which DLLs a process actually loads. Focus on unsigned or rarely seen libraries loaded by signed executables, especially when the library resides beside the executable outside a normal installation path.

Hash prevalence helps but is not a verdict. A rare module is more useful when combined with a newly created directory, an unexpected execution parent, or immediate access to config.ini.

Pro Tip: Build detections around the relationship between signer, executable path, module path, and prevalence. That survives filename changes better than a static list of malicious DLL names.

3. Detect decode-to-memory behavior

Sophos recommends looking for DLLs that read local files and immediately stage code in memory. Hunt for a sequence such as:

1. A trusted executable loads a local DLL.
2. The DLL reads an encrypted or unusually opaque configuration file.
3. The process allocates writable memory and changes it to executable.
4. Execution transfers into that region or creates a suspicious thread.
5. The process begins discovery, input capture, screenshot activity, or network communication.

Static scanning may identify known samples, but memory telemetry and behavioral correlation are essential when the on-disk payload is encrypted. This is the same reason Hexon's malicious npm runtime malware guide emphasizes what code does after launch rather than relying only on package reputation.

4. Add network and account context

Review connections from the suspected host process to file-sharing services, messaging platforms, GitHub APIs, and newly seen domains. Do not block an entire service solely because an attacker used it. Instead, correlate destination, repository or account, user agent, request timing, downloaded object, and process lineage.

Then look for the backdoor's likely follow-on activity: local and domain account enumeration, process discovery, network mapping, keyboard capture, screenshots, and access to browser or application data. A trusted utility that suddenly performs several of these actions presents a stronger signal than any destination alone.

Contain a suspected DLL sideloading compromise

If the evidence chain is credible, isolate the endpoint from the network while preserving your endpoint-response channel. Do not simply delete the suspicious DLL and return the machine to service. The loaded code may have collected credentials, created another persistence path, or moved laterally.

Use a disciplined containment sequence:

1. Isolate the host and record the exact time.
2. Capture volatile evidence, including processes, loaded modules, network connections, logged-on users, and relevant memory when your response process supports it.
3. Preserve the executable, DLL, configuration file, directory metadata, hashes, and endpoint timeline.
4. Identify how the bundle arrived and whether the same source reached other systems.
5. Disable or reset exposed accounts based on proven access and captured activity.
6. Block confirmed malicious hashes, paths, infrastructure, repositories, or accounts across the environment.
7. Hunt for the same behavior on peer endpoints before rebuilding the affected machine.

Treat screenshots and keylogging as potential credential exposure. Passwords, session tokens, one-time codes, recovery information, and sensitive content may have been captured even when no credential file was stolen directly.

Scope rotations to evidence, but move quickly. Prioritize accounts used on the endpoint during the compromise window, privileged identities, remote-access credentials, browser sessions, and secrets visible in applications. Hexon's session revocation after password reset guide explains why changing a password without invalidating active sessions can leave attacker access intact.

Common Mistake: Reimaging one endpoint before searching for the delivery source. If the same archive, share, remote tool, or compromised account remains active, the clean system can be infected again.

Prevent trusted applications from loading attacker code

Prevention starts by controlling where software runs and who can write beside it. Users should not be able to place executable-DLL bundles in broadly trusted locations and run them without scrutiny.

Apply these controls in layers:

• Restrict execution from downloads, temporary directories, user profile paths, and writable network shares.
• Use application control that evaluates scripts, DLLs, installers, and child behavior, not only executable signatures.
• Keep software in managed installation directories with permissions that prevent standard users from replacing adjacent libraries.
• Remove unused utilities and stale portable software that offer unnecessary sideloading hosts.
• Monitor new executables and libraries that appear together, especially from archives or remote administration sessions.
• Baseline normal module loads for high-value applications and investigate rare deviations.
• Enable endpoint telemetry capable of observing memory allocation, protection changes, and suspicious in-memory execution.
• Segment administrative workstations and sensitive systems so one compromised endpoint cannot freely enumerate the environment.

Developers should use fully qualified paths and safer library-loading APIs where possible. Microsoft also recommends testing applications for insecure loads and removing unnecessary search locations. Those practices reduce the number of legitimate programs that attackers can repurpose.

Signed code remains valuable, but policy should express what that signature permits. A signed diagnostic tool in its managed directory with known libraries may be normal. The same binary launched from a user-writable folder beside a newly created DLL should face additional scrutiny.

A 24-hour Bronze Sandcastle response plan

In the first four hours, distribute the known indicators from Sophos, search for the documented executable-DLL pairs, and identify trusted executables running from unexpected locations. Prioritize systems exposed to targeted users, international operations, sensitive research, government work, and administrative access.

Within eight hours, correlate image loads, encrypted configuration access, memory activity, discovery behavior, and outbound connections. Isolate hosts where multiple stages align. Preserve evidence before removing files or ending processes.

Within 12 hours, expand the hunt beyond filenames. Search for rare signed executables paired with unsigned adjacent libraries, followed by config-file reads and executable-memory behavior. Review remote administration, archive extraction, email, browser, and file-share activity around the first-seen time.

Within 24 hours, complete credential and session containment for affected users, block confirmed infrastructure, rebuild compromised systems from trusted media, and close the delivery path. Document what the original controls saw, what they missed, and which telemetry made the difference.

The practical outcome should be a reusable detection chain, not a one-day indicator sweep. Bronze Sandcastle may change its executable, DLL name, encryption, or command channel. The relationship between an unexpected module, decoded memory, suspicious host behavior, and anomalous communications is more durable.

Key Takeaway: Hunt the execution chain first and the campaign label second. Behavioral detections remain useful after the attacker changes names and infrastructure.

Turn the disclosure into a durable trust policy

Bronze Sandcastle malware demonstrates how a legitimate application can become a carrier for attacker-controlled code without the legitimate file itself being modified. That distinction matters for every organization that uses signatures, allowlists, or product reputation to reduce alert volume.

Do not throw away those controls. Make them conditional. Validate where the executable runs, which modules it loads, what happens in memory, and whether its network and account behavior match its business purpose.

Start with the known Sandboxie pattern, then broaden the hunt across the environment. Inventory unexpected executable-DLL pairs, correlate them with memory and network evidence, contain affected hosts, revoke exposed sessions, and harden writable execution paths. That turns a fresh threat report into a control that can catch the next sideloading campaign before its name is known.