Port 1025 – Microsoft RPC (Microsoft Remote Procedure Call)

Port 1025 is one of the first dynamic RPC ports Windows assigns, which is why it shows up so often on older Windows hosts. It is not a fixed service — it is a slot in the Microsoft RPC (MSRPC) dynamic port range. On pre-Vista Windows (2000, XP, Server 2003) that range started at 1025, so the first RPC-based services to start — the Task Scheduler (atsvc), the Messenger service, DNS/DHCP admin, WMI, and others — landed on 1025 through 1029. The service that is actually behind 1025 is registered with the RPC Endpoint Mapper on port 135, so you never assume what 1025 is — you resolve it. IANA registers 1025/tcp under the vestigial name “blackjack” (network blackjack), but on a real Windows box that assignment is meaningless: 1025 is a dynamic MSRPC endpoint.

Why It’s Open

Windows hands out dynamic RPC ports automatically, and on legacy systems the count starts at 1025. A domain controller, Exchange server, or workstation that boots its RPC services in a fixed order tends to place them on 1025, 1026, 1027, and so on — which is why you see this port open across older Windows estates without anyone deliberately opening it. Newer Windows (Vista / Server 2008 and later) moved the default dynamic range to 49152–65535, so on a modern, patched host an open 1025 is less likely to be a core system RPC service 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 1025 you almost always find 135 next to it, and often SMB on 445 and NetBIOS on 139.

Common Risks

• It hides a real service. Port 1025 is a pointer, not a payload. The risk is whatever RPC interface Windows bound to it — the Task Scheduler, the Messenger service, a WMI or DCOM interface — each with its own attack surface. Fingerprinting 1025 is step one; the interface behind it is the target.
• Legacy DCOM/RPCSS remote code execution. On Windows 2000/XP/2003 the DCOM activation and RPCSS interfaces reachable through the endpoint mapper and the 1025–1029 dynamic ports carried the Blaster-family overflows — unauthenticated RCE as SYSTEM. These bugs are triggered via 135 plus the dynamic port (and 139/445/593), not “port 1025” in isolation.
• RPC service enumeration. Dumping the endpoint map lists every RPC interface the host has registered and the dynamic port each one uses. Combined with a null session over 445, that fingerprints the OS, tells you whether it’s a DC, and points you at the exact port to hit next.
• Lateral movement. DCOM, WMI, scheduled tasks, and service creation all ride RPC from the endpoint mapper to a dynamic port like 1025. With valid credentials that turns into a SYSTEM shell.
• 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 whichever service is listening on 1025.

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 1025 <target>

Fingerprint the RPC service actually on 1025

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

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

rpcdump.py <target>

Enumerate the interfaces reachable on 1025 directly

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

Query the endpoint mapper over SMB

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

Enumerate with Metasploit

msfconsole -q
use auxiliary/scanner/dcerpc/endpoint_mapper
set RHOSTS <target>
run

Null-session RPC enumeration

rpcclient -U '' <target>

rpcdump and rpcmap are the payload here: note which interface answers on 1025 (Task Scheduler, Messenger, WMI, a DC replication service) and the other dynamic ports the map returns, and drop that map into the pentest report so the pivot path is documented rather than lost in scrollback. Note that the old habit of running rpcinfo -p here is a mistake — 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 RPC interfaces reachable on the dynamic port, not to “port 1025” itself. Each is scoped honestly below.

• CVE-2003-0352 — The DCOM/RPC buffer overflow behind the Blaster (MSBlast/Nachi) worm, MS03-026. A malformed message to the DCOM activation interface gave unauthenticated remote code execution on Windows NT 4.0/2000/XP/2003. CVSS v2 7.5. It’s reached through the RPCSS DCOM 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-2003-0715 — The MS03-039 follow-up: a heap overflow in the same DCOM interface in the RPCSS service via a malformed DCERPC object-activation packet with modified length fields. CVSS v2 10.0, and distinct from the Blaster bug — proof the DCOM activation path was rotten in more than one place. Same port scope: DCOM activation over 135 and the dynamic ports.
• 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 one genuinely tied to the dynamic ports: the Messenger service is an RPC service whose endpoint on pre-Vista Windows commonly landed on 1026/1027 (and 1025), so it was often reachable directly on the dynamic port as well as via 135/139/445 and UDP. Public PoC: Exploit-DB 23247.
• 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 — the perimeter guidance for it centers on 135 and 445.

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 to untrusted VLANs. This is the single highest-impact fix.
• Restrict RPC to management ranges. Allow the dynamic ports only from a jump host or admin subnet with a host firewall, so an exposed 1025 shows as filtered to everyone else.
• Patch Windows. The April 2022 update closes CVE-2022-26809; the MS03-026/039/043 fixes close the legacy DCOM/RPCSS/Messenger overflows on any host old enough to still run them.
• Disable unneeded RPC services. The legacy 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.
• Prefer static-port + firewall configs. Pin critical RPC services (AD replication, DFSR, event log) to fixed ports and allow only those, or narrow the whole dynamic range, so the RPC surface is a short allowlist instead of thousands of open high ports.
• Segment and monitor. Inside AD you can’t remove RPC, so put servers behind segmentation and watch the endpoint mapper for enumeration from unexpected hosts.

Real-World Example

The clearest reason port 1025 matters is the Windows Messenger service. In the early 2000s spammers blasted net send pop-ups at the dynamic RPC ports that 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. The lesson stuck: a dynamic RPC port like 1025 is never “just an open port” — it’s a door to whatever RPC interface is behind it, and on legacy Windows that interface was often something you very much did not want exposed.

FAQ

What service runs on port 1025?

There’s no single answer — 1025 is a dynamic Microsoft RPC (MSRPC) endpoint, not a fixed service. On older Windows the dynamic range started at 1025, so the port holds whatever RPC service booted first (Task Scheduler, the Messenger service, WMI, and so on). IANA lists 1025/tcp as “blackjack,” but that registration is essentially never what you’ll find. To learn the real service, query the endpoint mapper on port 135.

Is port 1025 dangerous?

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

Why is port 1025 open on Windows?

Because Windows allocates RPC ports dynamically and the legacy default range began at 1025. The endpoint mapper handed 1025–1029 to the first services that requested an endpoint. Vista and Server 2008 moved the default range to 49152–65535, so a modern host usually shows the higher ports instead.

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

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>[1025]', or fingerprint it with nmap’s rpc-grind script. Any of these tells you which RPC interface — and therefore which attacks — sits behind the port.

Is port 1025 the same as port 135?

No. Port 135 is the RPC endpoint mapper — the directory that tells clients where services live. Port 1025 is one of the dynamic ports that directory points to. You connect to 135 to ask “where is service X?”, get back a port like 1025, then connect there. Port 1026 works the same way — it’s typically the Windows DCOM dynamic endpoint on the same host.

TL;DR

• Service: a dynamic Microsoft RPC (MSRPC) endpoint, not a fixed service (IANA name “blackjack” is vestigial)
• Default port: 1025/TCP — one of the first ports in the legacy 1025–5000 dynamic RPC range (Vista+ uses 49152–65535)
• Biggest risk: the RPC interface behind it — legacy DCOM/RPCSS/Messenger RCE (via 135 + the dynamic port) and RPC-runtime RCE (CVE-2022-26809)
• Mitigation: firewall 135 and the dynamic range externally, patch the RPC runtime, disable unneeded RPC services, and pin RPC to static ports