Port 444 – SNPP (Simple Network Paging Protocol)

Port 444 is the registered port for SNPP (Simple Network Paging Protocol), defined in RFC 1861. SNPP is a simple, SMTP-like text protocol: an application opens a TCP connection to a paging gateway and sends an alphanumeric message to a pager using a handful of plain commands — PAGE, MESS, SEND, RESET, QUIT. It was built in the 1990s so scripts, monitoring systems, and email gateways could deliver pages over IP instead of dialing a modem with the older TAP/IXO protocol. Paging has largely been replaced by SMS and push notifications, so a live SNPP server is now mostly a legacy footprint — you’ll still find it in hospitals, industrial sites, and emergency services that kept their paging infrastructure. One caveat up front: TCP 444 is registered to SNPP but often used for other things in practice — Microsoft Exchange binds its back-end website (HTTPS, normally 443) to 444, load balancers like Zevenet/SKUDONET expose a web GUI there, and malware has historically squatted on the port — so an open 444 is not automatically SNPP.

Why It’s Open

SNPP servers shipped with paging software like QuickPage (which installs an snpp daemon) and HylaFAX (whose hfaxd can answer SNPP on 444), plus commercial paging gateways from carriers and messaging vendors. Where the port is open on purpose, something is still sending pages — a monitoring box alerting on-call staff, a SCADA/industrial controller, or a hospital notification system. Because level-1 SNPP needs no login, it was easy to wire into scripts and left running long after the pagers themselves were retired. Just as often, an open 444 has nothing to do with paging: on Windows mail servers it’s the Exchange back-end HTTPS listener, and on some appliances it’s a management GUI. Always fingerprint the service before assuming SNPP.

Common Risks

• Unauthenticated page injection (open relay). Level-1 SNPP (RFC 1861) has no authentication. Anyone who can reach the gateway can send — and spoof — pages to any subscriber: spam, fake alerts, and social-engineering against whoever carries the pager. Still a live concern for hospital and emergency paging.
• Cleartext everywhere. SNPP is plain text with no TLS. Message content, and any level-2/3 LOGIn credentials, cross the wire in the clear and are trivially sniffable on a shared segment.
• Flooding and alert fatigue. With no native rate limiting, an attacker can flood the gateway (or a specific pager) with messages, drowning real alerts or knocking the paging service over.
• Information disclosure. Pages often carry sensitive operational detail — hostnames, room or patient identifiers, alarm text — that an open gateway leaks to anyone probing it.
• Legacy, unmaintained code. SNPP daemons like QuickPage and older HylaFAX builds are rarely patched or monitored, and decades-old text-command parsers are exactly where buffer-overflow and parsing bugs hide.
• Mistaken identity. An open 444 may actually be Exchange’s back end or an appliance GUI. Treating it as SNPP — or the reverse — wastes time and can mask the real exposure.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

SNPP has no dedicated Nmap NSE script or Metasploit module — enumeration is manual, over netcat or telnet, using the protocol’s own text commands.

Detect the service and version

nmap -sV -p 444 <target>

Nmap usually fingerprints an SNPP server as snpp. If it reports HTTPS/SSL instead, you’re likely looking at Exchange’s back end or an appliance GUI, not paging.

Connect and list commands

nc -nv <target> 444
HELP

A live SNPP server greets with a 220 banner, and HELP lists the supported commands (PAGE, MESS, SEND, RESET, QUIT).

Walk a page through manually

# after connecting with nc/telnet:
PAGE 5551234            # target pager ID
MESS test from pentest
SEND                    # 250 = queued / delivered
QUIT

If SEND succeeds without any login, the gateway is an unauthenticated open relay — record it.

Log every open gateway and every page you can send unauthenticated so it lands in the final pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

There is no solid, dedicated CVE for SNPP itself or for port 444. The durable risk here is architectural, not a single patchable bug:

• No SNPP-specific CVE — the design is the vulnerability. Level-1 SNPP has no authentication and no encryption, so an exposed gateway is an open, cleartext relay for pages by design. That’s the finding to write up, not a CVE number.
• QuickPage had a buffer overflow corrected in its FreeBSD port in 2008 (ports PR 128216), but no CVE was ever assigned — worth noting on legacy installs, not something with a public exploit.
• HylaFAX does implement an SNPP server, but its known CVEs sit in other components, not the SNPP listener: CVE-2002-1050 is a faxgetty overflow via fax image data, and CVE-2013-5680 is a heap overflow in the hfaxd FTP-style client channel (default TCP 4559) when built with LDAP auth (Exploit-DB 28683). Neither is triggered through SNPP on 444 — don’t report them as port-444 findings.
• Watch for mislabeled CVEs. Some port-444 references cite CVE-2004-0790 as an “SNPP buffer overflow.” It isn’t: CVE-2004-0790 is the ICMP blind connection-reset (TCP denial-of-service) issue and has nothing to do with SNPP. Verify before you cite.

Mitigation

• Retire SNPP if paging is dead. If nothing still pages, stop the QuickPage/HylaFAX SNPP service so it stops binding 444, and confirm with a rescan.
• Require authentication and restrict senders. If paging is still in use, run a gateway that enforces level-2/3 LOGIn, and firewall 444 to the specific monitoring hosts allowed to send pages.
• Put it behind a tunnel. SNPP has no TLS of its own — carry it over a VPN or an stunnel/SSH tunnel so message content and any credentials aren’t in cleartext.
• Rate-limit and monitor. Cap pages per source and alert on bursts so the gateway can’t be used for spam, spoofing, or flooding.
• Confirm what 444 actually is. If it’s Exchange’s back end or an appliance GUI, harden that — certificates, access control — rather than chasing a paging service that isn’t there.
• Patch the daemon. Keep QuickPage/HylaFAX current and retire builds old enough to predate their buffer-overflow fixes.

Real-World Example

Hospitals are the clearest reason SNPP still matters. Many clinical environments never fully replaced pagers, and the gateways that feed them — often SNPP on 444 — were wired into monitoring and nurse-call systems years ago and forgotten. Because level-1 SNPP takes no login, an attacker who reaches such a gateway can inject pages that look exactly like legitimate clinical alerts: a fake “code” to the wrong ward, a bogus lab result, or a message crafted to social-engineer staff. Security researchers have repeatedly shown that pager traffic — including hospital pages carrying patient names and conditions — travels unencrypted and is trivial to capture; an exposed SNPP relay adds the ability to send into that same unauthenticated channel. There’s no exotic exploit here: the port simply shouldn’t be reachable, and the fact that it accepts an anonymous SEND is both the finding and the fix.

FAQ

What is port 444 used for?

Port 444 is the registered TCP port for SNPP, the Simple Network Paging Protocol (RFC 1861) — a plain-text, SMTP-like protocol that delivers alphanumeric messages to pagers through a paging gateway. In practice you’ll also see 444 used by Microsoft Exchange’s back-end website and by some load-balancer GUIs, so an open 444 isn’t automatically SNPP.

Is port 444 dangerous?

Level-1 SNPP has no authentication and no encryption, so an exposed gateway is effectively an open, cleartext relay: anyone who can reach it can send or spoof pages and sniff message content. It’s low-severity in the abstract, but genuinely relevant where paging is still used for critical alerts, such as hospitals and industrial sites.

What service runs on port 444?

Usually an SNPP paging server — QuickPage’s snpp daemon or HylaFAX’s hfaxd with SNPP support — or a carrier/messaging paging gateway. On Windows mail servers, 444 is more often Microsoft Exchange’s back-end HTTPS listener than paging.

How do I secure or close port 444?

If paging is no longer used, stop the SNPP service and confirm 444 is closed with a rescan. If it’s still needed, require authentication, firewall the port to authorized monitoring hosts, and tunnel it over VPN/stunnel so nothing is in cleartext. If the port is actually Exchange or an appliance GUI, harden that service instead.

TL;DR

• Service: SNPP (Simple Network Paging Protocol, RFC 1861) — SMTP-like delivery of text messages to pagers
• Default port: 444/TCP (also seen as Microsoft Exchange’s back end and some appliance GUIs — fingerprint before assuming SNPP)
• Biggest risk: level-1 SNPP is unauthenticated and cleartext, so an open gateway is a relay for spoofed and sniffable pages — no dedicated CVE, the design is the exposure
• Mitigation: retire SNPP if paging is dead, else require auth, firewall 444 to known senders, and tunnel it; patch QuickPage/HylaFAX