Local admin access to Windows 10 given physical access to the system
TL;DR This is just one of the ways an attacker or disgruntled insider could get local admin access, given physical access to a domain workstation.
Background
Many of the methods shown in the lab here start with the attacker already possessing Domain User and/or local admin access and then escalating domain privileges. This is due to a focus on domain security more than any one single system and the presumption of compromise. It can lead to a question though.
So how would someone get local admin access? There is the obvious answer that these vulnerabilities pop up from time to time in Windows. An attacker can phish a domain user, then exploit any unpatched vulnerabilities to escalate privilege. A recent example is CVE-2021–1647, a security issue in Windows Defender ironically enough.
Two other recent examples were PrintNightmare and HiveNightmare.
The issue
More insidiously, an insider can simply use the Windows 10 installation DVD to escalate privileges if they have physical access to a domain workstation. All they have to do is insert the disc, boot from it, and hit Shift + F10 at the first screen rather than installing.
This brings up a command prompt used for troubleshooting tools such as chkdsk. However it can also be used to first create a backup copy of utilman.exe and then overwrite utilman.exe with cmd.exe. BitLocker will not prevent this if the insider knows the pattern that the BitLocker password is based on.
Note on BitLocker:
If the insider knows the pattern that BitLocker is based on, for example the serial number of the workstation, they can still execute the Windows 10 installation disc attack and reset the local admin’s password. They only have to perform two extra steps after booting from the disc:
manage-bde -statusmanage-bde -unlock C: -Passwordmanage-bde off C:manage-bde -status
They can then simply wait for BitLocker to finish decrypting the hard drive and then proceed to overwrite utilman.exe with cmd.exe.
After performing this the malicious insider can simply reboot and remove the install disc. At the login screen they can click the ‘Ease of access’ icon in the bottom right. Normally this would bring up settings such as the Narrator and Sticky Keys, but since the attacker previously overwrote utilman.exe it instead brings up a command line as NT AUTHORITY\SYSTEM.
The attacker can then create a new local admin account or simply reset the password of the existing one via
Net user administrator *Then typing a password twice. They can now login to the system, make an exception in the anti-malware, and start running tools such as Mimikatz to attempt to escalate privileges on the domain. Even worse, the attacker does not need to login as a domain user at any point in this attack. This means it is almost impossible to attribute the incident to a particular offender.
Mitigations:
An obvious mitigation is to utilize full disk encryption such as BitLocker, however this is not fail proof if the insider knows the pattern that the BitLocker password to a given workstation is based on. Much like web application security, it is not best practice to rely on client side defenses entirely.
Server side controls include placing privileged user accounts in the Protected Users group in Active Directory so that their NT hash is not cached on domain workstations that they logon to. Additionally this forces their account to use Kerberos to authenticate to domain resources, so pass the hash attacks using NTLM is rendered almost useless on their account.
Utilizing GPOs to remove debug rights from local admin accounts greatly aids in stopping a malicious insider from running Mimikatz in the first place. This can be configured under in Group Policy under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Once this policy is pushed to domain workstations the attacker will see the below when they attempt to use a tool like Mimikatz to grab hashes. (gpedit.msc is shown to illustrate what the attacker will see if they attempt to abuse local admin access to give themselves debug rights back. By default local admin accounts have debug privileges.)
Of course the best mitigation is to limit where Domain Admins login at all.
Helpdesk personnel should have delegated privileges to just the OUs in which they manage workstations and users. They should not have domain wide rights beyond a normal Domain User. This is because helpdesk personnel will of course be logging into workstations all over the place as users have issues. It is rather likely that at some point one of these users will get phished.
Domain Admins should only be logging into trusted systems that only they use, thereby limiting the attack surface. Paired with usage of the Protected Users group this raises the bar for an attacker.
It goes without saying, but your HIPS solution and your SIEM should both be configured to alert on modifications to utilman.exe. If this event occurs it is quite likely you need to initiate your incident handling procedure.
Key take away
If there is one overriding point that cybersecurity folks who work in a Windows domain environment should understand; Windows domain workstations do not do a good job by default at keeping local accounts and domain accounts separate. If an attacker can gain local admin access to the workstation then they can compromise any domain accounts that later login to that workstation.
Futhermore the presumption of compromise dictates that defenders must assume that at some point a Domain User will get phished and compromised. Therefore defense in depth and best practice dictates that host defense should focus on preventing a Domain User from gaining local admin and operational practices should be structured in such a way that the entire domain is not compromised by an attacker gaining local admin to one workstation.
References:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1647
https://www.wired.com/story/windows-defender-vulnerability-twelve-years/
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk
https://pberba.github.io/security/2020/04/26/lateral-movement/
