Release the RAVEN: Destruction and Discipline
RAVEN is an open-source offensive security framework targeting Elasticsearch and Kibana. Part 5 of the series demonstrates the tool's destructive capabilities including index deletion, document wiping, mapping corruption, Meow attack simulation, and five denial-of-service modes. All destructive operations are gated behind a triple-confirmation safety system and logged for auditability, with a cleanup module that reverses reversible actions.
- filename~/.raven/activity.logDefault RAVEN activity log file. Contains a record of every state-changing action performed during an engagement. Used by the cleanup module to reverse actions.
- pypi_packageraven-esOffensive security tool for Elasticsearch and Kibana available on PyPI. An attacker with network access to an Elasticsearch cluster could install and use this tool to perform reconnaissance, exploitation, persistence, and destructive operations.
Detection / Hunteropenrouter
What Happened
A security researcher published a tool called RAVEN that can test Elasticsearch databases for security weaknesses. This article demonstrates the tool's ability to delete data, corrupt database structures, and overwhelm servers with resource exhaustion attacks. The tool includes safety mechanisms to prevent accidental damage during authorized testing and a cleanup feature to undo changes afterward. Organizations using Elasticsearch should ensure their clusters require authentication, are not exposed to the internet, and monitor for unusual administrative actions.
Key Takeaways
- RAVEN is an open-source offensive security framework for Elasticsearch and Kibana with 19 modules spanning reconnaissance, exploitation, persistence, destruction, and cleanup
- Destructive capabilities include index deletion, document wiping via delete-by-query, mapping corruption with garbage fields, Meow attack simulation, and five denial-of-service modes
- Triple-gated safety system (--confirm-writes, --confirm-destroy DESTROY, --scope-file) prevents accidental damage during authorized testing
- Mapping explosion DoS creates persistent cluster state bloat that requires hours of reindexing to remediate and scales regardless of data volume
- Cleanup module reverses reversible actions (API keys, rogue users, snapshot repos) but cannot restore deleted or corrupted data
Affected Systems
- Elasticsearch clusters (versions 6.4.2, 6.8.6, 7.6.2 observed in lab environments)
- Kibana deployments associated with Elasticsearch clusters
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker gains network access to an Elasticsearch cluster (open port, exposed API, compromised credentials)
- Reconnaissance: RAVEN fingerprints the cluster, maps indices, hunts for secrets, cracks credentials, and identifies privilege escalation paths
- Exploitation: Legacy scripting engines, snapshot traversal, and CVE exploitation achieve code execution and data access
- Persistence: Rogue superuser accounts, credential-independent API keys, and Watcher-based backdoors planted to survive password rotations
- Destruction: Index deletion, document wiping, mapping corruption, or Meow simulation executed against target indices
- Impact: Denial-of-service modes (mapping explosion, expensive aggregations, deep pagination, shard flood, bulk hammer) cause resource exhaustion and persistent cluster degradation
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 capability demonstration, not a detection-focused report.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR can detect the raven-es Python process and its command-line arguments. However, if an attacker uses the Elasticsearch REST API directly via curl or scripts, EDR visibility decreases. The tool itself runs as a Python process on the attacker's machine, not on the Elasticsearch host. |
| Network Visibility | High | RAVEN communicates with Elasticsearch over HTTP on port 9200 (or configured HTTPS). All operations are API calls to standard Elasticsearch endpoints. Network monitoring can capture these requests, though distinguishing malicious API calls from legitimate admin activity requires context. |
| Detection Difficulty | Moderate | RAVEN uses standard Elasticsearch APIs, making individual requests difficult to distinguish from legitimate administrative activity. However, the volume and pattern of operations (rapid index deletion, mass document deletion, mapping field injection with raven_poison prefix, Meow corruption markers) create detectable anomalies. The raven_poison field prefix and _corrupted_by marker are specific indicators. |
Required Log Sources
- Elasticsearch audit logs (xpack.security.audit.enabled)
- Elasticsearch slow query logs
- Elasticsearch index lifecycle logs
- Network flow data to port 9200
- Process execution logs on systems with raven-es installed
- Elasticsearch cluster state change logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Look for rapid sequential index deletion events in Elasticsearch audit logs within a short time window, which would indicate T1485 Data Destruction activity | Elasticsearch audit logs with delete_index API calls | Impact | Medium - legitimate cluster maintenance or migration may involve index deletion |
| Hunt for delete_by_query API calls with match_all patterns that result in zero remaining documents, indicating document wiping while preserving index structure | Elasticsearch audit logs and slow query logs | Impact | Medium - developers may legitimately clear test indices |
| Look for rapid mapping changes that inject fields matching the raven_poison prefix pattern or an unusually high number of new dynamic fields in a short period | Elasticsearch cluster state change logs and mapping API responses | Impact | Low - the raven_poison prefix is a specific tool indicator |
| Hunt for documents containing _corrupted_by fields or values ending in -meow, which indicate Meow-style data corruption | Elasticsearch search results and document indexing logs | Impact | Low - the corruption marker is a specific indicator |
| Look for rapid creation of many small indices in succession (shard flood) or a sudden spike in unique field names in cluster state (mapping explosion), both indicating DoS activity | Elasticsearch cluster state logs, index creation events, and cluster health metrics | Impact | Medium - automated indexing pipelines may create indices in bursts |
Control Gaps
- Network-level controls cannot distinguish malicious Elasticsearch API calls from legitimate administrative requests when both use the same endpoints
- Monitoring systems that track index count will not detect delete-by-query operations that empty indices while preserving their structure
- Mapping corruption may go undetected by dashboards that do not monitor field count or mapping schema changes
- Standard DDoS protections may not catch metadata-based DoS attacks (mapping explosion, shard flood) that use few requests but cause persistent damage
Key Behavioral Indicators
- Elasticsearch API calls from raven-es process or Python scripts targeting administrative endpoints
- Mapping fields with raven_poison prefix pattern
- Documents containing _corrupted_by field with value raven
- Document values ending in -meow suffix
- Rapid sequential delete_index or delete_by_query API calls
- Sudden spike in cluster state field count without corresponding data ingestion
- Rapid creation of many small indices with few or no documents
- Deeply nested aggregation queries from non-standard source IPs
- Large number of concurrent scroll contexts opened in rapid succession
False Positive Assessment
High - RAVEN uses standard Elasticsearch APIs for all operations. Index deletion, document deletion, mapping changes, and resource-intensive queries are all legitimate administrative activities. Distinguishing malicious use from authorized administration requires context such as source IP, user identity, operation frequency, and change management records.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing Elasticsearch clusters for exposed ports (9200) and ensure authentication is enforced on all nodes.
- If your Elasticsearch cluster is internet-facing, consider restricting access to internal networks only via firewall rules or security groups.
- Consider reviewing Elasticsearch audit logs for recent delete_index, delete_by_query, or unusual mapping change events.
- If you suspect compromise, consider checking for unauthorized API keys via the _security/api_key endpoint and rogue users via the _security/user endpoint.
Infrastructure Hardening
- Evaluate whether Elasticsearch security features (X-Pack) are enabled with authentication and TLS encryption for both transport and REST layers.
- Consider implementing network segmentation to isolate Elasticsearch clusters from general corporate networks.
- If supported by your deployment, consider enabling Elasticsearch audit logging to record all security-related events including index deletion and mapping changes.
- Evaluate whether role-based access control limits which users can perform destructive operations like index deletion or mapping modification.
- Consider implementing alerting on cluster state size growth and field count per index to detect mapping explosion attacks.
User Protection
- Consider restricting Elasticsearch API access to specific administrative workstations via network policies.
- If applicable, evaluate whether MFA or IP allowlisting can be applied to Elasticsearch management interfaces.
- Consider monitoring for installation of the raven-es PyPI package on systems within your environment.
Security Awareness
- Consider incorporating awareness of Elasticsearch attack techniques into existing security training for teams managing search infrastructure.
- If your organization runs Elasticsearch, consider briefing infrastructure teams on the Meow attack pattern and mapping corruption techniques.
- Consider adding Elasticsearch-specific incident response procedures to existing documentation, covering index restoration from snapshots and reindexing workflows.
MITRE ATT&CK Mapping
Initial Access
Execution
Persistence
Credential Access
Additional IOCs
- File Paths:
~/.raven/activity.log- Default RAVEN activity log file. Contains a record of every state-changing action performed during an engagement. Used by the cleanup module to reverse actions.
- Command Lines:
- Purpose: Delete an entire Elasticsearch index and all its documents | Tools:
raven-es| Stage: Impact - Purpose: Delete documents matching a query while preserving index structure | Tools:
raven-es| Stage: Impact |raven-es -t <target> destroy --delete-by-query --index <name> - Purpose: Corrupt index field mappings by injecting garbage fields with dynamic mapping | Tools:
raven-es| Stage: Impact |raven-es -t <target> destroy --poison-mapping <index> - Purpose: Simulate Meow Attack by corrupting all non-system indices with random markers | Tools:
raven-es| Stage: Impact |raven-es -t <target> destroy --meow-sim - Purpose: Denial of service via resource exhaustion (mapping_explosion, expensive_agg, deep_pagination, shard_flood, bulk_hammer) | Tools:
raven-es| Stage: Impact |raven-es -t <target> dos --mode <mode> --duration <seconds> - Purpose: Create credential-independent API key for persistent access | Tools:
raven-es| Stage: Persistence |raven-es -t <target> apikey --create --name <name> - Purpose: Create rogue superuser account for persistent access | Tools:
raven-es| Stage: Persistence |raven-es -t <target> persist --create-user --backdoor-username <name> - Purpose: Reverse all logged actions from an engagement | Tools:
raven-es| Stage: Cleanup |raven-es -t <target> clean
- Purpose: Delete an entire Elasticsearch index and all its documents | Tools: