Add DNS PTR-Based Host Discovery Detection by MehrabBakhtar · Pull Request #4332 · splunk/security_content

MehrabBakhtar · 2026-10-10T21:15:05Z

Summary

Add a detection for potential host discovery through high-volume DNS PTR queries.

Use the Network Resolution data model with tstats.

Identify source systems generating 80 or more unique PTR queries.

Include implementation guidance, false-positive considerations, and MITRE ATT&CK mapping to T1018 (Remote System Discovery).

Testing

Validated the detection using contentctl-ng build.

Confirmed the content build completed successfully.

nasbench · 2026-10-12T08:46:58Z

+status: experimental
+type: Anomaly
+description: This detection identifies source systems generating a high number of unique DNS PTR queries, which may indicate host discovery or reverse DNS reconnaissance. This activity may be associated with tools such as Nmap when reverse DNS lookups are performed for discovered or scanned hosts.
+data_source: []


We require a data source to be used here except in edge cases. What data did you test against?

I tested the detection using Windows DNS logs (MSAD:NT6:DNS). I couldn't find a matching data source definition in the repository, so I've uploaded sanitized JSON log samples for review.
The detection can also work with Zeek DNS and Stream DNS logs, provided the required fields are mapped to the Network_Resolution data model.
The goal is to identify a high number of distinct PTR queries generated by a single source. Nmap may perform reverse DNS lookups during host discovery, making this behavior useful for detecting potential network reconnaissance when appropriate thresholds and noise filtering are applied.

1791704186_3984387.json

nasbench · 2026-10-12T08:47:56Z

+tests:
+    - name: Manual Validation
+      description: Manually validate that a source generating at least 80 unique DNS PTR queries is returned by the detection.
+      test_type: experimental
+      attack_data: []


We discourage having rules without data. Please upload your test data to https://github.com/splunk/attack_data and link it here.

Else, upload the log samples here and we will take care of it.

Here are sample log events showing the burst of PTR queries generated during host discovery:

1791704186_3984387.json

{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"236.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"235.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"234.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"237.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"238.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"243.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"250.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"221.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"248.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"11.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"253.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"3.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"1.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"245.29.16.172.in-addr.arpa","record_type":"PTR"}}

nasbench · 2026-10-12T08:49:03Z

+references:
+    - https://attack.mitre.org/techniques/T1018/


We highly recommend putting useful references where possible. Could link to some public reference that talk about PTR/Attacks in that sense?

references:

https://attack.mitre.org/techniques/T1018/

https://nmap.org/book/host-discovery-dns.html

Added the official Nmap DNS Resolution documentation (https://nmap.org/book/host-discovery-dns.html). This confirms that Nmap, by default, initiates a reverse-DNS PTR query for every host that responds to host discovery probes. This effectively pairs each discovery attempt with a corresponding resolution request, creating the predictable pattern that this detection is designed to identify.

nasbench · 2026-10-12T08:51:04Z

+description: This detection identifies source systems generating a high number of unique DNS PTR queries, which may indicate host discovery or reverse DNS reconnaissance. This activity may be associated with tools such as Nmap when reverse DNS lookups are performed for discovered or scanned hosts.
+data_source: []
+search: |-
+    | tstats `security_content_summariesonly` min(_time) as firsttime max(_time) as lasttime dc(DNS.query) AS unique_queries FROM datamodel=Network_Resolution WHERE DNS.record_type="PTR" BY DNS.src


The output will contain src and queries, try and bring other useful to the output as well.

The detection uses a threshold of 80 unique PTR queries per source to identify potential host discovery activity.
I avoided collecting all queried DNS names by default to keep the search efficient, as values(DNS.query) may increase resource usage and result size.
However, if you believe displaying the queried names would be more useful, we can modify the query as follows:
| tstats security_content_summariesonly min(_time) as firsttime max(_time) as lasttime dc(DNS.query) AS unique_queries values(DNS.query) as all_dns_queries FROM datamodel=Network_Resolution WHERE DNS.record_type="PTR" BY DNS.src

I'm happy to adjust the output based on your preference.

Co-authored-by: Nasreddine Bencherchali <nbencher@cisco.com>

MehrabBakhtar

Hi! This is my very first contribution to this project, so I really appreciate your patience and help.
I've addressed the feedback and updated the references and log samples. Looking forward to your next comments/feedback!

MehrabBakhtar · 2026-10-12T09:55:30Z

+status: experimental
+type: Anomaly
+description: This detection identifies source systems generating a high number of unique DNS PTR queries, which may indicate host discovery or reverse DNS reconnaissance. This activity may be associated with tools such as Nmap when reverse DNS lookups are performed for discovered or scanned hosts.
+data_source: []


I tested the detection using Windows DNS logs (MSAD:NT6:DNS). I couldn't find a matching data source definition in the repository, so I've uploaded sanitized JSON log samples for review.
The detection can also work with Zeek DNS and Stream DNS logs, provided the required fields are mapped to the Network_Resolution data model.
The goal is to identify a high number of distinct PTR queries generated by a single source. Nmap may perform reverse DNS lookups during host discovery, making this behavior useful for detecting potential network reconnaissance when appropriate thresholds and noise filtering are applied.

1791704186_3984387.json

MehrabBakhtar · 2026-10-12T10:02:16Z

+description: This detection identifies source systems generating a high number of unique DNS PTR queries, which may indicate host discovery or reverse DNS reconnaissance. This activity may be associated with tools such as Nmap when reverse DNS lookups are performed for discovered or scanned hosts.
+data_source: []
+search: |-
+    | tstats `security_content_summariesonly` min(_time) as firsttime max(_time) as lasttime dc(DNS.query) AS unique_queries FROM datamodel=Network_Resolution WHERE DNS.record_type="PTR" BY DNS.src


The detection uses a threshold of 80 unique PTR queries per source to identify potential host discovery activity.
I avoided collecting all queried DNS names by default to keep the search efficient, as values(DNS.query) may increase resource usage and result size.
However, if you believe displaying the queried names would be more useful, we can modify the query as follows:
| tstats security_content_summariesonly min(_time) as firsttime max(_time) as lasttime dc(DNS.query) AS unique_queries values(DNS.query) as all_dns_queries FROM datamodel=Network_Resolution WHERE DNS.record_type="PTR" BY DNS.src

I'm happy to adjust the output based on your preference.

MehrabBakhtar · 2026-10-12T10:40:14Z

+references:
+    - https://attack.mitre.org/techniques/T1018/


references:

https://attack.mitre.org/techniques/T1018/

https://nmap.org/book/host-discovery-dns.html

Added the official Nmap DNS Resolution documentation (https://nmap.org/book/host-discovery-dns.html). This confirms that Nmap, by default, initiates a reverse-DNS PTR query for every host that responds to host discovery probes. This effectively pairs each discovery attempt with a corresponding resolution request, creating the predictable pattern that this detection is designed to identify.

MehrabBakhtar · 2026-10-12T10:50:09Z

+tests:
+    - name: Manual Validation
+      description: Manually validate that a source generating at least 80 unique DNS PTR queries is returned by the detection.
+      test_type: experimental
+      attack_data: []


Here are sample log events showing the burst of PTR queries generated during host discovery:

1791704186_3984387.json

{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"236.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"235.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"234.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"237.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"238.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"243.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"250.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"221.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"248.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"11.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"253.29.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"3.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"1.30.16.172.in-addr.arpa","record_type":"PTR"}}
{"preview":false,"result":{"_time":"2026-10-11T11:06:24.000+0330","src":"172.19.26.167","query":"245.29.16.172.in-addr.arpa","record_type":"PTR"}}

MehrabBakhtar and others added 2 commits October 10, 2026 23:58

Create detect_dns_ptr_based_host_discovery.yml

abdf43a

Add DNS PTR-based host discovery detection

1127d31

MehrabBakhtar requested review from P4T12ICK, RavenTait, ljstella, nasbench, onurmerdogan, patel-bhavin, pyth0n1c, rosplk and tccontre as code owners October 10, 2026 21:15

github-actions Bot added the Detections label Oct 10, 2026

nasbench requested changes Oct 12, 2026

View reviewed changes

Apply suggestion from @nasbench

9b11a19

Co-authored-by: Nasreddine Bencherchali <nbencher@cisco.com>

MehrabBakhtar commented Oct 12, 2026

View reviewed changes

MehrabBakhtar requested a review from nasbench October 12, 2026 11:12

nasbench added this to the v6.10.0 milestone Oct 13, 2026

Conversation

MehrabBakhtar commented Oct 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MehrabBakhtar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants