A cyber threat actor linked to Iran has had its entire operational infrastructure exposed following a significant security oversight, revealing a sophisticated botnet operation. The incident, uncovered on February 24, 2026, occurred when researchers discovered an open directory on a staging server, providing an unprecedented view into a live network of 15 nodes. This leak has exposed a mass SSH deployment framework, tools for distributed denial-of-service (DDoS) attacks compiled on compromised machines, and an actively developed bot client with a hardcoded command-and-control (C2) address.
The exposed server, located at IP address 185.221.239[.]162 and hosted on infrastructure registered to Dade Samane Fanava Company (PJS), an Iranian internet service provider, was identified during routine infrastructure scanning. The server contained a substantial amount of data, including 449 files spread across 59 subdirectories. Among the disclosed files were a tunnel configuration file, Python-based deployment scripts, compiled DDoS binaries, C-language source files for denial-of-service tools, and a list of credentials used for targeting victim systems via SSH.
Iran-Linked Botnet Exposed via Open Directory
The critical exposure was identified by analysts from Hunt.io using their AttackCapture™ feature, designed to index open directories across the internet. The researchers were conducting a routine review of Iranian-hosted infrastructure when they flagged the server. By tracing a shared Let’s Encrypt TLS certificate associated with the wildcard domain *.server21[.]org, they were able to identify an additional 14 IP addresses with a similar digital fingerprint. Seven of these IPs were hosted on infrastructure belonging to Hetzner Online GmbH in Finland, while the remaining seven were registered with Iranian ISPs, including Dade Samane Fanava Company (PJS) and Sindad Network Technology PJSC. The domain itself was registered in 2023, with its Domain Name System (DNS) records routed through ArvanCloud (arvancdn[.]ir), an Iranian Content Delivery Network (CDN) provider.
This network infrastructure served a dual purpose. A configuration file, named config-client.yaml, detailed the use of a KCP-based packet tunnel employing Paqet. Paqet is an open-source tool designed to circumvent Iran’s national internet filtering system. This setup involved the Iranian server forwarding encrypted traffic to an exit node located in Finland, hosted by Hetzner. The presence of 3x-ui, a web-based proxy panel that handles user account management and traffic quotas, suggests that a commercially operated VPN relay service was running concurrently with the malicious attack infrastructure.
Further insights into the threat actor’s operations were gleaned from an exposed bash history file. This log meticulously documented the operator’s activities across three distinct phases: the initial deployment of the tunnel, the development of DDoS tooling, and the subsequent build-out of the botnet. Crucially, inline code comments written in Farsi and raw Arabic-script characters resulting from input errors strongly indicate that the operator is based in Iran. The logged targets for DDoS attacks included a FiveM GTA server identified by the IP address 5.42.223[.]60 on port 30120, along with two other hosts accessible via HTTP/HTTPS. The attackers utilized custom C tools such as syn.c, flood.c, and au.c, as well as the MHDDOS tool, which was cloned from GitHub and compiled directly on the staging host.
SSH-Driven Mass Deployment Techniques
The primary mechanism for infecting victim machines involved a Python script named ohhhh.py. This script was designed to read credentials formatted as “host:port|username|password” and subsequently initiate 500 concurrent SSH sessions against target systems. Once an SSH session was established, the bot client source file, cnc.c, was retrieved from the staging server. It was then compiled on the victim machine using GCC with the `-pthread` flag and executed within a detached screen session. This strategy of compiling the bot client directly on the compromised host was a deliberate attempt to evade detection, as it eliminated the need to transfer pre-compiled executables, rendering traditional hash-based scanning methods largely ineffective.
The compiled binary was renamed simply “hex” on infected hosts—a nondescript name unlikely to trigger alerts during routine system monitoring. This bot client, self-identified as BOT CLIENT v1.0, would then register each newly infected host with a beacon transmitting the victim’s IP address, hostname, and process ID, labeled as “UnknownBOT ONLINE.” The built-in reconnection logic ensures that infected machines will persistently attempt to contact the C2 server, even if the staging server becomes unavailable. A secondary script, yse.py, functioned as a kill switch, enabling the operator to remotely terminate all running botnet sessions by executing the `pkill -9 screen` command across all compromised hosts.
Security professionals are advised to block all identified IP addresses associated with this operation. Monitoring for specific filenames and SHA-256 hashes linked to ohhhh.py, yse.py, and the cnc binary is also recommended. To counter the credential-driven infection method employed by this actor, it is crucial to harden SSH access. This includes enforcing key-based authentication, disabling root login, and implementing restrictions on concurrent sessions. Furthermore, security teams should flag any unexpected GCC compilation activity on servers, as on-host binary building serves as a significant indicator of threats that may bypass standard binary-level detection mechanisms.