拿到一个IIS服务器的远程代码执行权限，身份却只是IIS AppPool\DefaultAppPool，离NT Authority\SYSTEM还差着十万八千里。常规思路是翻找土豆系列漏洞，但这次的路子完全绕开了它们。
关键在于Windows一个设计层面的行为：当IIS应用池身份去访问网络级资源时，这个身份会被悄悄提升为宿主机的机器账户。也就是说，你手里的低权限账户，在特定网络请求中会自动“变身”。
身份切换的底层逻辑
IIS应用池默认以IIS AppPool\DefaultAppPool运行，这个账户本身权限很低。但当它向Active Directory网络中的资源发起请求时，Windows会自动把身份翻译成IIS服务器所在主机的机器账户。
比如请求目标是Active Directory证书服务（AD CS）的RPC端点，请求到达AD CS时，对方看到的就不是应用池账户，而是机器账户。这个切换是静默发生的，不需要额外漏洞触发。
从证书到域管权限的完整链条
攻击者从被攻破的IIS服务器向AD CS的RPC或Web注册端点提交一个证书签名请求（CSR）。由于身份已经被切换成机器账户，AD CS会按照默认的机器账户证书模板，高高兴兴地给这个请求签发一张机器账户证书。
拿到这张证书后，就可以用它去申请机器账户的票据授予票据（TGT）。有了TGT，再配合S4U2Self技术，就能在目标主机上模拟管理员身份，完成从应用池账户到SYSTEM的权限提升。
攻击链路的三个关键节点
- 利用IIS应用池访问网络资源时的身份自动提升，让请求以机器账户身份到达AD CS。
- 向AD CS提交CSR，获取默认机器账户模板签发的证书。
- 用证书换取机器账户TGT，再通过S4U2Self模拟管理员，拿下SYSTEM权限。
整条链路不需要任何土豆漏洞，完全依赖Windows和AD CS的既有行为。对于加入了Active Directory域的IIS服务器，这条路径的隐蔽性和可行性都相当高。
为什么这个技巧值得关注
很多防守方会把注意力放在应用池账户本身的权限隔离上，认为低权限账户翻不起大浪。但这个技巧恰恰利用了“网络请求身份切换”这个容易被忽略的细节，让低权限账户在特定场景下获得机器账户的完整能力。
对于红队来说，多了一条不依赖已知漏洞的提权路线；对于蓝队来说，则需要重新审视IIS服务器与AD CS之间的信任关系，以及机器账户证书的签发策略。
热门跟贴