
In this post
- Introduction
- FudCrypt
- HijackLibs submissions
- Finding side-loading opportunities at home
- Spotting side-loading in the wild
Introduction
In incident response I’ve seen Warzone RAT, SecTop RAT, PlugX, and ransomware actors use legitimate Windows applications to load malicious DLLs. The EXE looks ordinary; the DLL it loads carries the malicious code.
With DLL side-loading, a vulnerable EXE is copied into a writable folder alongside a DLL bearing the name it expects. When the EXE runs, it may load that DLL. Other routes include a missing DLL the application tries to load (phantom DLL hijacking), a malicious copy found earlier in Windows’ search order, or a search path redirected through an environment variable. HijackLibs documents these variations.
FudCrypt
I dissected FudCrypt’s builder and found 20 carrier EXE/DLL combinations it could produce, pairing malicious DLLs with carrier EXEs, including legitimately signed ones. These were profiles in a working crypter. None appeared in HijackLibs when the analysis was published, so I submitted them. The write-up is now cited on the version.dll and winmm.dll pages.
What made it into HijackLibs
Six HijackLibs DLL entries credit me and list 56 DLL/EXE combinations between them. I wrote two Sigma rules too. Some findings were mine; others came from researchers I supported, so the 56 includes work on shared entries.
Direct submissions
Microsoft version.dll — 42 combinations
I submitted combinations for version.dll. Chris Spehn and an0n are also credited.
agentservice.exe, certutil.exe, choice.exe, clip.exe, cmstp.exe, cofire.exe, cscript.exe, diskpart.exe, diskraid.exe, dism.exe, driverquery.exe, forfiles.exe, fxssvc.exe, ie4ushowie.exe, iexpress.exe, msconfig.exe, mstsc.exe, openfiles.exe, presentationhost.exe, psr.exe, RelPost.exe, sfc.exe, sigverif.exe, systeminfo.exe, taskkill.exe, tasklist.exe, timeout.exe, unregmp2.exe, verifiergui.exe, vsgraphicsdesktopengine.exe, waitfor.exe, wextract.exe, where.exe, whoami.exe, winsat.exe, wscript.exe, Zoom.exe, icardagt.exe, Microsoft.SharePoint.exe, IObitUnlocker.exe, CCleanerBugReport.exe, CiscoCollabHost.exe.
Microsoft winmm.dll — 9 combinations
I submitted combinations for winmm.dll. Wietze and Chris Spehn are also credited.
mblctr.exe, mspaint.exe, mstsc.exe, osk.exe, presentationsettings.exe, proximityuxhost.exe, wfs.exe, winsat.exe, Zoom.exe.
Submissions I’ve supported
I helped the researchers below find or submit four DLL entries covering five DLL/EXE combinations.
| DLL | Executable | Researchers I supported |
|---|---|---|
Ahnenblatt cc32290mt.dll | Ahnenblatt4.exe | Amelia Casley, Faith Stratton |
CheckMAL mfc140u.dll | AppCheck.exe | Jai Minton |
Flexera fnp_act_installer.dll | TSConfig.exe, ISDbg.exe | Jai Minton |
VMware libcrypto-3-x64.dll | vmware-vmx.exe | Harry Godridge |
I wrote two Sigma rules for Ahnenblatt: one for suspicious cc32290mt.dll image loads, the other for suspicious file writes.
Finding side-loading opportunities at home
While checking registered URI handlers, I found Black Desert Online’s pearlabyss-bdo-NA: handler launched BlackDesertLauncher.exe. The URI itself led nowhere, but the launcher requests elevation and imports VERSION.dll by name. With no local copy present, it loaded mine beside the EXE, both in the game folder and in a separate demo folder.
The launcher is 32-bit and imports three functions from VERSION.dll, so I built an x86 proxy with those exact exports:
LIBRARY VERSION
EXPORTS
GetFileVersionInfoSizeW=ProxyGetFileVersionInfoSizeW
GetFileVersionInfoW=ProxyGetFileVersionInfoW
VerQueryValueA=ProxyVerQueryValueA
Each proxy keeps the WINAPI signature and forwards the call via GetProcAddress to the real version.dll, loaded by full path from the Windows system directory. A thread started on DLL attach shows the MessageBoxW popup. I built and placed the DLL beside the launcher:
cl /LD /Fe:VERSION.dll version_popup.c /link /DEF:version_popup.def
Copy-Item .\VERSION.dll 'C:\Pearlabyss\BlackDesert\VERSION.dll'
Launching BDO brought up the popup:
Spotting side-loading in the wild
I’ve seen side-loading used for initial access, persistence, and disabling defences. I start with what launched the EXE, its path, and the DLL it loaded.
Initial access
I’ve seen Warzone RAT delivered in a ZIP with a .lnk posing as a PDF. The shortcut ran a renamed EXE in the same folder, which loaded the malicious DLL beside it. Tracing the alert back to that shortcut exposed the chain.
Persistence
I’ve seen IDAT Loader persist through scheduled tasks, Startup shortcuts, and registry autoruns that launch renamed EXEs. I check the task action, shortcut target, or registry value, then the EXE’s path and DLL loads. The copied EXE in an unusual folder is often the giveaway.
Defence impairment
I’ve seen ransomware operators use security vendor EXEs to load malicious DLLs and disable EDR. Amelia Casley’s SentinelOne example shows why the DLL and launch path matter more than the EXE’s name. A security process deleting shadow copies or disabling backups is already a serious indicator.
Anna (@PandaRE__) shared a tip for finding a malicious proxy DLL among many files.
Spotting a side-load is often the easy part. With so many documented and undocumented EXE/DLL combinations, trying to detect every pair becomes a cat and mouse game. The launch chain, file paths, and what the process does next give me more to work with.