Microsoft Deprecates Windows Deployment Services After Windows Server 2025 — WDS Attack Surface Audit and Migration Guide for Defenders

Microsoft has confirmed it will deprecate the Windows Deployment Services (WDS) server role, with Windows Server 2025 being the final release that ships it. Deprecation does not mean immediate removal — WDS will continue to function in Windows Server 2025 through its support lifecycle — but the writing is on the wall: organizations still relying on PXE-based, on-premises OS deployment need to plan their exit, and more urgently, they need to understand the attack surface WDS represents today.

This is not a vulnerability disclosure. There is no CVE here. But in my 15+ years of IR and red team work, WDS infrastructure has been a consistent soft target: unauthenticated TFTP access to boot images, plaintext domain credentials sitting in unattend.xml answer files on the REMINST share, and the ability for an attacker with network access to pull down or push operating system images. Deprecation announcements are exactly when defenders should take stock — because unmaintained, forgotten WDS servers become the kind of low-monitored infrastructure that attackers love. If your org runs WDS, this news is your trigger to audit, harden, and plan a controlled migration rather than an emergency one later.

Technical Analysis

What is being deprecated

• Product: Windows Deployment Services (WDS) server role
• Last supported release: Windows Server 2025 — WDS will not ship in the next Windows Server release
• Impact: New deployments of WDS are discouraged; Microsoft is steering organizations toward cloud-native and modern deployment paths (Microsoft Intune / Windows Autopilot, Microsoft Configuration Manager OSD, and other modern provisioning tooling). Note that the Microsoft Deployment Toolkit (MDT), WDS's longtime companion, was already deprecated previously — this closes the loop on the classic on-prem imaging stack.

Why WDS matters from a defensive perspective

WDS operates on protocols and patterns that were designed for convenience, not modern threat models:

1. TFTP-based boot image delivery (UDP/69). TFTP has no authentication and no encryption. Any host on a network segment that can reach the WDS server can request boot images (.wim files) without credentials. Boot and install images frequently contain staging scripts, drivers with embedded service accounts, or pointers to answer files.

2. Answer files with plaintext credentials (MITRE ATT&CK T1552.001 — Unsecured Credentials). The classic WDS compromise path: unattend answer files (unattend.xml, ImageUnattend.xml, Autounattend.xml) stored under the REMINST share (C:\RemoteInstall by default) often contain domain-join credentials in cleartext or reversibly base64 encoding. During red team engagements, we routinely check \\<server>\REMINST early in an engagement — it's one of the fastest ways to get a domain-join-capable service account.

3. PXE/DHCP trust relationships. WDS responds to PXE boot requests (DHCP options 66/67 or ProxyDHCP on UDP/4011). A rogue PXE server on the same segment — or a compromised WDS server — can push attacker-controlled images to endpoints at boot time, pre-OS, below the visibility of most EDR tooling. Conversely, an attacker can PXE-boot their own machine from your WDS server and extract data from the delivered image offline.

4. Post-deprecation rot. Once WDS stops shipping, existing deployments will age out of patch attention and institutional memory. Deprecated-and-forgotten infrastructure is where incident response engagements begin.

Exploitation status

There is no CVE associated with this announcement and no new exploit. However, the underlying techniques — credential harvesting from deployment shares, TFTP image theft, and rogue PXE/DHCP services — are well-established, publicly documented tradecraft used in both penetration tests and real intrusions. Treat this as a configuration and architecture risk, not a patch event.

Detection & Response

The detections below target the abuse patterns against WDS infrastructure that you should be watching for now, during your audit window. They are tuned to behaviors that should be rare in most environments — legitimate WDS administration happens from known admin hosts, and TFTP client use on servers is almost never legitimate outside the WDS role itself.

SIGMA Rules

---
title: Suspicious Access to WDS Answer Files via Command Line
id: 3f8a1c24-7b2e-4d19-a6c3-9e5f2b8d1a47
status: experimental
description: Detects command-line access to unattend answer files or the REMINST share associated with Windows Deployment Services. Attackers harvest these files for plaintext domain-join credentials.
references:
  - https://attack.mitre.org/techniques/T1552/001/
  - https://www.bleepingcomputer.com/news/microsoft/microsoft-to-deprecate-windows-deployment-services-after-windows-server-2025/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_share:
    CommandLine|contains:
      - '\\REMINST'
      - '\\RemoteInstall'
  selection_file:
    CommandLine|contains:
      - 'unattend.xml'
      - 'ImageUnattend.xml'
      - 'Autounattend.xml'
  selection_tools:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\type.exe'
      - '\findstr.exe'
      - '\xcopy.exe'
      - '\robocopy.exe'
      - '\copy.exe'
  condition: (selection_share or selection_file) and selection_tools
falsepositives:
  - Legitimate OS deployment engineering from known build/admin workstations
level: high
---
title: TFTP Client Execution on Windows Systems
id: 8c2d5e91-4a7f-4b36-9d28-1e6c3a5f7b92
status: experimental
description: Detects execution of the Windows TFTP client, which can be used to exfiltrate WDS boot and install images without authentication. TFTP client use is rare outside of network infrastructure management.
references:
  - https://attack.mitre.org/techniques/T1105/
  - https://www.bleepingcomputer.com/news/microsoft/microsoft-to-deprecate-windows-deployment-services-after-windows-server-2025/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.exfiltration
  - attack.t1105
  - attack.collection
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\tftp.exe'
  filter_known_wds:
    CommandLine|contains:
      - 'wdsserver'
  condition: selection and not filter_known_wds
falsepositives:
  - Network engineers managing switch/router firmware via TFTP from admin workstations
level: medium
---
title: WDS Administration Utility Execution from Non-Standard Hosts
id: 5b1e9f38-2c4a-4e87-b7d6-3a9f8c2e6d15
status: experimental
description: Detects execution of wdsutil.exe, the WDS management utility. Outside of known deployment servers and build engineers, this may indicate reconnaissance or manipulation of deployment images.
references:
  - https://attack.mitre.org/techniques/T1557/
  - https://www.bleepingcomputer.com/news/microsoft/microsoft-to-deprecate-windows-deployment-services-after-windows-server-2025/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.discovery
  - attack.collection
  - attack.t1557
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\wdsutil.exe'
falsepositives:
  - Deployment engineers performing legitimate image management
  - Automated image import pipelines on the WDS server itself
level: medium

KQL — Microsoft Sentinel / Defender Hunting

This query hunts for the combined abuse pattern: answer-file access, TFTP client use, and WDS utility execution, with host/user context for triage. Run it across your fleet and baseline anything that fires — legitimate hits should trace back to a small set of known build servers and deployment engineers.

let WDSAbusePatterns = dynamic(["REMINST", "RemoteInstall", "unattend.xml", "ImageUnattend.xml", "Autounattend.xml"]);
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where
    (FileName =~ "tftp.exe")
    or (FileName =~ "wdsutil.exe")
    or (ProcessCommandLine has_any (WDSAbusePatterns)
        and FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "findstr.exe", "xcopy.exe", "robocopy.exe"))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessAccountName, ReportId, DeviceId
| sort by TimeGenerated desc

If you ingest DHCP/firewall telemetry into Sentinel, also alert on new or unexpected sources responding to PXE/bootp traffic (UDP 67/68/4011) — a rogue PXE responder on a client VLAN is a serious finding that predates and outlives WDS itself.

Velociraptor VQL — Credential Exposure Hunt

This artifact sweeps suspected WDS servers for answer files and flags any containing credential material — the single highest-value finding in a WDS audit. Deploy it against systems with the WDS role installed.

-- Hunt for plaintext credentials in WDS answer files on deployment servers
SELECT FullPath, Size, Mtime,
       read_file(filename=FullPath) AS Content,
       count(string=split(string=read_file(filename=FullPath), sep='assword')) AS PasswordHits
FROM glob(globs='C:/RemoteInstall/**/*.xml')
WHERE Content =~ '(?i)<Password>|<Value>.*</Value>'
  AND Content =~ '(?i)<Password>'
ORDER BY PasswordHits DESC

Extend the glob to any custom image store paths in your environment (DataPath/RootFolder values in the WDS registry configuration at HKLM\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP if you relocated the REMINST share).

Remediation / Audit Script

Run this on candidate servers (or via your RCM/remote execution tooling fleet-wide) to inventory WDS exposure and locate credential-bearing answer files:

# WDS Audit Script — Security Arsenal
# Run elevated on Windows Servers. Reports role status, share exposure, and credential artifacts.

# 1. Is the WDS role installed?
$wdsRole = Get-WindowsFeature -Name WDS -ErrorAction SilentlyContinue
if ($wdsRole -and $wdsRole.Installed) {
    Write-Host "[!] WDS role INSTALLED on $env:COMPUTERNAME" -ForegroundColor Red

    # 2. Is the WDS service running?
    $svc = Get-Service -Name WDSServer -ErrorAction SilentlyContinue
    Write-Host "    Service state: $($svc.Status)"

    # 3. Locate REMINST share and root path
    $share = Get-SmbShare -Name 'REMINST' -ErrorAction SilentlyContinue
    if ($share) { Write-Host "    REMINST share: $($share.Path)" -ForegroundColor Yellow }

    # 4. Scan for answer files containing credentials
    $roots = @('C:\RemoteInstall')
    if ($share) { $roots += $share.Path }
    foreach ($root in ($roots | Select-Object -Unique)) {
        if (Test-Path $root) {
            Get-ChildItem -Path $root -Recurse -Include *.xml -ErrorAction SilentlyContinue |
              Where-Object { $_.Name -match 'unattend' } |
              ForEach-Object {
                  $content = Get-Content $_.FullName -Raw -ErrorAction SilentlyContinue
                  if ($content -match '(?i)<Password>') {
                      Write-Host "    [CRITICAL] Plaintext credential pattern in: $($_.FullName)" -ForegroundColor Red
                  } else {
                      Write-Host "    Answer file (review manually): $($_.FullName)"
                  }
              }
        }
    }

    # 5. Check TFTP listener (UDP 69) exposure
    $tftp = Get-NetUDPEndpoint -LocalPort 69 -ErrorAction SilentlyContinue
    if ($tftp) { Write-Host "    TFTP listening on UDP/69 — verify network segmentation" -ForegroundColor Yellow }
} else {
    Write-Host "[+] WDS role not installed on $env:COMPUTERNAME" -ForegroundColor Green
}

Remediation

This is a lifecycle and architecture event, so remediation is about audit, containment, and migration — in that order.

Immediate (this quarter):

1. Inventory. Identify every server with the WDS role installed across your estate, including lab and branch-office servers. The script above is a starting point; pair it with your asset inventory and SCCM/Intune hardware inventory data.
2. Hunt for credential exposure. Scan every REMINST share and image store for answer files containing <Password> values. Any domain-join account found in plaintext must be treated as compromised: rotate the password immediately and review that account's authentication history for anomalies.
3. Constrain network exposure. WDS/TFTP/PXE should only be reachable from dedicated deployment VLANs. Enforce ACLs blocking UDP/69 and UDP/4011 from general user segments. No endpoint outside the build network should be able to pull a boot image.
4. Baseline monitoring. Deploy the detections above and build an allow-list of legitimate build hosts and deployment engineers. Any WDS utility or answer-file access outside that list is an investigation.

Strategic (before Windows Server 2025 end of support):

5. Choose your migration path now. Microsoft is steering organizations toward Windows Autopilot + Microsoft Intune for cloud-joined provisioning, or Microsoft Configuration Manager OSD for environments that still need on-prem/task-sequence-driven imaging. Don't wait for a forced migration during a future server upgrade crunch — run a pilot this year.
6. Decommission cleanly. When a WDS server is retired: uninstall the role (Uninstall-WindowsFeature WDS), delete the REMINST share and residual images, and remove any DHCP options (66/67) pointing at it. Stale DHCP options pointing at decommissioned infrastructure are an attack-enabler if that IP is ever reused.
7. Watch the rogue-PXE angle permanently. The rogue PXE/DHCP responder technique does not retire with WDS. Keep DHCP snooping enabled on access switches and alert on unauthorized bootp responders — this control outlives any single product.

Reference: Microsoft announcement coverage — https://www.bleepingcomputer.com/news/microsoft/microsoft-to-deprecate-windows-deployment-services-after-windows-server-2025/

The organizations that handle deprecations well treat them as scheduled risk-reduction projects, not surprises. WDS has served its purpose, but its trust model belongs to a different era. Audit what you have, rotate anything it leaked, and migrate on your own timeline — not an attacker's.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub