Skip to main content

Summary

Last year, I researched a Windows DLL hijack behavior that a handful of adversaries were observed using in the wild, involving undocumented/nonexistent DLLs on Windows hosts. I observed this bypass leveraged by primarily APAC adversaries, namely the LAZARUS GROUP and APT41. Both groups appear to have the dual purpose of cyber espionage and nation-state financing. The Lazarus Group is attributed to the Democratic People’s Republic of Korea (DPRK), and APT41 is believed to be a Chinese state-sponsored group. For more information on the Lazarus Group’s foray into macOS, please reference my other research on Transparency, Consent, and Control (TCC) Database Manipulation.

This sub-technique will be included in the next MITRE ATT&CK Release scheduled for April 2024.

Intro

To the chagrin of Windows security practitioners everywhere, the Windows operating system (OS) references a surprising number of DLL files that do not exist. Thus, phantom DLL hijacking occurs when the adversary names their malicious DLL to match the non-existent file and writes it to the specified location of one these referenced missing files. This DLL is then loaded when the OS executes the code that references that file, typically by leveraging the API Call LoadLibrary, resulting in resulting in possible privilege escalation, persistence, malicious execution, etc.1

There are a ton of “phantom” DLLs that exist, and undoubtedly, some remain to be discovered and exploited 4, but for my research I focused on the following two examples:

Writing to TCC.db

IKEEXT is the service responsible for Internet Key Exchange (IKE) and Authenticated Internet Protocol (AuthIP) keying modules. These keying modules are needed for authentication and key exchange within Internet Protocol security (IPsec). Upon start, IKEEXT will attempt to load C:\Windows\System32\wlbsctrl.dll, which does not exist, and the SessionEnv service will then attempt to load TSMSISrv.dll and TSVIPSrv.dll (both of which also do not exist) from %System32%. Therefore, adversaries may drop their malicious, aptly named DLLs into %System32%, restart these two services, and successfully perform phantom DLL hijacking. 5

In the wild, the Lazarus Group was observed dropping their malicious DLL to disk, which they consequently rename to wlbsctrl.dll and write to %System32%. Thereafter, they use WMI to interactively restart the IKEEXT service. APT41 has similarly hijacked wlbsctrl.dll via restarting the IKEEXT service, in addition to hijacking TSVIPSrv.dll.

WMIprvse.exe

Another example of phantom DLL hijacking targets wmiprvse.exe, aka the Windows Management Instrumentation (WMI) provider host.  When wmiprvse.exe executes, it will look for wbemcomn.dll in the C:\Windows\System32\wbem\ folder. Lo and behold, since the DLL does not exist in that folder, adversaries may once again drop their malicious, aptly named DLL into that folder, hijacking execution.8

APT41 has been observed writing their malicious wbemcomn.dll to C:\Windows\System32\wbem\ to establish persistence.

Recommendations and Best Practices

It is highly recommended to deploy an enterprise monitoring solution (EDR, SIEM) that is able to monitor file writes and hunt for these non-existent DLLs. Programs like sxstrace may also be helpful in monitoring files and inspecting manifest files for side-by-side problems in software. A proactive application control solution could also block unsanctioned DLLs loaded by native Windows binaries. Additionally, block remote loading of DLLs, which is a feature included by default in Windows Server 2012+ and by patch for XP+ and Server 2003+.

Threat Hunting for DLL Hijacking

  • Monitor for module loads: monitor DLLs loaded into a process and detect DLLs that have the same file name but abnormal paths
  • Use process monitoring applications such as Procmon to monitor for processes with “NAME NOT FOUND,” and the type of file being a DLL, and the user executing the process as SYSTEM to identify possible DLLs used for phantom DLL hijacking
  • Look for the usual suspects: monitor for newly written DLLs to possible staging directories like %temp% or %appdata%2
  • Monitor for any changes to the following:
    • .manifest or .local redirection files
    • File systems for moving, renaming, or modifying DLLs
    • Renaming of any DLL to any non-existent DLL being written to %System32% such as dll, TMSISrv.dll, TSVIPSrv.dll
    • Renaming of any DLL to dll and being written to C:\Windows\System32\wbem
Close Menu