# T-Pot Honeypot Analysis Report: RDP Scanning & Brute-Force Activity

**Prepared:** 2026-08-21
**System:** T-Pot honeypot deployment (rdphoneypot service, RDP/3389)
**Audience:** Student review / presentation material

---

## 1. Summary

The RDP honeypot (`rdphoneypot`, listening on port 3389) is by far the most active
service on this T-Pot deployment. Since the log retention window began
(2026-07-27), it has recorded **761,821 connection attempts** from **1,192 distinct
source IPs**, dwarfing every other honeypot service in raw volume. This report
analyzes that traffic to characterize who is scanning, how they behave, and what
that reveals about modern RDP-targeting tooling.

## 2. Investigation Method

Log data was analyzed directly from the host filesystem (current and rotated/
gzip-compressed logs) at:

```
tpotce/data/rdphoneypot/log/rdphoneypot.json*
```

Analysis steps:
1. Aggregate `rdphoneypot.session.connect` / `.session.closed` / `.login` events
   across all log rotations (plaintext, dated, and `.gz` files).
2. Break down connection volume by day to identify trends.
3. Identify the most active source IPs and look up their network ownership via
   public RDAP (WHOIS) records.
4. Extract and tally usernames submitted during NTLM/NLA authentication attempts.
5. Examine session duration distribution to distinguish automated scanning from
   interactive attempts.
6. Review protocol-level fields (`hostname`, `domain`, `auth_method`) for any
   client-side information leakage.

## 3. Findings

### 3.1 Volume overview

| Metric | Value |
|---|---|
| Total connection attempts | 761,821 |
| Total login/credential attempts | 559,309 |
| Distinct source IPs | 1,192 |
| Observation window | 2026-07-27 → 2026-08-21 (26 days) |
| Peak single day | 2026-08-05 (81,626 hits) |

Daily volume rose sharply from under 3,000/day in late July to tens of thousands
per day by early August, with sustained high activity (10,000–80,000/day)
throughout the observation period. This is orders of magnitude higher than any
other honeypot service on this deployment (e.g., the FTP honeypot's largest
single-IP campaign totaled ~160,000 attempts over 4 days — see the companion
report on `45.61.170.83`).

### 3.2 Top offending source IPs

| Source IP | Hits | % of total | Network / Organization | Country |
|---|---|---|---|---|
| `79.124.8.107` | 109,788 | 14.4% | Colocatel Inc. ("ColocationX") | NL (org registered in Seychelles) |
| `94.26.88.29` | 62,526 | 8.2% | Telco Power Ltd ("Razinet Dedicated Servers") | GB/BG |
| `212.227.246.10` | 59,236 | 7.8% | IONOS SE | DE |
| `185.218.138.3` | 56,200 | 7.4% | Neterra / "zerolimit-servers" | FI (registrant in MD) |
| `109.205.211.4` | 49,785 | 6.5% | Colocatel Inc. ("ColocationX") | NL |
| `62.164.177.44` | 32,639 | 4.3% | — | — |
| `185.218.138.16` | 25,199 | 3.3% | Neterra / "zerolimit-servers" | FI |
| `94.26.88.34` | 25,047 | 3.3% | Telco Power Ltd | GB/BG |
| `185.156.73.157` | 25,020 | 3.3% | — | — |
| `88.210.63.75` | 24,989 | 3.3% | — | — |

Notable observations:
- **Colocatel Inc.** ("ColocationX"), a Seychelles-registered hosting reseller,
  owns two of the top five offending IP ranges (`79.124.8.0/24` and
  `109.205.211.0/24`) — a single hosting entity accounts for roughly 21% of all
  RDP honeypot traffic.
- The abuse contact for `185.218.138.0/24` is literally
  `ban-me-please@zerolimit-servers.cool` — a self-aware brand name that
  anticipates and expects abuse complaints, characteristic of "bulletproof" or
  abuse-tolerant hosting.
- `212.227.246.10` belongs to **IONOS SE**, a large mainstream German cloud/hosting
  provider. Unlike the other entries, this is likely a **compromised or abused
  customer VM** rather than infrastructure purpose-built for scanning.

### 3.3 Credential-guessing pattern

Of 559,309 login attempts:

- **271,867 (49%)** submitted a **blank username**. This is consistent with
  automated NLA/CredSSP handshake probes (e.g., mass scanners like `masscan`
  RDP plugins or Shodan/Censys-style crawlers) that only fingerprint whether
  RDP+NLA is enabled and never submit real credentials.
- Of attempts with a real username, the overwhelming majority target variants of
  **"administrator"**:

  | Username | Count |
  |---|---|
  | `Administrator1` | 103,152 |
  | `Administrator` | 58,777 |
  | `Administraor` *(sic)* | 37,273 |
  | `administrator` | 28,605 |
  | `Administrateur` *(French)* | 24,865 |
  | `admin` | 2,693 |
  | `ADMINISTRADOR` *(Spanish)* | 1,151 |
  | `support` | 1,075 |
  | `user` | 924 |
  | `scan` / `scanner` / `scans` | 604 each |

- The misspelling **"Administraor"** appearing 37,273 times only makes sense as a
  hardcoded typo baked into a widely-distributed scanning tool's built-in
  wordlist — this is a fingerprint of automated tooling, not manual attacker
  behavior.
- Localized variants (`Administrateur`, `ADMINISTRADOR`) indicate the underlying
  wordlists are reused/shared across multiple regional botnets or tools.
- A handful of attempts used transparently non-credential usernames
  (`scan`, `scanner`, `scans`) — some tools don't bother disguising themselves.

### 3.4 Session duration (automation signature)

| Duration | Sessions |
|---|---|
| 0 seconds | 284,966 |
| 1 second | 388,602 |
| 2 seconds | 30,165 |
| 15 seconds | 25,421 |
| 3 seconds | 13,714 |
| 5 seconds | 7,947 |

- **89% of all sessions last 0–1 seconds** — consistent with automated NLA
  handshake probes that disconnect immediately after fingerprinting.
- A distinct cluster of **25,421 sessions lasting exactly 15 seconds** stands out
  from the rest of the distribution. This duration is most likely the
  honeypot's own configured idle-connection timeout, meaning these clients
  opened a connection and left it idle until the server closed it — possibly a
  slower/interactive tool or a scanner exhausting connection pools rather than
  fingerprinting and disconnecting immediately.

### 3.5 Protocol-level information leakage

One anomalous entry used **legacy RDP Security Layer instead of NLA**:

```
Login from 185.226.197.62:55952,
  hostname: 'EMP-LAP-0015',
  username: '91xqzilj',
  password: ''.
```

In classic (non-NLA) RDP, the client's local Windows computer name is sent
**unencrypted** in the Client Info PDU before any authentication occurs. Here the
connecting machine identified itself as `EMP-LAP-0015` — plausibly a real
corporate endpoint ("Employee Laptop 0015") rather than purpose-built scanning
infrastructure. The random-looking username `91xqzilj` is consistent with
automated credential generation, but the leaked hostname suggests the underlying
attack source may be a **compromised or hijacked corporate Windows machine**
being used to relay or launch scans, rather than a rented VPS.

## 4. Conclusion

The RDP honeypot's dominant traffic volume is explained by the same underlying
cause seen in other T-Pot services: **RDP is one of the most heavily and
continuously scanned protocols on the internet**, driven by commodity
credential-stuffing tools and NLA fingerprinting scanners running from
hosting providers that tolerate (or specialize in) abuse traffic. Key
takeaways:

- Roughly half of all "login" traffic is not credential guessing at all, but
  low-cost NLA capability fingerprinting.
- Real credential attempts are dominated by a small set of "administrator"
  variants drawn from shared, reused wordlists — including at least one
  tool-specific typo that propagated across tens of thousands of attempts.
- A small number of hosting providers/resellers (notably Colocatel Inc. and
  "zerolimit-servers") are responsible for a disproportionate share of total
  volume, making them good candidates for abuse reporting or targeted
  firewall rules if noise reduction is desired.
- Non-NLA legacy RDP connections can leak the true client hostname before
  authentication — a useful detection/attribution technique, and a reminder
  of why enforcing NLA-only access on real-world RDP deployments is a
  meaningful hardening step.

## 5. Takeaways for Discussion

- Compare this RDP volume/behavior against the FTP incident in the companion
  report: FTP saw one persistent bot from a single IP; RDP sees continuous,
  distributed scanning from over a thousand IPs — illustrating how exposure
  level and protocol popularity shape the threat landscape differently per
  service.
- The "administrator" username dominance is a direct, practical illustration
  of why disabling/renaming default administrative accounts and enforcing
  NLA everywhere are baseline RDP hardening recommendations.
- Session duration and protocol-downgrade artifacts (like the leaked
  `EMP-LAP-0015` hostname) show how much can be inferred about attacker
  tooling and infrastructure purely from honeypot metadata, without ever
  capturing a successful compromise.
- WHOIS/RDAP attribution of top offending ranges is a quick way to identify
  recurring abuse-tolerant hosting providers worth reporting or blocking.

---
*Report generated from direct analysis of T-Pot log data
(`tpotce/data/rdphoneypot/log`) plus public RDAP/WHOIS lookups of the top
offending IP addresses.*