Does anyone have examples of how to use Splunk to find IP sources with a high volume of DNS traffic?
The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.
Security analysts can detect data exfiltration by monitoring DNS activity for total bytes transferred and looking for anomalies and deviations from normal traffic levels.
How to implement: This example use case depends on network communication data.
Install the add-on(s) that correspond to the firewall devices used in your data center. Find these and other add-ons on Splunkbase: Splunk Add-on for Check Point OPSEC LEA, Splunk Add-on for Cisco ASA, and the Palo Alto Networks Add-on for Splunk. Some add-ons in this answer are not Splunk-supported, but are available for download from Splunkbase as an open-source tool. See their entry in Splunkbase for more information. Follow the documentation of the respective add-on to install it and to collect data.
Best practice: For all of the data inputs, specify a desired target index to provide a more sustainable practice for data access controls and retention models. By default, Splunk collects the data in the default index named main
.
Data check: Run the following search to verify you are searching for normalized network data that is ready for this use case:
earliest=-1day index=* tag=network tag=communicate
| head 10
Malware authors and adversaries often use DNS to access a network to exfiltrate data. The technique is popular because organizations monitor for data exfiltration, but only monitor common protocols and fail to monitor DNS as an exfiltration vector. A common method of data exfiltration is to send out a huge volume (in bytes) of DNS or ping requests, embedding data into the payload. This is often not logged.
This search includes calculations that detect anomalous DNS traffic. Learn more about this example, including an explanation of each line in the search, at the Sources Sending A High Volume Of DNS Traffic documentation on Splunk Security Essentials Docs.
Run the following search.
tag=network tag=communicate
| bucket span=1h _time
| stats sum(bytes*) AS bytes* BY src_ip _time
| eventstats max(_time) AS maxtime avg(bytes_out) AS avg_bytes_out stdev(bytes_out) AS stdev_bytes_out
| eventstats count AS num_data_samples avg(eval(if(_time < relative_time(maxtime, "@h"),bytes_out,null))) AS per_source_avg_bytes_out stdev(eval(if(_time < relative_time(maxtime, "@h"),bytes_out,null))) AS per_source_stdev_bytes_out BY src_ip
| where num_data_samples >=4 AND bytes_out > avg_bytes_out + 3 * stdev_bytes_out AND bytes_out > per_source_avg_bytes_out + 3 * per_source_stdev_bytes_out AND _time >= relative_time(maxtime, "@h")
| eval num_standard_deviations_away_from_org_average = round(abs(bytes_out - avg_bytes_out) / stdev_bytes_out,2), num_standard_deviations_away_from_per_source_average = round(abs(bytes_out - per_source_avg_bytes_out) / per_source_stdev_bytes_out,2)
| fields - maxtime per_source* avg* stdev*
Best practice: In searches, replace the asterisk in index=*
with the name of the index that contains the data. By default, Splunk stores data in the main
index. Therefore, index=*
becomes index=main
. Use the OR
operator to specify one or multiple indexes to search. For example, index=main OR index=security
. See About managing indexes and How indexing works in Splunk docs for details.
Known false positives: False positives for this search are rare for hosts with static IPs. If you have a small number of DHCP hosts that routinely send a large volume of DNS, consider filtering out those destinations to reduce noise.
How to respond: When this search returns values, initiate your incident response process and identify owners of other systems that the alerting system communicates with. Capture the time, applications, destination systems, ports, byte count and other pertinent information for the systems receiving the alerts.
If systems that receive the alerts are internal, contact the owner of the system as to see if the communication is authorized. If the communication is authorized, document the name of the person who authorized the communication. If the communication is not authorized, additional investigation is warranted to determine if DNS is being used as a covert channel to exfiltrate data.
src_ip
and bytes_out
are properly defined.If no results appear, it may be because the add-ons were not deployed to the search heads, so the needed tags and fields are not defined. Deploy the add-ons to the search heads to access the needed tags and fields. See About installing Splunk add-ons in the Splunk Add-ons manual.
For troubleshooting tips that you can apply to all add-ons, see Troubleshoot add-ons in the Splunk Add-ons manual.
For more support, post a question to the Splunk Answers community.
The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.
Security analysts can detect data exfiltration by monitoring DNS activity for total bytes transferred and looking for anomalies and deviations from normal traffic levels.
How to implement: This example use case depends on network communication data.
Install the add-on(s) that correspond to the firewall devices used in your data center. Find these and other add-ons on Splunkbase: Splunk Add-on for Check Point OPSEC LEA, Splunk Add-on for Cisco ASA, and the Palo Alto Networks Add-on for Splunk. Some add-ons in this answer are not Splunk-supported, but are available for download from Splunkbase as an open-source tool. See their entry in Splunkbase for more information. Follow the documentation of the respective add-on to install it and to collect data.
Best practice: For all of the data inputs, specify a desired target index to provide a more sustainable practice for data access controls and retention models. By default, Splunk collects the data in the default index named main
.
Data check: Run the following search to verify you are searching for normalized network data that is ready for this use case:
earliest=-1day index=* tag=network tag=communicate
| head 10
Malware authors and adversaries often use DNS to access a network to exfiltrate data. The technique is popular because organizations monitor for data exfiltration, but only monitor common protocols and fail to monitor DNS as an exfiltration vector. A common method of data exfiltration is to send out a huge volume (in bytes) of DNS or ping requests, embedding data into the payload. This is often not logged.
This search includes calculations that detect anomalous DNS traffic. Learn more about this example, including an explanation of each line in the search, at the Sources Sending A High Volume Of DNS Traffic documentation on Splunk Security Essentials Docs.
Run the following search.
tag=network tag=communicate
| bucket span=1h _time
| stats sum(bytes*) AS bytes* BY src_ip _time
| eventstats max(_time) AS maxtime avg(bytes_out) AS avg_bytes_out stdev(bytes_out) AS stdev_bytes_out
| eventstats count AS num_data_samples avg(eval(if(_time < relative_time(maxtime, "@h"),bytes_out,null))) AS per_source_avg_bytes_out stdev(eval(if(_time < relative_time(maxtime, "@h"),bytes_out,null))) AS per_source_stdev_bytes_out BY src_ip
| where num_data_samples >=4 AND bytes_out > avg_bytes_out + 3 * stdev_bytes_out AND bytes_out > per_source_avg_bytes_out + 3 * per_source_stdev_bytes_out AND _time >= relative_time(maxtime, "@h")
| eval num_standard_deviations_away_from_org_average = round(abs(bytes_out - avg_bytes_out) / stdev_bytes_out,2), num_standard_deviations_away_from_per_source_average = round(abs(bytes_out - per_source_avg_bytes_out) / per_source_stdev_bytes_out,2)
| fields - maxtime per_source* avg* stdev*
Best practice: In searches, replace the asterisk in index=*
with the name of the index that contains the data. By default, Splunk stores data in the main
index. Therefore, index=*
becomes index=main
. Use the OR
operator to specify one or multiple indexes to search. For example, index=main OR index=security
. See About managing indexes and How indexing works in Splunk docs for details.
Known false positives: False positives for this search are rare for hosts with static IPs. If you have a small number of DHCP hosts that routinely send a large volume of DNS, consider filtering out those destinations to reduce noise.
How to respond: When this search returns values, initiate your incident response process and identify owners of other systems that the alerting system communicates with. Capture the time, applications, destination systems, ports, byte count and other pertinent information for the systems receiving the alerts.
If systems that receive the alerts are internal, contact the owner of the system as to see if the communication is authorized. If the communication is authorized, document the name of the person who authorized the communication. If the communication is not authorized, additional investigation is warranted to determine if DNS is being used as a covert channel to exfiltrate data.
src_ip
and bytes_out
are properly defined.If no results appear, it may be because the add-ons were not deployed to the search heads, so the needed tags and fields are not defined. Deploy the add-ons to the search heads to access the needed tags and fields. See About installing Splunk add-ons in the Splunk Add-ons manual.
For troubleshooting tips that you can apply to all add-ons, see Troubleshoot add-ons in the Splunk Add-ons manual.
For more support, post a question to the Splunk Answers community.