Proper Safelisting When Threat Hunting

Intro

Safelisting can dramatically reduce the time it takes to perform a proper threat hunt. However, if it is done incorrectly, it can blind us to active threat vectors. In this blog entry I’ll discuss why safelisting is so important and how to implement it correctly.

 

What is Safelisting?

“Safelisting” is the act of identifying outbound network connections that have a recognized business need, and then removing the display of these sessions from all future threat hunts. By removing these verified sessions, future threat hunts can be executed more quickly as we will not have to verify the same sessions over and over again. Further, new persistent connections become more apparent as known sessions are no longer mixed in.

 

A Safelisting Example

As an example of safelisting, imagine that during a threat hunt you identify a strong beacon signal originating on an internal host and going to an IP address out on the Internet. After performing some research, you identify that all of the connections were created by the application “Teams.exe”. The application was reaching out to the fully qualified domain name (FQDN) “config.teams.microsoft.com” when it connected to this IP address. All of the connections being analyzed were TLS sessions and the server returned a verifiable digital certificate with the Server Name Indicator (SNI) value of “config.teams.microsoft.com”.

If Microsoft Teams is an application commonly used by our business, we can expect to see many systems reaching out to this FQDN. With this in mind, it may make sense to ignore all outbound traffic from any internal system that is trying to reach “config.teams.microsoft.com”. Our safelist would include an entry that hides all traffic going to “config.teams.microsoft.com” from the final threat hunting report.

 

Methods of Safelisting

There are a number of ways safelists can be implemented. Each has their strengths and weaknesses. In many cases, you may want to implement a mixture of processes.

 

BP Filter

Berkeley packet (BP) filtering is a method of ignoring certain traffic patterns from being captured and analyzed. These can typically be implemented at the firewall level or directly within packet capture tools like dumpcap and Zeek. One of the benefits of BP filters is that they reduce the amount of data that must be processed. This can reduce storage requirements and processing time. It can also permit us to scale up to larger Internet link speeds.

BP filtering does have some drawbacks. To start, the filtering tends to be pretty rudimentary. You can usually filter based on IPs and ports but not data within the application layer. You also may not be able to filter based on FQDN. Further, when BP filters are implemented, the data is not being collected. This means that if you implement an incorrect filter, the data is completely gone.

 

Display Filtering

With display filtering, we collect all of the data, but we hide safelisted entries from the data being presented to the threat hunter. How this gets implemented is highly dependent on the tools we are using. In short, we effectively exclude any safelisted entries from the report being used by the threat hunters.

One of the benefits of display filtering is that all of the data is still collected. If we inadvertently add a safelist entry that we shouldn’t have, the data is still there and can be reviewed. Think of it as a safeguard from shooting yourself in the foot. The only downside to display filtering is that it will not scale as well as BP filtering because more data will be collected and stored.

 

Safelisting Example

Let’s walk through the “config.teams.microsoft.com” example above and identify the best way to safelist this entry. Here are the data points we have to work with:

• Internal source IP address
• Application on the source system which created the connection
• The FQDN which returned the destination IP address
• Destination IP address
• The protocol TLS was used during the connections
• The SNI value in the digital certificate

 

Safelisting Example – What Will Not Work

When creating safelist entries, you want to be as specific as possible while still being general enough to match all instances. Let’s run through the options for “config.teams.microsoft.com” to identify the best way to safelist this entry. We expect multiple systems will be connecting to this server, so safelisting based on source IP is not going to work. Further, the source app may not be the best choice as other apps may be able to tunnel data through this app when accessing the network.

This leaves us with the external data points. We can’t really use the FQDN as this data is exchanged in a separate session (the DNS query). The destination IP address may be problematic if it is a Content Delivery Network (CDN) server. CDNs act as pass-throughs for other servers. This means that multiple FQDNs may resolve to the same IP address(es). This could cause us to safelist traffic we didn’t intend to.

 

Safelisting Example – What Can Go Wrong

As an example, imagine we have two entities; “example.com” which is a legitimate business and “evil.com” which is a nefarious actor. Both are using the same CDN provider. When resolving example.com and evil.com, both are going to resolve to IP addresses for the CDN provider. So if we try to safelist the IPs associated with example.com, we are going to inadvertently safelist the evil.com traffic which is using the same IP addresses. This is obviously not the intent, as we would now be blind to any attacks from evil.com.

 

Safelisting Example – What Will Work

So with regards to “config.teams.microsoft.com”, our best option is to use the SNI parameter within the digital certificate. This will work if the internal system is directly connecting to that server. It will also work if the connection passes through a CDN provider. Since we would be keying in on the value which identifies the true server the source is trying to connect to. The traffic will not get confused with other customers using the same CDN provider.

In this example, we can assume that any internal system talking to “config.teams.microsoft.com” would be acceptable. This may not always be the case. For example, consider TeamView which is used for remote access. You would only want to safelist TeamViewer from servers where the source IP has been approved for use with TeamViewer. If TeamViewer shows up unexpectedly on some other server, you would obviously want that to be identified during a threat hunt. So when creating safelists, consider if a source IP restriction is needed.

 

Safelisting Best Practices

• Here are some basic rules to follow for creating safelists:
• BF filters reduce load but display filters are much more flexible
• For HTTP traffic, safelist based on the “host” parameter
• For HTTPS traffic, safelist based on the “SNI” parameter with the digital certificate
• For peace of mind, you can also check the validation status of the digital certificates
• When the traffic is not based on HTTP or HTTPS, use the FQDN
• When no FQDN is present, safelist based on destination IP
• Try each of the above options in the order they have been presented
• Consider if the safelist should be restricted to only certain internal IPs

 

Summary

Safelisting is a great way to reduce the workload involved with performing a threat hunt. When it comes to applying safelists, you have many options. Leverage the information above to make the best choices for your environment.