Logo
RSS Feed

👈🏼 Back to
Persistence and Escalation Mechanisms

Library Abuse

Created: 03.06.2023

Windows

DLL Search Order Hijacking

👑 - require w permissions for Windows and Windows\System32.

Detection:

  1. 💭 unusual locations for new DLL created or saved during the attack (especially unsigned)
  2. 💭 see RAM for DLLs loaded from the wrong locations
  3. 💭 multiple locations for one DLL
  4. 💭 behavioural analysis (C2C or other)
  5. 🛠️ https://github.com/adamkramer/dll_hijack_detect/releases
  6. IDS/IPS
  7. Integrity controls?

Example: eplorer.exe loading ntshrui.dll.

Following is the search order for modern Windows systems:

  1. Manifest (if the application provides an absolute path to the dll)
  2. RAM
  3. SxS
  4. KnowDLLs list HKLM\SYSTEM\CurrentControlSet\Control\WOW or HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs ([docs](KnowDLLslistHKLM\SYSTEM\CurrentControlSet\Control\WOW`)). So, if the dll is in the list, the link from the registry is used, and there is no search conducted.
  5. Application’s loading directory
  6. C:\Windows\System32
  7. C:\Windows\system
  8. C:\Windows
  9. Application’s registered App Paths directories ❓/ Current directory
  10. %PATH% env variable

❗️ If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path. [1] So, that means that we can make a side-loading attack on “a side-loaded dll”!

❓Not sure about the different paths specified for the KnowDlls entries. This might be due to the different OS versions. See here:

For 16-bit apps, Windows NT uses KnownDLLs to implicitly and explicitly load DLLs. The value is at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WOW. At this key, KnownDLLs is a type REG_SZ value which lists the 8.3 DLL names, separated by spaces. Without a KnownDLLs entry, WOW searches:

  1. The current directory.
  2. The %SystemRoot% directory.
  3. The %SystemRoot%\SYSTEM directory.
  4. The %SystemRoot%\SYSTEM32 directory.
  5. The .exe file directory.
  6. The directories in your Path environment variable.

With the KnownDLLs entry, WOW only searches the %SystemRoot%\SYSTEM32 directory.

The order also depends on the SafeDllSearchMode (🔑 HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode). Here is the quote from the docs:

If SafeDllSearchMode is enabled ✅, the search order is as follows:

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. No function obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. >5. The current directory.
  5. The directories are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If SafeDllSearchMode is disabled ⛔️, the search order is as follows:

  1. The directory from which the application loaded. > 2. The current directory.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. No function obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

Phantom DLL hijacking

An executable is trying to load a very old dll, even though it’s superfluous. Some don’t even exist anymore, for example, fxsst.dll (fax service). The attacker creates a DLL with the same name and some nefarious functionality.

📚 Further Reading:

  1. forrest-orr.net/post/malicious-memory-artifacts-part-i-dll-hollowing
  2. https://resources.infosecinstitute.com/topic/dll-hijacking-attacks-revisited/

DLL Side-by-side loading (SxS)

Side-by-side loading (SxS) mechanism to introduce updated versions of DLL. It can be used to circumvent anti-virus. Example: PlugX RAT. Legitimately signed exe uses SxS to load a malicious dll. The attacker puts a nefarious dll somewhere down the road to ensure it’s loaded instead of a legitimate one.

📚 Further Reading:

  1. https://www.bitdefender.com/blog/businessinsights/tech-explainer-what-is-dll-sideloading/
  2. https://www.mandiant.com/resources/reports/dll-side-loading-thorn-side-anti-virus-industry

Relative Path DLL Hijacking

The attacker discovers vulnerable executable files (ones that use relative paths to DLLs) and creates a malicious DLL to replace the legitimate one. Afterwards, they duplicate that executable and place it in the same directory as the malicious DLL. When that executable is launched, it will load the DLL living side by side rather than the legit one from a system directory.

Detection:

  1. 📂 Unusual locations for known libraries (especially, unsigned)
  2. 📂 Duplications

macOS

Dylibs Environment Variables

DYLD_*
DYLD_INSERT_LIBRARIES # all libs from this env will be loaded
DYLD_FRAMEWORK_PATH

These libraries are loaded within a trusted host process, not resulting in a new process.

A plist for launch item - EnvironmentVariables. For application - LSEnvironment (Info.plist).

Proxying

Hijacking

References

Expand… Something here