Iran-linked botnet exposed after open directory leak revealed relay nodes, SSH scripts, and active C2 work

A suspected Iran-linked botnet operation was exposed after researchers found an open directory on an Iranian-hosted server that contained the actor’s working files, deployment scripts, DDoS tools, and an in-development bot client. Hunt.io said it discovered the exposed server on February 24, 2026 and later published its findings on March 17, describing the leak as a rare look into a live operation rather than a cleaned-up malware sample.

According to Hunt.io, the server at 185.221.239.162 exposed 449 files across 59 subdirectories. The contents included tunnel configuration files, Python deployment scripts, compiled DDoS binaries, C source files, and a credential list used for SSH-based targeting. The report also says an exposed bash history file documented the operator’s activity across tunnel setup, DDoS tooling, and botnet development.

Hunt.io linked the exposed server to a broader 15-node relay network by pivoting on a shared Let’s Encrypt TLS certificate tied to the wildcard domain *.server21.org. The researchers said they identified 14 additional IP addresses sharing the same certificate fingerprint, including systems hosted by Hetzner in Finland and others registered to Iranian ISPs.

What researchers found

Hunt.io said the open directory held more than generic server clutter. It contained the components needed to run infrastructure, deploy malware over SSH, and compile attack tools directly on victim systems. That included a Python script named ohhhh.py, a separate script called yse.py, and source code for a bot client written in C.

The exposed bash history gave the clearest view into how the operator worked. Hunt.io said the commands fell into three broad phases: tunnel deployment, DDoS tooling development, and botnet buildout. The firm also noted Farsi comments and Arabic-script keyboard artifacts in the command history, which it cited as evidence that the operator was likely based in Iran or worked in a Farsi-language environment.

Hunt.io’s report does not claim a confirmed state attribution. The article describes the activity as Iran-linked based on infrastructure, language evidence, and hosting patterns. That distinction matters because “Iran-linked” is not the same as a confirmed government operation.

Relay network and infrastructure details

The report says the same infrastructure supported both botnet activity and traffic relaying. A file named config-client.yaml described a KCP-based tunnel using Paqet, which Hunt.io identified as an open-source tunneling tool designed to bypass internet filtering in Iran. The configuration reportedly forwarded encrypted traffic from an Iranian server to a Hetzner exit node in Finland.

Researchers also found evidence of 3x-ui, a web-based proxy management panel. Hunt.io said that suggested the infrastructure may have doubled as a commercially operated VPN relay service alongside the offensive tooling. That conclusion comes from the researchers’ interpretation of the exposed configuration and panel artifacts.

How the botnet spread

At the center of the deployment workflow was ohhhh.py, which Hunt.io described as a Python script that read credentials in the format host:port|username|password and launched up to 500 concurrent SSH sessions against target machines. Once a session succeeded, the script fetched the bot client source code from the staging server, compiled it locally with gcc -pthread, and launched it inside a detached screen session.

That local compilation step is important because it avoids transferring a ready-made binary. Hunt.io said this approach can weaken simple hash-based detections, since the final executable gets built on the victim host rather than downloaded as a known malware file. The compiled binary was reportedly renamed hex, which blends in more easily during casual system review.

The bot client identified itself as BOT CLIENT v1.0 and sent a beacon containing the victim IP address, hostname, and process ID as UnknownBOT ONLINE, according to Hunt.io. The researchers also said the code included reconnection logic so infected systems would keep trying to reach the command server even if the staging host went offline.

A second script, yse.py, acted as a kill switch. Hunt.io said it could issue pkill -9 screen across infected systems to shut down running bot sessions in bulk.

DDoS tooling found in the leak

The exposed materials included several denial-of-service tools and related source files. Hunt.io said it found custom C tools named syn.c, flood.c, and au.c, along with a cloned copy of MHDDOS from GitHub. The report also says the operator compiled these tools directly on the staging host.

Hunt.io cited specific targets from the bash history, including a FiveM GTA server on 5.42.223.60:30120 and two HTTP or HTTPS-facing hosts. The presence of both custom tooling and public DDoS code suggests the operator mixed original and off-the-shelf components rather than relying on one framework alone. That is an inference based on the toolset Hunt.io published.

What the leak included

Category	Examples Hunt.io said it found
Infrastructure files	Tunnel configs, relay settings, certificate-linked hosts
Botnet deployment	ohhhh.py, yse.py, C-based bot client
Attack tooling	syn.c, flood.c, au.c, MHDDOS clone
Operator artifacts	Bash history, credential list, inline Farsi comments
Victim-side behavior	Local compilation with gcc, detached screen execution

Why this exposure matters

Open directory leaks usually show misconfiguration. This one showed operations in progress. Hunt.io said the exposed environment contained both infrastructure setup and active attack development, which gave defenders visibility into how the actor staged tunneling, deployed bots, and built DDoS capabilities.

The report also highlights a simple but effective intrusion path. The botnet did not depend on a novel exploit in the published workflow. Instead, it relied on credential-driven SSH access at scale. That means organizations with weak passwords, exposed SSH services, or loose access controls remain vulnerable even when they are fully patched. That conclusion follows from Hunt.io’s description of the ohhhh.py deployment method.

What defenders should do

• Block and monitor the IP addresses and domains listed in Hunt.io’s indicators section. Hunt.io published IOCs tied to the relay network, certificates, and staging infrastructure.
• Harden SSH by enforcing key-based authentication, disabling direct root login where possible, and restricting brute-force or high-volume concurrent access. These steps directly address the credential-based SSH workflow described in the report.
• Hunt for unusual gcc compilation activity on servers, especially when followed by detached screen sessions or unfamiliar binaries such as hex. Hunt.io explicitly highlighted on-host compilation as a meaningful signal.
• Review systems for the filenames and hashes published by Hunt.io, including ohhhh.py, yse.py, and the bot client.
• Investigate relay and tunneling activity that connects Iranian-hosted systems to foreign exit nodes through KCP or similar tooling. That behavior appeared in the exposed tunnel configuration.

Quick facts

Item	Detail
Discovery date	February 24, 2026
Report publication date	March 17, 2026
Exposed server	185.221.239.162
Files exposed	449
Subdirectories exposed	59
Network size Hunt.io described	15 nodes total
Key deployment method	SSH with on-host compilation

FAQ