Password Abuse
When talking about "password abuse" we focus on ACLs like ForceChangePassword, ReadLAPSPassword, and ReadGMSAPassword.
ForceChangePassword
User-Force-Change-Password is an extended access right that allows users to reset the passwords of other accounts, even those with higher privileges.
If we control an account that can modify another user's password, we can effectively take over that user's account by changing the password; this is only possible if the controlled account has certain access rights, such as GenericAll
, AllExtendedRights
, or User-Force-Change-Password
, over the target account. The following is the BloodHound query to find these
but we can also use all the methods discussed in DACLs Enumeration.
To reset a user's password we use
or from windows
ReadLAPSPassword
LAPS allows managing the local Administrator password (randomized, unique, and changed regularly) on domain-joined computers. These passwords are centrally stored in Active Directory and restricted to authorized users using ACLs
. Passwords are protected in transit from the client to the server using Kerberos v5 and AES. Here is how it works:
a
LAPS
client is installed on each computer. This client is responsible for periodically changing the local administrator password on the computer.the password is stored in Active Directory as an attribute of the computer object. This attribute is named
ms-MCS-AdmPwd
.to access the local administrator password for a computer, we can use the LAPS UI tool or PowerShell to retrieve the current password from Active Directory.
the password is only visible to users granted permission to read it.
This is the cypher query to identify the ReadLapsPassword
edge in BH - but (at the time of writing) - this only works for LAPS (not LAPS2)
To read the LAPS password for a local machine we can use
From linux we can use LAPSDumper
ReadGMSAPassword
Group Managed Service Accounts or gMSAs are a feature in Microsoft Active Directory that provides a secure and automated mechanism for managing service accounts used by applications and services running on Windows servers. Unlike regular service accounts, gMSAs
have built-in password management and simplified key distribution, eliminating the need to manage and update passwords manually.
When a gMSA
is created, it is associated with a specific Active Directory group, allowing multiple servers or applications to share the same gMSA
for authentication. This association simplifies the administration and maintenance of service accounts across multiple systems. A gMSA
leverages a secure key distribution process
, where the password is automatically generated
, securely stored
, and periodically rotated
by the Active Directory domain controller. This eliminates the risk of the password being compromised or forgotten, reducing the attack surface and enhancing security. By utilizing gMSAs
, the associated principals (such as machine accounts, servers, or applications) are granted specific access rights through the use of a dedicated DACLs
stored in the msDS-GroupMSAMembership
attribute of the service account. These access rights can be tailored to meet the specific requirements of each principal, granting them access to the necessary resources and reducing the need for manual permission management.
If we get access to a principal (such as machine accounts, servers, or applications) that have access rights to use a gMSA
, we can abuse it to obtain the group-managed service account password.
This is the BH query we can use
To abuse this from linux we can use gMSADumper
and GMSAPasswordReader from windows
Last updated