通过 AD CS RPC 端点将 IIS AppPool 提权至 NT AUTHORITY/SYSTEM

securitainment · 2026-09-01 12:29 · 6 阅读

mannulinux 2026-09-01 12:29 中国香港

利用 IIS AppPool 访问网络资源时身份被静默提升为机器账户这一设计行为，经 AD CS RPC 端点以机器账户证书换取 TGT，再借 S4U2Self 模拟管理员，最终无需 Potato 漏洞即可完成提权。

原文链接	作者
https://www.mannulinux.org/2026/08/Privilege-escalation-from-IIS-AppPool-to-NT-AuthoritySYSTEM-via-AD-CS-RPC-endpoint.html	mannulinux

向各位致敬 🙏

在这篇博客文章中，我将演示：当我们在一台通过 IIS Web 服务器运行、且权限为 IIS AppPool\DefaultAppPool的 Web 应用程序上获得远程代码执行（RCE）能力时，如何在不使用任何 Potato 系列提权漏洞的情况下，从 IIS AppPool\DefaultAppPool提权至 NT AUTHORITY\SYSTEM——前提是受害主机属于 Windows Active Directory 域。

概述

这项技术背后的核心洞见，源于一个已被广泛记录的 Windows 行为：当 IIS AppPool 身份访问网络级资源时，其身份会被悄然提升为宿主主机底层的机器账户（machine account）。这一行为是设计使然，我们将滥用它来获取机器账户权限。

当一个 IIS AppPool（以 IIS AppPool\DefaultAppPool运行）向 Active Directory 网络中的某个网络资源——例如 Active Directory 证书服务（AD CS）RPC 端点——发起请求时，Windows 会自动将该身份转换为运行 IIS Web 服务器的那台主机的机器账户。

这意味着，当我们从被攻陷的 IIS 服务器向 AD CS RPC/Web 注册端点提交证书签名请求（CSR）时，该请求会以机器账户的身份抵达 AD CS，而 AD CS 会欣然使用默认的 Machine 账户证书模板为其签发证书。

通过将这一身份转换与证书请求相结合，我们可以从 AD CS 获取机器账户证书，进而利用该证书获取机器账户的票据授予票据（TGT），最终在我们想要提权的主机上使用 S4U2Self 技术模拟（impersonate）管理员。让我们开始吧 🤩

攻击链 🤘😎🤘

以下是一览完整的攻击链：

在攻击者控制的 Windows 机器上生成 CSR
利用运行在被攻陷 IIS 主机上的 ASPX 代码，将 CSR 提交至 AD CS RPC 端点（以机器账户身份）
AD CS 为机器账户签发证书
在攻击者机器上将签发的证书与私钥合并，生成 PFX
使用 Rubeus 工具，借助 PFX 请求机器账户 TGT
使用机器账户 TGT 请求管理员用户的 CIFS TGS

步骤 1：在攻击者机器上生成 CSR

在攻击者机器上，运行一个自定义 PowerShell 脚本来生成 CSR 及其私钥。该脚本会将 CSR 和私钥以 base64 编码字符串的形式直接打印到控制台。

让我们在攻击者控制的 Windows 机器上运行该 PowerShell 脚本：

PS C:\Users\b0x\Desktop> .\csr_short.ps1

注意：subjectName和 altName参数并非必填，因为 AD CS 默认的 Machine 证书模板不接受用户提供的 subject 和 alternate name。

输出大致如下：

👉 将私钥输出保存到攻击者机器上的一个文件中（我们称之为 machine_cet.key），步骤 4 中会用到它。

👉 复制 base64 编码的 CSR，下一步中我们将使用被攻陷的 IIS 主机和一段 ASPX 代码把它提交给 AD CS。复制 CSR 时，请排除 -----BEGIN CERTIFICATE-----和 -----END CERTIFICATE-----这两行。

步骤 2：从被攻陷主机向 AD CS RPC 端点提交 CSR

从以下地址下载 ASPX 代码：

https://github.com/incredibleindishell/Certi-Bhai/blob/main/IIS_Privilege_escalation/cert.aspx

将该 ASPX 代码上传到被攻陷的服务器，并通过 HTTP/S 浏览，我们会看到如下界面：

CA Server Name
：在此输入框中指定 AD CS 的地址。在我的案例中，是 winbox2.queen.indishell.lab\queen-WINBOX2-CA。
Template Name
：输入默认的机器账户证书模板名称，即 Machine。
CSR Text area
：将上一步复制的 CSR（base64 编码内容）粘贴到此文本框中。

当该请求命中 AD CS RPC 端点的那一刻，Windows 就会将身份转换为 WEBSERVER$（即机器账户）。AD CS 看到的则是一个合法的机器账户在使用默认的 Machine模板请求证书，并为其签发证书 😎

步骤 3：取回已签发的证书

当我们使用 ASPX 代码提交 CSR 时，AD CS 会签发一张证书，并将其作为响应返回给提交的 CSR。

从输出中复制这张 base64 编码的已签发证书，并粘贴到攻击者机器上保存 CSR 私钥（步骤 1 中生成）的那个文件中。

在我的案例中，我将已签发的证书保存到一个文件中，并将其命名为 machine_cert.cer。请注意，内容应粘贴在 -----BEGIN CERTIFICATE-----和 -----END CERTIFICATE-----两行之间（参考上面的截图）。

步骤 4：将已签发证书与私钥合并，创建 PFX

在攻击者机器上，将已签发的证书文件和私钥文件保存到同一目录下。

要合并已签发的证书（machine_cert.cer）与私钥（machine_cert.key）来创建 PFX 文件，可使用如下的 certutil命令：

C:\b0x> certutil -MergePFX machine_cert.cer machine_cert.pfx

执行上述命令后，我们需要为 PFX 文件指定一个密码（在我的案例中是 b0x@22）。

现在，我们就拥有了一张名为 machine_cert.pfx的 PFX 证书，用于机器账户 WEBSERVER$。

步骤 5：使用 Rubeus 请求机器账户 TGT

要为机器账户 WEBSERVER$请求 TGT，可在攻击者机器上使用 Rubeus 工具，通过新建的 PFX 向 KDC 认证：

C:\b0x> Rubeus.exe asktgt /user:hostname$ /domain:domain_name /certificate:machine_cert.pfx /password:password_of_the_cert /nowrap

所请求的 TGT 将用于被攻陷 IIS 主机的机器账户。

在我的案例中，主机名为 WEBSERVER$，PFX 密码为 b0x@22，域名为 queen.indishell.lab，因此命令为：

C:\b0x> Rubeus.exe asktgt /user:WEBSERVER$ /domain:queen.indishell.lab /certificate:machine_cert.pfx /password:b0x@22 /nowrap

截图显示，使用 Rubeus 工具为机器账户 WEBSERVER$请求了一张 TGT（命令行窗口 1）。截图中的第二个命令行窗口显示，所请求的 TGT 尚未注入当前主机，但已可对目标主机 WEBSERVER$进行 SMB 访问。

步骤 6：请求 CIFS TGS 并模拟管理员

拿到机器账户 TGT 后，使用 S4U2Self 技术，在模拟默认域管理员账户的同时请求 CIFS 服务票据。我们将在攻击者机器上使用 Rubeus 工具执行此步骤。

命令语法如下：

C:\b0x> Rubeus.exe s4u /self /impersonateuser:Administrator /altservice:cifs/machine_hostname.domain_name /nowrap /ptt /ticket:base64_encoded_machine_account_TGT

在我的案例中，命令为：

C:\b0x> Rubeus.exe s4u /self /impersonateuser:Administrator /altservice:cifs/WEBSERVER.queen.indishell.lab /nowrap /ptt /ticket:base64_encoded_machine_account_TGT