Iranian Botnet Exposed via Open Directory: 15-Node Relay Network and Active C2

Threat actors make mistakes. Sometimes those missteps are subtle; a misconfigured server, a reused TLS certificate. Other times, operators leave a directory open on their own staging infrastructure, exposing deployment scripts, configuration files, bash history, and more for anyone willing to look.

This research builds on our recent analysis of Iranian APT infrastructure, but represents a different layer of that ecosystem: a financially or personally motivated operator rather than a state-directed one.

During a routine review of exposed servers in Iran using AttackCapture™, Hunt.io researchers identified a threat actor's full working environment: a censorship bypass tunnel network spanning Finland and Iran, an SSH-based botnet framework, and a compiled bot client with a hardcoded C2 address still under active development.

Here is what the exposed directory revealed:

Key Findings

• A 15-node relay network exposed by a single TLS certificate. Pivoting on a shared certificate fingerprint surfaced 15 servers, seven hosted on Hetzner in Finland and seven registered to Iranian ISPs.

• On-host compilation to dodge binary detection. Rather than pushing pre-built binaries, the operator compiled DDoS tools directly on victim machines using gcc. The compiled bot client was also renamed "hex" on infected hosts.

• SSH mass deployment driven by a credential list. A Python script called ohhhh.py reads credentials in a host:port|username|password format and opens 500 concurrent SSH sessions, compiling and launching the bot client on each host automatically.

• The bash history documented the full operation. The exposed .bash_history captured three distinct phases of work: standing up the tunnel network, building and testing DDoS tooling against live targets, and iterative botnet development across multiple script versions.

• The same infrastructure runs censorship bypass and attack tooling. The config-client.yaml file confirms the host forwards traffic to a Hetzner exit node via KCP tunneling, while the same server staged all botnet and DDoS components.

• Bots reconnect automatically after disconnection. Strings recovered from the compiled binary explicitly reference reconnection logic, meaning infected hosts should be treated as independently compromised regardless of whether the C2 is reachable.

Here is how we found it, and what each piece revealed.

Initial Discovery in Hunt.io

At times, interesting open directories really are like finding a needle in a haystack. Most contain log files, forgotten backup archives, and the occasional developer testing something they shouldn't. Every so often, these operational security failures turn their working environment into a collection opportunity, offering a window into attacker tactics.

Hunt.io's AttackCapture feature indexes open directories observed across the internet and allows users to filter by country, hosting network, tagged malware, and more. One entry, captured on February 24th, stood out: 185.221.239[.]162:8080.

The server is hosted on infrastructure registered to Dade Samane Fanava Company (PJS), an Iranian ISP. A total of 449 files across 59 subdirectories provided researchers plenty to review and gain a picture of the files intent.

Automatic tagging allows for a quick overview of what the directory contains. From Figure 1, we can see: an MHDDos installation folder, a .bash_history file, and a MITRE ATT&CK tag (T1016 - System Network Configuration Discovery).

Among the files recovered were a tunnel client configuration file (config-client.yaml), a Python-based botnet script, a compiled DDoS binary, multiple C-language denial-of-service files, and IP addresses associated with SSH credentials.

Combined, the rest of this post will attempt to tell the complete story of how the actor built their network, and how it was managed and later weaponized.

Infrastructure Analysis

Taking a look at the IP summary on 185.221.239[.]162 in Hunt showed three additional open ports/services were active: 22/SSH, an unidentified service on port 2053, and 8443/HTTP. The host is also flagged with a 'Potential Malicious Open Directory' warning.

Checking the TLS certificate history revealed a single active Let's Encrypt issued certificate for *.server21[.]org, first observed on February 14th, ten days before the open directory was captured. That certificate (SHA-256: BA318B710978C277A1AD6F2DE81D7D2402607036D0C0E777EC75BC6B6E428974) became a pivot point that led to a broader network.

A quick and easy pivot using the Associations tab surfaced 14 IPs sharing the same fingerprint, seven hosted by Hetzner Online GmbH in Finland, and seven registered to Iranian ISPs Dade Samane Fanava Company (PJS) and Sindad Network Technology PJSC. This does not appear to be a simple case of certificate reuse, but a managed relay network deployed by a single operator.

To further discover related servers, it was decided to pivot on the wildcard domain using HuntSQL.

Example Query:

SELECT
    *
FROM
    certificates
WHERE
    hostnames LIKE '%*.server21.org%'

                
Copy

Output:

The results from the HuntSQL query revealed three Hetzner 65.109.0[.]0/16 IPs previously seen in Figure 4:

• 65.109.204[.]0

• 65.109.196[.]138

• 65.109.209[.]147

Additionally, at the bottom of the screenshot, is a second, different certificate hash (5C41C075BFB1FCB85095B539E0C97A07C62379518AE1289677B118C550AFB5D0) hosted at 212.74.39[.]128, on the OVH SAS network, located in London. This suggests the attacker sought to not only expand, but diversify their relay network using a renewed certificate belonging to an ASN outside of Hetzner and the Iranian ISP. The IP resolves to a single domain, robot5.server21[.]org and follows the naming pattern seen with the Finnish nodes, increasing the likelihood this infrastructure is linked to the same operator.

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. DNS is routed for the relay network through Iranian infrastructure, while the exit nodes are located in Finland.

A configuration file in the directory named config-client.yaml describes a KCP-based paqet tunnel client where 185.221.239[.]162 acts as the ingress, forwarding traffic on ports 8443 and 2053 to 65.109.187[.]102, one of the Hetzner nodes identified earlier. The paqet control channel runs on port 9999.

Paqet is an open-source tunneling tool built specifically to bypass Iran's (and other regions') national filtering system. The document refers to a "kharej" setup, commonly used in Persian-language network circumvention communities, meaning "abroad". The tool uses KCP over UDP with AES encryption to resist deep packet inspection.

From the outside, this IP presents itself as a VPN relay running common ports. The open directory made everything else visible as to what the actor was up to.

With the staging server identified, the certificate history and open ports provided the first pivot points into the broader network.

Bash History as an Intelligence Source

An exposed bash history file recovered from the server documented the full working session, from initial setup through active attack development, providing a clear window into how the operator thinks and operates.

We'll break this history up into three phases, each revealing a different dimension of the operation.

Phase 1 - Tunnel Deployment

The earliest commands show the operator standing up the relay network. Multiple executions of the paqet tunnel deployment script, alongside installations of sepehr-GRE-FORWARDER, rathole-tunnel, and ultimately 3x-ui, indicating the person behind the screen did some iterative troubleshooting. The same scripts were run repeatedly, suggesting possible network instability.

3x-ui is a web-based proxy panel with built-in user account management, traffic quotas, and subscription controls. Its presence is consistent with a service offering to multiple users rather than personal use. Our assessment is that this network is operated commercially, possibly providing censorship-bypass access to users inside Iran. This hypothesis is based on network lifespan and deployment scale, though no direct payment infrastructure was recovered to confirm.

Phase 2 - DDoS Tooling

The command history shifts abruptly into attack development. Multiple custom C tools were compiled directly on the host: syn.c, flood.c, and au.c, each representing raw socket SYN flood and UDP flood implementations. MHDDOS was cloned from GitHub, configured with live proxy lists, executed against two targets: 5.42.223[.]60 on port 30120, the standard FiveM GTA server port, and 194.147.222[.]151 on ports 80 and 443.

Significant effort was put into attacking the game server, including tuning threat counts, memory limits, and kernel parameters to maximize throughput. Additional information could not be identified whether the operator had a grievance against the game, or if this was a paid DDoS order.

Phase 3 - Botnet Development

The final phase showed a transition from manual attacks to building a persistent, distributed attack capability. Python scripts evolved across multiple versions: oh.py through ohhhh.py, and development of bot.c and cnc.c through repeated compile and test cycles. Screen sessions, named bot, bott, and sss indicated background processes running during development.

Inline code comments written in Farsi appear throughout the command history, including notes on memory management and threading guidance from the Python scripts. A keyboard input error produced raw Arabic-script characters, reinforcing our assessment.

The full picture of what was built during this phase, including the command-and-control, will be covered in the following section.

Botnet Scripts & Binaries

With a clear motive and timeline established, this section will take a brief look at the malicious tools themselves. Three different files make up the core of the botnet: ohhhh.py, which handles deployment, yse.py, which functions as a kill switch, and cnc.c, the bot client, which is compiled and executed on every recruited host.

Deployment and Management

ohhhh.py reads credentials from a file in host:port|username|password format and establishes SSH connections to each victim across 500 concurrent threads. Once a connection is established, cnc.c is pulled from the directory, compiled on the victim host with gcc -pthread, and launched inside a detached screen session. SSH reconnection instructions are then printed for each successful infection, operating as a live deployment log for the operator.

The C code is renamed hex, which is somewhat inconspicuous and may not immediately raise alarms. Modern EDRs on larger networks should be able to monitor and flag gcc usage, though this may not always be the case.

yse.py monitors the deployed infrastructure but serves a single purpose: running pkill -9 screen across every host. It can be inferred that the server operator has refined their workflow enough that a standalone script is deemed necessary to teardown, push updated payloads, abort an attack, or reduce exposure if detected.

cnc.c

The cnc.c source was not recoverable during our research. However, the compiled binary contained multiple strings that allowed for gaining a deeper understanding of its behavior.

Immediately viewable in the above Figure are strings indicating the program is very creatively referred to as BOT CLIENT v1.0 and registers each newly infected host to the C2 server with a beacon containing the victim's IP address, hostname, and process ID labeled UnknownBOT ONLINE. The remaining visible strings refer to the command set (ATTACK_RUNNING, ATTACK_STOPPED, STOP, EXIT), and connectivity confirmation via PINGSTATUS. A packet counter string (Total packets: %llu) confirms the primary purpose is flooding hosts by volume.

Reconnection logic ([!] Disconnecting from CNC. Reconnecting in %d seconds) indicates bots are likely designed to persist through downtime, so takedown of the staging server may not immediately affect already deployed bots. Recruited hosts should be treated as independently compromised regardless of whether a connection to the C2 is active or not.

It's likely cnc.c is a lightly modified public kit or an early-stage custom build, as the version is currently set at v1.0.

With the technical picture complete, the infrastructure and tooling offer several clues about who is behind this operation.

Threat Actor Assessment

Among indicators such as the Iranian ISP hosting, ArvanCloud DNS routing, native Farsi comments, and a relay network purposefully built to skirt Iran's filtering, the individual or group behind this malicious activity is most likely based within the country or is very comfortable with the language.

This does not appear to be linked to state-directed activity, as the target selection that was able to be observed had no geopolitical signatures. Furthermore, the tooling appears functional, but not sophisticated, and the version suggests capabilities are still being built.

With the actor's profile established, here is what defenders can take away from the techniques observed in this operation.

Mitigation Strategies

For defenders, the controls below that this operation sought to evade, for example: hash-based detection, source IP attribution, and binary scanning, are worth revisiting to ensure detections are in place:

• Block the identified IP address

• Monitor for similar file names and hashes discussed above

• Harden SSH accounts (security basics, best practices)f

Conclusion

Our research began with a single open directory captured during routine monitoring using AttackCapture, and ended with a documented network of 15 servers, a credential-driven botnet, and a compiled C2 client hardcoded to the same staging IP.

The bash history alone walked through three phases of work: tunnel deployment, DDoS tooling, and botnet buildout, producing a rare end-to-end picture of how this operator built and managed their infrastructure.

One exposed server unraveled an entire operation. Hunt.io gives your team the visibility to find and track malicious infrastructure before it becomes an incident. Book your free demo today.

Indicators of Compromise

The following indicators were identified during this investigation and can be used to detect or block related infrastructure.