RDP Honeypot Deployed: Credential Harvesting and Client Fingerprinting Across NLA and Legacy Connections

RDP brute-force is one of the most common attack vectors on the internet. It's been the initial access method behind ransomware campaigns, lateral movement toolkits, and credential-stuffing botnets for years. Until now, our sensor network didn't have direct visibility into it.

That changes today. Every sensor in SikkerAPI's global honeypot network now runs an RDP honeypot alongside the existing 16 protocol traps. It captures credential attempts, NTLM authentication exchanges, client fingerprint data, and protocol negotiation details, then feeds everything into the same IP reputation scoring engine that powers our API.

This brings the total protocol count to 17 across dozen sensors world-wide.

What the RDP Honeypot Captures

Our RDP implementation isn't a port listener that logs connection attempts. It implements the full RDP negotiation stack: X.224 connection requests, TLS upgrade, and CredSSP authentication with NTLM challenge-response. To the connecting client, it looks and behaves like a real Windows Remote Desktop server.

Here's what gets recorded from every connection:

Credentials and Authentication

• Username and password — plaintext, extracted from the NTLM authentication exchange
• NTLM hash — the NTLMv2 response, useful for identifying credential reuse across sessions
• Domain — the Windows domain the attacker claims to belong to
• Workstation name — the NTLM workstation field, often revealing the attacker's machine name
• Auth type — whether the client used NLA (Network Level Authentication) or legacy RDP security

Every credential attempt is a separate recorded event with its own timestamp, so multi-attempt brute-force sessions are captured as full sequences.

Client Fingerprinting

After accepting authentication, the sensor reads the client's MCS Connect Initial PDU, the message where RDP clients describe themselves to the server. This contains:

• Client name — the connecting machine's hostname
• Client build number — identifies the exact Windows version and patch level
• Desktop resolution — requested width, height, and color depth
• Keyboard layout — locale identifier (e.g., 0x00000409 for US English, 0x00000407 for German)
• Keyboard type — hardware keyboard classification
• Virtual channels — the list of RDP channels the client requests (clipboard redirection, drive mapping, audio, smart card, etc.)
• TLS version — the negotiated TLS protocol version

This fingerprint data is valuable beyond individual session analysis. Across thousands of connections, patterns emerge: botnets share identical client builds and keyboard layouts. A credential-stuffing campaign from 500 IPs that all report the same client name and desktop resolution is one operator with one tool. The channel list alone distinguishes legitimate RDP clients (which request cliprdr, rdpdr, rdpsnd) from attack tools (which often request none or a minimal set).

How RDP Authentication Actually Works

Modern RDP connections use Network Level Authentication (NLA), which wraps NTLM or Kerberos inside CredSSP, which itself runs over TLS. The connection sequence looks like this:

Client                              Honeypot
  │                                    │
  │─── X.224 Connection Request ──────▶│  (includes requested protocols)
  │◀── X.224 Connection Confirm ───────│  (selects NLA/CredSSP)
  │                                    │
  │─── TLS Handshake ────────────────▶│
  │◀── TLS Established ───────────────│
  │                                    │
  │─── CredSSP: NTLM Negotiate ──────▶│  (client starts NTLM)
  │◀── CredSSP: NTLM Challenge ───────│  (server sends challenge)
  │─── CredSSP: NTLM Authenticate ───▶│  (credentials here)
  │◀── CredSSP: Auth Success ─────────│
  │                                    │
  │─── MCS Connect Initial ──────────▶│  (client fingerprint here)
  │                                    │
  │              ✕ Connection closed    │

Our implementation accepts the authentication, reads the MCS Connect Initial to extract the client fingerprint, then terminates the connection. The session lasts a few hundred milliseconds longer than a rejection would, but it captures significantly more intelligence per connection.

Legacy clients that don't use NLA follow a different path, they send MCS Connect Initial before authentication. The honeypot handles both flows, capturing the same data regardless of which negotiation path the client takes.

Behavioral Analysis

RDP events feed into the same two-tier detection system that analyzes all other protocols:

Primitives match individual event fields. An RDP primitive might fire on a specific username pattern (like administrator, sa, or support), a known-bad NTLM hash, or a workstation name associated with a known attack tool.

What This Adds to IP Reputation

Before RDP, our sensors captured 16 protocols worth of attacker behavior. Adding RDP means:

• IPs doing RDP brute-force are now scored directly, previously, an IP that only attacked RDP would be invisible unless it also hit SSH, HTTP, or another monitored protocol
• Cross-protocol correlation gets stronger, an IP that brute-forces both SSH and RDP in the same hour is a different threat than one that only does SSH. The additional signal improves confidence scoring
• NTLM hashes enable credential reuse detection, the same NTLMv2 response appearing from different IPs indicates shared tooling or a coordinated campaign
• Client fingerprinting identifies tool clusters, grouping IPs by their RDP client fingerprint reveals botnets and campaigns that would otherwise look like unrelated scanners

All of this feeds into the IP reputation API, blacklist downloads, and STIX/TAXII feed automatically.

Protocol Coverage: 17 and Counting

The full sensor protocol list is now:

RDP fills the last major gap in remote access coverage. SSH, Telnet, and RDP together cover the three most brute-forced remote administration protocols on the internet.

Explore the Data

RDP attack data is already flowing into the threat database. Look up any IP at https://sikkerapi.com to see if it's been observed attacking RDP alongside other protocols. For automated protection, install SikkerGuard — it blocks malicious IPs at the firewall level, now including IPs identified through RDP brute-force.

Browse real-time attack activity across all 17 protocols on the threat landscape page, or explore specific RDP threat data at /threats/protocol/rdp.

API documentation: sikkerapi.com/docs