Iran-Linked Botnet Exposed After Open Directory Leak Reveals 15-Node Relay Network

A threat actor with ties to Iran has had their entire working infrastructure exposed after carelessly leaving an open directory on their own staging server, handing researchers a rare look into a live botnet operation.

The leak revealed a 15-node relay network, a mass SSH deployment framework, DDoS tooling compiled on victim machines, and a bot client with a hardcoded command-and-control (C2) address still actively under development.​

The exposure surfaced on February 24, 2026, when a server at IP 185.221.239[.]162, hosted on infrastructure registered to Dade Samane Fanava Company (PJS), an Iranian ISP, was flagged during routine scanning.

The server contained 449 files across 59 subdirectories, including a tunnel configuration file, Python-based deployment scripts, compiled DDoS binaries, C-language denial-of-service source files, and a credential list used to target victim systems via SSH.​

Hunt.io analysts identified the exposed server during a routine review of Iranian-hosted infrastructure using their AttackCapture™ feature, which indexes open directories across the internet.

By pivoting on a shared Let’s Encrypt TLS certificate tied to the wildcard domain *.server21[.]org, researchers uncovered 14 additional IP addresses sharing the same fingerprint — seven hosted on Hetzner Online GmbH in Finland, and seven registered to Iranian ISPs including Dade Samane Fanava Company (PJS) and Sindad Network Technology PJSC. The domain was registered in 2023, with DNS routed through ArvanCloud (arvancdn[.]ir), an Iranian CDN provider.​

The same infrastructure served a dual purpose. A configuration file named config-client.yaml described a KCP-based packet tunnel using Paqet — an open-source tool built to get around Iran’s national internet filtering system — where the Iranian server forwarded encrypted traffic to a Hetzner exit node in Finland.

The presence of 3x-ui, a web-based proxy panel with user account management and traffic quotas, pointed toward a commercially operated VPN relay service running alongside the attack infrastructure.​

An exposed bash history file laid out the operator’s working session across three distinct phases: tunnel deployment, DDoS tooling development, and botnet buildout.

Inline code comments written in Farsi and raw Arabic-script characters from keyboard input errors confirmed the actor is likely Iran-based.

DDoS targets in the history included a FiveM GTA server at 5.42.223[.]60 on port 30120 and two HTTP/HTTPS-facing hosts, with custom C tools — syn.c, flood.c, and au.c — alongside MHDDOS cloned from GitHub and compiled directly on the staging host.​

SSH-Driven Mass Deployment

The core of this botnet’s infection method was a Python script called ohhhh.py, which read credentials formatted as host:port|username|password and opened 500 concurrent SSH sessions against victim machines at once.

Once a session was live, the bot client source file cnc.c was pulled from the staging server, compiled on the victim machine using gcc -pthread, and launched in a detached screen session.

This on-host compilation tactic was a clear move to sidestep binary detection, since no pre-built executable is ever transferred, making standard hash-based scanning largely useless against it.

The compiled binary was renamed hex on infected hosts — a bland name unlikely to trigger alerts during a routine system check. ​

The bot client, self-labeled BOT CLIENT v1.0, registered each newly infected host with a beacon carrying the victim’s IP address, hostname, and process ID as UnknownBOT ONLINE.

The binary’s built-in reconnection logic means infected machines will keep trying to reach the C2 even if the staging server goes offline.

A secondary script, yse.py, served as a kill switch, letting the operator wipe all running sessions remotely by running pkill -9 screen across every infected host.​

Defenders should block all identified IP addresses tied to this operation and monitor for the specific filenames and SHA-256 hashes linked to ohhhh.py, yse.py, and the cnc binary.

Hardening SSH access — by enforcing key-based authentication, disabling root login, and restricting concurrent sessions — directly counters the credential-driven method this actor relied on.

Teams should also flag unexpected gcc compilation activity on servers, as on-host binary building is a significant indicator that standard binary-level detections may not catch this type of threat.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.