Direct Access Pwned!

Tommy Abrahamsson bio photo By Tommy Abrahamsson


Background Info

We were tasked recently to review the security of Direct Access, in order to evaluate how difficult it was to gain unauthorized remote access to the corporate network by simply stealing a valid certificate. It was quickly clear to us, that simply grabbing a certificate and it’s corresponding private key wasn’t going to cut it, as Direct Access is really a complex beast. You need a lot of different ingredients, in order to gain unauthorized access. Luckily all of these ingredients are on the local endpoint…

Direct Access Primer

Before we begin exploring the gory details, let’s try and understand the Direct Access connection steps a bit better.

Key Technologies


Setting up Direct Access involves several technologies and components.

  • Active Directory Domain Controller
  • Public Key Infrastructure (PKI)
  • HTTPS server as Network Location Service (NLS)
  • Name Resolution Policy Table (NRPT)
  • IPv6 Tunneling technologies (IPHTTPS)
  • NAT64/DNS64

This blog post assumes IPHTTPS is the chosen tunneling technology, but other technologies can be chosen.

Step 1: TLS Handshake

Initial TLS handshake with the Direct Access server, validating the server certificate.


Step 2: Bring up the IPHTTPS Interface

Once the TLS session is established, the client will bring up the IPHTTPS interface for running IPV6 communications.


Step 3: Bring up the Infrastructure IPSEC Tunnel

Then we will begin building the first IPSEC tunnel, authenticating the tunnel using a combination of Computer certificate and the NTLMv2 creds of the computer account.


Step 4: Bring up the Intranet IPSEC Tunnel

The final and last step is to bring up the Intranet IPSEC tunnel, which is used for routing the actual traffic to internal resources. The authentication consists of computer certificate and user Kerberos creds.


Pwning Direct Access

So let’s begin.

Basically we need a valid DA machine, in order to steal all the ingrediens and a rogue box to import the ingredients.

It’s a bit out of scope for this post to define how to get access to a valid machine…

Step 1: Elevate to admin

If the machine in question doesn’t give you administrator privileges, you need to elevate your permissions. There are many ways to do that, again out of scope for this post.

Step 2: Turn off endpoint protection

Before begining to grab what is needed for stealing the identity of a valid user and computer, we need to turn off endpoint protection in order to avoid detection. So if this is Windows Defender, please just turn it off as you’re admin by now :)

Step 3: Export the computer certificate and key

Run Mimikatz and grab the public and private key of the computer certificate issued by the PKI:


But hang on…the private part of the certificate is defined as non-exportable, so this is impossible ! Well, copy the file to the rogue box and import using default certificate manager.

Step 4: Export the Kerberos tickets

Run Mimikatz and grab all valid Kerberos tickets, in order to perform a valid Pass The Ticket attack. There are some important tickets of course, but in this example we export and import all.

You need to export them as SYSTEM (hint: psexec -i -s cmd.exe)


Copy all the .kirbi files to the rogue box and import them as follows:


Before continuing, use klist to validate the Kerberos tickets are imported on the rogue box.

Step 5: Grab DA Config

Last but not least, we need the Direct Access Configuratoin files. You need to export the following:

  • Windows Firewall Policy (Connection Security Rules define the IPSEC)
  • IPHTTPS Interface Settings (netsh httpstunnel show interfaces)
  • Direct Access Policy Configuration (PowerShell: Get-DAClientExperienceConfiguration)
  • NCSI Policy Configuration (PowerShell: Get-NCSIPolicyConfiguration)
  • NRPT Policy Configuration (PowerShell: Get-DnsClientNrptPolicy)

Import the exported settings on the rogue box.

Step 6: Connect

Try to make some traffic, ie. dir \\domain\something

You should see the IPSEC getting established….


tada.wav :)


Wrap it up

What just happened ? Basically if you run Direct Access without OTP, you risk loosing all the ingredients to an attacker giving him full remote access to your infrastructure. It’s quite hard to detect without proper endpoint monitoring, as all the AD related events appear coming form a legitimate user / computer. Will you be able to find this rogue user/machine in the network with a SIEM ?

Enabling OTP in Direct Access seems to be a good idea, but I guess that was the reason why a lot of customers turned down the “classic” vpn client. So if you’re going “back” to OTP, then why not go with something simple which isn’t a design nightmare (see bonus info below).

Bonus: Unauthenticated ICMPv6 Attacks on DA

Even unauthenticated users can probe around the infrastructure, and an attacker can launch many IPv6 attacks on both the Direct Access Server and Clients.

Read more: