I maintain several web servers and kept seeing a constant stream of SSH login attempts. At some point I became curious: what do these bots actually try to do after they get in?
I set up a Cowrie SSH honeypot and built a small live dashboard around its JSON logs. Cowrie listens on port 22, a Python service follows the log and streams events over WebSockets, and Nginx serves the frontend. The whole thing currently runs on a 1 vCPU / 1 GB Debian VPS.
The dashboard groups activity by source IP, with individual SSH sessions nested underneath. It shows authentication attempts, commands, SSH client fingerprints, file writes and downloads, and tunneling requests in real time.
Initially I thought the interesting part would be simply watching commands appear. After looking at the collected data, I realized that recurring behavior is much more interesting than individual events.
In one roughly 8-hour sample, the honeypot recorded about 1,950 sessions from 213 source IPs. 327 sessions reached command execution.
Some recurring patterns included:
- the same SSH public key being installed 152 times from 11 source IPs
- a system fingerprinting script that appears designed to distinguish a real shell from a honeypot
- a downloader requesting payloads for several CPU architectures
- attempts to use SSH forwarding as a proxy
- distributed credential probes that connect, test one value, and immediately disconnect
This also showed me that grouping activity only by IP isn't enough. Several apparently different sources can use the same SSH client fingerprint, command sequence, public key, or downloaded artifact and probably belong to the same automated campaign.
At the moment this is primarily a live log viewer. Some directions I am considering are:
- automatic classification of sessions as scanning, credential probing, reconnaissance, persistence, downloading, or tunneling
- clustering activity into campaigns using HASSH fingerprints, command sequences, SSH keys, and artifact hashes
- historical statistics and searchable sessions
- support for multiple distributed honeypot sensors
- publishing the collector and dashboard code
The public stream currently includes source IPs, attempted credentials, and commands. I added a notice explaining that an IP may belong to a compromised machine, proxy, VPN, or scanner, but I am still thinking through the privacy and responsible-disclosure tradeoffs.
Cowrie's "login.success" events only mean that the honeypot accepted the credentials; they don't mean those credentials would work on a real server.
I'm trying to decide whether this should remain a simple live visualization or grow into a small analysis tool.
Which direction would make this project most useful or interesting to you? Are there other patterns or types of analysis that would be worth adding?
Some kind of source IP masking would be prudent. As you pointed out, some of those machines are compromised, and you aren't making their owners' lives any easier.
Bad actors might use the data you're publishing to fingerprint specific exploits to which the machines are vulnerable, multiplying the problem.
If producing an IP blacklist is one of your aims, divorcing it from any specific traffic would be more responsible.
You may also want to consider the risk traffic from compromised machines could leak PII (eg. say a script tried to use you as a relay to exfiltrate data) - and the ethical and legal consequences. A filter for SIN, credit cards, etc. would be a basic table-stakes mitigation step.
> Some kind of source IP masking would be prudent. As you pointed out, some of those machines are compromised, and you aren't making their owners' lives any easier.
Hard for me to find much sympathy for negligent users who unintentionally allowed their home computers or phones to join a malicious botnet, or their ISPs who aren't stopping the activity. Even if it is my own grandma's PC.
I agree about the content though, there probably are a lot of actually innocent victims' personal information in the traffic itself.
Easy for you to say, assuming your PC is clean. I don't think negligent is the right word though. Ignorant maybe? Or some form of naivety? The negligence might be on software or hardware vendors, but grandma isn't to blame for the problem.
Software providers generally lack a duty to their clients to create and sell secure software. Further, generally, when you get hacked, there is only an interrupted causal chain between the software and your loss. Interrupting that chain is the intervening superseding cause of a criminal third-party. Finally, no states allow punitive damages, absent gross negligence in a software context.
when you read or are told not to click on that link in the e-mail, or open the attachment, you should fire up your monitor while you are clicking on the links.
it might be interesting to have an eye on this while you are talking to the phone scammer.
> a system fingerprinting script that appears designed to distinguish a real shell from a honeypot
Huh, so if you figure out what triggers this script into thinking your system is a honeypot, and then make your real system behave that way… unhackable /s
Hi tusksm! It's honeypot season! Really cool project, I've been working on a honeypot project of my own right now called `honeyprompt` (https://github.com/alectrocute/honeyprompt) that utilizes LLMs to craft responses and supports multiple protocols. Having a public sink presentation layer like honeypotlive.cc was one of my next todos.
You know what extra data would be cool? If you hit `curl https://ip.guide/{src_ip}` and got back the ASN and country etc and added a leaderboard. In my own experiments in this area I've been gobsmacked by how much malicious traffic comes from Azure.
I have a similar experience with a tendency to Digital Ocean. Actually, I semi-automatically collect IPs that are banned by (mostly SSH) fail2ban and eBPF bans from dnsdist. These IPs are then merged into CIDRs, which are used as ipsets in a firewall ban chain. The IPs are collected on around ~20 Machines with public, static IPv4 and IPv6 addresses. Most of the Machines are in Canada and Europe.
However, I have statistics for the CIDRs based on their whois record that look like:
CIDRs used: 1255
Already cached: 1252
Skipped uncached targets: 0
IPs scanned total: 985300
Estimated throttled wait: 0.10 minutes
== Country codes ==
Metric: Top 10 of 90 unique country codes
Total: 1183 country codes total and 90 unique country codes in 1255 targets
US 287
CN 132
NL 88
VN 53
DE 51
HK 45
AU 38
ID 36
RU 33
CA 27
== Regions ==
Metric: Top 10 of 29 unique regions
Total: 334 regions total and 29 unique regions in 1255 targets
CO 48
FL 40
WA 37
QLD 32
GA 26
NY 25
CA 23
TX 17
QC 15
UT 14
== Origin ASNs ==
Metric: Top 10 of 382 unique origin ASNs
Total: 805 origin ASNs total and 382 unique origin ASNs in 1255 targets
Total: 703 org names total and 222 unique org names in 1255 targets
RIPE Network Coordination Centre 55
DigitalOcean, LLC 40
Asia Pacific Network Information Centre 32
Microsoft Corporation 31
Internap Holding LLC 25
HostPapa 23
Korea Telecom 20
Hetzner Online GmbH 17
China Mobile 16
ReliableSite.Net LLC 16
== Organizations ==
Metric: Top 10 of 236 unique organizations
Total: 691 organizations total and 236 unique organizations in 1255 targets
RIPE Network Coordination Centre (RIPE) 55
DigitalOcean, LLC (DO-13) 40
Asia Pacific Network Information Centre (APNIC) 32
Microsoft Corporation (MSFT) 31
Internap Holding LLC (IC-1425) 25
HostPapa (HOSTP-7) 23
ORG-HOA1-RIPE 17
ORG-CM1-AP 16
ReliableSite.Net LLC (RL-323) 15
FranTech Solutions (SYNDI-5) 13
== Domains ==
Metric: Top 10 of 534 unique domains
Total: 2581 domains total and 534 unique domains in 1255 targets
I deleted the (abuse) mail section. Because.
99% of the IPs are IPv4. In the IPset are mostly /32 but also a lot of ~/24 and rarely ~/16 segments. RIPE, ARIN and APNIC comes into play because some CIDR blocks are somewhat generously sized and block multiple network segments belonging to different organizations at the same time. E.g. this hides BR from the stats (because the ipset mostly bans every provider from BR).
>Nah, Spur (a company tracking residential proxies) doesn't flag it at all.
I looked into it and so far as I can tell it works off a blacklist system, rather than any sort of automatic analysis (eg. TCP or MTU fingerprinting). If you set up a "residential proxy" in the form of a home VPN, it won't be detected. It also means the detection is only as good as whatever their backlist source is. If it's a niche provider, it might not get picked up at all.
They're not doing a very good job at it, tried a few disposable free residential proxies - not flagged. Tried my CGNAT home connection - flagged. My phone connection - also flagged.
> Tried my CGNAT home connection - flagged. My phone connection - also flagged.
Why does that mean they're doing a bad job? Since both are CGNAT, you're sharing the IP with lots of other people, and it's not unlikely that one of your network neighbors is infected.
They are leaking their IP on the internet! Big security no-no. They'll need to download a lot more ram to deal with all the hackers coming for them.
A data broker is going to correlate this IP with "never gonna give you up" as an ideological statement about his drug dealings. They'll be receiving weird ads for weeks!
We don’t have static IPs at home in Romania. A restart of the router will just give that person another public IP and they won’t notice any repercussions.
For the sake of interest you could try to expose periodically rotated keyed hashes of IPs and credentials instead of the raw values. It would still let people correlate events within a limited time window
Do you allow them entry, present a fake prompt, and record what they do?
Some time ago I did a little experiment by running `nc -l -p 23` (telnet) which connects the next incoming telnet connection to your console. Type in a simulated prompt like Password: or # and it'll be buffered until the connection comes in. Then see what the scanner sends.
Opened the website to be greeted with only spam of huge walls of random text, seems people are abusing the fun out of it! Would love to actually have seen some interesting bot patterns from the authors comments.
You're right. HN traffic quickly turned the live feed from bot activity into a wall of human-generated test payloads.
I'm already working on truncating long values and grouping events by source. The next step will probably be rate limiting noisy sources and separating likely human test traffic from recurring automated behavior.
The recurring bot patterns are the part I ultimately want the interface to surface, rather than forcing visitors to inspect every raw event.
can't you just keep the honeypot secret and detached from the interface? i guess someone might start scanning ips until their message pops up but still
That was my first impression too, since the SSH-key installation attempts are much more frequent and tend to dominate the feed.
I did find at least one campaign that went further: it tried to fetch `http://41.216.189.157/run.sh` with wget or curl, execute it, and remove the script afterward. The downloader referenced payloads for aarch64, i386, loongarch64, and m68k, so it appears to be targeting a fairly broad set of Linux systems.
I haven't fully analyzed the artifacts yet, so I can't say exactly what service or payload it ultimately installs. But it was definitely doing more than adding a key.
This also exposed a weakness in the current UI: repetitive persistence attempts are prominent, while rarer download and execution chains are easy to miss.
Cowrie author here! Yes this is the usual background noise on the internet! Cowrie (which I suspect is used here as well as the data generator) recently had a lot of updates, including now easy install from pip (pip install cowrie), and a much improved shell parser that’s much more capable of parsing attacker commands! https://github.com/cowrie/cowrie and get the full raw data in JSON or other formats to add geoip and ASN attribution! And of course malware samples.
[OP] tusksm | a day ago
I maintain several web servers and kept seeing a constant stream of SSH login attempts. At some point I became curious: what do these bots actually try to do after they get in?
I set up a Cowrie SSH honeypot and built a small live dashboard around its JSON logs. Cowrie listens on port 22, a Python service follows the log and streams events over WebSockets, and Nginx serves the frontend. The whole thing currently runs on a 1 vCPU / 1 GB Debian VPS.
The dashboard groups activity by source IP, with individual SSH sessions nested underneath. It shows authentication attempts, commands, SSH client fingerprints, file writes and downloads, and tunneling requests in real time.
Initially I thought the interesting part would be simply watching commands appear. After looking at the collected data, I realized that recurring behavior is much more interesting than individual events.
In one roughly 8-hour sample, the honeypot recorded about 1,950 sessions from 213 source IPs. 327 sessions reached command execution.
Some recurring patterns included:
- the same SSH public key being installed 152 times from 11 source IPs - a system fingerprinting script that appears designed to distinguish a real shell from a honeypot - a downloader requesting payloads for several CPU architectures - attempts to use SSH forwarding as a proxy - distributed credential probes that connect, test one value, and immediately disconnect
This also showed me that grouping activity only by IP isn't enough. Several apparently different sources can use the same SSH client fingerprint, command sequence, public key, or downloaded artifact and probably belong to the same automated campaign.
At the moment this is primarily a live log viewer. Some directions I am considering are:
- automatic classification of sessions as scanning, credential probing, reconnaissance, persistence, downloading, or tunneling - clustering activity into campaigns using HASSH fingerprints, command sequences, SSH keys, and artifact hashes - historical statistics and searchable sessions - support for multiple distributed honeypot sensors - publishing the collector and dashboard code
The public stream currently includes source IPs, attempted credentials, and commands. I added a notice explaining that an IP may belong to a compromised machine, proxy, VPN, or scanner, but I am still thinking through the privacy and responsible-disclosure tradeoffs.
Cowrie's "login.success" events only mean that the honeypot accepted the credentials; they don't mean those credentials would work on a real server.
I'm trying to decide whether this should remain a simple live visualization or grow into a small analysis tool.
Which direction would make this project most useful or interesting to you? Are there other patterns or types of analysis that would be worth adding?
p1anecrazy | a day ago
The aggregations of popular logins and IP locations seem interesting.
LorenDB | a day ago
CookieCrisp | a day ago
hideout_berlin | a day ago
krunck | a day ago
Try fingerprinting the behaviour in the sessions. Over time you should be able to distinguish between various automated tools and live people.
rkagerer | a day ago
Bad actors might use the data you're publishing to fingerprint specific exploits to which the machines are vulnerable, multiplying the problem.
If producing an IP blacklist is one of your aims, divorcing it from any specific traffic would be more responsible.
You may also want to consider the risk traffic from compromised machines could leak PII (eg. say a script tried to use you as a relay to exfiltrate data) - and the ethical and legal consequences. A filter for SIN, credit cards, etc. would be a basic table-stakes mitigation step.
ryandrake | a day ago
Hard for me to find much sympathy for negligent users who unintentionally allowed their home computers or phones to join a malicious botnet, or their ISPs who aren't stopping the activity. Even if it is my own grandma's PC.
I agree about the content though, there probably are a lot of actually innocent victims' personal information in the traffic itself.
taftster | a day ago
singleshot_ | a day ago
dpoloncsak | a day ago
rolph | a day ago
it might be interesting to have an eye on this while you are talking to the phone scammer.
left-struck | 16 hours ago
Huh, so if you figure out what triggers this script into thinking your system is a honeypot, and then make your real system behave that way… unhackable /s
arm32 | a day ago
tarpitt | a day ago
CzaxTanmay | a day ago
drcongo | a day ago
reaperducer | a day ago
I'm currently fighting this battle.
As of this morning:
ok123456 | a day ago
drcongo | a day ago
exiguus | 18 hours ago
However, I have statistics for the CIDRs based on their whois record that look like:
CIDRs used: 1255
Already cached: 1252
Skipped uncached targets: 0
IPs scanned total: 985300
Estimated throttled wait: 0.10 minutes
== Country codes ==
Metric: Top 10 of 90 unique country codes
Total: 1183 country codes total and 90 unique country codes in 1255 targets
== Regions ==Metric: Top 10 of 29 unique regions
Total: 334 regions total and 29 unique regions in 1255 targets
== Origin ASNs ==Metric: Top 10 of 382 unique origin ASNs
Total: 805 origin ASNs total and 382 unique origin ASNs in 1255 targets
== Netnames ==Metric: Top 10 of 630 unique netnames
Total: 1157 netnames total and 630 unique netnames in 1255 targets
== Org names ==Metric: Top 10 of 222 unique org names
Total: 703 org names total and 222 unique org names in 1255 targets
== Organizations ==Metric: Top 10 of 236 unique organizations
Total: 691 organizations total and 236 unique organizations in 1255 targets
== Domains ==Metric: Top 10 of 534 unique domains
Total: 2581 domains total and 534 unique domains in 1255 targets
I deleted the (abuse) mail section. Because. 99% of the IPs are IPv4. In the IPset are mostly /32 but also a lot of ~/24 and rarely ~/16 segments. RIPE, ARIN and APNIC comes into play because some CIDR blocks are somewhat generously sized and block multiple network segments belonging to different organizations at the same time. E.g. this hides BR from the stats (because the ipset mostly bans every provider from BR).yjftsjthsd-h | 15 hours ago
belval | a day ago
preetham_rangu | a day ago
b0rbb | a day ago
fragmede | a day ago
paoliniluis | a day ago
KomoD | a day ago
reaperducer | a day ago
KomoD | a day ago
He's most likely just not very smart.
gruez | a day ago
I looked into it and so far as I can tell it works off a blacklist system, rather than any sort of automatic analysis (eg. TCP or MTU fingerprinting). If you set up a "residential proxy" in the form of a home VPN, it won't be detected. It also means the detection is only as good as whatever their backlist source is. If it's a niche provider, it might not get picked up at all.
GreenVulpine | a day ago
KomoD | a day ago
Where are you finding free residential proxies?
> Tried my CGNAT home connection - flagged. My phone connection - also flagged.
Why does that mean they're doing a bad job? Since both are CGNAT, you're sharing the IP with lots of other people, and it's not unlikely that one of your network neighbors is infected.
toilet | a day ago
KomoD | a day ago
bleepblap | a day ago
m00dy | a day ago
efilife | a day ago
athrowaway3z | a day ago
A data broker is going to correlate this IP with "never gonna give you up" as an ideological statement about his drug dealings. They'll be receiving weird ads for weeks!
KomoD | a day ago
alin23 | a day ago
williamcotton | a day ago
spikk | a day ago
Farrynet | a day ago
_def | a day ago
fragmede | a day ago
throwaway7783 | a day ago
fragmede | a day ago
Human-Cabbage | a day ago
It’s too bad that ssh doesn’t carry sound. A MIDI-style rendition of the song would really tie it all together.
inigyou | 23 hours ago
Some time ago I did a little experiment by running `nc -l -p 23` (telnet) which connects the next incoming telnet connection to your console. Type in a simulated prompt like Password: or # and it'll be buffered until the connection comes in. Then see what the scanner sends.
voakbasda | 5 hours ago
Fabricio20 | a day ago
[OP] tusksm | 21 hours ago
I'm already working on truncating long values and grouping events by source. The next step will probably be rate limiting noisy sources and separating likely human test traffic from recurring automated behavior.
The recurring bot patterns are the part I ultimately want the interface to surface, rather than forcing visitors to inspect every raw event.
throawayonthe | 11 hours ago
charcircuit | 21 hours ago
[OP] tusksm | 20 hours ago
I did find at least one campaign that went further: it tried to fetch `http://41.216.189.157/run.sh` with wget or curl, execute it, and remove the script afterward. The downloader referenced payloads for aarch64, i386, loongarch64, and m68k, so it appears to be targeting a fairly broad set of Linux systems.
I haven't fully analyzed the artifacts yet, so I can't say exactly what service or payload it ultimately installs. But it was definitely doing more than adding a key.
This also exposed a weakness in the current UI: repetitive persistence attempts are prominent, while rarer download and execution chains are easy to miss.
micheloosterhof | 20 hours ago
asd000hh | 19 hours ago