Forem: Pastukhov Aleksey

Reverse Engineering rpcss.dll: Hunting for the ROT's Hidden Structure

Pastukhov Aleksey — Wed, 06 May 2026 13:51:47 +0000

Part IV(?) of the "Inside the Running Object Table" series

When I started this research, I assumed finding the internal layout of the Running Object Table would be straightforward. Microsoft documents IRunningObjectTable at the API level — surely the implementation couldn't be far behind. I was wrong. What followed was a Ghidra session that turned up something far more interesting than I expected.

Where does the ROT actually live?
First surprise: there is no rpcss.exe on disk.
What Windows Task Manager shows as rpcss.exe is actually svchost.exe hosting rpcss.dll, classic service host pattern. The DLL lives at C:\Windows\System32\rpcss.dll and gets mapped into a dedicated svchost instance at boot. Every ROT operation your process makes through ole32.dll crosses an ALPC channel and lands in that DLL's code.
So that's our target.

Loading rpcss.dll into Ghidra
Standard procedure — drag, drop, let the auto-analyzer run. The interesting part comes when you load the PDB. Microsoft publishes symbol files for most system DLLs through their public symbol server, and rpcss.dll is no exception.
Grab symchk.exe from your Windows SDK Debuggers folder and run:

symchk C:\Windows\System32\rpcss.dll ^
    /s srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Point Ghidra at the downloaded PDB and suddenly FUN_18006XXXX becomes something readable. This is where it gets interesting.

First hit: CScmRotEntry
Searching the Symbol Table for ROT turns up the string u"ROTFlags" at address 180136070. One xref later, we're inside a large function. But the real find is in the Symbol Table itself:
CScmRotEntry::GetAllowAnyClient
Not CROTEntry. Not CRunningObjectTableEntry. CScmRotEntry - SCM stands for Service Control Manager. This tells us something immediately, the ROT isn't just a COM subsystem. It's wired into the service infrastructure at a deeper level than the documentation suggests.
The decompilation of GetAllowAnyClient reveals the first concrete field offset:

return *(uint *)(this + 0x68) >> 1;  // bit 1 = AllowAnyClient flag

The real structure: LookupObjectInROT
Searching for CScmRot surfaces LookupObjectInROT - a function that takes ACTIVATION_PARAMS and walks the table looking for a matching object. From here we follow the call into CScmRot::GetObject, which is where the actual traversal happens.
The decompilation reveals the first architectural surprise:

cplVar13 = *(longlong **)(*(longlong *)(lpCriticalSection + 0x48) + uVar9 * 8);

The ROT is not a linked list. It's a hash table with 251 buckets (0xFB).
Each bucket is a pointer to a chain of CScmRotEntry objects. The hash function is a simple rolling hash over the moniker bytes:
chash = ((hash * 3) ^ byte) % 0xFB;
Aint cryptographic n complex. Fast and collision-tolerant for the expected workload of a few dozen registered objects.

Digging deeper: the class hierarchy
Listing all symbols with the CScmRot prefix turns up the full method table:

CScmRot::EnumRunning
CScmRot::GetEntryFromScmReg
CScmRot::GetTimeOfLastChange
CScmRot::IsRunning
CScmRot::Register
CScmRot::Revoke
CScmRotEntry::CScmRotEntry
CScmRotEntry::GetProcessID
CScmRotEntry::IsValid

Two things stand out. First, CScmRotEntry::CScmRotEntry it's a constructor, meaning this is a proper class with its own lifecycle. Second, CScmRotEntry::GetProcessID -every ROT entry stores the PID of the registering process. That field doesn't appear anywhere in the public API documentation.
Opening the constructor reveals something else entirely: CScmRotEntry is not a flat structure. It inherits from a base class:

CScmRotEntry
    └── CScmRotMgotEntryBase

"Mgot" itsa likely Marshaled Global Object Table. The base class constructor initializes most of the core fields:

CScmRotMgotEntryBase::CScmRotMgotEntryBase(
    CScmRotMgotEntryBase *this,
    ulong param_1, ulong param_2,
    _MnkEqBuf *param_3,
    CToken *param_4,
    ushort *param_5,
    tagInterfaceData *param_6,
    bool param_7,
    ulong param_8)
{
    *(undefined8 *)(this + 0x08) = 0;       // pNext = NULL
    *(undefined4 *)(this + 0x10) = 1;       // ref count = 1
    *(tagInterfaceData **)(this + 0x18) = param_6;
    *(ushort **)(this + 0x30) = param_5;    // display name
    this[0x40] = ... | param_7;             // flags
    *(_MnkEqBuf **)(this + 0x20) = param_3; // moniker eq buffer
    *(CToken **)(this + 0x28) = param_4;    // integrity token
    if (param_4 != NULL) {
        LOCK();
        *(int *)(param_4 + 8) += 1;         // manual AddRef
        UNLOCK();
    }
}

And CScmRotEntry adds its own fields on top:

*(ulong *)(this + 0x50) = 0x746f7263;   // magic: "crot"
*(ulong *)(this + 0x54) = param_5;
*(_FILETIME *)(this + 0x58) = *param_4; // last change time
*(tagInterfaceData **)(this + 0x60) = param_12;
*(ulong *)(this + 0x68) = param_7;      // ROTFlags

The complete structure map is being combining both constructors gives us the full layout:

struct CScmRotMgotEntryBase {
    void            *vtable;       // +0x00
    longlong         pNext;        // +0x08  next in bucket chain
    DWORD            dwRefCount;   // +0x10  starts at 1
    tagInterfaceData *pIFaceData;  // +0x18  marshaled interface
    _MnkEqBuf       *pMnkEqBuf;   // +0x20  moniker comparison buffer
    CToken          *pToken;       // +0x28  integrity level token
    ushort          *pwszName;     // +0x30  display name (wide string)
    longlong         unk_0x38;     // +0x38
    BYTE             bFlags;       // +0x40  bit 0 = various flags
    DWORD            dwField_44;   // +0x44
    DWORD            dwField_48;   // +0x48
    DWORD            dwField_4c;   // +0x4c
};
// Derived class
struct CScmRotEntry : CScmRotMgotEntryBase {
    DWORD            dwMagic;      // +0x50  0x746F7263 = "crot"
    DWORD            dwField_54;   // +0x54
    _FILETIME        ftLastChange; // +0x58  registration timestamp
    tagInterfaceData *pIFaceData2; // +0x60  second interface data
    DWORD            dwROTFlags;   // +0x68  bit 1 = AllowAnyClient
};

Three findings worth highlighting
The "crot" magic signature at +0x50. Every valid CScmRotEntry in memory carries the ASCII bytes c, r, o, t at this offset. This is almost certainly what CScmRotEntry::IsValid checks. For a memory scanner, this is a gift: you can locate entries by signature without knowing the head of the hash table.
CToken uses manual reference counting. The increment at param_4 + 8 is wrapped in LOCK/UNLOCK - interlocked, not COM AddRef. This means tokens are shared across multiple ROT entries from the same process using a private refcount mechanism entirely separate from COM lifetime management.
pwszName at +0x30 is the display name. This is the wide string you'd normally get from IMoniker::GetDisplayName. Reading it directly means a memory scanner doesn't need to deserialize tagInterfaceData or call any COM API to get human-readable moniker names — the string is right there in the entry.

The security picture
Walking CScmRot::GetObject surfaces three distinct access control mechanisms operating in sequence:

cRotEntryIsTrusted(plVar11, token)
RotMgotEntryIsAccessible(plVar11, token, ...)
CToken::IsTokenILLower(plVar11[5], plVar13[5], ...)

Trust check, accessibility check, integrity level comparison in that order. When multiple entries match the same moniker, the one with the higher integrity level wins. A sandboxed process cannot shadow a medium-integrity registration. AppContainer entries get discarded entirely for out-of-container clients — we even found the log string in the code:
"Disregarding ROT entry registered by AppContainer"
The ROT has a real access control model. It's just not documented anywhere near as clearly as the public API suggests.

Code and tooling: github.com/ssteelfactor-oss

[to be continued...]

KESTREL: AD enumeration that doesn't announce itself

Pastukhov Aleksey — Tue, 05 May 2026 15:25:37 +0000

The tooling problem is embarrassing
Everyone in AD security uses BloodHound. It's good at what it does, attack paths, delegation chains, ACL edges. No complaints there.
The problem is the how.
SharpHound is a .NET assembly. It floods your network with LDAP traffic patterns that zero legitimate workstations produce. EDR picks it up immediately, not because it's exploiting anything exotic, but because the behavioral signature is basically a neon sign. ADRecon, PowerView, Python alternatives, it's the same story. The runtime is the fingerprint.
Internal red teams and defenders are stuck in a ridiculous spot: you need to enumerate your own domain to find misconfigs before attackers do, but every tool available screams its presence. Unacceptable.
The solution was already there. Since Windows 2000.
Active Directory Service Interfaces, that is it. COM-based LDAP abstraction that Windows itself uses constantly. Group Policy uses it. MMC snap-ins use it. net user /domain uses it.
The traffic it produces is indistinguishable from normal domain activity. Because it is normal domain activity.
That's Kestrel's entire foundation.
It is just native, pure C. No managed runtime. No wrappers.
Direct COM vtable calls. No .NET. No PowerShell. No abstractions between you and the wire:

cIDirectorySearch *pSearch = NULL;
ADsGetObject(ldapPath, &IID_IDirectorySearch, (void **)&pSearch);
ADS_SEARCHPREF_INFO prefs[2];
prefs[0].dwSearchPref = ADS_SEARCHPREF_SEARCH_SCOPE;
prefs[0].vValue.Integer = ADS_SCOPE_SUBTREE;
prefs[1].dwSearchPref = ADS_SEARCHPREF_PAGESIZE;
prefs[1].vValue.Integer = 200;
pSearch->lpVtbl->SetSearchPreference(pSearch, prefs, 2);
pSearch->lpVtbl->ExecuteSearch(pSearch, filter, attrs, count, &hSearch);

From the wire's perspective: authenticated LDAP bind, paged search requests. What every DC sees from every domain workstation, every minute, every day. You're invisible by default.
v0.1 = just five passive modules
ADWS Endpoint Detection^ raw TCP connect to port 9389 per DC. One SYN. No WCF handshake, no ADWS framing. Just: is this port open, yes or no.
Computer Topology - full computer inventory, SPN decoding through a service-class table. MSSQLSvc → SQL Server, WSMAN → WinRM, TERMSRV → RDP. One LDAP query. Zero packets to target hosts.
Delegation Risks: actually separates the three categories most tools conflate:

Unconstrained (TRUSTED_FOR_DELEGATION on non-DC objects) - Kerberos ticket arrives with forwarded TGT. Serious.
Constrained (msDS-AllowedToDelegateTo) - exact target SPNs enumerated.
Protocol Transition / S4U2Self (UAC & 0x1000000) -- service gets a ticket for any domain user without their credentials. Different risk profile, reported separately. Most tools miss this distinction entirely.

LAPS Coverage detects both legacy LAPS (ms-Mcs-AdmPwdExpirationTime) and Windows LAPS 2023+ (msLAPS-EncryptedPasswordHistory). Splits computers into managed/unmanaged with percentage breakdown. You will know exactly how exposed your local admin situation is.
Stale Computers uses lastLogonTimestamp as primary reference. It replicates across DCs, unlike lastLogon which is per-DC only. Both values reported side by side.
Engineering discipline matters
Two things enforced that most open-source Windows tooling just ignores:
SAL 2.0 annotations on every function signature. Not for decoration it's PREfast (/analyze) validates them at compile time. Must_inspect_result on HRESULT-returning functions, Outptr vs Out where semantics differ. Contract violations caught before the code ever runs.
Single rootDSE resolution: defaultNamingContext read once at startup, passed as parameter to all five scan functions. The naive approach binds rootDSE in each module separately. That's five redundant DC round-trips for data that doesn't change mid-scan. Obviously wrong. Fixed.
Roadmap
v0.1 is the foundation. Here's what's coming:
v0.2 == raw SECURITY_DESCRIPTOR parsing via IDirectoryObject::GetObjectAttributes. Extended Rights GUID→name mapping built dynamically from CN=Extended-Rights,CN=Configuration. Full ACL edges on every AD object, no elevated privileges required.
v0.3 == transitive group membership via LDAP_MATCHING_RULE_IN_CHAIN (OID 1.2.840.113556.1.4.1941). One query, full recursive chain. Zero client-side BFS.
v0.4 == in-memory graph from ACL + membership + delegation data. JSON export for visualization.
v0.5 == BFS path finder across the graph. Attack path analysis from any principal to Domain Admins. Shortest privilege escalation route, computed natively.

What the point is: everything SharpHound does in managed code can be reproduced through interfaces Windows already exposes natively. Quietly. Without a detectable runtime. With full static analysis at build time.
This should have existed years ago.
→ Kestrel
Parent project: NetEnum

NetEnum: legitimate API scanning tool

Pastukhov Aleksey — Sun, 19 Apr 2026 12:47:39 +0000

NetEnum is a compact, purpose-built network and service enumeration tool, written in plain C, focused on one core idea: collecting intelligence through “legitimate” APIs and standard system interfaces rather than noisy, signature-heavy probing. That design choice makes it especially useful in environments where you need reliable discovery while keeping activity indistinguishable from normal administrative telemetry—a practical advantage when EDR, IDS, and other detection layers are tuned to flag aggressive scanners.

What NetEnum is (and what it is not)

Unlike classic scanners that spray packets, brute-force banners, or rely on exploit-style fingerprinting, NetEnum is intended to enumerate using the same mechanisms that real enterprise tooling uses: vendor-supported endpoints, OS-provided management interfaces, and other approved channels. In other words, it aims to behave like routine operations—inventory, auditing, compliance checks—rather than “attack-like” reconnaissance.

This makes NetEnum a good fit for:

internal asset inventory and continuous discovery,
lab validation of monitoring baselines,
security assessments where you want realistic operator behavior,
blue team exercises that measure what can be learned from sanctioned interfaces alone.

Why “legitimate API scanning” matters

Modern corporate networks are full of valuable signals exposed through APIs: identity systems, management planes, cloud services, directory services, configuration endpoints, and monitoring stacks. Those systems exist specifically so administrators and automation can query them safely.

NetEnum’s philosophy is simple:

Prefer official read paths (documented endpoints, authenticated queries, normal tooling behaviors).
Minimize noisy traffic patterns (avoid broad port blasting when high-confidence information is already available via an API).
Reduce anomalous fingerprints (keep requests close to typical management and inventory workflows).

Lower visibility to EDR / IDS (in the practical sense)

EDR and IDS commonly trigger on patterns associated with classic scanning:

high-rate connection attempts across many ports/hosts,
unusual protocols or malformed probes,
repeated banner grabs,
tool-specific packet signatures.

When enumeration is performed through standard API calls and normal management interfaces, the observable footprint is often closer to:

legitimate admin scripts,
IT automation,
health checks and inventory tasks.

That doesn’t mean “undetectable”—good monitoring can still catch unusual authentication patterns, abnormal query volumes, or access outside an expected role. But it does mean NetEnum is designed to avoid the obvious scanner-shaped telemetry that many detection stacks prioritize.

Built for controlled, responsible use

NetEnum is best used where you have permission and clear scope: your own infrastructure, sanctioned assessments, or test environments. The “legitimate API” approach is powerful precisely because it leverages trusted interfaces—so it should be paired with proper governance, logging, and access control. Used correctly, it becomes a high-signal inventory and visibility tool that complements (rather than replaces) traditional network scanning.

Summary

If your goal is to understand an environment with less noise and fewer detection spikes, NetEnum is built around a modern enumeration strategy: learn as much as possible from the same APIs and management planes that enterprises already rely on. That yields actionable discovery while keeping collection closer to normal operational behavior—an advantage in networks where EDR/IDS is sensitive to classic recon patterns.

If you want, paste your README (or tell me the key features/modules you want highlighted), and I’ll tailor the post to match NetEnum’s exact capabilities and include a short “How it works” section without revealing anything unsafe.

Link to: https://github.com/ssteelfactor-oss/NetEnum

Part 3: putting it al l together

Pastukhov Aleksey — Mon, 13 Apr 2026 17:24:59 +0000

#include <windows.h>
#include <objbase.h>
#include <stdio.h>

int main(int argc, char * argv[]) {
    CoInitializeEx(0, COINIT_APARTMENTTHREADED);

    IRunningObjectTable *pROT  = 0;
    IEnumMoniker        *pEnum = 0;
    IBindCtx            *pCtx  = 0;
    IMoniker *pMon   = 0;
    ULONG     fetched = 0;

    GetRunningObjectTable(0, &pROT);
    pROT->lpVtbl->EnumRunning(pROT, &pEnum);
    CreateBindCtx(0, &pCtx);

    while (pEnum->lpVtbl->Next(pEnum, 1, &pMon, &fetched) == S_OK) {
        LPOLESTR name = NULL;
        if (SUCCEEDED(pMon->lpVtbl->GetDisplayName(pMon, pCtx, 0, &name))) {
            wprintf(L"%s\n", name);
            CoTaskMemFree(name);
        }
        pMon->lpVtbl->Release(pMon);
    }

    pCtx->lpVtbl->Release(pCtx);
    pEnum->lpVtbl->Release(pEnum);
    pROT->lpVtbl->Release(pROT);
    CoUninitialize();
    return 0;
}

Compile with:

cl rot_enum.c ole32.lib

What you'll actually see - on my comp the output looks like:

Part 2: How It Works Under the Hood

Pastukhov Aleksey — Sun, 12 Apr 2026 12:16:14 +0000

Before diggin into, it's useful to consider a question that most COM tutorials never address: where does the Running Object Table actually reside?
The ROT isnt a data structure inside the calling process, nor is it a kernel object.

It exists as a global, session-scoped table inside rpcss.exe, the RPC Subsystem process, and is shared by all processes running in the same Windows session.
When code calls GetRunningObjectTable() func, it does not receive a direct pointer to the table. Instead, it receives a proxy object that implements the IRunningObjectTable interface. Every method invoked on this proxy is marshaled across a local RPC channel (ALPC) to rpcss.exe. The actual mapping of monikers to live objects never leaves that system process.

As a result, every ROT operation: Register, Revoke, IsRunning, GetObject, etc is an inter-process call. The overhead is insignificant for occasional use, but it must be taken into account when these functions are invoked inside tight loops or performance-critical code.

The API chain
The full enumeration path will be looks like this:

GetRunningObjectTable()
    └── IRunningObjectTable::EnumRunning()
            └── IEnumMoniker::Next()
                    └── IMoniker::GetDisplayName()

Step 1: Get a handle to the ROT

HRESULT hr = 0;
IRunningObjectTable *pROT = 0;
hr = GetRunningObjectTable(0, &pROT);

Entry point - GetRunningObjectTable(). 1-argument is reserved and must be zero. On success it gives you IRunningObjectTable, proxy to rpcss.exe. Always check SUCCEEDED(hr) before proceeding; if the RPC channel to rpcss is broken, it fails.

Step 2: Get an enumerator

IEnumMoniker *pEnum = 0;
hr = pROT->lpVtbl->EnumRunning(pROT, &pEnum);

EnumRunning() returns IEnumMoniker, a standard COM enumerator over the monikers currently registered in the table.
This is a snapshot: entries registered after this call won't appear, entries revoked before you iterate won't be missing from the snapshot either - enumerator captures state at the moment of the call.

Step 3: Iterate

IMoniker *pMon = 0;
ULONG fetched = 0;

while (pEnum->lpVtbl->Next(pEnum, 1, &pMon, &fetched) == S_OK) {
    // process pMon
    pMon->lpVtbl->Release(pMon);
}

Next() func follows the standard COM enumerator contract: request items, get back how many were actually returned.
Ask for one at a time it's simpler error handlingn.

Step 4: Decode the moniker

IBindCtx *pCtx = 0;
CreateBindCtx(0, &pCtx);

LPOLESTR displayName = 0;
pMon->lpVtbl->GetDisplayName(pMon, pCtx, NULL, &displayName);

wprintf(L"%s\n", displayName);
CoTaskMemFree(displayName);

GetDisplayName() requires a bind context. IBindCtx- even though we're only reading a name, not actually binding. The bind context carries parameters that affect how monikers resolve; for display purposes we pass a default one via CreateBindCtx(0, ...).
Don't forget to free memory with callong CoTaskMemFree().

To be continued

Inside the Running Object Table: COM's Hidden Registry of Live Objects

Pastukhov Aleksey — Sun, 12 Apr 2026 11:20:02 +0000

Inside the Running Object Table: COM's Hidden Registry of Live Objects

*Introduction: Running Object Table, part I *

"...almost no developer ever looks at directly", by me.

COM is a technology that many developers believe they understand until they encounter its less-documented internals. Most are familiar with the core concepts — interfaces, CoCreateInstance, and reference counting — yet the Component Object Model contains considerably more supporting infrastructure than its public API reveals. One of the least examined parts of this infrastructure is the Running Object Table, commonly abbreviated as ROT.

The ROT is a system-wide registry that holds references to live COM objects. It does not store class information or factory objects; it contains only instantiated objects that have been explicitly registered as running and available for external access. In essence, it serves as the mechanism by which a COM server can declare that a particular object is active and can be located by name. A client that needs to connect to an already-running instance checks the ROT before creating a new object.

This component plays a more important role than is commonly recognized. The ROT is the underlying mechanism used by GetObject() in VBScript, it enables Visual Studio to expose its automation model to external scripts, and it supports certain inter-process communication patterns in Windows without the need for explicit sockets or named pipes. At the same time, the ROT is an area that is frequently misunderstood and can be misused.
Currently registered on a live Windows system, decoding of the monikers they expose, and analysis of what these findings indicate about the runtime behavior of COM.
In C, without ATL, without MFC, without training wheels. Just enumerate what's actually registered on a live Windows system, decode the monikers i find, and talk about what the results reveal about COM's runtime model.

To be continued