1. Global Protect Abuse 1/2
#globalprotect #redteaming #globalprotect #VPNabuse
Introduction
The motivation for this blog comes after attending a Mandiant social gathering in London. The presenter, Rohan (@Decode141), described how the VPN could be abused to join an attacker controlled machine on the target Network after initial access is achieved.
In this blog I will explore how we can abuse Palo Alto's Global Protect to achieve just that.
Pre-Requisites
Initial foothold is required
VPN configuration details
User Credentials
Initial foothold
For the sake of simplicity we will assume that we compromised a user and we have a sliver session on the target machine. Anything demonstrated below can be achieved using a C2 of your choice since most functionality comes from Beacon Object Files and C# executables.
User Credentials
Once we have a foothold on the target machine we could capture user credentials in a number of different ways. The easiest way is to just ask for them :) Let's see how that's done using sliver.
Armory offers a wide range of Beacon Object Files (bof) that are officially supported by sliver. Luckily for us c2tc-askcreds bof prompts the victim for their credentials.
When the command is executed the following prompt will appear on their desktop:
OneDrive.exe is specified from the bof. That could be anything but something that is relevant to the user would be ideal.
This is how it looks from the attacker's perspective:
Please note that this bof doesn't validate if the credentials are correct.
Global Protect Enumeration
GUI
The easiest way to obtain information regarding the VPN is through the client app installed on the host machine.
The portal login page can be identified by the settings button as shown below:
Potential gateways to connect to are identified in the Connection Tab:
Information on the Host Profile on the respective tab. That will help us identify what sort of endpoint configuration / hardening we will need prior to a connection to the target network. If the endpoint doesn't meet the minimum requirements it might be isolated from the target network even though a successful connection was established.
CLI
The PanGPA.log located at C:\Users\<username>\AppData\Local\Palo Alto Networks\GlobalProtect is very verbose and includes all the information needed to successfully create a remote connection.
User Certificate
In order to login into the paloalto portal we need a client certificate (this is not always the case). Let's find a few potential targets using shodan.
The GlobalProtect Portal Login page ends with "/global-protect/login.esp" so using google dorks or shodan we can identify multiple instances.
Let's take a look at the first example:
A message appears at the end of the page informing us that a valid certificate is required.
Another page found from shodan doesn't seem to have the same requirement.
Obtain the certificate from the victim
We can obtain the certificate from the host in a number of ways:
Using mmc through the GUI (low-priv user)
Using trustedsec's bofs (low-priv user)
Using mimikatz (requires elevated access)
Obtain Certificates through the GUI
We can quickly access user certificates by searching "Manage user certificates" on our host.
In this case we need the "Dave Daves" certificate to be exported in order to gain access to the VPN portal.
We can export the certificate by right clicking > All Tasks > Export...
In some cases depending on the ADCS configuration we might face the issue of not being able to export the private key of the certificate.
At this point we could use a tool like mimikatz to extract the private key. That would require patching certain functions in memory and admin privileges. Also executing mimikatz on a mature environment would probably set off a few alarms.
Alternatively we could request another certificate from the ADCS server with the export private key property being enabled.
That can be done by requesting a new certificate.
After clicking on Request Certificate with New Key the following window pops up:
Expand User Certificate details
Click On Properties
Navigate to the 'Private Key' Tab
Under Key Options, select Make private key exportable
We now have a second key that we are able to export.
In the following steps we will be asked to set up a password for the exported key and define the export directory. On an engagement instead of leaving the key lying around you can delete it once it's downloaded.
Obtain the certificate through the beacon
We could use tools such as Hidden Desktop to extract the keys as demonstrated before but it's not always possible. Thankfully the same result can be achieved using beacon object files without any GUI interaction.
Two bofs will be used to request the certificate:
sa-adcs-enum (I found this bof more reliable than using sa-adcs-enum-com. sa-adcs-enum-com would cause the sliver beacon to crash. I am not sure if that's the case with Cobalt Strike)
sa-adcs-enum will help us identify all the information needed to create a valid adcs request using remote-adcs-request.
sa-adcs-enum
This bof doesn't really require any arguments. We can just run this bof to enumerate the Certificate Authority and the template name required for the next step.
The first few lines will show all the information needed for the CA
From the above screenshot we can extract the name of the Certificate Authority CLAIRE-ALEX-DC-CA and the domain name is CLAIRE.local
The User template is the one required to authenticate to the VPN portal. Depending on the environment the template might have a different name .
remote-adcs-request
All we need now is to run the following command so the pirvate key and certificate will be dumped.
We can then copy the contents of the certificate to a file and convert it to a .pfx file using the following command.
Additional considerations before connecting to the portal
It is common nowadays to come across MFA authentication after logging in. The fact that we have foothold on the target machine we can get the user to authenticate for us. Let's take the number matching scenario demonstrated below:
The user is expected to use the number appearing on his screen, usually in a browser, and type it into their authenticator application.
In some cases authenticator will show more information such as the connection location. We might want to match the user's location to avoid adding to the victim's suspicion.
To overcome the MFA a small c# script was written. We can run from sliver or cobaltstrike to prompt the user with the number to match.
Attacker
The user is essentially running the c# executable within the beacon's process. The executable takes 2 arguments, the user's email and the and number to type into their authenticator.
Victim
The victim will see the pop up show up on his desktop. We then hope the user will authenticate for us.
In the second part of this blog we will go through the process of connecting to the VPN and possible hardening techniques we can apply on the Firewall to stop attackers from connecting to the VPN from a non corporate laptop.
Last updated
