Inbound Connection to an Unsecure Elasticsearch Node
Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersESXiIaaSLinuxmacOSNetwork DevicesPREWindows
The rule states no platform. This is derived from the 2 ATT&CK techniques it maps to.
- Log source category
- event_index
Known benign triggers
- If you have front-facing proxies that provide authentication and TLS, this rule would need to be tuned to eliminate the source IP address of your reverse-proxy.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers | 2 |
| www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html | Only this detection cites it |
From the source
- At source
- Open at source
- Upstream identifier
- 31295df3-277b-4c56-a1fb-84e31b4222a9
- Tagged by the source as
- Data Source: Network Packet CaptureDomain: EndpointDomain: NetworkNoise: LowPerformance: NormalResources: Investigation GuideRule Type: Custom Query (KQL)Tactic: Initial AccessTactic: ReconnaissanceUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3