The (Un)Rightful Heir: My dMSA Is Your New Domain Admin

Hello everyone. Uh I'm very excited to be here. This is actually my first time talking in a conference. So getting to do it in ve here in Vegas, it's like a dream come true. And now uh uh today I'm going to talk about a vulnerability a vulnerability that I have found in active directory. And um before we start uh this vulnerability uh I found during my research on DMSA and few years ago I also did a research about GMSA and uh I now know a lot about MSA but there is just one thing that I just couldn't figure out and that is why the D in DMSA and the GMSA are lower case and uh at

first I thought that this is just because I'm not an not an English speaker but uh I asked a lot of people and I didn't actually get a response that satisfied me. So, uh I'm telling you this so just so you know if during this talk at some point you will ask yourself why it is written that way. Uh I have no clue. So uh I'm Yuval Gordon. I'm a security researcher at Akami. uh and in the in the last decade I've done uh uh different roles in security in cyber security and uh the one domain that I'm keep coming back to is active directory and today in Akami I'm focused on offensive research so uh this is how

I got to uh this vulnerability uh that's my ex handle so feel free to uh to follow me or reach out uh so the agenda for today we're going to start with a quick introduction to service accounts. Uh then we're going to deep dive to DMSA. I'm going to explain exactly what DMSA is, how they work, and uh where exactly I found the vulnerability. Then I'm going to talk about bed successor, which is a technique that abused this uh vulnerability. So uh in order to explain what a service account is, I'm going to use a story by Elatch Shamir. So uh Elachamir has amazing talks where he talks about uh different things around Keraros and um I

really love the way that he speaks about uh explains about Keraros and and the different terms. So uh I really recommend these talks but for now I'm just going to uh summarize uh the the relevant part for us. So uh in a lad's story there is this new amusement park and in this uh in this amusement park there are uh uh visitors and those visitors when when they want to come into the park they get a daily ticket. Uh so this daily ticket is like a TGT in Kerberos and uh when when a visitor want so uh in the park there are also uh several rides. So uh for example we have this uh really really cool roller coaster and uh

each different ride has a ride operator. Now a ride is like a service. So for example that can be a web application and uh the ride operator is a service account. This is the main focus of our talk and uh when a visitor wants to get on a ride uh they can't use their daily ticket. what they need to do is to go to the ticket office and actually get a ticket for the specific ride. So, uh to enter to to uh to enter each ride, they need a different a different ticket and when they get the the ticket to the specific ride they want to uh to enter. Uh they take this ticket to the ride

operator and uh the ride operator looks at the ticket, they validate it and uh the ticket has some information. So it has for example the the visitor height and age and uh the different memberships. So maybe this ride is only for the the premium maybe this is a premium ride. Uh so the ride operator will choose whether to allow the visitor to um to to uh join the join the ride. So um this is basically service accounts and we have different types of service accounts. So uh we have the unmanaged type the legacy kind uh and this kind has a lot of security risks uh the most major one that uh legacy service accounts are a target for for garbosting

attack. So uh in 2008 and 2012 Microsoft introduced MSA and GMSA. Uh for the sake of our talk I will just refer to both of them as MSA. It's not really important the the difference between them, but uh the the manage type of account solved the problems that the legacy account had. And so um so that was really great but uh it it has been u more than more than a decade more than a decade since uh Microsoft introduced MSA but still I'm talking about legacy service accounts. So uh I'm doing this because uh uh MSA just didn't take over. Uh organization still uses today legacy service accounts and uh I haven't actually found any organization

that don't use legacy service account at all. So uh the reasons for that um the most major one is that uh legacy uh in order for a service to be um to be configured with uh with an MSA they have to support MSA and unfortunately just some services just don't support MSA. So uh we can't configure MSA for that services. So if our organization uses uh those services we can't we can't uh use MSA for them and uh the other reason is if we have a service an existing service that is currently running with a legacy service account uh if we want this service to now use an MSA we will need to uh configure a lot

of things for the MSA to work exactly like the the old service account. uh we want them to have the same privileges, the same configurations and this will just take a lot of time from the IT team and if they will do some mistake uh it will uh result with a app downtime. So uh luckily for us in 2025 just recently Microsoft introduced a DMSA or delegated managed service account. So, uh, the MSA is completely new and it has all of the advantages that the old MSA had, but, uh, this time the IT team can just lay back and relax because Microsoft has introduced a really cool new migration process that lets, um, let's admin take an existing uh, legacy

service account and just migrate it into a DMSA. uh and it doesn't matter if the services that uses this service account support MSA or not. Uh they will all just work with the DMSA and the IT team doesn't need to do any work and they don't need to um to take care of anything. So that's really amazing. So let's talk about this uh cool migration process. So uh we can actually divide the migration process into three phases. we have the we need to start the migration then we uh in the waiting phase and then we complete the migration. Now uh before I actually get into uh uh into one of those uh phases uh let's

look at at how authentication looks like before we start a migration. So uh on our left we can see an SQL server. I I've called this server SQL SRV and this server is running an SQL service. Now when the uh when the service needs to authenticate in the domain uh we have configured it to run with SVCSQL a legacy service account. So um when the service authenticates it will issue an authentication request with SVCSQL and the DC will respond with a TGT which is like uh the daily ticket in the amusement park. So uh now let's start the migration and uh what happens now is uh we we have a new DMSA that I have called DMSA dollar and we have the

old legacy service account and uh when we start a migration uh those two accounts are being linked. So each of them is uh just pointing to the other and the other thing that happens is that the legacy service account is granted right permission on a specific attribute on the DMSA. So uh this attribute is a really important one and uh uh what it controls it it actually uh controls who can authenticate as the DMSA. So uh in order for a server to authenticate as the DMSA they have to be listed in this attribute. So uh in the next slide I will show how this attribute is uh being used. So uh we have configured we we

have started the migration and now we are on the waiting phase. So uh now when the server wants to authenticate it will uh again issue an authentication request just as before but uh and and this time again the DC will respond with the t with the TGT but uh the response will now have an additional information. So the additional information will say that this user will be soon superseded by DMSA dollar. Now when the kos client which is um uh what actually take carees of the authentication on the SQL server side. When this car client sees this message uh it will just automatically uh respond with sending an LDAP modification request to the DC requesting to add the server we are

currently working on which is SQLs dollar to the attribute that controls who can authenticate as the DMSA. So uh the result of that will be that this server will now be able to authenticate as the DMSA from now on. So uh this is why we are on the waiting phase. This phase is uh for the environment to learn which servers are currently using the legacy service account. So they will all be able to use uh the DMSA. So uh now we need to wait we wait for about a week before we complete the migration. So uh at this point the we complete a migration and uh what happens is that uh the legacy service account is getting

disabled and um some careerous configurations are being copied from the legacy service account to the DMSA and now uh let's look at the authentication now. So once again uh we're the the server is requesting uh a TGT uh requesting to authenticate as SVCSQL but this time uh the DC responds with an error because uh this user is now disabled. So uh this response again has an additional information which says that this user is superseded by DMSA dollar. Now when the keros client get this response, it will just automatically try to authenticate with uh DMSA dollar and because we are listed in the attribute that controls who can authenticate as the DMSA uh we will be

allowed to authenticate uh and and everything is is good. But uh so everything that I have just shown is uh from the Microsoft documentation. But uh there was just one thing that that was missing that really bothered me because uh the documentation didn't mention privileges at all. And uh uh actually uh this is really concerning because if we have a really cool uh great migration process uh they have to take care of privileges. If the legacy service account had certain p certain privileges, the new DMSA uh should have the ex exactly the same for the service to to uh to work as as expected. Now uh let's talk about privileges in Kerbaros. So uh in Kerbaros uh in Kerbaros we have

a structure that called pack which is in the Keros tickets. So uh this pack lists some information about the user and it also it also lists the uh group membership of the user. So it will list every group that the user is a member of and if we had the SVCSQL the legacy service account and uh it was a member of several groups. So I have just created a new DMSA and I have completed the migration and I checked and the new DMSA is not a member of any group. So we can expect the the pack of the DMSA to look like this. Um so this is really bad if that's the case because uh that means that the DMSA

don't has the same privileges as the legacy service account. Uh so uh that's a huge problem but uh I guess Microsoft engineers have watched Dragon Ball uh because they too knew that when a problem is just too big there is only one solution fusion. So uh the the park of the DMSA actually looks like this. So um what happens is when the when the when we authenticate as the DMSA uh the DC will build the pack just as before but this time it will also check if the DMSA is linked to another account and if so it will just also build the pack for the uh superseded account and will merge the two packs. So the the new pack will have

uh every group that either the the DMSA or the legacy service account was a member of. So uh that way we we make sure that the DMSA and the and the DMSA has the exactly has exactly the same permissions as the legacy service account had. Now uh we we thought that this uh mechanism is really great because that means that uh we can just take privileges of one account and give it to another without changing group membership. Uh so that is really cool and we wanted to know uh whether if whether we can abuse it and uh and and we can but uh in order to explain how we actually abused it I'm going to explain

how the migration process uh actually look like how we how we start the migration process. Um so uh one moment

so uh uh according to Microsoft documentation when we want to start the uh the migration we need to execute this PowerShell commandlet. Now uh we tried executing this PowerShell commandlet uh by a non-domain admin but uh it failed. So uh in order we we wanted to understand exactly what happens when we execute this command and actually this command is just a a wrapper for this LDSc operation. Now uh if you're not familiar with lupsc operation that's okay. Uh it's basically just requesting uh to invoke a certain functionality from the DC. Now uh if we try to in if we try to manually uh send this request to the DC as a non-domain admin it will

also fail. So uh that's because on the DC side there is a verification whether the color of this operation is uh is a domain admin and if not uh it will just not work. So uh at this point we wanted to understand what happens when the DC uh does approve this operation and what the DC does is just uh changing some attributes. So uh basically uh the DC just takes the DMSA and the superseded account and changed some attributes on them. And at this point we wanted to know whether we can uh if we control a DSA maybe we can just change the same attributes that the this is changing. So uh apparently we can do that. We don't need domain admins

for that. Uh so that means we can link the DMSA to another account and uh the link is and we do the link just from the DSA to the superseded account not the other way. So we don't need actually uh any permissions on the target account just on the DMSA and we link it to any account including domain admin and um uh we gather privileges. So uh that is basically bad successor and uh let's see it in action. So um we have an attacker and this attacker has a control over a DMSA and they want to get a domain admin privileges. So u they will just simulate DMSA migration. They will link the DMSA to a domain admin and they now need to

authenticate as a DMSA and uh that this is just granting them the privileges. So that's great. That's amazing, really cool. But uh there is a huge problem because uh getting getting control over a DMSA uh that's pretty hard because DMSA is is brand new as as I said. So most organizations don't use DMSA yet. And uh the second point is that DMSA are being created by default in the managed service accounts container and this container is uh heavily restricted. So only highprivileged groups have have access to this uh container by default and so uh we we even if there is a DMSA it will probably mean we can just uh I mean getting control over it will be

hard. So uh uh luckily for us we can actually create the DMSA in any OU not just in the managed service account container and that means that uh now the the diagram changed a bit and if we control any OU and OU is basically OU is an organizational unit it's basically a folder in active directory. So if we control a folder which you know some folders are just not as important as the others. If we control an U we can create a DMSA there and therefore we can simulate a migration and get domain admin. Now uh let's it uh let's see a demo of it. So here we are running as a weak user and this user has uh we are trying to

add oursel to do the main admins and we fail because we we don't have privileges but we can create objects in an OU called temp. Now we will try now we uh create a new DMSA in the tempu and we link the DMSA to the administrator account. Great. Now we need to authenticate as the DMSA. So we use Rubio for that. Okay, now we are authenticated as the DMSA as we can see in K list and uh we try to add a member to domain ad means once again this time we succeed because uh we are running with administrator privileges. So um we have reported this vulnerability to Microsoft and Microsoft said uh that this is a vulnerability.

they they agreed with us but uh they said that if we have a control over u and we can just gain any privileges that we want that is moderate so uh because this is moderate uh it does not meet the bar for uh immediate servicing uh however they did said that they're going to uh to fix it in the future um but that's actually uh not the end so uh when I started with uh with the research. I saw that uh there is this structure and uh I didn't thought much about this structure. I I actually ignored it. Uh basically this structure uh is in in TGT for DMSAs and uh it has two key members. It has the current keys

and the previous keys. So uh those fields uh hold the the Kerros keys for the DMSA both the current one and the previous. Uh so uh Keraros keys if anyone uh is not familiar with that is basically credentials in Keraros and we can think about it as a password hash. So now uh the the thing that that led me to look at this structure again is seeing this uh decoded response. So this is a decoded response of this structure. And uh we can see the current keys above and the previous keys below. And uh maybe it doesn't says much to you but uh I I saw this when I worked on the demo. So I

have just created the DMSA. I have uh simulated a migration. I linked it uh into admin administrator and and then I got this response. Now uh the weird part that I actually didn't notice is that the new DMSA that I have just created has a previous password. Now uh I didn't uh actually see that but uh what I did saw is the value in the previous keys and uh maybe you can't see the value or it just doesn't mean anything to you. uh it makes sense that that is just an antmash and uh usually I don't recognize antmash but uh this anti-mash specifically uh it means a lot for me because uh this is the anti-mash

of this password and I always use this password for my lab environment. So I immediately I immediately recognized the hash of A126 as I always use it. Now uh that was really weird because we have a DMSA which is a great security uh new feature and they have a randomly generated password but the old password is the password that I always use. That that's pretty weird. So uh apparently what happens is when we link the DMSA to another account, we are not only stealing the privileges of the other account, we also get uh the their credentials. So uh I have created a tweet about it and I show that I'm running a script and I just uh dump uh all of the credentials

of all of the users and computers in the domain. Uh so that's really cool. And I'm also dumping the credentials of uh KBT. Maybe you can see it from here, but KBTGT is uh I think the most critical uh user in active directory. If you have those credentials, you can craft golden ticket. Uh so that's really cool. Uh and uh I'm showing I I'm showing this tweet because there was just one comment that I think summarized this whole thing uh perfectly. So uh Andre Andre replied with seems quite moderate. So yeah, dumping the the every credentials is moderate. So now uh let's talk about uh detection. Uh and I'm not going to talk about mitigation because uh we I I think uh

the best mitigation will be just to wait for uh uh for Microsoft patch. Uh in the meantime there are some there was some discussion after I posted a blog about this. Uh there was some discussion in the in the identity realm about uh like uh how how organizations can protect themselves from this attack and uh there were some uh great ideas but I think that none of them actually uh is is uh like good enough for perfectly uh mitigating this uh this vulnerability. So uh in order to detect this uh this attack uh there are a couple of logs that are being created when we execute the attack. So uh first of all when we

create a DMSA u uh there will be a log saying that uh a DMSA was created if we configure a sackle. So a sackle is a system ACL uh and uh yeah you should configure sackle for uh for the creation of DMSAs. Uh the second point is DMSA linkage. So again uh this requires a suckle but then you will get a log every time that someone's link a DMSA to another account. And uh the last one the the most interesting is uh this log is actually for GMSAs. So uh when a user fetch a password of the GMS of a GMSA uh this log is uh logged but uh apparently it is also logged when we request a TGT

for DMSA. So I guess this is because of how uh Microsoft is uh sending us the the credentials. Uh now the the interesting part is that uh when we when we uh fetch GMSA password we we have the caller seed and caller IP and those those fields will have the seed that fetch the password and the IP that uh the the user was working from. But uh when we request a TGT for uh a DMSA uh this is getting logged with uh the caller IP as blank and the color seed as anonymous loon. So uh I think this is really interesting. I actually uh didn't have the time to to look into it more but I think uh this

may be uh worth uh some digging. Uh and now uh before we get to the conclusions um I I have contacted with uh MSRC because uh they were actually uh pretty great. I I mean beside the point that I don't agree with them on the severity uh that they were really great working with and uh I sent them the presentation and I asked if they want to put uh any official statement. So uh this is their their statement. Uh we are aware of this report and we'll be addressing it in an upcoming update. Um okay so uh let's talk about conclusions.

Okay so uh DMSA is a brand new feature and it was designed with security in mind. it actually solves some I think great security risk and uh but but that doesn't mean that the DMSA is necessarily uh secured and that they they don't have any vulnerability there. Uh the second point is to never skip the obvious because uh I think that when when I saw that uh that the whole new uh um pack merging thing, I talked with my manager about it and uh his response was something like well uh maybe you can just change the attribute and then it will give you the pack. And I said h no that sounds way too easy. Uh but but

apparently it was just that easy. So uh good thing that I I didn't skip it. Uh the the next point is uh as I said to log and alert on DMSA creation and links. And uh the final point is uh that DMSA is a great new feature. I know that in in this talk I I talk badly about it, but I actually really like this feature and I think that once Microsoft will uh u finish with the patch uh it will be much better and organization definitely should use this feature. Uh so uh thank you and if you have questions uh feel free >> [applause]