Palo Alto Networks Knowledgebase: What are suspicious DNS queries?

What are suspicious DNS queries?

(2921 Views)
Created On 09/30/18 18:32 PM - Last Updated 09/30/18 18:32 PM
Categories:  AutoFocus,  WildFire

Issue:


Solution:


A PAN-OS device's threat logs show Suspicious DNS Query triggers. 

 

2016-06-09_susp-dns.pngDetail of Threat log with Suspicious DNS Query.

What are suspicious DNS query signatures?

Suspicious DNS Query signatures are looking for DNS resolution to domains potentially associated with C2 traffic, which could be an indication of a breached machine.

 

Suspicious DNS Query signatures are part of Palo Alto Networks' approach to injecting protections into every point in the kill chain, in order to provide a layered defense in one solution, in which a threat actor has to penetrate an additional point of inspection in order to be successful. With the dynamic nature of the current threat landscape, antivirus protections, vulnerability exploitation detection, and URL filtering are effective, but more can be done. If a connection to a potentially malicious destination can be cut down before a name resolution even occurs, this is something that should be done.

 

Suspicious DNS signatures can be set to alert, to block the name resolution by resetting or dropping the connection, or sinkholed by leveraging the product's DNS sinkhole features. The suggested mitigation to adhere with Palo Alto Networks best practices is to sinkhole, so that one can identify the source IP of the suspected DNS query.

 

How do suspicious DNS query signatures work? Where do they come from?

Suspicious DNS query signatures (here-to refered to as SDNS signatures) operate by DNS traffic passing through the PAN-OS appliance inspected for a name lookup to any domain for which a signature currently exists. If packet captures are enabled on SDNS signatures, they are simply DNS queries with a specific domain in them. 

 

2.PNG

 

SDNS signatures are a result of intelligence gathering on the Palo Alto Networks back-end. WildFire sandbox sample detonation, external intelligence feeds, and analysis from researchers are some examples of where these signatures may originate.

 

Once created, these signatures make their way to PAN-OS appliances in two ways:

 

  • WildFire content, in the form of signatures 3,800,000 - 3,999,999. They can be updated/changed every 15 minutes, depending on how often the device's WildFire content update schedule is configured, and whether or not the signature is still active. These signatures will show up in the threat log in the following format: Malwarefamilyname:domain (Ex: None:google[.]com)
    If no family name is associated with the samples used to generate the signature, 'None' takes its place.

 

  • Antivirus content, in the form of signatures 4,000,000 - 4,199,999. AV content is usually released at roughly 7AM EST, once every twenty-four hours. These signatures will show up in the threat log in the following format: Suspicious DNS Query: Malwarefamilyname:domain (Ex: Suspicious DNS Query: None:google[.]com)
    If no family name is associated with the samples used to generate the signature, 'None' takes its place. 

The signatures show up in the "spyware" portion of content. For more information on what can be discerned by a signature's ID number reference this link.

 

You may have noticed that SDNS Query signatures that have been previously triggered have their names changing in the threat monitor and you may be wondering why this happened.

 

The current implementation of SDNS signatures, and for content in general, is that each threat has an ID assigned in the current content. Since content space is not infinite, keeping the most active and dangerous threats in the SDNS content space at any one given time is a priority. Since the threat landscape changes so quickly, these signatures can be replaced.

 

Our current implementation of the threat monitor UI queries the "Name" field directly from the content database currently installed on the firewall. What this means is that when one loads the threat monitor, signature triggers that may have previously read with one domain may now show whatever is currently assigned to the signature.


Example:

  • In WildFire Content 1, Google[.]com is assigned SDNS sig 3,800,000.
  • This threat triggers, and an entry for 3,800,000 Google[.]com is in the threat logs.
  • WildFire content 2 is applied.
  • In WildFire Content 2, Bing[.]com has taken the place of Google[.]com in SDNS sig 3,800,000.
  • Previous threat triggers now incorrectly show the name Bing[.]com associated with the previous triggers.

 

For now, the simplest work around is to enable packet captures on SDNS signatures by opening the spyware profile assigned to the security rule the DNS traffic is traversing. Packet captures are static data and will not change.

 

3.PNG

 

For more information on why DNS signatures change, see this article.

 

What should I do with Suspicious DNS Query signature triggers?

SDNS signature triggers are not meant to operate as an absolute indication of compromise, but can be used alongside other indicators to identify hosts that may be at risk, or require more attention. The host may be displaying outbound network patterns that are indicative of but not guaranteed to be malicious activity.

 

Seeing a host generate traffic to a domain an SDNS signature exists for can help proactive security analysts identify traffic on their networks that may warrant inspection or further action. If one sees a host trigger SDNS signatures, coupled with AV detection, a vulnerability signature trigger, or an attempt to visit via web browsing a URL categorized as malware, the SDNS signature can be used to add an additional measure of confidence to the necessity of further action on the host.

 

AutoFocus customers may look through their WildFire samples, other public samples, and query for any samples that had a verdict of malware and reached out to a specific domain. This can help the analyst understand why the signature exists, and what the behavior of the samples that generated traffic to the questionable domain look like, for potential incident response action. 

2016-06-10_susp-dns2.pngAutoFocus showing a query on a suspicious DNS domain.

To investigate the signature further, third-party open source intelligence sources are a fantastic method to see what kind of intelligence the security community has on the domain.

 

A few examples include:

  • Check other vendor responses via VirusTotal URL scanning.
  • Check passive DNS history of the domain using PassiveTotal.
  • Leverage WHOIS to see specifics on who owns a domain, when it was registered, and other data.

 

Once determination has been made as to if the alert is worthy of investigation, packet captures on the host to see contextual data, such as user activity and suspicious traffic, can help to set the scene for whether or not further action is required.

 

What if you've done all the above, a specific SDNS signature is generating a significant number of alerts, and no negative activity appears to be associated with the domain as far as you can tell?

 

In this instance, Palo Alto Networks support can help identify if the signature is a candidate for disable or not. If the signature appears to be generating significant noise for numerous customers, we don't want you to to grow tired inspecting your threat logs. However, if there is justification for the signature, you can always leverage exception functionality in spyware profiles to allow the traffic and stop alerts.

 

Example Suspicious DNS Query Signature:

 

Let us use SHA256 932836effd33218470e1c78dad3505d59af31ecff599e875ed79f47114552883 as an example.

 

We can see that this sample is a portable executable that, once executed, generated some suspected C2 HTTP traffic:

1.PNG

 

 

As a result, a C2 Domain Signature was generated to prevent traffic to the associated domain:

2.PNG

 

Attachments:

Actions:
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5kCAC&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Change Language: