Understanding Inline Cloud Analysis C2 Detections and False Positives in Cortex XDR

[tobias.fink]

Hi everyone,

I am currently investigating several Cortex XDR incidents that originate from Palo Alto Networks Firewall Security Profiles, specifically detections related to Inline Cloud Analysis, Anti-Spyware C2 classifications.

What I am trying to better understand is why a relatively large amount of legitimate-looking web traffic is being classified as C2 communication and then forwarded into Cortex XDR as incidents.

In some cases, the traffic seems to be related to normal website activity, for example connections to well-known websites such as LinkedIn or embedded third-party services loaded by those sites.

From the Cortex side, I can see the incident, but for proper troubleshooting I need to better understand the original source of the detection on the firewall side, especially the Anti-Spyware profile and Inline Cloud Analysis behavior.

My current assumption is that some modern web traffic patterns may look similar to C2-like behavior, for example:

• embedded JavaScript loading additional content dynamically

• recurring background requests

• small POST requests

• encoded URL parameters

• tracking, analytics, or telemetry endpoints

• communication with third-party domains or CDNs

• WebSocket, long-polling, or beaconing-like behavior

I would like to understand which characteristics typically cause Inline Cloud Analysis to classify traffic as C2 and what others are using to distinguish real C2 activity from false positives in daily operations.

Any practical experience, investigation approach, or recommended fields to look at would be very helpful.

Thanks in advance!

Best Regards,

Tobias

[susekar]

Hello @tobias.fink ,

Greetings for the day.

The classification of legitimate web traffic as Command and Control (C2) by the Next-Generation Firewall (NGFW) Inline Cloud Analysis engine, and its subsequent appearance in Cortex XDR, is a recognized trend often driven by connectivity latency, statistical rarity, or shared infrastructure patterns.

Why Legitimate Traffic is Classified as C2

Several technical factors and modern web patterns contribute to these detections:

-Cloud Connectivity Latency
A significant cause for Inline-Cloud-C2 misclassification is latency or unstable network paths between the NGFW and the cloud classification service. If the cloud service cannot provide a verdict within the configured timeframe, the firewall may default to a high-severity C2 alert for Unknown-TCP traffic, even if the traffic is eventually allowed.

-Statistical Rarity (Rare Domains)
Cortex XDR Analytics frequently flags legitimate third-party analytics and CDN endpoints because they appear statistically rare within a specific environment. Rules such as Abnormal Recurring Communications to a Rare Domain can trigger when benign domains exhibit periodic communication patterns that resemble C2 beaconing.

-Shared CDN Infrastructure (DNS Stitching Errors)
Multiple legitimate domains often share a single IP address on major CDNs or cloud platforms. The Analytics engine may incorrectly attribute traffic to a rare or suspicious domain when different domains resolve to the same shared IP address, resulting in DNS stitching inaccuracies.

-Specific Service Patterns
Authentication traffic from trusted services, such as Okta, can occasionally be misclassified as C2 activity when Inline Cloud Analysis is enabled within the Anti-Spyware profile.

---------------------------------

Investigation Approach in Cortex XDR

To distinguish genuine C2 activity from false positives, analysts should follow the workflow below:

Verify the Alert Source
Confirm that the detection originated from the firewall by checking the alert_source field (typically FW) and the data_sources field (typically PANW/NGFW).

Retrieve Debug Data
To extract detailed metadata such as the Threat ID, Firewall Serial Number, and Security Profile:

1. Navigate to the Alerts table.
2. Press ALT + Right-click on the alert.
3. Select Debug Alert.

Analyze Causality:
Review the Causality Card or Causality Chain to determine whether the network activity can be correlated with a local endpoint process. This helps identify whether the traffic originated from a legitimate application (such as a web browser) or from an unknown or suspicious process.

Query Raw Logs Using XQL
Inspect the raw traffic and threat data in the following datasets:

panw_ngfw_threat_raw
panw_ngfw_traffic_raw
panw_ngfw_url_raw

Reviewing these datasets can provide additional context around the communication pattern, destination, URL categorization, and firewall action, helping to determine whether the alert represents a true threat or a false positive.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar