How Attackers Masquerade and Abuse Digital Signatures in DLL Side-Loading
By: Dor Neemani and Dan Antonov
Overview
DLL side-loading is a long-standing technique leveraged by threat actors to execute malicious code under the context of trusted, digitally signed binaries. By abusing the Windows DLL search order, attackers can trick legitimate executables into loading their own malicious libraries instead of the intended system DLLs. This allows execution to appear legitimate and often bypasses application whitelisting, EDR heuristics, and user suspicion.
Infection Chain
The attack chain began with a phishing email linking to what appeared to be a .docx document. The downloaded “docx” was actually a ZIP archive containing multiple files, several flagged as Hidden and System. After extraction, these files remain invisible in File Explorer unless the user enables “Show protected operating system files”. This simple trick conceals the malicious components from casual inspection and sets the stage for the subsequent DLL side‑loading activity.
A similar sample has been analyzed in depth by researchers at SentinelOne[1], whose publication provides a thorough technical breakdown of the same attack chain.
Among the extracted files is a genuine Microsoft-signed winword.exe. The binary was renamed to resemble a legitimate document while keeping the original Word icon, giving it a benign appearance. Using a signed executable is intentional, it helps the attacker evade security controls that often trust or exclude digitally signed Microsoft binaries from intensive scanning. The large number of files within the archive further contributes to evasion, increasing the chance that security products overlook the relevant malicious components during extraction or initial inspection. Alongside it are several DLL files, including one named AppvIsvSubsystems64.dll, a library frequently seen in DLL side-loading attacks[2].
When the renamed Word binary runs, Windows resolves DLL dependencies by searching the application directory first. The attacker places a malicious AppvIsvSubsystems64.dll in that directory to ensure it is loaded in place of the legitimate system DLL. On execution, AppvIsvSubsystems64.dll locates the extraction path “_”. If present, the loader XOR‑decodes the filename of a designated file with behavior determined by a global flag: the code either performs a plain byte-wise XOR or executes an XMM/SIMD‑accelerated XOR sequence inline. The SIMD‑style code increases throughput and produces less regular instruction patterns, complicating static analysis. Only the filename is decoded; the file contents remain unchanged. The file “증거 보고서 - DA 성형외과.docx” (3 MB) is padded with “*” characters interleaved with ASCII bytes; the loader strips the padding and concatenates the remaining characters to reconstruct the command line for the next stage.
The package also contained a signed WinRAR executable that had been renamed and mislabeled with a .png extension to reduce suspicion. The adversary executed this binary to extract bundled payload files to disk, enabling subsequent staging and execution by the malicious loader.
One of the staged files was written to C:\Users\Public\Windows and named svchost.exe to suggest a legitimate Windows service host. In reality, the file is a Python interpreter binary and is digitally signed. The resulting name/icon mismatch, svchost.exe showing a Python icon, combined with the non‑System32 install path, defeats the masquerade and serves as a strong forensic indicator of malicious staging.
The Python payload is heavily obfuscated using a tool called PYMEOMEO, adding another layer of complexity and making static analysis more difficult.
Conclusion
This campaign highlights how threat actors continue to weaponize well-known techniques such as DLL side-loading and file masquerading to evade detection. The use of legitimate binaries and common file extensions further enhances the deceptive nature of these attacks, underscoring the need for advanced detection mechanisms beyond traditional signature-based approaches.
Fortinet Protections
FortiMail Workspace
FortiGuard Antivirus
FortiMail Workspace Security detects DLL side-loading delivery patterns using our advanced recursive unpacker, ensuring that hidden payloads are fully exposed and analyzed. Our HAP™ sandbox scans executables together with their entire archive content to detect such cases - identifying DLL side-loading behavior and blocking malicious files before they can reach the user.
IOCs
|
Name |
Value |
Description |
|
Copyright violation file.zip |
066d8670d26654cbb8cdeb9239df47278b4b6921a41b009ce64c925f63d7d4c9 |
Initial access ZIP |
|
מסמך_השוואת_תוכן_מפורט.zip |
5493f6e5744b7f2aece041bc08b010121c9f85ae6d505181443b7117b43706ed |
Initial access ZIP |
|
AppvIsvSubsystems64.dll |
406a6694eb5f377ad6be4750fc3cfde0528dd467274de21371fae01e9ada4562 |
DLL serving as Word dependency - side-loaded DLL |
|
AppvIsvSubsystems64.dll |
b0ecfe94a829ef82819a5bec168d313a55e07544c3e20e252239679b2e0f46c9 |
DLL serving as Word dependency - side-loaded DLL |
|
DA 성형외과 재무 보고서.pdf |
5096f1393dbd310532ed197d98a0858690e39326e423e2fcfbf18efbc389b7e7 |
Encoded Base64 PDF (zip file) |
|
DA 성형외과 재무 보고서.pdf |
7b3b379720cd827b5785fe246d60328b2239c63c55b35e7c7b0239716b1d7290 |
Encoded Base64 PDF (zip file) |
|
Invoice.pdf |
80d989484955f7cd5f7d5307561d23461d243d4a5018f78e01e39e4a20ac0a2c |
zip file |
|
images.png |
a5b19195f61925ede76254aaad942e978464e93c7922ed6f064fab5aad901efc |
python obfuscated payload |
References
[1] - Ghost in the Zip | New PXA Stealer and Its Telegram-Powered Ecosystem
