VNC Authentication (security type 2) is a challenge-response: the server sends a 16-byte challenge and the client returns a DES-based response derived from the password. In classic compatible implementations, only the first eight password bytes are significant. Online guessing submits candidates to the server and is subject to its delay, rejection, and logging behavior. A captured challenge-response pair permits candidates to be tested offline, avoiding further server interaction, but it does not guarantee quick recovery: cost depends on password choice, candidate strategy, character set, and available hardware.
# online brute force
nmap -p5900 --script vnc-brute --script-args passdb=rockyou.txt <target>
hydra -P rockyou.txt vnc://<target>
# offline: capture the challenge + response (sniff/MITM), then crack
# VNC auth is a known DES-challenge format; feed challenge+response to a cracker
# prioritize evidence-based candidate lists; exhaustive recovery may remain costly
Exploitation notes#
- In compatible implementations, bytes after the eighth do not strengthen VNC Authentication, but an eight-byte maximum does not make every possible password easy to recover.
- Offline candidate testing avoids server-side throttling and additional authentication logs; recovery speed still depends on the candidate space. See cleartext transmission for transport context.
- Online brute force works where you cannot capture, but VNC servers may limit or delay attempts; keep lists short given the 8-char cap.
- Test recovered credentials only where reuse is in scope; reuse across endpoints is an operational possibility, not a protocol property.