Security teams should hunt for archives that deliver a legitimate signed executable alongside an unexpected DLL, then inspect whether the DLL is loaded from user-writable paths such as AppData. Prioritise process ancestry, module path checks, and task creation activity because this family uses sideloading, self-copying, and scheduled execution to persist after initial launch.
Detecting archive-delivered sideloading chains before they become persistent
ToneShell-style activity matters because the archive is not the payload in any meaningful defensive sense. The archive is just the delivery wrapper for a trusted executable placed next to a malicious or tampered DLL, which lets the attacker borrow legitimacy from a signed binary and move execution into a location defenders often trust too much. That pattern can bypass naive attachment filtering, simple hash allowlisting, and one-time file inspection unless teams correlate the archive contents with the subsequent module load path. For defenders, the security problem is not merely “a DLL in a zip” but an execution chain that mixes trusted software, user-writable storage, and later persistence. Archive handling and execution monitoring should therefore be joined up, not treated as separate problems. In practice, many security teams encounter this only after a legitimate process has already loaded an unexpected module from a writable directory rather than through intentional malware analysis.
Official control guidance is useful here when it is tied to the detection problem, not as a generic citation. The NIST Cybersecurity Framework 2.0 is relevant because it helps teams connect file delivery, execution monitoring, and response into one operational view.
How to trace the sideloading path from archive to loaded module
Detection works best when teams treat the archive, the extracted files, and the running process as one chain of evidence. Start by identifying archives that contain a plausible signed executable plus one or more DLLs whose names match common application dependencies, then confirm whether the executable launched from a temporary or user-controlled location. The important question is not only whether the file is signed, but whether the process later resolved a module from the same directory or from another writable path such as AppData, Downloads, or a staging folder under a user profile.
Useful telemetry usually comes from three places:
- Archive and file delivery logs, which show what arrived together and whether the contents look intentionally bundled.
- Process creation and ancestry data, which shows whether the executable was launched directly by a user, script, email client, or another unusual parent process.
- Module load and file creation telemetry, which shows the executable pulling in a DLL from an unexpected path and then copying itself or related artifacts for reuse.
Containment should follow the execution path, not just the archive. If a suspicious module load is observed, isolate the host, preserve the archive and extracted contents, and check for scheduled task creation or other persistence mechanisms that indicate the actor has already moved beyond the first launch. The most reliable containment decision is often to block further execution from the suspicious directory while evidence is retained for triage. The approach becomes less reliable when archives are unpacked by tooling that strips path context or when logging does not capture module resolution, because then the sideloading relationship is no longer visible.
NIST SP 800-53 Rev 5 Security and Privacy Controls is also relevant where organisations want to anchor detection, logging, and containment to established control expectations, especially around process monitoring and system integrity.
When the usual DLL-sideloading playbook needs adjustment
Tighter archive scrutiny often increases analyst workload, so teams have to balance coverage against the volume of legitimate software bundles that also ship executables and companion libraries. The common mistake is treating every archive with a DLL as suspicious, which creates noise, while the opposite mistake is whitelisting trusted publishers and ignoring the directory where the DLL is actually loaded from. The load path is the deciding signal, not the presence of a signed binary by itself.
Guidance versus consensus also matters here. There is broad agreement that module path validation and process ancestry are high-value signals, but teams do not always agree on whether to enforce archive-blocking, quarantine on first sight, or alert-only workflows for unsigned companion DLLs. The right answer depends on whether the organisation can reliably observe extracted-file locations and whether endpoint telemetry includes task creation and image-load events. Where that visibility is weak, teams should treat archive-delivered sideloading as a containment problem as much as a detection problem, because missed module loads quickly become missed persistence.
Detection breaks down when the organisation cannot correlate extracted file placement with subsequent process execution, or when task and module-load telemetry is missing from the endpoint stack.
Risk and Threat Considerations
Archive-delivered sideloading is attractive to attackers because it blends trusted execution with untrusted content and can delay detection until after the initial launch. The material risk is not just code execution from a compressed archive, but the creation of a trusted-looking process path that hides malicious library loading and can enable persistence.
Failure mechanism: The attacker places a legitimate executable beside a malicious DLL, relies on DLL search order or application loading behaviour, and then uses the resulting process to load code from a user-writable directory. If the same chain also creates scheduled tasks or copies itself into a writable location, the compromise can survive the original archive being removed.
Impact: Defenders may see only a signed process and miss the injected or sideloaded module, allowing execution, persistence, and follow-on collection or lateral movement to continue from a host that initially looked low risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1218.011 — System Binary Proxy Execution: Rundll32 | Signed binaries loading malicious DLLs match proxy execution and sideloading behavior. |
| Recommendation — Hunt for trusted binaries loading unexpected libraries from writable paths and flag the execution chain. | ||
| CIS Controls v8 | 9 — Email and Web Browser Protections | Archive-delivered malware often enters through user-facing delivery channels and needs filtering. |
| Recommendation — Tighten attachment handling and quarantine suspicious archives before they reach execution. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Detection depends on observing process, module-load, and file activity as one chain. |
| RS.MI — Incident Mitigation | Containment requires isolating hosts and stopping further execution once sideloading is confirmed. | |
| Recommendation — Correlate file delivery, process ancestry, and module loads to detect sideloading in time. Isolate affected endpoints and block further execution from the suspicious directory. | ||
Practitioner Guidance
What to prioritise: Focus first on the module load path and process ancestry, because those two signals separate ordinary archive delivery from a real sideloading chain. If the executable is signed but the DLL comes from a writable user path, treat that as a containment-worthy event rather than a harmless packaging issue.
What to verify: Confirm that endpoint telemetry records archive extraction, image loads, and scheduled task creation before you trust your detection coverage. Teams often think they have visibility because they see process start events, but sideloading only becomes obvious when the loaded module path is visible as well.
Escalation / exception: Escalate quickly when the same host shows archive delivery, unexpected module loading, and self-copying or task creation in one chain. At that point, the question is no longer whether the archive was malicious in isolation, but whether the execution path has already established persistence.
Practitioner takeaway: The key judgement is to treat the signed executable as the lure and the module path as the proof; if you cannot see where the DLL came from, you cannot confidently say the archive is benign.
