- Blog articles related to hacking are only for informational and educational purposes. Any time the word “hacking” is used on this site, it shall be regarded as Ethical Hacking. You may try out these hacks on your own computer at your own risk. Performing hack attempts (without permission) on computers that you do not own is a serious crime under federal law.
- Refer to the laws in your province/country before accessing, using, or in any other way utilizing these materials. These materials are foreducational and research purposes only.
- Any actions and or activities relating to the material contained within this website is solely your responsibility. The misuse of the information in this website can result in criminal charges brought against the persons in question. The author and Winmill Software 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.
Introduction (Pen Test vs. Vulnerability Scan)
In this demonstration we leverage a Server-Side Request Forgery (SSRF) vulnerability, and then abuse the privileges of two users to access the root system of the server. If we had only performed a vulnerability scan on the target, we probably would have detected the SSRF vulnerability as a high or medium issue, and then been given some remediation options. End of story. Only a skilled penetration tester or red-team operator will be able to reveal the different ways that the vulnerability could be used as part of an attack chain to gain full control of the system.
Server-Side Request Forgery (SSRF) flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidences of SSRF attacks are increasing. Also, the severity of SSRF threats is rising because of cloud services and architecture complexity.
In this demonstration, we will leverage an SSRF vulnerability to retrieve an NTLMv2 handshake via Responder. We’ll then abuse the privileges of two users to obtain write permissions on the C:\Windows\system32\utilman.exe binary and trigger system-integrity execution via Remote Desktop Protocol (RDP).
We begin our enumeration with a simple Nmap all-ports scan (Figure 1):
There are many open ports on the target. The port numbers and banners indicate that this is most likely a Windows host. We’ll focus on the HTTP service running on port 8080. We scan for more details (Figure 2).
sudo nmap -vv –n –Pn -A –p8080 192.168.72.165
A quick online search of “Werkzeug” reveals that this is likely a Flask web application. Flask is a Python web framework that helps developers create web applications using the Python language.
Visiting the web app on port 8080, we are presented with a URL input form labeled “Super Secure Web Browser” (Figure 3).
curl http://192.168.72.165 (“curl” stands for “client URL,” which lets developers transfer data to and from a server).
Since the form is expecting a URL, let’s see if we can make it reach out to our attacking machine by supplying our IP address. We’ll note that the GET variable for the URL is named “URL.”
First, we’ll start our handy Python3 web server with sudo python3 -m http.server 80 (Figure 4).
We send our request, supplying the address of our machine in the URL parameter (Figure 5).
We look at our web server and we see a request from the target (Figure 6).
Server-Side Request Forgery (SSRF)
Server-side request forgery (SSRF) is a web security vulnerability that allows us to induce the server-side application to make HTTP requests to an arbitrary domain of our choosing. Seeing that this is a Windows target, we will attempt to steal an NTLMv2 handshake via responder, leveraging the SSRF vulnerability. We’ll begin by running responder on our active network interface. In this case, the interface is tun0 (Figure 7).
With Responder listening, we resend our request.
After the request is sent, the responder receives the NTLMv2 handshake with a password hash (Figure 8).
We save the hash in file hash.txt and run John the Ripper with the rockyou.txt wordlist. Almost instantly we crack the hash (Figure 9).
Since our Nmap scan showed the port 3389 open, we could try logging in via a remote desktop protocol (RDP) using rdesktop. Unfortunately, that does not seem to work. Another approach is to utilize Windows Remote Management as we saw the port 5985 open as well. We’ll use the Evil-Winrm tool for this (Figure 10).
Inside the C:\Users\enox\Desktop directory, we find a file todo.txt. Just as expected, it contains a list of remaining items for the developers to implement (Figure 11).
The item Migrate to apache is not marked as DONE (Figure 12). Seeing how the web application is running as a local user enox, we can venture a guess that the developers are intending to change the application to run under the context of a service account instead. Let’s see what other users exist on this system (Figure 13).
We find the account svc_apache$. Judging by the trailing $ character, we know that this is a service account and probably the same account the developers are intending to use. Let’s see what groups this account belongs to.
We’ll also check what groups our user is in (Figure 14).
The account we have taken over is in the Web Admins group. We can venture an educated guess that we might have some power over the Apache service account (Figure 15).
Group Managed Service Accounts (GMSA)
Group Managed Service Accounts provide a higher security option for non-interactive applications, services, processes, or tasks that run automatically but need a security credential. These service accounts are assigned automatically generated passwords. Given certain permissions, it is possible to retrieve these password hashes from Active Directory. To see what users or groups have permissions to do that for a given service account, we can look up the PrincipalsAllowedToRetrieveManagedPassword user property on the account (Figure 16).
Nice! It looks like we have the ReadGMSAPassword privilege over the svc_apache$ service account (Figure 17).
Retrieving the ReadGMSAPassword Hash
To retrieve the hash, we’ll use a publicly available tool GMSAPasswordReader. Let’s download it from GitHub to our attacking machine (Figure 18).
We can now upload it to the target using our WinRM shell, and then execute it against the svc_apache$ user (Figure 19).
Great! The tool retrieved the current RC4 HMAC of the password as 9C5B09584D21E5CFE41609623A78B8E8.
Pass the Hash Attack
Next, we’ll attempt to perform a pass the hash attack using evil-winrm to authenticate as svc_apache$ with the recovered hash. The attack is successful, and we have taken over this service account as well (Figure 20).
Checking this account’s privileges, we discover that the account has the SeRestorePrivilege permission (Figure 21).
The SeRestorePrivilege privilege allows a user to circumvent file and directory permissions when restoring backed-up files and directories, thus giving the user read and write access to system files.
We will use the EnableSeRestorePrivilege.ps1 script to enable this privilege in our PowerShell session. Let’s begin by downloading it to our attacking machine (Figure 22).
We upload the module and execute on the target (Figure 23).
Utilman.exe Abuse with RDP
Utilman.exe is a built-in Windows application that is designed to allow users to configure system accessibility options such as the Magnifier, High Contrast Theme, Narrator, and On-Screen Keyboard before they log in to the system.
This application is triggered by issuing the WIN + U key combination while on the Windows logon screen. It’s important to note that the application runs with SYSTEM privileges. We can leverage our write access in the system directory C:\Windows\System32 to replace utilman.exe with cmd.exe (Figure 24).
We trigger the application using rdesktop and get a SYSTEM shell on the server. We own the server! (Figure 25).
In this demonstration we leveraged an SSRF vulnerability to retrieve an NTLMv2 handshake via Responder, we then abused privileges of two users to obtain write permissions on the C:\Windows\system32\utilman.exe binary and triggered system-integrity execution via Remote Desktop Protocol.
As we mentioned earlier, if we had only performed a vulnerability scan on the target, we probably would have detected the SSRF vulnerability as a high or medium issue. Some remediation options would have been presented, and that would have been that. Only a skilled penetration tester or red-team operator has the ability to uncover the different ways in which the vulnerability could be used as part of an attack chain, giving the bad actor full control of the system.
Don’t let vulnerability scans give you a false sense of security with their limited scope. Schedule your penetration test today!