Privilege Escalation Capabilities in AD Certificate Services

All right. Uh, seems like we're rolling here. So, I will go ahead and get started. My name is Brady McLaclin. Um, my talk here, as you can see, is going to be on privilege escalation capabilities in Active Directory certificate services. Um, for the pre-recorded version of this talk, I do not actually need to share the slides with you here. Um, but I do have the link if you're curious. So, that'll be at this GitHub link down below. But uh since I don't really need to stall for people to type that in, I'll go ahead and move on from there. If my clicker would work. There we go. Okay. Uh so who am I? I'm a

pentester at a security firm called Viking Cloud. I'm a grad student at Penn State. I'm a contributor to the Ludas project, which is a cyber range automation deployment platform. Um they have roles for active directory certificate services misconfigurations. Um, and I built five of the 12 that are available, and that's what I'm going to be using for this demo today. Um, so anything that you see that is in the terminal is going to be attacking this, uh, Lutus range that I built. Um, I have some search that people care about sometimes. And then, uh, when I'm not doing stuff like this, I'm a husband and cat dad. Uh, moving on to what this talk is

going to be. Uh, this is primarily supposed to be an awareness piece mostly for blue teamers. Um it is my kind of understanding that it seems like a lot of uh blue teamer cisadmin type people either might not know about this or aren't fixing it uh because it is something that myself and my colleagues see pretty frequently on pentests. Um so yeah the main point is awareness piece. Um we're going to be doing a demonstration of several ADCs escalations and it is going to be a lot of info. I have 88 slides here some of which are memes. Um but in any case it is kind of a lot of info to get through. Um, we're going to be doing it kind of

fire host style. Uh, so getting into what this talk isn't, uh, it's not going to be lots of time. Uh, it's not meant to be a tutorial. So for my, uh, pentester, red teamer style people out there, um, you probably already know most of this stuff. This is nothing, uh, brand new. But, um, if you're, if you're coming here to try to learn how to do everything, this is probably not the talk for you. Um, if nobody can walk out of here doing any of this stuff today, that's fine, as long as you kind of are frightened of it and know what it is. Um so yeah this isn't going to be comprehensive uh because of the amount

of time and the amount of info. Uh there are going to be some well actuallyies. The theme of this talk is everything is going to be like an oversimplification for time. Um but that's just something to keep in mind. So if you have well actually just let me know after. Okay. Uh moving on to a brief timeline of ADCS abuse tradecraft. So the certified pre-owned white paper was released by real will Schroeder and Lee Christensen in June of 2021 at Black Hat. uh they released ESC1 through ESC8 in this white paper. Um this is kind of the primary ADCS document that we all refer back to and they also released certify.exe which is a Windows binary

that is used for identifying and exploiting vulnerable ADCS configurations. Um after that in the fall of 2021 certify a Python implementation of Certify was released by Oliver Leak. Um, and then our most recent uh development, I guess, is ESC15, which was published by Justin Bowlinger in October of 2024. Um, so this stuff is still like pretty recent. It's still coming out. Um, but it's not like super brand new. Started back in 2021. Um, some key terms that we're going to be using uh pretty frequently. So, ADCS is Active Directory Certificate Services. Um, this is Microsoft's public key infrastructure implementation that they use for Windows Server. Um, a CA, I'm going to say a whole bunch, is the

certificate authority. Um, if you're thinking of what a CA is, it's basically like the domain controller for the uh, PKI implementation, if you want to think of it that way. Um, CSRs are certificate signing requests. This is going to be how we're asking uh, the CA for certificates. Certificate templates are used because a CSR contains a whole ton of different properties and attributes. Um, and it would be a super pain to have to kind of uh, specify them all manually every single time. So these templates are used so that we can uh basically get in there and get out pretty fast with our CSRs. Um extended key usages or EKUs. This is a certificate attribute

that is used to specify what a certificate is used for. Um so anytime you hear me say EKU, just think this is what we're doing here. Um and then the last one here is a SAN or a subject alternative name. This is another certificate attribute that we can use to uh specify if a principal needs to be able to use a certificate to log in as an additional principal. um they would use a subject alternative name and we'll talk about some exploitation for that here in just a minute. Um but why do we care about certificates? So often we're only going to need a lowprivileged user to request a certificate. Um so we can often and in most cases in this talk

we're going to be escalating from a domain user that has no privileges to a full domain admin. Um this can be an arbitrary principle, you know, if you have a different target. Um but domain admin is kind of sexy, so we're going to use that. Um certificates can be used for authentication. So that's another important point here. And they can also be used for persistence. And a cool note here is that a certificate will be valid both before and after a password change. So if I were to pop one of your users um your user's compromised, but you notice and you have that user change their password. If I have a certificate for them from before they change their

password and that certificate is still valid, i.e. it hasn't been revoked, um that certificate will actually still work after the password change. And that is the case for both machine accounts and user accounts. Um and then a final note here just to kind of round out the slide is we can also do privilege persistence using certificates. So if you're familiar with the uh the concept of golden tickets, we can do the same thing just using golden certificates. Uh moving on to some tooling here. Uh so this is certify the Windows binary that was released with the original ADCS white paper. Uh this is certifi which is the Python implementation. And if you look down here, the latest release of Certify was

in September 20 or September 25th, 2023. Um, so we're going to be using a tool called Certify Merged, which is a fork of Certify. Um, this basically brought in some poll requests that covered some later released escalations and some other quality of life stuff. Um, so this is our first Well, actually, I'm going to be referring to everything as Certify. Um, we're technically using certify merged. Um, but for the for the purpose of simplicity, I'm just going to say certify for all of this. And that's going to bring us to our first set of ESC uh misconfigurations. So uh escalations in ADCS are referred to as ESC and then the number that identifies which one they are. So the

first subset is going to be escalations via misconfigured certificate templates. And that's going to cover ESC 1 2 3 9 10 13 and 15. Um something else to note is that we're not going to be going in numerical order. We're going to be going in kind of a logical order here. Um so when I jump to one to three and then 3 to two, don't freak out. Um, just trust me on this one. Okay. Uh, what causes these template misconfigurations? The primary thing is it just works, right? Um, so if you're trying to get an app running and the app is not working, you need to make a new certificate template. Um, you know, it's

it's Friday and you're trying to go home at 4 and it's 3:25. Uh, you might put up a template that may be vulnerable. Um, another thing that makes these templates uh possibly misconfigured is that the way that Microsoft actually wants you to create these certificate templates is by duplicating existing templates. Uh this is the Microsoft learn article for uh certificate template creation. So they say uh you can create it by duplicating a template and then using those templates properties as the default for the new template. So if you think about this, if you have like three out of four requirements for an escalation and then all of a sudden uh you need a new template. So you duplicate that template

and you change some stuff, you might have four out of four now. And we'll see what that looks like in ESC1 here. Um so ESC1 is the kind of simplest and most or not most common I guess but uh the the most referred to escalation. Uh so the escalation via subject alternative names which we talked about a little bit in our vocabulary section. Uh so this is what ESC1 is. You know I'm something of a domain admin myself. Uh this is going to be the certify find subcomand. So certify has subcomands such as the find command here which will give us uh enumeration capabilities over the ADCS. Um, so something to note here is our template

name up at the top. Uh, these are descriptive. So these are not actually telling you which escalation that we're going to be taking over. It's just named ESC1 because that's what I called it for simplicity. Um, and then I highlighted some key fields here as well. So here the uh certificate name flag enrolly supplies subject. That's what allows our subject alternative name to be weaponized. Um, the EKU or extended key usage in this case is for client authentication. So once we get a certificate, we'll be able to log in. uh manager approval is set to false, which is a requirement for ESC1. Um we're going to talk about this a little bit more when we get to ESC 7. Uh but just

keep that in the back of your mind. And then uh certify also gives us kind of a a nice guy hookup down here. And it tells us, hey, this uh template is vulnerable to ESC1. Uh domain users can enroll and only supply subject. And the template allows for client authentication. Uh this is what it's going to look like in the MMC snap-in. So when you're creating an ESC1 template, you do so by uh using the supply in the request for the subject name option. And then when you make an ESC1 vulnerable template, uh Microsoft actually pops up this little thing that says, "Hey, these options may create a security risk." Uh but what's fun about

this pop-up is that it's got this cool little okay button down here in the bottom right. Uh so we're just going to go ahead and click that and move on. Uh this is what the exploitation for ESC1 is going to look like. You can see it's pretty straightforward. It's only three commands. Um, our first one here is going to be the CSR. So, the certifi certificate signing request uh is going to be created using the certify wreck subcommand. Uh, we're going to be using a low-level uh lowprivilege user called domain user at the uh bsides.lab domain. Uh, their password is going to be password because they skipped their security training and just click through as fast as they could. Um, our DCIP for

this uh lab is the 225 IP address. You don't really need to keep track of that. I'll do that for you. Um, our CA name is the bside CA. our template name. Remember, this is not the escalation. This is the name of the template is ESC1. And then this is where we're going to specify our SAN. So, we're going to give it a user principle name of domain admin, which believe it or not is a domain admin. Um, our target is going to be the CA's IP address, which is this 235 IP. Um, again, you don't need to keep track of that. I'll do that for you. Uh, so when we go ahead and send

that CSR, it's going to tell us got a certificate with the UPN of domain admin. And then it's going to save the certificate and the private key to this certificate file, which is domain admin.pfx. PFX. Anytime we see a PFX, you can just think of that as a certificate. For the purposes of this talk, um after that, we can go ahead and authenticate using that certificate using the certify O subcomand. Uh we'll supply that domain admin pfx certificate. Uh the username domain admin, the domain name, and the DCIP. And it's going to give us back a TGT or ticket granting ticket. Uh TGTs being the way that Keraros does authentication in Windows Active Directory. Um so we're

going to get back this domain admin credential cache or CC cache file. Uh, anytime we see ccash today, we're just going to think this is a TGT. Okay. Um, it's also going to give us NT hashes. Um, we're not going to be using these today, but if you need those, they're there. Uh, so what we can do with this TGT is we can supply it in the KRB5C name variable. Uh, so we're going to supply our domain admin.Cash file. Uh, we'll use a tool like Wexec using Kerros and no password to log into DC01, which is the domain controller in this lab. And now you can see that we can run arbitrary commands like the who am I

command, which every domain admin always runs. Um, no offsec vulnerabilities here. Just everybody runs who am I, right? Um, so yeah, you can see we're now running as the domain admin. So this is what escalation one from a no privilege user to a domain admin looks like. Our next escalation here is going to be ESC3. This is escalation via the certificate request agent EKU EKU. Um, this is also going to be referred to as the CRA. So the certificate request agent or CRA is a principal in ADCS that uh is able to request certificates on behalf of other principles. Um so if you think about what that means, we can say we can get a certificate and say hey I

need a certificate for the domain admin and ADCS will say well if you're the CRA, sure you can do that. Um as such the CRA should be a privileged principle. Uh we shouldn't be able to just willy-nilly request things for the CRA, but if we do that's what ESC3 is. Um, so here's going to be our ESC3 CRA template, which is vulnerable again to ESC3. Uh, you can see the EKU for the certificate request agent or CRA is highlighted up here. And then our nice guy vulnerability output is ESC3. Domain users can enroll and template has the CRA EKU set. Um, this is what it's going to look like in the MMC. So, uh, certificate

request agent is here under the application policies. And then this is what our exploitation will look like. So we have the certify rec subcomand to do our CSR. We're using domain user and password, the DCIP and the CA name. Uh in this case, the template name is going to be the ESC3 CRA template. And we'll do our target, which is the D or the CA IP, I should say. Um notice we don't need to specify a user principle name or anything like that. And that's because we are getting a certificate for the domain user. Um so we're getting domain user PFX. Um but this is going to say anytime we're using the certificate that we are the CRA. Uh next we'll do a

second CSR using certify rec. We'll use username and password CA name. Uh this time we're going to use the user template. So this is not a vulnerable template. This is a built-in standard uh everybody can do template. Um but we're going to be doing it on behalf of the besides domain admin. The pfx is going to be the domain user pfx that we grabbed up here. This is what says that we are the CRA and we can do such a thing. And then our target is the bip again. Uh then we'll go ahead and grab our domain admin bsides.lab lab certificate and we get it as domain admin pfx. Um, then we can off with our

pfx and get a TGT. Um, and from this point on, I'm going to assume that you trust me that I can use the TGT to log in and stuff. Uh, because that'll save us a little bit of screen space down here. Um, so yep, TGT means we are domain admin. ESC3 complete. Moving on, uh, ESC2 is going to be our next escalation. So, this is escalation via the any purpose EKU. Um, so if you think about what any purpose means, uh, that kind of includes all of the other EKUs, including the CRA, um, among other ones like code signing or other things that can be dangerous. Uh, but for the scope of this talk today,

we're going to get in and get out really quick using the, uh, CRA EKU. Uh, so this is what a this is what the certify find output is going to look like. So our EKU up here is any purpose, and then it'll tell us in our vulnerabilities output, ESC2, the main users can enroll and template can be used for any purpose. Uh, notice that there's also ESC3 down here. And that's because if it's vulnerable to ESC2, it is also inherently vulnerable to ESC3. Um, and that is again because the CRA is included within any purpose. Uh, moving on to the snap-in, it's going to say any purpose just like we would expect. And then this is going to be how

we send our CSR. Um, so it's going to look very very similar in this case to ESC3 because we're doing the ESC3 path. We'll do our CSR using domain user and password. We'll use our DCIP and CA name. Our template this time is going to be called ESC2 because that's our any-purpose template. And then uh CA IP, we'll get our domain user PFX that says that we are the CRA. And then we'll move on to our second CSR. Um it's going to be exactly the same thing. We request using domain user and password at the uh bside CA. We'll use the user template to request on behalf of domain admin and when we uh supply our certificate from

up here that says that we're the CRA and we can do such a thing. And then our target's going to be the CA IP. We get our domain admin pfx. We can off and get our domain admin TGT. Um so that's what the ESC3 path for ESC2 looks like. Uh now in some cases you can also do an ESC1 path using the uh ESC2 template. You can see this is our CSR using ESC2 supplying an alternate SAN. Um then we get our certificate for domain admin. We can off and get a TGT. So uh ESC2 is a little bit more dangerous because of the any purpose capabilities. Um again there you can do some other things like code signing

which are important in some cases. Uh but we're going to skip over that for brevity today. Moving on to our next escalation in this group is going to be ESC15. Uh so this is our most recent escalation. It's actually been uh given a CVE CVE 20249019. Um this was disclosed back in October of 2024 and it was patched by Microsoft in November of 2024. Um but it's not like we ever see unpatched software, right? Uh so this is going to be escalation via application policies. So what does this mean? This is a friendly Microsoft learn article from back in 2010 um about using application policies. And the important part down here is that a if a certificate has an

extension containing an application policy and also has an EKU extension, the EKU extension is ignored. Uh so what does this mean? Basically, if we're able to request something from a template where we can supply our own application policy, we essentially can have any purpose privileges or uh any purpose EKU effectively over this template. So, that just sounds like ESC2 with extra steps, right? If we can supply our own application policy and that's going to overwrite the EKU, it's essentially like we have any purpose, just without saying. So, um we're going to be exploiting the web server template. Uh something that's notable for this vulnerability is that it only works on template schema version one templates. Um and the certificate

name flag will be enroll subject. Um template schema version one templates are uh kind of legacy templates if you want to think of them that way. There are very few of them and they're all builtin. Um once you change a template, it becomes schema version two. So uh schema version one will only work for built-in templates. Uh and that's pre- patching in this case. So it'll tell us down here ESC15 domain users can enroll and only supply subject and the schema version is one. This is what the exploitation is going to look like. Going to be very similar in appearance to ESC3. So we're going to do our uh CSR using certify rec domain user and

password DCIP and CA name. Uh the template is going to be the web server template. Uh we're going to be targeting the CAP which is 235. And here's our fancy ESC15 thing where we're going to supply an application policy. Uh, so we're going to say, "Hey, we want to be the CRA." And it says, "Well, if you say so, man, here you go. Here's your domain user PFX." Uh, and then we'll supply that PFX to say, "Hey, we want a user template on behalf of domain admin." We'll get our domain admin certificate, and then we can off and get our domain admin TGT. Um, so that's ESC15 using application policies instead of the EKUs. Uh, the final one in this group is

going to be ESC 13. So this is escalation via an oid group link. Uh, this one is a little bit theoryheavy, so I'm going to be relying on this visual here, uh, that I stole from the Spectre Ops article where they released ESC13. Um, this is going to be a super oversimplification because these kind of mean a lot of things. Uh, but essentially, if you have a principle that has enrollment rights over a certificate template, and that certificate template has an issuance policy that contains an oid, and that oid has a group link to a group, uh, which is a lot of words, I know. Um, basically if you get a TGT or a certificate using that, uh, you can

authenticate with that certificate and get the effective permissions of being in that group or this principle without actually having to put that principle in the group or, uh, modify the group or the principal itself. Um, so I know that's complicated. It may be a little bit uh illuminated when I demonstrate it here. Um, just for demonstration purposes, uh, this is a login to the domain controller as the domain admin. And that is only for the purpose of running the uh net user domain user domain command. Um and this will show us the permissions that the domain user user has. In this case they are only in the remote desktop users and domain users groups. So this

is not a privilege principle. This is just a low-level you know Bob from accounting style user. Uh moving on. This is our certify find output uh template name is ESC13. Uh and you can see the important parts here are the linked groups. Uh there's actually a there's an empty group right here. That's because the first time I ran the deployment, it actually didn't work. Uh, but I did not build this deployment or this escalation. So, I'm going to wipe my hands of that one. Um, our linked groups here are the ESC13 group. Uh, and it'll tell us here ESC 13 domain users can enroll. Template allows client authentication and issuance policy is linked to group and then

there's the empty group here and then ESC13 group, which is the one that we're going to be using today. Uh, so this is what it's going to look like. We'll do our CSR using domain user and password. Our DC IP and CA name just like always. Our template name is going to be ESC13 and then the target is going to be the CA IP. Uh because we didn't supply a SAN or anything like that, we get a certificate for the domain user. So domain user.pfx. Uh we can off using that domain user pfx and we just get a what appears like a regular old domain user TGT. Um, however, we can supply this TGT in the KRB5 CC name variable

and use a tool like WMIXC to log in uh using Kerros and no password to the DC01. And now we are on the DC running commands as the domain user. Um, now if you know a little bit about this, you probably are thinking, hey, a regular domain user shouldn't be able to Wii exec to the DC. Like what's going on here? Um, and that's because in this case, if we run who am I groups, you can see that using this TGT, we have the permissions of ESC13 group. And the ESC13 group in this uh deployment is a member of the enterprise admins group. And that's a little bit of smoke and mirrors just to make it kind of look

cool for the presentation. Uh, but there are actually some prerequisites for ESC13 where only certain groups are applied. And one of the groups that can be hit by ESC13 is actually the enterprise admins group. Uh so it is not entirely implausible that you would get enterprise admins if you have a successful escalation using ESC13. Okay, moving on to our next subset here. Um and I got to keep moving pretty fast uh just because there's a lot to go through. Um ESC9 and ESC 10 are going to be escalations via weak certificate mapping. Uh because from an attacker's perspective using Certipy, these are actually identical escalations. Uh we're going to condense them and just show ESC9. Uh but the

distinction here is that ESC9 is uh carried out using vulnerable certificate attributes and uh ESC 10 is brought about using registry keys. Um so that's kind of the the backend distinction but for our purposes we can just show ESC9 to demonstrate weak certificate mapping. So this is what it's going to look like in the certify find output. Uh we have our enrollment flag of no security extension and we'll talk about what that means here in just a second. Um and then ESC9 domain users can enroll and template has no security extension. So ESC9 is going to be the first exploitation path where we're going to actually need control over a second user, not just our low-level user. Um,

so what you need is write permissions at least over one other user. Um, so in this case, our domain user has write permissions over this ESC9 user account. Um, we're going to do something called pulling shadow credentials, which are just outside of the scope of today's talk. Um, but the 10-second version is if you have write permissions over a very specific uh attribute on a principle here. Um, you can actually get like a secondary authentication material that doesn't require you to use right permissions to change their password or anything destructive. Um, so you can essentially get something you can authenticate with. This user will still be able to log in fine and do everything. Uh, they might not even know

what happened, right? Um, so that's what we're going to do here. Certify has a command that'll do it for us. So we'll do certify shadow auto. grab uh using domain users and password uh to grab credentials for ESC9 user. Uh so we get a TGT. In this case, we're just going to need the Nthash just for simplicity here. Uh so we'll use that today. Uh then we're going to use the uh certify account update command and we're going to abuse our write permissions over the ESC9 user. Uh using domain user and password to login, we'll target ESC9 user and set a user principal name of domain admin at besides.lab. Um, so this is where the no security extension and

weak certificate mapping come in. Um, so if we're able to trick ABCS into thinking that we're requesting a certificate as the domain admin, it might just send us one, right? So if we successfully update the ESC9 user and then we're going to do a second CSR. Um, this time we're going to do a CSR as the ESC9 user and that's why we had to run shadow credentials up here. Um, so we get their hashes. Then we can uh use the CA name, the template which is the ESC9 template, the one that has no security extension, and then our target is the CA IP. Uh then we're going to get a certificate for the UPN domain admin.

And then we'll get our uh domain admin.pfx file that we can use here. Um now there is one wrinkle here and that is if we try to off using that certificate, we're going to get this error that says there's a name mismatch between the certificate and the username domain admin. And that's because we currently because we updated that one. We have two principles that are resolving to domain admin right now which is no good. We're going to have to do something here called put that thing back where it came from or so help me. Uh basically all we have to do is update that account again and just set the UPN to something other than domain admin. Uh

so in this case for simplicity we're just going to set it back to ESC9 user at besides.lab. It'll successfully update and then we can off using that domain admin pfx that we pulled before. And this time it'll off successfully give us a TGT and we are domain admin using ESC9. Moving on to our next subset here we have escalations via NLM relay to ADCS. Uh so this is going to cover ESC8 and ESC1. Uh the first one here is going to be ESC8 which is escalation via NLM relay to HTTP. Um and as a quick aside, this is the one that I see most commonly. So I usually see ESC 8 and then ESC1 and then I think uh ESC 4

after that in a order of most commonly seen. Um but anyways NLM relay to HTTP endpoints going to look something like this. So this is our certify find output. Uh but in this case we're not looking at any templates. We're just looking at the certificate authority output itself. Um so down here it'll say ESC8 among some others. We'll just ignore these for now. We'll come back to those. But ESC8 it'll tell us well web enrollment is enabled and the request disposition is set to issue. And uh here's what that looks like. So we can use certify as a relay using the certify relay subcomand. We're targeting our CA IP here which is the 235. And then we're

going to be using the domain controller template. And the reason for that is because uh for simplicity in this lab there are only two machines the CA and the domain controller. Um if we wanted to target a different principle we could do so using uh the machine template or something else. Uh but in this case, we're targeting something that is a domain controller. Um so for the sake of simplicity, we're just going to use the domain controller template. Uh it'll tell us that we're targeting the HTTP endpoint for certificate services. And it'll say ESC8. So it's actually hooking us up here and saying, "Hey, by the way, this is what you're doing." Um from there, we can coers authentication using

another tool called Coercer. Um you can use other things like this, like potam. Uh but for today's demo, we're just using Coercer. Um, and this will actually course authentication from our target which is going to be the uh DC IP 225 uh back to our listening IP. And this is just a WireGuard VPN IP um just to make the lab work. And then we're going to use our username, password, and domain name besides lab. Um Coercer will then coers authentication for us. It'll use some uh automagic kind of exploitation here. We're just going to say continue. And then we're actually going to catch our uh authentication back here in our relay. So you'll see it

comes from DC1. This is the machine account. That's what the dollar sign is for. Uh we'll get a certificate with the DNS host name DC1.bsize.lab. And then we can save that certificate and private key to the DC1 PFX. Uh next, we can certify O the same way that we've been doing for our users. Um but this time we're going to get a TGT as the DC1 machine account. Now with a machine account TGT, uh we can do what's called making a silver ticket, which again is just a little bit outside of the scope of this talk today. Uh but if you you want the 10-second version, silver ticket is basically just a uh a kerros ticket that is for a specific uh

machine or service principle. Uh so we're going to get a ticket for the administrator of the local administrator I should say for the DC1 machine. Um which in this case because it is the local administrator on the domain controller that is also the built-in administrator account. So when we supply that TGT and login with Wii Exec, you can see that we're running who am I, which of course every user always runs for sure. Um and then we're getting the bs.lab administrator output. So this is escalation to a uh machine account using escalation 8. Um ESC11 escalation via NLM relay to RPC. This is going to look very similar. It's just using RPC endpoints instead of

HTTP. Uh so this is going to be our output here. At the bottom you can see ESC11 encryption is not enforced for ICPR requests and the request is request disposition is set to issue. Um, so it's going to look very similar to ESC8, uh, except that in our target, we'll specify that we are targeting RPC. Uh, again, we're using domain controller for the reasons that I discussed before. And then it'll say targeting RPC endpoint, and it'll tell us that, hey, this is ESC11. Uh, then our coercer output is going to look exactly the same. Um, we're going to do coarser the exact same way. Catch our authentication here. Um and we'll get the basically the same

thing DC1 certificate which we can then off and get a DC1 TGT. Uh moving on to ESC6 which was patched in uh May of 2022. Uh this is an escalation via a CA misconfiguration. And if you've noticed most of these are actually unpatched uh because they are considered by Microsoft to be misconfigurations on the part of the organization not on the part of their software. Um but ESC6 was actually patched and we'll see why here in just a second. Uh I think we skipped one there. There we go. Yep. Um so this is our certify find output. So this is the certificate authorities. Uh you can see down at the bottom ESC6 enrollies can specify SAN

and request disposition is set to issue. And then certify actually hooks us up and says does not work after May 2022. Uh but then you get my anecdote again about nobody ever uses unpatched software, right? We never see Eternal Blue anymore. Um so what does this mean here? Enroll can specify SAN, right? That that sounds like ESC1, right? Uh but the issue here is that we're not talking about templates anymore. We're talking about their certificate authority itself. So if we have ESC 6 enrollies can specify SAN for any template. Uh so this is basically a more dangerous ESC1 because it doesn't rely on any template misconfigurations. And this is what it's going to look like for

an attacker. We're going to send our CSR using certify rec uh domain user and password DCIP CA name. We're going to use our built-in nonvulnerable regular uh you know run-of-the-mill user template. We're going to specify the domain admin UPN or whoever we want to log in as. Our target is the CA IP and then we get our domain admin pfx. So we get a certificate. We can off and get a TGT. Uh so no vulnerable templates used here. This is basically every template is vulnerable to ESC1. Uh so you can probably see why ESC6 was patched. Moving on to our final subset of escalations here. Um these are escalations via access control on ADCS objects. uh with a little asterisk here

because ESC14 is technically access control on the uh AD principle itself, not on the ADCS object. It just kind of fits nicely into this group and I kind of want it at the end anyway. Um but this is going to cover ESC 4, 5, 7, and 14, not in that order. So we'll start with ESC4, which is escalation via template access control. Um again, back to my aside from earlier, this is the uh third most commonly seen by me. Um so we have our template name ESC4 up here and then the critical part down here is the right owner principles. So in this case we have the domain users group which means we control a principle

who has write permissions over this template. Um and what does that mean? We can basically make this template vulnerable to things that was not previously vulnerable to because of our right permissions. And it identifies down here for us uh ESC4. It's going to say domain users four times. And that's because we have full control right owner right tackle and write property enroll uh permissions. Uh but it'll say domain users has dangerous permissions. So here's what this is going to look like in our uh ESC ESC4 template properties. Um you can see we're using the domain users principle or group I should say. Um and we have full control in this case. All you need is write as long as

you have another uh control of another principle that can enroll. Um but all you need is write. We're just going to do full control for simplicity. This is what our exploitation is going to look like. Um so you can see it's just one command here. So the certify template command which will alter a certificate template. We're going to use our basic off using domain user and password. We're going to use our DCIP target the template uh ESC4. And then this save old flag is not actually necessary. It's just kind of a nice guy hookup for the organization that you're actually uh carrying this out against. So what the save flag will do is it actually saves a copy of the

current configuration of the template and it'll save it to this ESC4.json file. Um, and it'll do that before you actually make the template vulnerable. So, it's just kind of a uh like a homeboy hookup. So, you can set their thing back and uh put that thing back where it came from or so help me as it were. Um, so what we can do from here is if we run a new dirty find command, you can see we're targeting the same template. Uh, but now we have ESC 1 2 3 and 4. Um, so it's giving us ESC 2 and ESC 1. And then if you remember, if you have ESC2, you also have ESC 3. Um

something else to note here is that now instead of being a specific principle, it's authenticated users can enroll. So we now have ESC 1 through 4 using authenticated users, not just uh the specific group, which in the previous case was domain users, but if you want to think about it, that could be any group that you have uh permissions over. Um from this point out, you would go ahead and grab your your proof of concept. You would tell your client, hey, we uh came in and smashed and grabbed and broke everything. Um, and then you would go ahead and use that save old if you are a nice guy and set the configuration of this template back

to what it was before. Um, I'm going to skip that for this case because I for the purpose of time I trust that you believe that I can use ESC2 and ESC1 since we did them before. Uh, moving on to ESC 7. This is escalation via CA access control. And this actually has uh two specific permissions that have two distinct escalation paths. Um, we're going to show both of them real quick. Um so again using certify find on the certificate authorities uh you can see these permissions down here the manage certificates and manage CA permissions. So the ESC7 manager user has managed certificates permission and then the ESC7 CA manager user has managed CA permissions. Um that's just kind of you

know the the name is in the name. Um in our vulnerabilities output you'll notice that ESC7 is not present and that's because as a fun fact we ran the certify find command in the context of the domain user. Um, if we were to run it as a principle that it can actually target, we would get ESC7 and that would look like this. So, it would say ESC7R manager user has dangerous permissions. Uh, so certify find actually gives you output in the context of the user you're running it as, which is kind of a fun fact here. Um, in the uh besides CA properties, we can see our manager user has the issue and manage certificates

permission. Um, this is the one that we're going to be exploiting for our first path. Um this is a vulnerable template that is vulnerable to uh escalation one. The only difference is uh that the manager approval sorry manager approval is set to true. Um now if we remember back to ESC1 I said that manager approval had to be set to false. Um so this is where this comes into play. So keep note uh the ESC7 manager template is vulnerable to ESC1 but requires manager approval. This is what our exploitation is going to look like. We're going to send our CSR using certify rec. We're going to use our ESC7R manager user whose password is ESC7 password uh because they clicked

through the second half of their user training. Uh we don't have a we don't have a symbol yet, but we do have a caps and a number. So that's uh an improvement at least. Uh we have our CA name, our template, which is the ESC7 manager template, and then we'll specify our SAN using the UPN flag for domain admin. And our target is the CA IP. In this case, we're going to fail to request that certificate. And that's because the certificate request is pending approval. So if if the uh manager approval is set to true, before we can issue that CSR or before the CA will issue that CSR, it needs to get approval from a uh a principal that has

that issue and manage certificates permission. Uh which in this case we do. So our request ID is 15. In this case, we're going to save our private key to what's called 15.key. Um and we'll supply that here in just a second. We're going to go into the CA using Certify CA. We'll log in with our uh ESC7 user and password. Uh the CA name is the same and then we're going to use the issue request command here which will issue request 15. Um and it'll say successfully issued certificate. So this is us right now, right? We're the manager. We can approve that. Um then we can do another certify rec command. We're going to retrieve

that certificate this time. So we'll retrieve 15 and then we get our uh certificate with UPN domain admin. We're going to combine that with the 15key private key that we saved from up here. And then we'll get our domain admin pfx. And then we can off get a TGT. We are a domain admin. Now um so this is the first escalation via uh ESC1. Uh here's the second one. So this in this case we have the CA manager user who also it says has dangerous permissions. That's because the CA manager user has this manage CA permission. It'll look like this in the MMC snap-in. Um and this will be ESC7 CA manager user has managed CA. Uh note

that they do not have issue and manage certificates. Uh but because we have manage CA, we can actually give that permission to ourselves. Uh so here's what that'll look like in our certify CA command. We'll use the CA manager user this time who has the same password, ESC7 password. Uh because password reuse is a thing that we see in real life. Um the CA name and this add officer command which is going to add the issue and manage certificates permission to the ESC7 CA manager user or whatever user we supply in here. Um in this case, we're going to give it to ourselves because we can also exploit the CA manager permissions. Um and then our target

which is the CA IP and it'll say successfully added officer CA manager user on besides CA. Uh so this is us right now. We can use manage CA to give ourselves managed certificates. Um then we can do a CSR using certify rec the uh ESC7 CA manager user who is now uh has the issue and managed certificates permissions uh the same password CA name. So in this case we don't need a vulnerable template in this in the previous case we did. In this case, we're going to request from the subca template, which is a privileged template that only a few users uh such as users that are in the enterprise admins or domain admins group

should be able to request from. Um, but in this case, because of our CA manager permissions, we should be able to do so. Um, so our UPN is domain admin. Uh, the target is the CA IP and it'll tell us a different error this time. So, it'll say got error. The permissions on the certificate template do not allow the current user to request this type of certificate, which got a little bit cut off, but it's like huge output. So just bear with me here. Um, and this is because again we're not able to request this uh as our our CA manager user because they're not a domain admin or enterprise admin or one of those other

principles that can request from CA or from subca uh template I should say. So we're going to save our request ID at 16. We'll save the private key like we did before. Um, but in this case we can actually just go in and say certify CA. Go ahead and issue that request. And the reason we can do this is because we have a permit, right? Not to worry. I can do what I want. So here it will issue that certificate and then we can retrieve the certificate even though uh it has the privilege template. We now have a certificate for domain admin.pfx. Um so that is the CA manager uh output path. It's a little bit more

dangerous because you can request from nonvulnerable templates but it requires additional permissions because you have to have the C CA manager permission in addition to the issue and manage certificates. Moving on to ESC 5 escalation via implicit CA access control. Um so this one is going to be um another one of these oversimplification ones. Um there are several princ or several paths to getting ESC5. Um the simplest to explain though is if we have a user that has uh local admin rights over the machine where the CA is running, we actually gain uh ESC7 with both permissions. So we'll have effectively manage CA and issue and manage certificates permissions. Um so you can see that here

using the ESC5 user who has ESC5 password which is a password convention. That's also something that we see commonly. Um they can request from template subca. It'll say hey you can't do that. Um we'll request or we'll save our request as 18. Um I missed 17 because I got a bad screenshot. So bear with me. It's going to be 18 now. Um we'll save that to 18. We'll issue our request and retrieve that quest. It'll package it with the key. And now we get domain admin pfx. Uh we can then off get a TGT and we are a domain admin via ESC5 here. Okay. And our last escalation that we're going to talk about is escalation

14. Uh so ESC14 is escalation via write access to alt security identities. Um, so this is where I had my asterisk before because all security identities is a permission on the uh AD principal itself and it basically identifies uh kind of similar to a subject alternative name, but it identifies other uh identities that that uh account or principal can log in as. Um, so if you think about it, it's going to be exploited in kind of a similar manner to ESC1 except for you're not exploiting a uh a template itself. You're just exploiting the principle. Um, and that's also going to rely on some concepts of certificate mapping which we exploited back in ESC9. Um, the only complications here

with ESC14 are that for one, I don't believe certify currently supports it. Um, so we would need to introduce a whole bunch of new tooling which we are like right at the very end of this talk here. Um, and the second part is that this is actually the table of requirements for different uh iterations of ESC14. And this is what the audience looks like right now trying to read this. Um, but just because of time, we're going to uh skip this one. So, I ain't reading all that. I'm happy for you, though. We're sorry that happened. Um, but yeah, ESC14, just think, hey, it's a uh it's a similar escalation to ESC1, except for you don't use the

template. Uh, you just use a whole bunch of different uh permissions on the AD user itself, and then you get certificates uh via weak certificate mapping. Um, and that brings me to the end of the escalations here. Um, this is the point in the talk where I would say, "Hey, uh, if you need to find me on Discord to ask me any of your, you know, well actuallyies or whatever you have, uh, you can do so. That's my Discord username. I'm in the Bside Charlotte Discord." Um, and then my LinkedIn up here on the top right from uh, it's it's my name and then a picture of me from when I was still young and full of life.

Um, if you need to find me on LinkedIn, just do uh do say, "Hey, I have a question from your Bside Charlotte talk or uh, you know, whatever the case may be, just because I kind of get a handful of uh, LinkedIn requests that I kind of ignore. Uh, but if you send a message, I will know that you're from this talk and I can add you." Um, but yeah, that's it. Uh, obviously there's no questions in the recorded format. Um, if I do have time at the uh, the live one, I will do questions there. Otherwise, like I said before, just find me on Discord or on LinkedIn. And that's all I got. Thanks.