220 mssante.elsan.care MSSPRO LPS AUTH_CLI submission server 501 2.7.0 Error: I can break rules, too. Goodbye.

Weird...

The rest of the router logins look the same as they would on port 80. A D-Link DSL-2740B (37.103.36.12 and two others), with "admin" already filled in as the username: two in French at Orange and Nerim in France, one in English at Wind Tre in Italy. A Linksys "Router Access" page in El Salvador (200.31.162.80). A plain "Sign in" form titled "Router Admin" on seven cloud servers: four at Hetzner, two at Online SAS, one at DigitalOcean.

One didn't bother with a login at all. A 3G/4G "Wireless Mobile Router" on China Unicom (183.93.33.155) serves its full status page on port 0 to anyone who asks: its WAN IP, LAN, WAN and wireless MAC addresses, SSID, firmware build, uptime, memory usage and whether DHCP is on.

Browsers won't open a URL with :0 in it, so to see the web interfaces I ran a small relay: listen on a local port, connect out to the target on port 0, pipe the bytes through, and point headless Chromium at the local port. 160 addresses speak HTTP on port 0, and 85 rendered a page.

A Gira HomeServer 4 (46.186.48.86), a KNX home and building automation controller, with its start page, debug page and monitor links sitting on port 0.

A Trane Tracer Synchrony login (201.171.202.25), which is HVAC and building control.

The web pages were the easy part to read. The more interesting devices don't speak HTTP. They send binary the moment you connect, and figuring out what they are meant matching bytes against nmap's probe database, Wireshark dissectors and, in one case, a disassembled vendor client.

A Beckhoff PLC with its screen open to anyone. 46.178.29.102, on Proximus in Belgium, sends this on connect:

30 01 00 00 05 6d 6d 6a 56 05 00 00 00 03 00 00 ... "CBx063" ... "CX5120" ...

The CX5120 is a Beckhoff embedded PC running Windows CE, the kind that runs TwinCAT and drives a machine. The protocol is CERDISP, Windows CE Remote Display, which Beckhoff's own security guideline lists as open on TCP 987 by default. I disassembled Beckhoff's client, CERHOST.exe 2.0.4.0. It reads a 0x130-byte info block first, which is the 30 01 00 00 at the start of the banner. Then it checks a magic word: 0x6a6d6d05 means no password, 0x6a6d6d06 means password required. This one sends 05 6d 6d 6a. Then a 1366×768 resolution (56 05, 00 03) and screen update data. CERHOST also sends mouse and keyboard input. So this is a PLC's screen that anyone can watch and operate, with no password, on port 0.

An Omron PLC that was too busy to talk. 194.49.59.232 (AireNetworks, Spain) answered with an Omron FINS/TCP frame:

46 49 4e 53 00 00 00 10 00 00 00 01 00 00 00 20 00 00 00 00 00 00 00 66 F I N S length=16 cmd=1 error=0x20 server node 0x66

Command 1 is the server's Node Address Data Send, and error code 0x20 is "All connections are in use." It is a FINS endpoint, the protocol used to read and write Omron PLC memory, and it turned us away only because its connection slots were full. Five days later it said the same thing. A second host, 14.49.206.64 (KT, Korea), repeats an Omron Host Link frame, @FFF07F000000018C3D*, over and over. The XOR of everything before 3D is 0x3D, so the checksum is valid, but unit FF is outside the normal 00–31 range. The framing is Omron. The device behind it I couldn't pin down.

A Modbus master. 155.93.146.109 (South Africa) doesn't wait to be polled. It polls you: 10 04 00 00 00 02 72 8a is slave 16, Read Input Registers 0–1, with a valid CRC-16/MODBUS. Something out there is a SCADA master on port 0 asking whoever connects for two registers. Another host, 85.198.27.114 (Iran), repeats a 7e-framed 7-byte payload with a valid Modbus CRC, which looks like a serial-to-TCP bridge.

A power quality meter. 166.169.193.134 on Verizon Wireless answers telnet with SEL-735 Telnet Server. The SEL-735 is a Schweitzer Engineering Laboratories revenue and power quality meter, the kind utilities put on substations and feeders. This one is on a cellular modem.

Factory telemetry. 175.202.128.103 (KT, Korea) sends an HTTP POST at whoever connects:

POST /highnet/v1/POST/MachineStatus?StationCode=20209263 HTTP/1.0 host: 52.83.191.199 User-Agent: uIP/1.0 (http://www.kq-china.net/) Data={"StationCode":"20209263","PickCard":[{"PickCardCode":"21032380","StartTime":"2026-10-7 10:3:41","MachineStatus":"0",...

kq-china.net is Zhejiang Keqiang Intelligent Control, which makes monitoring systems for injection moulding machines. uIP is Adam Dunkels' tiny embedded TCP/IP stack. A collector on a factory floor is pushing per-machine status to whoever connects, and masscan, confused, filed it as Minecraft.

A Swedish alarm. 82.183.26.214 (Telenor, Sweden) sends an STX/ETX frame containing "Kommunikationslarm medelvärde", Swedish for "communication alarm, mean value." I don't know the device.

Burglar alarm communicators. Five hosts, three in Mexico and two in Spain, send a greeting of about 56 bytes, with a 2-byte length prefix up front. That matches the README of DSC-TLink, a reverse-engineered client for DSC's alarm communicators: "opening a TCP connection with the TL280 on port 3062. The TL280 will immediately send a packet of 56 bytes." The TL280 family is the IP/cellular communicator on DSC PowerSeries Neo alarm panels, and this is the DLS path used to program and monitor the panel. Here's 213.181.95.33:

00 37 01 00 00 7e 00 30 e0 05 05 05 05 00 27 03 2b 54 03 00 02 0a 89 34 04 26 21 05 05 04 41 9f 03 00 00 50 03 02 01 03 00 00 02 04 05 06 00 03 4f 62 06 0e ea 79 06 6a 7f

(The 0a before the ICCID came out of the scan as 20, because our banner storage squashed whitespace bytes into spaces. I put it back.) The CRC-16 over the 42 bytes starting at 05 05 05 00 27 (polynomial 0xD003, from DSC-TLink's DLSProNetHeader.cs) comes out 0xea79, which is the ea 79 that follows. The MAC starts 00:03:4F, the IEEE OUI for Sur-Gard Security, DSC's receiver brand. And the device ID field on the cellular models is the SIM card's ICCID:

All three ICCIDs pass the Luhn check, and their prefixes say where the SIMs are from: 89 34 is Spain, 89 52 is Mexico. According to DSC-TLink, the AES key for the rest of the session is built from data in this greeting.

Alarm communicators that tell you the password. Three Spanish hosts, 109.167.87.236, 85.87.152.80 and 88.3.213.39, run telnet on an Alwon E20, a Notifier/Honeywell IP/GPRS alarm communicator module:

Alwon E20 Telnet Input password (defaul 1234):

Notifier's manual agrees: telnet password, "1234 por defecto." I didn't try it.

Time clocks. 187.235.160.47 and one other host at UNINET in Mexico repeat a5 00 00 00 00 7f 00 00 e0 5c. That's an Anviz time-and-attendance frame: a5, a 4-byte device ID of 0, command 7f, zero length, and a CRC-16/MCRF4XX of 0x5ce0 sent low byte first. Open-source Anviz SDKs call 0x7f a ping.

Home automation. Five hosts answer *#*1##, the OpenWebNet ACK used by BTicino and Legrand home automation gateways: 190.113.106.159 (Costa Rica), 171.242.179.164 (Vietnam), 187.145.124.63 (Mexico), 105.157.199.125 (Morocco) and 213.7.222.134 (Cyprus). 219.241.160.119 in Korea is a SiHAS HCM-300 Ver 2.12 > prompt, a Shina System smart heating thermostat. And 192.119.63.143 (wilhelm.tel, Germany) is a mediola a.i.o. Gateway that sends its encrypted cloud request to whoever connects: POST /ra/d HTTP/1.1 host: mediola-ws.elasticbeanstalk.com.

A debug menu. Three hosts on SK Telecom in Korea, 42.42.150.116, 42.42.203.12 and 42.42.201.80, greet you with this:

##################################

DEBUG LOGIN!!

F/W Version : EBH0920.0

Dev ID : ldg4839

IP : 192.168.225.100

##################################

MENU DISPLAY

l : Log On/Off. n : NTP Query. d : DNS Query. i : SysEnv Informaton. t : Time Display. s : Server Data Send. h : Menu Display.

192.168.225.x is the default subnet on Qualcomm LTE modules like the Quectel EC2x, so it's probably a cellular IoT device. Which product, I don't know.

A power strip. 64.201.180.254 (Gatewest, Canada) runs a Remote Power Controller v1.41i that prints its whole outlet table, circuit, name, status and boot delay, before asking for a login. Others ask only for a password but label themselves first: MGTN CO - Right Rack - Bottom, Power Switch, 151 Front Street.

SAProuters leaking their build. Four hosts are SAProuter, the SAP gateway that relays connections into SAP systems. They accepted the connection, waited 5 seconds for a route request that never came, and then sent back an NI_RTERR error packet with a lot of detail:

NI_RTERR ... ERR connection timed out -5 NI (network interface) 754 40 D:/depot/bas/754_REL/src/base/ni/nirout.cpp 8213 RTPENDLIST::timeoutPend: no route received within 5s (CONNECTED) Tue Oct 6 10:56:27 2026 ... SAProuter 40.4 on 'ADSJ'

IPISPKernelBuild pathHostname 37.61.221.36velia.net, DE754D:/depot/bas/754_REL/.../nirout.cppADSJ 37.61.219.146velia.net, DE753/bas/753_REL/.../nirout.cpphsaprouter 60.16.63.41China Unicom, CN745D:/depot/bas/745_REL/.../nirout.cpprbjsaprouter 154.236.187.38Etisalat Misr, EG753/bas/753_REL/.../nirout.cppba-srt

Every one gives away the SAProuter version (40.4), the SAP kernel release, the router's hostname, the server's local clock, and whether it's a Windows build (D:/) or not.

RustDesk. Four hosts, 93.118.140.111, 78.38.90.162 (Iran), 39.48.42.201 and 103.213.111.82 (Pakistan), open with HJ. That isn't a magic string. In RustDesk's bytes_codec.rs, the low two bits of the first byte give the header size and the rest gives the length, so 0x48 means an 18-byte message follows. 0x4a is protobuf field 9, Hash, which carries a salt and a challenge:

48 | 4a 10 | 0a 06 "usjk79" | 12 06 "zrktdr" len Hash salt challenge

The salt stays the same per host. The challenge is six random characters, new on every connection. That's the password challenge a RustDesk client answers before it gets the desktop. 103.213.111.82 sends a 32-character salt, which is what newer versions use.

Winflector. Eight hosts run Winflector, a Polish remote application server. 193.32.180.51 sends Terminal client version too old - please update to version 4.0.0.1 and then an RSA public key in DER form, with exponent 17, which is Crypto++'s default. The versions are sent byte-reversed: 04 03 00 04 is 4.0.3.4. All six versions I saw are on Winflector's own version list. The hosts are in Cape Verde (156.238.40.243, 156.238.47.54 and one more), Malaysia (202.187.2.203 and one more), Poland (193.32.180.51), Ghana (80.87.66.51) and India (49.204.146.227).

VNC with no password. Of the 39 VNC servers, one doesn't ask for anything. 107.174.67.223 answers with security type none and a desktop name of resolv.moe, meow meow meow :3 haiiii!!, and an 850×591 framebuffer. Four more just send RFB 005.000.

Phone switches. 117.236.74.58 (BSNL, India) is Asterisk Call Manager/2.10.5, the Asterisk Manager Interface from Asterisk 13.26–13.34. Once logged in, AMI can originate calls and run console commands. 38.229.159.25 (France) and 41.60.171.20 (Liquid) send 04 00 fb ff LAPK, the 3CX tunnel protocol.

Cameras and NAS. exacqVision video surveillance servers on 8 hosts, including two at OneCleveland (204.156.216.130 and 204.156.198.238), send a 56-byte header ending in three values that change on every connection. Six QNAP NAS boxes expose RTRR (Realtime Remote Replication, ab ca a5 5d ...), on 202.184.138.61 in Malaysia and five others in Austria, Sri Lanka, Spain and Italy. Two Rifatron DVRs send RIFA, 42.200.149.78 in Hong Kong and 14.241.231.170 in Vietnam. One more is a UMS WebViewer DVR stream in Japan (123.242.213.10).

The rest of the RPC zoo. 223.76.20.55 (China Mobile) is ZeroC Ice, IceP 1.0 Validate Connection. 191.13.74.178 (Telefonica, Brazil) sends just ac ed 00 05, the header of a Java serialization stream, and then nothing else. 119.152.239.20 (Pakistan) sends a bare HTTP/2 SETTINGS frame with the same bytes as a default grpc-g