2026-05-20 06:08:00 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文揭示了红队行动中常被忽视的MicrosoftDeploymentToolkit(MDT)部署共享存在的严重凭据泄露风险。文章详细分析了MDT错误配置导致的关键文件（如Bootstrap.ini、CustomSettings.ini、ts.xml等）中存储的DomainAdmin、UserID等敏感凭据位置，并提供了从部署共享中提取凭据的具体方法和攻击路径。作者强调MDT配置不当可能成为域内横向移动的快速通道，建议防御者加强共享权限管理和敏感文件监控。 综合评分： 87 文章分类： 红队,内网渗透,渗透测试,漏洞分析

cover_image

红队金矿：从 MDT 部署共享中提取凭据

Oddvar Moe Oddvar Moe

securitainment

2026年5月19日 11:11 中国澳门

在小说阅读器读本章

去阅读

| 原文链接 | 作者 | | — | — | | https://trustedsec.com/blog/red-team-gold-extracting-credentials-from-mdt-shares | Oddvar Moe |

在红队行动中针对企业部署基础设施时，SCCM ( System Center Configuration Manager )往往独享所有关注。围绕 SCCM 错误配置、凭据暴露以及横向移动机会的研究、技战法和博客文章层出不穷。但当 SCCM 站在聚光灯下时，它那位常被忽视的远房表亲 —— Microsoft Deployment Toolkit ( MDT )—— 却悄然提供着一些同样的机会，有时所需的功夫甚至 _更少_。然而 MDT 却经常被排除在讨论之外。本文就来填补这块空白。

MDT 入门

MDT 是一款工具包，旨在帮助企业环境以简便的方式部署操作系统，而无需搭建一整套 SCCM 基础设施。对于许多客户而言，从所需功能的角度来看，MDT 是一个完美契合的方案。多年来，MDT 一直是一款出色的工具，甚至还提供与 SCCM 的集成，以便用额外功能扩展 SCCM 的能力。在使用 MDT 时，你常常会看到 LTI 和 ZTI 这两个术语，它们分别是 Lite-Touch Installation ( 轻接触安装 ) 和 Zero-Touch Installation ( 零接触安装 ) 的缩写。独立使用 MDT 时被视为 LTI;而通过与 SCCM 的集成使用时，则被视为 ZTI。

MDT 的安装过程非常简单，这里有一份很好的官方文档可供参考。

首先，搭建一台 Windows 服务器，然后从 Microsoft 页面下载 MSI 安装包并运行。此外，还需要安装 Windows ADK。一切就绪后，启动 Deployment Workbench，通常按照向导即可设置一个 Deployment Share。

图 1 – 创建一个新的 Deployment Share

图 2 – 共享名称的默认建议

Deployment Share 创建完成后，你就可以导入操作系统、驱动程序，添加应用程序和软件包，并创建任务序列。

图 3 – Deployment Workbench 总览

如果你阅读 Microsoft 的文档，会看到其中推荐使用一个专用的 MDT AD 加入账户 ( 用于将机器加入 AD ) 以及一个 MDT 服务账户 ( 用于部署镜像时连接 MDT Deployment Share 并安装文件 )。该文档同时说明了如何在创建的 MDT Deployment Share 上正确配置权限，以及 MDT AD 加入账户所需的权限设置。

为什么 MDT 值得关注

前面提到文档说明了如何正确配置权限;然而在大多数情况下，当我在实战中遇到 MDT 时，极少看到它被正确配置。更常见的情形是，Deployment Share 被共享给了所有用户，意味着任何 AD 账户都能在该服务器上打开 MDT Deployment Share 并浏览其内容。你可能会想：那又如何？让我们来看看其中潜藏的风险。

我们先了解一下管理员配置 MDT 的几个典型位置。第一个位置是 Rules部分。你可以通过右键点击 Deployment Share 并选择 Properties 找到它。在 Properties 对话框中，选择 Rules选项卡。

图 4 – Rules 示例

如你所见，MDT 部署配置中定义了大量属性。这些属性决定了一旦部署在目标机器上启动后将如何执行。

举例来说，一个关键属性是 DeploymentType,在本例中被设置为 NEWCOMPUTER。这告知 MDT:从此共享部署的机器应作为新计算机处理，即一台从未加入过域的系统。

接下来，我们看看一些更有意思的设置：凭据。

在截图中，你可能注意到 DomainAdmin和 UserID都有对应的值，并各自关联了一个密码。那么它们有何区别？各自又用于什么？

– DomainAdmin:MDT 用于将计算机加入域的账户。

– UserID:用于访问网络资源的账户 —— 通常就是 MDT Deployment Share 本身。

如果你在 MDT Workbench 中点击过 Edit Bootstrap.ini按钮，你应该见过 bootstrap.ini 文件。对于一次完全自动化的 Lite Touch Installation ( LTI ),管理员需要在该文件中同样添加 UserID属性。

作为一名渗透测试人员，你或许会想：管理员在此处填入凭据后，如何才能找到它们？这正是错误配置的 Deployment Share 发挥作用的地方。如果你能在一台 MDT 部署服务器上找到这些共享并具备浏览权限，那么找到你所需内容的可能性就相当高。在 Deployment Share 中，可重点查看以下位置：

Bootstrap.ini

—— 位于 DeploymentShare\Control\Bootstrap.ini
CustomSettings.ini

—— 位于 DeploymentShare\Control\CustomSettings.ini

图 5 – 浏览 Deployment Share 的示例

为了方便阅读，我整理了下面这张表，列出了值得关注的若干属性。

所有属性均可在 Microsoft 的这份文档中查到：https://learn.microsoft.com/en-us/intune/configmgr/mdt/properties

还有更多

我们已经过了一遍最常见的凭据藏匿点，但要注意，密码也可能出现在其他位置。先来看管理员是如何在任务序列里实现自定义命令的。打开一个任务序列，界面大致如下面的截图所示 ( 如果你熟悉 SCCM，会觉得任务序列的样子有点眼熟 ):

图 6 – 任务序列视图

在这里，管理员可以点击 Add,然后从一长串可选活动中挑选所需项。

图 7 – 任务序列活动

假设管理员需要在部署过程中运行一个特殊命令以修复某个遗留问题，并且出于某种原因 ( 权限或访问限制 ),这个命令必须以某个特定用户身份运行才有效。这种情况下，管理员会选择 Run Command Line,并按下图所示进行填写。

图 8 – 添加自定义命令

完成填写并保存后，这些信息会被存储在 DeploymentShare\Control\TASKSEQUENCENAME\ts.xml中。具体形态可以参考下面的截图。

图 9 – ts.xml 中的凭据

再来看另一个场景。假设管理员想直接自定义 unattend.xml( 安装引擎应答文件 ),因为并非所有内容都能通过 Deployment Workbench 添加。同时，管理员也想硬编码本地管理员账户，以确保该密码在部署期间被正确设置，或者只是因为排错的需要而留在了里面。unattend.xml文件可以在 DeploymentShare\Control\TASKSEQUENCENAME\unattend.xml中找到。

图 10 – 来自 unattend.xml 的示例

最后，自然少不了脚本里硬编码的凭据。这通常是放在部署共享上、并在部署过程中执行的某个自定义脚本。自定义脚本并没有默认存放位置，理论上放在哪里都行。不过我发现，DeploymentShare\Scripts以及 DeploymentShare\Applications文件夹是比较常见的去处。每次进入一个塞满 MDT 文件的目录，我都会按修改日期排序，把那些时间和其余脚本对不上的挑出来逐一查看。

另外，如果你碰巧看到名为 LiteTouchPE_x86|x64.iso或 LiteTouchPE_x86|x64.wim的文件，建议把它提取出来，在里面找一找 bootstrap.ini。我见过这类文件被存放在其他 IT 相关的共享上，用于制作 USB 启动盘进行安装 —— 而这恰好为我打开了通往整个 Deployment Share 和 MDT 服务器的大门。

番外篇

在结束本文之前，再补充一个小彩蛋。每次在实战中做初始侦察时，我总会顺手查一下 Tattoo信息。原因在于：当一台计算机或服务器通过标准的 MDT 任务序列被部署后，会经过一个名为 Tattoo的步骤。

图 11 – 任务序列中的 Tattoo 步骤

那么 Tattoo步骤到底做了什么？简单说，它会把部署相关的部分信息”刻印”到计算机上，这些信息会被写入到 *HKLM\Software\Microsoft\Deployment 4*之下。它虽然不会留下所有信息，但红队人员一眼就能识别出环境中存在 MDT 在运转。剩下的事就简单了 —— 只需找到 MDT 服务器，顺藤摸瓜挖出那些藏着好东西的部署共享！

总结

MDT 完全可以成为在域中收割凭据的一张快速通行证。设想一下，如果 adjoin账户被用来把所有服务器加入域，那就意味着拿下了一批 AD 账户的所有权。再设想一下，如果该账户在域中被赋予了远超其本应拥有的权限 ( 我就见过它被加为域管理员成员 ),那么这一刀很可能就是致命一击。希望本文对你有所帮助，也希望你能从中学到一些新东西！

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Oddvar Moe Oddvar Moe《红队金矿：从 MDT 部署共享中提取凭据》