The lingo
Understanding cross-session relay attacks requires a solid foundation in how Windows authentication and session management work. Concepts like Kerberoasting are often misunderstood without first grasping what a service account is, why it’s assigned a Service Principal Name (SPN), and how valid Ticket Granting Tickets (TGTs) are requested and used. The same applies to cross-session relay attacks without at least a basic understanding of Windows sessions, COM/DCOM, and the OXID resolver service, it’s easy to get lost in the details.
In this article, we’ll build up that foundational knowledge and explore how these components interact to make cross-session relay attacks possible. Let’s start with the basics.
Component Object Model COM
As an outsider to Windows development looking in (like me), your first reaction is probably: “What the fuck is that?” Well, according to Microsoft’s official documentation, it’s defined as:
The Microsoft Component Object Model (COM) defines a binary interoperability
standardfor creating reusable software libraries that interact at run time.
If that still sounds like gibberish, here’s a fun and familiar example of a COM we all use (and probably take for granted): DirectX. It’s the backbone of Windows PC gaming. Most of us just install it and forget it, but under the hood, DirectX is built on top of COM (Component Object Model) technology. It exposes a set of COM interfaces that act as an abstraction layer between software like video games and the low-level graphics drivers.
This design means game developers don’t need to worry about writing code for every individual GPU driver. Instead, they interact with DirectX’s COM interfaces, call the functions they need, and let Microsoft’s DirectX handle the hardware-specific implementations behind the scenes.
If you’re interested in the implementation details and the ABI rules involved, James Forshaw has a great talk that dives deep into all of that. But for the sake of this article, we’re going to stick to just the concepts we actually need to understand in order to visualize how the Cross-Session Relay attack works. And for that, let’s talk about the COM client-server architecture.
COM Client-Server Architecture:
In the COM (Component Object Model) client-server architecture, a client application interacts with a COM object (the server) through standardized interfaces like IUnknown, without needing to understand the object’s internal implementation. The client calls methods on these interfaces, and the COM runtime manages aspects like object creation, lifetime, and method dispatch, all using the platform’s ABI to ensure correct function calls.
To bring this into context, consider DirectX: it exposes COM interfaces that game developers use to perform graphics operations. For example, in DirectDraw, a game might request surface creation or perform blitting to render 2D graphics. These calls are made through COM interfaces like IDirectDraw, and under the hood, DirectX translates them into GPU-specific driver commands completely abstracting the hardware layer.
COM Server Types:
Before diving into DCOM, it’s important to understand that COM objects can be hosted in different ways depending on how they’re designed to run. These hosting models define where the COM object lives in relation to the client and how communication happens:
In-process server: A COM DLL that runs inside the same process as the client application. This is the most efficient model since it avoids any inter-process communication.- Example: Most DirectX components, such as
IDirect3D9orIDirectDraw, are implemented as in-process servers. When a game callsDirect3DCreate9(), it loadsd3d9.dllinto its own process space and interacts with the COM interfaces directly.
- Example: Most DirectX components, such as
Local server: A standalone EXE that runs in its own process on the same machine as the client. Communication happens via RPC or other IPC mechanisms.- Example: Microsoft Word can act as a local COM server. A separate application (like an automation script) can launch Word via COM, open documents, and control it programmatically without Word running inside the same process.
Remote server (DCOM): A COM EXE hosted on a remote machine. The client communicates with it over the network using RPC, allowing distributed object access.- Example: There’s no DirectX equivalent here, since DirectX is designed for local graphics rendering. However, WMI (Windows Management Instrumentation) is a well-known use case. A remote admin tool might query system information from another computer via WMI, which internally uses DCOM to instantiate and communicate with remote COM objects.
DCOM Activation Mechanisms
Now that we understand what COM is, how its architecture works, the different types of COM servers, and that DCOM is essentially just a COM server extended over the network, let’s dive deeper into how it actually operates. Specifically, we’ll look at how a COM client running on Machine A can discover, request, and use interfaces exposed by a COM server running on Machine B.
For two applications to communicate over a network, they must use a shared network protocol. In the case of DCOM, Microsoft chose to use Remote Procedure Call (RPC) as the underlying protocol to enable communication between COM clients and remote COM servers. Before any actual method calls can be made, the client and server must go through an authentication process to establish trust, where the Object Exporter ID (OXID), a unique identifier for a COM object instance, is resolved to facilitate remote object location. In DCOM, this happens during a phase known as DCOM Activation, where the client requests the creation of a COM object on the remote machine, and authentication is handled as part of this initial activation sequence.
During DCOM activation, the client on Machine A initiates a request via CoCreateInstanceEx, specifying the CLSID (Class ID, unique identifier for the COM class) and remote server. The COM runtime checks the registry, then contacts Machine B’s SCM (Service Control Manager) via RPC (TCP 135), authenticating the client using NTLM/Kerberos. The SCM’s OXID Resolver maps the object’s OXID to an RPC endpoint, launching the server to create the object. The interface is marshaled on the server, transmitted, and unmarshaled on the client, returning a proxy for method calls. This process ensures secure, network-transparent object activation. And of course, I didn’t just gloss over a bunch of big terms; I wanted to give them justice by thoroughly explaining them:
- OXID Resolver: A service within the SCM that resolves the Object Exporter ID (OXID) to an RPC endpoint (IP, port), enabling the client’s proxy to locate and connect to the remote object’s stub for communication.
- Marshaling/Unmarshaling: Serializes (marshals) the object’s interface pointer on the server into a network-transmissible format and deserializes (unmarshals) it on the client, allowing seamless method invocation across machines via proxy-stub RPC communication
The Attack
Ok so now that we know all of that, it’s time to dive into how the cross-session relay attack actually works. A cross-session relay attack exploits the way DCOM handles authentication and session management in Windows to relay credentials or hijack sessions across different user sessions on the same machine or network. The attacker begins by leveraging a compromised user context, a low-privilege account with access to a machine running a DCOM server. By initiating a DCOM activation request, the attacker triggers the client to authenticate to the remote server using NTLM or Kerberos credentials. The key vulnerability lies in how the OXID Resolver and SCM manage session-specific authentication tokens. If the attacker can manipulate the RPC endpoint or intercept the marshaled interface data, they can relay these credentials to another session or machine, impersonating the legitimate user. For example, an attacker might use a malicious COM client to call CoCreateInstanceEx, targeting a vulnerable DCOM server that improperly validates session boundaries. By relaying the authentication token to a higher-privilege session or a different machine, the attacker can escalate privileges or execute remote code, all while appearing as a legitimate user. This attack hinges on weak session isolation and improper DCOM server configurations, which fail to enforce strict authentication checks or validate the client’s session context. For a more visual explanation you can either check out my writeup of the Shibuya Or the image bellow:
