Lying to your fACE | Easy way to setup ADCS Honeypot

Ever since Will Schroeder and Lee Christensen released their Certified Pre-Owned whitepaper outlining the first eight domain escalation paths through misconfigured certificate templates, Active Directory Certificate Services have become everyone’s favorite way to grab domain admin rights before lunch.

When it comes to finding vulnerable templates, most of us still rely on well-known offensive tooling that enumerates both the CA server and the published templates. Tools like Certipy, Certify, and LockSmith among others have proven to be dependable for both enumeration and exploitation of insecure configurations.

But what about Honeypots?

Several efforts to deploy ADCS honeypots have been documented in the past. They usually involve creating almost-vulnerable templates within existing CA environments to catch attackers in the act as they try to modify them. Others take a different route by setting up a standalone CA server with carefully crafted policy modules designed to prevent abuse of templates that allow user-supplied subject alternative names, such as in ESC1-style attacks.

But what if I told you there’s a much simpler way to deploy non-vulnerable templates that, to most open-source tools, look exploitable?

Maybe by using magic, right? And you’d be correct — it’s AD magic indeed!

HoneyPotter.png

Let’s check two different templates that are presumably vulnerable to ESC1:

BothESCOnes.png

So by the looks of it we are getting DA rights on both of templates right?

Let’s request both of them and see what happens

BothESCReq.png

One fails for a reason I redacted on purpose. You could try to guess it, but we’ll stay mysterious for now…

Since we only enumerated both templates with Certipy and it gives us no clear difference between them or any answer to our weird request behavior, let’s try it with different tools like Certify or LockSmith!

Certify first :D

BothESCCertify1.png

BothESCCertify2.png

Weird right? It’s like only the name has changed… Let’s try Locksmith next:

BothESCLocksmith.png

Both vulnerable and still we have no clue what is going on :(

But we are lucky, we have an ESC4 template in our client network. One would think that ESC4, a template with far fewer “requirements” compared to the others, wouldn’t trick us like ESC1 did, right?

Wrong.png

But before we jump to a conclusion, let’s first check it ourselves.

Let’s use ALL the tools at our disposal to check that ESC4 template, and you can take as much time as you need to find the “bug” between them.

Time to enumerate the shi* out of this one :>

ESC4.png

ESC4.png

ESC4.png

Well….. that seems nice, all of the tools tell me that this is 100% ESC4 vulnerable template right?

But I have one more trick up my sleeve

MasterPokeball.png

ESC4.png

FINALLY, we’re good to go, the DA rights are ours for the taking!

Time to change that template and make it vulnerable to more ESCs than there are grains of sand in the entire Sahara Desert.

ESC4Req.png

…..What the F___…..

How is this possible, bet it’s stupid client network… There is no way I have skill issue… Tools are fine too….. What is the cause of this blasphemy?

Well time for the big reveal!

Let’s first check that ESC1 that bothered us in the beginning.

Beninging.png

Let check the ACE list of ESC1 object

ACEs.png

We can notice some weird “Deny” for ReadPropery on GUID that is not in human-readable format, and for who? For Domain Users with RID of 513!

If we Google that GUID, we can notice that it correlates to msPKI-RA-Signature.

Hmm, weird. Why would someone do that, and what does it have to do with our failed requests?

A simple sneak-a-peak on one of the open source tools will give us the answer we seek.

SneakAPeak.png

It seems that tools like to set attributes to “0” when they can’t read it :D

Doge.jpg

And that is exacly what me and my friend did!

I strongly recommend you check out his blog: Kerberpoasting

And if you call now, you can get access to the tool that we built together!

Check it out on his GitHub page (since he had the tedious task of fixing my part of the code and adding his).

Certily is a tool that can be used to create honeypot certificate templates in an Active Directory environment. Its also be configured to optionally trigger a Canary Token alert every time a Certily template is requested. This is especially useful for ‘one-man-band’ IT or security teams, where resources are sparse.

Thank you for your time and sorry for the long post here is a picture of Murloc:

Murloc.jpg