FalconFriday — Detecting ADCS web services abuse

FalconFriday — Detecting ADCS web services abuse — 0xFF20

One of the popular attack vectors against ADCS is ESC8 — relaying NTLM creds to the ADCS HTTP(S) endpoints. While preventing this vulnerability rather than detecting it is the preferred approach by a long shot, we’ve seen cases where mitigating the vulnerability is not feasible.

In this FalconFriday we focus on detecting irregular access to the various ADCS web services exposed, as well as detecting the NTLM relaying itself. The three ways to access ADCS over HTTP are:

The “web enrollment” application, reachable at http:///certsrv/
The “certificate enrollment service” (CES). A web service reachable at https:///_CES_Kerberos/service.svc
The NDES services, reachable at https:///CertSrv/mscep/

Since we want to detect abuse of these web interfaces, you need to make sure that your IIS access logs of these servers are onboarded into Sentinel.

Web enrollment

All implementations of ESC8 I’ve seen are against the “web enrollment” application, as that offers the easiest interface to talk to. Certipy, PKINITools, ntlmrelayx all use the same web interface to talk to. If you’ve ever had a look at the interface, you’d realize really quickly that this application is ANCIENT! It’s an old-school ASP application that looks like it’s meant to be used in Netscape Navigator. Nobody really uses this interface anymore for production purposes (famous last words 🤷‍♂️). So, any traffic to this endpoint in general should be already super suspicious; and that’s exactly the first detection of this FalconFriday looks for. Since most public attacks are focused on the web enrollment application, we strongly recommend to focus your first efforts there.

Certificate enrollment service

The second web enrollment method is the collection of CES SOAP endpoints. These are used (natively) by the MMC snap-in for certificate management requests and the User-Agent they’re used with is “MS-WebServices/1.0”. Any traffic to these endpoints with a different User-Agent might be an indicator. So, the second detection looks for any traffic to these endpoints which doesn’t have this User-Agent. Obviously, an attacker building his own toolchain to talk to these endpoints is perfectly capable of modifying the User-Agent, but having sufficient tripwires in place in the form of such detection will make the attacker slip up at some point.

NDES services

The NDES endpoint is the most used endpoint for legitimate purposes. It’s based on the SCEP protocol and is the way Microsoft recommends to roll-out certificates for non-Windows devices. So here it becomes even harder to distinguish real traffic from malicious traffic. To catch ESC8 abuse to NDES endpoints, we have to detect the actual NTLM relaying.

Now here’s our next challenge: how do we detect NTLM relaying without direct network visibility?

NTLM relaying

Mehmet Ergene / @Cyb3rMonk has come up with a clever way to detect NTLM relaying. He explains all the details of the detection in his own blogpost. The bottom line is that Mehmet’s detection looks for a mismatch between the device name of the authenticating machine and the IP where the authentication is coming from — clever!!

We’ve modified his detection slightly, as the original detection was solely considering logons with domain accounts that have local admin permissions. Machine account logons were disregarded as well. We’ve worked around those limitations to make the detection applicable for ESC8, as often machine accounts and non-admin accounts are abused against ADCS.

Keep in mind that this only works if the victim and target are both enrolled in Defender for Endpoint.

You can find the NTLM relaying detections here.

From an attacker perspective, you definitely want to avoid using the web enrollment application. Relaying to that endpoint will get you caught in any mature environment. But then again, if the environment is mature, relaying to HTTP shouldn’t be possible in the first place.

If you want to abuse ESC8, you’re better of relaying requests to the ICertPassage RPC or MS-WCCE DCOM interfaces, these are the native interfaces used by Windows and won’t get you caught based on suspicious web traffic. However, the NTLM relaying detection will get you caught.