High

Analysis Summary

A highly sophisticated DLL sideloading campaign targets Microsoft OneDrive by placing a weaponized version.dll alongside OneDrive.exe, abusing Windows’ DLL search order so the application loads the malicious library from its local directory before the legitimate System32 copy. Because OneDrive is a trusted, digitally signed Microsoft binary, code executed in its process inherits a high-trust context that helps attackers bypass process-based and signature-focused security controls. The malicious DLL is crafted to mimic the real library’s exports so normal functionality remains intact and users or defenders see no obvious application breakage.

To preserve normal behavior while running malicious logic, the adversary implements DLL proxying: exported functions are forwarded to the original System32 version.dll so legitimate calls succeed, while the proxy also performs background malicious tasks. This dual-path design ensures OneDrive continues to operate normally, reducing user suspicion and limiting heuristic alarms. The malicious DLL typically spawns a separate thread so payloads run asynchronously and do not block application initialization; spawned processes have their windows hidden to maintain covert operations.

The campaign’s stealth is heightened by an advanced hooking method that avoids straightforward inline patches: attackers use Vectored Exception Handling combined with the PAGE_GUARD memory protection flag to intentionally trigger and catch exceptions when target APIs (for example, GUI or window-creation calls such as CreateWindowExW) are invoked. By intercepting execution through exception handlers and then re-arming hooks via single-step exceptions, the attacker redirects control flow to attacker-controlled routines without leaving persistent code modifications that many signature-based detectors look for. This exception-driven hooking is effective precisely because it minimizes static artifacts and operates at runtime in a way that resembles legitimate exception handling.

Defensive measures should therefore focus on behavior and provenance rather than solely on static signatures: enforce application whitelisting and least-privilege execution for trusted binaries, monitor and alert on unusual DLL load paths (applications loading DLLs from local or user-writable directories), and validate digital signatures of loaded libraries at runtime. Additional controls include monitoring for anomalous process creation and hidden-window child processes, using EDR rules to flag unusual use of vectored exception handlers or PAGE_GUARD manipulations, and applying integrity checks or allowlisting for critical libraries to reduce the effectiveness of DLL proxying and sideloading.

Impact

• Gain Access
• Code Execution

Remediation

• Enforce application allowlisting (AppLocker or WDAC) to prevent unsigned or unapproved DLLs from loading with trusted binaries.
• Restrict write permissions to application directories (e.g., OneDrive install folder) so non-admin users and processes cannot drop DLLs beside executables.
• Deploy least-privilege for user accounts and services — avoid running user workloads with local admin rights.
• Keep OS and OneDrive (and other applications) fully patched to reduce known DLL-related weaknesses.
• Validate digital signatures for DLLs at load time where possible (enable code-integrity checks or use EDR features that validate Authenticode).
• Enable Sysmon and monitor Image loaded events (Sysmon Event ID 7) for suspicious DLLs loading from non-standard locations (user-writable folders, app install dirs).
• Create EDR/AV alerts for processes loading DLLs from the same directory as a signed Microsoft binary (local-directory DLL loads).
• Alert on unusual uses of Vectored Exception Handling (VEH) and repeated PAGE_GUARD manipulations — these are strong indicators of exception-based hooking.
• Monitor for process creation with hidden/hidden-window flags and parent-child relationships where a trusted binary spawns unknown executables.
• Log and alert on modifications to System32\version.dll or attempts to proxy/forward functions (file replacement or shadow DLLs).
• If suspicious DLL sideloading is detected: isolate the host, collect memory and full process image, and capture DLL and executable files for offline analysis.
• Use process memory dumps to detect in-memory hooks and identify vectored exception handler chains.
• Hunt for persistence artifacts (scheduled tasks, services, Run keys, .lnk files) created around the same time as the malicious DLL drop.
• Revert affected binaries to known-good copies, remove malicious DLLs, and validate file integrity (hashes) before reconnecting hosts to the network.
• Implement file integrity monitoring (FIM) for application folders and System32 to detect unauthorized DLLs or proxy libraries.
• Enforce secure software deployment pipelines and digital signing policies so only approved builds are installed on endpoints.
• Maintain a whitelist of allowed DLL names and their expected hashes for critical apps (or use vendor-provided allowlists).
• Include DLL sideloading techniques in tabletop exercises and incident playbooks so SOC/IR teams know the workflow.
• Rule: alert when a Microsoft-signed executable (OneDrive.exe) loads a DLL from a user-writable path.