Original text by Akijosberry
LAPS Overview:
LAPS (Local Administrator Password Solution) is a tool for managing local administrator passwords for domain joined computers. It stores passwords/secrets in a confidential attribute in the computer’s corresponding active directory object. LAPS eliminates the risk of lateral movement by generating random passwords of local administrators. LAPS solution is a Group Policy Client Side Extension (CSE) which is installed on all managed machines to perform all management tasks.
Domain administrators and anyone who has full control on computer objects in AD can read and write both pieces of information (i.e., password and expiration timestamp). Password’s stored in AD is protected by ACL, it is up to the sysadmins to define who can and who cannot read the attributes. When transferred over the network, both password and time stamp are encrypted by kerberos and when stored in AD both password and time stamp are stored in clear text.
Components of LAPS:
- Agent – Group Policy Client Extension(CSE)
- Event Logging and Random password generation
- PowerShell Module
- Solution configuration
- Active Directory
- Computer Object, Confidential attribute, Audit trail in security log of domain controller
Reconnaissance:
Firstly, we will identify whether LAPS solution has been installed on the machine which we had gained a foothold. We will leverage powershell cmdlet to identify if the admpwd.dll exist or not.
| 1 |
Get-ChildItem ‘c:\program files\LAPS\CSE\Admpwd.dll’ |
The very next step would be identifying who has read access to ms-Mcs-AdmPwd. we can use Powerviewfor identifying users having read access to ms-Mcs-AdmPwd
| 12345 |
Get-NetOU -FullData | Get-ObjectAcl -ResolveGUIDs | Where-Object { ( $_ .ObjectType -like 'ms-Mcs-AdmPwd' ) -and ( $_ .ActiveDirectoryRights -match 'ReadProperty' ) } |
If RSAT(Remote Server Administration Tools) is enabled on the victim machine, then there is an interesting way of identifying user’s having access to ms-Mcs-AdmPwd. we can simply fire the command:
| 1 |
dsacls.exe 'Path to the AD DS Object' |
Dumping LAPS password:
Once you have identified the user’s who has read access to ms-Mcs-AdmPwd, the next thing would be compromising those user accounts and then dumping LAPS password in clear text.
I already did a blog post on ‘Dump LAPS password in clear text‘ and would highly encourage readers to have look at that post as well.
Tip: It is highly recommended to provide ms-Mcs-AdmPwd read access to only those who actually manage those computer objects and remove unwanted users from having read access.
Poisoning AdmPwd.dll:
Most of the previous research/attacks are focused on the server side (i.e., looking for accounts who can read the passwords) not on the client side. Microsoft’s LAPS is a client side extension which runs a single dll that manages password (admpwd.dll).
LAPS was based on open source solution called “AdmPwd” developed by Jiri Formacek and is a part of microsoft product portfolio since may 2015. The LAPS solution does not have integrity checks or signature verification for dll file. AdmPwd solution is compatible with Microsoft’s LAPS, so let’s poison the dll by compiling the project from source and replace it with the original dll. To replace the original dll administrative privilege is required and at this point we assume the user already has gained administrator privilege by LPE or any other means.
Now let’s add these 3-4 lines in the AdmPwd solution and compile the malicious dll. These lines will be added where the new password and time stamp would be reported to the AD.
| 1234 |
wofstream backdoor; backdoor.open( "c:\\backdoor.txt" ); backdoor << newPwd; backdoor.close(); |
In this way adversary will appear normal, passwords would be synced and will also comply with LAPS policy.
BONUS: Persistence of clear text password *
*Persistence till the time poisoned dll is unchanged.
Dectection/Prevention:
- Validate the Integrity/Signature of admpwd.dll
- File Integrity Monitoring (FIM) policy can be created to monitor and changes/modification to the dll.
- Application whitelisting can be applied to detect/prevent poisoning.
- Increase LAPS logging level by setting the registry value to 2 (Verbose mode, Log everything):
HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}\ExtensionDebugLevel
Note: Above methods are just my ramblings, I am not sure whether some of these would detect or prevent.
Modifying searchFlags attribute:
The attribute of our interest is ms-Mcs-AdmPwd which is a confidential attribute.Let’s first identify searchFlags attribute of ms-Mcs-AdmPwd. We will be using active directory PS module.
The searchFlags attribute value is 904 (0x388). From this value we need to remove the 7th bit which is the confidential attribute. CF which is the 7 th bit (0x00000080) ie., After removing the confidential value(0x388-0x80) the new value is 0x308 ie., 776. We will leverage DC Shadow attack to modify the searchFlags attribute.
Detection/Prevention:
- Anything which detects DC Shadow attack eg.,ALSID Team’s powershell script. ( It detects using the “LDAP_SERVER_NOTIFICATION_OID” and tracks what changes are registered in the AD infrastructure).
- Microsoft ATA also detects malicious replications.
- It can also be detected by comparing the metadata of the searchFlags attribute or even looking at the LocalChangeUSN which is inconsistent with searchFlags attribute.
Note: In my lab setup when i removed the confidential attribute from one DC it gets replicated to other DC’s as well (i.e., searchFlags attribute value 776 gets replicated to other DC’s). Another thing i noticed is after every change the SerachFlags version gets increased but in my lab setup it was not increasing after 10. If you find something different do let me know.