Hardening the Local Administrator Account
Although disabling this account would block this attack vector,
many organizations rely on this account
for various applications and administrative tasks.
In an attempt to prevent attacks that leverage shared Administrator passwords,
Microsoft introduced Group Policy Preferences with Windows Server 2008,
which included the ability to centrally change
local administrator account passwords.
However, this approach stored data in an XML file in a SYSVOL folder,
which must be accessible to all computers in Active Directory.
This created an obvious security issue since the unhashed local administrator
password was stored on an easily-accessible share.
To solve this issue, Microsoft AES-256 encrypted them.
The AES-256 encrypted password is realistically unbreakable
given a strong key.
Surprisingly, Microsoft published the AES private key on MSDN,
effectively breaking their own encryption.
As an apparent solution, Microsoft issued a security update in 2014,
which removed the ability to create Group Policy Preferences
containing passwords.
Although these files could no longer be created,
existing Group Policy Preferences containing passwords were not removed,
meaning some may still exist in the wild.
To again address the issue of centrally managing passwords for the local
administrator account, Microsoft released the Local Administrator Password Solution
or LAPS in 2015, which offered a secure and scalable way of remotely managing
the local administrator password for domain-joined computers.
LAPS introduces two new attributes for the computer object into Active Directory.
The first registers the expiration time of a password
as directed through a group policy.
The second contains the clear text password of the local
administrator account.
This attribute is confidential,
meaning specific read permissions are required to access the content,
which is normally assigned through group membership.
LAPS uses the unmanaged dynamic link library admpwd.dll
to change the local administrator password,
and push the new password
to the second attribute of the associated computer object.
If LAPS is in use, we should try to gain access to the clear text passwords
in Active Directory as part of a penetration test.
While Microsoft has released a PowerShell toolkit to query LAPS,
it is not typically installed on a Workstation.
Instead, we can use the LAPSToolkit PowerShell script,
which is essentially a wrapper script
around the PowerView Active Directory enumeration PowerShell script.
For example, we’ll invoke the GetLAPSComputers method
from LAPSToolkit to list all computers which are set up with LAPS
and display the hostname, the clear text password, and the expiration time.
Although we have discovered the “appsrv01” server, which is managed by LAPS,
we cannot view the clear text password.
In this case, our current user account does not have permissions to read
the password, so it is returned as empty.
We can use the Find-LAPSDelegatedGroups method of LAPSToolkit
to discover groups that can fully enumerate the LAPS data.
From the output we find that members of the custom LAPS Password Readers group
have read permissions.
Next, we can use PowerView to enumerate members of that group through
the Get-NetGroupMember method,
supplying the -GroupName option to specify the group name.
The output reveals that the jeff and admin users can read the LAPS passwords.
These permissions are often given to both help desk employees
and system administrators.
Users with these permissions are prime targets during a penetration test
since they have access to clear text passwords on a potentially
large number of workstations or servers.
For example, we start a powershell instance as the admin user,
and view the LAPS passwords with Get-LAPSComputers
We can use the local administrator password for “appsrv01”
to remotely log in to this machine and others with matching credentials.
Now that we have an understanding of the local administrator
account and potential attack vectors against it,
let’s investigate how access rights and permissions work
after a user has authenticated on Windows.