5601/tcp - Pentesting Kibana

Basic Information

Kibana is the Elastic Stack web interface for searching, visualizing, and administering Elasticsearch data. A self-managed installation listens on localhost:5601 by default, although both the bind address and port are configurable in kibana.yml.^[1]

Initial checks

Open /status or use the status API to identify the deployed version and service health.^[2]
Determine whether the instance exposes a login form, anonymous access, or a configured SSO provider. Kibana supports multiple authentication providers backed by Elasticsearch security.^[3]
On legacy or deliberately unsecured stacks where Elasticsearch security is disabled and no reverse proxy supplies authentication, Kibana may be reachable without credentials. When security is enabled, interactive users authenticate through Kibana’s configured provider and their effective access is determined by the associated Elasticsearch roles plus Kibana feature and space privileges; it is not safe to assume that every Elasticsearch credential has identical UI access.^[3]
If local file access is already available, inspect /etc/kibana/kibana.yml on package installations, or $KIBANA_HOME/config/kibana.yml on archive installations. Do not assume Elasticsearch credentials are stored there: modern deployments can use service-account tokens or a keystore.^[1]
On older password-based deployments, kibana.yml may contain the credentials Kibana uses to connect to Elasticsearch. The expected built-in identity is kibana_system, which is a service account rather than an interactive Kibana user. Credentials for a broader identity—especially elastic or another superuser—are substantially more sensitive and indicate excessive privilege.^[5]
Record whether browser-to-Kibana and Kibana-to-Elasticsearch connections use TLS.

Actions after authorized access

The available features depend on the authenticated user’s Elasticsearch and Kibana privileges. Within the scope of the assessment:^[3]

Review accessible data views, dashboards, saved searches, and developer-console access for sensitive data.
Inspect Stack Management for exposed users, roles, API keys, connectors, and saved objects. Where the account has the required privileges, these interfaces can create, edit, or delete users and roles and create or invalidate API keys; do not make those changes unless the test explicitly permits it.^[3]
Compare the exact Kibana and Elasticsearch versions with Elastic security advisories. Avoid inferring vulnerability from the major version alone.
As a historical example, Kibana versions before 5.6.15 and 6.6.1 had an arbitrary-code-execution vulnerability in Timelion (CVE-2019-7609). Access to Timelion was a prerequisite, and Elastic’s remediation was to upgrade or disable Timelion.^[4]
Check whether low-privileged accounts can reach administrative features or data outside their intended spaces.

For a worked assessment covering discovery, credential sources, index access, and historical exploitation paths across the ELK stack, see the practical guide in reference 6.^[6]

Transport-security considerations

If Kibana is reachable over plaintext HTTP, credentials, session cookies, queries, and returned data may be exposed to an on-path observer. Also verify certificate validation on Kibana’s connection to Elasticsearch.^[1]