DLL Side-Loading
Last updated
Last updated
Adversaries may execute their own malicious payloads by hijacking the library manifest used to load DLLs.
Adversaries may take advantage of vague references in the library manifest of a program by replacing a legitimate library with malicious one, causing the operating system to load their malicious library when it is called for by the victim program.
Program may specify DLLs that are loaded at runtime. Programs that improperly or vaguely specify a required DLL may be open to a vulnerability in which an unintended DLL is loaded. Side-loading vulnerabilities specifically occur when Windows Side-by-Side (WinSxS) manifests are not explicit enough about characteristics of the DLL to be loaded. Adversaries may take advantage of a legitimate program that is vulnerable by replacing the legitimate DLL with a malicious one.
Adversaries likely use this technique as a means of masking actions they perform under a legitimate, trusted system or software process.
Windows, like many operating systems, allows applications to load DLLs at runtime. Applications can specify the location of DLLs to load by specifying the location of DLLs to load by specifying a full path, using DLL redirection, or by using a manifest. If none of these methods are used, Windows attempts to locate the DLL by searching a predefined set of directories in a set of order.
Example:
I will work on the Winamp Program again, this time I won't be replacing any DLL files to load my payload but here I will be tricking the Program into load my DLL payload, usually to achieve this we would need a .manifest file to be modified and to point to our payload but here we will modify a legit DLL and add a "proxy DLL" to execute our payload and send the legitimate calls to the legit DLL as well. So here execution wouldn't even fail!
First we will search for a proper DLL, according to the hints the smaller the better. I will use Procmon again as well and search for a proper file that has a SUCCESS Result.
My victim is the nsutil.dll, usually we want to target files that have user-land access but in these situations most likely you will encounter a situation where Administrator Privileges are required.
Will grab nsutil and place it on the same folder as our payload.dll file and have a work from this awesome tool DLLSideLoader.
Will Import the PS1 Script onto our PowerShell Session and run the following syntax, if everything runs correctly you should see something like this:
Something I had troubles when using this method is I wasn't paying attention to the architecture of the software, I was mainly building my payload for a 64 Bit PC as this was my targeted machine, but in this situation we are targeting the program not the OS.
Will grab all of these files (payloadx86.dll, nsutil.dll and tmp2D86.dll and replace them where our legitimate program is located.
Once winamp is executed the nsutil will call tmp and proxy the execution onto our payloadx86 and move back to the legitimate calls so our program won't crash but we will also receive our reverse shell. (This is a Hit or Miss I managed to get it working sometimes and sometimes it wouldn't even open but will always receive a shell no matter the location of the binary as long as they were in the same location with the files)
Or we can also execute without having all of this replaced they can run in the same folder as long as these files are all together (remember dll hijacking the order it follows)
The same result for both situations.
##################################################################################################
References:
