ARTICLE · 1001512
从IIS AppPool到SYSTEM:利用AD CS RPC端点的权限提升之路
本文展示了一种在无需使用任何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编码的格式直接输出到控制台。
▲ 运行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：
执行完上面的命令后，需要给PFX文件设置一个密码（作者用的是b0x@22）。
▲ 生成PFX文件
现在，我们有了机器账户WEBSERVER$的PFX证书，命名为machine_cert.pfx。
第五步：用Rubeus申请机器账户TGT
在攻击者机器上使用Rubeus工具，用刚生成的PFX向KDC（密钥分发中心）请求机器账户的TGT：
拿到的TGT就是被入侵IIS主机的机器账户的TGT。
在作者的测试环境中，主机名是WEBSERVER$，PFX密码是b0x@22，域名是queen.indishell.lab，所以实际命令是：
▲ 申请机器账户TGT
看截图，第一个命令提示符完成了WEBSERVER$的TGT申请。第二个命令提示符验证了：当前主机没有注入这个TGT，通过SMB访问目标主机WEBSERVER$是通的，但还没有权限。
第六步：请求CIFS TGS并模拟管理员
拿到机器账户的TGT之后，用S4U2Self技术请求CIFS服务票据，同时模拟默认的域管理员账户。这步还是在攻击者机器上用Rubeus完成。
命令语法如下：
作者的实际命令是：
▲ 使用S4U2Self请求CIFS TGS
一切顺利的话，KDC会返回CIFS TGS，并且票据会被注入到当前主机（攻击者机器）中。
用下面的命令确认CIFS TGS已经成功注入：
▲ klist输出显示CIFS TGS已注入
输出显示，Administrator@queen.indishell.lab的CIFS TGS已经注入到当前的会话中。
收尾：拿下目标主机
现在我们已经有了用户Administrator@queen.indishell.lab的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