Setup DNS Traffic Event Monitoring with Elasticsearch SIEM

You know that as a cyber defender, you have the nearly impossible job of catching anything and everything across your entire environment. The more data you have available, the more coverage you have on the types of attacks you can detect. You can align and prioritize data collection and analysis with the Mitre ATT&CK map, which shows which data sources are required to detect which adversary techniques.

With use cases spanning connections to known bad domains and DGAs, detecting covert command and control, data exfiltration, DNS data ingestion, and analysis are high priorities for security engineers and SOC analysts. In this guide, learn how to passively collect, ingest, and analyze this data with Packetbeat and the elastic SIEM.

Packetbeat is an agent installed on a device you would like to monitor that parses network traffic and sends information about it back to the Elastic SIEM. Packetbeat differs from other beat products in its method-of-implementation options. Because this is drawing information such as DNS activity passively from the traffic received on the monitored interface, it is deployed on a specific device you would like to monitor or on a device with a network tap or span.

This guide covers the installation on a Windows 10 endpoint to monitor the activity on a single active interface. It then covers setting up packetbeat for enterprise DNS monitoring on Linux, covering the installation of Packetbeat on a CentOS 7 system with multiple interfaces monitoring span ports from different infrastructure locations.

Packetbeat, as most of the beat family, installs across all common OSes. You can find a list of downloads for supported architectures and operating systems on the Elasticsearch download site for Packetbeat.

If you followed along with the Setting Up Elasticsearch for the Elastic SIEM Guide and the subsequent Kibana installation and configuration, you have specific IP addresses that are exposed in your environment, waiting to receive information. Before you get started, make sure you collect and record that information for further use. For this guide, the IP:Port endpoint for the Elasticsearch node is 192.168.218.139:9200 and for Kibana is 192.168.218.139:5601.

A windows device could be used to collect data from a span as much as a Linux system, but one implementation use case for Packetbeat deployment can be for temporary incident response or as an additional measure on critical systems. To get a window in the DNS activity from a specific Windows endpoint, first follow the download and installation steps.

1. Download and install WinPcap . Note: If you install npcap instead of winpcap, even with the recommended WinPcap compatible API mode, the Packetbeat executable will not find the wpcap.dll fill required to run. There are instructions for attempting to use Packetbeat with Npcap here .
2. Download the correct architecture installation file for Packetbeat from elastic.

1. Download the associated sha file to the same location.
2. Open a Powershell terminal and compare the sha512 file hash to the downloaded file to ensure integrity.

1. Extract the packetbeat-7.3.2-windows-x86_64.zip file to c:\Program Files

Note: If you want to install this as a service, run the install-service-packetbeat.ps1 file from an administrative Powershell prompt.

The configuration for Packetbeat follows the same pattern as the other beat programs, located in the c:\Program Files\packetbeat-7.3.2-windows-x86_64 called packetbeat.yml. There are a series of changes to be made, some that are common, like changing the IP addresses for Elasticsearch and Kibana, and others that are specific to Packetbeat and the capability to capture traffic from the device's interfaces.

To run Powershell ISE as an administrator, click file in the top left menu bar, select open file and change the file type selector to All Files. Now navigate to the c:\Program Files\packetbeat-7.3.2-windows-x86_64 location and select and open the packetbeat.yml file.

Note: You can use whatever editor for Yaml files you like. I use Powershell ISE because it is built-in and displays the YAML file properly in an easily editable format.

Now that the file is open, scroll down until you see the Kibana section, which has the default values commented out and looks like this:

Remove the # from the line that currently says localhost:5601 and change that value to equal https://192.168.218.139:5601, to the listening address of your respective Kibana node. Do not forget to add the https:// url prefix to the Kibana address when using an external instance.

The results should look like this:

Next, continue scrolling to the Output section of the configuration file, to the first subheading named Elasticsearch .

Similar to the Kibana section configuration, you want to remove the # comment character and replace the localhost:9200 value with the value of your Elasticsearch node's listening address. In this case, it is 192.168.218.139:9200.

This config differs from the Kibana configuration in that it does not require the https:// prefix.

For Packetbeat, specifically the network device and what transactional data to report back to the Elastic SIEM, scroll back to the top of the configuration file and locate the section called Network device*

Here you need to change the packetbeat.interfaces.device: value to the name of the interface from which you want to capture traffic. First, you need to get a list of the interfaces available to Packetbeat and how they are named. In the bottom window of Powershell ISE, use the PS console to navigate to the c:\Program Files\packetbeat-7.3.2-windows-x86_64 directory and run the packetbeat devices command to list the interfaces available for this configuration option.

Using this list, select the associated number of the interface you want to monitor. For this device, it is the main wifi interface assigned an IP address called Microsoft, and the device number is 1. Changing the device value to equal 1, the network device config should look like this:

Next, look at the section called Transactional Protocols. These are protocols that parsed beyond the simple IP 5 tuple of information provided from a flow. For each protocol, the parser adds additional information to the events to the SIEM. For this guide, the concern is with DNS, but there is a multitude of other protocols supported. Ensure that the -type: dns entry is configured and the port is set.

Now save the configuration, but do not close the Powershell ISE Window.

In the Powershell ISE terminal window, run a test on the new configuration file.

Next, for the first run of Packetbeat, run .\packetbeat.exe in the console using the setup option to load the templates, indexes, and dashboards into the configured Elasticsearch and Kibana nodes.

A successful setup output looks like this, indicating all components successfully connected, created an index, template, and uploaded dashboards, if not already done by another installation.

Now run Packetbeat with the -e flag to log output to the stdout (the console in which you are running the program). Successful execution finalizes with reports of events sent to the Elasticsearch node.

Notice the events field at the end of the JSON block and the value that says published. This value is the number of events pushed in the current batch to the Elasticsearch node. If this is zero, then there are either no events or the monitoring configuration is not set up correctly.

If you see these events publish from this side, get a definite confirmation by checking the Elastic SIEM overview page. It should show Packetbeat events under the Network section. DNS data is vital as it is is just one of the supported Packetbeat datasets for the Elastic SIEM. There are also TLS and Flow datasets that are usable within the SIEM context with this current release.

Flow data is any TCP or UDP session captured on the interface Packetbeat is monitoring. DNS and TLS data are specific to lookups and encrypted web page browsing. If you do not see any data for these datasets, be sure to open a browser and browse to a few sites.

You are now the proud owner of DNS data for security analysis within the context of the Elastic SIEM.

• Packetbeat Options - https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-interfaces.html
• Elastic SIEM Guide - https://www.elastic.co/guide/en/siem/guide/current/index.html
• Packetbeat Guide - https://www.elastic.co/guide/en/beats/packetbeat/current/index.html
• Elastic SIEM Dat Sources - https://www.elastic.co/products/siem

• SET: Detecting Malicious Traffic with Signature and Session Analysis
• SET: Detecting Network Anomalies with Behavioral Analysis
• SET: Monitoring Assets and Topology

Packetbeat is installed with very similar steps on a CentOS 7 system and set up to monitor.

Install the required libpcap package, then download and install the packet beat RPM.

With the RPM or DEB package installation, the configuration file lives in /etc/packetbeat and the binary is added to your path.

Before opening the configuration YAML file, list the devices available to Packetbeat and the associated index or device number for each.

In this instance, the ens37 and ens38 interface have traffic mirrored from a core switch to only monitor these two interfaces. A separate instance of Packetbeat runs for each. The faster af_packet option to read the packets from memory is available on Linux systems and is faster and less CPU intensive than the use of the libpcap options. Open the configuration file and edit the Network devices section to reflect the first network interfaces you want to monitor and the use of the af_packet options.

Before closing, edit the Kibana output and the Elasticsearch output to the same values corresponding to the previously set up Elastic SIEM. Then exit nano, saving the file with ctrl+x, y, enter. Test your configuration, and then run the initial Packetbeat set up.

Create a copy of the configuration file and append the name with 2 or a descriptor of your choice. Edit the new configuration file, changing only the interface index number and the shipper name.

Everything is set up to monitor your mirrored or span interfaces, and it is now time to run Packetbeat. You can also run Packetbeat as a service after the RPM or DEB install, but for the first run and to ensure this works, run from the terminal, first using screen to monitor the two separate processes.

This runs with the default packetbeat.yml file with the first interface. Monitor for successfully published events then detach from that terminal session with ctrl+a+d and enter a new screen session and run Packetbeat with the second configuration file.

Once you see events being published to the Elasticsearch node, check out the Elastic SIEM Network page to ensure you are receiving data. You should see a litany of network information populated.

The DNS data you were after in the first place is passively collected.

Also, in the Packetbeat index information, you can see both agent sources.

Now get to hunting!

• Packetbeat Options - https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-interfaces.html
• Elastic SIEM Guide - https://www.elastic.co/guide/en/siem/guide/current/index.html
• Packetbeat Guide - https://www.elastic.co/guide/en/beats/packetbeat/current/index.html
• Elastic SIEM Dat Sources - https://www.elastic.co/products/siem

• SET: Detecting Malicious Traffic with Signature and Session Analysis
• SET: Detecting Network Anomalies with Behavioral Analysis
• SET: Monitoring Assets and Topology