12 minhigh
Release the RAVEN: An Offensive Reconnaissance and Attack Tool on Vulnerable Elasticsearch Nodes
LevelBlue SpiderLabs has released RAVEN, an open-source offensive security framework with 19 modules targeting Elasticsearch and Kibana environments. The tool automates reconnaissance, credential brute-forcing, exploitation of 8 tracked CVEs (three in CISA's KEV catalog, CVSS up to 10.0), Kibana-specific attacks, data exfiltration, and persistence via rogue users and long-lived API keys. Defenders should treat the release of this tool as an indicator that adversaries now have a consolidated, purpose-built toolkit for attacking exposed Elasticsearch/Kibana infrastructure.
Sens:▲ 24h
Showing defanged values
- filename~/.raven/activity.logDefault activity log file created by RAVEN during operations. Presence of this file on a host indicates RAVEN has been executed, whether authorized or unauthorized.
- pypi_packageraven-esPyPI package name for the RAVEN offensive framework. Presence of this package installed on a production or non-testing system may indicate unauthorized offensive tooling activity.
Detection / Hunteropenrouter
What Happened
A cybersecurity researcher has published a free, open-source tool called RAVEN that is designed to test the security of Elasticsearch and Kibana systems — the search and dashboard software used by many organizations to store and analyze sensitive data like customer records, logs, and financial transactions. The tool can automatically discover exposed systems, guess passwords, exploit known software flaws (including some that allow full remote control), steal data, and create hidden backdoor accounts that survive password changes. While RAVEN is intended for authorized security testing, its public availability means that attackers could also use it against organizations with unpatched or misconfigured Elasticsearch systems. Organizations running Elasticsearch or Kibana should immediately check whether their systems are exposed to the internet, verify that all 8 referenced vulnerabilities are patched, and ensure strong authentication and access controls are in place.
Key Takeaways
- RAVEN is a new open-source offensive security framework with 19 modules specifically targeting Elasticsearch and Kibana deployments, available via PyPI as 'raven-es'
- The tool tracks 8 CVEs (CVSS 7.5–10.0) including MVEL/Groovy scripting RCE, directory traversal, Kibana LFI, prototype pollution, and API key privilege escalation; three are listed in CISA's KEV catalog
- RAVEN supports full attack lifecycle from reconnaissance through post-exploitation including data exfiltration, persistence via rogue users and long-lived API keys, and destructive operations
- Default activity log path at ~/.raven/activity.log provides a detection artifact for defenders hunting for unauthorized RAVEN usage
- Nine Docker-based lab environments are included, each mapping to a specific vulnerability class with pre-seeded vulnerable Elasticsearch/Kibana versions
Affected Systems
- Elasticsearch 1.1.1 (MVEL scripting engine lab target)
- Elasticsearch versions vulnerable to Groovy scripting RCE (CVE-2015-1427)
- Elasticsearch versions vulnerable to snapshot directory traversal (CVE-2015-5531, CVE-2015-4165)
- Kibana versions vulnerable to LFI (CVE-2018-17246)
- Kibana versions vulnerable to prototype pollution RCE (CVE-2019-7609)
- Kibana versions with keystore disclosure (CVE-2019-7614)
- Kibana versions vulnerable to RCE (CVE-2024-7489)
- Internet-facing Elasticsearch instances on port 9200 and Kibana instances on port 5601
Vulnerabilities (CVEs)
copy:
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2014-3120 | Elasticsearch (MVEL scripting engine) | Remote code execution via MVEL scripting engine in Elasticsearch, allowing arbitrary command execution on the host. | |
| CVE-2015-1427 | Elasticsearch (Groovy scripting engine) | Remote code execution via Groovy scripting engine bypass in Elasticsearch, allowing arbitrary command execution. | |
| CVE-2015-5531 | Elasticsearch | Directory traversal vulnerability in Elasticsearch allowing read access to arbitrary files on the host. | |
| CVE-2015-4165 | Elasticsearch (snapshot feature) | Remote code execution via Elasticsearch snapshot repository feature allowing traversal and file access. | |
| CVE-2018-17246 | Kibana | Local file inclusion vulnerability in Kibana allowing attackers to read arbitrary files from the server. | |
| CVE-2019-7609 | Kibana | Prototype pollution vulnerability in Kibana leading to remote code execution via crafted requests. | |
| CVE-2019-7614 | Kibana | Kibana keystore disclosure allowing attackers to extract sensitive configuration data and credentials. | |
| CVE-2024-7489 | Kibana | Remote code execution vulnerability in Kibana exploitable via the tool's Playwright-based browser trigger. |
Attack Chain
- Reconnaissance: Fingerprint Elasticsearch cluster version, enumerate indices, detect anonymous access, and search for secrets in documents
- Access Testing: Bruteforce credentials from curated wordlists, analyze privilege escalation paths, and enumerate/manage API keys
- Exploitation: Exploit tracked CVEs including MVEL/Groovy scripting RCE, directory traversal, Kibana LFI, and prototype pollution for remote code execution
- Kibana Attacks: Perform Kibana-specific reconnaissance, exploit Kibana CVEs including automated RCE via Playwright browser trigger, and extract intelligence from saved objects
- Post-Exploitation: Exfiltrate entire indices to disk, establish persistence via rogue users and long-lived API keys that survive password rotations
- Cleanup: Reverse all actions from activity log to cover tracks and restore original state
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided in this article. It is a tool release announcement and prologue to a five-part blog series. Detection content may appear in subsequent installments.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR can detect the raven-es process execution, child process spawning patterns, and the ~/.raven/ directory creation. However, if the attacker runs RAVEN from a remote system against exposed Elasticsearch/Kibana ports, EDR on the target may only see network traffic, not the tool process itself. |
| Network Visibility | High | RAVEN communicates with Elasticsearch (port 9200) and Kibana (port 5601) over HTTP/HTTPS. Network monitoring can detect the scanning patterns, brute-force attempts, and anomalous API requests characteristic of RAVEN's 19 modules. |
| Detection Difficulty | Moderate | RAVEN's reconnaissance and exploitation generate distinctive HTTP API patterns against Elasticsearch and Kibana that can be detected with good network and application logging. However, distinguishing authorized penetration testing from adversarial use requires context about the source and authorization scope. |
Required Log Sources
- Elasticsearch audit logs (for API key creation, index access, authentication events)
- Kibana application logs
- Network flow logs (ports 9200 and 5601)
- Web application firewall logs for Elasticsearch/Kibana endpoints
- Endpoint detection logs for raven-es process execution
- DNS logs (if RAVEN is used through a proxy or against external targets)
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for processes named raven-es or Python processes executing from the ~/.raven/ directory, which would indicate the RAVEN tool is installed and running on a host in your environment. | EDR process execution logs, file system monitoring for ~/.raven/ directory creation | Reconnaissance / Initial Access | Low — legitimate penetration testers may use this tool during authorized engagements, but presence on production servers outside of sanctioned testing windows is suspicious. |
| Consider hunting for bursts of authentication failures followed by success against Elasticsearch API endpoints on port 9200, which may indicate RAVEN's bruteforce module is in use. | Elasticsearch authentication/audit logs, network flow logs for port 9200 | Credential Access | Medium — legitimate monitoring tools or applications may generate authentication failures; correlate with source IP reputation and timing patterns. |
| Consider hunting for creation of new Elasticsearch API keys or rogue user accounts that coincide with unusual external IP access patterns, as RAVEN's persist module creates long-lived API keys and backdoor accounts. | Elasticsearch audit logs for API key creation events, user creation events, security realm logs | Persistence | Low to Medium — API key creation is a legitimate administrative action, but keys created from unfamiliar source IPs or outside business hours warrant investigation. |
| Consider hunting for large-volume data reads or bulk index export patterns from Elasticsearch that originate from non-application source IPs, as RAVEN's exfil module downloads entire indices to disk. | Elasticsearch audit logs for scroll/search API usage, network flow logs for high-volume data transfer from port 9200 | Exfiltration | Medium — backup systems and legitimate data pipelines may perform bulk reads; correlate with source identity and expected data access patterns. |
| Consider hunting for HTTP requests to Kibana endpoints on port 5601 that include prototype pollution payloads or file inclusion patterns, as RAVEN's Kibana modules exploit CVE-2019-7609 and CVE-2018-17246. | Kibana application logs, reverse proxy/WAF logs for port 5601, network IDS alerts | Exploitation | Low — prototype pollution and LFI payload patterns in HTTP requests to Kibana are highly suspicious and rarely seen in legitimate traffic. |
Control Gaps
- Network firewalls allowing unrestricted access to Elasticsearch port 9200 or Kibana port 5601 from external networks
- Elasticsearch instances without X-Pack security enabled or with anonymous access permitted
- Lack of audit logging on Elasticsearch clusters, preventing detection of API key creation, rogue user creation, and bulk data access
- Unpatched Elasticsearch/Kibana versions vulnerable to the 8 tracked CVEs, especially the three listed in CISA KEV
- Absence of rate-limiting or brute-force protection on Elasticsearch authentication endpoints
Key Behavioral Indicators
- Process named 'raven-es' or Python interpreter executing RAVEN modules on a host
- Creation of ~/.raven/ directory and activity.log file on endpoint
- Rapid sequence of HTTP requests to Elasticsearch _cat, _cluster, _indices, and _search API endpoints from a single source (reconnaissance pattern)
- High volume of HTTP 401/403 responses followed by a 200 OK from Elasticsearch API (brute-force pattern)
- Creation of Elasticsearch API keys with long expiration or no expiration from non-administrative source IPs
- New user accounts created in Elasticsearch security realm from external or unusual source IPs
- HTTP requests to Kibana containing prototype pollution or path traversal payload patterns
- Bulk scroll API requests from non-application source IPs indicating index exfiltration
False Positive Assessment
Medium — RAVEN is a legitimate open-source security tool used by authorized penetration testers. Detection of raven-es or ~/.raven/ artifacts on a system may indicate sanctioned security testing rather than adversarial activity. Correlation with authorized engagement schedules, source IP reputation, and timing is necessary to distinguish legitimate use from attacks.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing all Elasticsearch and Kibana instances for internet exposure on ports 9200 and 5601, and restrict access to trusted internal networks or VPN where possible.
- Evaluate whether all 8 CVEs tracked by RAVEN (CVE-2014-3120, CVE-2015-1427, CVE-2015-5531, CVE-2015-4165, CVE-2018-17246, CVE-2019-7609, CVE-2019-7614, CVE-2024-7489) are patched in your Elasticsearch and Kibana deployments, prioritizing the three listed in CISA's KEV catalog.
- If your Elasticsearch deployment supports X-Pack security, consider verifying that authentication is enforced, anonymous access is disabled, and audit logging is enabled for API key creation, user creation, and data access events.
- Consider searching endpoints for the presence of the raven-es PyPI package or the ~/.raven/ directory to detect any unauthorized installation of the RAVEN tool.
Infrastructure Hardening
- Consider implementing network segmentation to isolate Elasticsearch and Kibana from general corporate networks, allowing access only from known application servers and administrative hosts.
- Evaluate whether a reverse proxy or WAF in front of Elasticsearch/Kibana can provide rate-limiting, brute-force protection, and payload inspection for known exploit patterns.
- If applicable to your environment, consider enabling Elasticsearch audit logging to capture authentication events, API key operations, index access, and configuration changes.
- Consider implementing TLS encryption for Elasticsearch transport and HTTP layers to prevent credential interception and data exposure in transit.
User Protection
- Consider reviewing Elasticsearch role assignments to ensure least-privilege access, preventing privilege escalation paths that RAVEN's privesc module could discover.
- Evaluate whether long-lived API keys in your Elasticsearch environment are necessary; consider rotating or expiring keys that were created without expiration dates.
- If your tooling supports it, consider monitoring for and alerting on new Elasticsearch user account creation, especially accounts created outside of normal administrative windows.
Security Awareness
- Consider informing database and search infrastructure teams about the public availability of RAVEN and the importance of keeping Elasticsearch/Kibana patched and properly secured.
- Where applicable, consider adding guidance to existing security awareness programs about the risks of exposing Elasticsearch and Kibana dashboards to the internet without authentication.
- If your organization conducts authorized penetration testing, consider adding RAVEN to the approved tooling list and establishing procedures to distinguish authorized testing from adversarial use.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping8 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
Persistence
Tactic
Credential Access
Tactic
Discovery
Tactic
Collection
Additional IOCs
- File Paths:
~/.raven/- Default RAVEN configuration and activity log directory. Presence on a system indicates the RAVEN tool has been installed and run.
- Command Lines:
- Purpose: Fingerprint and enumerate an Elasticsearch cluster's version, nodes, and attack surface | Tools:
raven-es| Stage: Reconnaissance |raven-es fingerprint -t <host> - Purpose: Bruteforce Elasticsearch credentials using curated wordlists | Tools:
raven-es| Stage: Access Testing |raven-es bruteforce -t <host> - Purpose: Detect and exploit tracked CVEs against Elasticsearch or Kibana targets | Tools:
raven-es| Stage: Exploitation |raven-es cve -t <host> - Purpose: Bulk exfiltrate Elasticsearch index data to local disk | Tools:
raven-es| Stage: Post-Exploitation |raven-es exfil -t <host> - Purpose: Establish persistent access via rogue users and long-lived API keys | Tools:
raven-es| Stage: Persistence |raven-es persist -t <host> - Purpose: Run comprehensive reconnaissance against a target with all modules orchestrated | Tools:
raven-es| Stage: Reconnaissance |raven-es all -t <host>
- Purpose: Fingerprint and enumerate an Elasticsearch cluster's version, nodes, and attack surface | Tools:
Stay currentSubscribe via RSS