1,137 simulated successful logins
Records where the SSH honeypot accepted credentials into its simulated environment—not real host compromises.
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.
Scope: These observations came from one intentionally exposed honeynet and the logs available
in its exported archive. A Cowrie “successful login” is a simulated login, not access to a real production host.
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.
The work was observation and analysis—not interaction with, or retaliation against, remote systems.
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
Unique IP addresses in the successful fake-login export; not a count of distinct people or organizations.
10,758 command records
Parsed Cowrie command records across 1,025 sessions, including reconnaissance and persistence attempts.
Environment, method, and limitations
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.
What the evidence does—and does not—show
- A source IP is not necessarily a distinct operator; attribution and intent remain uncertain.
- Credential and command counts are log records, not counts of confirmed real-world compromises.
- Simulated service banners and provider alerts do not establish that an actual vulnerable device was present.
- High Suricata engine-alert volumes can reflect capture artifacts or malformed traffic, not separate attacks.
Publication boundary: This case study summarizes the findings without source-IP leaderboards
or full attempted-credential tables. The linked public HoneyNet report contains more detailed source-IP lists,
observed username/password pairs, and redacted command examples from the honeypot. The recorded source
addresses do not establish the identity of individual operators, and an attempted credential pair is not
evidence that it works on a real system.
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 scanning for crypto-related Linux infrastructure, but do not identify a target organization
or prove an operator's motive.
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 observed attempts within Cowrie; the report does not establish successful persistence on a real server.
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
These are the service categories supported by log activity, Suricata detections, or provider notices in the original analysis—not a claim that every scan exploited a service.
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
These installation notes are retained from the original lab writeup, not a guarantee that every command or port matches the current T-Pot release. Confirm the official instructions, requirements, and exposure model before reproducing the setup.
Lab boundary: Use an isolated VPS or VM, not a shared production host or home network.
Provider notifications are possible because the honeypot deliberately looks like exposed infrastructure.
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.