Server Authentication: The neglected area of Active Directory Certificate Services (ADCS)

Reading Time: 9 Minutes

This article is written by Ofir Hamam

Introduction

Active Directory Certificate Services (ADCS) exploitation has been a focal point for several years, ever since SpecterOps introduced the “Certified Pre-Owned” white paper in 2021. Since then, ADCS misconfigurations have become a staple in every attacker’s toolbox. Periodically, new methods and misconfigurations emerge, enabling attackers to achieve full domain compromise.

On the defensive side, organizations have recognized the significant risks posed by ADCS and responded by hardening misconfigured certificate templates. The primary focus has been on templates that allow Client Authentication, given their potential to facilitate credential abuse and privilege escalation.

However, while much attention has been directed toward Client Authentication templates, Server Authentication templates have often been overlooked, leaving them vulnerable to exploitation.

In this blog post, the author explores how attackers can leverage Server Authentication templates to compromise networks and why hardening these templates is just as critical to an organization’s security posture.

The Why?

When it comes to client authentication templates, we know they can be exploited to obtain valid and persistent credentials for highly privileged identities, such as Domain Admins or Domain Controllers. However, their utility is significantly diminished without continuous network access.

To understand why Server Authentication templates are just as dangerous, it’s important to provide some context. Today, organizations treat their internal networks as secure zones. They’ve invested heavily in protecting entry points using firewalls, VPNs, and robust cloud security solutions. Physical security measures have also evolved, making it increasingly challenging to breach an organization’s internal network.

But what if, instead of targeting users in these highly fortified environments, we shift our focus to less secure ones? Think of coffee shops, coworking spaces, or even personal home networks. These environments lack the rigorous security controls of corporate networks, creating opportunities for attackers to exploit vulnerabilities in ways that bypass the robust protections of the internal network. This is because the network protection changes but the device behavior stays the same.

The How?

While Server Authentication certificates cannot be directly used to authenticate to network services, they are designed for Server Authentication purposes. By obtaining a Server Authentication certificate, an attacker can impersonate any server.

This allows the attacker to exploit the implicit trust that clients place in these certificates, enabling various types of attacks.

Few certificate templates by default allow both Server Authentication and Enrollee Supplies Subject. The most notable is the Web Server template, which is widely used but often configured with overly permissive enrollment rights, posing potential security risks.

This Certipy command can be used to request a certificate that matches a specific name:

certipy req -u [email protected] -p "SecPass$" -target-ip 192.168.42.10 -ca ninja-DC01-CA -template "WebServer" -dns "dc01.ninja.lab"

Trust Me, I Will Be Your Proxy

One of the most straightforward methods to exploit a Server Authentication certificate is by using it with a proxy server. In today’s modern environments, countless software and products rely on web services as part of their functionality. Possessing a valid and trusted Server Authentication certificate (which we can supply any subject to) enables an attacker to perform a Man-in-the-Middle (MITM) attack, intercepting traffic in cleartext. This can include credentials, secrets, and any other sensitive information transmitted by the client.

The simplest method to utilize this technique is using Burp Suite, by configuring the proxy listener as following:

Redirect traffic to the legitimate host when invisible proxy is required

Use custom certificate for HTTPS service

At this point, the proxy serves an HTTPS server (using the provided certificate) and every received request will be forwarded to the “real” server.

A concrete example of such an attack was detailed in a research paper co-authored by the author and their colleague, Noam Moshe, titled “Guarding the Bridge: New Attack Vectors in Azure AD Connect.” In this research, the author demonstrates how manipulating an AD Connect server with an obtained Server Authentication certificate can compromise the Entra Cloud Connector account credentials. However, this attack could be taken even further — an attacker could issue a valid certificate for the Microsoft login domain, allowing them to intercept credentials, including past MFA access tokens.

Execution and Impact

Once a valid certificate is obtained, the attacker can manipulate client hosts to redirect traffic to his malicious server, impersonating the legitimate server.

This redirection can be achieved through several methods, including:

• Modifying the HOSTS file on the victim’s machine
• Controlling DNS records (e.g., ADIDNS or an attacker-controlled network)
• Conducting spoofing attacks

In all these scenarios, the result is the same: the client recognizes the attacker’s server as legitimate due to the trusted certificate, enabling the interception of sensitive data.

Introducing SharpInvisibleProxy

Once thing that can interfere with exploitation attempt, is if the client validate that the endpoint is exist on the server before submitting the credentials. To overcome this, we can use Invisible proxy (instead of HTTPS web server) which access to original server and fetch the required data.

To facilitate this type of attacks, the author developed SharpInvisibleProxy which is a C# invisible proxy tool. Once configured, the tool spawns a web service presenting the configured certificate, and write to the console the requests intercepted.

Extract credentials from HTTP traffic

My Network, My Rules!

Another potential attack vector to consider is wireless networks, which have become less prevalent due to the adoption of 802.1x authentication. This protocol leverages certificates for authentication rather than traditional username-password methods. However, given the capabilities of Server Authentication certificates, this vector warrants reevaluation.

An attacker could exploit this by deploying a rogue access point and executing an Evil Twin attack. This method could be effective even if clients are configured to validate the server’s identity, as the attacker could present a trusted certificate. Consequently, the attacker would gain network access to client machines, bypass network segmentation, and intercept or manipulate client traffic, as the network is under the attacker’s control.

In the example below, the author utilized the default WebServer certificate template (which, by default, enables Server Authentication and includes a supplied subject) in his lab to successfully execute an Evil Twin attack. This allowed him to authenticate clients to my rogue network instead of the legitimate one.

client trust the AP certificate and connected to malicious AP

the client refuse to connect to the AP because of untrusted certificate

Package creation page in UEM admin panel

Interestingly, in addition to the main installation file, there are Pre-Deployment and Post-Deployment sections that allow administrators to perform actions before and after the installation process.

Pre-deployment script

There are several options to choose from; however, in this case, the “Custom Script” option seems to be the most suitable.

UEM allows for uploading script files, as well as providing command-line options:

The author created a package with a command-line pre-deployment task and tested it on an agent.

A package configured with a command line

Deploy the package on a client

Monitoring the process on the agent machine reveals that the command was executed with SYSTEM-level privileges:

PowerShell process executes by the task

However, checking the proxy reveals that the command line is encrypted, making it impossible to modify.

Server response with the encrypted command line

Before giving up, the author decided to try the same process with an uploaded script—a simple script that writes the current user to a log.txt file on the C:\ drive.

whoami | Out-File -FilePath c:\log.txt -Encoding ascii

Uploading a custom script

This time, the author noticed that the script content wasn’t encrypted at all. Instead, it was signed using SHA-256.

SHA256 checksum of the script file

Script file content

Verify the script signature using PowerShell

Given this flow, any attacker in a man-in-the-middle position could alter the command, checksum, and script content in the HTTP requests, potentially gaining code execution with SYSTEM-level privileges.

To demonstrate this, the author first created a simple script and calculated its SHA-256 checksum.

Check the malicious script checksum using PowerShell

Then, the author modified the server responses to include the altered script signature and content:

Alter the server responses with the malicious script checksum

inject the malicious script content in the server response

Finally, the author was able to obtain command execution with SYSTEM privileges on the agent machine:

Monitoring the process on the agent machine reveals that the command was executed with SYSTEM-level privileges:

The malicious script executed on the client machine

The author reported this behavior to the product vendor, who responded that obtaining a Server Authentication certificate requires high privileges — which is true in a properly configured environment — and therefore did not consider it a vulnerability.

However, this type of misconfiguration is commonly observed in real-world environments. Furthermore, beyond the requirement for a trusted certificate, the application’s behavior differed between command-line scripts and uploaded script files. While command-line scripts were encrypted, uploaded script files were only validated using a checksum — one that could be easily spoofed. This discrepancy allowed him to exploit the application by modifying the contents of the uploaded script.

This example is just one instance of how Server Authentication certificates can be exploited for code execution. In modern environments, many services could be leveraged to achieve similar results.

Wrapping Up

Server Authentication certificates have long flown under the radar in the broader conversation about ADCS security, yet as demonstrated, their misuse can have serious consequences. From impersonating trusted servers to enabling stealthy Man-in-the-Middle attacks and even achieving SYSTEM-level code execution, attackers can leverage these certificates in powerful and unexpected ways. Misconfigurations — especially in widely used templates like Web Server — are more common than many assume and often go unnoticed during hardening efforts.

Are you a security researcher? Or a company that writes articles about Cyber Security, Offensive Security (related to Information Security in general) that match with our specific audience and is worth sharing? If you want to express your idea in an article contact us here for a quote: [email protected]