We Mapped a Live P2P Botnet from a $6 Honeypot
SHELLHOUNDS — Rapid Tactical Prototyping Lab A Division of Klavan Security
Shadow Tactics IIS Carbon Copy is sponsored by
All views expressed belong to Shadow Tactics IIS Carbon Copy and do not reflect the position of any sponsor.
Within 16 hours of deploying an SSH honeypot in Singapore, we captured a live Panchan sample, identified five distinct threat actor operational models, and enumerated 96 nodes of the botnet’s P2P mesh — the same botnet Akamai documented in 2022, still operational in 2026.
Here’s what we deployed, what showed up, and what it means.
Methodology and Scope
The honeypot was a Cowrie SSH deployment on DigitalOcean Singapore (SGP1), configured to accept common default credentials and log all session activity.
GPU presence was spoofed via custom command handlers to attract cryptomining-focused actors.
P2P enumeration was limited to passive banner reading on port 1919 — the same lightweight probe that services like Shodan and Censys perform at scale. No payloads were sent to any node. No exploitation was attempted. Enumeration was capped at three hops from seed peers to limit scope.
All IPs referenced in this post were already exposed to the public internet and actively participating in botnet operations.
We cross-referenced our findings against published research from Akamai (2022) and Nozomi Networks (2024). All claims below are bounded to what we directly observed or what published sources corroborate.
The Setup
The honeypot was configured to look like a neglected GPU compute server. Hostname: sgp-prod-web01. Custom handlers spoofed lspci output showing an NVIDIA RTX 3090 and A100 on the PCIe bus, nvidia-smi displaying both GPUs at 0% utilization, and /proc/cpuinfo reporting an Intel Xeon Gold 6248. Idle GPUs signal untapped mining potential to automated reconnaissance.
Singapore was chosen for Asian threat actor coverage — Panchan historically concentrates in that region, and the education/cloud infrastructure targets it favors are well-represented in SGP1.
Beyond the hardware bait, we addressed known Cowrie fingerprinting vectors. Default Cowrie produces non-standard output for cat --help and ls --help, which experienced operators use as detection tests. We also patched Cowrie’s cat -n implementation, which output double spaces after line numbers instead of tabs — a subtle discrepancy from GNU cat that at least one operator tested for during our observation window.
What Showed Up
16,131 inbound connections in approximately 16 hours.
151 unique source IPs.
91 successful logins.
73 executed reconnaissance commands.
7 attempted post-exploitation.
2 deployed malware.
That funnel matters. It shows a layered ecosystem where scanning, validation, triage, and exploitation are performed by different actors — often independently.
We identified five operational models:
Amsterdam GPU Botnet (our label, based on infrastructure location and observed behavior).
Four DigitalOcean Amsterdam IPs (159.223.13.213, 188.166.93.77, 209.38.43.231, 209.38.45.120) sharing an identical HASSH fingerprint (2ec37a7cc8daf20b10e1ad6221061ca5) and SSH-2.0-Go client string. 208+ sessions, each running the same script: OS fingerprinting, CPU core count, GPU detection via lspci | grep -i nvidia, anti-honeypot checks (cat --help, ls --help), and last for competing attacker detection.
This is Phase 1 reconnaissance — payload deployment on validated targets would follow separately.
Swedish Triage Operator. Single IP (81.226.165.204), root/root credential, 10-second session. The most operationally dense actor observed. One session evaluated the host across six dimensions: MikroTik RouterOS detection (/ip cloud print), competing miner detection (ps | grep '[Mm]iner' — bracket syntax avoids matching the grep process itself), Telegram session data theft (checking tdata directories for active session tokens), SMS gateway infrastructure detection (probing for GSM modems and SMS daemon logs at /dev/ttyGSM*, /var/spool/sms/*), competing botnet marker search (locate D877F783D5D3EF8Cs), and honeypot detection (echo Hi | cat -n). Six classification checks in ten seconds suggests a triage pipeline that routes compromised hosts to different exploitation modules.
Indonesian Access Broker. 180.252.170.122 on Telkom Indonesia generated 44,325 login attempts — the highest volume single IP. Upon successful login, the only command executed was echo -e "\x6F\x6B". That hex string decodes to “ok” and validates that the shell is real, responsive, and correctly interprets escape sequences. No further exploitation. This is inventory building: validate access at scale, then sell or reuse the credential database later.
Russian Manual Operator. 87.228.27.214 (Rostelecom) conducted 5 sessions over 50 minutes. Consistent 12-second delay between login and first command — human reaction time, not automation. Ran hostname four times across sessions and ssh -V 2>&1 once, checking SSH client version with stderr redirected to stdout. That command evaluates whether the host can serve as an SSH pivot point for lateral movement.
Worm Deployers. Two IPs deployed Panchan samples. The first (59.185.230.105) staged a binary in a hidden directory with a randomized numeric name, made it executable, and launched with nohup:
chmod +x ./.5155522444205515704/sshd; nohup ./.5155522444205515704/sshd &The second deployment (154.66.196.87) used a different staging directory but the same binary — and critically, passed 51 IP addresses as command-line arguments. Those addresses turned out to be P2P seed peers.
The Binary
SHA-256: 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00
30 MB Go-compiled ELF. Symbol analysis via readelf revealed 80+ exported Go functions:
main.spreader+main.sshtry(9 sub-functions) — SSH worm propagation via key harvesting and brute forcemain.miner— NiceHash-integrated cryptomining with GPU detectionmain.p2p(7 sub-functions) — peer-to-peer mesh coordination on port 1919main.protector(10+ functions) — anti-removal, includingmain.antikillandmain.antitaskmanagermain.randomIP— random IPv4 address generation for scanning (true internet worm behavior)
The SHA-256 is an exact match to a sample analyzed by Nozomi Networks in July 2024, which they attributed to the Panchan botnet family originally documented by Akamai in March 2022.
A note on the hash
The fact that the identical binary hash from 2024 is being deployed in 2026 raises a question worth flagging: is this the same compiled binary being reused verbatim, or are we observing cached/archived samples being redeployed by a secondary operator? We can’t definitively answer this from honeypot data alone. What we can confirm is that the P2P mesh is active, the seed peers are responsive, and the botnet infrastructure is maintained — regardless of whether the deployer is the original author or a downstream operator working from an existing toolkit. The binary’s behavior and infrastructure remain functional.
Published corroboration
The Nozomi and Akamai research confirmed details consistent with our analysis: persistence via /bin/systemd-worker and a systemd service file, PID storage in /tmp/.jpecggmkwmcssjj, XMRig and NBMiner deployment via memfd_create (fileless execution through /proc/self/fd/), SSH key harvesting from .ssh/known_hosts for recursive lateral movement, Discord webhook reporting, and SSH server replacement that retains the original host key to avoid fingerprint warnings.
Operator language artifacts — Japanese text in Discord messages (”わあわあ”), the “pan-chan” naming convention (likely referencing Panchan Rina, a kickboxer), and admin panel language in earlier samples — are consistent with a Japanese-speaking operator, though we note this falls short of definitive attribution.
Mapping the Mesh
The second Panchan deployment gave us the P2P seed list: 51 IPs passed as arguments on the command line. Each is a known-good Panchan peer listening on port 1919.
The protocol is plaintext TCP:
$ echo "" | nc -w3 34.126.82.84 1919
pan-chan's mining island hi!
sharepeer 105.156.152.32
sharepeer 34.131.124.206
sharepeer 13.114.13.6
sharepeer 111.170.140.117
sharepeer 203.186.60.250
finishEach node returns up to 5 peers. Those peers return 5 more. Three hops deep, we identified 96 unique nodes.
Seed peers: 45 of 51 responded on port 1919 (88% uptime).
Hop 1: 25 new peers discovered, 4 responsive and returning peer lists.
Hop 2: 18 new peers discovered from 6 responsive second-hop nodes.
The infrastructure breakdown: approximately 40% cloud/VPS (AWS, GCP, DigitalOcean, Alibaba, Hetzner, Linode, OVH) and 60% residential or unclassified. The cloud concentration reflects the target profile — poorly secured VMs with default SSH credentials.
For reference, Akamai found 209 peers in 2022. Our enumeration was capped at three hops and likely represents a partial view.
We wrote a recursive crawler — same single-banner TCP request per node, no additional protocol interaction — and set it on a 6-hour cron interval to track mesh evolution over time.
The Anti-Honeypot Arms Race
Three IPs tested our honeypot for detection artifacts within the observation window:
echo Hi | cat -n — Checks whether cat -n formats output with a tab after the line number (GNU behavior) or spaces (Cowrie’s default). We discovered this discrepancy because the test was run against us, patched it in production, and confirmed subsequent scans from different IPs passed.
echo -e "\x6F\x6B" — Verifies hex escape interpretation. Restricted shells and some honeypots won’t produce “ok” from this input. Cowrie handled this correctly out of the box.
ssh -V 2>&1 — Beyond its lateral-movement purpose, this also fingerprints the environment. A real server returns a version string; a limited emulation might not.
The implication for honeypot operators: Cowrie out of the box has detectable tells. The more sophisticated operators — the ones producing the most interesting data — are the first to leave if they identify the trap. Maintaining honeypot fidelity requires ongoing patching against adversary fingerprinting, not just initial deployment.
Takeaways
For cloud operators. If you have a Linux VM with SSH password authentication enabled, check for /bin/systemd-worker, any systemd-worker.service unit file, port 1919 listeners, and outbound connections to ip.seeip.org. Disable password authentication. This is not theoretical — 91 successful logins on default credentials in 16 hours on a single IP.
For threat researchers. P2P botnets are enumerable when you understand the protocol. The tools are readelf, strings, nc, grep, and patience. Cross-referencing captures against published research multiplies findings: Akamai and Nozomi gave us context we couldn’t have derived from static analysis alone, and our observations extend the timeline of their published work.
For security leadership. Five distinct economic models of exploitation converged on one server in 16 hours — automated reconnaissance, multi-revenue triage, access brokering, manual assessment, and worm deployment. Each represents independent actors with different objectives and monetization strategies. The attack surface facing any internet-exposed server is not a single threat but a competitive ecosystem.
Indicators of Compromise
Malware Hash: 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00 (SHA-256)
File System:
/bin/systemd-worker— persistence binary/lib/systemd/system/systemd-worker.service— systemd unit/tmp/.jpecggmkwmcssjj— PID file.*/sshdin numbered hidden directories — staging
Network:
Port 1919/TCP — P2P mesh communication
Banner:
pan-chan's mining island hi!ip.seeip.org— external IP check-inNiceHash mining pool connections
Discord webhook C2
HASSH: 2ec37a7cc8daf20b10e1ad6221061ca5 — Amsterdam GPU botnet scanner
Behavioral:
Process masquerading as
sshd(not child of real SSH daemon)SSH server replacement retaining original host key
Miners terminated when
top/htopdetectedPort-based process killing of competing miners
References
Akamai Security Research, “Panchan: A New Golang Peer-to-Peer Botnet,” June 2022
Nozomi Networks Labs, “The Evolving Panchan Botnet,” July 2024
About This Research
SHELLHOUNDS is the Rapid Tactical Prototyping Lab of Klavan Security. Our research informs the penetration testing and threat modeling we deliver through Klavan’s Mission Ready SOC 2 Success Path™.
Full technical report with complete MITRE ATT&CK mapping and detailed actor profiles available on request — klavansecurity.com.
Ongoing threat intelligence: Shadow Tactics newsletter.