# VNC Protocol Fingerprinting: How RFB Handshake Detection Works

VNC is one of the most widely deployed remote access protocols in the world, and also one of the most exposed: Forescout research counts more than 1.6 million VNC servers reachable directly from the internet, roughly 60,000 of them with authentication disabled, and more than 670 of those sitting in front of operational technology and industrial control panels. For defenders, that exposure has a useful flip side: the protocol VNC runs on, RFB (remote framebuffer), announces itself in plain text during every session setup [1]. This post walks through what the RFB handshake exposes, why it makes VNC sessions highly fingerprintable, and what that looks like in a monitoring stack.

The RFB Handshake Is a Plain-Text ID Card

Every VNC connection begins with a fixed sequence defined in RFC 6143, the protocol's specification: the server speaks first, sending a 12-byte ProtocolVersion message such as "RFB 003.008" followed by a newline [1]. The client replies with its own version string, and the two settle on the highest version both support [3]. Nothing about this exchange is encrypted, because encryption has not been negotiated yet, so the version banner is readable by anything that can see the TCP stream.

That banner alone is a fingerprint. The version numbers tell a defender which protocol generation is in play, and the security types offered alongside each generation vary by vendor [2].

Security Types: The Second Layer of the Fingerprint

After versions are exchanged, the server sends the list of security types it supports, and the client picks one [3]. The core types defined in the specification are 0 (invalid), 1 (none, meaning no authentication at all), and 2 (VNC Authentication), with vendor-specific ranges beyond that: types 3, 4, and 7 through 15 belong to RealVNC, 16 is Tight, 18 is TLS, 19 is VeNCrypt, 20 is SASL, 21 is MD5 hash authentication, 22 is xvp, and 30 through 35 are Apple's macOS security types [2]. This list is a second, richer fingerprint, because the registry is fragmented by vendor.

Where authentication is enabled, the classic VNC Authentication flow has the server send a random 16-byte challenge, which the client encrypts with DES using a key derived from the access phrase and returns. The channel carrying it is not encrypted unless a TLS-based security type was selected, and the original scheme provides limited protection [5]. For detection purposes the important part is that this exchange is structurally fixed, so session state (authentication attempted, succeeded, or failed) is observable on the wire.

ServerInit Leaks the Desktop Itself

Once security is settled and the client initializes the session, the server sends a ServerInit message containing the framebuffer width and height, the pixel format, and the desktop name, a human-readable string labeling the shared screen [1]. This is the third fingerprint layer, and it is the one that turns a protocol detection into asset intelligence. A desktop name like "PanelView VNC Server" tells you the endpoint is an industrial human-machine interface, not a workstation, before anyone logs a ticket.

What This Looks Like in a Monitoring Stack

Network monitoring tools already decode all of this. Zeek, the open source network analysis framework, ships a built-in RFB analyzer that logs every VNC session with fields for client and server major and minor versions, the authentication method, whether authentication succeeded, the shared-session flag, and the desktop name, width, and height of the shared screen [6].

In practice that means a defender can answer, directly from logs: which VNC implementations run on my network, by version banner [6]; which endpoints accept the unauthenticated "None" security type [2]; which sessions failed authentication repeatedly, a classic brute-force signal; and which industrial screens are being shared, by desktop name [6].

The port matters less than people assume. VNC's conventional port is 5900, but RFB shows up on any port, and offset configurations are common [5]. The handshake fingerprint is port-independent: the "RFB 003.008" banner identifies the protocol wherever it lives.

Why This Matters at Scale

The exposure numbers make fingerprinting operationally urgent, not academic. Forescout identified more than 670 internet-facing VNC servers with authentication disabled and direct access to OT/ICS control panels [4]. Healthcare is one of the environments where a remote desktop session can reach equipment with physical consequences.

The same telemetry that makes VNC fingerprintable for defenders is trivially collectable by anyone else. Fingerprinting is symmetric; the difference is whether anyone on your side is looking.

Hardening Takeaways

The detection story and the hardening story converge on the same points:

  • Keep VNC off the open internet: remote access protocols belong behind a gateway or VPN, a point the Forescout research makes unambiguously [4].
  • Disable the "None" security type everywhere. An authentication-disabled VNC server grants remote desktop access to anyone who connects, a configuration the Forescout research found on roughly 60,000 internet-exposed servers [4].
  • Prefer TLS-backed security types (VeNCrypt, SASL with encryption) over the legacy DES challenge, which offers limited protection [5].
  • Monitor the handshake. If you run Zeek or a comparable stack, the RFB log gives you version, authentication method, result, and desktop name per session, which is enough to baseline and alert on anomalies [6].

VNC is not going away: it is simple, cross-platform, and embedded in everything from lab machines to factory displays. But its handshake design means every session starts by declaring what it is. Defenders who read that declaration get a cheap, reliable detection signal and an asset inventory for free.