Skip to content
Go back

Dude, Where's My DLL?

Dude, Where's My DLL? banner

In this post

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.

DLLExecutableResearchers I supported
Ahnenblatt cc32290mt.dllAhnenblatt4.exeAmelia Casley, Faith Stratton
CheckMAL mfc140u.dllAppCheck.exeJai Minton
Flexera fnp_act_installer.dllTSConfig.exe, ISDbg.exeJai Minton
VMware libcrypto-3-x64.dllvmware-vmx.exeHarry 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:

BlackDesertLauncher.exe loading a local VERSION.dll, showing the popup, with the PoC window visible in the process view

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.


Share this post on:

Previous Post
Crosshair X URI to Code Execution via SVG Injection
Next Post
The Chrome Extension Economy, and How Trust Gets Hijacked