OXID resolution is the process Windows uses to obtain the RPC binding information needed to communicate with a COM object exporter. In this attack chain, manipulating the resolver helps redirect a privileged COM server toward an attacker-controlled endpoint.
How OXID resolution works
OXID resolution is a Windows COM plumbing step, not a security control on its own. It translates a COM object’s resolver path into the RPC binding details Windows needs to contact the object exporter.
In normal operation, that lookup is part of how COM activation reaches the correct server endpoint. The mechanism is usually invisible to users, but it is foundational to how local and remote COM components connect.
Why OXID resolution matters in COM communication
The resolution step sits between object activation and network or RPC communication. If the binding information is correct, the client reaches the intended exporter and the COM call proceeds as expected.
Because the resolver determines where the client will connect, it is a trust-sensitive part of COM communication. The security significance comes from the fact that the binding target is not just a technical detail, it is the path that decides which endpoint receives the request.
How OXID resolution can be abused
Attackers care about this step because manipulating resolution can redirect a privileged COM server toward an attacker-controlled endpoint. That makes the resolver path part of the attack surface for endpoint spoofing, relaying, or other forms of redirection abuse.
This is especially relevant where a high-value process relies on COM activation to reach a remote or higher-privilege exporter. MITRE ATT&CK Enterprise Matrix is useful for mapping the broader abuse pattern to adversary techniques such as credential access, privilege escalation, and lateral movement.
Security implications for Windows environments
OXID resolution becomes security-relevant when endpoint selection is trusted without enough validation or boundary enforcement. In that case, a malicious resolver response can influence where privileged traffic is sent, which can expand the impact of a local foothold into a more dangerous execution path.
Defenders should think about this as a trust-boundary issue in COM remoting and RPC handling. If the binding target can be influenced, then the integrity of the activation path can be undermined even when the COM object itself is legitimate.
Risk and Threat Considerations
OXID resolution can be abused when an attacker can influence the resolver outcome or intercept the binding process. The main risk is that a trusted COM client or privileged server may be redirected to an endpoint chosen by the attacker instead of the intended exporter.
Failure mechanism: The attack succeeds when binding information is accepted from an untrusted or tampered source, allowing redirection before the COM connection is established.
Impact: The result can be privilege misuse, endpoint spoofing, relay-style abuse, or a broader compromise path if a high-privilege COM interaction is steered into the wrong destination.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | OXID resolution abuse can steer COM/RPC communication into remote service paths. |
| T1557 — Adversary-in-the-Middle | Resolver manipulation can place the attacker between the client and the intended exporter. | |
| Recommendation — Map COM redirection activity to remote-service abuse and investigate unexpected privileged connections. Hunt for interception and redirection patterns where COM binding is influenced in transit. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | OXID resolution affects where privileged COM traffic is allowed to flow. |
| IA-9 — Service Identification and Authentication | COM/RPC binding depends on authenticating the service endpoint being contacted. | |
| AU-2 — Event Logging | Resolver abuse is easier to detect when COM/RPC endpoint events are logged. | |
| Recommendation — Enforce endpoint and flow restrictions so COM requests only reach approved exporters. Require strong service endpoint authentication before allowing privileged COM communications. Log COM activation and RPC binding events to spot anomalous redirection attempts. | ||
Practitioner Guidance
Why practitioners should care: Treat COM activation and RPC endpoint resolution as security-sensitive trust paths, especially on systems that host privileged services. The practical question is not whether COM works, but whether the binding target can be influenced without strong safeguards.
What to watch for: Unexpected COM redirection behavior, unusual RPC endpoints, or privileged processes contacting destinations that do not match the expected exporter pattern. Those conditions often indicate that the resolution path deserves investigation.
