VNC
Synopsis
Creates a decoy VNC server that emulates the RFB protocol handshake far enough to receive a client's authentication response. Every connection attempt is logged, along with the DES challenge/response pair needed to crack the client's password offline. Authentication always fails and no framebuffer is ever served.
Schema
- id: <numeric>
name: <string>
description: <string>
type: vnc
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
address: <string>
port: <numeric>
timeout: <numeric>
Configuration
The following fields are used to define the device:
Device
| Field | Required | Default | Description |
|---|---|---|---|
id | Y | Unique identifier | |
name | Y | Device name | |
description | N | - | Optional description |
type | Y | Must be vnc | |
tags | N | - | Optional tags |
pipelines | N | - | Optional pre-processor pipelines |
status | N | true | Enable/disable the device |
Connection
| Field | Required | Default | Description |
|---|---|---|---|
address | N | "0.0.0.0" | Listen address |
port | Y | Listen port. VNC display :0 is 5900. | |
timeout | N | 20 | Idle timeout in seconds |
Ingest Buffer
| Field | Required | Default | Description |
|---|---|---|---|
max_buffer_size | N | 128MB | Ingest buffer admission cap. Also sets this listener's eager heap reservation |
max_buffer_size is the ingest-buffer admission cap, and is distinct from any buffer_size field above, which sizes the network read buffer. Left unset it is 128MB, which commits 384 MiB of heap per listener worker before any data arrives — and with reuse: true a device runs one worker per listener. Size strings are binary, and 32MB and 32MiB are exact synonyms.
See Listener Memory Sizing for the arithmetic, the sizing table, and what happens when the cap is exhausted.
Details
Handshake
On connection, the honeypot announces RFB 003.008\n and reads the client's 12-byte version string, logging a connection event with the reported client_version.
The security handshake branches on the client's minor version. For version 3.7 and later, the honeypot offers a one-entry security-type list containing VNC Authentication and reads the client's chosen type. For version 3.3, the security type is not negotiated — the honeypot dictates VNC Authentication as a 4-byte big-endian value.
The honeypot then sends a cryptographically random 16-byte challenge and reads the client's 16-byte DES response, logging an auth_attempt event with the hex-encoded challenge and response. Authentication always fails: the honeypot returns a SecurityResult of 1 with the reason "Authentication failure". No framebuffer is ever served — there is no screen content behind this device.
Logged Events
Each connection produces one or both of the following event types:
event_type | Emitted when |
|---|---|
connection | The client sends its RFB protocol version |
auth_attempt | The client answers the authentication challenge |
Event Fields
Every event carries timestamp, event_type, source_ip, source_port, and local_addr. The remaining fields depend on the event type:
| Field | Description |
|---|---|
client_version | RFB protocol version string reported by the client |
auth_method | Always vnc |
challenge | 16-byte random challenge sent to the client, hex-encoded |
response | 16-byte DES response returned by the client, hex-encoded |
vnc_hash | Crackable hash assembled from the challenge and response |
Captured Hashes
vnc_hash is formatted as $vnc$*<CHALLENGE_HEX>*<RESPONSE_HEX>, directly usable with John the Ripper's vnc format.
Examples
The following are commonly used configuration types.
Basic
Minimal VNC honeypot listening on the standard display :0 port:
Creating a simple VNC honeypot... | |
Non-Standard Port
Running the honeypot on a high port so it does not require elevated privileges:
Running VNC honeypot on an unprivileged port... | |
With Pre-Processing
Routing captured events through a pipeline before they reach a target:
Attaching a pre-processing pipeline to a VNC honeypot... | |
A cracked login attempt produces an | |