Skip to main content

MITRE ATT&CK TTPs

Requirements

  • Unauthenticated network access
  • Line of sight to DHCP server (optional, but helps)
  • Line of sight to PXE-enabled distribution point

Summary

SCCM contains a preboot execution environment (PXE) feature which allows systems to load a specific operating system image on boot. When PXE is configured, SCCM will make various configuration changes to the distribution point (DP). Most notably, the PxeInstalled and IsPxe values under the HKLM\Software\Microsoft\SMS\DP registry key are set to 1. The boot images are then deployed from the site server to the DP’s file system at C:\RemoteInstall\. The three required components for PXE boot to work are: a PXE client, a DHCP server, and a PXE-enabled DP. A non-domain-joined computer (the PXE client in this case) that has network access could initiate the DHCP process, resulting in the PXE client receiving a DHCPPACK request containing the BootFileName location and Windows Deployment Services (WDS) network boot program (NBP). Next, the client initiates a TFTP session to download the NBP. The NBP contains several files and and programs that are used to boot the computer into a Windows Preinstallation Environment (WinPE). To Summarize this process, how PXE works in SCCM:
  1. PXE client gets an IP from DHCP server
  2. Client sends new DHCPREQUEST to DP, DP responds with DHCPACK that contains the BootFileName
  3. Client starts TFTP session targeting the boot file
  4. Client downloads the network boot program (NBP)
  5. NBP downloads the operating system loader and boot files
  6. The WinPE image is loaded into a RAMDISK in memory
  7. WinPE boots, loading a task sequence (TS) boot shell, TS manager boot strap (TsPxe.dll)
  8. TS environment variables and a client certificate are downloaded via TFTP
  9. TSPXE locates the MP and downloads policy assignments
  10. Collection and machine variables are downloaded
Note: This goes beyond the scope of this article, but Microsoft’s documentation covers it in more depth. This process can be abused because the files and policies can be accessed without booting the PXE media. By initiating the DHCPDISCOVER request, an attacker can locate the PXE media on the network, or they can contact a PXE-enabled DP directly if they know its name or IP address. If the PXE media stored there is password-protected, the hash can be retrieved and cracked offline using hashcat and this custom module from Christopher Panayi. If not protected, the cleartext data can be directly used. PXEThief and pxethiefy both enable and make it trivial to conduct this attack. Once the media file is decrypted, it may contain or be used to obtain credential material in the NAAConfig (network access account(NAA)), TaskSequence, and CollectionSettings (collection variables) policies.

Impact

Attackers may recover domain credentials from this process, the difficulty of which is a direct function of the complexity of the password set on the PXE media file. If a weak password is set, cracking the password is relatively computionally “easy,” depending on the hardware. With these credentials, attackers may transition from an unauthenticated context on the network to a domain-authenticated context. If any of the credentials recovered are privileged, it may also enable privilege escalation and lateral movement vectors.

Defensive IDs

Examples

PXEThief

It is now possible to locate a PXE-enabled DP, download the encrypted media variables file, recover the certificate and management point URL from the variables file, and request and deobfuscate policy secrets in one command from a Linux box with this PR to PXEThief by Nic Losby @Blurbdust: https://github.com/MWR-CyberSec/PXEThief/pull/11

Pxethiefy.py

Using pxethiefy from a Linux machine with network access to retrieve a PXE media file with no password set:

Cred1py

Using Cred1py from a Linux machine over a UDP SOCKS5 proxy to retrieve the decryption key for a PXE media file: On Cobalt Strike, enable UDP SOCKS5 proxy on port 9090:
Then execute Cred1py with:

References