The Security Easy Button. Block Threats in Real Time.

Menu

Under the Hood: How ThreatSTOP Protects Against WannaCry

One of the key features of the ThreatSTOP platform is the ability to tailor a security policy to meet specific operational objectives. In a broad sense, this is done by selecting the policy components, such as botnets or banking Trojans, but another powerful tool is the application of User Defined Lists (UDLs) to the customer security policy. Using UDLs, our customers can use ThreatSTOP DNS Firewall to identify machines infected by Wannacry ransomware that are latent because of the accessibility of the “kill switch” domains.

UDL 101

UDLs are most commonly used to allow or block specific IP address or domains that may have a business impact. For example, your company might want to block or monitor employee access to facebook.com. Or, you might whitelist the IP address of a key vendor website whose IP address occasionally winds up on a threat list. (Because it shares the IP with malicious sites) In these cases, a customer would simply log into the ThreatSTOP portal and add the domain or IP address to a User Defined List. They would then apply the UDL to their current security policy with the appropriate action (e.g. allow / block / passthru / cname). Fifteen minutes later, the new policy is generated and sent to their device. Users of machines that connect – or attempt to connect – to the UDL entries will ultimately show up in their ThreatSTOP report.

UDL Actions

There is more you should know about UDL actions. First, there are two types of UDLs: ones that have IP addresses, and ones that have domain names. Customers that use ThreatSTOP IP Firewall can use only IP Address UDLs (since router security policies don’t use domain names). DNS Firewall customers can use both types of UDLs, since the Response Policy Zones (RPZs) that DNS servers use to implement security policies can contain both domain and IP address entries.

For IP address UDLs, there are only two actions: allow and block. For domain UDLs, there are more actions. The most common are NXDOMAIN, NODATA, DROP, PASSTHRU, and what is typically referred to as “walled garden." The first three essentially block the DNS request by providing no answer or no data back to the requesting machine. PASSTHRU does what you might think it would – it allows (passes through) the DNS request and logs the request. The “walled garden” action allows ThreatSTOP customers to modify the DNS request, responding with an IP address or CNAME for a website of their choice. For instance, a company could use this to redirect DNS lookups for facebook.com to an internal website reminding their employees of the company’s internet usage policy.

How to Detect Wannacry

The original Wannacry malware included four “kill switch” domains. When the malware successfully infects a machine, it checks to see if the kill switch domains respond to a web request. If the domains respond, the malware is disabled and does not encrypt files. In order to access the kill switch domains, the malware must do a DNS query. If we can find out which machines are querying for the kill switch domains, we know which machines are infected and they can be remediated before data is lost.

In order to do this, ThreatSTOP customers could add the kill switch domains to a domain UDL and then apply the UDL to their security policy. Since it is critical that the infected machines are able to receive a web response from the kill switch domains, the UDL should be added with a PASSTHRU or walled garden action. After the security policy is regenerated and distributed to the customer DNS server, any queries for the kill switch domains will show up in their ThreatSTOP report.

Summary

In this article, we explained how ThreatSTOP user defined lists (UDLs) may be used in conjunction with DNS Firewall as a tool for providing custom responses to Wannacry malware DNS requests. By applying a PASSTHRU action for the kill switch domains, we can keep the malware dormant while logging the address of the infected machine. The machine can be remediated without the risk of data encryption.