Escalating to Domain Admin via DCOM and AD CS Misconfigurations

TLDR: This research details a novel privilege escalation path from a standard domain user to Domain Admin by abusing DCOM and Active Directory Certificate Services (AD CS). By leveraging the CoGetInstanceFromIStorage API, attackers can trigger remote COM object activation to perform NTLM or Kerberos relay attacks. Defenders must enable Extended Protection for Authentication (EPA) on AD CS endpoints and audit DCOM security configurations to prevent this escalation.

Active Directory environments are rarely as hardened as they appear on paper. While most organizations focus on patching critical vulnerabilities, they often overlook the complex, legacy interdependencies that define Windows communication. The recent research presented at Black Hat 2024 regarding DCOM and AD CS is a perfect example of how an attacker can chain seemingly benign permissions into a full domain compromise.

The Mechanics of the DCOM Attack Surface

At the core of this technique is the Component Object Model (COM) and its distributed counterpart, DCOM. COM is the backbone of Windows inter-process communication, and DCOM extends this capability across the network. When a client requests a COM object, it communicates with the Remote Procedure Call (RPC) service on the target machine. If the target is a remote server, the process is known as DCOM.

The research focuses on the CoGetInstanceFromIStorage API. Unlike standard object creation methods, this API accepts an IStorage interface pointer, which allows for more granular control over how the object is initialized. An attacker can use this to force a high-privilege COM server to authenticate against an attacker-controlled machine. Because the DCOM protocol relies on RPC, it is susceptible to relay attacks if the authentication level is not strictly enforced.

Chaining DCOM to AD CS

The real power of this research lies in its application to Active Directory Certificate Services. AD CS is a frequent target in modern red team engagements because it is often misconfigured or over-privileged. The researchers identified that the AD CS service, specifically the Certificate Enrollment Web Service, uses DCOM protocols like MS-WCCE to handle certificate requests.

By default, the security descriptors for these DCOM interfaces are often too permissive. If a domain user has the ability to trigger a DCOM activation on an AD CS server, they can force the server to initiate an NTLM or Kerberos authentication request to an attacker-controlled listener. Once the attacker captures this authentication, they can relay it to other services or use it to request a certificate on behalf of a high-privilege account.

The specific vulnerability tracked as CVE-2022-37976 highlights the danger of these default configurations. The patch for this CVE raised the required authentication level to RPC_C_AUTHN_LEVEL_PKT_PRIVACY, effectively forcing encryption and integrity checks that break simple relay attempts. However, the underlying issue remains: if your DCOM security settings are not hardened, you are leaving the door open for forced authentication.

Practical Exploitation in the Field

During a penetration test, you should look for servers running the AD CS role. Use tools like Impacket to enumerate DCOM interfaces and check the security descriptors. If you find that the Authenticated Users group or a broad group like Domain Users has Remote Launch or Remote Activation permissions on critical DCOM objects, you have a viable path for exploitation.

The attack flow typically looks like this:

1. Identify an AD CS server with weak DCOM permissions.
2. Use a tool to trigger CoGetInstanceFromIStorage against the target.
3. Set up an NTLM relay listener to capture the incoming authentication.
4. Relay the authentication to the AD CS web enrollment interface or an LDAP service to perform an RBCD or ShadowCredentials attack.
5. Request a certificate for a Domain Admin account and use it to obtain a Kerberos Ticket Granting Ticket (TGT).

This is not a theoretical exercise. In environments where AD CS is integrated with web-based enrollment, the attack surface is exposed to any machine joined to the domain. If you can reach the RPC port on the AD CS server, you can potentially escalate your privileges.

Hardening Your Environment

Defenders need to move beyond simple patching. While CVE-2022-37976 is a necessary fix, it does not address the fundamental issue of over-privileged DCOM configurations.

First, enable Extended Protection for Authentication (EPA) on all AD CS HTTP endpoints. This prevents NTLM relaying by binding the authentication to the TLS channel. Second, audit your DCOM security settings using the Component Services management console. Ensure that only necessary accounts have Remote Launch and Remote Activation permissions. If a service account does not need to interact with DCOM, remove its permissions entirely.

Finally, enforce LDAP Signing and Channel Binding across your domain. This is a standard best practice that mitigates a wide range of relay attacks, not just those involving DCOM.

The path to Domain Admin is often paved with legacy protocols that were never designed for the modern, interconnected enterprise. By understanding how DCOM interacts with services like AD CS, you can identify these hidden paths before an attacker does. Stop treating DCOM as a black box and start auditing it with the same rigor you apply to your web applications.