Port 9389 – ADWS (Active Directory Web Services)

Port 9389 is the default port for Active Directory Web Services (ADWS), a SOAP-based web service that Microsoft ships on every domain controller. Introduced with Windows Server 2008 R2 and enabled automatically when a server is promoted to a DC, ADWS gives management tools a web-friendly way into the directory: the ActiveDirectory PowerShell module (Get-ADUser, Get-ADComputer, and friends) and the Active Directory Administrative Center (ADAC) both talk to 9389 rather than hitting LDAP directly. Under the hood, ADWS wraps directory queries in SOAP messages over a .NET Net.TCP binding, hands them to the directory service running on the same box, and returns the results. In practice that makes port 9389 an alternate query channel for the same data you’d normally pull over LDAP on port 389 — and, increasingly, the channel attackers reach for precisely because defenders are watching LDAP and not ADWS.

Why It’s Open

ADWS is open because it’s part of Active Directory Domain Services. When a Windows Server becomes a domain controller, the AD Web Services role service starts and binds 9389 by default — you can’t manage AD with the modern PowerShell module or ADAC without it. It runs alongside the rest of the domain-controller stack: Kerberos on port 88, LDAP on 389, LDAPS on 636, the Global Catalog on 3268/3269, and RPC on port 135. So an open 9389 is, on its own, a reliable fingerprint of a domain controller — and it means administrators (and their automation, and their monitoring appliances) are using the web-service path to read and change the directory. It’s a legitimate, load-bearing service; the problem is that the same door serves attackers just as well.

Common Risks

• Stealthy directory enumeration that evades LDAP monitoring. ADWS exposes the same users, groups, computers, ACLs, trusts, and GPOs as LDAP, but the queries travel as SOAP over Net.TCP — not as the LDAP traffic most SOC tooling and ETW-based detections are tuned to catch. Pulling a full BloodHound-style graph over 9389 sidesteps a lot of LDAP-focused visibility.
• A second, often-unmonitored recon channel. Teams frequently lock down and log LDAP while leaving ADWS wide open by default. Any authenticated domain user can query the directory over 9389, so the port is a low-friction reconnaissance surface for privilege-escalation and lateral-movement mapping.
• NTLM relay into ADWS. ADWS clients authenticate with NTLM by default, and the service historically lacked signing/channel-binding enforcement, so coerced or relayed NTLM authentication can be pointed at 9389 to act against the directory as the relayed identity.
• Exposure of the whole AD schema. Because ADWS is a thin wrapper over the directory, a read-only foothold still yields SPNs (for Kerberoasting), delegation settings, adminCount objects, ACL misconfigurations, and trust relationships — the raw material for nearly every AD attack path.
• Blind spot in defence. SOAP traffic to ADWS is not captured in Windows event logs by default; without extra diagnostics (Directory Service field logging, decoy objects, or network monitoring) an operator can enumerate the domain over 9389 while leaving almost nothing in the standard logs.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The point of testing port 9389 is to confirm it’s a domain controller and then show how much of the directory can be read over the web-service channel — the same data an LDAP assessment would gather, but through a path that’s often unwatched.

Detect the service and version

nmap -sV -p 9389 <target>

Nmap reports 9389 as adws (Microsoft AD DS Web Services); the underlying transport is .NET Message Framing over TCP, so a version probe may also surface it as mc-nmf. An open 9389 next to 88/389/636 is a domain controller.

Query the directory with the AD PowerShell module (over ADWS)

The Microsoft ActiveDirectory module speaks to a DC over 9389, not LDAP. From a domain-joined or credentialed context:

Get-ADDomain -Server <target>
Get-ADUser -Filter * -Server <target> -Properties servicePrincipalName,adminCount
Get-ADComputer -Filter * -Server <target>
Get-ADGroup -Filter * -Server <target>
Get-ADTrust -Filter * -Server <target>

Every one of these calls rides ADWS on 9389 — useful for pulling users, groups, computers, SPNs, and trusts without generating classic LDAP query traffic.

Collect BloodHound-style data over ADWS

SOAPHound (FalconForce) is a .NET collector that builds a cache of directory objects over ADWS and emits BloodHound-compatible output, deliberately avoiding direct LDAP:

# On the target/host context (.NET):
SOAPHound.exe --buildcache -c cache.txt
SOAPHound.exe -c cache.txt --bhdump -o bloodhound-output --nolaps
SOAPHound.exe --dnsdump -o dns-output

From Linux, SoaPy (Logan Goins / Jackson Leverett) does ADWS enumeration in pure Python and can be proxied through SOCKS:

soapy 'domain/user:password@<target>' --users
soapy 'domain/user:password@<target>' --query '(objectClass=computer)' --filter "samaccountname,objectsid"

ShadowHound-DS (PowerShell) is a further option that drives the AD module for the same ADWS-based collection.

Test NTLM relay into ADWS

Impacket’s ntlmrelayx.py added a WCF relay server specifically to point coerced/relayed NTLM authentication at the ADWS Net.TCP endpoint:

ntlmrelayx.py -t <target> -smb2support   # WCF/ADWS relay target on 9389

Note there is no Metasploit module for ADWS — enumeration here is driven by .NET, PowerShell, and Python tooling, not by raw LDAP clients or an MSF exploit path. Record every object, ACL, SPN, and trust you pull over 9389 straight into the pentest report so the ADWS collection is documented as its own finding, not lost in a terminal.

What to Look For

Known CVEs and Exploits

Port 9389 is not a “big CVE” port, and it’s important to be honest about that. There is no widely recognised, ADWS-specific remote CVE — no headline RCE or denial-of-service bug in the Active Directory Web Services daemon itself. Searching NVD for “Active Directory Web Services” returns only vulnerabilities in other AD-adjacent services — Active Directory Federation Services (ADFS) and Active Directory Certificate Services (ADCS) — such as CVE-2018-8547 and CVE-2011-1264, which run on different ports and are not ADWS bugs. Don’t let keyword matches fool you into pinning ADFS/ADCS flaws on 9389.

The real significance of port 9389 is as a stealth reconnaissance channel and attack surface, not a patchable single vulnerability:

• ADWS-based enumeration that evades LDAP-focused detection. SOAPHound (FalconForce), SoaPy, and ShadowHound collect the full directory over ADWS instead of LDAP, so the query traffic doesn’t look like the LDAP most detections watch for. This is a technique, not a CVE — and it works against fully patched domain controllers.
• NTLM relay of ADWS/WCF connections. Documented by Clément Notin and weaponised via Impacket’s ntlmrelayx.py WCF relay server: coerced NTLM authentication is relayed to 9389 to act against the directory. Again, this is a design/configuration weakness (NTLM + missing signing) rather than a numbered ADWS CVE.

Because this is a brand-new page, no incorrect or fabricated CVEs were carried over from an older stub — none were invented, and none needed removing. If you find an advisory that claims to be an “ADWS CVE,” verify on NVD that the affected product is genuinely AD Web Services on 9389 before you trust it; most such matches turn out to be ADFS or ADCS.

Mitigation

• Monitor ADWS the way you monitor LDAP. The core fix for the stealth-recon risk is visibility. Enable Directory Service field/diagnostic logging (Event ID 1644 for expensive/inefficient searches), deploy decoy (“canary”) accounts with a SACL that audits property reads (Event ID 4662), and watch Sysmon Event ID 3 for network connections to 9389 from unexpected hosts.
• Restrict who can reach 9389. Firewall ADWS so only administrative jump hosts and management tooling can reach the port on domain controllers; there’s rarely a reason for arbitrary workstations to connect to a DC’s web service.
• Kill NTLM relay. Prefer Kerberos over NTLM, enforce SMB and LDAP signing and channel binding across the domain, and remove application patterns that pass user-supplied server names into the AD module — all of which shut down relay-into-ADWS paths.
• Baseline normal ADWS use. Know which accounts and hosts legitimately run the AD PowerShell module or ADAC, so bulk directory dumps over 9389 from anything else stand out.
• Don’t disable it blindly. ADWS is required for modern AD management; the answer is segmentation and monitoring, not turning off a service the admins depend on. Treat 9389 as one more domain-controller service to lock down and log, right beside 88, 389, and 636.

Real-World Example

The canonical scenario for port 9389 is SOAPHound-style collection that quietly beats LDAP detection. FalconForce released SOAPHound in early 2024 as a .NET data collector that gathers everything BloodHound needs — users, groups, computers, GPOs, containers, ACLs, even ADCS and AD-integrated DNS — but does it over ADWS. The trick is that SOAPHound wraps its LDAP-equivalent queries in SOAP messages sent over the Net.TCP binding to 9389; the domain controller unwraps them and runs them against the directory locally, so no LDAP query traffic ever crosses the wire. Blue teams that had invested in LDAP query monitoring and ETW-based LDAP detections suddenly had a graph of their entire domain pulled without tripping those controls. Follow-ups like SoaPy (from an IBM X-Force Red internship) brought the same technique to Linux with SOCKS proxying, and the wider defensive community responded by adding ADWS-specific detections — decoy-object SACL auditing and Directory Service diagnostic logging chief among them. The episode is the port-9389 lesson in one story: the service has no dramatic CVE, but because it’s an unwatched twin of LDAP, simply choosing to enumerate over 9389 was enough to render a lot of Active Directory monitoring blind.

FAQ

What is port 9389 used for?

Port 9389 is the default port for Active Directory Web Services (ADWS), a SOAP web service that runs on every Windows domain controller. It lets the ActiveDirectory PowerShell module (Get-ADUser, Get-ADComputer, etc.) and the Active Directory Administrative Center read and manage the directory over a web-service channel instead of talking to LDAP directly.

Is port 9389 a domain controller?

Effectively, yes. ADWS is enabled by default when a Windows Server is promoted to a domain controller and isn’t found on ordinary member servers, so an open 9389 — especially alongside Kerberos (88), LDAP (389), LDAPS (636), and the Global Catalog (3268) — is a strong fingerprint that the host is a DC.

How is ADWS on 9389 different from LDAP on 389?

They expose the same directory data, but by different means. LDAP on 389 is the classic query protocol; ADWS on 9389 wraps directory queries in SOAP over a .NET Net.TCP binding. The security consequence is that many organisations monitor and harden LDAP while leaving ADWS unwatched, making 9389 an alternate, often-invisible path to the same information.

Does port 9389 have any serious CVEs?

No — there is no widely recognised ADWS-specific remote CVE. Its importance is as a stealthy reconnaissance channel and attack surface, not a single patchable bug. NVD keyword hits for “Active Directory Web Services” are actually ADFS or ADCS vulnerabilities on other ports, so verify any “ADWS CVE” claim against the affected product before believing it.

What is SOAPHound and why does it use port 9389?

SOAPHound is an open-source .NET collector from FalconForce that gathers BloodHound-style Active Directory data over ADWS on 9389 instead of over LDAP. By sending SOAP messages that the DC unwraps into local LDAP queries, it avoids putting LDAP traffic on the wire, which sidesteps LDAP-focused monitoring and ETW detections. SoaPy (Python/Linux) and ShadowHound (PowerShell) achieve the same over ADWS.

How do I secure or monitor port 9389?

Don’t disable it — AD management needs it — but restrict and watch it. Firewall 9389 to administrative jump hosts, enforce Kerberos and signing/channel binding to defeat NTLM relay, and add ADWS visibility: Directory Service diagnostic logging (Event 1644), decoy accounts with SACL property-read auditing (Event 4662), and Sysmon network-connection monitoring (Event ID 3) for connections to 9389. Feed anything unusual into your pentest report or detection backlog.

TL;DR

• Service: Active Directory Web Services (ADWS) — SOAP-over-Net.TCP web service on domain controllers, used by the AD PowerShell module and Active Directory Administrative Center
• Default port: 9389/TCP (enabled by default on every DC since Windows Server 2008 R2)
• Biggest risk: stealthy directory enumeration that evades LDAP-focused detection — tools like SOAPHound, SoaPy, and ShadowHound pull BloodHound-grade recon over 9389 without generating LDAP traffic; NTLM relay into the WCF endpoint is a secondary concern. No headline ADWS CVE — it’s an attack-surface/visibility problem, not a patch problem
• Mitigation: firewall 9389 to management hosts, enforce Kerberos + signing/channel binding to stop relay, and add ADWS-specific monitoring (Directory Service diagnostics, decoy-object SACL auditing, Sysmon network events) so 9389 is logged like the rest of the DC