IIS AppPool to SYSTEM Escalation via AD CS RPC Hits Windows Servers

What exactly is the IIS AppPool to SYSTEM escalation chain?

By abusing the AD CS RPC enrollment endpoint, a process running under a low‑privilege IIS application‑pool identity can request a machine‑account certificate, then use that certificate to forge a Kerberos TGT for the host’s computer account and finally impersonate NT AUTHORITY\SYSTEM on the target server. This technique was detailed in a recent Reddit discussion on r/netsec, highlighting a concrete path to full domain control for attackers who already have web‑server footholds.

How does the AD CS RPC endpoint enable the privilege shift?

When an IIS worker process makes an outbound RPC call to the Certificate Authority, Windows authenticates the connection using the server’s computer account (the machine’s AD object), not the application‑pool name. The CA therefore evaluates the request as coming from a trusted machine, even though the caller has no administrative rights. Researchers demonstrated that embedding a base64‑encoded Certificate Signing Request (CSR) in an ASPX page allows the IIS process to submit the request directly to the AD CS RPC service.

Because the CA trusts the machine account, it issues a certificate that contains the machine’s SID. The attacker can then extract the private key, use it to request a Kerberos Ticket‑Granting Ticket (TGT) for the same machine account, and finally employ the S4U2Self protocol to obtain a service ticket for any target service, effectively acting as SYSTEM on that host.

Why is the SeImpersonatePrivilege relevant to this attack?

The SeImpersonatePrivilege allows a process to adopt the security context of a client that connects to it. Windows grants this privilege by default to built‑in accounts such as LOCAL SERVICE and NETWORK SERVICE, which many web‑applications run under. When the IIS process receives the RPC request, it can impersonate the caller (the machine account) without needing the caller’s password, enabling the seamless transition from a low‑privileged AppPool to full SYSTEM rights.

Which environments are most at risk?

Any Windows domain‑joined server that hosts IIS and is configured to use Active Directory Certificate Services for certificate enrollment is a potential target. The risk is especially high for organizations that expose internal web applications without strict network segmentation, as the attacker only needs to control an IIS site to trigger the chain.

Large enterprises with extensive AD CS deployments, as well as smaller firms that rely on AD CS for internal TLS or code‑signing, should treat this as a critical security gap. The attack does not require a zero‑day exploit; it leverages default configurations and built‑in privileges.

What mitigation steps can administrators take right now?

Restrict RPC enrollment access. Limit the AD CS RPC endpoint to a narrow set of trusted hosts using firewall rules or AD CS enrollment permissions. Ensure that only designated certificate‑enrollment servers can communicate with the CA over RPC.

Disable unnecessary privileges. Review the SeImpersonatePrivilege assignment and remove it from service accounts that do not need to impersonate clients. Harden IIS application‑pool identities by using custom, least‑privilege accounts instead of the default ApplicationPoolIdentity.

Enforce certificate‑request authentication. Require explicit authentication for certificate requests (e.g., using HTTPS with client certificates) and disable unauthenticated web enrollment if it is not needed.

Monitor for anomalous certificate issuance. Deploy logging and alerting on AD CS to detect unexpected machine‑account certificates, especially those issued from web servers that rarely request certificates.

How can security teams detect exploitation in the wild?

Look for patterns such as:

• Unusual CSR submissions originating from IIS servers.
• New machine‑account certificates issued without a corresponding service‑account change.
• Kerberos TGT requests for computer accounts that originate from unexpected source IPs.
• Event 4624 logs showing successful impersonation of NT AUTHORITY\SYSTEM by a web‑service process.

Correlating these events with network traffic to the AD CS RPC port (typically 135/TCP) can reveal the early stages of the chain before the attacker obtains SYSTEM.

What does this mean for your organization?

The IIS‑to‑SYSTEM escalation demonstrates that trusted internal services can become inadvertent launch pads for full‑domain compromise. Organizations should audit their AD CS exposure, tighten service‑account privileges, and implement continuous monitoring of certificate issuance. By reducing the attack surface around AD CS and limiting impersonation rights, you can break the chain before an attacker reaches SYSTEM.

Frequently asked questions

Can I completely disable AD CS RPC without breaking certificate enrollment?

Yes, you can switch to HTTPS‑based enrollment (AD CS Web Enrollment) and block the RPC endpoint at the firewall. This removes the RPC attack surface while still allowing certificate requests through a more secure channel.

Do I need to patch Windows to stop this escalation?

No specific patch is required; the issue stems from default privilege assignments and service configurations. Mitigations focus on hardening permissions and restricting RPC access rather than applying a software update.

Is the SeImpersonatePrivilege always dangerous?

It is not inherently dangerous, but when granted to accounts that run network‑exposed services, it can be abused for impersonation attacks like this one. Review and limit its assignment to only those services that truly need it.

How can I test if my environment is vulnerable?

Create a low‑privilege IIS site and attempt to submit a CSR to the AD CS RPC endpoint. If a machine‑account certificate is issued, your configuration is vulnerable and requires the mitigations described.

What logging should I enable to catch this attack early?

Enable AD CS audit logging for certificate enrollment, enable Kerberos authentication event logging, and capture RPC traffic on port 135. Correlate these logs to spot unexpected certificate requests from web servers.