← All talks

Sniffing Out Cert Abuse: A Dogged Approach to ESC Remediation

BSides NYC · 202521:1549 viewsPublished 2025-12Watch on YouTube ↗
Speakers
Tags
About this talk
Emily Leidy covers Active Directory Certificate Services (ADCS) escalation attack paths (ESC1–16) and practical remediation strategies. The talk groups ESC techniques by abuse category, presents a prioritization matrix for targeting remediation efforts, and demonstrates real-world exploitation scenarios using BloodHound.
Show transcript [en]

technical difficulties over here, but I'm gonna dive right in because I have quite a bit to cover. Um, so thank you for joining. Uh, welcome to my talk, Sniffing Out Abuse, a dogged approach to ESC remediation. Apologies for the terrible blood hound pun. U, there is no more in this presentation, but I'm going to cover different ways to kind of audit and remediate different ESC attack paths. So escalation paths from one all the way through to 16 which was actually released earlier this year uh back in May. So I'm going to cover some prioritization methodology as well that I built out recently for identifying ESC kind of attack paths you know all of these different escalations in your

environment specifically. All right so I'm going to start with just a quick intro uh followed by an ADCS overview for anybody who's not familiar with these attack paths. Then I'll dive into remediation for a select subset of these techniques. I don't have time to go into all of them today. Um, and then I'll go through the prioritization matrix walkthrough and some future research opportunities. All right, so quick intro. My name is Emily Lighty. I'm a managing consultant here at Spectre Ops. Um, I've been with the company for about four and a half years now. So, I started back in 2021 as a defensive consultant. Kind of worked my way up. So, now I manage a team of

offensive, defensive operators. Uh, really runs the gamut. But I also kind of lead assessments myself. So, I'm kind of operational as well, but more focused on building out services at this point. Um, I'm based here in New York, so I'm excited. Hopefully, you know, some of you didn't have to travel too far, but um definitely love, you know, attending shows here, all that stuff. I was a professional opera singer in a former life. So, that's what I like to do in my free time. All right, so I'm going to start with some ADCS background. Um, so by a show of hands, who's heard of ADCS, escalation paths? Okay, awesome. A fair few. Um, so I'm sure you're familiar

with certified pre-owned as well. Um so ADCS for those of you that did not raise your hand um just stands for active directory certificate services. Um so it's a Windows server role for issuing and managing PKI public key infrastructure. Um all of theseerts they're used in secure communication uh different authentication protocols as well. Um so this screenshot on the right uh shows a set of com kind of interfaces objects allows us to view and manage our environment as well um in our active directory forest. So you can see public key services that container holds this forestwide configuration um for ADCS itself. So it's really your one-stop shop your way to manage your environment. So my colleagues will sher

and leagola Christensen they released certified pre-owned made a lot of waves in the industry uh back in 2021. So that kind of seminal research that they did covered escalations one through eight. Um so that was really the basis of you know ADCS of all of these escalation opportunities and misconfigurations that they identified. Um so since then in the last roughly four years eight more have actually been added. So ESC9 all the way through ESC 16 uh most recently which was released back in May of this year. Um so I wanted to give a quick shout out to my colleague Jonas as well. He did a lot of this research on remediation last year. So this kind of builds on some of

his research from that talk. All right. So I'm going to go into ADCS components really fast. Um these are some kind of relevant LDAP objects for modeling ADCS attack paths which sit in this configuration naming context. So on the left we have our certificate template node. Um that's has this non-traversible publish to edge. Uh so this represents the AD objects of that PKI certificate template LDAP class. So the enterprise CA in the center um that stores your permissions and registry on the computer hosting that enterprise CA service. So when you're authenticating in AD using some certificate, the DC then checks and see if it trusts that certificate or the issuer of theert um for NT authentication. So all of that is

kind of stored in this NT off store. Um and that is what's kind of holding all of those uh certificates trusted for NT authentication and those are held in its CA certificate attribute. Uh so for ESC1 really all of these escalation paths there's a series of conditions that need to be met for it to be viable. Um so ESC1 using that as our example. Uh the enterprise CA really has to be trusted for NT authentication for that to work. So all of these map back to that initial set of kind of column interfaces. Um so you see public key services uh this container that we saw on the first slide. They all have their own

subcontainers as well. So on each of these objects, Blood Hound collects the security descriptor and the relevant ACES of the DALE, the discretionary access control list of each of these security descriptors. So on an enterprise CA object um where the enrollment rates and those replicated uh kind of rights, they're replicated from the host essentially um up into the LDAC object. So from that we can see which principles are actually allowed to enroll um which have full control, the CA things like that. And I'm going to mention Blood Hound throughout this. How many of you are familiar with Blood Hound? That tool. Okay, most of you. Great. I'm wearing the shirt. So, got a rep. Um, but Blood Hound is a great

tool. I'm going to mention it. Um, I'm not talking about our enterprise product. We do have a paid product, but we also have a community edition version. So, all of this is applicable to our community editions. So, that's open source. All right. So, since my colleague Jonas's talk last year, there have been a number of updates to ADCS. Um, so starting with ADCS ESC9, specifically attack paths or edges A and B. um it's no longer tenable. There was a recent Windows patch in September on September 9th. Um it enforces this strong certificate mapping. Uh so it's really no longer viable. So we have since removed it. Um and I've kind of nixed it from this presentation. Um same with

ESC14 specifically scenarios BC and D as well as ESC15. Uh so there are still some escalations some scenarios in ESC14 that are viable. Um, so you can map alt security identities with a strong value such as cert thumb thumprint. So that does still work. Um, so you should still see that if you're mapping out a full environment. And then ESC16 was recently added. Um, we have not since mapped this or pushed it to Blood Hound. So you won't see that just yet. You can't use Blood Hound unfortunately to audit this, but it is coming. Um, and then we can now identify ESC8 in Blood Hound with this new edge that we've added recently. It's coerc and relay NTLM to ADCS. Um,

so you know, if you just search kind of run a cipher query and then find that edge, um, then you'll know, you know, if ESC8 is prevalent in your environment. And then finally, Blood Hound now has the ability to show all of these ADCs kind of inbound escalation opportunities for a singular domain, which is awesome. Um, really allows you to kind of see everything that is applicable to a specific domain in your environment, anything that you're really concerned about. um you can more easily find uh some of these edges that completely cut off the most non-tier zero nodes which is what we're concerned with. All right, so I'm going to start with some of the basics and kind of the

requirements for ESC1. Um I'm using that as our example today. So a subject alternative name, it's a SAN. Um it's just an extension that allows for uh some additional identities to be bound to a certificate beyond just the subject of theert. So if a web server hosts content for multiple domains, uh each of those domains could be included in the SAN so that the web server only needs you know a single HTTPS uh instead of one for each domain. It's really convenient but it does allow for some dangerous situations regarding domain authentication. Um so you know using ESE1 as kind of our um first example if an attacker can specify an arbitrary SAN when they're requesting some certificate

that enables domain authentication and the CA creates and signs a certificate using that attacker supplied SAN the attacker can become essentially any user in the domain. So very very powerful um and we see this unfortunately in a lot of client environments a lot of customers um do have this. So I actually ran uh a cypher query across our entire BHE fleet. Um so that was roughly four 1500 actually domains. Um so quite quite a few uh and ESC1 was the second highest attack path that I found after ESC4. Um so there's a series of conditions like I mentioned that need to be met for this to actually be possible. Um but it does permit this lowp privileged user to

request a certificate specify that arbitrary identity within the certificate SAN and then kind of allows them to impersonate any user uh including admins. So that does require one of these conditions that I mentioned uh requires this enroll supplies subject flag to be enabled. All right. So escalation one it's just this abuse primitive um very common. I've kind of reviewed uh the basics of it already. So, I'm just going to walk through what it would actually look like. And we're going to use Alice and Bob as our examples. Um, and I'm not going to get into enrollment agent restrictions here. There's really ultimately no protection against this. It's just as powerful as like DC sync. Um, but let's say we have our search

template, we have our enterprise CA, we have our DC, and we're assuming that Alice has the ability to do ESC1. So the way Alice would actually do this uh she requests this enterprise CA to issue a certificate back uh that's valid for authentication where a particular field in the certificate called subject alternative name so our SAN uh will be populated by the user principle name of some other user in our case Bob. So let's say Bob is domain admin. Uh so we can say our SAN is Bob at Ktoso.local. uh the security reference monitor on the host that hosts that CA service will then check several different security descriptors and see if Alice can actually do that. So they say, "Yep,

Alice can." Um so the CA then issues this certificate back that's valid for authentication. And that certificate needs to have some sort of EKU that's valid for NT authentication. There's several. Um in our case, we're just using client authentication. So with that certificate, Alice can then present that to the domain. Uh the DC uh just say, "Hey, I want a TGT as Bob." Um so this certificate serves as the credential. It's really our proof that we're allowed to authenticate as Bob. So at this point, the domain controller will then return your TGT that can then be used to get different TGS's and Alice has effectively become Bob. So um you know, she is impersonating him in the

domain at this point. This is extremely common, a very reliable privilege escalation primitive. It's common in nearly, you know, every AD environment. Um, finding it by hand can be timeconuming. So that's why Blood Hound is so effective. So escalation one is really possible because of the mechanics of the system. Uh, you have the security descriptors on your different objects and then configurations on these different objects. So there's at least five objects that you know have to be present for this to be possible for it to emerge. Um there's actually a composition graph that we have in Blood Hound that allows you to view all of these. But um all of these puzzle pieces essentially fit together uh to create

this primitive. So if we remove one of these puzzle pieces, one of these configurations like what if CA is not issued by root CA. Um it won't be trusted by the domain. So ESC1 is null and void. So I'm going to start grouping some of these different escalation techniques into abuse categories. This will allow us to kind of prioritize our remediation. um if there are any through lines in your environment. Uh so for ESC1, ESC1, ESC2, ESC3 and 13 um they all have to do with you know this template that enables impersonation. ESC 4, 5, 7, and 12 all require control over ADCS objects. So you can kind of see some of these um commonalities between

all of these escalation attacks. And for this chart, I've just bolded the ones that I'll try to walk through today. Um hopefully we'll have enough time for all of them. And then I'm not going to dive into, you know, what each of these escalation paths is. There's plenty of resources out there. So if you're interested, I'm happy to share this. Um, so remediation guidance, it's very difficult to build, right? Um, you have like 10 or 12 different conditions that need to be met. So if you're looking for, you know, the factor of all those different combinations, you're going to have like 40 or 50. Um, so that makes it very daunting for a lot of customers to

know where to start. Um maybe you have like generic rate on the object and roll rates through another path. Or you have um generic all on like a services container, but that only inherits down to a certain class of objects and you have another way to make up for it somewhere else. So this is very environment dependent and it's going to change kind of your priority level for each of these escalation paths. So we hear this from a lot of customers. we don't need to audit ADCS because uh you know we've have preventive tooling in place or we've done regular testing um or they've already remediated you know back in like 2021 but like we've

seen there have been a lot of new escalations that have been discovered just in the last few years. Um so I'm going to go through these. I would definitely recommend auditing ADCS. Um you know a lack of visibility really leaves you blind to a lot of these pretty critical attack paths that you know we exploit regularly in penetration tests and red teams. um these are extremely common and viable and there's a lot of great mitigation guidance on the certify wiki as well. Um if you're familiar with that definitely check it out. So I'll start with uh ESC1 and 13. So this first bucket which is template enables impersonation. Um so you have this cipher query down below.

Um if you're not familiar with cipher queries, there's a lot of great documentation on our Blood Hound uh pages, but we're essentially looking for anything ESC1 ESC13. So self-explanatory, but we're looking for anything that's not sourced by admin tier zero. So we're looking for anything that's not this admin tier zero, which you know should have those privileges anyway. Um and then we're returning this path object piece. So the source node, relationship, target node. So if you can for remediation, um limit enrollment rights to tier zero principles. You want to remove any EKUs that enable domain authentication. So you can only impersonate for signing and things like that, which aren't quite as bad as authenticating. Um, and this

applies to ESC 2 and three, too. Um, they're in that same abuse category, but say you have like a group help desk. So, they're not tier zero, but you know, they do need these impersonation rights if they're say creating smart cards for other users and things like that. Um, so the kind of workaround, the solution to this would be implementing enrollment agents with restrictions. Uh, so this allows you to specify more granular permissions for enrollment agents and kind of who they can impersonate. Um, I would deny the impersonation uh for tier zero admins. Um, but there's a lot of good vendor guides for this. There's also a lot of not so good ones. Uh, so

proceed with caution, but Ubico has a really great one out there. Um, so I'm happy to send that link if you're interested. All right. Um, so to audit ESC4 in your environment, you can run this cipher query too. I'm going to going to run through this um, because we are short on time, but the primary remediation uh, for this is to restrict control over your ADCS objects, especially for your non-tier zero principles. Um, so this includes control over CA computers. You want to enumerate all of these security principles that have non-default rights. So you're looking for your generic all your um right dackle, your manage CA, things like that. And then enforce group policy to block non-admin certificate

enrollment modifications. Um this applies to ESE 57 and 12 as well. Um there's some great event IDs too that you can enable if you're centralizing your telemetry and like a SIM. Um there's event ID 48.99. You have to do some group policy uh modifications probably, but 4,900 uh for CA configuration changes. 4662 things like that. All right. And then this is the latest coerc and relay NTLM to ADCS. So this will allow you to detect ESC8. So the remediation for this um if it does you know show up in your environment. Uh it's kind of twofold. So uh you want to enable extended protection for authentication. Um this is really the primary mitigation for IIS

hosted web services like Cert SRV. um you want to configure this application protocol or pool um kind of site hosting the ADCS web services to require EPA. So just set that to required. Um and then for requiring HTTPS, you want to ensure all of your ADCS web services are configured to use HTTPS only. Um so disable HTTP bindings, but this isn't going to in of itself prevent, you know, NLM relay, but it is a prerec for EPA. All right. Okay. And then a lot of the more recent escalations, they have some overlap with pre-existing ones. So ESC16 overlaps a good deal with ESC9. Um they both deal with DC's strong certificate binding enforcement setting. Um but

there's a few key indicators. Like I mentioned, we're not ingesting this into Blood Hound just yet. Um but you can audit it with Certify. Um so I'm not going to go into all of those indicators, but there's some good information on the wiki. And then for remediation, this is going to include reenabling the SID security extension on the CA. You can do that using start util and making sure it's patched properly. You'll also want to enable full strong certificate binding enforcement on DCs. And then this is coming soon to Blood Hound. So just an FYI. Um we are going to be adding ESC14 at scenario A. So ultimately, you know, proceed with caution. Remediation is a balance. You

don't want to just, you know, click and then people are screaming in the background. Um not great. You want to look at all of your dependencies in place. Uh kind of document where you can. um look at anything that you know could happen uh could be could break as part of remediation because that does happen. All right, so I'm going to go into prioritization. Like I mentioned, this is a new view that we've added to Blood Hound. Um it allows you to view all of these inbound ADCS paths in your environment in a given domain. Um so it's a great starting point when you're looking at what to start remediating, what's the most critical, what is

mapping to, you know, non-tier zero users. All right. So, prioritizing remediation, it's tough like I mentioned and we thought about this a lot internally of how to incorporate it into Blood Hound itself. Um, but path length is not currently factored into our exposure score. Uh, so even if you remove some of your like shortest paths, uh, the impact the risk is not really clear that risk reduction. Um, just because longer alternative paths might exist in the environment. Um, so there's different ways of doing this. You could do like a Monte Carlo simulation kind of using repeated random sampling. um using starting nodes kind of crawl the graph that way. Um but in the meantime while

we build that out internally uh I have developed this priority score formula to help users get started. Um so I gave impact and exploitability the largest weights because of the significant effects of ADCS misconfigurations can have. You can have forestwide uh compromise and then likelihood is weighted next because a lot of environments do expose these conditions. Um, like I mentioned, I ran uh cippher queries across our fleet. Um, and ESC1, um, and ESC4, ESC8, those were three of the most common. Um, so this is all and I'm going to pull up an example here in a sec. Um, but these are all based on, you know, real world environments that we're currently monitoring. All right. So, and one quick note on

detection difficulty that is weighted the lowest. It's not non-zero. Um, just because detection cap difficulty, it's a little bit different. It's usually treated as its own entity or capability. Um, but if your a detection is harder to build, say for like ESC4, um, then that might bump up your remediation score a little bit and that priority. So this is the matrix that I built out. Um, it's geared toward all of these viable escalation techniques. The ultimate goal here is to help you calculate a priority score based on a number of different values. Um, so like I mentioned, you know, a lot of these are based on actual environments. Um, you can tailor these to your environment though. So I kind of

assumed a moderate maturity for defensive and offensive operations and functions. Um but say you don't have a detection function um or you're you know your detection team is made of one and you know they're pretty junior um then you might bump the dete detection difficulty scores up to high critical um something like that. All right so I'm going to touch on some attack path research opportunities too. Um, these are either things that we're already looking into internally or just things that, you know, I would love to dig into if I had a little bit more time. But, um, there's a lot of great work out there, good research on detections for ADCS attack paths. So,

I've included two links here. We've actually done a lot of work with the Australian Signals Directorate. They're great. They put out uh, good research pretty regularly. So, um, there's also remediation automation. Um so one of our security researchers JD or SAD processor if you're familiar with his handle um he's working on some remediation automation scripts as part of his BH operator PowerShell client. These are meant to be like click to fix playbooks uh for common attack paths and this would also calculate your shortest path to DA uh to help you prioritize findings for your environment. And it feels like there's a new open graph extension every week. Um I think that's going to keep coming. There's a ton of opportunity

here. Um, so you could even, you know, prioritize or pull in some of your prioritization, um, calculations from that previous matrix that I pulled up, uh, as o open graph attributes on templates, CAS, and surface a priority score in Blood Hound. There's just so many things that you can do with it. Um, so that is a great research area that I think folks are going to continue digging into. Um, and then finally, MCP integration. Um, so Matthew Nickerson, who's one of my colleagues, he's done a lot of research on this. He's actually here at the conference. So if you run into him, say hi. Um, but this would be a great way to kind of ask Blood Hound

some questions as you're remediating. So if you know you don't know what the downstream consequences of some remediation step could be, MCP is comes in handy for sure. All right, that is all I have for today. I know that was really fast, but thank you so much. [applause]