DEV Community: Pastukhov Aleksey

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