1,137 simulated successful logins
Cowrie records where the simulated SSH service accepted submitted credentials.
Security research • T-Pot • Cowrie • Suricata
T-Pot honeynet: from exposed services to observed behavior
I deployed T-Pot on a dedicated public VPS to observe how Internet-facing simulated services were discovered and interacted with. I then archived the logs and analyzed the evidence offline rather than treating dashboard activity as a finding by itself.
The March 15–April 1, 2026 Cowrie exports showed repeated SSH credential attempts, fake successful logins, and automated commands issued inside the simulated shell. Suricata events and hosting-provider exposure notifications added network-level context.
Isolated public VPS
Dedicated host and restricted management access.
T-Pot sensors
Cowrie sessions, Suricata alerts, and simulated services.
Offline evidence review
Credential exports, command timelines, protocol events.
Document and retire
Findings summary, archived logs, verified shutdown.
Deployed, observed, archived, and analyzed honeynet telemetry.
Observed results
The counts below come from the Cowrie exports analyzed in my public honeynet report. The reported login and command datasets cover March 15–April 1, 2026.
508 unique source IPs
Distinct source addresses in the Cowrie accepted-login export.
10,758 command records
Parsed Cowrie command records across 1,025 sessions, including reconnaissance and persistence attempts.
Environment and analysis method
What I collected
A disposable public VPS hosted T-Pot's simulated services. I reviewed Cowrie SSH/Telnet logs and aggregate credential exports, parsed command timelines, inspected Suricata alerts, and compared service-specific observations with exposure notices received through the VPS provider.
The report describes an archived T-Pot dataset of approximately 4.2 GB before compression. The honeynet was stopped before offline analysis.
Interpreting the telemetry
Counts describe recorded sessions and commands; source IPs are observed endpoints, not identified operators. I interpreted Suricata events alongside Cowrie sessions and service logs.
What the honeynet recorded
The strongest evidence was not the attack map alone. It was the connection between credential attempts, Cowrie's simulated post-login shell, the commands submitted there, and independent service-exposure signals.
01 — Crypto-themed SSH credential attempts
Cowrie recorded familiar account guesses alongside repeated Solana-related strings, including
sol, solana, solv, validator,
raydium, and firedancer. This was visible in aggregate exports,
not just one selected session.
Among simulated successful logins, the report records solana/solana 78 times,
ubuntu/ubuntu 70 times, and sol/sol 48 times. The strings are
consistent with crypto-related targeting; the logs do not identify specific organizations.
02 — Commands after fake successful logins
Sessions included short system-fingerprinting commands such as
uname -s -v -n -r -m. Other submitted sequences attempted to manipulate
~/.ssh/authorized_keys, change passwords, inspect host resources and cron jobs,
or terminate competing scripts.
The command export contains 551 SSH-key persistence command records and 6,662 host-resource reconnaissance command records. These are attempted commands recorded in Cowrie.
03 — Broader service probing
Cowrie and Suricata were only part of the picture. The report documents SSH, SMB, industrial-control, SNMP-like, Elasticsearch/OpenSearch, Android Debug Bridge, and MQTT-related exposure or probing. I distinguished an exposed simulated service from an observed interaction before listing it as a finding.
Particularly relevant were IEC-104 alerts associated with 2404/tcp and
external notifications about the honeypot's simulated industrial and infrastructure services.
Service-level evidence
Service categories observed through logs, Suricata detections, and provider notices.
22/tcp
SSH / Cowrie
Credential guesses, fake logins, and simulated shell commands.
445/tcp
SMB
Suricata SMBv1 detections and external exposure notification.
2404/tcp
IEC-104 / industrial control
Protocol-specific Suricata alerts and provider notifications.
161/udp
SNMP-like exposure
Provider notice identifying simulated Siemens/S7-style device information.
9200/tcp
Elasticsearch/OpenSearch
Provider notice associated with an exposed simulated search service.
5555/tcp
Android Debug Bridge
Provider notice associated with simulated ADB exposure.
1883/tcp
MQTT
Suricata malformed-MQTT detection and exposed MQTT-like service.
Interpretation: The report also contains high-volume Suricata truncated-packet alerts.
I did not treat those engine/capture events as evidence of an equivalent number of attacks.
Dashboard and evidence views
Dashboards helped locate interesting windows; the underlying exports and command timelines supported the findings. The published live-feed image has its source-IP column redacted.
Operational controls and teardown
Running a honeynet is an infrastructure responsibility, not just an installation exercise. The lab was isolated from personal services, management access was restricted, and logs were archived before shutdown.
Separate collection from analysis
Collect on a disposable dedicated VPS, preserve the evidence, then review the exported data offline.
Restrict administration
Management SSH and web access are not the honeypot: restrict them to trusted source addresses and protect credentials.
Handle exposure notices
Simulated vulnerable-looking services generated hosting-provider notifications. Document why they exist and retire the lab when collection is complete.
Verify retirement
The original report records tpot.service stopped and disabled, with Docker containers verified no longer running.
Deployment notes and lab reproduction
Original lab configuration and installation notes. Check current T-Pot documentation before reproducing the setup.
Use an isolated VPS or VM, with management access restricted to trusted addresses.
1
Create the VPS
Use a fresh supported Linux image. Do not install Apache, Nginx, databases, panels, or extra services first.
- Pick a server with enough RAM and disk
- Add your SSH key
- Record the public IP
2
Restrict management ports
Before exposing honeypot traffic, keep T-Pot management access limited to your IP.
- Lab SSH management:
64295/tcp - Lab web landing page:
64297/tcp - Allow those only from your home IP
3
SSH into the server
If SSH is still new, read the terminal and SSH guide first.
ssh username@YOUR_SERVER_IP4
Install curl if needed
T-Pot uses a remote installer script, so the server needs curl.
sudo apt update
sudo apt install -y curl5
Run the T-Pot installer
Review the installer from the official T-Pot repository before running it. These are the commands recorded in the original guide; run from $HOME as a normal user, not as root.
cd ~
env bash -c "$(curl -sL https://github.com/telekom-security/tpotce/raw/master/install.sh)"6
Read every installer prompt
Do not speed-click through the installer.
- Choose the install type intentionally
- Create the web user when prompted
- Write down the web username and password
- Watch for port conflict warnings
7
Reboot after install
The official flow expects a reboot after the installer finishes.
sudo reboot8
Log in through T-Pot SSH
These notes used the T-Pot management SSH port configured for this lab.
ssh -l username -p 64295 YOUR_SERVER_IPResearch and project references
Honeynet analysis report
The public analysis includes source-IP tables, observed credential pairs, redacted command examples, Suricata findings, and service-exposure evidence.
T-Pot project
Check current releases, requirements, installation instructions, default ports, and operating guidance here.
Terminal and SSH
An introductory guide for readers who want more background before deploying an isolated lab.