From Deployment to Compromise: Understanding Credential Storage in Microsoft Deployment Toolkit

11 Jan 2025 in Offensive Security

A look into how Microsoft Deployment Toolkit stores credentials, how they can be obtained by a threat actor (or pentester), and what you can do to securely manage them.

• Introduction
• What is Microsoft Deployment Toolkit?
• What’s the issue?
• What are my options?

Introduction

One of the tasks I frequently perform during Assumed Breach engagements is exploring SMB shares accessible to the “compromised” user to find information that would be useful to a threat actor.  In numerous engagements, I have discovered Microsoft Deployment Toolkit (MDT) deployment shares available to all users within an Active Directory environment.  This access quickly becomes more concerning when you consider that MDT stores service credentials used for the computer deployment process in cleartext.  In almost all cases, I have documented MDT configurations that hold cleartext credentials to overprivileged accounts, including Domain Admin access.

This article will explore common misconfigurations frequently discovered in MDT deployments and options to reduce the MDT attack surface.

What is Microsoft Deployment Toolkit?

MDT is a free, Microsoft-provided solution that automates Windows and Windows Server OS deployments.  Using this solution, organizations can create deployment workflows to automate nearly every part of operating system deployment, including:

• Network boot (in conjunction with Windows Deployment Services)
• Operating system deployment
• Post-install script execution and endpoint configuration
• Application installation
• Active Directory membership

The latest version of MDT was released in September 2020 and officially supports up to Windows 10 1809 and Windows Server 2019¹; however, there are examples of MDT being used to deploy Windows 11.  A GitHub project is in development to “modernize” the solution by moving the scripting elements of MDT from VBScript to PowerShell².  This solution will likely remain an option for the foreseeable future, so we must understand the security impacts of such a solution, especially as it has not received an official update in four years.

What’s the issue?

By default, a new MDT install creates a folder, C:\DeploymentShare, and shares this folder as DeploymentShare$.  This share contains all MDT information, including configurations, VBScript, task sequences for automated deployments, and applications.  At the time of writing, an MDT install only provides share and file system access to the Local Administrators group of the MDT server.  In practice, I have noted multiple instances of organizations modifying permissions to grant ‘Authenticated Users’, Domain Users’, or ‘Everyone’ read access to this share.  

To aid the deployment process, areas within the MDT configuration exist where one can provide service account passwords. Providing these credentials enable more workflow automation within MDT.  These configuration files are found within C:\DeploymentShare\Control and are titled CustomSettings.ini and Bootstrap.ini.

Domain Join Credentials

To provide MDT with the ability to join a deployed endpoint to the domain, three properties can be added to the configuration files: DomainAdmin, DomainAdminDomain, and DomainAdminPassword.  These values provide the username, password, and domain of an account with permission to join the endpoint to the domain.  While the property names would lead one to believe this account requires Domain Admin privileges, this is incorrect.  This account only needs privileges to add a device to Active Directory.

To me, this is one of the most significant areas of misconfiguration and one I have taken advantage of the most in engagements.  Because this account needs to be an Active Directory account to add endpoints to the domain, it provides a threat actor with a prime opportunity to obtain an account to move throughout the domain.  As mentioned previously, I frequently find that these accounts possess Domain Admin privileges.  In the engagements where I run across this issue, this exposure essentially provides access to a Domain Admin or other highly privileged account to all users on the domain.  Not only is this a great stepping stone for a threat actor in the network, it’s also a configuration error that could be used by legitimate users internal to the network, maybe an employee that wants to make some changes to their computer or access sensitive files they otherwise would not have access to.

Local Administrator Credentials

Also potentially found within these configuration files is the property AdminPassword.  This property sets the password of the local administrator account.  A second location where local administrator passwords exist is within unattend.xml files.  These files contain the instructions needed by the Windows installation process to configure operating system elements automatically.  The local administrator password can be set here in plaintext or base64 encoded.  Alternatively, it is also possible to use unattend.xml to create entirely new users and assign passwords to those accounts.

Access to these local passwords could allow a threat actor to move laterally throughout the network to any endpoints deployed through MDT.  While the usage of Microsoft’s Local Administrator Password Solution (LAPS) helps mitigate this issue by providing unique local administrator accounts per workstation after the deployment process is complete, a threat actor can leverage a password stored within this property in situations where administrator password use is high or where LAPS is not fully deployed within an organization.

Deployment Share Authentication Credentials

By default, a user must authenticate to the deployment share within the MDT pre-boot environment.  As discussed previously, access to the deployment share is limited to local administrators on the MDT server.  If an organization wants to circumvent this authentication requirement and allow any device to automatically authenticate to the deployment share, they could provide the properties UserID, UserDomain, and UserPassword.  The user information provided in these properties is used to automatically grant a machine access to the deployment share.

These are three of the primary credential storage mechanisms I have witnessed. However, a review of all configurable properties³ within MDT shows other options for password storage, including storing passwords to credentials that can promote a deployed server to a domain controller.  These configuration files, and the deployment share in general, are prime targets for threat actors looking to further their access.

What are my options?

Now that we have detailed some areas of concern, let’s review some configuration options that can implemented to make my job a bit harder during an assessment.

Understand Credential Storage Locations

The best way to prevent credential leakage is to understand where those passwords are hardcoded into configuration files.  Powershell is a great option to search through your deployment share for passwords. An example below illustrates an option for searching the Control folder for the DomainAdminPassword property. The variables can be modified to expand the scope to the entire deployment share or search for a more generic string like ‘password’, though it could generate more noise in your specific environment.

# Define the search directory and pattern
$Path = "C:\DeploymentShare\Control"
$Pattern = "domainadminpassword"

# Process files
Get-ChildItem -Path $Path -Recurse -File -ErrorAction SilentlyContinue | ForEach-Object {
    $FilePath = $_.FullName
    Select-String -Path $FilePath -Pattern $Pattern -ErrorAction SilentlyContinue | ForEach-Object {
        # Output each match immediately
        [PSCustomObject]@{
            FilePath    = $_.Path
            LineNumber  = $_.LineNumber
            MatchedText = $_.Line.Trim()
        } | Format-Table -AutoSize
    }
}

Limit Domain Privileges

Limiting the privileges of the account used to join newly deployed endpoints to Active Directory is one of the best methods you have at your disposal to avoid MDT credential abuse.  The goal is to ensure that even if the credential is stolen, the threat actor is limited in their options.  There are a few recommendations here:

• Audit the account to ensure it isn’t a member of any privileged groups

• Delegate rights to the account.  Based on the use case, this can be granted to the domain level or specific OUs.

• Restrict logon privileges to the account through Group Policy.  This will ensure that if the credentials are obtained, their use is severely limited.

Limit File and Share Access to Deployment Share

Access to c:\DeploymentShare, both NTFS and share permissions, should be limited to employees responsible for imaging machines.  User accounts should not need access to this share.  Restricting access to this share will serve as another layer of protection for the configuration files.

Consider Updated Technologies

While MDT does work for Windows 11, it is not a service that Microsoft will continue to support moving forward.  Modern endpoint deployment services such as Intune and Autopilot are worth a look.

1. Microsoft Deployment Toolkit Supported Platforms - Microsoft Learn ↩︎

2. PowerShell Deployment Extension Kit ↩︎

3. Microsoft Deployment Toolkit Configuration Properties ↩︎