All Apps and Add-ons

Example of how to find IP sources with a high volume of DNS traffic?

sloshburch
Splunk Employee
Splunk Employee

Does anyone have examples of how to use Splunk to find IP sources with a high volume of DNS traffic?

0 Karma
1 Solution

sloshburch
Splunk Employee
Splunk Employee

The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.

For more information on this and other examples, download the free Splunk Security Essentials app on Splunkbase.

Security analysts can detect data exfiltration by monitoring DNS activity for total bytes transferred and looking for anomalies and deviations from normal traffic levels.

Load data

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

Get insights

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.

Help

  • Exclude actual DNS servers from this analysis.
  • If this search this produces too much noise for your environment, tune it to operate on specific servers.
  • Build two separate searches for user-subnet and server-subnet ranges to separate the organization-wide average.
  • Ensure the fields 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.

View solution in original post

0 Karma

sloshburch
Splunk Employee
Splunk Employee

The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.

For more information on this and other examples, download the free Splunk Security Essentials app on Splunkbase.

Security analysts can detect data exfiltration by monitoring DNS activity for total bytes transferred and looking for anomalies and deviations from normal traffic levels.

Load data

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

Get insights

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.

Help

  • Exclude actual DNS servers from this analysis.
  • If this search this produces too much noise for your environment, tune it to operate on specific servers.
  • Build two separate searches for user-subnet and server-subnet ranges to separate the organization-wide average.
  • Ensure the fields 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.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In September, the Splunk Threat Research Team had two releases of new security content via the Enterprise ...

New in Observability - Improvements to Custom Metrics SLOs, Log Observer Connect & ...

The latest enhancements to the Splunk observability portfolio deliver improved SLO management accuracy, better ...

Improve Data Pipelines Using Splunk Data Management

  Register Now   This Tech Talk will explore the pipeline management offerings Edge Processor and Ingest ...