Port 49666 – MSRPC (Windows Dynamic RPC Endpoint)

Port 49666 is not a fixed service — it sits deep inside the Windows ephemeral/dynamic range (49152–65535), and that single fact explains everything you will find on it. When an RPC-based Windows service starts, it asks the operating system for any free high port instead of binding a fixed one, and 49666 is simply one of the numbers the OS hands out. So an open 49666 is almost always a dynamic Microsoft RPC (MSRPC) endpoint: some svchost-hosted service — the Task Scheduler (MS-TSCH), the Event Log (MS-EVEN), Netlogon (MS-NRPC), the DHCP Server, or a DCOM application — that registered itself with the RPC Endpoint Mapper on port 135 and was assigned this port at boot. The number itself tells you nothing; the whole job on 49666 is to map it back through 135 and find out which interface actually answers, then test that. Because the assignment is not deterministic, the service on 49666 can differ from one reboot — or one host — to the next, which is exactly why you never attack “port 49666,” you attack the interface behind it.

Why It’s Open

The dominant reason 49666 is open is Windows dynamic RPC. Microsoft’s RPC subsystem lets a service register an interface and then bind to a runtime-assigned TCP/UDP port from the top of the ephemeral range rather than a well-known one. Clients never guess that port — they connect to the Endpoint Mapper on 135, ask “where is interface UUID X right now?”, and are told the current dynamic port. That is why 135 and a cluster of 4966x/4967x ports almost always appear together on a Windows box, and why enumerating 49666 always routes back through 135.

Which service lands on 49666 depends entirely on start order. On a typical Windows host it could be:

• Task Scheduler (MS-TSCH) or the Event Log collector (MS-EVEN),
• Netlogon (MS-NRPC) on a domain controller,
• the DHCP Server or DNS Server management interfaces,
• WMI/DCOM activation, or a third-party service that speaks DCE/RPC.

Neighbouring dynamic ports such as 49152 — the very first slot in the range — usually host other RPC interfaces on the same machine, so a scan that lights up 135 plus a run of high ports is the normal Windows RPC footprint, not an anomaly. Because RPC services can bind UDP as well as TCP, a thorough check scans both protocols.

Not to be confused with port 17001. A legacy stub once shared the “alt-service / alternative-service” label with 49666, but port 17001 sits below the Windows dynamic range and is a different, non-RPC generic service. Different port, different service — resolve each on its own merits and don’t carry one’s findings onto the other.

Common Risks

• The interface behind the port is the real attack surface. 49666 is just a number; the risk lives in whatever RPC interface the Endpoint Mapper points you to. Runtime-level and coercion bugs (RPC runtime RCE, Zerologon, PrintNightmare, PetitPotam) are reached over exactly these dynamic endpoints, so an exposed 49666 can be the doorway to a domain-critical service.
• Endpoint Mapper leaks the internal service inventory. Query 135 and it happily lists every registered interface UUID and its current dynamic port — a free map of what’s running, letting an attacker pick the vulnerable interface bound to 49666.
• RPC runtime flaws hit every endpoint at once. A bug in the RPC runtime itself (not one service) is reachable through any RPC port, including this dynamic one — CVE-2022-26809 is exactly that class of wormable, unauthenticated network RCE.
• Lateral movement over DCE/RPC. Tools such as Impacket’s wmiexec.py and dcomexec.py, plus PsExec-style techniques (often paired with SMB on 445 or RPC over the named pipes on 139), ride RPC/DCOM over dynamic high ports to run commands across a Windows domain once credentials are in hand.
• Over-broad firewall rules. Firewalls that permit the whole 49152–65535 range “for RPC” expose far more than intended, pushing internal management and RPC surfaces out to untrusted zones or the internet.
• Blind spots in monitoring. Because the port number changes across reboots and hosts, defenders often don’t alert on it — an attacker probing high ports for a vulnerable interface can go unnoticed.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The entire job on 49666 is identification: resolve the dynamic port back to a concrete RPC interface, then test that interface. Start with a version scan across both protocols.

Detect the service and version

nmap -sV -p 49666 <target>
nmap -sU -sV -p 49666 <target>

An nmap -sV label of “Microsoft Windows RPC” confirms you’re looking at a dynamic MSRPC endpoint and that 135 is your next stop.

Enumerate the Endpoint Mapper via NSE

# Queries the MSRPC endpoint mapper for every mapped interface
nmap -p 135 --script msrpc-enum <target>

Resolve the dynamic endpoint with Impacket (via port 135)

A high MSRPC port is meaningless until you map it back to an interface. Dump every endpoint the target registered, then read off which UUID landed on 49666:

# List every RPC interface, its UUID, and its bindings/ports
rpcdump.py <target>

# Bind directly to 49666 and enumerate the interfaces exposed there
rpcmap.py 'ncacn_ip_tcp:<target>[49666]'

Use Metasploit’s DCERPC scanners

msfconsole -q
# Endpoint Mapper Service Discovery (RPORT defaults to 135)
use auxiliary/scanner/dcerpc/endpoint_mapper
set RHOSTS <target>
run

# Bind straight to the high port and fingerprint the DCERPC interface it serves
use auxiliary/scanner/dcerpc/tcp_dcerpc_auditor
set RHOSTS <target>
set RPORT 49666
run

Identify the local process (on the Windows host itself)

# Windows: which PID owns 49666, then map the PID to a service
netstat -anob | findstr 49666
tasklist /svc | findstr <PID>

Record every open 49666, the interface UUID it resolves to, and the owning service, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no CVE for “port 49666” itself — it’s an arbitrary slot in the ephemeral range. The vulnerabilities that matter belong to the RPC runtime and to whatever interface the Endpoint Mapper points you to. Once 135 tells you which UUID landed on 49666, that interface’s CVEs apply. The most relevant, all reachable over dynamic RPC endpoints like this one, are:

• CVE-2022-26809 — Microsoft RPC Runtime Remote Code Execution. The flaw is in the RPC runtime itself, so it is reachable over any RPC endpoint — including a dynamic high port like 49666 — with no authentication and no user interaction. CVSS 9.8 (Critical), network vector, and widely flagged as potentially wormable. This is the single most important reason to keep RPC off untrusted networks.
• CVE-2020-1472 — “Zerologon.” An elevation-of-privilege flaw in the Netlogon Remote Protocol (MS-NRPC), an RPC interface that a domain controller exposes over dynamic endpoints. An unauthenticated attacker who reaches the Netlogon interface can set the DC machine-account password to empty and seize domain-admin control. CVSS 10.0 (NIST) and on CISA’s Known Exploited Vulnerabilities list.
• CVE-2021-34527 — “PrintNightmare.” Remote code execution in the Windows Print Spooler service (MS-RPRN/MS-PAR), which registers dynamic RPC endpoints exactly like this one. Reaching the spooler RPC interface runs code as SYSTEM. CVSS 8.8, on CISA KEV.
• CVE-2021-36942 — “PetitPotam.” A Windows LSA spoofing bug patched to blunt MS-EFSRPC coercion; coercing a machine account into authenticating to an attacker enables NTLM relay to AD CS. CVSS 7.5, on CISA KEV.

CVE removed from the previous version of this page. The old stub cited CVE-2018-8453, which NVD describes as a Win32k local elevation-of-privilege bug (“an elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory”). It requires local access — attack vector Local, not network — and has nothing to do with RPC or any port. It was wrong-service filler and has been removed. Verify every CVE against its NVD record and scope it to the actual interface before trusting it — the bugs on this port are properties of the RPC runtime and its interfaces, never of the port number.

Mitigation

• Identify the real interface before doing anything else. You cannot secure 49666 generically. Resolve it through the Endpoint Mapper on 135, find out whether it’s Netlogon, the spooler, EFSRPC, Task Scheduler, or DCOM, and harden that specific service.
• Patch the RPC runtime and the interface. Apply the CVE-2022-26809 RPC runtime update and the Zerologon, PrintNightmare, and PetitPotam fixes; disable the print spooler on servers that don’t need it; and enforce Netlogon secure-channel signing.
• Don’t expose RPC to untrusted networks. Firewall 135 and the dynamic range (49152–65535) so only trusted management hosts can reach them, and never publish them to the internet. Microsoft’s own guidance for CVE-2022-26809 is to block TCP 445 and the RPC ports at the perimeter.
• Pin the RPC dynamic range and allow only that. Use netsh int ipv4 set dynamicport tcp (or the RPC registry policy) to narrow the dynamic window, then firewall exactly that range instead of the full 16k-port block — which also makes 49666 predictable enough to monitor.
• Segment and monitor. Keep RPC/management traffic on an isolated VLAN, and alert on unexpected DCE/RPC binds from outside your admin subnet even when the port number shifts.
• Rescan to confirm. After locking down, re-run nmap -p 135,49666 <target> and re-resolve the endpoint to verify the surface is actually gone, and log the result in your pentest report.

Real-World Example

The clearest illustration of why a dynamic RPC port like 49666 matters is CVE-2022-26809, disclosed on Patch Tuesday in April 2022. The bug lived in the Windows RPC runtime — the shared machinery every RPC service uses — not in any single application, which meant it was reachable over any RPC endpoint the runtime served: the well-known 135, RPC-over-SMB on 445, and every dynamic high port in the 49152–65535 range, 49666 among them. Rated CVSS 9.8, unauthenticated, no user interaction, and widely described as potentially wormable, it had the security community bracing for a WannaCry-style event and scrambling to block the RPC ports at their perimeters. No public mass-exploitation wave materialised, largely because most organisations had already firewalled 135/445 externally — but that is precisely the lesson: the port number (49666) is mundane and shared, but the RPC runtime bound to it was a critical, network-reachable code-execution surface. Identify what’s actually listening, patch the runtime and the interface, and keep the whole dynamic range off untrusted networks.

FAQ

What is port 49666 used for?

Port 49666 is not a fixed service. It’s a high port inside the Windows ephemeral/dynamic range (49152–65535) that the operating system assigns at runtime to whichever Microsoft RPC service starts and asks for a port — often the Task Scheduler, Event Log, Netlogon on a domain controller, or the DHCP/DNS Server management interface. To learn what actually answers on 49666, you query the Endpoint Mapper on port 135, which maps interface UUIDs to their current dynamic ports.

Why is port 49666 open on my computer?

On a Windows machine it’s almost always normal: an RPC-based system service asked the OS for a dynamic port and was handed 49666. You’ll usually see port 135 open alongside it, plus a cluster of other high ports like 49152 hosting other RPC interfaces. It is not inherently malicious — but because the mapping changes across reboots, you should resolve the interface via 135 rather than assume anything from the number.

How do I find out what service is really behind port 49666?

Query the RPC Endpoint Mapper on 135. Run rpcdump.py <host>, nmap -p 135 --script msrpc-enum <host>, or the Metasploit auxiliary/scanner/dcerpc/endpoint_mapper module to list every registered interface, its UUID, and its current dynamic port, then read off which one landed on 49666. rpcmap.py 'ncacn_ip_tcp:<host>[49666]' binds straight to the port and enumerates the interfaces it serves.

Is port 49666 the same service on every machine?

No. Because the OS assigns dynamic ports based on service start order, 49666 can host different RPC interfaces on different hosts — and even a different interface on the same host after a reboot. Never cache the mapping; always re-resolve through the Endpoint Mapper on 135 before testing.

Is port 49666 TCP or UDP?

It can be either. RPC services usually bind TCP (ncacn_ip_tcp) but can also use UDP (ncadg_ip_udp). Scan both (nmap -sV -p 49666 and nmap -sU -sV -p 49666) so you don’t miss a UDP endpoint.

How do I secure or close port 49666?

Identify the interface first via 135, then patch that service and the RPC runtime (CVE-2022-26809, Zerologon, PrintNightmare, PetitPotam). Pin the RPC dynamic range to a narrow window with netsh int ipv4 set dynamicport tcp, firewall 135 plus that range to trusted management hosts only, keep RPC off the internet, and rescan to confirm the surface is gone.

TL;DR

• Service: no single service — a dynamic Microsoft RPC (MSRPC) endpoint in the Windows ephemeral range (49152–65535), assigned at runtime to an svchost-hosted service (Task Scheduler, Event Log, Netlogon, DHCP, DCOM…) and resolved via the Endpoint Mapper on 135
• Default port: 49666/TCP (and UDP for some RPC services); a dynamic high port, not a fixed assignment — its sibling 49152 is the start of the same range
• Biggest risk: the RPC runtime or interface behind the port — the wormable runtime RCE CVE-2022-26809 (reachable over any RPC endpoint), Netlogon Zerologon, spooler PrintNightmare, or EFSRPC PetitPotam
• Mitigation: resolve the endpoint via 135, patch the RPC runtime and the real interface, pin and firewall the RPC dynamic range to trusted hosts, keep RPC off untrusted networks, and rescan to confirm