RDP
Synopsis
Creates a decoy RDP server that drives the X.224 and CredSSP/NLA handshake far enough to capture a client's NTLM credentials as a crackable Net-NTLMv2 response. Every connection is logged, along with the routing cookie and requested security protocols. Authentication always fails and no desktop is ever presented.
Schema
- id: <numeric>
name: <string>
description: <string>
type: rdp
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
address: <string>
port: <numeric>
os_flavor: <string>
tls:
cert_name: <string>
key_name: <string>
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 rdp | |
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 | |
timeout | N | 20 | Deadline in seconds for each connection, set once when the client connects. Activity does not extend it, so a session is closed this long after it opened |
Emulation
| Field | Required | Default | Description |
|---|---|---|---|
os_flavor | N | server2019 | Windows version advertised in the NTLM challenge |
Accepted values are server2012, server2012r2, server2016, server2019, and server2022. Each preset supplies the NetBIOS and DNS computer and domain names, plus the Windows version reported to the client. Scanners and client tools fingerprint the host from these, so the value determines which Windows Server build the honeypot appears to be.
An unrecognized or empty value falls back to server2019 without raising a configuration error.
TLS
| Field | Required | Default | Description |
|---|---|---|---|
tls.cert_name | N | - | Certificate name resolved from the certificate store |
tls.key_name | N* | key.pem | Key name resolved from the certificate store |
* = Read only when tls.cert_name is set.
RDP does not read a tls.status key. TLS is unconditional — Network Level Authentication requires it — so a tls.status key in an RDP device configuration is silently ignored, including when set to false. When tls.cert_name is empty, a self-signed certificate is generated on each start; a non-empty tls.cert_name that cannot be resolved stops the device from starting.
Ingest Buffer
| Field | Required | Default | Description |
|---|---|---|---|
max_buffer_size | N | 128MB | Ingest buffer admission cap. Also sizes this listener's ingest buffers: 3/8 of this value at start, growing to at most 3x |
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, whose buffers take 48 MiB of heap per listener worker at start and grow to at most 384 MiB as bursts need the room — 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
The honeypot reads the client's TPKT/X.224 Connection Request, parsing the mstshash= routing cookie and the requested-protocols bitmask, and logs a connection event. If the client does not offer HYBRID (NLA), the honeypot sends a Connection Confirm selecting SSL when offered, or plain RDP, and stops the connection there — no credential exchange takes place.
When the client offers HYBRID, the honeypot confirms it, upgrades the connection to TLS, and runs CredSSP: it reads the TSRequest carrying the client's NTLM NEGOTIATE message, replies with a CHALLENGE advertising the os_flavor preset's computer name, domain name, and Windows version, then reads the AUTHENTICATE message and captures the credential. The connection is then closed, which a brute-forcer reads as an authentication failure. No desktop, graphics channel, or screen content is ever served.
Logged Events
Each connection produces one or both of the following event types:
event_type | Emitted when |
|---|---|
connection | The client sends its X.224 Connection Request |
auth_attempt | The client completes the CredSSP/NTLM exchange after negotiating HYBRID (NLA) |
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 |
|---|---|
cookie_user | Username from the client's mstshash= routing cookie |
requested_protocols | Security protocols offered in the Connection Request: RDP, SSL, HYBRID, HYBRID_EX |
username | Username captured from the NTLM AUTHENTICATE message |
domain | NTLM domain captured from the AUTHENTICATE message |
workstation | NTLM workstation name captured from the AUTHENTICATE message |
auth_method | Always ntlm |
netntlmv2 | Crackable Net-NTLMv2 response captured from the AUTHENTICATE message |
os_flavor | Configured os_flavor preset for the session |
Captured Hashes
netntlmv2 is a hashcat -m 5600 Net-NTLMv2 string.
Examples
The following are commonly used configuration types.
Basic
Creating a minimal RDP honeypot on the standard port... | |
Operator Certificate
Presenting an operator-supplied certificate during NLA instead of a self-signed one... | |
With Pre-Processing
Routing captured attempts through a pre-processing pipeline before ingestion... | |
A completed NLA exchange is logged with the captured Net-NTLMv2 response before pipeline processing... | |