Attacks Against Windows PXE Boot Images

Share this…

If you’ve ever run across insecure PXE boot deployments during a pentest, you know that they can hold a wealth of possibilities for escalation. Gaining access to PXE boot images can provide an attacker with a domain joined system, domain credentials, and lateral or vertical movement opportunities. This blog outlines a number of different methods to elevate privileges and retrieve passwords from PXE boot images. These techniques are separated into three sections: Backdoor attacks, Password Scraping attacks, and Post Login Password Dumps. Many of these attacks will rely on mounting a Windows image and the title will start with “Mount image disk”.

Recommended tools:

  • VMware (Workstation or Fusion)
  • Microsoft Hyper-V
  • Kali Linux iso
  • Windows image (blog uses Windows 10 Professional)

General overview:

  • PXE booting a Windows image with Hyper-V
  • Mounting a Windows image
  • Backdoor attacks
    • Add a local Administrator during setup
    • Mount image disk – Add batch or executable files to all users
    • Mount image disk – Overwrite sethc.exe or other accessibility options
    • Mount image disk – Use chntpw tool to overwrite Administrator password
  • Password Scraping attacks
    • Scrape VM memory files for passwords during install or login
    • Mount image disk – Review local Unattend/Sysprep files
    • Mount image disk – Copy the SAM file and pass the hash with the Administrator account
    • Mount image disk – Copy the SAM file and crack the Administrator account
  • Post Login Password Dumps
  • Mitigation and Prevention
  • References

PXE booting a Windows image with Hyper-V

Create a new VM through the New Virtual Machine Wizard. Follow the guided steps and make sure to choose the “Install an operating system from a network-based installation server” option. Check the settings menu after the wizard is complete and make sure “Legacy Network Adapter” is at the top of the Startup order.

Save and start the VM. The PXE network install should start and begin the Microsoft Deployment Toolkit deployment wizard.

Run through the wizard and start the installation task sequence for the target image. This can take a while.

Mounting a Windows image

Once the setup is completely finished (including the Windows operating system setup), you should have a working Windows VM. Make sure to shutdown the VM safely and download the Kali Linux iso. Go to the Settings menu and choose the location of your DVD drive image file.

Now, change the boot order so that “CD” is at the top of the BIOS startup order.

Save the settings and start the VM. Choose to boot into the “Live (forensic mode)”.

Once Kali is booted, mount the Windows partition with the following sample commands. Make sure to change the  example /dev/sda2 partition use case.

fdisk -l
mkdir /mnt/ntfs
mount -t ntfs-3g /dev/sda2 /mnt/ntfs

Backdoor Attacks

1. Add a local Administrator during setup.

This is probably the simplest way to gain elevated access to the system image. After going through the Windows PE boot process, go back into the Settings menu for the VM. Set “IDE” to be at the top in the “Startup order” of the BIOS section.

Save the settings, start the VM, and connect to the console. The VM should enter the initial Windows setup process. Pressing Shift+F10 will bring up a system console. Note that this is different than pressing F8 during the Windows PE deployment phase. Enter the following commands to add your local Administrator user.

net user netspi Password123! /add
net localgroup administrators /add netspi

Check the Administrators group membership.

Now that the user has been created and added to the Administrators group, wait for the VM to finish setup and log in.

Once logged in, you will have local Administrator privileges! We can go a step further and obtain local system with PsExec.

PsExec.exe -i -s cmd.exe

The local system cmd prompt can be used to check if the computer account has domain user privileges. This can be a good starting point for mapping out the domain with a tool like BloodHound/SharpHound.

2. Mount image disk – Add batch or executable files to all users.

The shortcuts or files located in C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup will run when the users log in at startup. Change directories to the Administrator’s Startup directory and create a batch file with the following commands.

@echo off
net user "startup" "password" /add
net localgroup "Administrators" /add "startup"

The batch file will run when the Administrator user logs in. If this attack is combined with attack scenario #4, the Administrator user can log in with a blank password. Check to see that the startup user is created and added to the Administrators group after login.

3. Mount image disk – Overwrite sethc.exe or other accessibility options.

Replacing sethc.exe (Sticky Keys) is a classic privilege escalation technique. sethc.exe is located at %windir%\System32\sethc.exe. The command below copies cmd.exe and renames it to sethc.exe.

cp cmd.exe sethc.exe

If sticky keys is enabled, a local system cmd prompt will pop up when “Shift” is clicked five times in a row.

4. Mount image disk – Use chntpw tool to overwrite Administrator password.

The chntpw tool can clear the password for a Windows user. The SAM and SYSTEM files are located in the %windir%\System32\config\ directory.

The netspi user’s password is cleared and the account can be logged into without entering a password.

Password Scraping Attacks

5. Scrape VM memory files for passwords during install or login.

My colleague James Houston deserves a huge shout out for coming up with this attack. The general idea here is to use the snapshot or suspension functionality to capture passwords in the VM’s memory. This can be done during the actual PXE boot deployment process, installation, or login steps. This example will retrieve the password for the deployment service account during the MDT deployment process.

The deployment user is used to join computers to the domain in the “Computer Details” step of the deployment task sequence.

At this point, either suspend or take a snapshot of the VM’s current state. In Hyper-V, use the Checkpoint functionality to take a snapshot. Under the Checkpoint menu in Settings, make sure that “Standard checkpoints” is selected. This will ensure application and system memory is captured. The snapshot location is also set in this menu.

Browse to the snapshot file location and look for the corresponding files for your hypervisor.

  • VMWare: .vmem, .vmsn (snapshot memory file), .vmss (suspended memory file)
  • Hyper-V: .BIN, .VSV, .VMRS (virtual machine runtime file)

Since this example uses Hyper-V, copy off the .VMRS file to search for passwords. I used Kali Linux along with strings and grep to locate the service account and password. Searching for keywords like “User” or “Password” is a great start if the username or password was not displayed during the Windows Deployment Wizard.

strings PXEtest.VMRS | grep -C 4 "UserID=deployment"

6. Mount image disk – Review local Unattend/Sysprep files.

Unattend and Sysprep files can contain passwords used for deployment and setup. The following locations contain files related to Sysprep.

  • %windir%\Panther
  • %windir%\Panther\Unattend
  • %windir%\System32\Sysprep

In this case, the unattend.xml file has been sanitized but it is always worth checking these locations for passwords and sensitive information.

7. Mount image disk – Copy the SAM file and pass the hash with the Administrator account.

The SAM and SYSTEM files are located in the %windir%\System32\config\ directory.

This file can be copied off to your local machine and Mimikatz can be used to extract the hashes. The Administrator hash can be used in pass the hash attacks with CrackMapExec or Invoke-TheHash.

crackmapexec smb targetip -u username -H LMHASH:NTHASH

Invoke-SMBExec -Target 192.168.100.20 -Domain TESTDOMAIN -Username TEST -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 -Command "command or launcher to execute" -verbose

This can be an extremely effective technique to elevate privileges if the domain has shared local Administrator passwords.

8. Mount image disk – Copy the SAM file and crack the Administrator account.

Like above, once the SAM and SYSTEM files are copied to your local machine, the Administrator account can be cracked with Hashcat or John the Ripper. A sample Hashcat command is below. Visit the hashcat wiki for setup and basic usage.

hashcat64.bin -m 1000 targethashes.txt wordlist.txt -r crackrule.rule -o cleartextpw.txt --outfile-format 5 --potfile-disable --loopback -w 3

Post Login Password Dumps

Once the techniques above have given access to the PXE booted image, we can dump passwords. Mimikatz is a great tool for password dumping.

sekurlsa::logonpasswords will dump passwords from LSASS memory.

lsadump::secrets dumps the LSA secrets.

vault::cred dumps saved credentials from the Credential Manager. However, if a saved credential is set as a domain password type, this command will not retrieve the credential successfully. The Mimikatz wiki has a good explanation on how to extract these credentials.

Mitigation and Prevention

There are inherent security risks associated with the use of PXE deployments that do not require authentication or authorization of any kind, especially on user LANs. It is highly recommended that PXE installations require credentials to begin the installation process. For example, this can be configured on a distribution server simply by checking “Require a password when computers use PXE” in System Center Configuration Manager.

One of the main takeaways from the attacks above is that applications or software that contain sensitive data should not be included in any images. In addition, shared local Administrator passwords or service account passwords should not be used on images (or anywhere in the domain). Images can be compromised and this should help reduce the risk to machines on the domain. Finally, PXE deployments should only be available on isolated networks. Check out these best practices from Microsoft for more information on securing PXE boot deployments.

Source:https://blog.netspi.com/attacks-against-windows-pxe-boot-images/