Port 1026 – Windows DCOM (Distributed Component Object Model)

Port 1026 is a dynamic Windows RPC/DCOM endpoint — not a fixed service, but a slot in the Microsoft RPC (MSRPC) dynamic port range that Windows hands out at boot. On pre-Vista Windows (2000, XP, Server 2003) that range started at 1025, so the RPC services that started early tended to land on 1025–1029 — and two in particular made 1026 (and its neighbour 1027) notorious: DCOM (Distributed Component Object Model) object endpoints and the Windows Messenger service. DCOM lets one machine activate and call COM objects on another, and it does that over MSRPC: the client asks the RPC Endpoint Mapper on port 135 where an interface lives, gets back a dynamic port like 1026, then connects there. So 1026 is a pointer, not a payload — you never assume what’s behind it, you resolve it on 135. IANA registers 1026/tcp as “cap” (Calendar Access Protocol, RFC 4324), but on a real Windows host that name is meaningless: 1026 is a dynamic DCOM/MSRPC endpoint.

Why It’s Open

Windows allocates RPC ports dynamically, and on legacy systems the count started at 1025, so DCOM object activations and the Messenger service frequently registered on 1026 and 1027. Where 1025 is best understood as generic dynamic RPC, 1026 earns its own page because it’s the port people historically saw carrying DCOM and the Messenger pop-up service. Newer Windows (Vista / Server 2008 and later) moved the default dynamic range to 49152–65535, so on a modern, patched host an open 1026 is less likely to be a core system DCOM interface and more likely to be a legacy machine, a pinned custom RPC listener, or a non-Windows application squatting on the port. Either way, where you find 1026 you almost always find 135 beside it, and often SMB on 445 and NetBIOS on 139.

Common Risks

• It hides a real DCOM interface. Port 1026 is a dynamic endpoint, not a fixed service. The risk is whichever COM/DCOM or RPC interface Windows bound to it — an activation interface, a WMI object, the Messenger service — each with its own attack surface. Fingerprinting 1026 is step one; the interface behind it is the target.
• DCOM lateral movement. DCOM object activation is a first-class remote-execution technique. With valid credentials, tools like Impacket’s dcomexec.py abuse exposed COM objects (MMC20.Application, ShellWindows, ShellBrowserWindow) to run commands as the logged-on user — reaching the interface through 135 and a dynamic port like 1026, not “1026” in isolation.
• Legacy Messenger service RCE. On pre-Vista Windows the Messenger service commonly bound to 1026/1027, and MS03-043 (CVE-2003-0717) made that reachable endpoint a buffer overrun for remote code execution as LocalSystem. That’s the signature 1026-era bug.
• RPC service enumeration. Dumping the endpoint map lists every RPC interface a host has registered and the dynamic port each uses. Combined with a null session over 445 it fingerprints the OS, says whether it’s a DC, and points you at the exact port to hit next — all unauthenticated.
• RPC-runtime RCE. The Windows RPC runtime itself has been remotely exploitable (CVE-2022-26809, wormable), and that flaw is reachable over any RPC endpoint — including whatever interface is listening on 1026.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service

nmap -sV -p 1026 <target>

Fingerprint the RPC service actually on 1026

nmap -p 1026 --script=rpc-grind <target>

Dump the endpoint map to see what’s bound to 1026

rpcdump.py <target>

Enumerate the interfaces reachable on 1026 directly

rpcmap.py 'ncacn_ip_tcp:<target>[1026]'

Query the endpoint mapper over SMB

nmap -p 445 --script=msrpc-enum <target>

Test DCOM lateral movement (authenticated)

dcomexec.py -object MMC20 '<domain>/<user>:<password>@<target>'

rpcdump and rpcmap are the payload for recon: note which interface answers on 1026 (a DCOM activation interface, WMI, the Messenger service) and the other dynamic ports the map returns, then drop that map into the pentest report so the pivot path is documented, not lost in scrollback. dcomexec.py is the DCOM mechanism — it activates a COM object via 135 and a dynamic port and runs your command through it. Note that rpcinfo -p does not belong here: that tool speaks Sun/ONC RPC to the portmapper on port 111, not Microsoft RPC.

What to Look For

Known CVEs and Exploits

The bugs that matter here belong to the DCOM/RPC interfaces reachable on the dynamic port, not to “port 1026” itself. Each is scoped honestly below.

• CVE-2003-0717 — MS03-043, a buffer overrun in the Windows Messenger service (NT through Server 2003) that fails to verify message length, giving remote code execution as LocalSystem. This is the bug genuinely tied to 1026: the Messenger service is an RPC service whose endpoint on pre-Vista Windows commonly landed on 1026/1027, so it was often reachable directly on the dynamic TCP port as well as via 135/139/445 and UDP. CVSS v2 7.5. Public PoC: Exploit-DB 23247 (binds a shell for LocalSystem code execution).
• CVE-2003-0352 — The DCOM/RPC buffer overflow behind the Blaster (MSBlast/Nachi) worm, MS03-026. A malformed activation message to the RPCSS DCOM interface gave unauthenticated remote code execution on Windows NT 4.0/2000/XP/2003. CVSS v2 7.5. It’s reached through the DCOM activation interface over TCP 135 and the dynamic RPC ports (1025–1029), plus 139/445/593 — the dynamic port is one of the doors, not the vulnerability. Weaponized as Metasploit’s exploit/windows/dcerpc/ms03_026_dcom.
• CVE-2022-26809 — A remote code execution flaw in the Windows RPC runtime itself, so it is reachable over any RPC endpoint — TCP 135, 445 (RPC over SMB), and the high dynamic ports. No authentication, wormable, CVSS 9.8, patched April 2022. Because it lives in the runtime rather than a specific service, the fix is patching, not guessing which port it lands on.

Note that DCOM lateral movement (the dcomexec.py MMC20/ShellWindows/ShellBrowserWindow technique) is a feature-abuse method, not a CVE — it’s the intended DCOM mechanism turned to remote execution, and it’s the reason DCOM still matters to pentesters today.

Mitigation

• Firewall 135 and the RPC dynamic range from untrusted networks. Never expose port 135 or the dynamic RPC ports (the legacy 1025–5000 range, or 49152–65535 on modern Windows) to the internet or untrusted VLANs. This is the single highest-impact fix.
• Restrict DCOM/RPC to management ranges. Allow the dynamic ports only from a jump host or admin subnet with a host firewall, so an exposed 1026 shows as filtered to everyone else.
• Patch Windows. The April 2022 update closes CVE-2022-26809; the MS03-043 and MS03-026 fixes close the legacy Messenger and DCOM/RPCSS overflows on any host old enough to still run them.
• Disable unneeded COM/DCOM and the legacy Messenger service. The Messenger service is disabled by default from Windows XP SP2 / Server 2003 SP1 onward — keep it off. Turn off DCOM/WMI remoting where nothing needs it, and enable the DCOM authentication hardening (the CVE-2021-26414 enforcement).
• Prefer static-port + firewall configs. Pin critical RPC services (AD replication, DFSR, event log) to fixed ports and allow only those, so the RPC surface is a short allowlist instead of thousands of open high ports.
• Monitor for DCOM lateral movement. Inside AD you can’t remove RPC, so segment servers and watch the endpoint mapper for enumeration and for DCOM object activations (dcomexec-style MMC20/ShellWindows launches) from unexpected hosts.

Real-World Example

The clearest reason port 1026 matters is the Windows Messenger service. In the early 2000s spammers blasted net send pop-ups at the dynamic RPC ports the Messenger service registered on — most infamously 1026 and 1027 — turning a legitimate admin-notification feature into a channel for desktop spam. Then MS03-043 (CVE-2003-0717) showed the same reachable Messenger RPC endpoint could be overflowed for remote code execution as LocalSystem, arriving right behind the Blaster wave that had already proven an unauthenticated RPC/DCOM endpoint was indefensible on the open internet. Microsoft’s response was to disable the Messenger service by default. Two decades on, DCOM is still a live concern for a different reason: object-activation abuse like dcomexec.py (MMC20.Application, ShellWindows, ShellBrowserWindow) turns legitimate DCOM into quiet lateral movement — the same 135-plus-a-dynamic-port plumbing, used for execution instead of an overflow. The lesson holds: a dynamic RPC port like 1026 is never “just an open port” — it’s a door to whatever DCOM or RPC interface is behind it.

FAQ

What service runs on port 1026?

There’s no single answer — 1026 is a dynamic Windows DCOM/MSRPC endpoint, not a fixed service. On older Windows the dynamic range started at 1025, so 1026 often held a DCOM object’s activation endpoint or the Windows Messenger service. IANA lists 1026/tcp as “cap” (Calendar Access Protocol), but that registration is essentially never what you’ll find on Windows. To learn the real service, query the endpoint mapper on port 135.

Is port 1026 dangerous?

On its own it’s just a dynamic endpoint; the danger is whatever DCOM or RPC interface is behind it. Exposed to an untrusted network it enables RPC enumeration, coercion, DCOM lateral movement with valid credentials, and — on unpatched or legacy systems — the Messenger (MS03-043) and DCOM/RPCSS (Blaster) and RPC-runtime remote-code-execution bugs below. Internally, on a patched host, it’s a normal necessary port.

What is the Windows Messenger service and why is it linked to port 1026?

The Messenger service delivered net send administrative pop-up messages. It’s an RPC service, and on pre-Vista Windows its endpoint frequently bound to the dynamic ports 1026 and 1027 — which is why those ports became synonymous with net send spam and, via MS03-043 (CVE-2003-0717), with remote code execution. It is unrelated to the later MSN/Windows Live Messenger chat client, and it’s been disabled by default since Windows XP SP2.

How is port 1026 different from port 1025 and port 135?

Port 135 is the RPC endpoint mapper — the directory that tells clients where services live. Port 1025 and port 1026 are dynamic ports that directory points to; 1025 is best treated as generic dynamic RPC, while 1026 is the one historically associated with DCOM endpoints and the Messenger service. You connect to 135 to ask “where is service X?”, get back a port like 1026, then connect there.

How do I find out what’s really on port 1026?

Resolve it, don’t guess. Dump the endpoint map with Impacket’s rpcdump.py <target>, enumerate the port’s interfaces directly with rpcmap.py 'ncacn_ip_tcp:<target>[1026]', or fingerprint it with nmap’s rpc-grind script. Any of these tells you which DCOM/RPC interface — and therefore which attacks — sits behind the port.

TL;DR

• Service: a dynamic Windows DCOM/MSRPC endpoint, not a fixed service (IANA name “cap” is vestigial; on Windows it’s DCOM or the legacy Messenger service)
• Default port: 1026/TCP — with 1027, the classic pre-Vista home of DCOM object endpoints and the Windows Messenger service (Vista+ uses 49152–65535)
• Biggest risk: the DCOM/RPC interface behind it — Messenger RCE (MS03-043 / CVE-2003-0717), legacy DCOM/RPCSS RCE (Blaster), DCOM lateral movement (dcomexec.py), and RPC-runtime RCE (CVE-2022-26809)
• Mitigation: firewall 135 and the dynamic range externally, patch Windows, disable unneeded COM/DCOM and the Messenger service, and monitor for DCOM lateral movement