Lion Cipher Lab

Exploit an unauthenticated Elasticsearch in your own lab — dump the indices, then secure it

• Penetration Testing / Red Team
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Exposed, unauthenticated data stores are one of the most common serious findings on the entire internet, and Elasticsearch sits right beside Redis and MongoDB at the top of that list. Elasticsearch is a distributed search and analytics engine: you POST it JSON documents, it indexes them, and you query them over a simple HTTP REST API on port 9200. It is superb at powering search boxes, log analytics and dashboards, and for most of its history it shipped with no authentication at all, on the same 'it only lives on a trusted network' assumption that betrayed Redis. That assumption is where the…

What you'll learn

• defining what Elasticsearch is (a distributed search/analytics engine and JSON document store driven over an HTTP REST API on 9200), what an INDEX and a DOCUMENT are, and what 'unauthenticated' means for it — reach 9200 and you can read and write everything over plain HTTP
• standing up Elasticsearch 8.x in a single Docker container deliberately weakened with xpack.security.enabled=false and single-node discovery, so the whole exercise touches nothing but your own machine
• seeding realistic-looking indices of fake leaked records with the document and _bulk APIs, so the 'dump' has something to find
• confirming the exposure from the host with curl: GET / for the cluster name and version, GET /_cluster/health, GET /_cat/indices?v to list every index, GET /<index>/_search to dump documents, and GET /_cat/nodes — all succeeding with no credential
• understanding the read-AND-write blast radius (POST/PUT overwrite, DELETE /index wipes) and how it maps to the 2016-2020 wave of open-Elasticsearch data leaks and the 'meow' attacks — without running anything destructive
• seeing precisely how Elasticsearch differs from the Redis sibling: HTTP/JSON REST and mass document disclosure here, versus a compact text protocol and the CONFIG SET dir write-primitive there
• applying the fix — xpack.security.enabled=true, an elastic bootstrap password (ELASTIC_PASSWORD or bin/elasticsearch-reset-password), TLS, and binding/publishing only where needed — and re-running the SAME curl to watch it flip to HTTP 401 security_exception, then succeed with -u elastic:<password>
• judgment: recognising an unexpected 9200/tcp returning a version JSON with no auth as the finding (least-invasive proof), reporting cause/impact/fix, and preventing recurrence with security-on base images, private binds, and scanning your own estate

Steps in this lab

1. What Elasticsearch is, and what 'unauthenticated' actually means here
2. Build the isolated lab: one deliberately weakened Elasticsearch container, your machine only
3. Seed a couple of indices with fake 'leaked' records
4. Confirm unauthenticated access — the finding, and the blast radius
5. Why the default is safe — and why exposed clusters still happen anyway
6. The fix, part 1: turn security back on and measure the flip to 401
7. The fix, part 2: defence in depth — TLS, roles/API keys, and bind only where needed
8. Do it better — how to recognise, report, and prevent the exposed cluster

Open the full interactive lab →