文章总结： 本文展示了一条从IISAppPool权限提升至SYSTEM的攻击链，利用Windows设计特性：IISAppPool访问网络资源时身份被静默提升为宿主机账户。攻击者通过构造CSR提交至ADCSRPC端点获取机器账户证书，再用Rubeus申请TGT，最后通过S4U2Self模拟管理员获取目标主机控制权。文章提供了详细攻击步骤及防御建议，包括收紧ADCS证书模板权限和监控可疑CSR请求。 综合评分： 88 文章分类： 渗透测试,红队,内网渗透,安全建设

从IIS AppPool到SYSTEM：利用AD CS RPC端点的权限提升之路

幻泉之洲

2026年9月2日 10:08 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

本文展示了一种在无需使用任何Potato漏洞的情况下，从IIS AppPool\DefaultAppPool权限提升至NT Authority\SYSTEM的攻击链。核心思路是利用Windows的一个设计特性：当IIS AppPool身份访问域内网络资源（如AD CS的RPC端点）时，其身份会被静默提升为宿主机账户。通过构造证书签名请求（CSR）并配合S4U2Self技术，攻击者最终可以管理员身份控制目标主机。

攻击前的准备

各位师傅好🙏

这篇文章要聊一个实战性很强的技巧。场景是这样的：你已经拿下一个运行在IIS上的Web应用，获得了IIS AppPool\DefaultAppPool权限的远程代码执行（RCE），而且这台机器已经加入了Windows Active Directory域。目标很明确——拿到SYSTEM权限。

通常的思路是上Potato家族的漏洞利用，但今天这条路线完全绕开Potato，走的是AD CS（Active Directory Certificate Services）的路子。

核心思路

这个技术的基石是一个被微软官方文档记录过的Windows行为：

当IIS AppPool身份访问网络级资源时，其身份会被静默提升为宿主机的基础机器账户（machine account）。

这是Windows的设计如此，不是漏洞。但设计如此不代表不能拿来搞事。我们要做的，就是利用这个”特性”拿到机器账户的权限。

具体来说：当IIS AppPool（以IIS AppPool\DefaultAppPool身份运行）向AD CS的RPC端点发起请求时，Windows会自动把这个身份翻译成宿主机账户（比如WEBSERVER$）。

这意味着什么？意味着当我们从被入侵的IIS服务器向AD CS的RPC/Web注册端点提交证书签名请求（CSR）时，请求到达AD CS时的身份已经是机器账户了。AD CS会认为这是一个合法的机器账户在用默认的Machine证书模板申请证书，然后乖乖地把证书发给它。

把这一步身份转换和证书申请结合起来，我们就能拿到机器账户的证书。然后用这个证书申请机器账户的票据授权票据（TGT），最后在目标主机上用S4U2Self技术模拟管理员身份。完美闭环。

攻击链全景

把整条链路拆开来看：

• 在攻击者控制的Windows机器上生成CSR
• 通过运行在被入侵IIS主机上的ASPX页面，以机器账户身份把CSR提交给AD CS的RPC端点
• AD CS为机器账户签发证书
• 在攻击者机器上把签发的证书和私钥合并成PFX文件
• 用Rubeus工具配合PFX申请机器账户的TGT
• 用机器账户的TGT申请管理员用户的CIFS服务票据（TGS）

第一步：在攻击者机器上生成CSR

在攻击者控制的Windows机器上，运行一个自定义的PowerShell脚本来生成CSR和对应的私钥。脚本会把CSR和私钥以base64编码的格式直接输出到控制台。

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

▲ 运行CSR生成脚本

有一点需要注意：subjectName和altName参数不是必填的，因为AD CS的默认Machine证书模板不接受用户提供的subject和altname。

运行后的输出大致长这样：

▲ 生成的CSR输出

把私钥输出保存成文件（假设叫machine_cert.key），后续第四步会用到。

▲ 保存私钥

再把base64编码的CSR复制下来，下一步要提交给AD CS。复制的时候注意把-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----这两行排除掉。

第二步：从被入侵主机提交CSR到AD CS RPC端点

从GitHub下载ASPX代码：

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

把ASPX文件上传到被入侵的服务器上，然后通过HTTP/S访问，会看到一个交互界面：

▲ cert.aspx 的交互界面

• CA Server Name：

  填写AD CS地址。在作者的测试环境中是winbox2.queen.indishell.lab\queen-WINBOX2-CA

• Template Name：

  填默认的机器账户证书模板名称，即Machine

• CSR Text area：

  把上一步复制的base64编码CSR粘贴到这个文本框中

▲ 提交CSR

请求打到AD CS RPC端点的那一刻，Windows就把身份转换成了WEBSERVER$（机器账户）。AD CS看到的是一个合法的机器账户在用默认Machine模板申请证书，于是痛快地签发了证书😎

第三步：取回签发的证书

在用ASPX代码提交CSR之后，AD CS会签发证书，并把证书作为CSR的响应返回回来。

▲ AD CS返回的签发证书

从输出中复制base64编码的签发证书，在攻击者机器上保存成文件。注意保存的位置要跟第一步的私钥文件放在一起。

▲ 保存签发的证书

作者把证书保存成了machine_cert.cer，文件内容要在-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----之间（参考上面的截图）。

第四步：合并证书和私钥生成PFX

在攻击者机器上，把签发的证书文件和私钥文件放到同一个目录下，然后用certutil命令合并生成PFX：

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

执行完上面的命令后，需要给PFX文件设置一个密码（作者用的是b0x@22）。

▲ 生成PFX文件

现在，我们有了机器账户WEBSERVER$的PFX证书，命名为machine_cert.pfx。

第五步：用Rubeus申请机器账户TGT

在攻击者机器上使用Rubeus工具，用刚生成的PFX向KDC（密钥分发中心）请求机器账户的TGT：

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

拿到的TGT就是被入侵IIS主机的机器账户的TGT。

在作者的测试环境中，主机名是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 Copy

▲ 申请机器账户TGT

看截图，第一个命令提示符完成了WEBSERVER$的TGT申请。第二个命令提示符验证了：当前主机没有注入这个TGT，通过SMB访问目标主机WEBSERVER$是通的，但还没有权限。

第六步：请求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 Copy

作者的实际命令是：

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

▲ 使用S4U2Self请求CIFS TGS

一切顺利的话，KDC会返回CIFS TGS，并且票据会被注入到当前主机（攻击者机器）中。

用下面的命令确认CIFS TGS已经成功注入：

C:\b0x> klist Copy

▲ klist输出显示CIFS TGS已注入

输出显示，[email protected]的CIFS TGS已经注入到当前的会话中。

收尾：拿下目标主机

现在我们已经有了用户[email protected]的CIFS TGS，意味着可以以管理员身份完整访问目标主机WEBSERVER$的本地文件系统🤘😎🤘

▲ 以管理员身份访问目标主机文件系统

更进一步的，还能用impacket工具包的secretsdump脚本[1]配合拿到的CIFS TGS，把目标主机WEBSERVER$的NTLM哈希全部导出来。

一些思考

这条攻击链最有趣的地方在于：完全不需要Potato，不需要任何内核漏洞，纯粹是Windows设计行为+AD CS错误配置的组合拳。关键在于AD CS默认的Machine模板允许机器账户自动注册证书，而且没有任何访问控制的限制。

防御角度来说，可以考虑：收紧AD CS的证书模板权限，机器账户不应该能随意通过RPC端点申请证书；监控IIS主机到AD CS的可疑CSR请求；对IIS AppPool的网络访问做审计。

参考资料

[1] https://github.com/fortra/impacket/blob/master/examples/secretsdump.py

[2] https://www.mannulinux.org/2026/08/Privilege-escalation-from-IIS-AppPool-to-NT-AuthoritySYSTEM-via-AD-CS-RPC-endpoint.html

免责声明：

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

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

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

本文转载自：幻泉之洲 《从IIS AppPool到SYSTEM：利用AD CS RPC端点的权限提升之路》