11 minhigh
Release the RAVEN: Data Heist and Persistence
RAVEN is an offensive tool targeting Elasticsearch deployments that enables bulk data exfiltration, credential-independent persistence via API keys, and multi-layered backdoor mechanisms. The tool exfiltrates data through Scroll/PIT API pagination or stealthier server-side snapshot operations. Persistence is established through rogue superuser accounts, non-expiring API keys, and Elasticsearch Watcher scheduled tasks that automatically recreate deleted backdoor components.
Sens:▲ 24hConf:high
Showing defanged values
- cveCVE-2015-5531Allows file read through the Elasticsearch snapshot API, referenced in Part 2 of the series.
- filename~/.raven/activity.logRAVEN activity log containing timestamped operations and reverse_hint fields for automated cleanup. Presence on a host indicates RAVEN was executed there.
- filename/tmp/raven_repoDefault filesystem path used by RAVEN for rogue snapshot repository registration on the Elasticsearch server.
- pypi_packageraven-esOffensive Elasticsearch exploitation tool available on PyPI. Used for data exfiltration, API key manipulation, and persistence in Elasticsearch clusters.
Detection / Hunteropenrouter
What Happened
A security research tool called RAVEN demonstrates how attackers can steal all data from Elasticsearch databases and maintain permanent access even after defenders change passwords. The tool can copy entire databases to files, create hidden administrator accounts with service-like names, generate API keys that survive password changes, and set up automated scheduled tasks that recreate these backdoors if they are deleted. Organizations using Elasticsearch should audit their clusters for unauthorized API keys, unexpected user accounts, and suspicious scheduled Watcher tasks. Breaking the persistence requires finding and removing all three mechanisms, starting with the Watcher.
Key Takeaways
- RAVEN tool exfiltrates entire Elasticsearch databases via Scroll/PIT API pagination or stealthier server-side snapshot operations that are invisible to network monitoring
- Snapshot-based exfiltration requires only two API calls to register a rogue repository and create a snapshot, with all data movement occurring server-side within the Elasticsearch process
- API keys provide credential-independent access that survives password rotations and account disabling; keys do not expire by default in Elasticsearch
- Three-layer persistence chain: rogue superuser account, long-lived API key, and Elasticsearch Watcher that automatically recreates deleted backdoor components on a configurable interval
- Activity log at ~/.raven/activity.log records all operations with reverse_hint fields for automated cleanup; presence on a host indicates RAVEN was executed
Affected Systems
- Elasticsearch 7.17.22 (unsecured configuration without authentication)
- Elasticsearch 7.17.22 with X-Pack security enabled
- Elasticsearch clusters with exposed port 9200 or compromised Kibana (port 5601)
Vulnerabilities (CVEs)
copy:
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2015-5531 | Elasticsearch | Allows file read through the Elasticsearch snapshot API, referenced in Part 2 of the series. |
Attack Chain
- Initial Access: Attacker accesses Elasticsearch cluster via exposed port 9200 or compromised Kibana on port 5601
- Reconnaissance: Attacker enumerates indices and existing API keys to identify valuable data and current access credentials
- Exfiltration: Data exported to disk via Scroll/PIT API pagination or stealthier server-side snapshot mechanism requiring only two API calls
- Persistence: Rogue superuser account created with service-like username (e.g., svc_monitoring) to blend with legitimate accounts
- Persistence: Long-lived API key created for credential-independent access that survives password rotations and account disabling
- Persistence: Elasticsearch Watcher scheduled task created to automatically recreate deleted backdoor user and API key on configurable interval
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. The article is a penetration testing demonstration focused on offensive capabilities and business impact proof.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | RAVEN interacts with Elasticsearch via API calls over HTTP. Endpoint detection would only see the raven-es process or curl commands on the attacker's machine, not on the Elasticsearch server itself. If the attacker runs RAVEN from a compromised host inside the network, EDR may capture process execution but the malicious activity occurs within the Elasticsearch process. |
| Network Visibility | Medium | Scroll/PIT API exfiltration generates significant HTTP traffic to port 9200 that could be detected by network monitoring. However, snapshot-based exfiltration operates entirely server-side within the Elasticsearch process, producing only two API calls with no sustained bulk data transfer visible on the network. |
| Detection Difficulty | Moderate | Detecting API key creation, rogue user creation, and Watcher registration requires Elasticsearch-specific audit logging that many organizations do not enable by default. Snapshot-based exfiltration is particularly difficult to detect via network monitoring. However, if audit logs are enabled, the API calls for persistence mechanisms are distinctive and queryable. |
Required Log Sources
- Elasticsearch audit logs (xpack.security.audit.enabled)
- Elasticsearch slow log for index operations
- Elasticsearch deprecated API usage logs
- Network flow data for port 9200 traffic analysis
- HTTP access logs for Elasticsearch REST API endpoints
- Process execution logs on hosts with raven-es installed
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for newly created Elasticsearch API keys, especially those with generic service-like names that blend with legitimate automation. Look for API key creation events outside normal business hours or from unusual source IPs. | Elasticsearch security audit logs with events for api_key creation (event type: api_key_authenticated, action: create_api_key) | persistence | Medium - legitimate service teams regularly create API keys for integrations. Correlate with change management records to identify unauthorized creations. |
| Consider hunting for new Elasticsearch user accounts with superuser role created outside normal provisioning windows. Focus on accounts with service-like names that could blend with legitimate automation. | Elasticsearch security audit logs for user creation events (action: create_user, realm: reserved) | persistence | Medium - service accounts are regularly created during deployments. Cross-reference with IT provisioning tickets and deployment schedules. |
| Consider hunting for Elasticsearch Watcher definitions that reference user creation, API key creation, or security index operations in their action payloads. These would indicate a persistence Watcher designed to recreate backdoor access. | Elasticsearch Watcher API (GET _watcher/watch/) and audit logs for watch execution events | persistence | Low - legitimate Watchers typically perform alerting actions (email, Slack, webhook) rather than security API operations like user or API key creation. |
| Consider hunting for snapshot repository registrations at unusual filesystem paths (e.g., /tmp/) or with names that do not match organizational naming conventions. These could indicate server-side data exfiltration. | Elasticsearch audit logs for snapshot repository registration events (action: create_snapshot_repository, repository: *) | exfiltration | Low - snapshot repositories are typically registered by administrators during planned backup operations. Unexpected registrations at /tmp paths are highly suspicious. |
| Consider hunting for bulk data export patterns via Scroll or PIT API, characterized by large numbers of scroll context creations or long-lived PIT IDs with high document counts. Compare against baseline query patterns. | Elasticsearch slow logs, API access logs, and metrics for scroll context count and PIT allocations | exfiltration | High - legitimate applications use Scroll and PIT APIs for batch processing, reporting, and data migration. Correlate with known application patterns and source IPs. |
Control Gaps
- Network monitoring cannot detect snapshot-based exfiltration because data movement occurs server-side within the Elasticsearch process
- Standard incident response playbooks that focus on password rotation do not address API key revocation or Watcher cleanup
- Default Elasticsearch configurations may not have audit logging enabled, leaving no record of API key creation or user creation events
- Endpoint detection on the Elasticsearch server cannot distinguish malicious snapshot operations from legitimate backup operations
Key Behavioral Indicators
- Elasticsearch Watcher definitions with actions containing security API calls (create_user, create_api_key) rather than alerting actions
- Snapshot repositories registered at /tmp/ paths or with names matching raven_exfil_repo pattern
- New user accounts with superuser role and service-like names (svc_monitoring, es_replication_agent) created outside provisioning windows
- API keys with names like analyst_standard_key or monitoring_service_key that do not match organizational naming conventions
- Presence of ~/.raven/ directory or activity.log file on any host in the network
- Scroll API or PIT API usage from source IPs outside known application server ranges
- Elasticsearch API key creation events where the creating user is the default elastic account
False Positive Assessment
Medium - Many of the detection indicators overlap with legitimate Elasticsearch administration activities. API key creation, user provisioning, snapshot repository registration, and Watcher creation are all standard administrative operations. Distinguishing malicious use requires baseline knowledge of legitimate administrative patterns, naming conventions, and change management records. Snapshot repositories at /tmp paths and Watchers performing security API operations have lower false positive rates.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing Elasticsearch clusters for unauthorized API keys by querying the _security/api_key endpoint and comparing against known legitimate keys.
- Consider enumerating all Elasticsearch user accounts and verifying each against your organization's provisioning records. Focus on accounts with superuser role and service-like names.
- If applicable, review all registered Elasticsearch Watcher definitions by querying _watcher/watch/ and look for watchers that perform security API operations rather than alerting actions.
- Consider checking for unauthorized snapshot repositories by querying _snapshot/_all and verifying each repository against known backup infrastructure.
Infrastructure Hardening
- Evaluate whether Elasticsearch audit logging is enabled (xpack.security.audit.enabled: true) and logs are forwarded to a centralized SIEM for correlation.
- Consider implementing network-level access controls to restrict port 9200 access to only known application servers and administrative hosts.
- If your Elasticsearch deployment uses X-Pack security, evaluate whether API key expiration policies can be enforced to limit the lifespan of credential-independent access tokens.
- Consider implementing Elasticsearch role-based access control with least-privilege principles to limit the blast radius of compromised credentials.
- Evaluate whether Elasticsearch Watcher execution can be restricted to specific roles or users to prevent unauthorized scheduled task creation.
User Protection
- Consider deploying Elasticsearch behind a reverse proxy or API gateway that logs and inspects API calls for suspicious patterns like bulk scroll operations or snapshot repository registration.
- If supported by your tooling, consider implementing alerting on Elasticsearch API key creation events, especially those created by the default elastic superuser account.
- Evaluate whether your organization's password rotation procedures should be expanded to include API key inventory and revocation as a standard step.
Security Awareness
- Consider incorporating Elasticsearch-specific persistence techniques into existing security awareness training for database administrators and DevOps teams.
- If applicable, educate incident response teams on the need to check for API keys, rogue user accounts, and Watcher-based persistence beyond standard password rotation during Elasticsearch incident response.
- Consider adding Elasticsearch audit log review to existing security operations procedures, focusing on security API events (user creation, API key creation, snapshot repository registration).
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping7 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
Persistence
Tactic
Credential Access
Additional IOCs
- File Paths:
/tmp/raven_repo- Default filesystem path used by RAVEN for rogue snapshot repository registration on the Elasticsearch server.
- Command Lines:
- Purpose: Bulk data exfiltration from Elasticsearch indices to local disk as NDJSON files using Scroll or PIT API | Tools:
raven-es| Stage: exfiltration |raven-es --quiet -t <target> exfil --index <index> --to disk --dest <path> - Purpose: Bulk exfiltration of all non-system Elasticsearch indices to local disk | Tools:
raven-es| Stage: exfiltration |raven-es --quiet -t <target> exfil --all --to disk --dest <path> - Purpose: Register rogue snapshot repository on Elasticsearch server for server-side data exfiltration | Tools:
raven-es| Stage: exfiltration |raven-es --quiet -t <target> snapshot --register-repo --repo-path <path> - Purpose: Create snapshot of target indices into rogue repository for server-side exfiltration invisible to network monitoring | Tools:
raven-es| Stage: exfiltration - Purpose: Enumerate existing Elasticsearch API keys visible to current user for reconnaissance | Tools:
raven-es| Stage: reconnaissance |raven-es --quiet -t <target> apikey --list - Purpose: Create persistent API key with current user privileges for credential-independent access | Tools:
raven-es| Stage: persistence |raven-es --quiet -t <target> apikey --create --name <keyname> - Purpose: Harvest API keys directly from .security index to steal credentials from other users and service accounts | Tools:
raven-es| Stage: credential_access |raven-es --quiet -t <target> apikey --harvest - Purpose: Create rogue superuser account with attacker-controlled credentials and service-like username | Tools:
raven-es| Stage: persistence - Purpose: Create long-lived API key that survives password rotations indefinitely | Tools:
raven-es| Stage: persistence |raven-es --quiet -t <target> persist --create-apikey --apikey-name <keyname> - Purpose: Create Elasticsearch Watcher scheduled task to recreate backdoor user and API key if deleted by defenders | Tools:
raven-es| Stage: persistence
- Purpose: Bulk data exfiltration from Elasticsearch indices to local disk as NDJSON files using Scroll or PIT API | Tools:
- Other:
persist_watcher_svc_monitoring- Watcher ID pattern used by RAVEN for persistence. Recreates backdoor user and API key on schedule. Pattern follows persist_watcher_<username>.analyst_standard_key- API key name used in RAVEN demonstration for credential-independent access to Elasticsearch cluster.monitoring_service_key- API key name used in RAVEN demonstration for persistent access that survives password rotations.heist_001- Snapshot name used by RAVEN for server-side data exfiltration via Elasticsearch snapshot API.