Adversaries may execute their own malicious payloads by hijacking the search order used to load DLLs. Windows systems use a common method to look for required DLLs to load into a program. (Citation: Microsoft Dynamic Link Library Search Order)(Citation: FireEye Hijacking July 2010) Hijacking DLL loads may be for the purpose of establishing persistence as well as elevating privileges and/or evading restrictions on file execution. There are many ways an adversary can hijack DLL loads. Adversaries may plant trojan dynamic-link library files (DLLs) in a directory that will be searched before the location of a legitimate library that will be requested by a program, causing Windows to load their malicious library when it is called for by the victim program. Adversaries may also perform DLL preloading, also called binary planting attacks, (Citation: OWASP Binary Planting) by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL. Often this location is the current working directory of the program.(Citation: FireEye fxsst June 2011) Remote DLL preloading attacks occur when a program sets its current directory to a remote location such as a Web share before loading a DLL. (Citation: Microsoft Security Advisory 2269637) Phantom DLL hijacking is a specific type of DLL search order hijacking where adversaries target references to non-existent DLL files.(Citation: Adversaries Hijack DLLs) They may be able to load their own malicious DLL by planting it with the correct name in the location of the missing module. Adversaries may also directly modify the search order via DLL redirection, which after being enabled (in the Registry and creation of a redirection file) may cause a program to load a different DLL.(Citation: Microsoft Dynamic-Link Library Redirection)(Citation: Microsoft Manifests)(Citation: FireEye DLL Search Order Hijacking) If a search order-vulnerable program is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation from user to administrator or SYSTEM or from administrator to SYSTEM, depending on the program. Programs that fall victim to path hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace.
Adversaries can take advantage of insecure library loading by PowerShell to load a vulnerable version of amsi.dll in order to bypass AMSI (Anti-Malware Scanning Interface) https://enigma0x3.net/2017/07/19/bypassing-amsi-via-com-server-hijacking/
Upon successful execution, powershell.exe will be copied and renamed to updater.exe and load amsi.dll from a non-standard path.
Supported Platforms: Windows
auto_generated_guid: 8549ad4b-b5df-4a2d-a3d7-2aee9e7052a3
1
command_prompt
! Elevation Required (e.g. root or admin)copy %windir%\System32\windowspowershell\v1.0\powershell.exe %APPDATA%\updater.exe
copy %windir%\System32\amsi.dll %APPDATA%\amsi.dll
%APPDATA%\updater.exe -Command exit
del %APPDATA%\updater.exe >nul 2>&1
del %APPDATA%\amsi.dll >nul 2>&1
.NET components (a couple of DLLs loaded anytime .NET apps are executed) when they are loaded they look for an environment variable called APPX_PROCESS Setting the environmental variable and dropping the phantom WinAppXRT.dll in e.g. c:\windows\system32 (or any other location accessible via PATH) will ensure the WinAppXRT.dll is loaded everytime user launches an application using .NET.
Upon successful execution, amsi.dll will be copied and renamed to WinAppXRT.dll and then WinAppXRT.dll will be copied to system32 folder for loading during execution of any .NET application.
Supported Platforms: Windows
auto_generated_guid: 46ed938b-c617-429a-88dc-d49b5c9ffedb
1
command_prompt
! Elevation Required (e.g. root or admin)copy %windir%\System32\amsi.dll %APPDATA%\amsi.dll
ren %APPDATA%\amsi.dll WinAppXRT.dll
copy %APPDATA%\WinAppXRT.dll %windir%\System32\WinAppXRT.dll
reg add "HKEY_CURRENT_USER\Environment" /v APPX_PROCESS /t REG_EXPAND_SZ /d "1" /f
reg delete "HKEY_CURRENT_USER\Environment" /v APPX_PROCESS /f
del %windir%\System32\WinAppXRT.dll
del %APPDATA%\WinAppXRT.dll
Re-starting the Print Spooler service leads to C:\Windows\System32\ualapi.dll being loaded A malicious ualapi.dll placed in the System32 directory will lead to its execution whenever the system starts
Upon successful execution, amsi.dll will be copied and renamed to ualapi.dll and then ualapi.dll will be copied to system32 folder for loading during system restart. Print Spooler service is also configured to auto start. Reboot of system is required
Supported Platforms: Windows
auto_generated_guid: 5898902d-c5ad-479a-8545-6f5ab3cfc87f
1
command_prompt
! Elevation Required (e.g. root or admin)copy %windir%\System32\amsi.dll %APPDATA%\amsi.dll
ren %APPDATA%\amsi.dll ualapi.dll
copy %APPDATA%\ualapi.dll %windir%\System32\ualapi.dll
sc config Spooler start=auto
del %windir%\System32\ualapi.dll
del %APPDATA%\ualapi.dll