# T-Pot Honeypot Incident Report: FTP Credential-Stuffing Activity from 45.61.170.83

**Prepared:** 2026-08-21
**System:** T-Pot honeypot deployment (Dionaea, Suricata, p0f, Cowrie, and other services)
**Audience:** Student review / presentation material

---

## 1. Summary

While reviewing captured credentials in Kibana, an unusual password was observed:

```
H0neyp0t_$tr0ng_p@ssw0rd_!
```

The initial concern was that an attacker had recognized the system as a honeypot and was
"trolling" the operator by submitting a password that literally spells out "honeypot."
Investigation of the raw honeypot logs shows this is **not** the case. The password came
from a single automated credential-stuffing bot running a generic default/IoT password
wordlist, and its disproportionate repetition is explained by normal bot behavior rather
than targeted honeypot detection.

## 2. Investigation Method

Raw log data was searched directly on the host (not just the Kibana front end) to get full
context, across both live and rotated/compressed logs:

- `tpotce/data/dionaea/log/dionaea.json*` (FTP honeypot session logs)
- `tpotce/data/suricata/log/eve.json*` (network IDS / packet capture metadata)
- `tpotce/data/p0f/`, `tpotce/data/cowrie/`, and all other honeypot service logs
  (searched to rule out the password/IP appearing elsewhere)

Commands used included `grep`/`zgrep` across plaintext and gzip-rotated logs to:
1. Locate every occurrence of the literal password string.
2. Identify which honeypot service(s) captured it.
3. Enumerate distinct source IPs using that password.
4. Pull the full username/password/timestamp pattern used by the offending IP.
5. Determine which ports/services that IP touched across the whole platform.

## 3. Findings

### 3.1 Source of the password

The password appeared **only** in:
- Dionaea's FTP emulator logs (`USER`/`PASS` commands, `credentials` field)
- Suricata's `eve.json` (same traffic, parsed at the network layer)

It did **not** appear anywhere else in the deployment (no Cowrie, no other honeypot
service), and it is not part of T-Pot's own default configuration/codebase — it was
submitted entirely by the remote client.

### 3.2 Single source IP, single service, single protocol

| Attribute | Value |
|---|---|
| Source IP | `45.61.170.83` |
| Target service | Dionaea FTP emulator (port 21 only) |
| First seen | 2026-08-17 22:01 UTC |
| Peak activity | 2026-08-20 (~140,000 hits) |
| Last seen | 2026-08-21 15:25 UTC |
| Total FTP login attempts (Dionaea) | 160,215 |
| Attempts using the "honeypot" password | 80,095 |
| Other ports/services touched | None (one stray packet to a random high port; otherwise 100% FTP) |

### 3.3 Credential pattern

The source IP cycled through a large, generic default/IoT-style username and password
dictionary:

- **Usernames tried:** `ftp`, `anonymous`, `admin123`, `admin12345`, `avery`, `website`,
  `web`, `tablet`, `smarthome`, `site`, `secure`, `rootpasswd`, `qwerty`, `qwerty123`,
  `monkey`, `master`, `letmein`, `null`, `none`, and others.
- **Passwords tried:** common weak/default values (`123456`, `password`, `admin`,
  `qwerty123`, `abcd1234`, `q1w2e3r4`, etc.), each attempted only **~85 times** — i.e.,
  roughly one pass through the dictionary.
- **One password, `H0neyp0t_$tr0ng_p@ssw0rd_!`, was reused 80,095 times** — nearly
  1,000x more often than any other entry.

### 3.4 Why one password dominates

Dionaea's FTP emulator is designed to **accept any username/password combination**, since
its purpose is to lure in malware droppers and attackers, not to enforce real
authentication. The observed pattern is consistent with the following bot logic:

1. Try each username/password pair from the dictionary once.
2. As soon as a login "succeeds" (which happens on the very first attempt against any
   honeypot, since everything succeeds), **cache that credential as known-good**.
3. Reconnect repeatedly using only the cached credential from then on.

The cached credential simply happened to be the dictionary entry containing the word
"honeypot" — likely a joke/test entry seeded into a public credential wordlist by whoever
compiled it, not a deliberate signal from the attacker that they identified the system.

### 3.5 Infrastructure attribution (WHOIS/RDAP)

| Attribute | Value |
|---|---|
| Network | `45.61.170.0/24` |
| ASN | 14956 |
| AS Name | RouterHosting LLC |
| Upstream / parent block | FranTech Solutions "PONYNET" (`45.61.128.0/18`) |
| Registry | ARIN |
| Country | US |
| Geofeed | `api.cloudzy.com/geofeed.csv` (Cloudzy VPS reseller) |

The source is a **rented VPS** from a low-cost, signup-friendly hosting provider
(FranTech/PONYNET, resold via Cloudzy/RouterHosting), not a compromised residential or IoT
device. This class of provider is well known in the security community for hosting
scanning bots and abuse traffic due to easy anonymous signup and weak abuse enforcement.

## 4. Conclusion

The evidence does **not** support the hypothesis that an attacker recognized the honeypot
and reacted to it. Instead:

- A commodity FTP credential-stuffing bot, running on cheap VPS infrastructure, swept the
  target with a standard weak/default-credential wordlist.
- Because the honeypot accepts any credential by design, the bot's first successful login
  was cached and replayed tens of thousands of times.
- The "honeypot" wording in the password is coincidental — it was one low-value entry in
  a large public wordlist, not a targeted message.
- No indication of detection, evasion, or behavior change was observed on the attacker's
  side (e.g., no immediate disconnect, no probing of other services, no change in
  technique).

## 5. Takeaways for Discussion

- Honeypot emulators that accept all credentials (like Dionaea's FTP) will always attract
  disproportionate reuse of whichever credential "worked first" — this is a useful
  detail to understand when interpreting top-credential charts in Kibana.
- Seeing a suspicious or "cute" string in captured data is not proof of detection; always
  check log volume, source diversity, and dictionary context before drawing conclusions.
- WHOIS/RDAP lookups on repeat offenders are a quick way to distinguish "rented scanning
  VPS" from "likely compromised end-user device," which changes the risk interpretation.
- This incident is a good example of why raw log review (not just dashboard aggregates)
  is necessary to correctly explain anomalies before presenting conclusions.

---
*Report generated from direct analysis of T-Pot log data (`tpotce/data/dionaea`,
`tpotce/data/suricata`) plus a public RDAP/WHOIS lookup of the offending IP.*