85

Port 85/tcp is registered with IANA as mit-ml-dev with the description "MIT ML Device," assignee and contact both listed as [David_Reed], and a blank reference field (dual-registered on TCP and UDP). The IANA Reference, Registration Date, and Modification Date columns are all blank in the registry — no RFC or other formal standard is cited, and the assignment traces to the early MIT AI Lab "ML Device" lineage rather than any published protocol. For all practical purposes the official registration is defunct: no modern software speaks an "MIT ML Device" protocol on this port. What actually drives traffic on 85/tcp today is an unrelated, de-facto use: it is a common alternative HTTP port for the embedded web management interface on low-cost DVRs and IP cameras built on the Xiongmai (XMeye / NetSurveillance) firmware stack, where embedded servers such as GoAhead and uc-httpd serve the device admin UI on TCP/85 when port 80 is taken or blocked. Because many rebranded H.264 DVR vendors ship the same firmware, the same port turns up across a large installed base. That installed base is the reason port 85 sees persistent background scanning, tracked by the SANS Internet Storm Center (low/green threat level as of June 2026): IoT botnets in the Mirai/Gafgyt family probe TCP/85 for these devices and try default credentials (commonly admin with a blank or trivial password) against the unauthenticated uc-httpd interface. Devices are findable on Shodan by the uc-httpd banner; Pen Test Partners indexed on the order of 720,000 such devices in 2017. No CVE is keyed to port 85 alone — the risk is tied to the device software stack, not the port number — so for an analyst a responsive 85/tcp on the public internet most often means an exposed Xiongmai-class camera/DVR admin panel rather than anything resembling the registered MIT ML Device.

IANA assignment

mit-ml-dev — "MIT ML Device"; reference (blank — no RFC cited in IANA registry); assignee and contact both [David_Reed]; dual-registered 85/tcp + 85/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry, lines 238–239)

Registration / modification date

blank in the IANA registry (not recorded) [Confirmed] — IANA registry CSV

Range class

well-known (0–1023)

Prevalence / exposure

persistent background scanning tracked by SANS ISC (threat level green/low as of June 2026); large installed base of Xiongmai-stack devices; ~720,000 uc-httpd devices indexed on Shodan as of 2017 (Pen Test Partners) [Confirmed] — https://isc.sans.edu/data/port/85, https://www.pentestpartners.com/security-blog/what-did-mirai-miss-making-a-better-bigger-botnet/

Related ports

80/8080 (HTTP alternatives), 81/tcp (also seen on uc-httpd devices), 9527/tcp (Xiongmai debug console)

Other/unofficial use

de-facto alternative HTTP port for embedded web admin UIs on Xiongmai (XMeye / NetSurveillance) firmware DVRs and IP cameras, served by GoAhead / uc-httpd embedded web servers

Security implications

Mirai/Gafgyt-class IoT botnets probe TCP/85 for Xiongmai devices, exploiting default credentials (e.g., admin/blank, admin/123456) and uc-httpd weaknesses; the broader Xiongmai surface includes a default-on XMEye P2P cloud feature and a debug console on TCP/9527, but 85/tcp is specifically the HTTP management surface. No CVE is keyed to port 85 alone — risk follows the software stack, not the port. [Confirmed/Threat-reported] — https://internet-security.com/ports/port-85-TCP.html, https://sec-consult.com/blog/detail/millions-of-xiongmai-video-surveillance-devices-can-be-hacked-via-cloud-feature-xmeye-p2p-cloud/

Typically seen on

low-cost Chinese-manufactured DVRs / IP cameras (Xiongmai-based, rebranded by many vendors); rarely anything matching the registered MIT ML Device

Primary (registered) use

MIT ML Device — a legacy MIT AI Lab assignment with no associated RFC; essentially defunct in modern networks [Likely] — IANA registry; https://isc.sans.edu/data/port/85

Analyst note

A responsive 85/tcp on the public internet is most often an exposed Xiongmai-class camera/DVR admin panel, not the registered MIT ML Device — treat as an IoT exposure to inventory and harden, not a benign legacy service.

Port 85/udp is registered with IANA as mit-ml-dev, described as "MIT ML Device," with assignee and contact listed as [David_Reed] and blank registration-date, modification-date, and reference columns. The identical service name is registered on 85/tcp (the registry's preceding row), so this is a dual TCP/UDP assignment under one name. The label points to the MIT Lisp Machine / AI Lab lineage of the early system-port range: "ML" reads as Lisp Machine ("Machine Lisp" / MIT Lisp Machine), and the entry is a vestige of that era rather than a live, governed protocol. No RFC or standards document is cited in the IANA registry, and the reference field is genuinely blank — not omitted here, simply absent from the source. There is no documented active UDP protocol that uses 85/udp today; in practice the assignment is historical. Notably, the security and deployment activity associated with "port 85" is almost entirely on the TCP side: 85/tcp appears as an alternate web-interface port on Xiongmai-firmware DVRs and IP cameras, and those devices are targeted by Mirai/Gafgyt-class IoT botnets via default credentials — but that is HTTP-over-TCP exploitation and does not transfer to the connectionless UDP port. One source (auditmypc.com) notes an unattributed, undated historical Trojan use of the port without flagging any current active threat, which we treat as Likely/unconfirmed. Because UDP carries no handshake and no known protocol drives 85/udp, an open socket here is hard to fingerprint remotely and is most plausibly a misconfiguration or legacy artifact rather than a real service. For an analyst, a responsive 85/udp is statistically unusual and worth investigating rather than assuming a standard service.

IANA assignment

mit-ml-dev — "MIT ML Device"; assignee/contact [David_Reed]; registration date, modification date, and reference all blank in the registry; dual-registered 85/tcp + 85/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry line 239; 85/tcp on line 238)

Range class

well-known / system (0–1023) [Confirmed]

IANA reference

(blank — no RFC cited in registry) [Confirmed] — IANA registry

Related ports

85/tcp (identical mit-ml-dev registration; where real-world activity concentrates)

Primary use

legacy MIT Lisp Machine / AI Lab system-port assignment; no governing RFC and no documented active UDP protocol

Common software

no known software actively uses 85/udp as its primary transport; the TCP counterpart (85/tcp) is seen as an alternate web-interface port on Xiongmai-firmware DVRs/IP cameras, but that is a TCP HTTP use, not UDP

Security implications

no active malware/botnet campaign specifically targets 85/udp in available sources; auditmypc notes an undated/unattributed historical Trojan use with no current threat flagged; the real port-85 security story (Mirai/Gafgyt scanning Xiongmai DVR/camera web interfaces via default creds) is on 85/tcp and does not apply to UDP

Exposure

essentially no legitimate internet-facing 85/udp services are known; open exposure is likely misconfiguration or a legacy artifact, and a connectionless UDP socket with no known protocol is hard to fingerprint remotely

Analyst note

A responsive 85/udp is statistically unusual; treat as a misconfiguration, legacy artifact, or anomaly to investigate rather than a standard service.