A PAN-OS device's threat logs show Suspicious DNS Query triggers.
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.
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.
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:
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.
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.
For more information on why DNS signatures change, see this article.
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.
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:
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.
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:
As a result, a C2 Domain Signature was generated to prevent traffic to the associated domain: