topic Re: Anti-Spyware Behaviour and Inline Cloud Analysis in General Topics

Anti-Spyware Behaviour and Inline Cloud Analysis

nohash4u — Fri, 09 May 2025 20:35:25 GMT

Hello All,

I have run into some curious behaviour with Anti-Spyware. High severity threats tagged as threat type 'spyware' are coming through the firewall with an action of alert, despite all configurations pointing to an action that should either be reset-both, or sinkhole.

I have confirmed the following:

The security policy rule that matches the traffic does have the correct security profile group set.
The security profile group set does reference the specific Anti-Spyware security profile.

Within the Anti-Spyware profile here is the breakdown:

Signature Policies
- Severity medium, high, and critical all have an action of reset-both.
Signature Exceptions
- None.
DNS Policies
- All signature sources have a log severity set to high, and an action of sinkhole.
DNS Exceptions
- None.
Inline Cloud Analysis
- Enabled.
- The action for all models is set to alert.

Could this behaviour be a result of inline cloud analysis?

Is there a way to tell if the traffic flow has had inline cloud analysis applied to it? If so, I have not found a way to tell as of yet. I have checked the columns available in the threat logs, as well as the Detailed Log View, but to no avail.

I would like to note that the threat ID is identified in each traffic flow. An example is 109010004.

As always: any insight is much appreciated!

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

kiwi — Mon, 12 May 2025 08:31:13 GMT

Hi @nohash4u ,

Try enabling the threat category in the detailed threat logs (enable the column if needed).

Notice in my example screenshot how the inline-cloud-c2 category has the "alert" action for high severity threats indicating that the Inline Cloud engine took action as opposed to the anti-spyware engine (where the action would be reset-both).

Hope this helps,

-Kim.

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

nohash4u — Mon, 12 May 2025 17:13:13 GMT

Hello @kiwi,

Thanks for the great insight on how to determine if a threat is identified via Inline Cloud Analysis. In my case I have yet to see this appear under the threat category column.

Here is an example:

On another thread - it is almost as if layer 7 inspection is not occurring or functioning properly. I did notice the security policy rule that matches these traffic flows has the 'Disable Server Response Inspection' option enabled. Would this have an implication on DNS related traffic flows ? Even so, I find it interesting that the flow is marked with a certain severity, and yet the prescribed action is not enforced.

Lastly, could this be timeout related? I have noticed via the detailed log view that the flows start with an action of alert, and end 30 seconds later with an action of allow.

Thanks again for your insight.

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

Raido_Rattameister — Mon, 12 May 2025 19:10:21 GMT

Enabling "Disable Server Response Inspection" is very insecure practice because you will bypass whole server to client flow from inspection.

Could make sense only for incoming traffic towards web servers that you control and really trust that they are not hacked and don't host anything malicious and you really need to reduce load on the firewall.

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

nohash4u — Mon, 12 May 2025 22:50:28 GMT

Thanks for confirming. The documentation also strongly advises against enabling DSRI. I did not configure this device, but I will pass this along in my future discussions.

Regardless, the main unknown is the action of alert for high severity DNS based threats being inconsistent with the configuration on the firewall. Would enabling DSRI interfere with the enforcement behaviour? If so, why is the action alert with the threat ID identified as something that should be sinkholed, reset-both, etc?

More than happy to open a TAC case, but I thought I would ask here first!

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

nohash4u — Mon, 26 May 2025 21:45:21 GMT

For those curious - I have opened a TAC case, and I will post the results here for future reference.

Re: Anti-Spyware Behaviour and Inline Cloud Analysis

nohash4u — Mon, 09 Jun 2025 18:32:44 GMT

Bittersweet Update

I would like to note that the DSRI theory can be discarded as the symptoms are prevalent on another HA pair on the same PAN-OS version where the matching security policy rule does not have this option enabled.

I opened a TAC case. Here are the findings:

Analysis of the 'show dns-proxy dns-signature counters' cli command on both HA pairs indicated there were a small (but not insignificant) amount of DNS Security Cloud queries that were outside the DNS Signature Lookup Timer configuration. The breakdown of this can be found here: How to do basic debugging for DNS Security before you open a su... - Knowledge Base - Palo Alto Networks
The behaviour of such a scenario is outlined here: DNS Security Behaviour in PAN-OS when There Is Connectivity Iss... - Knowledge Base - Palo Alto Networks
- "When the DNS response is received within DNS signature lookup timeout and no cloud verdict is received (e.g. due to DNS Security cloud service connectivity issue).
  DNS response will be dropped and PAN-OS will re-transmit the original DNS request (extra DNS request in the transmit stage).
  If the next DNS response is received after DNS signature lookup timeout expired, DNS response will be forwarded to the client as the fail open mechanism."

The behaviour above describes the symptoms perfectly. It was thought that perhaps there could be a bug, as there is one of a similar nature

outlined in PAN-275077, however, that is specific to phishing domains.

Proving exactly when the fail open mechanism occurs, and when it does not is open to interpretation as this point. It was thought that perhaps System logs will be generated like the following screenshot:

That being said, I was unable to match the event timestamps in the System logs with the event timestamps in the Threat logs.