Repository navigation
Add DNS PTR-Based Host Discovery Detection #4332
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| name: DNS PTR-Based Host Discovery | ||
| id: ae8ee2ad-1f54-4e8a-820e-eef32684e933 | ||
| version: 1 | ||
| creation_date: '2026-10-10' | ||
| modification_date: '2026-10-10' | ||
| author: Mehrab Bakhtar | ||
| 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: [] | ||
| 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 | ||
|
Contributor
There was a problem hiding this comment. The output will contain src and queries, try and bring other useful to the output as well.
Author
There was a problem hiding this comment. The detection uses a threshold of 80 unique PTR queries per source to identify potential host discovery activity. I'm happy to adjust the output based on your preference. |
||
| | `drop_dm_object_name("DNS")` | ||
| | search unique_queries >= 80 | ||
| | sort - unique_queries | ||
| | `security_content_ctime(firsttime)` | ||
| | `security_content_ctime(lasttime)` | ||
| | `dns_ptr_based_host_discovery_filter` | ||
| how_to_implement: This detection requires DNS events mapped to the Network Resolution data model, including DNS.query, DNS.record_type, and DNS.src. Ensure the data model is populated and appropriately accelerated for summaries-only searches. Tune the threshold according to normal DNS activity. | ||
| known_false_positives: Legitimate asset discovery tools, vulnerability scanners, network monitoring systems, administrative scripts, and authorized Nmap scans may generate large numbers of PTR queries. Validate the source system and its expected behavior before determining whether the activity is suspicious. | ||
| intermediate_findings: | ||
| entities: | ||
| - field: src | ||
| type: system | ||
| score: 20 | ||
| message: DNS PTR-based host discovery from $src$ | ||
| references: | ||
| - https://attack.mitre.org/techniques/T1018/ | ||
|
Comment on lines
+27
to
+28
Contributor
There was a problem hiding this comment. We highly recommend putting useful references where possible. Could link to some public reference that talk about PTR/Attacks in that sense?
Author
There was a problem hiding this comment. references: 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. |
||
| mitre_attack_id: | ||
| - T1018 | ||
| analytic_story: | ||
| - Network Discovery | ||
| asset_type: Endpoint | ||
| product: | ||
| - Splunk Enterprise | ||
| - Splunk Enterprise Security | ||
| - Splunk Cloud | ||
| category: network | ||
| security_domain: network | ||
| 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: [] | ||
|
Comment on lines
+40
to
+44
Contributor
There was a problem hiding this comment. 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.
Author
There was a problem hiding this comment. Here are sample log events showing the burst of PTR queries generated during host discovery: {"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"}} |
||
|
|
||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We require a data source to be used here except in edge cases. What data did you test against?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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