IIS-to-SYSTEM escalation chain abuses AD CS machine certificates

An attacker with remote code execution in an IIS-hosted web application can use a Windows identity behavior to seek administrator-level access on a domain-joined server. The technique starts with IIS AppPool\\DefaultAppPool and ends with a Kerberos service ticket that can provide access to the server's file system.

The chain relies on Active Directory Certificate Services (AD CS), the Windows certificate authority role. Microsoft documents AD CS in its official overview, while Microsoft’s IIS application pool identity guidance explains the virtual-account model behind the attack.

Windows turns the application pool into a machine account

IIS can run an application pool under a virtual identity such as IIS AppPool\\DefaultAppPool. The identity limits access to the local operating system, yet Windows handles network authentication from that account in a special way.

When the application pool contacts a network resource, Windows presents the request as the computer account of the IIS host. A server named WEBSERVER therefore reaches a domain service as WEBSERVER$.

That identity change gives an attacker a path into domain services from a web process that lacks local administrator rights. The web application still needs a route to the AD CS service, and the domain must accept the requested certificate template.

The attack chain

The technique follows six stages:

1. The attacker creates a certificate signing request and keeps the matching private key.
2. The attacker submits the request through code running inside the compromised IIS application.
3. AD CS receives the request as the IIS host's machine account.
4. The attacker combines the returned certificate with the private key in a PFX file.
5. The attacker uses Rubeus to request a Kerberos ticket-granting ticket for the machine account.
6. The attacker uses Kerberos service-ticket operations to request access to the server's CIFS service under an administrator identity.

The process separates certificate creation from certificate enrollment. The attacker creates the key pair on a controlled Windows system, while the compromised IIS server submits the certificate request. The private key never needs to reside on the web server.

AD CS supplies the credential

The vulnerable path depends on a certificate authority that permits the machine account to enroll in a machine certificate template. The request can use a standard machine template, such as Machine, when that template accepts the host account and includes the settings required for domain authentication.

The attacker places the base64-encoded certificate signing request into an ASPX page or another web-accessible component that can call the AD CS RPC endpoint. The page sends the request from the IIS process. Windows authenticates the network connection with the server's computer account, and the certificate authority evaluates that account rather than the low-privilege application-pool name.

A related proof-of-concept implementation appears in the Certi-Bhai repository. Organizations should treat code that submits certificate requests from a web process as a high-risk capability.

AD CS returns the signed certificate after it approves the request. The attacker pairs that certificate with the private key from the original request and creates a PFX bundle. The bundle becomes a portable credential for the machine account.

Kerberos extends the machine identity

The attacker can present the PFX to a domain controller through Rubeus and request a TGT for WEBSERVER$. This step converts certificate enrollment into Kerberos credentials for the compromised host's computer account.

A machine-account TGT can carry more authority than the original IIS process. The attacker can use Kerberos service-for-user operations to request a CIFS ticket for the target server while presenting an administrator identity. On configurations that permit the required delegation path and local rights, the ticket can provide access to administrative SMB resources.

That access can expose sensitive files, registry data and credential material. Tools such as Impacket can use Kerberos tickets for remote administration and credential extraction, subject to the permissions available on the target host.

Why defenders should care

The chain joins three controls that teams often manage apart: IIS application identities, AD CS enrollment and Kerberos authentication. A web process may appear isolated from the domain, yet Windows can give its outbound network requests the authority of the host computer account.

AD CS then turns that account into a certificate. Kerberos turns the certificate into a TGT. Each system performs an expected operation, but the combined result can cross the boundary from web application compromise to operating-system compromise.

The technique requires conditions that defenders can audit. The server must belong to an Active Directory domain, the IIS process must reach the certificate authority, the certificate template must permit enrollment, and the resulting certificate must support domain authentication. The S4U step requires additional account and service conditions.

Defensive checks

Administrators should review certificate templates that allow machine-account enrollment. Check enrollment permissions, extended key usages, issuance requirements and subject-name controls. Remove unnecessary enrollment rights and restrict certificate templates to the accounts and services that need them.

Network controls should limit access from web servers to AD CS RPC and web-enrollment services. Application pools should run with the smallest practical permissions, and web servers should not expose unnecessary outbound paths into domain infrastructure.

Certificate-authority logs can show suspicious activity. Windows event IDs 4886 and 4887 record certificate requests and issuance. Domain-controller events 4768 and 4769 can reveal a new TGT or service-ticket pattern for a machine account, especially when the request follows web-server activity or targets administrative SMB services.

After a suspected compromise, revoke certificates issued to the machine account, remove stored PFX files and private keys, reset the computer account password, review the IIS application for persistence and rotate credentials reachable from the server. Investigators should preserve certificate-authority, IIS, Windows authentication and endpoint telemetry before remediation changes the evidence.

The technique demonstrates a broader security lesson: identity boundaries depend on the behavior of the systems around them. An application pool can hold little local authority while its network identity grants access to a domain certificate authority. Security teams need to audit that entire path when they assess the impact of web-server code execution.