Potential DNS Rebinding from Public to Private Address

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/20"
  3integration = ["network_traffic", "zeek"]
  4maturity = "production"
  5updated_date = "2026/08/25"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a client resolving the same public registered domain to both a public IP address and a private, loopback,
 11link-local, unique-local IPv6, or shared address. This includes both address classes being observed at the same
 12timestamp, and a public answer followed within five minutes by a private answer where the minimum TTL across all answer
 13records in the private-answer events is 60 seconds or less. Either pattern is consistent with DNS rebinding that pivots
 14browser or application trust to internal resources.
 15"""
 16false_positives = [
 17    """
 18    Split-horizon DNS, VPN transitions, service discovery, failover, hairpin NAT, and dual-stack names that publish a
 19    public A record with a unique-local AAAA record can legitimately produce public and private answers for the same
 20    name. Recursive resolvers, DNS forwarders, and localhost listeners can also aggregate many endpoints under one
 21    client address. Security products may sinkhole suspicious domains to loopback or private addresses with short TTLs.
 22    Confirm the domain, resolver placement, and client identity before adding an exception, and scope exceptions by
 23    registered domain or client rather than globally.
 24    """,
 25]
 26from = "now-15m"
 27language = "esql"
 28license = "Elastic License v2"
 29name = "Potential DNS Rebinding from Public to Private Address"
 30note = """## Triage and analysis
 31
 32### Investigating Potential DNS Rebinding from Public to Private Address
 33
 34DNS rebinding uses attacker-controlled public names that resolve to internal addresses so a victim browser or client
 35reaches RFC1918, loopback, link-local, unique-local IPv6, or shared-address targets. This rule alerts on two patterns
 36for the same client and fully qualified domain name: public and internal addresses whose first observations have the
 37same timestamp, or a public answer followed by an internal answer within five minutes. Sequential transitions also
 38require the minimum TTL across all DNS answer records in the private-answer events to be 60 seconds or less. Equal
 39timestamps often represent a mixed-answer response, but do not prove that the addresses came from one DNS transaction;
 40parallel A and AAAA events can share a timestamp. Equal-timestamp matches do not require the TTL or five-minute gates.
 41
 42`Esql.client_ip` is `client.ip` when present and otherwise `source.ip`. Depending on sensor placement this value may
 43identify an endpoint, a recursive resolver, a forwarder, or a localhost DNS listener such as `127.0.0.1`. Resolver or
 44loopback identities can merge many hosts into one bucket.
 45
 46### Possible investigation steps
 47
 48- Review `dns.question.name`, `dns.question.registered_domain`, `Esql.public_ips`, and `Esql.private_ips` to confirm the
 49  same name resolved to both a public and an internal address.
 50- Check `Esql.same_timestamp`. A value of `true` means both address classes were first observed at the same timestamp,
 51  but does not establish that they came from one DNS transaction. Compare `Esql.first_public_answer`,
 52  `Esql.first_private_answer`, `Esql.transition_seconds`, and `Esql.min_private_event_ttl` for sequential transitions.
 53  Short transitions and TTL values near zero increase confidence.
 54- Use `Esql.resolved_ip_observation_count`, `Esql.resolved_ip_count`, `Esql.dataset_values`, and
 55  `Esql.observer_name_values` to assess observation volume, distinct IP cardinality, and the integrations and sensors
 56  that contributed to the alert.
 57- Identify the requesting client using `Esql.client_ip`. Confirm whether that address is an endpoint rather than a
 58  recursive resolver, forwarder, or localhost DNS service before attributing the activity to one host.
 59- Determine whether the registered domain is attacker-controlled or a legitimate split-horizon or failover domain.
 60- Check the requesting host for browser or application connections to the resolved private address immediately after
 61  the private answer.
 62- Review the targeted internal service for requests carrying the public domain in the HTTP Host header or TLS SNI and
 63  for unauthorized access, state changes, or sensitive-data retrieval.
 64
 65### False positive analysis
 66
 67- Split-horizon DNS, VPN transitions, service discovery, failover, and hairpin NAT can legitimately cause a public
 68  registered domain to alternate between public and private answers. Confirm the domain and resolver behavior with DNS
 69  administrators.
 70- Dual-stack names may publish a public IPv4 address and a unique-local IPv6 address under the same question name.
 71- Security products may intentionally sinkhole suspicious domains to loopback or private addresses with short TTLs.
 72- Exclude confirmed internal domains, approved sinkholes, and controlled security-testing infrastructure by registered
 73  domain or client only after validation. Do not exclude a resolver address until the originating endpoint is known.
 74
 75### Response and remediation
 76
 77- Block or sinkhole the queried name at recursive resolvers if it is confirmed malicious.
 78- Patch or isolate affected internal services reached through the rebound name.
 79- Restrict outbound DNS for clients that should not resolve arbitrary external names directly.
 80"""
 81references = ["https://owasp.org/www-community/attacks/DNS_Rebinding", "https://portswigger.net/web-security/ssrf"]
 82risk_score = 47
 83rule_id = "c485ceb7-b0e3-4540-9e8c-e9c655406e68"
 84setup = """## Setup
 85
 86This rule requires DNS transaction events from one of the following passive network integrations:
 87
 88- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*`
 89- Zeek (`zeek.dns`) in `logs-zeek.dns-*`
 90- Legacy Packetbeat DNS events in `packetbeat-*`
 91
 92Enable DNS logging so that `dns.question.registered_domain` and `dns.resolved_ip` are populated. Populate
 93`dns.answers.ttl` to detect sequential public-to-private transitions; equal-timestamp matches do not require TTL data.
 94
 95Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver,
 96or if the captured client is a localhost listener such as `127.0.0.1`, `Esql.client_ip` may identify shared DNS
 97infrastructure instead of the originating endpoint and can merge answers from many hosts.
 98
 99DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the
100sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS.
101"""
102severity = "medium"
103tags = [
104    "Domain: Network",
105    "Use Case: Threat Detection",
106    "Use Case: Network Security Monitoring",
107    "Tactic: Initial Access",
108    "Rule Type: ESQL",
109    "Data Source: Network Packet Capture",
110    "Data Source: Network Traffic",
111    "Data Source: Zeek",
112    "Resources: Investigation Guide",
113]
114timestamp_override = "event.ingested"
115type = "esql"
116
117query = '''
118from logs-network_traffic.dns-*, logs-zeek.dns-*, packetbeat-*
119| where
120    (
121      data_stream.dataset in ("network_traffic.dns", "zeek.dns") or
122      event.dataset == "dns"
123    ) and
124    dns.question.name is not null and
125    dns.question.registered_domain is not null and
126    dns.resolved_ip is not null and
127    TO_UPPER(dns.response_code) == "NOERROR" and
128    TO_UPPER(dns.question.type) in ("A", "AAAA")
129| eval
130    Esql.client_ip = COALESCE(client.ip, source.ip),
131    Esql.dataset = COALESCE(data_stream.dataset, event.dataset)
132| where Esql.client_ip is not null
133| mv_expand dns.resolved_ip
134| eval Esql.is_private = CIDR_MATCH(
135    dns.resolved_ip,
136    "0.0.0.0/32",
137    "10.0.0.0/8",
138    "100.64.0.0/10",
139    "127.0.0.0/8",
140    "169.254.0.0/16",
141    "172.16.0.0/12",
142    "192.168.0.0/16",
143    "::1/128",
144    "fc00::/7",
145    "fe80::/10"
146  )
147| eval
148    Esql.private_time = CASE(Esql.is_private, @timestamp, null),
149    Esql.public_time = CASE(not Esql.is_private, @timestamp, null),
150    Esql.private_event_ttl = CASE(Esql.is_private, MV_MIN(dns.answers.ttl), null),
151    Esql.private_ip = CASE(Esql.is_private, dns.resolved_ip, null),
152    Esql.public_ip = CASE(not Esql.is_private, dns.resolved_ip, null)
153| stats
154    Esql.resolved_ip_observation_count = COUNT(*),
155    Esql.resolved_ip_count = COUNT_DISTINCT(dns.resolved_ip),
156    Esql.first_public_answer = MIN(Esql.public_time),
157    Esql.first_private_answer = MIN(Esql.private_time),
158    Esql.min_private_event_ttl = MIN(Esql.private_event_ttl),
159    Esql.public_ips = MV_SLICE(VALUES(Esql.public_ip), 0, 100),
160    Esql.private_ips = MV_SLICE(VALUES(Esql.private_ip), 0, 100),
161    Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 10),
162    Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 20)
163  by Esql.client_ip, dns.question.name, dns.question.registered_domain
164| eval
165    Esql.same_timestamp = Esql.first_public_answer == Esql.first_private_answer,
166    Esql.transition_seconds = DATE_DIFF("seconds", Esql.first_public_answer, Esql.first_private_answer)
167| where
168    Esql.first_public_answer is not null and
169    Esql.first_private_answer is not null and
170    (
171        Esql.same_timestamp or
172        (
173            Esql.first_public_answer < Esql.first_private_answer and
174            Esql.min_private_event_ttl is not null and
175            Esql.min_private_event_ttl <= 60 and
176            Esql.transition_seconds <= 300
177        )
178    )
179| keep Esql.*, dns.*
180'''
181
182
183[[rule.threat]]
184framework = "MITRE ATT&CK"
185[[rule.threat.technique]]
186id = "T1189"
187name = "Drive-by Compromise"
188reference = "https://attack.mitre.org/techniques/T1189/"
189
190
191[rule.threat.tactic]
192id = "TA0001"
193name = "Initial Access"
194reference = "https://attack.mitre.org/tactics/TA0001/"
195
196[rule.investigation_fields]
197field_names = [
198    "Esql.client_ip",
199    "dns.question.name",
200    "dns.question.registered_domain",
201    "Esql.resolved_ip_observation_count",
202    "Esql.resolved_ip_count",
203    "Esql.first_public_answer",
204    "Esql.first_private_answer",
205    "Esql.transition_seconds",
206    "Esql.same_timestamp",
207    "Esql.min_private_event_ttl",
208    "Esql.public_ips",
209    "Esql.private_ips",
210    "Esql.dataset_values",
211    "Esql.observer_name_values",
212]

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.

References

Related rules

to-top