Sunburst, in short, is malware that spreads via a compromised vender supply chain (software update of a popular tool), that then uses a command and control network to download malicious payloads or instructions.

One of the best ways to search for indicators of compromise is to search for the DNS calls or Network Traffic to the malicious command and control network. Enter, the PAVO Network Traffic App for Splunk and PAVO DNS App for Splunk.

Our clients used the IP Profile and Network Traffic Search Dashboards in our Network Traffic App to look for IP addresses associated with the Sunburst attack. The bad actors associated with these types of attacks often change IP addresses, thus making it hard to maintain a watchlist. Most clients quickly pivoted to search for related domain names. In this case the domain avsvmcloud[.]com has been identified by industry security experts.

Additionally, our clients used the Query Profile Dashboard in our DNS App to quickly search for the aforementioned domain. If any communications are found, the Query Profile Dashboard provides valuable information such as time, source, destination and type of query to jump start the investigation.

You may have already vetted your network against Sunburst, but PAVO can provide other valuable advantages for you. This is a real-world example for keeping and using PAVO in your Splunk deployment. Access PAVO here for any further needs.

PDF

The Pavo team at Aplura wanted to highlight a commonly requested search technique that can help polish and tune a Splunk Use Case. In this post, we will talk about DNS resolution in the searches themselves!

DNS is becoming increasingly important in correlating events and incidents; however in many cases logs do not have both an IP and DNS name. We can use the feature “lookup dnslookup “ in order to resolve an IP address or vice versa.

Here are some starter examples you might have run into:

• Your boss needs a report of system names accessing the VPN, but the VPN only logs the IP address. Use this lookup to find the host names in that report.
• You need to correlate the IPs of systems in IDS logs to the names of systems in the authentication logs. Use this lookup to find the host names, then search those names in the authentication logs.
• Your vulnerability data has the names of systems, but you need to have both the names and IP addresses for your report. Use the reverse lookup to output the IP addresses for those names.

Of course, all commands have a few things to keep in mind. This lookup tries to resolve each value it is passed when the search runs. This could add more information, but it also slows down the search. Also, if the name or IP does not resolve, you won’t have a value.

Now that we know how useful it is, let’s take a look at the syntax. Splunk ships configurations out of the box with this external lookup ready. You do not have to add configurations to it.

The following search performs a DNS lookup on the field named “IP_data_field” and outputs the results in “host_data_field.”

index=gogo sourcetype=gaga | lookup dnslookup clientip as IP_data_field OUTPUT clienthost as host_data_field

The next search performs a reverse DNS lookup on the field named “host_data_field” and outputs the results in “IP_data_field.”

index=happy sourcetype=joyjoy | lookup dnslookup clienthost as host_data_field OUTPUT clientip as IP_data_field

Maybe you don’t need to resolve fields in your current use case but instead need to explore, analyze, and report on the DNS logs directly. Our PAVO DNS App for Splunk can help do just that. Download today.

The app uses Splunk CIM normalized data and can help you quickly find a breakdown of queries to non-existent domains; maybe you need to highlight anomalies of DNS record types; or you need to add transparency to where all the DNS data is coming from, and much more.

PDF

Let’s break it down and maybe this use case can help you in your environment.

The Use Case:

With the current environment around the world, this client knows everyone is working remotely at home. “Bad actors” are attempting now more than ever to access company systems. In order to quickly screen out possible incidents from their Citrix VPN NetScaler, the client would like a chart to show any VPN access (both successful and unsuccessful) and also who is accessing VPN from countries where there are no offices. No personnel is located overseas and travel is currently restricted.

The Search:

Search Title:

Citrix VPN Connections Outside Your Business Operations

index=netscaler (event_name='SSLVPN LOGIN' OR event_name='AAA LOGIN_FAILED') NOT src_user='scriptChecker' 
| iplocation src_ip 
| search Country=* NOT (Country='United States' OR Country='Canada') 
| table _time event_name src_user src_ip client_ip nat_ip City Country Region

Dissecting the Search:

Let’s break this down in quick detail.

index=netscaler (event_name='SSLVPN LOGIN' OR event_name='AAA LOGIN_FAILED') NOT src_user='scriptRunner'

We start by searching the VPN NetScaler logs and narrowing down to the specific events that show users logging in or failing to login. In this case, we know we have 1 automated account that runs various scripts for the BizDev Team called “scriptRunner.” The SOC has created its own explicit controls for this account and has chosen to ignore it from this report. 

| iplocation src_ip 

Next, we need to lookup (find) the location of each source IP. To do this, we are using the Splunk iplocation command. This command takes the specified IP, checks that IP in the GeoLite2-City.mmdb database, and outputs the fields. (the fields are: city, country, latitude, longitude, and region) IP Location Reference

| search Country=* NOT (Country='United States' OR Country='Canada') 

At this point in the search we have our logins and attempts, plus where they are coming from. We now need to filter down the results, removing any acceptable results from countries where offices are located. We start a sub-search with the search command, ensuring the country is specified. Then, we filter out the countries where the client has offices.

| table _time event_name src_user src_ip client_ip nat_ip City Country Region

So now, we have all the fields for location and events that meet the use case’s criteria. We are creating the table for the final presentation of results. List the fields in the order that is desired. Table Reference

We concluded this report by scheduling it to search over a small window of 15 minutes.

You may not have Citrix, but the idea of this use case can be applied to any VPN with little effort. A more generalized visualization of this search can be found in the Geo Location Dashboard within the PAVO Network Traffic App. This page will visualize all the network traffic Data Model on your network.

PDF