Port 666 – DOOM (Doom Game Protocol)

Port 666 is the registered port for DOOM, id Software’s 1993 multiplayer first-person shooter. IANA assigns both TCP and UDP 666 to the service name doom, a holdover from the era when DOOM and matchmaking services like DWANGO helped invent online deathmatch. In practice the original game leaned on IPX/SPX and serial/modem links for its networking, so the TCP/IP assignment was never heavily used — and today’s Doom source ports (Zandronum, ZDaemon, Odamex) default to UDP 10666, not 666. That makes an open port 666 in the wild almost never an actual Doom server. Because the number is memorable — the “number of the beast” — it has been squatted for decades by backdoors, trojans, and deliberately provocative services, so the real job when you find 666 open is to identify what is actually listening.

Why It’s Open

• Legacy IANA assignment. The doom label lingers in port databases and the occasional firewall rule set, so tools still recognise 666 by name even though the game protocol is effectively dead.
• Novelty and lab use. Admins, honeypot operators, and CTF authors pick 666 precisely because it’s memorable — it shows up on hobby boxes and training machines (VulnHub’s “Temple of Doom” being a well-known example).
• Backdoor/trojan squatting. Historic Windows/DOS-era trojans defaulted to 666, so a copy-pasted or leftover backdoor can still land there.
• Not modern multiplayer. Real Doom multiplayer today runs on UDP 10666 (Zandronum, ZDaemon, Odamex), so genuine game traffic almost never touches 666.

Common Risks

• Unknown, unauthenticated service. The biggest risk on 666 is simply not knowing what it is. An open, unidentified listener on a memorable port deserves immediate fingerprinting rather than a shrug.
• Backdoor / C2 default. Port 666 appears on classic trojan-port references — Attack FTP, Back Construction, Cain & Abel, Satanz Backdoor, ServeU, Shadow Phyre — the same “memorable number” pattern as NetBus on 12345 and Back Orifice on 31337. These are legacy, but the default occasionally resurfaces.
• Provocative custom apps. Because of the symbolic number, 666 is a favourite for shock-value or “look at me” services — some benign, some genuinely malicious, and it’s the same instinct that makes 4444 (the Metasploit handler default) worth a second look.
• No transport security. Whether it’s a game/link service or a hand-rolled app, expect no encryption or authentication on 666.
• False attribution. A stray doom label in scan output can lull you into ignoring a real backdoor. Never trust the label — verify the service.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect and fingerprint the service

nmap -sV -p 666 <target>

Nmap may print doom from its service database — treat that as a guess from the port number, not a verified protocol. There is no dedicated Doom/666 NSE script or Metasploit module; the entire task is identifying whatever actually answers.

Raw banner grab

nc -nv <target> 666

A raw connect proves the port is open and often reveals a banner, prompt, or shell-like response that gives away a backdoor or custom app. Try both TCP and UDP (nmap -sU -p 666 <target>), since the assignment covers both.

Wider context

nmap -A -p 666 <target>

Pull OS, script, and traceroute context so you can correlate 666 with everything else the host exposes — a trojan default rarely sits alone.

Log every open instance and whatever you fingerprint so it lands in the final pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

• No protocol-specific CVEs. There are essentially no CVEs for the DOOM multiplayer protocol or for “port 666” as a network service — it was never a widely deployed listening daemon. The classic DOOM engine bugs that do exist (demo, WAD, and savegame parsing overflows in source ports) are client-side file-parsing issues, not something you attack across an open port 666.
• Old page CVE removed. A previous version of this page cited CVE-1999-0710 as a “Doom protocol buffer overflow.” That CVE is actually a Squid proxy cachemgr.cgi issue on Red Hat Linux, unrelated to Doom or port 666 — it has been removed.
• The real exposure is the unknown service. Treat an open 666 as “identify this listener,” then apply whatever CVE and exploit research matches the software you actually find — a backdoor, a web app, an admin panel — rather than a Doom-specific bug.

Mitigation

• Identify what’s really on 666 first. Fingerprint the service before anything else. If it isn’t something you deliberately configured, treat it as suspicious.
• Close it if it isn’t sanctioned. There’s no reason to expose 666 on a modern host — block it at the firewall and stop the listener.
• Don’t run services on memorable or provocative ports. If you must host something real (including a Doom source port), use its documented port — UDP 10666 for Zandronum/ZDaemon/Odamex — not 666.
• Hunt for backdoors. An unexplained 666 listener is an incident-response trigger: check the process and its parent, autostart entries, and outbound connections. A host with a trojan default port open may already be compromised.
• Monitor and alert. Add 666 to IDS and egress rules so any new listener or C2-style traffic is flagged early.

Real-World Example

Port 666’s notoriety is cultural, not exploit-driven. It’s a recurring pick in CTF and training labs precisely because of the number — VulnHub’s “Temple of Doom” box is a well-known walkthrough where port scanning is the opening move — and the memorable-number motif shows up across practice machines. In the real world the pattern is subtler: a scan turns up 666 open, the operator thinks “oh, that’s just Doom,” and moves on, when the listener is actually a leftover backdoor or an undocumented custom service. That folklore is the vulnerability. Port 666 has been squatted by trojans (Attack FTP, Satanz Backdoor, Back Construction, and friends) since the late 1990s, and the doom label is a distraction — every time, the fix is to identify the service rather than trust the name.

FAQ

What is port 666 used for?

Port 666 is the IANA-registered port for doom, id Software’s DOOM multiplayer game, on both TCP and UDP. It dates to the mid-1990s birth of online first-person shooters. It sees almost no legitimate use today — modern Doom source ports use UDP 10666 — so an open 666 is far more likely to be a backdoor, a custom service, or a novelty listener than a real game server.

Does Doom still use port 666?

Not in any meaningful way. The original DOOM mostly networked over IPX/SPX and serial/modem links, and today’s popular source ports — Zandronum, ZDaemon, Odamex — default to UDP 10666, not 666. The 666 assignment survives only as a historical IANA registration.

What service runs on port 666?

Officially doom. Realistically, anything: because 666 is a memorable “number of the beast,” it has been the default of numerous legacy trojans (Attack FTP, Satanz Backdoor, Back Construction, ServeU, Shadow Phyre) and is a popular pick for hand-rolled or provocative services. Always fingerprint the listener instead of trusting the port label.

Is port 666 dangerous?

The port isn’t dangerous by itself — what’s dangerous is an unidentified service on it. An open 666 that you didn’t deliberately configure should be treated as a potential backdoor or unauthorised app until you’ve confirmed exactly what’s listening.

How do I secure or close port 666?

Identify the service first, then shut it down if it isn’t sanctioned: stop the process, block 666 at the firewall, and investigate the host for compromise if the listener is unexplained. If you legitimately run a Doom source port, move it to its documented port (UDP 10666). Rescan to confirm 666 no longer answers.

TL;DR

• Service: doom — id Software’s DOOM multiplayer protocol (IANA-registered, largely historical)
• Default port: 666/TCP and 666/UDP (modern Doom source ports use UDP 10666, not 666)
• Biggest risk: an open 666 is rarely a real game server — it’s more likely a legacy trojan default, a custom service, or a novelty listener, so the finding is “identify the unknown service”
• Mitigation: fingerprint what’s actually on 666, close it if it isn’t sanctioned, avoid memorable/provocative ports, and treat an unexplained listener as an IR trigger