Fantastic Persistence: Creative backdoors & where you will NOT find them

Thank you. So, urugat and uh it's great to be back uh in Budapest. Actually, it's great to be back in any Bides. I'm a big fan of besides events. I really love the community events all around the world and I try to be as in as many as them as possible uh and especially in Budapest. So, good to be back today. Uh I'm going to talk to you uh a bit about um how not uh back doors in Microsoft environments and uh this year uh I will um dive into some very specific ones in the infrastructure that allows you to persist uh for a long time uh inside the on-prem and from there to move to the

cloud etc. Uh and uh just to kick things off um let me just start by saying by doing this. So you're in the blue uh stage blue track. But to be honest uh even if you're a red teamer, right? or a blue teamer or if you're a purple teamer or if you're an old school guy uh like myself uh or maybe if you're you're just not no uh cyber security gender specific that's okay because uh I I hope and want to hope that we have something for everybody uh this this morning. So uh what we're going to talk about so we're going to talk about sorry okay so we're going to talk about uh like I said some creative persistence uh

backd doorors in the Microsoft uh uh infrastructure uh mainly active directory which is the Microsoft mainframe which is here to last on onrem for many many years to come and especially more importantly is how to detect and mitigate them. So I'm I'm going to show you how to attack, how to use it, and also how to abuse it and also how to uh identify and mitigate it along with some open source tools. And when I say persistence mechanisms, I mean it's not a hit and run. It's a like advanced persistent threat, right? essentially like

advanced. >> So advanced persist and thread. That's what we're going to talk about today. Somebody that comes to stay in your network for a long time. Um a bit about myself. I celebrated recently uh 37 years to my first uh prompt. Uh it was in the 80s. It was in times that you had to know hardware in order to really hack uh computers. Today you don't really have to know everything anything. Uh maybe English just to use Genai. Uh but I've been around with computers um I've done Red Purple whatever consulted to Fortune 100 companies. Even got a chance to work for Microsoft in times that they didn't like Linux and I had Linux on my

laptop which was fun. Uh which was really fun. Uh I've been around in um not only but mainly in Microsoft technologies uh also part of Javelin networks which we sold to semantic etc. And all in all in my spare time I try to balance it with anything else but technology. I really love to be offline uh whether it's to uh help volunteer in different uh communities uh to fly airplanes or to play in my uh band oriental rock orchestra. It's hard to believe that we reached the year 2025. I'm no domin directory. Uh it's uh it's hard to believe that it's been like uh the fourth decade for the life of active directory since the '9s. Uh and still

all the vulnerabilities are there. Everything is bypassed, evaded, obuscated. Uh and to be honest, the more that the time flows, uh uh it's very comes more and more easy to hack uh to hack into systems and uh more and more impossible to defend. Uh but still I have some hope and especially when you add to the mix uh the cloud especially in Microsoft the anti environment uh which is someone else's computer with zero tolerance to impact uh that really comes uh becomes really fun. Um so the idea is that for the purpose of the backd doorors I'm going to share with you now is that uh really uh persistence privilege persistence is just the beginning in the Microsoft networks uh

domain admin or access to a global admin etc is achieved in a matter of minutes. My team the average is below 7 minutes actually anything above 5 minutes gets left in the team. uh and this is really when the basics are not happening well right when I say less than 7 minutes is postnak so it's after you have a valid IP etc not even a credential um so really really situation is very bad the attack surface is is uh huge uh but for an adversary that wants to dwell in your network for a long time to be in the background uh there are uh ways to be stealthy and stay there and those persistence uh mechanism can help. If we

look at this anatomy uh anatomy of an attack versus defense, you see the routine you see the uh steps of the that you know maybe for Maitra and other frameworks on on the top from the attacker perspective adversary um attack phases and then below the defense uh routine monitoring detection etc. So it's clear to see that and to understand that the attack the organization essentially us you we live in a zone of uncertainty uh the attacker lives in a window of opportunity. This is like cyber security in uh 30 seconds. Okay. You all live in uncertainty. If you feel uh that you are certain in things in your network uh tell me afterwards. I want to learn how

and what you are taking. And uh the window of opportunity is all the attacker has. And it's clear to see that the attacker joins in the first patient zero uh point of entry. You detect the attack I don't know maybe after 1 minute, 5, 1 hour, 3 days, never after it gets published on in the dark web. And it's clear to see that the window of opportunity stretches the more as your zone of uncertainty. And uh I've delivered in the past uh multiple talks about how to narrow down this window of uh uh of how to narrow down the window of opportunity uh while of course uh essentially u uh decreasing the zone of uncertainty for the organization. You

can check it out. So first back door admin as the older who knows what it is is admin as the older no hands. Okay. It's been around since the 90s. this technology uh you can see I'm uh now in this demo I'm a normal user user Kai you can see that I'm I'm only a member of domain users like a very very basic uh group uh I'm connected to this domain controller loan DC1 uh funny enough I try to access uh the C C dollar of course I get access denied because I have zero privileges uh but you know uh I try to uh be a bit sassy about it and I'll go to a

privilege group called enterprise admins and you know just straight off the uh management tool the active directory users and computers I'm going to add a user to this very highly privileged group uh enterprise admins which has uh administrative permissions uh on the entire forest and I add a username Ashley apply boom and it works and it works it shouldn't work right Why is my user able to add into enterprise admins? So the answer lies in a system container uh which is buried uh down. If you uh collapse uh your um set of hierarchy in the domain you will discover the system container under that you have admin as the older admin as the older which is administrative security

descriptor holder like a placeholder. Here you have permissions and this is a mechanism created uh very uh back in time when active directory was created in order to uh keep you out uh keep you uh not to be locked out of out of your own network. So for example uh this runs every 60 minutes and it makes sure that certain permissions always get applied every hour uh to make sure that you can access your domain back. like if I took out all the domain admins from all the groups, I can still come back and have permissions and log on. Uh so attackers can actually abuse this because nobody in the room knows what this is. Trust

me, adversaries know. So if I uh uh enter a permission here, it will linger to the entire domain from the domain root and it will linger on all privilege groups. So essentially this security descriptor this uh access control list essentially it's uh built in in uh any domain any windows domain it corresponds with the 16th character of the dsuristic attribute which is another thing worth uh knowing uh this actually this attribute controls uh this behavior of privilege groups and uh the propagation like I said is done by a process called sdrop sdrop we'll talk about it in a second these are u the groups and users that are protected by default. Seat 500 your domain administrator always get

protected and of course all the backup operator, server operator, print operators etc. Uh you have the the slides from a previous talk and also all the tools I will show on GitHub. So um so SD prop by default is something that runs every 60 minutes. uh if you ask Chad GPT or uh other uh AI engines they will tell you uh that there is a registry key also Microsoft documentation says that I know there this registry key doesn't work because I remember Windows code it's a hardcoded thread uh that looks for no registry it's commented in the Microsoft code uh so it will not work however you can uh run a task a specific task task that you

can trigger on the root DSC the root of the LDUP server called run protect admin group task equal one and this will uh refresh uh will uh re rest restep and uh reacle the permissions. So how do you detect this attack? So first you should alert on the modification of this ACL. This is something that about a year ago, it's amazing to uh to believe it, but until a year ago, all the big uh companies including Microsoft itself, uh MDI, the defendful identity, also crowd strike identity protection, etc. had no alert for this. But today, most identity protection uh products are beginning to uh bring bring an alert. Essentially, it's like called a privilege escalation

or something like that. But they don't tell you they don't show you which entity was added. You you just have to go and look look for it. Uh plus they don't alert on modifying the DSUistic attribute. I don't know why because it controls the behavior of your entire domain and any unprivileged user that you see there on this uh on that list should be considered stealthy. Um something else to consider is that if you remove an ACE an access control entry from a privilege group uh but you didn't remove it from the admin as the older that container it will uh reapply in after 60 minutes or less. So you have to um remove that and of course you can

leverage those system but you can also use this script. I published the script invoke admin as the older permission check PowerShell script open source which is essentially it shows you what are the permissions that were added after the domain was uh installed uh from the the threshold the comparison the diff between what should be and what you have today and also you can compare it with the previous run uh and you can also automate the execution of uh this script etc. So uh let's see what we mean here. It's now we see the admin as the older properties and if we add user Kai uh and we give it a full control let's say on that container on that system

container right so we're adding this permissions on this system container and if we apply it uh then and we uh trigger uh SD prop so the permissions will linger to the entire domain and the protected groups. So now when we go to administrators for example domain admins, enterprise administr admins, backup operator of course we see any privileged group uh now gets full control of that user automatically uh of um of that account and uh of course if we uh remove that account you saw that uh we can go to the security of that account and we removed it. So now it it doesn't exist. But if we reapply uh admin as the older permissions, so

the permission persists. So the persistence comes not from the multiple hundreds of objects and privileged users and and the main privileged groups. It comes from that single container and it will continue to persist until you remove the permission from the container itself. And only after you remove the permission from the container itself then you can move forward and uh and actually only now it will be really removed and uh and let's see that that it was really cleared this time for real because we removed it from the right place and uh finally if you want like I said to automate it so you can use my invoke admin as the older permission check uh you can also compare it with

the previous run and it will uh show you uh what was added. what was removed uh etc. So uh this is a nice visibility. Second one which I really love is uh the concept that you have to be a local admin in order to uh execute remote code or to run remote processes, right? Do you need to be a local admin to run remote processes on remote machines? Not really. I mean we're used to do that but we can create a backd dooror to do that without local admin. For example, uh this is my host. I'm running on LON CL1 and that host uh you can see of course my user is Kai and again Kai is a normal

user. He doesn't have any uh special permissions and uh if you would see you would see that now my Kerros tickets have only tickets to the domain controller. uh when I try to access SRV2 this server uh I get access denied because I don't have permissions. I'm not a local admin on that server and you can see that authentication worked. I got a cable ticket for SIFS for the server too but authorization failed. So essentially I don't have uh uh enough permissions to manage it remotely. But now I run a Wii query on that remote computer and it works. So I got information about the disk drive. This is interesting because when I tried to access with SMB, it

didn't work. But when I try with WI, it works. Now I'm going to invoke a WI method. Essentially a Win32 process class uh create new process and I'm going to create a local CMD and it succeeded. So return value zero means success. So now I created a a process on that remote machine. Uh so that's interesting. When I go to that server, let's go to the server VM, the ones that I did all the commands on that server remotely on this uh machine srv1. If I look at commands cmd, then I see we have a process created by Kai. Uh and that's fun. It means that it really worked. Uh if we go to the computer management uh

and look at the um local administrators group or the just so you'll see that we don't have any special group membership giving us those permissions. You'll see Kai is far from being like you saw is just a domain user normal domain user is not a local admin is not even a remote desktop user or remote management user is not on any of those groups. But when you go really really down to WMI control, you go all the way down in computer management. I don't know when you visited there last time, but if you look at the security tab of WI control, you will see there is uh a security for each of the name spaces of WI. And you

will see that here on this uh security descriptor on this SDL we have Kai with enable uh remote Right. And uh essentially Kai has permissions to run code. So how do you detect those hidden WMI doors, the back doors? Essentially no EDR cares about that. Uh I checked I keep checking. Actually I'm checking for one year now and I talked specifically to few of the vendors and nobody thinks it's a problem. Okay, life goes on. Uh so I created a script at least as a public service get WM permission anomaly. This script will actually uh scan a computer remotely or the entire domain computers and uh alert you if there is something that is uh outside of the normal

permissions that you should see there. Uh let's see that quickly in action. You can scan for a specific namespace. The default is root sim v2 the default name space for most of the Wii classes. And you can see that when I run it, it gives us a warning. It enumerates the permissions and it will alert on anything that is outside of the default permissions. And you can actually run it not only on a specific computer, it can uh there is a parameter for to get all the domain servers via winrm. And uh now it will uh create uh multi-threaded jobs to run that and very quickly it will give you the results from all the domain

computers. Um and it really works. It really scales in enterprises. I've checked it. uh remember to consider al of course always the recursive permissions nested groups because there is a could be a group within a group and that's really where the uh effective permissions are coming from your cumulative uh group membership. So if you see a group there you should check who is inside of that. A quick note while we're talking about recursive groups is that of course as you know uh uh you have few commands to show the uh the nested group uh essentially and uh for example get ID group member shows only the direct members users and groups but if you do

minus recurse uh as a parameter it shows you all the users not groups including all the uh direct and indirect members of nested groups. Uh there is also my command from my GitHub which you can download which shows you all the recursive groups per account. This uh functionality you don't have in the built-in Microsoft tools. So I went ahead and wrote it. So it's also on my GitHub and you can actually query for every user what is the effective privilege attribute certificate or in other words the what it will get that account user or computer what uh you will get in the in its token in its TGT essentially and all the list of the

seeds effectively all the nested cumulative groups and this is the only thing you should uh really uh look at um so here is a question for Do how do you detect privileged accounts in your uh network? Do you look at admin count equal one? Who looks at admin count equal one in your ID domain? Uh maybe a few. Okay. Who looks at group membership domain admins? Okay, not too bad. uh who looks at the pack enumeration on the actual nested permissions because a user can have that group from anywhere in the tree or who looks at control path who looks at who holds persistence on another account and like this matrioska of permissions uh because if you will uh do that which we

do in assessments you will find out that with the control path essentially levels of proximity in one or two jumps of hopes of trust. Uh you actually have uh in a average network something like 500 domain admins waiting to happen. All they need is the willpower and that's something in humanity we always miss. It's that willpower to escalate yourself to greater things uh also in computers. Uh so while uh most of you like I statistically uh uh thought and predicted look at these two these are uh very bad indicators of privilege groups. You should really look at pack enumeration which is the effective nested permissions where you can uh hide users and you also need to look at

control path. So how about CD history? Moving on to the next uh uh backdoor. Uh anybody people know what is seed history in general? Okay. So seed history of course also it's been around for a while. It's been with us for decades. Uh it's essential tool in uh domain consolidation and migrating uh different domains from networks uh classic for mergers and acquisition etc. Essentially, it allows a user, a group, a computer, etc. to retain the access to resources in an uh older domain or organizational uh uh resources while uh the domain is in migration. So it's a temporary solution when you create a new account in the new domain, the consolidated destination domain to still

retain access for a while uh for some I don't know web servers, database servers, for uh business systems until you have to decommission it and wrap it up. Uh but that can be actually a great point to abuse because seed history is uh being uh uh facilitated as an attribute. It's essentially a property on a user or computer object and you can actually do privilege escalation by seed injection. So you can inject a seed value into an account. It's just a seed. You can inject any seed. So any simple user can have a seed of a domain admin or whatever group you want or user. It can have multiple seeds and also it's a good persistence mechanism. Why why it

is good for permissions uh persistence sorry because it retains the access regardless of the actual group membership because you're not a member of a group you just have the seed of the group in your seed history and also it has nothing to do with your password so uh even when a user changes a password the user that we are abusing uh the user that has the seed I will always have access with that permission and that's why cleanup is so important let's see this abuse So for example now I'm a a normal user called Martin and this Martin as you can see his seed history is empty he has no seed history now uh so user Martin uh is

going to do uh the following uh thing uh is going to um we look at domain admins first and you can see there's only two users in domain admin keep that in mind uh as user Martin now uh you can see that when you try to access the domain controller, of course, we get access denied. Duh. Because we don't have uh proper permissions. Uh but now uh we will look at the Kerberus principal token group, the script I told you about that shows the nested uh group membership. And you can see user Martin actually has two more groups uh in his nested group membership, which is developers and research. uh and you can see how this differentiates from the

normal uh normal command for Microsoft. So if if you use the nested command which I provide it's it shows you all the real uh groups that this user gets in its token. So that's one thing to remember but uh still we don't have permissions doesn't matter that we also have the that additional uh group. Now we're going to jump over over to the domain controller and I'm going to uh uh do this command. You see add A ads DB history from the DS internals. First I'm going to stop the NTDS service for a while a short while and I'm going to ask you later a question about that. And then I'm going to add that seed. I

injected it because the database is in use. I can do it by the way remotely without uh shutting down the database. But I wanted to show you that as well. And uh now when I will look uh you remember these were the groups for that user uh Martin by the way who has an alert when you stop the service of NTDS of AD in his organization. I can tell you that almost 10 MSPS managed sock providers in Europe that I checked don't have this alert. I don't know why. Uh so as you can see now voila. So now I have uh the seed history of domain admins in my uh uh cumulative groups. As you saw it was

added. Uh that command actually will show me also uh the you can see that on any user regardless of your permissions. So I can enumerate for other users including the default token groups which I filter by by default etc. You can also do it for computers. Uh anything you'd like. Uh and essentially that's that's how it goes because you remember that uh we couldn't access the that uh domain controller. But now if we will run again um we will re relog. That's because we need a new TGT. So now if we will try to access the domain controller with the same user Martin then of course it will uh work right. So how do you protect against that? You

have to first of all audit and remove unnecessary the seed value the seed history values uh keep in mind that you cannot uh just uh um delete it or clear it. You have to actually specify the specific values. So you have to enumerate it and then remove the values that you want. Uh please document before you do that. We had a customer that said, "Yeah, we finished the migration five years ago and we have no resources. You can do that." And uh luckily we documented everything before because they had a server uh an old DRP system that was still using CD history uh and everything stopped working. So but it's very easy to inject it again to attack

the domain. Uh you can like I showed you you can try the uh script to detect seed in the TGT. Uh please enable seed filtering in trusts if you have domain trusts. Um because you don't want to make this uh seed history tokens linger between domains. Monitor for attacks like DC shadow or start stop NTDS. Uh these are the ways that you uh inject that attackers inject CD story into your uh AD database. And of course add sim detections. And if you're doing a migration that doesn't need CD story enabled, simply disable it uh if it's not needed if the domain will be immediately decommissioned. So next uh next one up is uh abusing uni-ode characters. Uh you might know

that uniode that opened a new world for u uh showing uh special characters from different languages around the world breaking the boundaries of ASI. uh some there are a few more than a few characters in UI code that appear as a null characters like like it's an empty or space character in ASKI and as attackers uh I saw it actually in in a few uh incident response cases being used by threat actors. Uh this can really be confusing when you create users accounts. Essentially you can create multiple accounts that appear to have the same name because each of them has a different uni code character but in your sim or in your defense systems you will see just the username. Uh let's

see how confusing this is. So I'm going to create a a zero with a joiner. uh zero with the joiner is a character uh that uh is essentially as you see it's invisible in ASI but it's there it's a character it's valid right now I'm going to create a new user inside active directory I'm going to give it a a password and uh yeah I'm going to create it with a password obviously and I'm going to uh uh give it a quick description can give it uh have it enabled so I can uh use it right uh and the user as you can see the user name will be the uniutat character essentially this uh zero with a joiner

um and now I'm going to because I have permissions like I told you I'm a I'm a privileged user but I want to uh have persistence uh that is confusing to find I'm going to add that user to the domain domain admins not necessarily something I would do as an an adversary but now uh if you can see when I enumerate domain admins these are the members can you see this member on the left so it's a member and uh the question begs that uh is this really a real user can you run as that user uh let's try and uh funny enough I'm logged on as nothing uh and that user is a domain admin. So

you will see in your system things like user nothing did something to something or you can see user administrator and it's not administrator it's administrator with some uh abuse of some character. So how do you detect that again I went ahead and created a tool which is essentially quite simple recursive lookup for your entire directory. It looks for any hidden unic code character and lists it on the way because I'm already doing a recursive lookup. I haded added optional parameters for regex to find all the IP addresses and to find for any string to look to at secrets or some uh sensitive department. So it can be a real uh tool to do reconnaissance for interesting

information. Um and uh of course any unic code characters in a same account name should be uh investigated right so how does this look in practice uh again open source powershell easy to use for Microsoft if I look for a search term like change uh so you see all the places in my domain it's not a huge domain but still everywhere that the word change comes from it will show you the attribute and where it's and what is the value that is related to it it's essentially essentially a recursive lookup for strings in each and every attribute of each and every object really each and every object. Uh and now I'm looking for all the IP addresses essentially as you

can see uh this is uh also version numbers can look like an IP address because it's uh it matches the regax. uh but this can be also interesting and if I uh jump over uh to uh the uni-ode characters. So you will see uh this is the search for a hidden uh unicode characters. Uh you can see I have multiple system objects a system container system user another system user IT support all of them have uh a hidden value in the same account name and and that's where it's more more interesting. So th this will actually reveal uh those accounts. Final one is essentially not really a back door. It's more like a misconfig but it's something

that I I bet you have in every network of each and everyone here that has a domain ad domain is exploiting is clear text credentials. Essentially Microsoft web servers keep uh the application pool identity of virtual direct directories etc in clear text locally on the web config and any local admin can read this clear text. It's uh easier to have clear text than hashes of course very good for lateral movement and it's a very common finding in enterprise environments. So uh this tool gets credentials essentially uh will go ahead. The new version doesn't use RPC. It's an older video. It only uses winrm exclusively. But you can see that it ran it detects all the servers. It checks if there is

IAS running and for all the servers in the domain uh it will find the application pool identities and it will export the uh the results uh in clear text. So this is something you can use uh to map in your entire domain and map all those accounts. Uh what should you do in order to mitigate that? So first of all run the script. It does the initial mapping and it will give you good insights about how common this finding is in your enterprise environment. Uh these scripts will map the entire domain and it will also can be used of course as a red team tool. Uh but you can add mitigations to detections to find it right it's across

multiple hosts in PS remoting upmdx is running etc. Secondly you'll have to secure those service accounts on those is boxes. So uh the number one recommendation is move away from uh uh service uh users service accounts in application pools. Move away from SPNS. Move away period. Just move to managed service accounts. They're much better. They've been around for a long time and managed service account or GMSAs are a good alternative for user service accounts. Consider encrypting sensitive sections using the ASP.NET RSA provider. You can also protect application pools using configuration locks which is a bit more advanced. You can also use secret uh management solutions like vaults uh etc. You have so many solutions uh just

use one of them at least you can next step would be to map the local admins and just to uh get uh less of them uh just remove local admins. If there is a developer uh that just needs to access it once in a while don't give it local admin. There are alternatives. You can use SECM, pin castle, whatever to manage uh to map local admins. And finally, secure the local access which is essentially reduce admins uh restrict the access to application pool credentials. You can actually restrict the access control list on the web config file itself. And the most uh uh uh intriguing solution, the compelling solution which I love is to leverage just enough access. Just enough access

is essentially based on PowerShell session configurations. You don't need the GUI. You have UI but without the G, without the graphic. Uh but still you you can manage permissions. You can create uh constrained RO based uh remote access CLI and just give it limited commands only. So if you have a developer that only needs to run I reset. Okay, it doesn't need local admin for that. It doesn't need RDP for that. It doesn't need anything. It needs uh restricted CLI. Uh so that's about the IAS stuff. At the end of the day like we started this uh quick journey between back doors and uh how to protect and mitigate them. It's all about the big

picture. Uh remember anything you don't do today expands the attacker window of opportunity tomorrow as the French coined. So key takeaways adversaries can and will get creative with persistence mechanisms. When you are in the game of advanced persistent tra uh threats interpreter, you have to be ready to mitigate them. Uh you should create your own creative defenses. Uh time based security uh clever honeypotss. We have here with us Kat Fitzgerald from the Besides Chicago branch which I recommend that you see her talk in 1150 I think it's on the other side right that always has good ideas you know how how to defend and how to advance your knowledge in this field and uh check my GitHub page because it

has uh uh all the scripts I showed you and more so with that said Kenan thank