Looking Back: Hacking and Defending Windows Public Key Infrastructure (ADCS)

I live at the fringes of the cybersecurity community. I have never attended infosec conferences.

There will be a talk on PKI hacking at Blackhat 2021 soon: Top AD offensive security gurus are presenting comprehensive research on abusing ADCS (Active Directory Certificate Services). I only know about that, because I noticed backlinks from their article Certified Pre-Owned to my websites. elkement’s articles from 2019 and from 2020 have been quoted as prior work in this white paper. Thanks for that – I feel really honored, especially because currently my blog explores the intersection of mathematical physics and art, rather than offering something infosec-related. I feel compelled to publish something “more normal” during Blackhat, to make it easier to find the relevant ADCS-related posts, and to provide some background on where I am coming from.

I used this blog for wildly different things, including the publication of research related to energy engineering (our special heat pump system). Only indirectly, this was related to information security – when I played with the security of the “Internet of Things”, with the things involved in control and monitoring. It was this tangent that finally led to a series of articles on hacking and defending Windows Public Key Infrastructure.

I have never been a pentester, but a consultant planning and building PKIs and troubleshooting all kinds of X.509 certificate issues. I am an experimental physicist turned IT security engineer turned renewable energy engineer … turned [some combination of all of that]. Against grand announcements I made on this blog and elsewhere, I had never fully traded in Public Key Infrastructure for energy engineering and physics. I have degrees in the latter fields, but when it comes to anything computers and networks, I am self-studied. I recently read Cliff Stoll’s classic “hacker detective memoir” Cuckoo’s Egg. He is an astronomer with experience in scientific computing who accidentally invented incident response methodologies and who hand-crafted intrusion detection systems. Had I read it earlier, I had been able to give better answers to “How come a physicist works in cybersecurity?”.

Developing software for analyzing measurement data, I had to connect to more or less secure “things”. I figured I should learn to really attack them for research and testing purposes, and I joined HackTheBox. I zoomed in on boxes where certificates played an important role, even if only to compensate for my lack of other pentesting tricks. And finally, there was a machine that featured the Windows Public Key Infrastructure. I struggled with the intended way to root the box, with pentesting tools, and with common Active Directory exploits. Then I noticed that this box featured a misconfiguration of certificate templates, and I was determined to put my dated Windows knowledge to good use.

This is the related series of blog posts:

  • Automatic Mapping of Logon Certificates to Users in Active Directory, published 2014 (to my other / “archive” website which is available under different domains) A quick demo on what happens if a third-party CA would be trusted (via NTAuth). The most common dangerous scenario I had encountered in the old days was like this: Subsidiary in [remote small country] quickly needs to implement logon smartcards. We want to delegate all things PKI to them – including the idea of delegating both admin access to the enterprise CA and to the certificate templates. Sometimes, delegation of template management is also unintended, e.g. by having groups with “forgotten” nesting into other groups in the template’s access control entries.
  • Sizzle @ hackthebox – Unintended: Getting a Logon Smartcard for the Domain Admin! In 2019 I played with the box Sizzle, and I saw that even Authenticated Users have Write access on the template. It can happen – an accidental click in the wrong checkbox. I wanted to logon with a physical USB crypto token, or use the /smartcard option available in some Windows command line tools. I combined Windows and Linux boxes in this attack, and I joined a client to Sizzle’s domain. This required me to fake an Active Directory Domain Controller on my Linux attack box with hand-crafted DNS records in dnsmasq, because the Kerberos port was not accessible and not proxy-able on Windows.
  • The DNS/logon/forward/proxy stuff is not related to certificates, but I found it so interesting, that I dedicated also a separate post to it:
    Locating Domain Controllers and Spoofing Active Directory DNS Servers
  • Impersonating a Windows Enterprise Admin with a Certificate: Kerberos PKINIT from Linux: To distract myself from the pandemic panic in spring 2020, I have been thinking about simplifying the attack. I wanted to get rid of the hardware token, all the Windows boxes, and the proxy/forwarding complexity. I used certutil to edit templates directly in the shell, openssl to create the certificate request, and native (non-offensive) Kerberos and PKINIT tools on Linux to create a Kerberos ticket. Only to finally present the ticket to the DC, I used the Kerberos options in impacket tools. This was before I noticed that other people had been working on adding a default PKINIT option to other tools.

The Linux attack is more economic, but logging on with a physical token to a physical Windows box joined to the HackTheBox’ machine’s domains was certainly the highlight of this research.

~~~

Unrelated to this logon attack, I found another (old-school Windows) certificate-powered thing to attack on another HackTheBox machine. On the Helpline machine you could get SYSTEM access easily, but you could not read any flags because they were encrypted with the EFS keys of specific users or admins. The intended way was to find their credentials somewhere else.

But I was obsessed with injecting an EFS recovery agent into the registry, faking an EFS group policy. Then you only need to import the related certificate and key to SYSTEM’s personal store to read the flags – but only after the legit users had looked at their files to really update the recovery agent used for those files. I demonstrated the injection both for a standalone and a domain machine, but I could not fully automate the “Users looking at files” part. I thought about social engineering the user into running a custom virus scan. A security expert provided the missing piece in the comments: Use a scheduled task that will run as the logged on user.

~~~

I am not sure, if there will ever be more articles on Windows security research! I feel I have exhausted all I once knew. Thanks for all the fish!

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.