Share By: Garrett Foster • 12 min read TL;DR – After reporting vulnerabilities found in MDT, Microsoft chose to retire the service rather than fix the issues. As of January 6, 2026, Microsoft stopped supporting MDT and will no longer provide updates, including security patches. Admins should follow the defensive recommendations to mitigate the issues if they choose to continue using the software or can’t migrate to a different solution. Acknowledgements Before diving in, I’d like to acknowledge the work of other security researchers on similar topics: Thomas Elling from NetSPI, who wrote a blog on attacking PXE boot images Jason Mull , who wrote a blog on Microsoft Deployment Toolkit (MDT) credential storage Chris Panayi, who wrote a blog and presented at DEF CON 30 about attacking SCCM task sequences Intro In the summer of 2025, TrustedSec’s Oddvar Moe published a blog titled “Red Team Gold: Extracting Credentials from MDT Shares” that details targeting MDT to acquire privileged Active Directory (AD) domain credentials. If you’re unfamiliar with the service, I encourage you to take a moment to read his blog, where he lays out the foundation of MDT and how it can be configured. From an offensive point of view, my mindset has always been that creds are king. The more credentials I can acquire and retain access to, the better. This is especially true when they have some kind of privilege. However, it was his wrap-up to the blog, combined with a Microsoft-recommended PowerShell script that grants excessive permissions during deployment, that convinced me to look into it further. After finishing the blog and considering the high value of the configured service account, I was left with three questions: Can we locate the MDT servers? Can we locate them unauthenticated?fanot Can we bypass the security controls? Can we locate the MDT servers? At a high level, MDT is a file share used to build and host operating system images and deployment task sequences. To deploy the image, MDT relies on a separate service such as Windows Deployment Services (WDS). WDS is a network boot solution (PXE boot) that Microsoft recommends for a production MDT deployment is Windows Deployment Services (WDS). The installation of WDS is relatively straightforward, but there are some interesting parts. The first is that the admin is given three options for how the service may respond to potential clients. The first, and most restrictive, is to not respond to any PXE boot clients. The second is to respond to only known client computers, such as a pre-staged AD computer that the new OS will take over. The last involves responding to any PXE client computer with optional administrator approval. We can also choose between two installation options: deploy the WDS server as a standalone server, or integrate it with AD. For what it’s worth, I’ve never come across a standalone server before. Remote Access As part of the AD integration, a serviceConnectionPoint object is created as a child object of the WDS server’s AD machine account. Authenticated users can query AD to identify all servers that may have the WDS role installed. The three configuration options shown in the previous section are stored on this object. As an attacker, this is useful because it discloses which servers may have more lax controls, which will be more relevant in the upcoming sections. In Microsoft’s deployment guide, the WDS role is installed side-by-side with the MDT service. While this won’t reflect all deployments, it’s a solid first check in AD to locate the MDT server. And, since this is an authenticated lookup, reviewing the file shares of the WDS server may confirm it’s the MDT server based on the Deployment Share’s default remarks: Client Access From the client perspective, Oddvar already touched on the Tattoo registry entry resulting from the Tattoo task sequence step in MDT, which discloses that the Windows host was previously deployed using MDT. Another location to query is the Unattend.xml file. In my experience and in my lab, I found it in the C:\Windows\Panther directory, but it may appear in other locations as well. If you’re unfamiliar, this file is called an “answer file” and is used to automate OS installation. Thomas Elling’s blog post in 2018 details targeting these files before they’re used for deployment. In this case, since it’s post-deployment and there are steps to remove sensitive information from the file, we can’t recover credentials from it; however, we can still see the UNC path from where the image was installed, which could point to an MDT server. Can we locate them unauthenticated? To work through the previous section, I had to actually walk through the PXE boot process in my lab. If you’re curious about how the process works, this blog post walks through the technical details. To summarize that post, though, an OS deployed through WDS follows a basic DHCP sequence: The PXE client boots and sends a DHCP DISCOVER packet claiming the host nee...