« Potential DNS Exfiltration via Excessive Chunked Queries Potential DNS Tunneling via Long and Unique Subdomains »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Potential DNS Rebinding from Public to Private Address

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential DNS Rebinding from Public to Private Address

edit

Identifies a client resolving the same public registered domain to both a public IP address and a private, loopback, link-local, unique-local IPv6, or shared address. This includes both address classes being observed at the same timestamp, and a public answer followed within five minutes by a private answer where the minimum TTL across all answer records in the private-answer events is 60 seconds or less. Either pattern is consistent with DNS rebinding that pivots browser or application trust to internal resources.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-15m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Network
  • Use Case: Threat Detection
  • Use Case: Network Security Monitoring
  • Tactic: Initial Access
  • Rule Type: ESQL
  • Data Source: Network Packet Capture
  • Data Source: Network Traffic
  • Data Source: Zeek
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential DNS Rebinding from Public to Private Address

DNS rebinding uses attacker-controlled public names that resolve to internal addresses so a victim browser or client reaches RFC1918, loopback, link-local, unique-local IPv6, or shared-address targets. This rule alerts on two patterns for the same client and fully qualified domain name: public and internal addresses whose first observations have the same timestamp, or a public answer followed by an internal answer within five minutes. Sequential transitions also require the minimum TTL across all DNS answer records in the private-answer events to be 60 seconds or less. Equal timestamps often represent a mixed-answer response, but do not prove that the addresses came from one DNS transaction; parallel A and AAAA events can share a timestamp. Equal-timestamp matches do not require the TTL or five-minute gates.

Esql.client_ip is client.ip when present and otherwise source.ip. Depending on sensor placement this value may identify an endpoint, a recursive resolver, a forwarder, or a localhost DNS listener such as 127.0.0.1. Resolver or loopback identities can merge many hosts into one bucket.

Possible investigation steps

  • Review dns.question.name, dns.question.registered_domain, Esql.public_ips, and Esql.private_ips to confirm the same name resolved to both a public and an internal address.
  • Check Esql.same_timestamp. A value of true means both address classes were first observed at the same timestamp, but does not establish that they came from one DNS transaction. Compare Esql.first_public_answer, Esql.first_private_answer, Esql.transition_seconds, and Esql.min_private_event_ttl for sequential transitions. Short transitions and TTL values near zero increase confidence.
  • Use Esql.resolved_ip_observation_count, Esql.resolved_ip_count, Esql.dataset_values, and Esql.observer_name_values to assess observation volume, distinct IP cardinality, and the integrations and sensors that contributed to the alert.
  • Identify the requesting client using Esql.client_ip. Confirm whether that address is an endpoint rather than a recursive resolver, forwarder, or localhost DNS service before attributing the activity to one host.
  • Determine whether the registered domain is attacker-controlled or a legitimate split-horizon or failover domain.
  • Check the requesting host for browser or application connections to the resolved private address immediately after the private answer.
  • Review the targeted internal service for requests carrying the public domain in the HTTP Host header or TLS SNI and for unauthorized access, state changes, or sensitive-data retrieval.

False positive analysis

  • Split-horizon DNS, VPN transitions, service discovery, failover, and hairpin NAT can legitimately cause a public registered domain to alternate between public and private answers. Confirm the domain and resolver behavior with DNS administrators.
  • Dual-stack names may publish a public IPv4 address and a unique-local IPv6 address under the same question name.
  • Security products may intentionally sinkhole suspicious domains to loopback or private addresses with short TTLs.
  • Exclude confirmed internal domains, approved sinkholes, and controlled security-testing infrastructure by registered domain or client only after validation. Do not exclude a resolver address until the originating endpoint is known.

Response and remediation

  • Block or sinkhole the queried name at recursive resolvers if it is confirmed malicious.
  • Patch or isolate affected internal services reached through the rebound name.
  • Restrict outbound DNS for clients that should not resolve arbitrary external names directly.

Setup

edit

Setup

This rule requires DNS transaction events from one of the following passive network integrations:

  • Elastic Network Packet Capture (network_traffic.dns) in logs-network_traffic.dns-*
  • Zeek (zeek.dns) in logs-zeek.dns-*
  • Legacy Packetbeat DNS events in packetbeat-*

Enable DNS logging so that dns.question.registered_domain and dns.resolved_ip are populated. Populate dns.answers.ttl to detect sequential public-to-private transitions; equal-timestamp matches do not require TTL data.

Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, or if the captured client is a localhost listener such as 127.0.0.1, Esql.client_ip may identify shared DNS infrastructure instead of the originating endpoint and can merge answers from many hosts.

DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS.

Rule query

edit
from logs-network_traffic.dns-*, logs-zeek.dns-*, packetbeat-*
| where
    (
      data_stream.dataset in ("network_traffic.dns", "zeek.dns") or
      event.dataset == "dns"
    ) and
    dns.question.name is not null and
    dns.question.registered_domain is not null and
    dns.resolved_ip is not null and
    TO_UPPER(dns.response_code) == "NOERROR" and
    TO_UPPER(dns.question.type) in ("A", "AAAA")
| eval
    Esql.client_ip = COALESCE(client.ip, source.ip),
    Esql.dataset = COALESCE(data_stream.dataset, event.dataset)
| where Esql.client_ip is not null
| mv_expand dns.resolved_ip
| eval Esql.is_private = CIDR_MATCH(
    dns.resolved_ip,
    "0.0.0.0/32",
    "10.0.0.0/8",
    "100.64.0.0/10",
    "127.0.0.0/8",
    "169.254.0.0/16",
    "172.16.0.0/12",
    "192.168.0.0/16",
    "::1/128",
    "fc00::/7",
    "fe80::/10"
  )
| eval
    Esql.private_time = CASE(Esql.is_private, @timestamp, null),
    Esql.public_time = CASE(not Esql.is_private, @timestamp, null),
    Esql.private_event_ttl = CASE(Esql.is_private, MV_MIN(dns.answers.ttl), null),
    Esql.private_ip = CASE(Esql.is_private, dns.resolved_ip, null),
    Esql.public_ip = CASE(not Esql.is_private, dns.resolved_ip, null)
| stats
    Esql.resolved_ip_observation_count = COUNT(*),
    Esql.resolved_ip_count = COUNT_DISTINCT(dns.resolved_ip),
    Esql.first_public_answer = MIN(Esql.public_time),
    Esql.first_private_answer = MIN(Esql.private_time),
    Esql.min_private_event_ttl = MIN(Esql.private_event_ttl),
    Esql.public_ips = MV_SLICE(VALUES(Esql.public_ip), 0, 100),
    Esql.private_ips = MV_SLICE(VALUES(Esql.private_ip), 0, 100),
    Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 10),
    Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 20)
  by Esql.client_ip, dns.question.name, dns.question.registered_domain
| eval
    Esql.same_timestamp = Esql.first_public_answer == Esql.first_private_answer,
    Esql.transition_seconds = DATE_DIFF("seconds", Esql.first_public_answer, Esql.first_private_answer)
| where
    Esql.first_public_answer is not null and
    Esql.first_private_answer is not null and
    (
        Esql.same_timestamp or
        (
            Esql.first_public_answer < Esql.first_private_answer and
            Esql.min_private_event_ttl is not null and
            Esql.min_private_event_ttl <= 60 and
            Esql.transition_seconds <= 300
        )
    )
| keep Esql.*, dns.*

Framework: MITRE ATT&CKTM

« Potential DNS Exfiltration via Excessive Chunked Queries Potential DNS Tunneling via Long and Unique Subdomains »