Iran-Linked Botnet Exposed After Open Directory Leak Reveals 15-Node Relay Network
A misconfigured opendirectory on an Iranian server has exposed a live censorship-bypass relay and SSH-based botnet operation, revealing how a single actor stitched together a 15-node network across Iran and Finland using commodity tools and sloppy operational security.
The discovery shows how financially or personally motivated actors can reuse tradecraft seen in Iranian APT infrastructure, without matching the sophistication or targeting of state-aligned groups.
Hunt.io researchers uncovered the operation during a routine review of exposed servers in Iran using the AttackCapture feature, which indexes open directories and tags malware, scripts, and logs for analysis.
One directory on 185.221.239[.]162, hosted by Iranian ISP Dade Samane Fanava Company (PJS), contained 449 files across 59 subdirectories, including a .bash_history file, MHDDOS installer, multiple C-based flood tools, and botnet components.
TLS certificate history provided the key pivot: a single Let’s Encrypt certificate for *.server21[.]org (SHA-256: BA318B710978C277A1AD6F2DE81D7D2402607036D0C0E777EC75BC6B6E428974) was observed on February 14th and later found on 14 additional IPs.
Seven of those IPs were hosted by Hetzner in Finland and seven by Iranian ISPs, strongly indicating a purpose-built relay mesh rather than accidental certificate reuse.
A HuntSQL pivot on the wildcard domain surfaced further related infrastructure, including an OVH-hosted node at 212.74.39[.]128 (robot5.server21[.]org), suggesting the operator was diversifying exit points beyond Hetzner and local ISPs.
Censorship Bypass Meets DDoS
A config-client.yaml file in the exposed open directory described a KCP-based Paqet tunnel client, with 185.221.239[.]162 acting as the ingress and forwarding traffic on ports 8443 and 2053 to a Hetzner node (65.109.187[.]102), with control traffic on port 9999.
![IP Summary for 185.221.239[.]162 (Source : Hunt.io).](https://public-hunt-static-blog-assets.s3.us-east-1.amazonaws.com/3-2026/Iranian+Botnet+Exposed+via+Open+Directory+15-Node+Relay+Network+and+Active+C2+-+figure+2.png)
Paqet itself is an open-source raw-socket, KCP tunnel commonly used in Persian-language communities to bypass Iranian national filtering, supporting “kharej” (external) server and Iran-side client configurations.
From the outside, the node looked like a VPN relay, but the open directory showed it also hosted MHDDOS, custom SYN/UDP flood tools, and botnet source files.
The recovered bash history allowed researchers to reconstruct three phases of activity: initial tunnel deployment, DDoS tooling, and botnet build-out.
Early commands showed repeated Paqet, GRE forwarder, rathole-tunnel, and 3x-ui deployments, consistent with a commercial censorship-bypass service exposed to multiple users.
Later entries captured compilation and tuning of C-based flood tools (such as syn.c and flood.c) and MHDDOS runs against targets including a FiveM GTA server on 5.42.223[.]60:30120 and a web host at 194.147.222[.]151 (ports 80/443).
Reviewing WHOIS records for the server21 domain showed it was registered in 2023. The nameservers resolve through arvancdn[.]ir, an Iranian CDN and cloud provider.
![WHOIS results for server21[.]org (Source : Hunt.io).](https://public-hunt-static-blog-assets.s3.us-east-1.amazonaws.com/3-2026/Iranian+Botnet+Exposed+via+Open+Directory+15-Node+Relay+Network+and+Active+C2+-+figure+6.png)
The deployment script ohhhh.py reads a host:port|username|password credential list, opens 500 concurrent SSH sessions, uploads cnc.c, compiles it with gcc -pthread on each victim, then launches it in a detached screen for persistence.
Another script, yse.py, acts as a kill switch by issuing pkill -9 screen across infected hosts, allowing rapid teardown or payload refresh.
Although the cnc.c source was not recovered, strings from the compiled binary identify it as “BOT CLIENT v1.0,” using a beacon labeled “UnknownBOT ONLINE” to register each new victim with the C2 along with IP, hostname, and process ID.
Additional strings such as ATTACK_RUNNING, ATTACK_STOPPED, PINGSTATUS, and “Total packets: %llu” confirm a flood-focused design, while “[!] Disconnecting from CNC. Reconnecting in %d seconds” indicates built-in reconnection logic.
Because bots attempt to reconnect automatically, infected hosts must be treated as independently compromised even if the C2 or staging server is taken down.
Attribution Signals and Defender Takeaways
Multiple signals point toward an Iran-based operator: Iranian ISP hosting, DNS routed through ArvanCloud for server21[.]org, Farsi inline comments, and explicit use of Paqet “kharej” configurations tailored to Iranian censorship conditions.

The final phase revealed iterative botnet development and automation. Python scripts evolved from oh.py to ohhhh.py, accompanied by bot.c and cnc.c compiled repeatedly on the staging host and launched in screen sessions named bot, bott, and sss.
However, the opportunistic targeting of a game server and generic web infrastructure, combined with relatively simple tooling and early versioning, suggests a profit- or personal-motive actor rather than a state-directed APT.
Defenders should monitor for unusual gcc usage on servers, anomalous screen sessions running binaries named innocuously (such as “hex”), and high-concurrency SSH activity sourced from the same host.
Network teams should watch for Paqet-style KCP tunnels over UDP, especially where domestic IPs forward traffic to known Hetzner or OVH nodes tied to *.server21[.]org certificates.
Strong SSH hygiene (key-based auth, disabling password login, and rate limiting), coupled with detection for mass SSH attempts and open directories exposing operational files, can significantly reduce exposure to similar ran-linked botnet frameworks.
Indicators of Compromise
| IP addresses | Details |
|---|---|
| 185.221.239[.]162 | Open directory in AttackCapture |
| 65.109.187[.]102 | Shared TLS certificate |
| 65.109.184[.]58 | Shared TLS certificate |
| 65.109.196[.]138 | Shared TLS certificate |
| 65.109.204[.]0 | Shared TLS certificate |
| 65.109.209[.]147 | Shared TLS certificate |
| 65.109.213[.]131 | Shared TLS certificate |
| 65.109.214[.]203 | Shared TLS certificate |
| 185.221.239[.]84 | Shared TLS certificate |
| 185.221.239[.]121 | Shared TLS certificate |
| 185.221.239[.]160 | Shared TLS certificate |
| 185.221.239[.]188 | Shared TLS certificate |
| 185.236.38[.]79 | Shared TLS certificate |
| 185.236.38[.]81 | Shared TLS certificate |
| 194.147.222[.]183 | Shared TLS certificate |
| 212.74.39[.]128 | Shared TLS certificate |