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, andEsql.private_ipsto confirm the same name resolved to both a public and an internal address. - Check
Esql.same_timestamp. A value oftruemeans both address classes were first observed at the same timestamp, but does not establish that they came from one DNS transaction. CompareEsql.first_public_answer,Esql.first_private_answer,Esql.transition_seconds, andEsql.min_private_event_ttlfor sequential transitions. Short transitions and TTL values near zero increase confidence. - Use
Esql.resolved_ip_observation_count,Esql.resolved_ip_count,Esql.dataset_values, andEsql.observer_name_valuesto 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
- Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence
- Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts
- Potential Self-Signed TLS Certificate Recently Issued on External Connection
- Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)
- Thrift RPC Method from an External Client