Port 20000 – DNP3 (Distributed Network Protocol)

Port 20000 is the standard, IANA-registered port for DNP3 (Distributed Network Protocol 3), the SCADA protocol that dominates electric power and water/wastewater utilities. It carries the real-time conversation between a master — the control-center SCADA host — and its outstations: the remote terminal units (RTUs), intelligent electronic devices (IEDs), and protective relays sitting in substations, pump stations, and along distribution feeders. Over DNP3 a master reads analog and binary points (voltages, breaker states, tank levels), collects time-stamped event data by exception, and — this is the part that matters — issues control commands that operate real hardware. And it does all of this, in its baseline form, with no authentication and no encryption. Reaching port 20000 is, by protocol design, most of the way to controlling the device behind it.

Why It’s Open

Port 20000 is open because a utility depends on it. DNP3 is the backbone of distribution and substation SCADA in North America and much of the world: RTUs, IEDs, protection relays, protocol gateways, and data concentrators all listen on 20000 so the control center can poll them around the clock and send operators’ commands back. Standardized as IEEE 1815 (revisions 1815-2012 and 1815-2020), DNP3 is prized in operational technology for reporting-by-exception, precise event time-stamping, and resilience over slow, lossy, or intermittent links — exactly the conditions of a rural feeder or a remote pump station.

The trouble is where that port ends up reachable. DNP3 was designed for isolated serial links inside a trusted substation, then lifted onto TCP/IP essentially unchanged. Flat OT networks, cellular RTUs, remote-engineering access, and the general collision of IT and OT have pushed these endpoints onto routable networks — and a Shodan or Censys search for port:20000 reliably returns internet-facing RTUs and outstations answering DNP3 directly. There is no login to fail. If the outstation answers, it is talking to whoever asked.

Common Risks

• No authentication by default. Baseline DNP3 has no concept of a user, password, or session. Reaching the outstation is the authorization. There is a standardized fix — DNP3 Secure Authentication (SAv5, IEEE 1815-2012) — but it is rarely deployed in the field, so in practice most reachable DNP3 endpoints trust whatever master address speaks to them.
• No encryption. DNP3 frames — device addresses, object data, control payloads — cross the wire in cleartext. Anyone on the path can read process state and craft spoofed or replayed messages that are indistinguishable from legitimate traffic.
• Unauthenticated control of physical outputs. A reachable outstation will accept Control Relay Output Block (CROB) commands (object group 12) via SELECT/OPERATE or DIRECT_OPERATE — letting an attacker trip or close a breaker, operate a relay, or change a setpoint on live power or water infrastructure.
• Telemetry disruption and operator blinding. Beyond writes, an attacker can disable unsolicited responses, force COLD_RESTART/WARM_RESTART, or feed forged responses so the control center sees fabricated “normal” readings while the real process drifts — a classic ICS deception.
• Implementation robustness bugs. DNP3 stacks have historically crashed on malformed frames (see Project Robus below), so a single crafted packet can knock a master or outstation offline — a denial of service against supervisory control.
• Segmentation failure. DNP3 belongs on an isolated OT network. A port 20000 reachable from the IT LAN or the internet means the isolation the protocol assumes has already broken.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

DNP3 testing is not like testing an IT service: reads are usually harmless, but control commands, restarts, and even malformed probes can trip protection, misoperate equipment, or crash fragile OT gear and endanger people. Only ever touch equipment you are explicitly authorized to test, prefer passive discovery on live networks, and keep any active or state-changing operation to a lab bench or an agreed maintenance window — never a live outstation running a feeder.

Confirm the service and version (light touch)

nmap -sV -p 20000 <target>

DNP3 outstation discovery (community NSE)

There is no dnp3-info script in stock Nmap. The one everyone uses is dnp3-info.nse from Digital Bond’s Redpoint project (authored by Stephen Hilt; categories discovery, intrusive). You install it yourself, and because it sends real DNP3 application-layer requests to enumerate the outstation, treat it as an active, intrusive test:

# Redpoint community NSE — clone/copy dnp3-info.nse into your scripts dir first
nmap --script dnp3-info -p 20000 <target>

Read points and issue requests with a DNP3 library

There is no dedicated DNP3 module in the Metasploit Framework (its auxiliary/scanner/scada/ tree covers Modbus, BACnet, Profinet, Koyo, Moxa and others — but not DNP3), so don’t cite one. For hands-on DNP3 work use a real stack instead:

# opendnp3 — the reference open-source DNP3 stack (C++), ships master/outstation demos
# pydnp3 — Python bindings over opendnp3 for scripting an integrity poll (Class 0/1/2/3)
python3 - <<'PY'
# pseudo-flow: build a master, connect to <target>:20000, run an integrity poll,
# then read the returned analog/binary points. Do NOT send CROB/OPERATE outside a lab.
PY

Prefer passive discovery in production

On a live utility network, inventory DNP3 by watching traffic, not probing it. A SPAN/TAP feeding Wireshark’s DNP3 dissector or an OT-aware IDS / Zeek with a DNP3 analyzer enumerates masters, outstations, addresses, and function codes without ever touching a device. DNP3 frames are easy to fingerprint — they begin with the 0x05 0x64 start bytes.

Record every reachable DNP3 endpoint, whether it enforces DNP3 Secure Authentication, the points you read, and any unpatched vendor stack you find, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The single most important thing to understand about port 20000 is that DNP3’s biggest weakness is not a CVE — it is the design. There is no missing patch that adds authentication or encryption to baseline DNP3; the lack of both is inherent to the protocol as historically deployed, and “unauthenticated read/write to an outstation” is expected behaviour, not a bug. The mitigation for that is architectural (segmentation) plus enabling DNP3 Secure Authentication — covered below — not a firmware update.

Where real, verifiable CVEs do exist is in specific vendor DNP3 stacks, and the richest source is the Crain–Sistrunk “Project Robus” fuzzing campaign (2013–2014), which drove roughly 30 ICS-CERT advisories by feeding malformed DNP3 into implementations from many vendors. These are implementation-robustness (DoS/crash) bugs, fixed in vendor updates:

• CVE-2013-2811 — The Catapult Software DNP3 I/O driver (before 7.2.0.60) and the GE Intelligent Platforms Proficy DNP3 I/O driver (before 7.20k), shipped in GE Proficy HMI/SCADA (CIMPLICITY and iFIX), let a remote attacker cause a denial of service (infinite loop) in the DNP3 master via a crafted DNP3 TCP packet. Unauthenticated, network-reachable — the class of bug that directly threatens a port-20000 master. CWE-20, CVSS v2 7.1 (High).
• CVE-2014-2342 — Triangle MicroWorks SCADA Data Gateway before 3.00.0635 allows a remote denial of service (excessive data processing) via a crafted DNP3 packet. CWE-20/CWE-400, CVSS v2 5.0 (Medium).
• CVE-2013-2823 — The same Catapult / GE Proficy driver family, a DoS (infinite loop) triggered by crafted input over a serial line rather than TCP. Included honestly here because it is the classic Project Robus point that even serial reach is an attack surface — but note it is not a network/port-20000 vector (CVSS v2 4.7, local). Treat it as a stack-quality signal, not a remote exploit.

The broader Project Robus takeaway: DNP3 Secure Authentication does not protect against malformed input — a device can be crash-tested regardless of whether SA is enabled — so patching the vendor stack matters independently of turning authentication on. When you fingerprint a specific outstation on port 20000, check that vendor and firmware version against NVD/ICS-CERT; the DNP3 advisory space is vendor-scoped (Catapult, GE, Triangle MicroWorks, SEL, Kepware and others each have their own). Don’t over-claim: none of these give unauthenticated code execution, and the design-level no-auth risk remains the headline.

Mitigation

Because the core risk is design-level, most fixes are network-architectural, not patch-level:

• Never expose port 20000 to the internet. Audit with Shodan/Censys and firewall rules; a DNP3 outstation answering a public IP is an incident waiting to happen.
• Segment the OT network (Purdue model). Keep RTUs/IEDs/relays in their process cell behind an industrial DMZ, isolated from IT and, where possible, from each other. DNP3 assumes a trusted, isolated bus — give it one.
• Enable DNP3 Secure Authentication. IEEE 1815-2012 (SAv5) adds cryptographic message authentication; IEEE 1815-2020 (SAv6) adds authenticated encryption (AES-GCM) and centralized key management. Turn it on wherever masters and outstations support it — it is the standardized answer to the no-auth default.
• Wrap DNP3 in TLS or a VPN gateway. Where SA isn’t available, tunnel DNP3 through a TLS-terminating gateway or site-to-site VPN so the cleartext protocol never rides an untrusted path.
• Allowlist masters on outstations. Restrict each outstation to accept sessions and controls only from its authorized master IP(s) and DNP3 source addresses; drop everything else at an OT-aware firewall.
• Use unidirectional gateways / data diodes for telemetry that only needs to flow outward (historian, monitoring), so no inbound control path exists at all.
• Patch the vendor DNP3 stack for the Project Robus CVEs and track ICS-CERT/CISA advisories for your specific product, even though the protocol itself won’t change.
• Monitor DNP3 traffic with a protocol-aware IDS for control-oriented functions (CROB OPERATE, COLD_RESTART, disable-unsolicited, writes) arriving from unexpected sources.

Real-World Example

The defining port-20000 story is Project Robus. In 2013–2014, researchers Adam Crain and Chris Sistrunk systematically fuzzed DNP3 implementations from a wide range of vendors — Catapult Software, GE, Triangle MicroWorks, SEL, Kepware and more — and found that crafted DNP3 responses and frames repeatedly crashed master stations, the control-center hosts that monitor and command substations. An attacker able to inject malformed DNP3 could blind operators to grid conditions and disrupt supervisory control. The work produced roughly 30 ICS-CERT advisories and a wave of vendor patches (including CVE-2013-2811 and CVE-2014-2342), and it made a lasting point: the exposure wasn’t an exotic zero-day but ordinary, reachable DNP3 endpoints that trusted whatever bytes arrived.

The quieter, ongoing example is exposure itself. At any given time, Shodan and Censys searches for port:20000 return internet-facing DNP3 outstations — utility RTUs and IEDs — answering unauthenticated read and, often, control requests to anyone who asks. Because baseline DNP3 has no login and DNP3 Secure Authentication is so rarely enabled, a reachable outstation is effectively controllable: an attacker can read its points and, in the worst case, issue CROB OPERATE commands against real breakers and relays. No zero-day is required; the protocol’s own defaults are the vulnerability, and the internet-facing ones are found the moment they appear.

FAQ

What is port 20000 used for?

Port 20000 is the standard TCP/UDP port for DNP3 (Distributed Network Protocol 3), the SCADA protocol that electric-power and water/wastewater utilities use to connect a control-center master to field outstations — RTUs, IEDs, and protective relays. It carries live telemetry (analog and binary points, time-stamped events) and the control commands that operate physical equipment.

Is port 20000 dangerous to expose?

Extremely, on any untrusted network. Baseline DNP3 has no authentication and no encryption, so anyone who can reach port 20000 can read process data and — unless DNP3 Secure Authentication is enabled — issue valid control commands to breakers, relays, and setpoints. An internet-facing port 20000 should be treated as a critical exposure to close, not a service to harden in place.

Does DNP3 have authentication or encryption?

Not by default. Classic DNP3 was built for isolated serial links and has neither. There is a standardized add-on — DNP3 Secure Authentication (SAv5 in IEEE 1815-2012; SAv6 with authenticated encryption in IEEE 1815-2020) — but it is rarely deployed in the field. Where it isn’t enabled, confidentiality and authenticity depend entirely on the network around DNP3 (segmentation, TLS, or a VPN).

Can an attacker actually control equipment over port 20000?

Yes, on an unauthenticated outstation. DNP3’s Control Relay Output Block (CROB, object group 12) via SELECT/OPERATE or DIRECT_OPERATE lets a reachable peer trip or close breakers, operate relays, and change setpoints. Attackers can also disable unsolicited reporting or force restarts to disrupt telemetry and blind operators.

Is there a CVE that fixes DNP3’s lack of security?

No, and there won’t be — the missing authentication and encryption are design characteristics of baseline DNP3, not a tracked bug. Real CVEs exist in specific vendor stacks (for example the Project Robus DoS bugs CVE-2013-2811 and CVE-2014-2342), but the protocol-level risk is addressed with network architecture plus enabling DNP3 Secure Authentication, not a single patch.

How do I secure port 20000?

Keep it off the internet entirely, segment OT from IT using the Purdue model, enable DNP3 Secure Authentication wherever devices support it, allowlist only the masters that need to poll each outstation, use unidirectional gateways for outbound-only telemetry, and wrap DNP3 in TLS or a VPN where SA isn’t available. Patch the vendor stack for the Project Robus CVEs and monitor DNP3 traffic for unexpected control functions.

TL;DR

• Service: DNP3 (Distributed Network Protocol 3) — SCADA master-to-outstation communication in electric power and water utilities
• Default port: 20000/TCP and 20000/UDP (DNP3-over-TLS is registered on 19999; DNP3 also runs on a non-standard port 4024 in some vendor deployments)
• Biggest risk: no authentication and no encryption by default — DNP3 Secure Authentication (SAv5) exists but is rarely deployed — so anyone reaching port 20000 can read outstation points and issue CROB control commands against breakers and relays; vendor stacks also carry Project Robus DoS bugs
• Mitigation: never internet-expose; segment (Purdue model); enable DNP3 Secure Authentication; allowlist masters; use TLS/VPN and unidirectional gateways; patch vendor firmware and monitor for control functions

DNP3 is one of several ICS and device-management protocols that assume a trusted network they no longer have. For related exposures, see Modbus on port 502 (the other dominant no-auth ICS fieldbus), SNMP on port 161 (device management with weak community strings), and Telnet on port 23 (unencrypted legacy device administration). Siemens S7comm on port 102 is the analogous PLC protocol in Siemens-heavy plants, and IEC-104 on port 2404 is the sibling telecontrol protocol across European and Asian power grids. Whatever you find on port 20000, capture the reachable outstations, the points you read, and the control impact directly in your pentest reporting tool.