Release the RAVEN: First Contact

You are mid-engagement. Nmap finishes its sweep and port 9200 lights up on a host. Elasticsearch. You know it matters. You know the client's logging pipeline, search infrastructure, or analytics platform probably flow through it. But what do you actually know about this cluster? Right now, nothing. No version, no configuration, no indication of whether it is locked down or wide open.

This is where RAVEN's first contact begins.

In this post, we walk through the reconnaissance phase of an Elasticsearch offensive security engagement. From a single open port, we will fingerprint the cluster, perform deep reconnaissance, assess its exposure, enumerate its data, hunt for secrets, test credentials, and map privilege escalation paths. By the end, we will know exactly what we are dealing with and exactly how deep we can go.

All demonstrations use RAVEN's integrated lab environments. No production systems were touched.

Setting the Stage

For this walkthrough, we are using two of RAVEN's lab targets:

• lab-main (Elasticsearch 7.17.22, no authentication) for demonstrating reconnaissance against an unsecured cluster
• lab-secured (Elasticsearch 7.17.22, X-Pack security enabled) for demonstrating credential testing and privilege analysis against a hardened cluster

Before we begin, ensure RAVEN is installed. Full instructions are in the GitHub repository, but the quick setup involves the following steps: cloning the repository (`git clone https://github.com/karlvbiron/raven`), creating and activate a virtual environment (`python3 -m venv .venv && source .venv/bin/activate`), and install with `pip install -e .`. With the virtual environment active, `raven-es` is ready to use.

Each lab spins up with a single command. As shown in Figures 1 and 2, `make lab-main-up` builds the Docker container, waits for Elasticsearch to be healthy, seeds test data (users, orders, logs, configuration indices), and reports ready in under two minutes.

Figure 1. Lab startup: Docker image build, container creation, and seed script initialization.

Figure 2. Lab startup (continued): health checks, data seeding with index summary, and ready confirmation.

With our target live, we begin.

Fingerprinting the Target

The first thing any security professional needs to know is what they are looking at. Version, build type, cluster configuration, installed plugins. Every piece of this information shapes the rest of the engagement. A cluster running Elasticsearch 1.4.2 has a fundamentally different attack surface than one running 7.17.22.

Before RAVEN, this meant running `curl -s http://localhost:9200/ | python3 -m json.tool` and manually parsing the JSON response. As shown in Figure 3, the raw output is dense and requires careful reading to extract the version, build type, and cluster metadata.

Figure 3. Raw curl output from the Elasticsearch root endpoint. The version is buried in a nested JSON structure.

RAVEN transforms this into structured, actionable intelligence. Running `raven-es --quiet -t localhost fingerprint` produces the output shown in Figure 4.

Figure 4. RAVEN fingerprint output with cluster details, node information, and plugin enumeration.

One command, one glance. The cluster name (`raven-lab-main`), version (`7.17.22`), build type (`docker`), node roles, operating system, and JVM version are all presented in a structured format that immediately tells you what you are working with. In a real engagement, this output alone determines which CVEs to check, which scripting engines are available, and whether the cluster is a single node or a distributed deployment with multiple attack surfaces.

The version number is the most critical data point. Every CVE in RAVEN's catalog is matched against this version. Knowing that the target runs 7.17.22 immediately tells us that the legacy scripting engine CVEs (MVEL, Groovy) do not apply, but we should check for privilege escalation vulnerabilities in the API key service. We will put this to the test in Part 2.

Detecting Kibana

Elasticsearch rarely operates alone. Most deployments include Kibana on port 5601 as the visualization and management layer. RAVEN can probe for Kibana directly during fingerprinting by running `raven-es --quiet -t localhost fingerprint --detect-kibana`. If Kibana is present, RAVEN reports its version and status. This matters because Kibana has its own CVE history and its own attack surface. Discovering Kibana during initial fingerprinting means we can plan for Part 3's Kibana-specific attacks from the very first minute of the engagement. A cluster with Kibana 6.5.4 is not just an Elasticsearch target. It is a two-front engagement.

For environments where stealth matters, the `--banner-only` flag limits fingerprinting to a single GET request to the root endpoint. Minimal footprint, just enough to grab the version and cluster name without querying node details or plugin lists.

Deep Reconnaissance

Fingerprinting tells you what the target is. Reconnaissance tells you how it is built. RAVEN's `recon` module goes deeper, querying internal cluster APIs that reveal topology, configuration, filesystem paths, and cross-cluster relationships. As shown in Figure 5, running `raven-es --quiet -t localhost recon --full` produces a comprehensive map of the cluster's internals.

Figure 5. Full reconnaissance output showing cluster health, node details, shard allocation, and cluster settings.

The `--full` flag queries every available endpoint: `_cat/*` for indices, nodes, shards, plugins, and aliases. `_cluster/*` for health, settings, and state. The result is a comprehensive map of the cluster's internal architecture.

Three flags deserve special attention for penetration testers:

• `--paths` extracts `path.data`, `path.logs`, and `path.repo` from node settings via `raven-es --quiet -t localhost recon --paths`. The repository path (`path.repo`) is critical for later exploitation. If a repository path is configured, CVE-2015-5531 (snapshot directory traversal) becomes viable. If it is not, certain file-read techniques are blocked at the configuration level. Knowing this up-front saves time during the exploitation phase.

• `--remote` enumerates cross-cluster replication and search configurations. In enterprise environments, Elasticsearch clusters are frequently connected for disaster recovery or data federation. Discovering a remote cluster relationship means a single compromised cluster may provide a path to others.

• `--plugins` lists installed plugins, which directly feeds the CVE module. Certain vulnerabilities only apply when specific plugins are present. For example, the Kibana Timelion CVE (CVE-2019-7609) requires the Timelion plugin to be enabled. Plugin enumeration is not just informational — it is target refinement.

Is the Door Open?

Before testing credentials, there is a more fundamental question: does this cluster require authentication at all? A surprising number of Elasticsearch deployments in the wild have security disabled entirely. No username, no password, no TLS. Just an open REST API serving data to anyone who asks.

RAVEN's `anonymous` module answers this question definitively by testing critical API endpoints without providing any credentials and classifying the exposure level. As shown in Figure 6, running `raven-es --quiet -t localhost anonymous` against our lab-main target produces a damning result.

Figure 6. Anonymous access assessment showing endpoint accessibility and risk severity on an unsecured cluster.

Every endpoint responds. Indices are enumerable. Documents are searchable. Cluster settings are readable. The module does not just tell you, "Authentication is disabled." It quantifies exactly how much damage an unauthenticated attacker could do and presents it as a severity rating.

The `--full` flag extends the test to all endpoints, not just the critical ones. This provides a complete map of what an unauthenticated attacker can access, from `_cat/indices` to `_cluster/settings` to `_nodes/stats`.

This is a finding that goes directly into the penetration test report. Not as a footnote, but as a critical vulnerability. If this were a production cluster, every document in every index would be exposed to any network-adjacent attacker.

What Data Lives Here?

Now that we know the door is open, the next question is what is behind it. Index enumeration reveals the scope of the data at risk. As shown in Figure 7, running `raven-es --quiet -t localhost indices` lists every non-system index in the cluster.

Figure 7: Index enumeration showing four data-bearing indices with health status and aliases.

Four indices: `users`, `orders`, `logs`, and `config`. The color-coded health column provides instant visual triage. But the names alone tell a story. User data, transaction records, application logs, and configuration entries. In a real engagement, index names frequently reveal organizational structure, application architecture, and data classification failures. Indices named `customer-pii`, `payment-transactions`, or `admin-credentials` are more common than they should be.

Going Deeper with Mappings

Index names tell you what exists. Mappings tell you what the data actually looks like. As shown in Figure 8, running `raven-es --quiet -t localhost indices --mappings` reveals the field names and types for every index.

Figure 8. Index mappings showing field names and data types for each index.

Field mappings are the schema of the data. A `users` index with fields named `username`, `email`, `role`, and `full_name` tells you exactly what to target with your search queries. A `logs` index with `api_endpoint`, `api_key`, and `db_connection_string` fields tells you there are credentials sitting in plaintext. Mappings transform blind enumeration into surgical targeting.

Prioritizing by Size

When a cluster has dozens or hundreds of indices, you need to prioritize. Running `raven-es --quiet -t localhost indices --sort-by-size --sizes` reveals where the bulk of the data lives. The largest indices are typically the most valuable. A 50GB `transactions` index is more interesting than a 12KB `test-data` index. Size-based prioritization is a simple technique that experienced penetration testers use instinctively but that few tools automate.

The `--system` flag expands the view to include hidden and system indices. On a secured cluster, this reveals the `.security-7` index where Elasticsearch stores its own user and role definitions. On a cluster with Kibana, `.kibana` indices contain saved dashboards, visualizations, and configuration that feed into Part 3's intelligence extraction.

Hunting for Secrets

Knowing which indices exist is useful. Knowing what is inside them is devastating. RAVEN's search module goes beyond simple data retrieval. It hunts for the kind of information that turns a reconnaissance finding into a full compromise.

Targeted Queries

Start with what the mappings told us. If the `config` index has credential-like fields, search it directly. As shown in Figure 9, running `raven-es --quiet -t localhost search --index config --query "password"` surfaces documents containing credential-related content.

Figure 9. Search results from the config index showing documents matching the "password" query.

Configuration indices are a gold mine. Developers store database connection strings, API keys, service account credentials, and internal URLs in Elasticsearch because it is convenient, searchable, and always available. They rarely consider that the same properties that make it useful for storage also make it useful for an attacker.

Automated Secret Detection

RAVEN's `--grep-secrets` flag automates the hunt with curated regex patterns designed to detect AWS keys, private keys, bearer tokens, basic auth headers, and other credential formats across all indices. As shown in Figure 10, running `raven-es --quiet -t localhost search --grep-secrets` reveals embedded credentials scattered across the cluster.

Figure 10. Automated secret detection showing 12 credential patterns found across multiple indices with severity levels.

Every match is a potential lateral movement path. An AWS key stored in an Elasticsearch index does not just compromise the cluster. It compromises whatever that key has access to in the cloud environment.

Regex Hunting

For custom patterns that the built-in secret detection does not cover, the `--grep` flag applies arbitrary regex filtering across search results. For example, running `raven-es --quiet -t localhost search --grep "api[_-]?key|secret|token" --index logs` targets specific credential-naming conventions within the logs index. This is where domain knowledge meets tooling. A penetration tester who knows the client's naming conventions can craft targeted patterns that surface exactly the data that matters. RAVEN provides the engine. The operator provides the intelligence.

Sampling and Extraction

Some indices contain millions of documents. Scrolling through all of them is impractical. Running `raven-es --quiet -t localhost search --sample 5 --index users` randomly samples a specified number of documents, giving you a representative view of what an index contains without pulling the entire dataset.

Combined with `--fields` for projection, you can extract just the columns you need. As shown in Figure 11, running `raven-es --quiet -t localhost search --index users --fields "username,email,role"` produces a clean, targeted output.

Figure 11. Projected search output showing only username, email, and role fields from the users index.

Clean, targeted data extraction. No noise, no unnecessary fields, just the information that matters for the engagement report. For full extraction rather than sampling, the `--scroll` flag paginates through the entire index using the Scroll API, pulling every document regardless of dataset size.

Breaking In (When the Door is Locked)

Not every cluster is wide open. When authentication is enabled, RAVEN shifts from passive reconnaissance to active credential testing. We switch to our secured lab target by running `make lab-secured-up`. Against a cluster with X-Pack security enabled, anonymous access fails and every endpoint returns 401 Unauthorized. This is where the bruteforce module enters.

Default Credential Testing

The most common path in. As shown in Figure 12, running `raven-es --quiet -t localhost bruteforce --auth-list raven/data/default_creds.txt --stop-on-success` tests default credentials against the secured cluster.

Figure 12. Bruteforce results showing a valid credential pair discovered from the default credentials list.

RAVEN ships with a curated default credentials list covering the most common Elasticsearch deployments. The `--stop-on-success` flag halts on the first valid credential, minimizing noise and failed authentication events in the target's logs.

Default credentials remain one of the most common misconfigurations in Elasticsearch deployments. The built-in `elastic` superuser account with password `changeme` is the factory default and is found in production environments far more often than anyone in the industry would like to admit.

Password Spraying

When default credentials fail, the `--spray` mode takes a different approach. Instead of testing many passwords against one account (which triggers lockout policies), it tests one password against many accounts. Running `raven-es --quiet -t localhost bruteforce --userlist users.txt --passlist common_passwords.txt --spray --sleep 2` demonstrates this approach. The `--sleep` flag adds a configurable delay between attempts. Two seconds per attempt may feel slow, but it keeps you under the radar of most rate limiting and account lockout policies. Patience is a weapon. The `--spray` flag exists because a careful attacker is a successful attacker.

For maximum coverage with custom wordlists, the `--userlist` and `--passlist` combination mode tests every username against every password by running `raven-es --quiet -t localhost bruteforce --userlist users.txt --passlist passwords.txt`. Use it carefully: a 100-user list crossed with a 100-password list produces 10,000 login attempts.

Understanding What We Can Do

Valid credentials in hand, the final reconnaissance step is understanding the privileges those credentials grant. RAVEN's privilege escalation module maps the current user's permissions and analyzes potential escalation paths.

Superuser Landing

As shown in Figure 13, running `raven-es --quiet -t localhost privesc --analyze -u elastic -P changeme` reveals the full privilege profile of the authenticated user.

Figure 13. Privilege analysis for the elastic superuser showing full access and no escalation needed.

With `elastic:changeme`, we have landed as superuser. The module confirms this and reports that no escalation is necessary. Game over for access control. But that is the easy scenario. The interesting case is when you land with limited privileges.

Limited User Analysis

The contrast becomes clear when analyzing a restricted account. As shown in Figure 14, running `raven-es --quiet -t localhost privesc --analyze -u reader -P readonly123` reveals a far more limited privilege profile.

Figure 14. Privilege analysis for the reader user showing limited access and no escalation opportunities.

Now the picture changes. The `reader` account has a single role (`data_reader`) and cannot create API keys. RAVEN identifies these limitations and reports no obvious escalation opportunities. The contrast with the superuser analysis above is stark: 34 roles versus 1, API key creation enabled versus disabled, "no escalation needed" versus "no opportunities found." This is the information a penetration tester uses to decide whether to pursue privilege escalation through other means or focus on extracting value from the limited access available.

Enumerating the Security Landscape

Three additional flags provide the raw material for privilege escalation planning:

• `--roles` enumerates every role defined in the cluster by running `raven-es --quiet -t localhost privesc --roles -u elastic -P changeme`. This reveals which privilege sets exist and which ones are worth targeting. On our secured lab, this returns 34 defined roles, each with different index permissions, cluster privileges, and run-as capabilities.

• `--users` lists all user accounts via `raven-es --quiet -t localhost privesc --users -u elastic -P changeme`. Combined with role enumeration, this maps which users have which privileges. Over-privileged accounts (developers with superuser roles, temporary accounts that were never removed) are common escalation targets.

• `--role-mappings` is the most subtle and often the most valuable. Role mappings automatically assign roles based on user metadata, realm membership, or other attributes. A misconfigured role mapping can grant elevated privileges to users who meet certain criteria, sometimes unintentionally. Running `raven-es --quiet -t localhost privesc --role-mappings -u elastic -P changeme` reveals which mappings exist and what triggers them, exposing hidden privilege paths that might not be visible through direct role inspection alone.

Understanding role mappings is the difference between "I have read-only access" and "there is a path to higher privileges through a mapping rule that nobody audited." The mapping is the bridge. RAVEN shows you where the bridges are.

The Full Picture

Everything demonstrated above across a dozen commands can also be run in a single invocation. Running `raven-es --quiet -t localhost all -u elastic -P changeme` chains fingerprinting, reconnaissance, index enumeration, search, and anonymous access testing into one comprehensive scan, generating a consolidated report. One command, full coverage.

In total, we went from a single open port to a complete understanding of the target. Fingerprint revealed ES 7.17.22 on Docker with a single node and detected whether Kibana is present. Recon mapped cluster topology, filesystem paths, cross-cluster relationships, and installed plugins. Anonymous confirmed whether authentication is required and quantified the exposure. Indices enumerated all data-bearing indices with health, mappings, and field types. Search surfaced credentials, secrets, and sensitive data using targeted queries and automated pattern detection. Bruteforce found valid credentials using default credential testing and password spraying. Privesc mapped the privilege landscape, enumerated users, roles, and role mappings, and identified escalation paths.

All output supports `--format json` for scripting and automation, and `--output FILE` for direct inclusion in engagement reports.

This is the intelligence foundation that every subsequent phase builds on. We know what we are attacking, what data is at stake, what access we have, and where the privilege boundaries can be crossed.

In Part 2, we put that intelligence to use. We will exploit real CVEs against vulnerable Elasticsearch versions, from legacy scripting engine RCE that returns root shells to prototype pollution attacks against Kibana that require building a novel browser-based trigger to automate. The cracks have been mapped. Now we break through them.

This is Part 1 of the "Release the RAVEN" series. Read Part 0: Prologue for an overview of the tool or continue to Part 2: Exploiting the Cracks for CVE exploitation.

RAVEN is available on GitHub and PyPI.