Bench.sh: How Threat Actors Repurpose a Legitimate Benchmarking Tool for Post-Exploitation Recon

By Assaf Morag, Cybersecurity Researcher

We have observed repeated use of an open-source script called Bench.sh in real-world attack activity over the past several months.

Bench.sh is a convenience wrapper that downloads a network benchmarking tool (most commonly Speedtest), executes it, and presents the results in a clean, readable format. Originally developed by Teddysun and released as open source, the script itself is legitimate and widely used by administrators to validate the performance of VPS and cloud infrastructure.

However, our telemetry shows that attackers are also consistently using this script during intrusions. We observed it across multiple exploitation attempts targeting exposed services in our honeypots, including:

• JupyterLab
• Jupyter Notebook
• SSH servers
• Apache Tomcat
• PHP-based applications

Because of its recurring presence across different threat actors and attack paths, we conducted a deeper analysis of the wrapper to understand its operational role and provide actionable intelligence for SOC and incident response teams.

Key Takeaways about Threat Actor Usage of Bench.sh

• Bench.sh is a legitimate benchmarking tool that has become a standard post-exploitation reconnaissance step for threat actors. Attackers use it to quickly profile compromised systems for CPU performance, disk I/O, memory, network throughput, and GPU availability, helping them decide whether a host is worth monetizing for cryptomining, proxying, or DDoS activity.
• We observed Bench.sh across hundreds of attacks targeting multiple exposed services, including JupyterLab, Jupyter Notebook, SSH servers, Apache Tomcat, and PHP-based applications, indicating adoption across different threat actors and attack paths rather than a single campaign.
• Two distinct behavioral patterns emerged: reconnaissance-only and benchmarking followed by payload deployment. In some cases attackers abandoned targets after benchmarking (likely filtering out low-value hosts), while in others the script preceded deployment of cryptominers and Mirai botnet malware with full C2 infrastructure.
• Cybercrime forums and Telegram channels treat Bench.sh as a standard infrastructure validation tool, with threat actors running it immediately after provisioning VPS servers to verify performance before deploying bots, scanners, or C2 panels. It frequently appears alongside IP-region checkers and latency probes, reflecting mature cybercrime logistics workflows.
• Defenders can use Bench.sh execution as an early detection signal. Unexpected benchmark script runs on production servers, especially when combined with new cron jobs, unfamiliar outbound connections, or sequential script downloads, indicate an attacker is still in the evaluation phase, creating a window for containment before payload deployment.

Why Threat Actors Use Bench.sh

Bench.sh provides attackers with a fast way to understand the system they have just compromised.

The script automates checks such as:

• CPU performance
• Disk I/O speed
• Memory availability
• Network throughput
• Connectivity to public mirrors

In practice, this allows an attacker to quickly determine:

• Whether the host is worth monetizing
• If the system can sustain cryptomining
• If bandwidth is sufficient for proxying or DDoS activity
• Whether GPU resources may be present
• If the machine is throttled or sandboxed

In short, it acts as a post-exploitation reconnaissance tool that helps attackers decide whether to continue the intrusion or move on.

Observed Attacks in the Wild

Across several hundred observed attempts during the past couple of months, we identified two distinct behavioral patterns.

Pattern 1: Opportunistic Reconnaissance Only

In several cases, attackers ran Bench.sh and stopped afterward. This suggests they may have been:

• Checking for GPU availability
• Evaluating network quality
• Filtering out low-value targets

Our honeypots lack GPUs and do not provide strong network characteristics, which may explain why the attackers abandoned the intrusion after testing.

Pattern 2: Benchmarking Followed by Payload Deployment

In other attacks, the benchmarking stage was followed by additional payload downloads.

One observed intrusion involved retrieval of multiple scripts:

• load.sh: Prepares the environment for execution by setting up Linux utilities (SHA256: a86344620ce97d6c8c98ca41681ee58fac025f558118f9b9b11c89cd34bcc996)
• payload.sh: Deploys the main payload, a cryptominer and Mirai malware (SHA256: e57dbb59109cf956078ab184573f0bf18df9a0626401cc6ce85a845419fa028c)
• da.sh: Runs defense evasion command like disabling SELinux (SHA256: 1e95f8577ff291cb7aa62e798804a8ab73c99684d17ac973d481fd8a18b8090e)
• update.sh: Handles C2 communication to update the attacker (SHA256: c7813f789c5597ccd740dceb67898cdc4d51edfb3fd8e9e1c8fbbb1aa8512303)

The attack also dropped a cryptominer (SHA256: b0e1ae6d73d656b203514f498b59cbcf29f067edf6fbd3803a3de7d21960848d) and a Mirai binary (SHA256: a59c9100954f759717339c440521f04a20717eb285e2ccd4effab5f965e67e1c).

A Discord C2 communication

Mirai is a well-known botnet malware family that infects internet-connected devices by brute-forcing credentials and turning them into remotely controlled bots. These bots are typically used for:

• Distributed denial-of-service attacks
• Internet-wide scanning
• Further propagation

Since Mirai’s source code leaked in 2016, Mirai has evolved into one of the most persistent and adaptable botnet ecosystems on the internet.

VirusTotal Mirai detection details

Testing Bench.sh in the Lab

Sometimes a free tool may involve some more nefarious activity, whether it’s a free game or utility offered to naïve users or an underground tool (RAT, scanner etc.) that stores a backdoor or transmits the result to another threat actor. To rule this out and better understand Bench.sh runtime behavior, we downloaded the script and executed it in our lab environment.

Bench.sh website display

We monitored execution using Tracee, an open-source eBPF-based runtime security tool. 

Tracee monitoring output

From syscall and runtime evidence, the bench activity consisted primarily of:

• HTTP retrieval via curl
• File download activity
• Expected network syscalls

Bench.sh cli output, after testing our server

However, we did not observe:

• Shell execution chains
• Fork/exec bursts
• Disk benchmarking commands
• CPU stress operations

This indicates the script was downloaded but not executed within the captured trace window.

If the script had actually run, we would expect to see:

• Process spawning
• Network stress tests
• File I/O bursts
• Benchmark utilities launching

None of these syscalls or activities seems malicious or unrelated to its nature. In other words, this specific observation looked like a simple and straight-forward tool used by some for malicious behavior. 

Bench.sh Mentions in Cybercrime Discussions

Bench.sh is not only observed in attack telemetry, but also appears regularly in cybercrime conversations and threat actor exchanges.

We identified multiple references across forums and Telegram channels discussing:

• Use in compromised VPS infrastructure
• Deployment during automated exploitation
• Integration into botnet setup workflows

These mentions reinforce the idea that Bench.sh has become a standard reconnaissance step in attacker playbooks.

Infrastructure Validation in Cybercrime Discussions

In Telegram channels and hosting forums, we observed recurring references to Bench.sh. While benign on its own, its appearance in attacker discussions reveals how cybercriminals evaluate newly acquired infrastructure. 

In Telegram sales channels and hosting forums, Bench.sh is often executed immediately after provisioning a VPS, allowing operators to quickly verify CPU, I/O, and network throughput before deploying bots, scanners, or C2 panels. This highlights a common operational workflow: infrastructure validation comes before weaponization.

Notifications that highlight Bench.sh as an interesting tool to use (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

Geolocation and Routing Assessment

Interestingly, Bench.sh frequently appears alongside scripts such as IP-region checkers, censorship tests, or latency probes. This combination suggests actors are not only testing raw performance but also assessing geolocation behavior, routing stability, and potential filtering by Russian or Asian providers. 

Best practice tools for server checks (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

In several cases, the script was referenced in discussions about “clean VPS” availability, reinforcing that criminals treat hosting infrastructure like a commodity product, one that must be measured and quality-checked before being trusted for operations.

Message in Russian that explains about the Bench.sh for Russian networks inspection (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

Post that explains about the Bench.sh output in Chinese (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

From a cybercrime economy perspective, this reflects the maturation of cybercrime logistics. Just as legitimate DevOps teams validate cloud performance before production deployment, threat actors run standardized benchmarking tools to grade providers, compare hosting offers, and detect oversold servers. The presence of Bench.sh in these conversations shows a signal of pre-deployment staging activity, often appearing shortly before infrastructure is used for scanning, brute-forcing, phishing hosting, or panel deployment.

Takeaways for Security Teams

Understanding the tools attackers use, even legitimate ones, can make the difference between detecting an intrusion early and missing the weak signals that allow persistence.

Bench.sh is a clear example. The script itself is benign, but in the hands of attackers, it serves as a rapid capability-assessment tool that helps them determine how to monetize a compromised system.

Recognizing this early reconnaissance phase allows defenders to:

• Detect intrusions before payload deployment: Benchmark script execution on a production server that no administrator initiated is a strong signal worth investigating.
• Correlate suspicious benchmarking activity: Bench.sh execution combined with other post-exploitation indicators (new cron jobs, outbound connections to unfamiliar IPs, or tool downloads) strengthens the case for a true positive.
• Build detections for post-exploitation environment testing: Monitor for curl calls to bench.sh or related benchmarking domains, unexpected Speedtest executions, and sequential script downloads from the same source.
• Improve response playbooks: If Bench.sh appears in an incident timeline, treat it as an indicator that the attacker is still in the evaluation phase. Rapid containment at this stage can prevent payload deployment entirely.
• Learn from complementary threat intelligence from hacker communities: SOC and incident response teams can get an extra advantage by incorporating this intel. 

Understanding how attackers evaluate infrastructure is often the first step toward stopping them before they scale their operation.