Windows Deployment Services (WDS) is a partially deprecated Windows role providing PXE boot services for deploying machines over a LAN. Although its usage has declined since the release of Windows 11, it often remains in Active Directory environments because it has been overlooked, leaving even up-to-date networks potentially exposed. Default administrative practices, sometimes masked by Windows behaviors, further increase the attack surface. The recent deprecation of Microsoft Deployment Toolkit (MDT), widely used for image orchestration and customization alongside WDS, accelerates the ecosystem’s retirement while leaving existing deployments exposed and security issues unresolved. This presentation examines the attack vectors that can be exploited against WDS servers in Active Directory environments. Scenarios will include credential leakage, WinPE image extraction, and a supply chain attack, demonstrated through examples from real-world penetration tests on information systems. Practical exploitation paths, common misconfigurations, and residual artifacts left after removal of PXE components will be highlighted. Possible ways to address these risks in enterprise environments will also be discussed.

Outline

I. Introduction and Reminders

A. Main technical terms demystified

• What exactly is PXE? Spoiler it’s not a protocol, but a boot mechanism built on top of DHCP and TFTP
• Role of WDS in an Active Directory environment
• Interaction with MDT (Microsoft Deployment Toolkit) for automated deployment workflows

B. Origin of My Research and Where WDS Still Exists

• Initially identified during real-world penetration tests, this exposure repeatedly appeared across multiple clients (including environments considered up to date).
• In most cases, it was found in typical enterprise infrastructures where WDS had survived several Windows migrations, often within flat or poorly segmented networks, alongside abandoned yet still reachable servers.

C. Why It Becomes a Problem and Why It Is Still Here in 2026

• Common misconfigurations that increase exposure across information systems
• Online tutorials that explain how to use WDS and MDT, but rarely address security implications
• Credentials often stored in deployment workflows to simplify administrative tasks
• Implicit trust placed in the deployment infrastructure for years by sysadmins
• Residual artifacts left behind after partial decommissioning of the WDS role
• Migration complexity and low perceived risk among administrators: managing network-based deployments is operationally complex, and changing solutions requires extensive testing and training
• Reluctance to pay for SCCM or migrate to Intune, a cloud-oriented solution

II. Demos

A. Reconnaissance Phase

1. Without Credentials - DHCP & TFTP

• Simulate a PXE client using a VM or a physical machine, attempt to boot via PXE, and investigate sensitive files (credentials, etc.) exposed over the TFTP protocol (only possible if network segmentation is weak)
• Obtain the PXE server address by requesting it from the DHCP server

2. With Active Directory Credentials - LDAP or SMB

LDAP Object Enumeration to Retrieve the PXE Server

• Practical techniques for enumerating WDS-related objects in Active Directory (when domain-integrated)

SMB Enumeration

• Discovery of SMB shares whose names almost never change: REMINST\ (readable by any authenticated domain user by default, and considered normal behavior) or DeploymentShare$\ (usually restricted to the local admin and, in practice, to domain administrators as well)
• Why SMB is often more practical than TFTP from an attacker’s perspective when targeting a WDS server

B. Exploitation - Manual

1. Direct Credential Extraction

• Direct access to deployment configuration and automation files that may contain credentials

2. Offline Image Abuse

• Inspection of .wim images when no credentials are exposed in accessible shares (focus on the WinPE image)
• Local extraction and file system reconstruction for credential hunting

3. Supply Chain Attack - Misconfigured deployment server in production you said?

Attack surface:

• Misconfigured DeploymentShare$\ with read and write access for all domain users
• Ability to modify existing deployment scripts (Malicious code execution during the next deployment cycle without creating a new task sequence)

C. Exploitation – Partially Automated

• Introducing the module wds_mdt from nxc (NetExec)
• Brief overview of other existing tools
• Step-by-step demonstration with sequential screenshots of the attack workflow

III. What About Detection?

• Why standard EDR/XDR solutions usually do not generate alerts
• Operations resemble legitimate administrative activity
• Only noisy behavior, such as large SMB scans to locate the REMINST\ share, tends to trigger detection
• Logging blind spots in both Windows and network monitoring
• How detection and logging can be improved, and what preventive measures can be implemented

IV. Remediation and Defensive Guidance

• Fully decommission or isolate the WDS server (if WDS is no longer used)
• Clean up deployment share files, including REMINST\ and DeploymentShare$\
• Use a dedicated network segment for PXE traffic in any case
• Deploy a dedicated DHCP server isolated from the main DHCP infrastructure
• Consider migrating to MECM or third-party solutions such as Ivanti or FOG Project

V. Takeaways

• WDS remains widely overlooked in many enterprise environments, which makes it a particularly valuable Active Directory pivot point from an attacker’s perspective.
• Deployment SMB shares and associated WinPE images frequently expose credentials or sensitive configuration data, even in infrastructures considered mature or up to date.
• Removing the WDS role alone does not eliminate the risk. Residual deployment shares and legacy configuration artifacts must also be audited and cleaned.
• Most abuse scenarios rely on legitimate protocols and expected administrative behavior. In practice, this type of activity has never triggered an EDR or XDR alert during real-world engagements.