Port 593 – RPC over HTTP (ncacn_http)

Port 593 is the default port for the RPC over HTTP endpoint mapper (ncacn_http), the HTTP-tunneled sibling of the classic RPC endpoint mapper that runs on port 135 (ncacn_ip_tcp). It does the same job as 135 — it maps DCE/RPC interface UUIDs to the services and dynamic ports behind them — but it wraps that RPC traffic inside HTTP so it can slip through proxies and firewalls that would drop raw RPC. This is the plumbing that made Outlook Anywhere / RPC-over-HTTP to Exchange work for years, and it is still used by parts of Active Directory and DCOM. To a pentester the important fact is simple: 593 exposes the same RPC interfaces as 135, just over a different transport — so a firewall that carefully blocks 135 but leaves 593 open has left the RPC front door ajar under a different number.

Why It’s Open

Port 593 is open because Windows binds the RPC subsystem (RpcSs/RpcEptMapper) to the ncacn_http protocol sequence so RPC and DCOM can survive a trip across proxies and perimeter firewalls. Where a client on the local network reaches the endpoint mapper on 135, a client stuck behind an HTTP proxy connects to 593 (front-ended in Exchange environments by the RPC Proxy component in IIS) and tunnels the very same RPC calls over HTTP. The canonical driver was Outlook Anywhere, which let Outlook talk to Exchange RPC services from the internet without a VPN; DCOM activation and assorted Active Directory management paths can use the HTTP transport too. Because 593 was provisioned to punch RPC through firewalls by design, it is frequently left reachable on hosts where 135 is filtered — and where you find it you will usually find SMB on 445, NetBIOS on 139, and, on a domain controller, LDAP on 389 nearby.

Common Risks

• The same RPC attack surface as 135, under a different number. 593 maps to the identical DCE/RPC interfaces the endpoint mapper on 135 exposes. Everything an attacker does against 135 — enumeration, coercion, lateral movement — is reachable here too, which makes an “only 135 is blocked” firewall rule a false sense of security.
• Endpoint-map disclosure. Querying the mapper over HTTP lists the RPC interfaces the host has registered, fingerprinting the OS and revealing whether the box is a domain controller, an Exchange server, or a DCOM host — typically without authentication.
• RPC-based authentication coercion. Interfaces such as MS-EFSRPC (PetitPotam) and MS-RPRN (the printer bug) can be called to force a machine account to authenticate to an attacker, feeding an NTLM relay against AD CS or LDAP. The coercion rides the same RPC plumbing that 593 fronts.
• RPC runtime remote code execution. The Windows RPC runtime itself has been remotely exploitable (CVE-2022-26809, rated wormable) over any RPC transport, and the endpoint mapper over HTTP is one of them.
• Overlooked legacy exposure. An internet-reachable 593 often traces back to a forgotten Outlook Anywhere / RPC-over-HTTP deployment that predates modern MAPI-over-HTTP, sitting exposed long after anyone stopped thinking about it.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The play on 593 is to treat it as 135’s HTTP twin: confirm the transport, then dump and map the same RPC interfaces you would over ncacn_ip_tcp.

Detect the service

nmap -sV -p 593 <target>
# pair it with 135 to compare the two transports on the same host
nmap -sV -p 135,593 <target>

Dump the endpoint map with Impacket

# default endpoint-map dump (ncacn_ip_tcp / 135)
rpcdump.py <target>

# point the dump at the HTTP transport on 593
rpcdump.py 'ncacn_http:<target>[593]'

Map which interfaces the HTTP binding exposes

rpcmap.py 'ncacn_http:<target>[593]'

rpcmap.py walks a string binding and reports which RPC interface UUIDs answer on it — the fastest way to prove 593 reaches the same services (spooler, EFSRPC, DC replication) as 135.

Enumerate with Metasploit

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

Coercion over reachable RPC

Coercion tools such as PetitPotam.py (MS-EFSRPC) and Coercer operate over RPC interfaces, so a reachable RPC endpoint — including the HTTP transport on 593 — is the surface they target. Use them only with authorization, and pair any forced authentication with an NTLM relay listener (ntlmrelayx.py) to demonstrate real impact.

Record every open 593, the interfaces the endpoint map returns, and the dynamic ports behind them, so the pivot path lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no port-593-specific CVE. 593 is a transport — the HTTP protocol sequence for the RPC endpoint mapper — so its risk is the attack surface it exposes, not a bug in “port 593” itself. The vulnerabilities that matter are the ones in the RPC runtime and the RPC interfaces reachable over it, which apply equally over ncacn_ip_tcp (135) and ncacn_http (593):

• CVE-2022-26809 — A remote code execution flaw in the Windows RPC runtime, reachable over RPC transports with no authentication or user interaction. Code runs at the privilege of the RPC server and Microsoft rated it wormable — CVSS 9.8. It is most often discussed against TCP 135 and 445, but because the flaw is in the runtime the endpoint mapper serves, the HTTP transport on 593 is another way to reach it. Patched in the April 2022 updates.
• CVE-2021-36942 — The Windows LSA Spoofing vulnerability behind PetitPotam, CVSS 7.5. It let an unauthenticated attacker coerce a machine account to authenticate via the MS-EFSRPC interface — an RPC call reachable over any transport that fronts that interface — which was then relayed to AD CS for domain takeover. Microsoft’s patch blocked the specific EFSRPC coercion path; the broader coercion technique is a design-level risk of exposing reachable RPC.

Much of 593’s real-world risk is honestly design-level: it is another reachable RPC surface that coercion (PetitPotam, the printer bug) and interface enumeration can be driven against, often on hosts where 135 was firewalled and 593 was forgotten. Scope any finding to the actual RPC runtime/interface version behind the port rather than to the port number.

Mitigation

• Don’t firewall 135 and forget 593. If you block the RPC endpoint mapper at the perimeter, block both transports — 135 (ncacn_ip_tcp) and 593 (ncacn_http) — or the HTTP twin quietly re-opens the surface you thought you closed.
• Never expose 593 to the internet or untrusted segments. Restrict it to the management ranges that genuinely need RPC-over-HTTP, with a host firewall.
• Retire legacy Outlook Anywhere / RPC-over-HTTP. Modern Exchange uses MAPI-over-HTTP; decommission old RPC-over-HTTP virtual directories and confirm 593 is no longer reachable.
• Patch the RPC runtime. The April 2022 update closes CVE-2022-26809; keep hosts current so the wormable path stays shut over every transport.
• Blunt coercion and relay. Apply the PetitPotam mitigations (CVE-2021-36942), enforce SMB signing and Extended Protection for Authentication, and enable AD CS HTTPS/EPA so a coerced machine account can’t be relayed.
• Segment and monitor. Inside AD you can’t rip out RPC; put domain controllers and servers behind segmentation and watch the endpoint mapper — on both 135 and 593 — for enumeration from unexpected hosts.

Real-World Example

PetitPotam (July 2021) is the cleanest illustration of why another reachable RPC transport matters. Researcher GILLES Lionel released a tool that made an unauthenticated RPC call to the MS-EFSRPC interface to coerce a Windows machine — including a domain controller — into authenticating back to an attacker-controlled host. Chained with ntlmrelayx.py, that forced authentication was relayed to Active Directory Certificate Services, which minted a certificate for the domain controller’s machine account and handed the attacker a path straight to Domain Admin. Microsoft responded with CVE-2021-36942 to close the specific EFSRPC coercion vector. The lesson for port 593 is direct: the coercion is an RPC technique, not a 135 technique — it works wherever the interface is reachable, and a host that dutifully filters 135 but leaves the ncacn_http endpoint mapper on 593 exposed has simply offered the same front door under a different number. Before that, the identical transport was what carried millions of Outlook Anywhere sessions to Exchange — the same plumbing, put to opposite purposes.

FAQ

What is port 593 used for?

Port 593 is the HTTP transport (ncacn_http) for the Microsoft RPC endpoint mapper. It maps DCE/RPC interfaces to their services and lets RPC and DCOM ride over HTTP so they can traverse proxies and firewalls that would block raw RPC. Historically it was the backbone of Outlook Anywhere (RPC-over-HTTP to Exchange), and parts of Active Directory and DCOM use it too.

Is port 593 the same as port 135?

They are the same endpoint mapper over two different transports. Port 135 is RPC over TCP (ncacn_ip_tcp); port 593 is the identical RPC service over HTTP (ncacn_http). They expose the same RPC interfaces, so anything you can enumerate, coerce, or exploit against 135 is reachable over 593 as well — which is exactly why blocking only one is a mistake.

Is port 593 dangerous?

The port isn’t dangerous by itself, but the RPC surface it exposes is. An exposed 593 lets an attacker dump the endpoint map, fingerprint the host, drive RPC coercion (PetitPotam, the printer bug) toward an NTLM relay, and reach RPC-runtime bugs like CVE-2022-26809. Internally it’s a normal transport; internet-facing, it’s a serious finding — often a forgotten Outlook Anywhere deployment.

How do I enumerate port 593?

Confirm the transport with nmap -sV -p 593 <target>, then treat it like 135: dump the endpoint map with Impacket (rpcdump.py 'ncacn_http:<target>[593]') and map which interfaces answer with rpcmap.py 'ncacn_http:<target>[593]'. Metasploit’s auxiliary/scanner/dcerpc/endpoint_mapper works against the RPC endpoint mapper as well.

Can I close port 593?

Yes, if nothing needs RPC-over-HTTP. Decommission legacy Outlook Anywhere / RPC-over-HTTP virtual directories, block 593 at the perimeter alongside 135, and restrict it to management ranges internally. Inside Active Directory you generally segment and monitor RPC rather than removing it outright. Rescan afterward to confirm the port is closed.

Is port 593 TCP or UDP?

TCP. The ncacn_http transport carries RPC inside HTTP over TCP 593. (An older UDP variant of RPC exists on ncadg_ip_udp, but the HTTP endpoint mapper on 593 is TCP.)

TL;DR

• Service: RPC over HTTP endpoint mapper (ncacn_http) — the HTTP twin of the 135 RPC endpoint mapper, historically behind Outlook Anywhere
• Default port: 593/TCP
• Biggest risk: the same RPC surface as 135 under a different number — endpoint-map enumeration, RPC coercion (PetitPotam / printer bug) into NTLM relay, and RPC-runtime RCE (CVE-2022-26809), often left open where 135 is filtered
• Mitigation: firewall 593 alongside 135, retire legacy RPC-over-HTTP, patch the RPC runtime, apply PetitPotam/coercion mitigations, and segment and monitor RPC inside AD