Lying to your fACE: Deploying an ADCS honeypot the easy way

gone. >> Hello everyone. >> Is Is it working? Can you all hear me? Okay. So before we begin, I would like to apologize in advance. Uh yesterday I strained my neck. So if you do see me turning around like an idiot during a presentation, that's the case. So hopping onto presentation, honeypotss. As majority of us already know, implementation of a honeypot is no trivial task. But today, former colleague and I will show you an easy way to implement an ADCS honeypot. Uh I'm Yosip. I currently work at Infigo, cyberc company as a penetration tester and redteamer. >> I am Zrao. I work at spawn detection engineering and research. I used to work with him, but obviously there was some

skill issues, so we're no longer together. Okay, so now let's jump right into it. So what is an ADCS? An ADCS is a Windows server role for implementation, issuing and managing PI certificates. Those certificates can then be used for encryption, signing, client authentication, uh computer authentication, etc. Also it's important to notice that uh other than standard password authentication you can use certificates via pa init or PKI authentication to authenticate on domain without using your password. So what do we get when we install ADCS you get confidentiality implemented through encryption. You get integrity implemented through digital signatures. And lastly, you get authentication implemented by associating certificate keys with computer users or other devices. So, ADCS does have a few components and

I would like to point out a few that are actually most important. First is certificate authority used for managing and issuing certificates. certificate template that actually gives the attributes for your certificates like the name uh PI ex extension uh EKUs or just a template name etc. Certificate enrollment web service and certificate enrollment policy web service are used in conjunction because in order for users to enroll or review certificates via HTTPS protocol you would use certificate enrollment web service. How do we get the attributes and policies of those certificates is issued by certificate enrollment policy. Certification authority web enrollment is a GUI based basically a browser that allows the users to enroll certificates via browser. And lastly, network device

enrollment service is used for offline devices such as router or uh switches to enroll certificates from ADCS. So can ADCS be vulnerable? Of course it can. Spectre Ops in 2022 did a research actually anyone who didn't read it I recommend it. He did a research on few of techniques that can be used if ADCS is indeed implemented in domain. Uh then we had eight different escalation techniques that lets us get to domain admin rights. Five theft techniques that are I personally never heard anyone talking about these and I actually like them very much during internal network penetration tests are used to steal certificates from a systems uh p three persist techniques for local computer persistence and uh three domain persist

techniques. As of today those escalation techniques more than doubled. We now have 70 of them and most of these techniques are actually based on poorly configured certificate templates. So you're saying we can escalate right? Basically yes most of s techniques will give us the rights to get domain admin immediately. I'm say mostly 99% and I would like to point out these few because these are important to our presentation today from 1 to 4 9 and 15. So in order for me not to repeat myself, most of these certificates escalation techniques I already mentioned actually require these four attributes to be implemented and basically that is enterprise CA and allows low privileged users to enroll enrollment rights.

Manager approval is disabled. No authorized signatures is are required and enrollment rights to low privileged user as per template. Other than that, ask one uh actually requires for user to specify subject alternative name in certificate signing request and it needs client authentication or smart car loon EKU to be uh exploited. ESK 2 on the other hand uh needs no EKU or any purpose EKU. ES3 is the most let's say has the most prerequisite to abuse. You need a minimum of two templates. First needs to have certificate request agent EKU. Second templates actually differs. You either need a version one template or greater than two. But the greater than two templates need to have application policy issuance requirements for

certific certificate request agents EKU. Also, it needs all clientation and or smart card loon. Enrollment agents restrictions are not implemented on certificate authority. And lastly, request agents uh signatures are required. So the minimum of one. We have ask 4 that is by far the least uh that has the least requirements to abuse. So it's literally just over permissive ACL over one template. ESK 9 needs to have this flag set up city flag no security extension. This is actually based on a certificate mapping that is set up on the domain controller. You could actually speak literally about that team but I'm going not going to deep dive into that and client education smart and log on eku just as some of

other before. Lastly ask 15 needs to have a version one and certificate template allows users to specify subject alternative name and the certificate signing request. So as you also just mentioned we have a bunch of asks that we can exploit. The thing that we are or we should be generally interested in is how do we detect those attacks, right? So first of all we need logs. We always need logs. It's a blue team curse. There are three of these which are important for us. So first the 4662 event. This is a domain controller event. This triggers any time that a specified monitored operation is performed or attempted to be performed on a domain object. Next up, we have the

4886 event, which triggers every time somebody tries to request a certificate. So, not if it succeeds, just an attempt is enough. And finally, we have the 4898, which effectively says, "Hey, your CA loaded a new template or a template was modified and reloaded or something." So, the sigma rules for ADCS are kind of different than the usual detection rules. They're not reactive, they're proactive. So instead of looking for requests containing SANS, Sigma looks for any templates which were loaded which either contain a SAN or contain a SAN and a potentially exploitable EKU such as client authentication or smarter login. Now these are good. These are great. We have logs, we have sigmas, we have everything we need with the entire

plumbing. The problem is that ADCS logs are not ingested that often. Now there are a plethora of reasons why this could be. Uh clients typically state performance reasons which correct me if I'm wrong. There's like one edge case that I'm aware of for performance reasons. Uh cost reduction because there's a billion requests daily that you need to ingest into your SIM. Knowledge gaps. Some people just may not be able to or do not have the knowledge to enable logging. Ingest that keep the SIM rolling. And the worst part about all of this is that even if you do all the things correct, you ingest your logs, you monitor those logs, there are still two metrics that can severely

hinder your ability to even respond to ESK attacks. So this would be the MTD or the meanantime to detect, which means that if your SIM has a parsing delay or storage delay or you have a cloud SIM, so it goes on a polling rate, it's not perpetual, you can get slowed down there. So this is typically a minute up to 5 to 10 minutes depending on your SIM on your config and the meanantime to respond which is okay now I have a detection from this moment on our MTR starts rolling this can obviously depend on the socks response time their internal procedures the technical levels and everything else and if you're like me you don't want an attacker anywhere near

your network let alone giving an attacker domain admin rights for half an hour so there needs to be a better way. Now, we had several discussions regarding honeypotss today. So, let's see what even a honeypot is. How do we implement this? Well, first of all, a honeypot, at least what GPT said, it's a deliberately vulnerable decoy system designed to lure attackers away from real assets. Now, this is very nice, but there are a few other prerequisites for honeypots. First, they should never be touched by genuine activity, legitimate users. You can't use an existing file share as a honeypot. Don't. Secondly, honeypot if set up correctly, they should be a trip wire. So if anybody touches those, that's 100%

detection. That's insanely high fidelity. Typically, this is somewhere in the range of 95 to 99%. There's always that Nessus or Qualis or something that's pinging those those honeypotss, but you can set that up later. Next, we need a honeypot to be secure. You can't expand your attack surface by incorporating additional defensive mechanisms and it needs to be either hard to distinguish or basically indistinguishable from the real thing. So an actual vulnerable system. If you'd like to play with these u in your free time, you can use Canary tokens. U I'm not sponsored. They're just a cool technology that lets you basically craft your fake credit cards, fake DNS entries, URLs, whatever you'd like, and plan them as you go along with your

life. Now before we dove into the ADCS honeypot, we decided to look at some of the previous investigations people have done and there are the three ones which we would like to highlight first and the oldest one was done by Paris in I believe 2022 where they created an ask for template which when modified would trigger an alert in their monitoring solution. Now it's very important to keep this in mind. S Paris did this honeypot with the idea that you have their monitoring solution on the endpoint, right? Why is this important? Well, if you have an ES1, which typically the flow goes ask4, we convert it to SK1, right? Because we have weak ACL. What Saris wanted to explicitly state is

uh template modifications which are logged can be acted upon if you have the solution. If you don't, you suffer from the same consequences we mentioned before. So the MTD, MTTR delays. The good thing about this is it does not require the deployment of a new CA. So you can use your existing infrastructure, but the bad thing is that the vulnerable template can be deployed on other CAS. Now this might not seem that terrible, but you may not have logging set up on those CAS. You might not have agent collectors set up. There might be some firewall issues. There's a bunch of things that can go wrong, right? And this is not necessarily a bad thing, but it's like a

bonus. It only accounts for S4 attacks. The better version is Seption published by Sur Labs who creates an S1 template instead of an S4 and they did a slightly better job. So they created a new CA on that CA. They deployed a policy module via teams. Now a policy module is effectively an XML file implemented through a DL which tells you hey if your certificate request does not match this specific requirements it cannot be issued right however the bad part is that you still need a new CA and once again the template is still available on other CAS we do not want that ideally there's two pathways we can take either don't deploy the CA or don't deploy the

template on all CAS or if you can deploy it, make sure it's not actually vulnerable, which is what we're going to touch. And finally, tame the asserts, which is not really a honeypot per se, but can be used as a honeypot. And the great thing about terts, which as I mentioned is a policy module. It can be used to enhance your existing detection. Why? Because theme iserts comes with its own proprietary set of logs which can tell you exactly hey somebody requested this template with this attribute which does not match the spec. Okay. So the good thing about themeerts is it's generally a good policy module to deploy on your PKI servers. But if you have a

bunch of templates, a bunch of requests, a bunch of people or the other extreme where you have like two people in your IT staff, it can be cumbersome to maintain and deploy. Okay, now on to the fun part. Uh so how this idea came to mind? Uh the correct answer would be under the shower, right? Just kidding. Uh during one of our mutual red team exercises, me and my colleague actually this is not the exact example of course we came up on one of the templates that as per certify seem to be vulnerable to ask 15 right but even as certify states I don't know if you can see it it is only applicable if the environment has not

been patched there is also one more case that we can fix this but I was thinking to myself This could be very easy way to implement a honeypot that's stupid enough because during a red team engagement let's say or maybe some a is desperate and he needs those uh privilege escalation so maybe he will request it right so now let's check out how this works so basically ask 15 implements additional application policy that was not there client authentication and then user can simply sign to LDUP and get those administrator rights from the loop priv user. Like I said before, there is additional way to fix this without uh implementing a patch and that is simply set up a registry key on the

CA that will deny all application policy used on certificate templates. So what would happen if we implement this? No more signing to LDUP on domain controller. This is cool and all but during our other research we came to more fun solution. This is very simple and to be honest not so fun. So now let's go to the fun part. I will show you the two templates both like certify says vulnerable to S1 right so I don't know how many internal network penetration testers or red teamers can anyone raise hands who is doing internal network penetration testing. Okay, so both of these think think in your mind like both of these are vulnerable, right? You cannot actually see any difference.

So let's try to abuse both of them. We should get those domain admin rights on the boat. First one ask one trust me bro gets our administrator certificate. Very nice. But the second one fails. I purposely hidden the error part because that would spoil the fun. But this is I mean during the internal network penetration test this would be ah I don't care but during a red team engagement this would be very depressing because we thought this one was vulnerable. We thought we're going to get domain admin rights before lunch as they say but that's not the case. So what do we do? We can check with another tool. We have certify.net implementation of certify or vice versa. I don't know

who did the first. So we have s1 trust me bro. It says literally template has client application EKU and allows enrolls to supply uh enrolling to supply the subject right vulnerable the one we saw gave us administrator certificate right so let's see the difference pay close attention to this >> one more time >> one more time yeah so stupid right nothing but the name changes and I didn't cheat this is legit output no We have no an answer to this let's say bug. Let's try another tool. This is locksmith PowerShell tool that checks also for v vulnerable templates. Same stuff right? Same stuff. Both are critical. Both uh domain users can provide subject alternative name and

it's CSR. So then this doesn't give any any additional answers either. And lastly to do like a real OG like a gigachad you do LDUP query right LDUP queries are the most I actually the best way to enumerate templates the only issue is not many people can actually determine if this wasn't named ask one if it's even vulnerable right it's very hard to parse this thing and also via LDUP we can actually see what's wrong with this template you would see it eventually it's very very hard if you compare literally normal template but it's very hard trust me on this so what do we do we don't know the issue right now we so what do we do we say it's not me issue

it's not tool issue right the tool is well known it's client network issue there must be something wrong with their CA and what would happen let's say we play literally a red team engagement we already told our boss our seniors trust me I have domain admin rights we will patch this up real quick and then you get that one fail luckily for us. We have S4 template which has much less requirements uh in uh in order to abuse it unlike ES1 we literally need just uh misconfigured ACL's and as certify states it's vulnerable right user has dangerous permission if you check this out we have write duckle principles that lets domain users change the duckle to write on a

duckle okay but we are not stupid enough we won't going to request the certificate uh just yet we're going to first check via another tool certify that also tells us template has insecure delegated permissions and if you see on enrollment per uh I'm sorry on object control permissions we have write property domain user right so users can write the property of a template another plus for us let's do another check we have ask for that also says it's critical domain users have granted self-write property and generic readrs on this template So now lastly what I added in specifically for ES4 I added an enumeration via beacon object file and we can also see ask for template domain

users with right property all rights. So we are good to go. We'll we'll patch this up. It's it's done. Red team engagement is over. Right? We can request we can change the attributes in order to modify this template to be vulnerable. We are good. Right? Then this happens. We get user low priv I guarantee you he is inside domain users it's very hard to remove a user from domain users group in active directory trust me on that doesn't have permission to update these attributes on ask4 so we don't know what is happening but we already told our boss our seniors we have domain admin rights and I I will simply just show you a simulation of

what would happen during one of red team engagements your seniors would be like where is the main admin right standing like monkeys? Your boss already knew you ain't getting those domain admin rights anytime soon or maybe never. He would just send this right and the rest of your pentesting crew would simply say that that is skill issue. You as a rational human being have only one thing left to do, right? You got to break that computer down. But that's just a joke. So now I will tell you how actually how we did this actually by doing it manually. What are templates attributes and its ACAs access control entities. First let's check on that S1 template we

show earlier in the example. We can see this is an object. These are its uh users and security descriptors on this object. It's actually quite easy to understand this. Just using my cheat sheet. we can simply get the rights we need. No, I'm just kidding. We're not going to do that. It's very hard, very tedious. Other tools are going to do it for us. This is a zoomed out example of all the uh ACEs on our S1 template object. So, let me zoom in on this. And most of you can already guess what is wrong here. And the correct answers would be the first ACA, right? We have on our object ask one template we have AC X is denied

object Ace okay for Y denied we have denied for read property nice what read property that would say object ace type the only let's say nonhuman readable stuff here and for who is this implied security identifier will tell us anyone who is administrating domain knows that that air ID the last three digits is actually relative identifier for domain users so What can we conclude out of this? Domain users have read property denied on a certain uh object. So let's say let's see what this good representation means. Simple Google will do, right? So MSPI ARI signature. So I already mentioned this correlates to those signatures required. Why would we hide an attribute from domain users? Why can't they read this

attribute? It's literally dumped. The answer is quite simple. As certify as certified and many many other tools do not even check ACAs on an object certify if you can't read if the template requires manager approval authorized signature it will default to zero. So no need for manager approval or signatures required right because I can't read it. So this is where you get the idea right this is that point what we did in this honeypoint it's actually quite simple when you look at it how to do it CA is actually used for managing your templates but CA won't be enough right because templates on a CA don't have the entire ACA list we have only these like five full control read

write enroll and roll we can either allow or deny them where are the templates actually stored they are stored on the domain controller in domain configuration part in a public in the services public key services I did use a different uh template but that's not the issue we can see that if we click on advanced on a security we will get the list entire list of attributes of one template and it's very simple just clicking deny on a read of one attribute and then when building a template we set either signatures required manager approval any of that and template will no longer be vulnerable, but all of these tools will tell you it is. It's quite the easy way

to set up a honeypot. And lastly, this is just a short list of uh ACAs we actually used in all of these previously mentioned uh vulnerable asks. So we have we can hide ARI signature enrollment flag template schema version and PI certificate application policy certificate name or extended key usage. >> So it's working. Yeah. Now that Ysip has given you an overview of how this thing actually works, we are still missing the second part which is actually detecting when somebody is tampering with our honeypots. So let's catch Winnie in the act. Right. First, we need logs. Once again, I'm here to tell you we need logs. Let's enable the logs. We need 4886, which tells us, hey, somebody

requested something. The way we do that is twofold. So, first, we're going to go to our audit policy on typically on your DCs and say, hey, enable auditing of certification services. Success events are enough for this. I like to enable failures in my lab as well, but that's besides the point. And the other part is we need to go to the actual CA and enable auditing of uh certificate issuance. Right now let's go and request a template and we get the 4886 which states hey this was the request ID this was the requesttor this was the template name the subject alternate name the application policy which was injected if there were any and so on. In this case,

and this was a honeypot template, we also get the 4888 event, which states effectively the same thing except that there's a different message stating that DCA denied this request. Bless you. So, those were non-ES4 events. About 4, we'd have to take a slightly different approach. Why? Well, the first approach relies on the fact that somebody is going to come, they're going to request a finished template, which is vulnerable. Ask for templates by default do not necessarily have to be vulnerable. The only requirement is they have a vulnerable ACE which means someone can come in modify the template and then make it vulnerable. So we need to take a different route. The way we do this is using everyone's favorite

sackles. I know there's at least one person in the audience who loves sackles. So what do we do with sackles? We are going to enable directory service access logging for failure events. Once again same principle applies. This is going to trigger 4662 events in our event viewer every time somebody tries to do something with a cycle monitored object. Now, what are we monitoring the template? More specifically, we're monitoring for any failed rights from domain users because as Ysef mentioned, we are restricting domain users in this case whenever they try to write any of these attributes. Now, you might notice this read permissions here. I'm not going to get into that. It's a long story. Okay, let's detect that. We

trigger an ask for event using certifi. We tell it to write the default configuration. The configuration update, sorry, fails and we get a 4662 failure which states, hey, this user requested this template and they tried to write the discretionary access control list. And that, my friends, is how you catch highly sophisticated APS in your environment. exploiting highly sophisticated vulnerabilities such as ES1. Now that's cool and all and you come to your sock client and you're like look I can explain all of this and the client is fuming. They're like you want ADCS logs. You know how much that's going to cost? You want sackles? I don't have anybody to do sackles. And then you come

to an incident. Things usually look like this because if they had a SIM, they probably wouldn't have had an incident. It sort of correlates. So what about the people who don't have SIMs or as the picture would say no logs? Well, no problem. We can use offensive tradecraftraft for that as we'll see. But first, let's see what problem we actually need to solve. So many organizations with fewer IT staff lack the resources, the knowledge, the time or just any the staff in the end to manage both of their users and reset passwords and fix laptops, reinstall those things and then still take care of ADCS, right? Plus, that's a sort of niche thing. The good part for

us is that this usually correlates with the amount of logs we generate. So the fewer people, the fewer logs, I would hope. Now, this will be important later on. This means we need a solution which is easy to implement. It's high fidelity. It's pretty black and white. Whenever this fires, that's an incident. There's no need for you to investigate any further. And it requires that an alert can be fired without a SIM. So, Teams Discord Slack Telegram name your favorite communication channel. It has to be available. And finally, it's reliable enough for smaller orgs with once again no log aggregators, no SIMs, no nothing. We can use WI. Now, what exactly? I mentioned WI enabled

canaries. But first, what are canaries and why do we call them canaries? I also mentioned canary tokens. Well, back in the day, coal miners used to bring canaries with them in the mines. And every time a canary got sick or a canary died, that would be a sign for the miners to get the hell out of there because there's some toxic gas leaking or or something else. The same principle applies. So we can generate a webbug URL. This effectively triggers every time we visit that. The Canary console is going to ask us, hey, give me some email or even a web hook is available and just tell me how you want me to remind you of this alert. Why did this

fire? Once you do that, you get a nice little URL and it also states, remember, it gets triggered every time somebody visits that. So, what actually happens when we visit that? You get a nice image of a supposedly round globe of the Earth. I'm not going to get into that. You get an email and you get an alert in your console. So, that's part one. The other part regarding WI is actually fairly simple. The thing with WI event subscriptions and the offensive part of WI is that an attacker can come and set up persistence in a way where they can say hey every time I fail a login with a specific username I want you to fire off

a payload and that's how I regain access to the domain. We can use the same principle to our benefit. So instead of saying any log on fail we can say whenever there's a certificate request with our template name. So a certificate request for our template. We can fire off a PowerShell script. The script does nothing except fetching the latest request event for our template and literally sending the event message to our console. So let's try that. We can use certify to enumerate the templates. We find one. All of the requirements are satisfied. We don't need uh manager approval. We have zero authorized signatures. Of course, the request fails, but because we requested a template that there was

that 4886 which fired, our WI came across that and fired off a script which pulled the data from this event and triggered an HTTP request. Now, we've gone through a lot. We've gone through sackles. We've gone through manual setup. We've gone through what even is a honeypot. We've gone through all of the esque types. We've gone through a bunch a bunch a bunch of things which if even slightly misconfigured can end very badly for your domain. So if you forget to change the value of the RA signature even if you apply apply the deny read that's still a vulnerable template. So what Yseph and I decided to do is let's automate this first. Let's automate it

so we can reduce the number of mistakes, but also let's automate this to give the people who don't have a lot of IT staff a fighting chance against script kitties at least because let's let's hope that an AP is not attacking a 50 person company. So what did we do? We created lie. So it's not certifiy, it's not certify, but it does lie to you quite effectively. We would say it's an open open source PowerShell module which creates or has the ability to create es one through 4 9 and 15. We also could have done 13 but that was uh not not very nice and easy to create. Plus it's not really found in the wild

anywhere. Uh we also added the support for WIS or canaries for non-es4 templates and we also create the failure cycle for the S4 template object. The script is available on GitHub. It has an MIT license. You can do without whatever you like. It's open source as it gets. The only prerequisites are effectively you have ADCS installed. How does the tool work? Well, this is just a help. So, it's nothing too important, but it actually states you can create a certain template, you can remove a certain light template, and these are basically all the types we support. So, first we want to create a new template. It's going to be an SQ1 template called bside zagreb.

We use canary tokens for this one. The script will modify the local GPO. So keep this in mind if you're deploying this to production. Make sure to change those settings uh on the DC as well. And it pops open the MMC console prompting you to change the audit policy on your CA. Once that's done, or hopefully that's done, you get a prompt to enter your Canary token URL and we can move on with actually creating the certificate template. So, first we create the template obviously publish it to the CA and then we ask the user if applicable. Some templates automatically choose their own property. If applicable, which property do you want to hide? We typically recommend RA signatures

because it's less weird to see a template without RA signatures than it is to see a template with no enrollment flags whatsoever. But that's up to you. Once you select your value, we're going to say, okay, we're modifying that to a safe value. So now this template actually requires a request agent signature and cannot be issued without one. Right? Once that's done, we uh hide the RA signature property or your property of choice with the safe value and you get back some metadata about your template. Now, if we try to abuse that with certify, we uh enumerate the template. We can see it's again vulnerable. You can't see, but it's vulnerable to S1. Uh if we were to try to request that via

certify, we get an RPC error stating that hey, you need a signature. It's required by the policy. And of course, 4886 fires in the background sending the canary an alert. If you want to remove that, just run remove the template. It unpub unpublishes it from the CA. It removes it from AD. and it goes ahead and checks if you had any WI subscriptions whether or not you would like to remove those as well because they can be a pain to remove manually. Just keep in mind this does remove existing nonsilite templates from your ad. So make sure not to mistype anything. Okay. >> And thank you all for coming. Uh we'll be taking donation for this tool. Just

kidding.

Since we have time questions, maybe think about it. I'm just curious one thing, maybe I missed it. So, uh, certify uh says that it cannot create a new certificate because it cannot read uh a field, right, do the properties, right? >> Uh, a bit different. uh it cannot read the property but it's going to use RPC to communicate to the CA and tell I want that template but once the CA comes back and checks and says hey that template needs a signature or management approval >> it's going to execute the function it's going to either generate a template if management approval is required but it's not going to give you the certificate until a manager approves it or it's not

even going to issue it if a request is >> okay that was my question because if this certifi is a Python script and it's probably to impact or something to connect with RPC. Uh so is it just certify being dumb and not ABA to able to send a request because he does not cannot read something or it's it's tools being done. >> Okay. And mostly you do not want to use open source tools especially during a red team engagement because the proper like and like I said before the OG way would to add up query template. >> Yeah. Not many people do it actually and not many people know how to do it. That's I would say skill issue.

Yeah. So, how many of you have done any kind of red team engagement pen test and tested your templates? One, two. I know some are shy over there. Yeah. Three. >> The other ones aren't aren't pentesters. That's fine. >> Yeah. Any questions? >> Oh god. >> Yeah. Yeah. No. No. Please stop the cameras. >> So, >> roll credits. >> The the access control list, the deny access control list is on domain users. >> Yeah. >> We >> Yeah. >> Access control list is specifically on a template we want to avoid being abused. So domain users can't read specific attribute on our honeypot template >> and if we remove ourselves from the domain users group >> that's good question you needed

>> it is it is a good question we were actually evaluating that because >> you need domain admin for that to remove yourself >> also also because most of users correct me if I'm not mistaken they have domain users as their primary group and you do need domain admin rights to remove Another thing we actually did get in mind uh you could actually use machine account right? >> Yeah. >> Yep. But uh we we were thinking about it not to do it to do it. You can actually do it. It's literally just don't use the main users, use also machine account. But that would be quite quite tedious to manage. And also we were looking into

perspective like most of the red teams actually start from you domain users >> and I don't think many people would like think why did I don't enumerate the templates with machine account but this I like I say it is another option of course >> what would happen if we put authenticated users >> uh from what we tested I'm assuming the would have an issue with reading those templates so you could play like we talked you could play along with the ACL ordering or the ACE ordering. But that was that's a good pull request. Please submit that. Yes, >> I will. I will. >> Yes. >> Cool. >> Uh I was wondering about one thing recently. So uh so when I first heard

about these issues years ago, it was like well okay so everything in normal enterprise environments is you know centralized you know IT environments you know IT department creates m u m devices machines they enroll them they provision the cert the device certificates they create users they get their certificates there is actually no need for a user to be able to do anything basically but then I heard uh last year Then Microsoft in their own wisdom is saying okay you will you're going to have agents soon you have more than one agent for yourself because you don't you want personal agents to work with your cred credentials not with some admin credentials but you don't want full

scope for every single agent to have a full scope of your credentials. So you want to have like 17 different agents and 17 different agent identities some principle name some SPN or something in that regard for each of them scope to a smaller range and you probably use certificates for it. So will that incre change you know our setup where we will have to again grant some kinds of broader access for end users or will some application you know do that for them or what do you think will we have a bigger a new big problem with a ADCX very soon? Well, because of all of that, >> it is quite thoroughly researched. I maybe maybe new exploits come every day

like like we've seen almost doubled from the primary research Spectre Ops did. So, who knows? It's Microsoft. >> Yeah, we like Microsoft. >> Yeah. >> Uh, any more questions? >> Don't be shy. I know somebody from the first row supposedly had a bunch of questions. They're staying silent, but okay. >> In that case, catch them during the coffee break. Thank you very much, guys. We are back in 17 minutes.