Many organisations make use of the Cisco ASA series of devices to provide their users with VPN connectivity. Usually it is configured through an ASA management application and users connect using the Cisco AnyConnect VPN Client.  There are a myriad of ways to provide authentication, with Google Authenticator, machine certificates and Active Directory integration being the most common.

Organisations often then direct their users to a URL such as https://vpn.organisation.com which will prompt them to download the latest version of the AnyConnect client.  It will also frequently provision a connection policy, determining various connection parameters and configurations.  These configuration files can often provide useful information such as the FQDN of the VPN connection point, as well as telling you exactly how the VPN connection will be authenticated.

Connection profiles and connection policies are stored in:

C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client

Depending on how old the implementation is, settings may also be stored in:

C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client

C:\Users\%username%\AppData\Local\Cisco\Cisco AnyConnect VPN Client\

C:\Users\%username%\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\

From examination of these files (which are editable by any user), you can determine whether certificates are in use, as well as which certificate store will be checked for the validity of that certificate.  The most recently used connection profile is saved as preferences_global.xml and can give you a further hint as to VPN endpoints or thumbprints of certificates:

<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectPreferences>
<DefaultUser></DefaultUser>
<DefaultSecondUser></DefaultSecondUser>
<ClientCertificateThumbprint></ClientCertificateThumbprint>
<ServerCertificateThumbprint></ServerCertificateThumbprint>
<DefaultHostName>vpn.organisation.com</DefaultHostName>
<DefaultHostAddress>123.123.123.123:443</DefaultHostAddress>
<DefaultGroup></DefaultGroup>
<ProxyHost></ProxyHost>
<ProxyPort></ProxyPort>
<SDITokenType>none</SDITokenType>
<ControllablePreferences></ControllablePreferences>
</AnyConnectPreferences>

The XML file also configures how the AnyConnect client is configured, such as allowing whether the user is allowed to accept unsafe certificates, connect to untrusted servers, or whether the user should be prompted to manually select from a list of valid certificates to connect with. Most interestingly, a user is able to change whether the VPN is always on, and what the TrustedDNS zones are. This is relevant as it determines whether the VPN is always on when the machine is remote, or whether it is deactivated should the machine be inside the corporate infrastructure.

Organisations will often use machine certificates to authenticate remote machines, as well as AD credentials or other second factor.  There is a tweak made in the ASA Connection Profile Editor that means that the Cisco AnyConnect Client is able to utilise Machine Store certificates (usually only visible to Administrators).  This  explains how unprivileged Domain Users are able to access Machine Store certificates to authenticate to their corporate network. The connection profile details how certificates are selected to be used for authentication (full documentation here and whether it should be an exact match, pattern match, string match or case match.  This can really help you target which exact certificate you need to target to allow you to authenticate to the corporate infrastructure remotely!

Having determined which certificate is being used by AnyConnect to authenticate, we now need to extract it so it can be imported into an attacker VM.  Certificates are often machine based, and as mentioned previously, this locks access to Administrators only.  A privesc to some form of Administrator on the target machine is required.

Assuming access to the machine as an Administrator has been gained, you may be able to use MMC to extract it cleanly.  However it is extremely likely that the sysadmin who developed the PKI solution also took the extra step of marking the certificate as non-exportable – so you will only end up with a .cer file rather than a .cer and a .pfx file.  Luckily, the extremely talented Gentilkiwi has developed a a solution in the form of Mimikatz’s crypto function.

Load Mimikatz using which AV-avoidance technique you chose, and enter the following (the initial commands amend settings to allow export of non-exportable certificates:

privilege::debug
crypto::capi
crypto::cng
crypto::stores /systemstore:local_machine /export

NB: If you omit the /systemstore:local_machine argument, Mimikatz will default to a CERT_SYSTEM_STORE_CURRENT_USER context, even if running as an Administrator or SYSTEM.

If the particular store that contains your target certificate is different, use the list here to help tweak your command.  Once exported you will notice two extra files in the current working directory, a .cer and a .pfx. You can exfiltrate this  across whatever C2 mechanism you are using (I’d suggest grabbing the Connection Profile and preferences_global.xml too so you can quickly configure your own AnyConnect installation on your attacker VM.

You can then import the stolen certificate into the requisite store in a disposable attacker VM.  The passphrase for the .pfx is mimikatz.   I had a few problems in the lab getting the VPN activated, with it failing after trying to get any requisite Connection Profile updates.  I found that manually grabbing the certificate from the VPN gateway, and installing that as a trusted certificate within my machine allowed the VPN connection to establish successfully.