Full Report
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 interact...
Analysis Summary
# Incident Report: SeleniumGreed Cryptomining Campaign
## Executive Summary
Wiz Research uncovered the ongoing "SeleniumGreed" threat campaign, which exploits publicly exposed and misconfigured Selenium Grid services to deploy cryptominers. The attack leverages the inherent ability of the Selenium WebDriver API to execute remote commands, resulting in resource hijacking for cryptojacking. The campaign demonstrates a significant risk associated with improperly secured testing infrastructure exposed to the internet.
## Incident Details
- Discovery Date: July 25, 2024 (Report publication date)
- Incident Date: Ongoing, detection reported July 25, 2024
- Affected Organization: Multiple organizations hosting exposed Selenium Grid instances (Not specified individually)
- Sector: Cloud Compute / Technology / Web Application Testing
- Geography: Global (Implied, as Selenium is widely used)
## Timeline of Events
### Initial Access
- Date/Time: Undetermined (Ongoing campaign)
- Vector: Software Misconfiguration (Exposed Selenium Grid service)
- Details: Attackers leveraged the lack of default authentication on publicly exposed Selenium Grid API endpoints.
### Lateral Movement
- Details: The attacker reportedly used compromised Selenium nodes' workloads/instances as command and control (C2) infrastructure for hosting payloads and as proxies for the mining pool.
### Data Exfiltration/Impact
- Details: Primary impact was **Resource Hijacking** (Cryptojacking). No explicit data exfiltration was mentioned, but the ability to read/download files exists via the exploited API.
### Detection & Response
- Date/Time: Prior to July 25, 2024 (Detection by Wiz Research)
- Details: Detected via cloud threat monitoring (Wiz Research). Response actions are focused on remediation guidance provided by the research group.
## Attack Methodology
- Initial Access: Functionality Abuse (Exploiting Selenium WebDriver API features on misconfigured, internet-exposed Selenium Grid services).
- Persistence: Not explicitly detailed, but using compromised nodes as C2 suggests transient persistence tied to the miner execution.
- Privilege Escalation: Not required, as the WebDriver API allows direct or near-direct system interaction.
- Defense Evasion: Using modified XMRig miners packed with custom UPX headers; utilizing compromised nodes as C2/proxy infrastructure to obfuscate the ultimate source/destination.
- Credential Access: Not explicitly mentioned as a primary goal.
- Discovery: Likely inherent to the execution environment once the remote command functions are active.
- Lateral Movement: Leveraging existing compromised compute resources (other Selenium nodes) for infrastructure purposes.
- Collection: N/A (Focus on resource consumption/mining).
- Exfiltration: C2 communication and mining pool connection.
- Impact: Resource Hijacking (Cryptojacking).
## Impact Assessment
- Financial: Costs associated with unauthorized cloud compute usage (cryptojacking).
- Data Breach: No specific data breach of sensitive customer/organizational data was reported, but file reading/downloading capabilities via the API present a high potential risk.
- Operational: Potential degradation of performance on affected compute resources due to cryptomining activities.
- Reputational: Potential reputational damage for organizations hosting insecure testing environments.
## Indicators of Compromise
- *Note: IOCs are not provided in the article, only attack techniques.*
- Network Indicators: Communication with mining pools (specific pools unknown).
- File Indicators: Modified XMRig miner binaries packed with custom UPX headers.
- Behavioral Indicators: Execution of Python scripts (via reverse shell) designed to download and run miners on the compromised host originating from Selenium WebDriver commands.
## Response Actions
- Containment measures: Not detailed as official organizational response; recommended containment is firewalling/securing the Selenium Grid API endpoints.
- Eradication steps: Removal of deployed cryptominers and associated scripts. Disabling public access to the service.
- Recovery actions: Reconfiguring Selenium Grid instances to adhere to secure deployment practices (e.g., internal network only).
## Lessons Learned
- Selenium Grid’s powerful API, designed for testing, can be trivially leveraged for system compromise if exposed externally without authentication.
- Testing infrastructure (like Selenium Grid) often lacks the security hardening applied to production environments, making them soft targets when publicly accessible.
- Reliance on default security settings for non-production tools deployed in accessible environments is critically dangerous.
## Recommendations
- **Never** expose Selenium Grid services or their API management interfaces to the public internet.
- Implement strong network segmentation (firewalls, security groups) to restrict access to Selenium Grid instances strictly to internal testing teams and necessary IP ranges.
- Enable authentication mechanisms, if available, on all management APIs for testing infrastructure.
- Regularly audit running services in cloud environments for known vulnerable configurations (e.g., unauthenticated APIs).