[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise CVE-2026-0300
Report Type:
EXP
Threat Category:
Active edge-infrastructure exploitation
Assessment Date:
May 6, 2026
Primary Impact Domain:
Firewall control-plane integrity and perimeter security-control trust
Secondary Impact Domains:
Segmentation enforcement, logging reliability, perimeter visibility, administrative-control integrity, configuration integrity, downstream intrusion exposure, operational continuity, customer trust, legal and regulatory risk
Affected Asset Class:
PAN-OS PA-Series and VM-Series firewalls with User-ID Authentication Portal or Captive Portal services enabled and reachable from untrusted networks
Threat Objective Classification:
Unauthorized firewall control-plane access or influence, with potential configuration manipulation, visibility reduction, firewall-originated outbound communication, and conditional downstream access enablement
BLUF
[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 creates material enterprise risk by turning an exposed firewall-hosted authentication portal into a potential path for perimeter control-plane compromise. The risk is driven by active exploitation of affected PA-Series and VM-Series firewalls where User-ID Authentication Portal or Captive Portal services are enabled and reachable from untrusted networks. The threat posture is elevated because successful exploitation can affect the firewall itself, which is both the exposed target and a security enforcement point for segmentation, logging, traffic inspection, administrative access, and perimeter visibility. Executive action is required to validate exposure, restrict or disable unsafe portal access, preserve firewall telemetry, review historical portal activity, validate configuration integrity, and confirm detection coverage for suspicious portal interaction, firewall instability, administrative-control anomalies, configuration changes, visibility reduction, firewall-originated outbound communication, and downstream intrusion activity.
Executive Risk Translation
This threat shifts business risk from isolated vulnerability exposure to loss of confidence in the perimeter security-control layer. The primary concern is not only whether affected PAN-OS firewalls were vulnerable, but whether externally reachable portal services allowed attackers to compromise or manipulate the firewall before mitigation. If exploitation occurred, response may expand into firewall isolation, control-plane integrity review, configuration reconstruction, administrator credential rotation, policy and NAT validation, log-forwarding review, downstream intrusion hunting, firewall rebuild or replacement, customer assurance, legal review, and executive incident governance. This creates financial, operational, regulatory, customer-trust, and security-governance exposure beyond the initially exposed portal service.
S3 — Why This Matters Now
· CVE-2026-0300 should be treated as an active edge-firewall exploitation risk, not as a routine patch-management issue.
· The affected service sits on the firewall control plane and can be exposed through internet-facing or untrusted ingress paths.
· The firewall is not only the vulnerable asset; it is also the enforcement point that protects downstream systems, governs traffic paths, and produces security telemetry.
· Successful exploitation can create uncertainty around firewall integrity, configuration trust, logging reliability, administrative-control state, and downstream access enforcement.
· Exposed User-ID Authentication Portal or Captive Portal services require immediate prioritization because they provide the attacker-facing interaction point.
· Patch status alone does not prove that externally reachable firewalls were uncompromised before remediation.
· Historical compromise review is required for affected firewalls that were reachable from untrusted networks before mitigation.
· Detection must focus on suspicious portal interaction followed by firewall instability, administrative anomalies, configuration changes, logging changes, outbound communication, or downstream activity.
· Exposure-only telemetry should support prioritization and hunting, but it must not be treated as confirmed compromise without stronger behavioral, forensic, vendor-supported, or incident-response evidence.
· Organizations without reliable PAN-OS system logs, traffic logs, threat logs, configuration logs, administrative audit logs, commit history, crash records, portal telemetry, network-flow data, and firewall-originated egress visibility face elevated risk of delayed detection and incomplete scoping.
S4 — Key Judgments
· CVE-2026-0300 creates a high-priority firewall control-plane compromise risk when affected User-ID Authentication Portal or Captive Portal services are reachable from untrusted networks.
· The primary business risk is loss of confidence in firewall integrity, security policy enforcement, segmentation control, logging reliability, and perimeter visibility.
· The strongest enterprise risk signal is suspicious portal-directed activity followed by firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, firewall-originated outbound anomalies, or downstream intrusion activity.
· Exposed or affected PA-Series and VM-Series firewalls should drive emergency mitigation and retrospective hunt scoping, but exposure alone should not be treated as confirmed compromise.
· Firewall-native telemetry is central because the exploitation target is the firewall itself rather than a conventional endpoint, web server, or user workstation.
· Administrative audit logs, commit history, configuration logs, and log-forwarding records are required to determine whether attacker activity altered firewall control, visibility, or enforcement.
· Firewall-originated outbound communication is a high-priority signal because a compromised firewall may communicate externally in ways that differ from normal update, licensing, telemetry, logging, support, DNS, NTP, or management behavior.
· Network-adjacent telemetry materially improves confidence when portal-specific logging is incomplete or when firewall-originated communication must be distinguished from through-firewall transit traffic.
· Detection must remain behavior-led because public exploit artifacts, packet structure, source infrastructure, request timing, and visible traffic characteristics can change quickly.
· Executive risk reduction depends on emergency exposure validation, portal restriction or disablement, patch planning, log preservation, configuration integrity review, administrator credential review, and validated detection coverage across firewall-native and network-adjacent telemetry.
S5 — Executive Risk Summary
Business Risk
PAN-OS User-ID Authentication Portal exploitation can create severe operational, security-control, customer-trust, and governance risk when attackers target the firewall control plane. Risk increases when affected firewalls protect production ingress, regulated environments, customer-facing systems, remote access paths, cloud workloads, branch connectivity, high-value segmentation boundaries, or critical business applications.
Technical Cause
The risk is driven by active exploitation of a critical PAN-OS vulnerability affecting exposed User-ID Authentication Portal or Captive Portal services on affected PA-Series and VM-Series firewalls. The enterprise detection model should focus on exposed portal access, suspicious pre-authentication interaction, firewall crash or restart behavior, management-plane instability, administrative-control anomalies, commit and configuration changes, log-forwarding changes, firewall-originated outbound anomalies, and downstream intrusion signals.
Threat Posture
The threat posture is elevated because successful exploitation can convert an exposed firewall service into a control-plane compromise path. The risk is amplified because firewall compromise may affect more than device availability. It may create uncertainty around traffic enforcement, visibility, segmentation, administrative trust, logging completeness, configuration integrity, and downstream intrusion exposure.
Executive Decision Requirement
Executives must require immediate validation of affected firewall inventory, portal enablement, internet or untrusted reachability, mitigation status, patch planning, log retention, administrative-control integrity, configuration-change history, firewall-originated egress baselines, and retrospective compromise review. Response leadership should also confirm that mitigated or patched systems exposed before remediation receive historical review rather than being closed solely on patch completion.
S6 — Executive Cost Summary
[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 creates financial exposure based on the number of exposed firewalls, external reachability duration, firewall role criticality, telemetry completeness, configuration integrity confidence, administrative credential exposure, downstream blast radius, containment burden, patch or replacement complexity, customer assurance requirements, regulatory review, and the degree to which compromised firewall infrastructure may have affected segmentation, inspection, logging, or traffic control.
Low Impact Scenario
Rapid assessment confirms that affected PA-Series or VM-Series firewalls were not externally reachable, portal access was already restricted to trusted networks, mitigations were applied quickly, logs are preserved, no suspicious portal activity is observed, no firewall instability follows portal interaction, no administrative-control anomalies are present, no unexpected commits or configuration exports occurred, no visibility reduction is identified, and no abnormal firewall-originated outbound communication or downstream activity is linked to the exposure. Response still requires emergency inventory validation, portal exposure review, mitigation confirmation, patch planning, telemetry preservation, and limited retrospective hunting because active exploitation conditions existed; estimated impact $500K to $3M.
Moderate Impact Scenario
One or more affected firewalls were reachable from untrusted networks during the active exploitation window, suspicious portal-directed activity is observed, firewall telemetry is incomplete, or investigation identifies limited instability, administrative anomalies, configuration changes, visibility changes, or firewall-originated outbound behavior without confirmed downstream compromise. Response requires incident-response mobilization, firewall-native log review, configuration integrity validation, commit and export review, administrator credential review, egress analysis, maintenance-window reconstruction, segmentation validation, selective downstream hunting, detection tuning, legal assessment, executive coordination, and customer or regulator readiness planning; estimated impact $5M to $30M.
High Impact Scenario
Confirmed or strongly suspected firewall compromise affects externally reachable PA-Series or VM-Series firewalls supporting production, regulated, customer-facing, cloud, branch, or high-value segmentation environments, with evidence of unauthorized configuration activity, administrative-control compromise, log-forwarding reduction, policy or NAT manipulation, firewall-originated outbound communication, degraded inspection, traffic-path changes, credential exposure, downstream reconnaissance, lateral movement, or incomplete historical telemetry. Response may require firewall isolation, rebuild or replacement, emergency architecture changes, credential rotation at scale, configuration reconstruction, policy and route validation, downstream compromise assessment, customer assurance, legal and regulatory review, cyber insurance engagement, business-continuity coordination, and board-level incident governance; estimated impact $40M to $200M or higher.
S6A — Key Cost Drivers
· Number of affected PA-Series and VM-Series firewalls.
· Whether User-ID Authentication Portal or Captive Portal services were reachable from the public internet or other untrusted networks.
· Duration of exposure before access restriction, portal disablement, compensating controls, or patch validation.
· Whether suspicious portal-directed activity occurred before remediation.
· Whether portal activity was followed by firewall crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Whether suspicious activity was followed by administrator login anomalies, administrative account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, policy changes, NAT changes, route changes, or management-setting changes.
· Whether logging, syslog forwarding, traffic logging, threat logging, administrative auditing, monitoring, or visibility controls were reduced, redirected, disabled, or weakened.
· Whether firewall-originated outbound communication occurred to newly observed, rare, unexplained, suspicious, or unapproved destinations.
· Whether the affected firewall protects regulated environments, customer-facing systems, remote access paths, production ingress, cloud workloads, branch connectivity, or critical segmentation boundaries.
· Ability to distinguish firewall-originated communication from ordinary through-firewall transit traffic.
· Availability and retention of PAN-OS system logs, traffic logs, threat logs, configuration logs, administrative audit logs, commit history, crash records, portal telemetry, network flows, DNS logs, TLS metadata, and firewall egress telemetry.
· Need for administrator credential rotation, privileged-access review, configuration reconstruction, policy validation, NAT review, route review, certificate validation, and log-forwarding review.
· Need for downstream intrusion hunting across identity, endpoint, network, cloud, and internal application telemetry.
· Degree to which incomplete telemetry forces broader containment, firewall rebuild, segmentation review, or executive incident governance.
· Need for customer assurance, legal review, regulatory assessment, insurance reporting, or board-level oversight.
Most Likely Scenario Justification
Moderate scenario is most likely when affected firewalls were externally reachable during the active exploitation window and require historical compromise review, but available evidence does not confirm unauthorized code execution, attacker-controlled configuration changes, downstream compromise, or broad security-control failure. The estimate moves toward the lower end when telemetry confirms rapid mitigation, short exposure duration, no suspicious portal interaction, no firewall instability, no administrative anomalies, no configuration changes, no visibility reduction, and no abnormal firewall-originated egress. The estimate moves toward the upper end when firewalls are internet-facing, protect critical segmentation or regulated environments, telemetry is incomplete, suspicious portal activity occurred, instability is observed, administrator or configuration anomalies exist, outbound communication is abnormal, or downstream hunting is required.
S6B — Compliance and Risk Context
Compliance Exposure Indicator
Moderate to High depending on whether suspicious portal activity, unauthorized administrative access, configuration tampering, traffic-path manipulation, logging reduction, credential exposure, downstream intrusion activity, regulated-system exposure, customer-impact uncertainty, or incomplete forensic scoping affected systems subject to regulatory, contractual, customer, insurance, or material business obligations.
Risk Register Entry
Risk Title
PAN-OS Firewall Control-Plane Compromise and Perimeter Integrity Risk from Exposed User-ID Authentication Portal Exploitation
Risk Description
Adversaries may exploit externally reachable User-ID Authentication Portal or Captive Portal services on affected PA-Series or VM-Series firewalls to compromise firewall control-plane integrity, alter administrative state, modify configuration, reduce logging visibility, manipulate policy or NAT behavior, communicate externally from firewall infrastructure, weaken segmentation trust, and enable downstream intrusion activity.
Likelihood
High.
Impact
Severe.
Risk Rating
Critical.
Annualized Risk Exposure
Estimated $10M to $75M or higher based on affected firewall count, external exposure duration, active exploitation conditions, firewall role criticality, segmentation dependency, regulated-system footprint, telemetry completeness, configuration integrity confidence, administrator credential exposure, downstream intrusion evidence, containment complexity, customer assurance requirements, and legal or regulatory obligations.
S7 — Risk Drivers
· Active exploitation of a critical PAN-OS firewall portal vulnerability increases near-term compromise likelihood.
· Exposed User-ID Authentication Portal or Captive Portal services create direct control-plane attack surface.
· The vulnerable asset is also a security enforcement point for segmentation, traffic inspection, policy control, logging, and perimeter visibility.
· Successful exploitation may create uncertainty around firewall trust, policy enforcement, logging integrity, and administrative-control state.
· Externally reachable PA-Series and VM-Series firewalls protecting production, regulated, customer-facing, cloud, branch, or high-value segmentation environments carry elevated business impact.
· Firewall instability after suspicious portal interaction may indicate exploit impact even when payload visibility is unavailable.
· Administrative-control anomalies after portal interaction may indicate unauthorized access, control-plane manipulation, or attacker attempts to preserve access.
· Configuration changes after suspicious portal interaction may indicate traffic-path manipulation, policy weakening, NAT modification, route changes, or inspection bypass.
· Logging and visibility changes after suspicious portal activity may reduce investigation confidence and increase incident scope.
· Firewall-originated outbound communication to unusual destinations may indicate post-exploitation behavior or attacker-controlled communication.
· Patch validation does not prove externally reachable systems were uncompromised before remediation.
· Missing PAN-OS system logs weakens crash, restart, fault, failover, and service-health assessment.
· Missing traffic logs or portal telemetry weakens exploit-attempt and exposure-window review.
· Missing administrative audit logs and commit history weakens analysis of unauthorized control-plane activity.
· Missing configuration logs weakens validation of policy, NAT, route, certificate, authentication-profile, logging, and management-setting integrity.
· Missing firewall-originated egress baselines weakens identification of abnormal outbound communication from firewall infrastructure.
· Missing downstream telemetry weakens assessment of internal reconnaissance, credential-use anomalies, lateral movement, and newly enabled access paths.
· Legitimate maintenance, failover, software updates, configuration changes, certificate renewals, Panorama-driven commits, and approved security testing can resemble suspicious post-interaction behavior without strong operational context.
· Over-reliance on exploit strings, public proof-of-concept artifacts, scanner infrastructure, source reputation, or affected-version inventory can miss evolved exploitation and post-compromise behavior.
S8 — Bottom Line for Executives
[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 should be treated as a high-priority perimeter integrity and security-control trust risk because the exposed service resides on the firewall itself. The key executive concern is not only whether affected firewalls were patched or mitigated, but whether exposed portal services allowed attackers to compromise, destabilize, manipulate, or communicate from firewall infrastructure before remediation. Risk reduction depends on exposed asset scoping, portal restriction or disablement, patch planning, preserved firewall telemetry, historical compromise review, configuration integrity validation, administrator credential review, outbound communication analysis, downstream hunting, and behavior-based detection coverage. Organizations should prioritize this report as a firewall control-plane compromise issue because successful exploitation can create operational disruption, visibility loss, segmentation uncertainty, customer trust exposure, regulatory uncertainty, and board-level incident governance requirements.
S9 — Board-Level Takeaway
CVE-2026-0300 turns an exposed PAN-OS firewall authentication portal into a potential enterprise perimeter-control compromise path. The board-level concern is that attackers may target the same infrastructure used to enforce segmentation, inspect traffic, log security events, manage policy, and protect downstream systems. Leadership should require evidence that affected firewalls have been identified, unsafe portal exposure has been eliminated or restricted, patch plans are tracked, historical compromise review has been performed, firewall integrity has been validated, administrator credentials have been reviewed, and response teams can detect suspicious portal interaction followed by instability, administrative anomalies, configuration changes, visibility reduction, outbound communication, or downstream activity. This report supports governance decisions around perimeter security, control-plane integrity, exposure management, telemetry readiness, incident-response escalation, regulatory posture, and executive oversight of firewall compromise risk.
Figure 2
S10 — Threat Overview
[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 involves active exploitation of exposed PAN-OS firewall portal services that can place the firewall control plane at risk. The affected exposure path is the User-ID Authentication Portal, also known as Captive Portal, on PA-Series and VM-Series firewalls where portal access is enabled and reachable from untrusted networks.
This activity should be assessed as an edge-infrastructure exploitation event rather than a conventional endpoint, user workstation, or generic web-application compromise. The firewall is the target, the control point, and the potential post-compromise operating position. This creates elevated business and operational risk because the same device may enforce segmentation, inspect traffic, control policy, forward logs, authenticate administrative activity, and protect downstream assets.
The primary threat concern is that successful exploitation may allow adversaries to move from exposed portal interaction into firewall control-plane compromise, device instability, configuration manipulation, visibility reduction, firewall-originated communication, or downstream access enablement. Confirmed downstream intrusion activity should not be assumed without evidence, but any suspicious portal activity paired with firewall instability, administrative anomalies, configuration changes, logging changes, or outbound anomalies should be treated as a high-priority perimeter-integrity incident.
S11 — Threat Classification and Type
Threat Type
Active edge-infrastructure exploitation.
Threat Sub-Type
Firewall control-plane compromise risk through exposed authentication portal services.
Operational Classification
Externally reachable security-appliance exploitation with potential post-exploitation control-plane impact.
Primary Function
Create unauthorized control-plane access or influence over affected firewall infrastructure, enabling potential device instability, configuration manipulation, visibility reduction, firewall-originated communication, or downstream access enablement.
S12 — Campaign or Activity Overview
The observed activity is best characterized as active exploitation of exposed PAN-OS firewall portal services rather than a fully attributed campaign. Public reporting and vendor advisory language support exploitation against exposed User-ID Authentication Portals, but they do not establish a single named intrusion set, malware family, campaign identity, or complete post-exploitation playbook.
The exploitation pathway centers on internet-facing or otherwise untrusted access to affected PA-Series and VM-Series firewalls configured with User-ID Authentication Portal or Captive Portal functionality. Attackers are likely to prioritize reachable firewall assets because successful exploitation can affect the control plane of a security device positioned at the enterprise edge.
Operationally, the activity should be handled as a perimeter-control trust event. The required investigation question is not only whether an affected PAN-OS version exists, but whether an exposed portal received suspicious activity before mitigation and whether that activity was followed by firewall instability, administrative-control anomalies, configuration changes, visibility reduction, firewall-originated outbound communication, or downstream intrusion signals.
No specific malware family or intrusion set is confirmed for this report. The responsible actor should be treated as unidentified unless future vendor, government, or incident-response reporting confirms attribution.
S13 — Targets and Exposure Surface
The primary targets are PA-Series and VM-Series firewalls running affected PAN-OS versions where User-ID Authentication Portal or Captive Portal services are enabled and reachable from untrusted networks. Exposure is highest when the portal is reachable from the public internet, external ingress paths, permissive security policies, cloud load balancers, externally routable interfaces, or unmanaged scanning infrastructure.
The exposure surface includes firewall-hosted authentication portal services, interface management profiles that expose response pages or portal functionality, public or untrusted ingress paths, firewall management or control-plane interfaces, and network paths that allow unauthenticated traffic to reach the affected portal service.
Risk increases where affected firewalls protect production ingress, remote access paths, regulated environments, customer-facing applications, branch connectivity, cloud workloads, high-value segmentation boundaries, or security-monitoring choke points. In these environments, firewall compromise may affect more than a single device because the firewall can influence traffic enforcement, inspection, routing, NAT behavior, log forwarding, administrative access, and downstream security visibility.
Exposure-only findings should drive urgent mitigation and retrospective hunting. They should not be classified as confirmed compromise unless supported by suspicious portal activity, device instability, unauthorized administrative behavior, configuration tampering, visibility reduction, firewall-originated outbound anomalies, downstream activity, forensic evidence, or validated incident-response findings.
S14 — Sectors / Countries Affected
Sectors Affected
· Financial services and banking.
· Healthcare and life sciences.
· Technology, cloud-hosted enterprises, and software development.
· Manufacturing and industrial operations.
· Energy, utilities, and critical infrastructure.
· Retail, ecommerce, and payment-processing environments.
· Education and research institutions.
· Government and public-sector organizations.
· Telecommunications and managed service providers.
· Enterprise IT operations, security operations, and organizations with distributed firewall estates.
· Organizations with externally reachable PA-Series or VM-Series firewalls protecting production ingress, customer-facing applications, remote access paths, regulated data environments, cloud workloads, branch connectivity, or high-value segmentation boundaries.
Countries Affected
· Global.
· Exposure is not limited to a single country or region because PA-Series and VM-Series firewalls are broadly deployed across enterprise, government, cloud, regulated, and customer-facing environments.
· Countries with large enterprise firewall deployments, regulated industries, government operations, cloud adoption, branch-network scale, or high-value technology environments may face elevated operational exposure.
· Country-specific impact should be assessed by exposed firewall presence, User-ID Authentication Portal or Captive Portal reachability, PAN-OS version exposure, telemetry quality, mitigation status, and incident-response readiness rather than geography alone.
S15 — Adversary Capability Profiling
Capability Level
High.
The activity requires the ability to identify exposed PAN-OS portal services, exploit a critical firewall control-plane vulnerability, and potentially operate against security infrastructure rather than ordinary user endpoints. Capability assessment should remain behavior-based because no single actor, toolkit, or intrusion set is confirmed.
Technical Sophistication
High.
Technical sophistication is elevated because exploitation targets a firewall-hosted authentication portal and may lead to control-plane impact on a security appliance. Post-exploitation activity, if present, may require understanding of firewall configuration, policy behavior, log forwarding, routing, NAT, administrative workflows, and network segmentation.
Infrastructure Maturity
Moderate to High.
Attackers may use cloud-hosted infrastructure, scanning infrastructure, anonymized access paths, compromised intermediaries, VPN services, residential proxy paths, or rotating source infrastructure. Infrastructure maturity should be assessed from local telemetry because public reporting does not confirm a stable adversary infrastructure model.
Operational Scale
Limited to opportunistic-to-targeted.
The current activity should be treated as active but not fully characterized as a mass compromise campaign. Exposed systems may be discovered opportunistically through internet scanning, while higher-value firewalls protecting regulated, production, cloud, or customer-facing environments may receive more targeted follow-on attention.
Escalation Likelihood
High for externally reachable and unmitigated affected firewalls.
Escalation likelihood is highest when suspicious portal interaction is followed by firewall instability, administrative-control anomalies, configuration changes, visibility reduction, outbound communication, or downstream intrusion activity. Escalation likelihood is lower when portal access was restricted to trusted networks, telemetry confirms no suspicious interaction, and mitigation or patch actions were completed before exposure.
S16 — Targeting Probability Assessment
Overall Targeting Probability
High for externally reachable affected User-ID Authentication Portal or Captive Portal deployments.
Moderate for affected firewalls where portal exposure is uncertain or where the portal was reachable only through limited untrusted paths.
Low to Moderate for affected firewalls where portal access was restricted to trusted internal networks before the active exploitation window and telemetry confirms no suspicious interaction.
Targeting Drivers
· Internet or untrusted reachability of User-ID Authentication Portal or Captive Portal services.
· Affected PA-Series or VM-Series firewall deployment.
· Firewall role in production ingress, segmentation, cloud transit, branch connectivity, remote access, or customer-facing service protection.
· Ability to reach portal services without trusted network placement.
· Limited portal logging, short retention, or weak traffic visibility.
· Lack of confirmed mitigation, portal restriction, portal disablement, or patch status.
· High-value downstream environment protected by the firewall.
· Weak administrative-source restrictions or inconsistent firewall administrative audit logging.
· Absence of reliable firewall-originated outbound communication baselines.
· Presence of public exposure through cloud ingress, load balancers, permissive policies, or unmanaged edge configurations.
Most Likely Targets
· Internet-facing PA-Series and VM-Series firewalls with User-ID Authentication Portal or Captive Portal enabled.
· Firewalls protecting production ingress, customer-facing applications, regulated systems, or high-value segmentation boundaries.
· VM-Series deployments exposed through cloud security groups, public IPs, load balancers, permissive route paths, or externally reachable ingress controls.
· Firewalls with incomplete portal telemetry, weak log retention, limited administrative audit visibility, or poor configuration-change monitoring.
· Organizations where firewall compromise would enable traffic-path manipulation, reduced visibility, downstream access, or incident-response delay.
S17 — MITRE ATT&CK Chain Flow Mapping
Stage 1 — Exposure Identification and Target Selection
Adversaries identify externally reachable PAN-OS User-ID Authentication Portal or Captive Portal services on PA-Series or VM-Series firewalls. This stage may involve internet-scale discovery, targeted probing, or validation of untrusted access paths to firewall-hosted portal services.
MITRE ATT&CK Mapping
T1595 — Active Scanning
Stage 2 — Initial Access Through Exposed Firewall Portal
Adversaries interact with exposed PAN-OS portal services and attempt to exploit CVE-2026-0300 against affected firewall infrastructure. The core access path is exploitation of an externally reachable service hosted by the firewall.
MITRE ATT&CK Mapping
T1190 — Exploit Public-Facing Application
Stage 3 — Conditional Administrative or Configuration Manipulation
If exploitation produces attacker control or unauthorized access, adversaries may attempt to modify administrative state, authentication profiles, certificates, security policy, NAT rules, routing, logging, management settings, or commit activity. This stage should remain evidence-driven and should not be assumed without logs or validated incident-response findings.
MITRE ATT&CK Mapping
T1098 — Account Manipulation, conditional where administrator account or privilege changes are observed
T1562 — Impair Defenses, conditional where logging, forwarding, monitoring, inspection, or visibility changes are observed
Stage 4 — Conditional Downstream Discovery
If firewall compromise is used to alter traffic paths, enable access, or support follow-on activity, downstream signals may include internal reconnaissance, newly observed access paths, or service-discovery activity. This stage is conditional and should require defensible linkage to suspected or confirmed firewall compromise.
MITRE ATT&CK Mapping
T1046 — Network Service Discovery, conditional where downstream reconnaissance or service-discovery activity is observed
S18 — Attack Path Narrative (Signal-Aligned Execution Flow)
Initial Exposure
The attack path begins when a PA-Series or VM-Series firewall exposes User-ID Authentication Portal or Captive Portal services to untrusted networks. This exposure may occur through internet-facing interfaces, external ingress paths, permissive security policies, externally reachable response pages, cloud load balancers, public IP association, or network paths that allow unauthenticated traffic to reach the portal service.
At this stage, the primary signal is exposure rather than confirmed compromise. The required defensive action is to validate whether the portal is enabled, reachable from untrusted sources, and associated with an affected PAN-OS deployment.
Portal Interaction
Adversaries interact with the exposed portal service from internet-originating or otherwise untrusted infrastructure. This activity may appear as targeted probing, low-volume interaction, repeated portal access attempts, abnormal session behavior, or traffic inconsistent with expected authentication workflows.
The primary signal is suspicious portal-directed traffic. This should support exploit-attempt classification when abnormal or high-risk, but it should not be treated as confirmed compromise without supporting post-interaction evidence.
Potential Exploitation
If the exposed portal is vulnerable, attacker interaction may trigger exploit behavior against the firewall control plane. Publicly confirmed details do not support a stable payload signature, durable request pattern, malware family, or complete post-exploitation artifact model for this report.
The primary signals at this stage are suspicious portal activity and temporally related firewall instability, including crash, restart, fault, failover, portal interruption, service degradation, management-plane instability, or degraded inspection behavior. Instability alone is not sufficient for confirmed compromise, but instability following suspicious portal activity should be treated as probable exploitation until reviewed.
Control-Plane Follow-On Activity
If exploitation produces attacker control or unauthorized access, follow-on activity may affect firewall administration, configuration state, trust settings, or traffic-control behavior. Observable activity may include administrator login anomalies, administrative account changes, privilege changes, unexpected commits, configuration exports, authentication-profile changes, certificate changes, policy changes, NAT changes, route changes, logging changes, or management-setting changes.
The primary signal is post-portal administrative or configuration activity that cannot be explained by approved maintenance, expected administrator sources, normal commit behavior, Panorama-driven workflow, scheduled certificate renewal, or documented change activity.
Visibility and Egress Anomalies
Adversaries may attempt to reduce visibility or establish communication from firewall infrastructure. Visibility-impacting behavior may include changes to logging, syslog forwarding, threat logging, traffic logging, administrative auditing, monitoring profiles, or other log-forwarding paths. Firewall-originated outbound communication may include new, rare, unexplained, or unapproved destinations inconsistent with normal update, licensing, telemetry, logging, support, DNS, NTP, or management behavior.
The primary signal is a same-firewall relationship between suspicious portal activity and either visibility reduction or abnormal firewall-originated egress. This requires careful distinction between firewall-originated traffic and ordinary through-firewall transit traffic.
Conditional Downstream Activity
If firewall compromise is used to alter traffic paths, weaken policy enforcement, create access paths, or support follow-on operations, downstream activity may appear as internal reconnaissance, newly observed access paths, unusual segment access, credential-use anomalies, or service-discovery activity. This stage is conditional and should not be assumed without defensible linkage to suspected or confirmed firewall compromise.
The primary signal is downstream activity that occurs after suspicious firewall interaction and aligns with configuration changes, routing changes, NAT changes, policy modification, or firewall-mediated access behavior.
Compromise Classification
Exposure should be classified as exposed.
Suspicious portal traffic without meaningful post-interaction behavior should be classified as targeted or attempted exploitation.
Suspicious portal traffic followed by firewall instability, administrative-control anomalies, configuration changes, visibility reduction, firewall-originated outbound anomalies, or downstream activity should be classified as probable exploitation.
Confirmed compromise should require forensic evidence, vendor-supported confirmation, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, malicious persistence, or validated incident-response findings.
S19 — Attack Chain Risk Amplification Summary
Control-Plane Targeting
Risk is amplified because the exploitation target is a firewall control plane rather than a conventional endpoint or application server. A compromised firewall can affect policy enforcement, traffic inspection, routing, NAT behavior, logging, administrative access, segmentation trust, and downstream visibility.
Security-Control Trust Loss
Risk increases when defenders cannot prove that the firewall remained trustworthy during the exposure window. Even limited uncertainty can force broader review of configuration integrity, commit history, administrative access, log forwarding, policy enforcement, and outbound communication.
Detection Confidence Dependency
Risk increases when PAN-OS system logs, traffic logs, threat logs, configuration logs, administrative audit logs, commit history, portal telemetry, crash records, network flows, DNS records, TLS metadata, and firewall-originated egress baselines are missing or inconsistently retained.
Post-Interaction Ambiguity
Risk increases when legitimate maintenance, failover, upgrades, certificate renewal, Panorama-driven commits, policy changes, or approved security testing overlap with suspicious portal activity. Weak change records can make it difficult to separate authorized operations from attacker-driven control-plane manipulation.
Configuration Integrity Exposure
Risk increases when suspicious portal interaction is followed by changes to administrator accounts, authentication profiles, certificates, security policy, NAT, routing, logging, log forwarding, or management settings. These changes can affect access, visibility, enforcement, and incident scoping.
Visibility Reduction
Risk increases when logging, forwarding, monitoring, auditing, or traffic visibility is changed near suspicious portal activity. Reduced visibility can delay detection, weaken forensic confidence, and expand the investigation window.
Firewall-Originated Communication
Risk increases when the firewall itself communicates with new, rare, unexplained, or unapproved external destinations. This behavior can indicate post-exploitation activity, attacker-controlled communication, payload staging, or operational use of the firewall as an egress point.
Downstream Blast Radius
Risk increases when suspected firewall compromise aligns with internal reconnaissance, newly observed access paths, credential-use anomalies, lateral movement indicators, or firewall-mediated traffic changes. Downstream activity can convert a perimeter incident into an enterprise intrusion investigation.
Response Complexity
Risk increases when affected firewalls protect production ingress, regulated systems, customer-facing applications, cloud workloads, branch connectivity, remote access paths, or high-value segmentation boundaries. Containment may require emergency architecture decisions, firewall isolation, failover planning, rebuild activity, credential rotation, and executive governance.
Figure 3
S20 — Tactics, Techniques, and Procedures
Exposure Targeting and Portal Discovery
· Attackers target internet-facing or untrusted-accessible PA-Series and VM-Series firewall services where User-ID Authentication Portal or Captive Portal functionality is enabled.
· Attackers may use scanning, probing, low-volume validation, repeated portal interaction, abnormal session behavior, or access from unfamiliar source infrastructure to identify exposed firewall-hosted portal services.
· Scan-only or exposure-only traffic should remain classified as exposure or exploit-attempt activity unless correlated with firewall instability, administrative-control anomalies, configuration changes, visibility reduction, firewall-originated outbound communication, or downstream activity.
Exploitation of Firewall-Hosted Portal Services
· Attackers attempt to exploit exposed User-ID Authentication Portal or Captive Portal services on affected PAN-OS firewalls.
· Suspicious behavior may include portal-directed traffic from untrusted sources, interaction patterns inconsistent with normal authentication workflows, repeated attempts against exposed portal services, or activity occurring outside expected user or administrative access paths.
· Exploit-attempt activity becomes higher confidence when suspicious portal interaction is followed by firewall crash, restart, fault, failover, portal interruption, service degradation, management-plane instability, or degraded inspection behavior.
Control-Plane Administrative Abuse
· If exploitation produces unauthorized control-plane access or influence, attackers may attempt to affect administrator accounts, authentication profiles, certificates, security policy, NAT rules, routing, logging, management settings, or commit activity.
· Observable procedures may include unexpected administrator login activity, account modification, privilege change, unexplained commit activity, configuration export, authentication-profile change, certificate change, policy modification, NAT modification, route change, or management-setting change.
· Legitimate firewall operations can resemble attacker activity, so validation must account for approved maintenance, failover activity, Panorama-driven commits, certificate renewal, planned policy deployment, backup activity, and documented change windows.
Visibility Reduction and Logging Manipulation
· Attackers may attempt to reduce visibility by altering logging, syslog forwarding, threat logging, traffic logging, administrative auditing, monitoring profiles, or log-forwarding destinations.
· Visibility-impacting changes near suspicious portal activity should increase severity because they can reduce detection confidence, weaken forensic reconstruction, and expand the investigation window.
· Logging or forwarding changes should be evaluated against approved change records, expected log destinations, maintenance windows, and normal monitoring operations.
Firewall-Originated Outbound Communication
· Attackers may cause or use firewall-originated communication to reach external infrastructure after suspected compromise.
· Observable procedures may include outbound sessions from firewall management or control-plane interfaces to newly observed, rare, unexplained, suspicious, or unapproved destinations.
· Outbound communication should be evaluated against expected update, licensing, telemetry, logging, support, DNS, NTP, and management destinations.
Traffic-Control and Access-Path Manipulation
· Attackers may attempt to alter firewall behavior by modifying policy, NAT, routing, objects, authentication controls, or management settings.
· Procedures may include creating new access paths, weakening inspection, changing route behavior, modifying NAT behavior, changing policy order, altering object definitions, or enabling access inconsistent with prior segmentation.
· Traffic-control changes after suspicious portal activity should increase severity when they affect production ingress, regulated systems, customer-facing applications, cloud workloads, remote access paths, or high-value segmentation boundaries.
Conditional Downstream Activity
· If firewall compromise enables follow-on activity, attackers may perform internal reconnaissance, service discovery, credential-use activity, or access-path validation through newly enabled, altered, or firewall-mediated paths.
· Observable procedures may include new internal destination access, unusual segment access, destination fan-out, port fan-out, management-protocol access, or traffic behavior inconsistent with prior firewall enforcement.
· Downstream activity should be treated as conditional unless it is temporally and logically linked to suspicious portal activity, firewall instability, configuration changes, or confirmed firewall compromise.
Evasion and Blending Behavior
· Attackers may blend with legitimate firewall administration by using low-volume portal interaction, delayed follow-on activity, cloud-hosted or anonymized infrastructure, ordinary administrative workflows, or changes that resemble maintenance.
· Attackers may avoid obvious malware deployment and instead rely on subtle configuration changes, logging changes, administrative-control manipulation, firewall-originated communication, or access-path modification.
· Detection should remain behavior-led because source infrastructure, request timing, traffic shape, visible portal interaction, payload content, and follow-on behavior can change quickly.
S20A — Adversary Tradecraft Summary
The adversary tradecraft in this report is best understood as exploitation of exposed edge-security infrastructure with potential control-plane consequences. The governing behavior is not endpoint malware execution, phishing delivery, or commodity webshell deployment. The governing behavior is suspicious interaction with a firewall-hosted portal service that may be followed by firewall instability, administrative-control anomalies, configuration manipulation, visibility reduction, firewall-originated outbound communication, or downstream activity.
Attackers can vary source infrastructure, scanning patterns, request timing, visible request characteristics, and follow-on behavior. The tradecraft should therefore be assessed through the relationship between suspicious portal interaction and subsequent firewall behavior, including instability, administrative-control anomalies, configuration manipulation, visibility reduction, firewall-originated outbound communication, or downstream activity.
Operationally, exposed firewalls require urgent mitigation and hunting. Suspicious portal traffic may indicate attempted exploitation. Suspicious portal traffic followed by instability or control-plane anomalies supports probable exploitation. Confirmed compromise requires stronger forensic, vendor-supported, configuration, unauthorized-code-execution, or incident-response evidence.
The highest-confidence tradecraft signals are suspicious portal-directed activity followed by one or more of the following: firewall crash or restart behavior, management-plane instability, unexpected administrative activity, unauthorized or unexplained commit activity, configuration export, authentication-profile change, certificate change, policy or NAT modification, routing change, logging or forwarding change, abnormal firewall-originated outbound communication, or downstream activity aligned to a firewall-mediated path.
Tradecraft should be assessed conservatively. No actor identity, malware family, persistence mechanism, payload signature, or complete post-exploitation playbook should be asserted unless validated by vendor guidance, government reporting, forensic review, or incident-response evidence.
S21 — Detection Strategy Overview
Detection Philosophy
Detection coverage for [EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 must focus on active edge-device exploitation, exposed-service abuse, firewall control-plane integrity, and post-exploitation behavior affecting security infrastructure.
The governing detection challenge is not conventional endpoint malware execution. The firewall is the exploitation target, the security control at risk, and a potential post-compromise operating point for attacker activity.
Detection strategy must prioritize firewall-native telemetry, management-plane behavior, configuration integrity, portal-directed traffic, device-health anomalies, and firewall-originated outbound communication.
The detection model must clearly separate exposure, exploit attempt, probable exploitation, and confirmed compromise. Exposure alone creates urgent remediation pressure, but it must not be treated as confirmed compromise without supporting behavioral, forensic, or vendor-confirmed evidence.
High-confidence detection should come from behavioral convergence: suspicious portal-directed activity followed by device instability, administrative anomalies, configuration changes, logging changes, outbound communication, or downstream intrusion activity.
Primary Detection Anchors
Exposure Anchor
Identify PA-Series and VM-Series firewalls where the User-ID Authentication Portal or Captive Portal is enabled and reachable from untrusted networks, public internet sources, permissive security policies, external load balancers, cloud ingress paths, or unmanaged scanning infrastructure.
Exploit-Attempt Anchor
Identify abnormal or high-risk pre-authentication interaction with User-ID Authentication Portal services, especially from internet-originating infrastructure, newly observed sources, scanning infrastructure, anonymized access paths, or networks with no expected relationship to the protected environment.
Device-Instability Anchor
Identify firewall service crashes, unexpected restarts, management-plane instability, dataplane degradation, portal interruption, repeated fault events, failover activity, or degraded inspection behavior occurring near suspicious portal-directed traffic.
Administrative-Control Anchor
Identify suspicious administrator sessions, unexpected account changes, privilege changes, unauthorized commits, authentication-profile changes, certificate changes, configuration exports, policy modifications, NAT changes, logging changes, or management-setting changes following suspicious portal activity.
Outbound-Communication Anchor
Identify unusual outbound communication from firewall management or control-plane interfaces, including newly observed destinations, abnormal DNS activity, rare external infrastructure, unexpected TLS sessions, unusual egress paths, beacon-like timing, or communication inconsistent with normal update, licensing, logging, telemetry, or management behavior.
Downstream-Intrusion Anchor
Identify internal reconnaissance, lateral movement, credential-use anomalies, authentication anomalies, or unusual access paths that occur after suspicious firewall interaction. This anchor is conditional and requires reliable downstream telemetry with defensible temporal linkage to suspected firewall compromise.
Detection Prioritization Model
Detection priority must be based on behavioral convergence rather than isolated vulnerability presence.
Priority 1
Suspicious internet-originating portal activity followed by firewall instability, suspicious administrative behavior, configuration change, logging modification, unexpected commit activity, unusual outbound communication, or downstream intrusion activity.
Priority 2
Suspicious internet-originating portal activity involving abnormal, targeted, or high-risk pre-authentication interaction with the User-ID Authentication Portal.
Priority 3
Firewall crash, restart, failover, portal interruption, or service-instability events on affected PAN-OS firewalls where User-ID Authentication Portal exposure is confirmed or suspected.
Priority 4
Suspicious administrative, configuration, authentication-profile, certificate, policy, NAT, logging, or commit activity on affected PAN-OS firewalls without confirmed exploit-attempt telemetry.
Priority 5
Exposure-only findings where User-ID Authentication Portal is reachable from untrusted networks but no suspicious portal activity, instability, administrative anomaly, outbound anomaly, or downstream activity has been observed.
Exposure-only findings should trigger access restriction, mitigation validation, and retrospective hunting. They should not be classified as probable exploitation unless paired with suspicious traffic, device instability, administrative anomalies, outbound anomalies, downstream activity, or validated forensic evidence.
Correlation Strategy (Strict Enforcement)
Detection engineering must avoid single-signal confirmation of compromise.
High-Confidence Correlation Requirements
A high-confidence exploitation alert should require at least two materially related signal groups from the following categories:
· Untrusted access to User-ID Authentication Portal services.
· Abnormal, targeted, or high-risk portal-directed traffic.
· Firewall crash, restart, fault, failover, portal interruption, or service instability.
· Suspicious administrative login, account, commit, configuration, certificate, or authentication-profile activity.
· Unexpected logging, policy, NAT, routing, or management-setting modification.
· Unusual outbound communication from the firewall.
· Internal reconnaissance, lateral movement, authentication anomalies, or downstream access activity temporally associated with suspicious firewall interaction.
Exploit-Attempt Alerting
Exploit-attempt alerts may be generated from suspicious portal-directed traffic alone when the activity is sufficiently abnormal, targeted, or high-risk. These alerts should remain classified as attempted exploitation unless paired with instability, administrative anomalies, outbound communication, downstream activity, or forensic confirmation.
Probable-Exploitation Alerting
Probable-exploitation alerts should require suspicious portal activity plus at least one meaningful post-interaction behavior, such as device instability, administrator-session anomaly, configuration change, logging modification, commit anomaly, firewall-originated outbound communication, or downstream intrusion activity.
Confirmed-Compromise Alerting
Confirmed-compromise alerting should require forensic evidence, vendor-supported confirmation, unauthorized configuration activity, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
Post-Exploitation Alerting
Post-exploitation alerting should prioritize behavior after suspicious portal access, especially administrative session anomalies, configuration modification, policy changes, authentication-profile changes, certificate changes, logging changes, outbound communication, internal reconnaissance, or altered traffic-control behavior.
Correlation Window
Correlation windows should support both immediate exploitation and delayed follow-on operator activity. A firewall may be exploited first and later used for persistence, traffic manipulation, credential exposure, reconnaissance, configuration tampering, policy modification, or intrusion staging.
Telemetry Prioritization
The primary telemetry model must be firewall-native first, network-adjacent second, and endpoint-supported only where downstream activity requires host-level confirmation.
Primary Telemetry Sources
· PAN-OS system logs.
· PAN-OS traffic logs.
· PAN-OS threat logs.
· PAN-OS configuration logs.
· PAN-OS administrative audit logs.
· Administrator login history.
· Commit history.
· Configuration export records.
· User-ID Authentication Portal or Captive Portal access telemetry where available.
· Firewall crash, restart, fault, failover, and service-health records.
· Network IDS or NDR telemetry observing traffic to and from the firewall.
· NetFlow, VPC Flow Logs, NSG Flow Logs, firewall-adjacent packet metadata, or equivalent network records.
· SIEM-ingested firewall syslog.
· Cloud control-plane telemetry for VM-Series deployments.
· External attack-surface management or internet exposure data.
Secondary Telemetry Sources
· Endpoint telemetry from administrator workstations.
· Identity-provider logs tied to firewall administration.
· Privileged-access-management logs.
· Configuration-management system records.
· DNS, proxy, and egress telemetry associated with firewall-originated communication.
· Internal host telemetry for systems contacted after suspected firewall compromise.
Conditional Cloud Telemetry
Cloud-native telemetry applies where VM-Series firewalls operate in AWS, Azure, or GCP. Relevant telemetry may include security group changes, route table changes, public IP association, load balancer access logs, cloud flow logs, instance metadata access patterns, IAM activity, control-plane exposure changes, and firewall instance network-path modifications.
Detection Design Constraints
Detection content must distinguish between exposure, exploit attempt, probable exploitation, and confirmed compromise.
Exposure
The vulnerable portal is reachable from untrusted networks, but suspicious activity has not been confirmed.
Exploit Attempt
Suspicious or abnormal traffic has interacted with the portal, but post-exploitation behavior has not been observed.
Probable Exploitation
Suspicious portal traffic is followed by firewall instability, abnormal administrative behavior, configuration change, logging modification, unusual outbound communication, or downstream intrusion activity.
Confirmed Compromise
Forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, malicious persistence, or validated incident-response findings confirm compromise.
Detection rules must not classify every portal request as exploitation.
Detection rules must not rely on unvalidated public exploit payload strings as mandatory conditions.
Detection rules must not require full packet capture as a baseline dependency.
Detection rules must not require endpoint-agent visibility on the firewall.
Detection rules must not treat source IP reputation alone as sufficient for compromise classification.
Detection rules must account for attacker variation in source infrastructure, request timing, request volume, session behavior, traffic shape, and delayed follow-on activity.
Detection logic should prioritize durable behavioral relationships over brittle indicators because attacker infrastructure and visible request characteristics can change quickly.
Baseline and Deployment Requirements
Organizations must maintain a current baseline of firewall exposure, portal enablement, administrative behavior, configuration-change patterns, device-health norms, and firewall-originated communication before deploying high-confidence detections.
Required Baseline Elements
· Deployed PA-Series and VM-Series firewall inventory.
· PAN-OS version inventory.
· User-ID Authentication Portal or Captive Portal enablement status.
· Interfaces, zones, source ranges, and ingress paths that can reach the portal.
· Expected administrative users and source IP ranges.
· Normal administrator login patterns.
· Normal commit frequency and configuration-change patterns.
· Normal authentication-profile, certificate, NAT, policy, and logging changes.
· Normal firewall outbound communication destinations.
· Normal update, licensing, logging, telemetry, and management traffic.
· Normal crash, restart, failover, and service-health behavior.
· VM-Series exposure through cloud security groups, load balancers, public IPs, route tables, or permissive network controls.
Detection quality depends on accurate asset inventory, affected-version tracking, portal exposure visibility, management-plane logging, configuration-change monitoring, firewall-originated egress baselining, and reliable retention of firewall system and traffic logs.
Baselines must be updated after mitigation, patching, portal restriction, portal disablement, policy changes, segmentation changes, management-plane changes, cloud ingress changes, or firewall replacement.
Variant Resilience Requirements
Detection content must remain effective if attackers alter visible indicators while preserving the underlying exploitation behavior.
Required Variant Resistance
· Detect low-volume probing as well as high-volume scanning.
· Detect suspicious portal access without depending on a single source IP, country, hosting provider, or autonomous system.
· Detect instability even when exploit payload details are not visible.
· Detect delayed post-exploitation behavior after initial portal interaction.
· Detect subtle configuration changes, not only large policy modifications.
· Detect logging, authentication-profile, certificate, policy, NAT, and management-setting changes that could support stealth, persistence, or traffic manipulation.
· Detect firewall-originated outbound communication to newly observed or abnormal destinations.
· Detect activity routed through VPN, residential proxy, cloud-hosted, compromised, or rotating infrastructure.
· Detect administrative and configuration anomalies even when the attacker attempts to blend into normal management workflows.
Durable Behavioral Focus
· Untrusted access to sensitive firewall portal services.
· Unexpected portal exposure.
· Suspicious pre-authentication interaction with firewall portal services.
· Device instability after suspicious inbound traffic.
· Administrative or configuration changes after suspicious portal interaction.
· Logging or policy changes that reduce visibility or alter traffic enforcement.
· Unusual outbound communication from firewall infrastructure.
· Internal activity temporally associated with suspected firewall compromise.
Operational Detection Model
SOC triage should classify alerts according to operational state, evidence strength, and required response action.
Exposed
The portal is reachable from untrusted networks, but suspicious activity has not been confirmed. Response should prioritize exposure validation, mitigation, access restriction, and retrospective hunting.
Targeted
Suspicious traffic has interacted with the portal, but post-exploitation behavior has not been observed. Response should prioritize traffic review, affected-version validation, firewall-health review, management-plane review, and enhanced monitoring.
Probable Exploitation
Suspicious portal traffic is followed by firewall instability, suspicious administrative behavior, configuration change, logging modification, unusual outbound communication, or downstream intrusion activity. Response should prioritize containment, configuration integrity review, forensic collection, credential review, and escalation to incident response.
Confirmed Compromise
Unauthorized code execution, unauthorized configuration activity, attacker-controlled behavior, malicious persistence, or vendor-supported forensic evidence confirms compromise. Response should prioritize full incident handling, containment, firewall rebuild or recovery, credential rotation, configuration integrity validation, downstream intrusion hunting, and executive notification.
Initial SOC Response Priorities
· Validate whether User-ID Authentication Portal is enabled and externally reachable.
· Confirm affected product line and PAN-OS version.
· Review recent portal access from untrusted sources.
· Review system crash, restart, failover, and fault logs.
· Review administrative login activity.
· Review commit history and configuration exports.
· Review authentication-profile, certificate, NAT, security policy, routing, and logging changes.
· Review outbound communication from firewall management and control-plane interfaces.
· Identify internal hosts contacted after suspicious firewall interaction.
· Escalate when suspicious portal activity aligns with instability, administrative anomalies, configuration changes, logging changes, outbound communication, or downstream intrusion activity.
The detection program should treat suspected exploitation as a perimeter-integrity incident, not only a vulnerability-management event.
Explicit Non-Deployment Guardrails
Do not deploy rules that alert solely because a firewall is running PAN-OS.
Do not deploy compromise-level alerts based only on the existence of User-ID Authentication Portal.
Do not deploy rules that classify all external portal traffic as exploitation without anomaly, exposure, source-risk, instability, administrative, outbound, or post-interaction context.
Do not deploy rules that require unavailable payload signatures, full packet capture, or unvalidated exploit strings as mandatory conditions.
Do not deploy generic any-external-access-to-firewall rules without environmental allowlisting, zone context, service context, and portal-specific scoping.
Do not assume that Panorama, Prisma Access, or Cloud NGFW are affected by CVE-2026-0300 unless vendor guidance changes the affected-product scope.
Do not suppress firewall instability as routine maintenance when it occurs near suspicious portal access from untrusted sources.
Do not treat patch status alone as detection coverage. Patching reduces exposure, but detection must still account for pre-patch exploitation, attempted exploitation, and possible post-compromise persistence.
Do not treat this as a Windows endpoint, Linux endpoint, or generic web-application exploitation problem. The governing detection challenge is edge firewall control-plane compromise.
S22 — Primary Detection Signals
Primary Detection Signals
Primary detection signals for [EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 should focus on observable activity tied to exposed portal access, suspicious pre-authentication interaction, firewall instability, administrative-control anomalies, configuration integrity changes, and firewall-originated outbound communication.
These signals should support detection of exploitation attempts, probable exploitation, and post-exploitation activity. They should not be treated as standalone proof of compromise without correlation to additional behavioral, forensic, or vendor-supported evidence.
Exposed Portal Reachability
PA-Series or VM-Series firewalls with User-ID Authentication Portal or Captive Portal enabled and reachable from untrusted networks, internet-originating sources, cloud ingress paths, external load balancers, permissive security policies, or unmanaged scanning infrastructure.
Suspicious Portal Interaction
Abnormal or high-risk pre-authentication interaction with User-ID Authentication Portal services, including unexpected source patterns, repeated probing, unusual session behavior, abnormal request timing, or access inconsistent with normal portal usage.
Portal Activity From Untrusted Sources
Portal-directed traffic from newly observed internet sources, scanning infrastructure, anonymized access paths, cloud-hosted infrastructure, or networks with no expected relationship to the protected environment.
Firewall Instability Near Portal Activity
Firewall crash, restart, failover, portal interruption, management-plane instability, dataplane degradation, repeated fault events, or degraded inspection behavior occurring near suspicious portal-directed activity.
Administrative-Control Anomaly
Unexpected administrator login, new or modified administrative account, privilege change, unauthorized commit, authentication-profile change, certificate change, configuration export, or management-setting change following suspicious portal interaction.
Configuration Integrity Change
Unexpected modification to security policy, NAT policy, routing, logging, authentication profile, certificate, management access, administrative account, object configuration, or traffic-enforcement behavior.
Firewall-Originated Outbound Anomaly
Outbound communication from firewall management or control-plane interfaces to newly observed destinations, abnormal DNS destinations, unexplained TLS endpoints, unusual egress paths, or destinations inconsistent with normal update, licensing, logging, telemetry, or management behavior.
Supporting Detection Signals
Supporting signals increase confidence when they occur near primary signals. They should be used to enrich prioritization, scoping, and triage rather than independently establish compromise.
Source-Risk Context
Portal traffic from source infrastructure associated with scanning, hosting providers, anonymization services, VPN services, residential proxy patterns, newly observed networks, or geographies inconsistent with expected portal use.
Temporal Convergence
Portal-directed activity, firewall instability, administrative actions, configuration changes, logging changes, or outbound communication occurring within a defensible investigation window.
Identity and Access Anomaly
Unexpected administrator authentication attempts, unusual administrator source locations, failed administrative bursts, abnormal successful logins, privileged-access-management anomalies, or identity-provider events inconsistent with normal firewall administration.
Visibility Reduction
Changes that reduce, redirect, disable, or weaken firewall logging, log forwarding, administrative auditing, threat logging, traffic visibility, or configuration-change visibility.
Traffic-Control Anomaly
New or modified rules, NAT entries, routes, decryption settings, objects, or rule ordering that changes enforcement in a manner inconsistent with approved change-management activity.
Cloud Exposure Context
For VM-Series deployments, security group expansion, load balancer exposure, public IP association, route table change, ingress rule expansion, or cloud control-plane change that exposes portal services or alters firewall traffic paths.
Exploit Attempt and Instability Signals
Exploit-attempt and instability signals should be prioritized when suspicious portal-directed activity is temporally associated with firewall service degradation or control-plane anomalies.
Abnormal Pre-Authentication Portal Activity
Portal interaction that shows unusual timing, repeated attempts, unexpected session behavior, atypical source distribution, or activity inconsistent with known user authentication workflows.
Targeted Portal Probing
Repeated or focused portal interaction from untrusted sources against exposed User-ID Authentication Portal services, especially when the activity is not consistent with routine user authentication.
Crash or Restart Following Portal Interaction
Firewall crash, restart, fault, failover, portal interruption, or management-plane instability occurring after suspicious portal-directed activity.
Health Degradation Following Portal Interaction
Repeated fault events, degraded inspection behavior, abnormal resource pressure, service-health transitions, or portal availability changes occurring near suspicious portal traffic.
Outbound Communication Signals
Outbound communication signals should be prioritized when they originate from firewall infrastructure and deviate from established management, update, licensing, logging, or telemetry baselines.
New Firewall Egress Destination
Firewall-originated communication to destinations not previously observed in normal management-plane or control-plane activity.
Abnormal Firewall DNS Activity
DNS queries or resolution patterns from firewall infrastructure that do not align with expected vendor, logging, update, telemetry, or management behavior.
Unexpected Firewall TLS Session
Firewall-originated TLS communication to rare, newly observed, suspicious, or operationally unexplained external infrastructure.
Beacon-Like Firewall Egress
Repeated outbound connections from firewall infrastructure with timing regularity, destination consistency, or session characteristics inconsistent with normal firewall operations.
Unexpected Firewall Egress Path
Management-plane or control-plane traffic leaving through unexpected interfaces, routes, NAT paths, cloud egress paths, or network segments.
Persistence and Post-Exploitation Signals (Conditional)
Persistence and post-exploitation signals are conditional because public reporting does not provide a complete persistence model. These signals should be used only when supported by firewall logs, configuration history, forensic review, or validated incident-response findings.
Administrative Account Modification
Creation, modification, reactivation, privilege expansion, or unexpected use of administrative accounts after suspicious portal activity.
Authentication Control Modification
Changes to authentication profiles, identity integration, administrator authentication controls, or related access-control settings that could weaken administrative security or support attacker access.
Certificate or Trust Modification
Unexpected certificate changes, TLS profile changes, key material changes, trust-setting changes, or related modifications affecting firewall trust relationships.
Commit or Configuration Export Anomaly
Unexpected configuration exports, commits outside normal windows, commits by unusual users, repeated commit activity, or commits following suspicious portal interaction.
Logging Control Modification
Changes that reduce event visibility, alter log-forwarding behavior, disable relevant logging, modify syslog destinations, or weaken monitoring coverage.
Traffic Enforcement Modification
Security policy, NAT, routing, decryption, or object changes that alter enforcement, bypass inspection, permit new access, or create unexplained traffic paths.
Lateral Movement and Expansion Signals (Conditional)
Lateral movement and expansion signals should be evaluated only when downstream telemetry supports a defensible connection to suspected firewall compromise.
Internal Reconnaissance After Firewall Interaction
Scanning, service discovery, route exploration, authentication probing, or unusual internal connection attempts occurring after suspicious portal activity or firewall instability.
Credential-Use Anomaly After Firewall Interaction
Use of administrative, service, VPN, or privileged credentials from unusual sources, at unusual times, or against unusual systems after suspected firewall compromise.
Unexpected Access Path Creation
New traffic paths, policy changes, NAT changes, route changes, or access-control changes that enable access inconsistent with prior segmentation or expected firewall enforcement.
Downstream Host Contact
Internal systems contacted from firewall infrastructure, newly permitted paths, or suspicious source paths after suspected exploitation.
Management-Plane Expansion
Access to management systems, identity systems, logging systems, configuration repositories, or administrative workstations following suspected firewall compromise.
Signal Usage Constraints
Detection signals must be interpreted according to evidence strength, telemetry availability, and operational context. No single signal should be used as standalone confirmation of compromise.
Exposure Constraint
Portal exposure is a remediation and hunting trigger, not proof of exploitation.
Attempt Constraint
Suspicious portal-directed traffic can support attempted-exploitation alerting, but compromise-level classification requires correlated instability, administrative anomaly, configuration change, logging change, outbound communication, downstream activity, forensic evidence, or vendor-supported confirmation.
Correlation Constraint
High-confidence alerting should correlate suspicious portal activity with at least one meaningful post-interaction behavior, such as device instability, administrative-control anomaly, configuration change, logging change, outbound communication, or downstream intrusion activity.
Payload Constraint
Detection content should not depend on unvalidated exploit payload strings, public proof-of-concept artifacts, or brittle request characteristics as mandatory conditions.
Source-Reputation Constraint
Source reputation may support prioritization, but it must not be used as the sole basis for compromise classification.
Telemetry Constraint
Signals requiring cloud logs, packet metadata, identity-provider records, privileged-access-management logs, or downstream endpoint telemetry should remain conditional when those sources are unavailable or inconsistently retained.
Noise-Control Constraint
Rules derived from these signals must account for expected portal usage, approved administrative sources, scheduled firewall maintenance, approved change windows, expected update destinations, normal failover behavior, and known log-forwarding patterns.
S23 — Telemetry Requirements
Endpoint and Process Execution Telemetry
Endpoint and process execution telemetry is secondary for this report because the primary detection surface is the PAN-OS firewall, not a conventional workstation or server endpoint.
Endpoint telemetry should support investigation of administrator workstation activity, credential misuse, configuration-management access, and downstream host behavior after suspected firewall compromise. It should not be required to detect initial exploitation.
Administrator Workstation Telemetry
Collect process execution, browser activity, remote administration tooling, command-line activity, credential-use events, authentication events, and unusual network connections from systems used to administer PA-Series or VM-Series firewalls.
Privileged Access Telemetry
Collect privileged-access-management events, administrator session records, credential checkout activity, identity-provider activity, multi-factor authentication events, and anomalous privileged access tied to firewall administration.
Configuration-Management Telemetry
Collect activity from systems used for firewall configuration backups, policy deployment, change automation, certificate management, administrative access workflows, and configuration integrity validation.
Downstream Host Telemetry
Collect endpoint and server telemetry from internal systems contacted after suspicious firewall interaction, newly permitted access paths, unexpected NAT or policy changes, or suspected post-compromise expansion.
Endpoint Telemetry Constraint
Endpoint telemetry should support downstream investigation and credential validation. It must not be treated as a baseline requirement for detecting initial exploitation of CVE-2026-0300.
Memory and Execution Telemetry
Memory and direct execution telemetry are limited because PA-Series and VM-Series firewalls should not be assumed to provide enterprise endpoint-agent visibility.
Detection design should not depend on memory inspection, host-based process telemetry, or direct execution telemetry from the firewall.
Firewall Execution Visibility
Use firewall-native system events, service status, process-health indicators, crash records, management-plane health telemetry, and vendor-supported diagnostic records as substitutes for endpoint-style execution visibility.
Forensic Execution Evidence
When available through vendor-supported diagnostics, authorized forensic collection, or incident-response review, execution evidence may support confirmed-compromise classification.
Memory Telemetry Constraint
Memory-level evidence may validate unauthorized code execution, but it should not be required for deployable detection. Baseline detections should rely on firewall-native logs, network telemetry, configuration history, device-health records, and behavioral correlation.
Crash and Fault Telemetry
Crash and fault telemetry is a primary requirement because exploitation attempts against a firewall control plane may produce instability even when payload content is unavailable.
This telemetry should receive high collection priority for affected PA-Series and VM-Series firewalls where the User-ID Authentication Portal or Captive Portal is enabled or exposed.
Firewall Crash and Restart Records
Collect crash events, unexpected restart records, process fault indicators, diagnostic references where available, service-failure events, and abnormal management-plane restart activity.
Portal Service Health
Collect User-ID Authentication Portal or Captive Portal service interruption records, portal availability changes, portal error patterns, service degradation, and portal-adjacent health events.
Management-Plane Health
Collect management-plane degradation, high resource pressure, commit failures, administrative interface instability, abnormal latency, management service restarts, and control-plane fault events.
Dataplane and Inspection Health
Collect dataplane degradation, inspection interruption, high-availability failover, HA state changes, policy enforcement irregularities, and abnormal traffic-inspection health indicators.
Fault Correlation Requirement
Crash and fault telemetry should preserve timestamps, device identity, service context, HA state, interface or zone context where available, and proximity to portal-directed traffic, administrative activity, configuration changes, and outbound communication.
File and Persistence Telemetry
File and persistence telemetry is conditional because public reporting does not provide a complete persistence model for this activity. Collection should focus on configuration integrity, administrative-control state, certificate and trust changes, and visibility-impacting modifications.
Configuration Integrity Telemetry
Collect configuration change history, commit records, configuration exports, configuration imports, backup activity, object changes, policy changes, routing changes, NAT changes, and management-setting changes.
Administrative-Control State
Collect administrator account creation, deletion, reactivation, privilege modification, role assignment, authentication-profile assignment, and unusual administrator usage.
Certificate and Trust Telemetry
Collect certificate creation, certificate replacement, TLS profile changes, trusted authority changes, key material changes, and trust-setting modifications affecting firewall authentication, administration, or encrypted communication.
Logging and Forwarding Telemetry
Collect changes to logging profiles, syslog forwarding, threat log forwarding, traffic log forwarding, administrative audit logging, log destinations, and monitoring visibility controls.
Persistence Evidence Constraint
Do not assume a specific persistence artifact unless supported by vendor guidance, validated forensic findings, or incident-response evidence. Persistence-related telemetry should be used to identify suspicious control-plane changes, stealth-enabling modifications, and attacker-maintained access.
Network and Outbound Communication Telemetry
Network and outbound communication telemetry is a primary requirement because the firewall may be both the exploitation target and a post-compromise egress point.
Inbound Portal Traffic
Collect traffic to User-ID Authentication Portal or Captive Portal services from untrusted networks, public internet sources, cloud ingress paths, load balancers, scanning infrastructure, and source networks without expected portal-use relationships.
Firewall-Originated Egress
Collect outbound communication from firewall management and control-plane interfaces, including destination IP, domain, autonomous system, protocol, port, timing, session duration, byte volume, TLS metadata where available, DNS resolution, and route or interface path.
Firewall-Adjacent Network Metadata
Collect NetFlow, VPC Flow Logs, NSG Flow Logs, firewall-adjacent packet metadata, NDR events, IDS alerts, load balancer access records, and external perimeter telemetry that can observe traffic to or from firewall infrastructure.
Internal Traffic Path Telemetry
Collect network records that show new access paths, newly permitted flows, route changes, NAT behavior changes, inspection bypass, or internal access inconsistent with prior firewall enforcement.
Outbound Baseline Requirement
Outbound telemetry must distinguish normal update, licensing, logging, telemetry, management, monitoring, and vendor communication from newly observed, rare, unexplained, or suspicious firewall-originated destinations.
Web and Application Telemetry (Conditional Availability)
Web and application telemetry is conditional because the exposed service is a firewall-hosted portal rather than a conventional web application stack.
Where available, portal-specific or ingress-layer telemetry should enrich exposure validation, source analysis, and suspicious interaction assessment.
Portal Access Telemetry
Collect User-ID Authentication Portal or Captive Portal access records, source address, requested service, session metadata, authentication workflow events, portal errors, unusual interaction timing, and activity inconsistent with normal user authentication workflows.
Load Balancer and Ingress Telemetry
For environments where portal access traverses a load balancer, proxy, cloud ingress component, or external traffic-management layer, collect access logs, source metadata, request timing, TLS metadata, route selection, health checks, and error responses.
Attack-Surface Telemetry
Collect external exposure data showing whether the portal is reachable from untrusted networks, which ingress paths expose it, whether cloud controls permit access, and whether exposure changed near suspicious activity.
Web Telemetry Constraint
Do not require full HTTP request payload visibility as a baseline dependency. Portal and ingress-layer telemetry should support exposure validation, source analysis, and interaction pattern assessment, but detection must remain viable when payload detail is limited.
Telemetry Availability Requirements
Effective detection requires consistent collection, retention, normalization, and correlation across firewall-native logs, network-adjacent telemetry, administrative records, and exposure data.
Minimum Required Telemetry
· PAN-OS system logs.
· PAN-OS traffic logs.
· PAN-OS threat logs.
· PAN-OS configuration logs.
· PAN-OS administrative audit logs.
· Administrator login history.
· Commit history.
· Firewall crash, fault, restart, failover, and service-health records.
· Network telemetry observing inbound portal traffic.
· Network telemetry observing firewall-originated outbound communication.
· Asset inventory for PA-Series and VM-Series firewalls.
· PAN-OS version inventory.
· User-ID Authentication Portal or Captive Portal enablement and exposure status.
Strongly Recommended Telemetry
· Portal access telemetry where available.
· Configuration export and import records.
· Identity-provider logs for firewall administrators.
· Privileged-access-management logs.
· Configuration backup and change-management records.
· External attack-surface management data.
· DNS telemetry for firewall-originated lookups.
· TLS metadata for firewall-originated sessions.
· Load balancer or ingress logs where applicable.
· Endpoint telemetry from administrator workstations.
Conditional Telemetry
· Cloud control-plane telemetry for VM-Series deployments.
· Cloud flow logs for VM-Series traffic paths.
· Cloud load balancer access logs for exposed portal paths.
· Internal host telemetry for suspected downstream activity.
· Packet metadata or packet capture where legally available and operationally feasible.
· Vendor-supported forensic or diagnostic artifacts.
Retention Requirement
Telemetry should be retained long enough to support retrospective hunting across exposure windows, exploit-attempt activity, delayed follow-on activity, configuration changes, outbound communication, and post-compromise investigation.
Normalization Requirement
Firewall logs, network records, identity events, cloud telemetry, and configuration-change records should preserve timestamps, source and destination context, device identity, user identity where available, action fields, object names, policy names, interface or zone context, and commit metadata.
Correlation Requirement
Telemetry must support correlation between portal exposure, suspicious portal interaction, device instability, administrative activity, configuration changes, outbound communication, and downstream activity.
Telemetry Limitations and Gaps
Telemetry limitations must be explicitly accounted for so detection logic does not depend on unavailable, inconsistent, or overly fragile data sources.
Limited Payload Visibility
Many environments will not have full payload visibility for portal-directed traffic. Detection should not depend on complete request bodies, unvalidated exploit strings, or packet capture as mandatory inputs.
Firewall Endpoint-Agent Gap
PA-Series and VM-Series firewalls should not be assumed to provide conventional endpoint-agent process, memory, or file telemetry. Detection should rely on firewall-native logs, health indicators, configuration records, and network telemetry.
Portal Logging Variability
Portal-specific telemetry may vary by deployment, logging configuration, PAN-OS version, forwarding configuration, and retention policy. Detection content should degrade gracefully when portal access detail is limited.
Cloud Telemetry Variability
VM-Series cloud telemetry depends on provider logging configuration, flow-log enablement, load balancer architecture, route design, security group visibility, and control-plane logging retention.
NAT and Source Attribution Challenges
Source attribution may be weakened by NAT, proxies, load balancers, cloud ingress paths, carrier-grade NAT, VPN services, residential proxies, or anonymization infrastructure.
Administrative Activity Ambiguity
Administrator logins, commits, policy changes, and service restarts may occur during legitimate maintenance. Detection logic must account for approved change windows, expected administrator sources, normal commit behavior, and maintenance records.
Outbound Communication Ambiguity
Firewall-originated outbound traffic may include legitimate update, licensing, logging, telemetry, and management activity. Detection logic must baseline expected destinations and avoid treating all outbound communication as suspicious.
Post-Exploitation Evidence Gap
Public technical detail remains limited, and a complete persistence or intrusion artifact model may not be available. Detection must prioritize behavioral correlation and validated evidence rather than assumed post-exploitation artifacts.
Telemetry Failure Risk
Attackers may attempt to reduce visibility by modifying logging, changing forwarding destinations, altering policies, disabling relevant telemetry, or creating traffic paths that bypass expected monitoring. Changes to logging and visibility should be treated as high-value supporting signals when they occur near suspicious portal activity
Figure 4
S24 — Detection Opportunities and Gaps
Detection Opportunities and Gaps
Detection opportunities for [EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 are strongest where exposed portal reachability, suspicious portal-directed activity, firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, and firewall-originated outbound communication can be correlated.
The primary detection challenge is not signal absence. The primary challenge is separating exposure, attempted exploitation, probable exploitation, and confirmed compromise without overclassifying single-signal events.
Detection engineering should prioritize opportunities that are telemetry-realistic, behaviorally durable, low-noise, and resilient to attacker changes in source infrastructure, timing, request shape, and follow-on activity.
Rule-Grade Detection Opportunities
Suspicious Portal Activity Followed by Firewall Instability
Detect suspicious portal-directed activity followed by firewall crash, restart, fault, failover, portal interruption, management-plane degradation, or degraded inspection behavior.
This is a rule-grade opportunity because it combines exploit-facing activity with device-health impact and does not require payload visibility.
Suspicious Portal Activity Followed by Administrative-Control Anomaly
Detect suspicious portal-directed activity followed by unexpected administrator login, account modification, privilege change, unauthorized commit, authentication-profile change, certificate change, configuration export, or management-setting change.
This is a rule-grade opportunity when administrator behavior is inconsistent with expected sources, approved users, normal maintenance activity, or established change patterns.
Suspicious Portal Activity Followed by Configuration Integrity Change
Detect suspicious portal-directed activity followed by unexpected changes to security policy, NAT policy, routing, logging behavior, traffic enforcement, object configuration, authentication profiles, certificates, or management access.
This is a rule-grade opportunity because configuration changes after suspicious portal interaction may indicate attacker attempts to alter enforcement, preserve access, enable traffic paths, or reduce visibility.
Suspicious Portal Activity Followed by Firewall-Originated Outbound Anomaly
Detect suspicious portal-directed activity followed by firewall-originated communication to newly observed, rare, unexplained, or suspicious destinations inconsistent with expected update, licensing, logging, telemetry, monitoring, or management baselines.
This is a rule-grade opportunity when outbound behavior is temporally linked to suspicious portal activity, instability, administrative anomalies, or configuration change.
Visibility Reduction Near Suspicious Portal Activity
Detect logging, forwarding, audit, monitoring, or visibility-control changes occurring near suspicious portal-directed activity.
This is a rule-grade opportunity when the change reduces investigative visibility and is not explained by approved change-management activity.
Hunt-Grade Detection Opportunities
Exposed Portal Reachability
Identify PA-Series and VM-Series firewalls where User-ID Authentication Portal or Captive Portal is enabled and reachable from untrusted networks, public ingress paths, cloud exposure points, external load balancers, or permissive access policies.
This is high-value for remediation and retrospective hunting, but exposure alone should not be deployed as a compromise-level rule.
Suspicious Portal Interaction Without Follow-On Behavior
Identify abnormal or high-risk pre-authentication interaction with User-ID Authentication Portal services from internet-originating, scanner-associated, anonymized, newly observed, or unexpected source infrastructure.
This can support attempted-exploitation alerting or hunting, but probable-exploitation classification requires correlated instability, administrative anomaly, configuration change, outbound anomaly, downstream activity, forensic evidence, or vendor-supported confirmation.
Affected Firewall Instability Without Portal Detail
Identify crash, restart, fault, failover, portal interruption, or management-plane degradation on affected and exposed PA-Series or VM-Series firewalls where portal telemetry is incomplete.
This should remain hunt-grade unless paired with suspicious portal access, administrative-control anomaly, configuration change, visibility reduction, outbound anomaly, or forensic evidence.
Firewall-Originated Outbound Anomaly Without Portal Detail
Identify unusual firewall-originated outbound communication where portal telemetry is limited or unavailable.
This should remain hunt-grade unless paired with affected-device exposure, firewall instability, administrative-control anomaly, configuration change, visibility reduction, or downstream evidence.
Conditional Detection Opportunities
VM-Series Cloud Exposure Change
For VM-Series deployments, detect security group expansion, public IP association, load balancer exposure, route table change, cloud ingress change, or permissive network-control modification that exposes portal services or alters firewall traffic paths.
This opportunity is conditional on cloud control-plane telemetry, cloud flow-log availability, and accurate VM-Series asset mapping.
Downstream Intrusion Activity After Suspected Firewall Compromise
Detect internal reconnaissance, credential-use anomalies, lateral movement indicators, management-plane expansion, or unexpected access paths after suspected firewall compromise.
This opportunity is conditional and should require defensible temporal linkage to suspicious firewall activity or confirmed firewall compromise.
Vendor-Supported Forensic Confirmation
Use vendor-supported diagnostics, forensic evidence, or validated incident-response findings to confirm unauthorized code execution, unauthorized configuration activity, malicious persistence, or attacker-controlled behavior.
This opportunity supports confirmed-compromise classification but should not be assumed available in all environments.
Detection Gaps
Exploit Payload Visibility Gap
Many environments may lack full payload visibility for portal-directed traffic. Detection should not depend on complete request bodies, packet capture, public proof-of-concept strings, or unvalidated exploit byte patterns.
Firewall Endpoint-Agent Gap
PA-Series and VM-Series firewalls should not be assumed to provide conventional endpoint-agent telemetry, direct process execution logs, memory telemetry, or file-level monitoring comparable to workstation or server EDR platforms.
Portal Logging Gap
Portal-specific access telemetry may vary by PAN-OS version, logging configuration, forwarding policy, retention, deployment architecture, and exposure path.
Source Attribution Gap
Source attribution may be weakened by NAT, load balancers, cloud ingress paths, VPN services, residential proxies, carrier-grade NAT, anonymization infrastructure, and compromised intermediary systems.
Post-Exploitation Artifact Gap
Public reporting may not provide a complete post-exploitation artifact model. Detection should not assume specific persistence files, malware families, payload names, file paths, process names, or command strings unless supported by vendor guidance or validated incident-response evidence.
Cloud Visibility Gap
VM-Series detection depends on cloud logging configuration, flow-log enablement, load balancer telemetry, security group visibility, IAM logging, route visibility, and control-plane retention.
Administrative Ambiguity Gap
Administrator logins, commits, policy changes, certificate updates, logging changes, restarts, and failovers may be legitimate during approved maintenance.
Outbound Baseline Gap
Firewall-originated outbound traffic can include legitimate update, licensing, telemetry, logging, monitoring, and management communication.
Retention and Normalization Gap
Short retention, inconsistent timestamps, missing device identifiers, incomplete zone or interface context, absent user identity fields, incomplete commit metadata, and inconsistent log forwarding can weaken correlation.
False Positive Drivers
Routine Portal Use
Expected user authentication activity may produce legitimate portal traffic.
Authorized Security Testing
Approved vulnerability scanning, exposure management, penetration testing, and security validation may resemble suspicious portal probing.
Approved Maintenance
Expected restarts, failovers, commits, policy changes, certificate updates, logging changes, and configuration exports may occur during approved maintenance windows.
Normal Vendor or Management Communication
Firewall-originated communication to expected update, licensing, telemetry, logging, support, or management destinations may be normal.
Approved Cloud Architecture Changes
Security group changes, public IP association, load balancer updates, route modifications, and ingress changes may be legitimate infrastructure operations.
False Negative Drivers
Low-Volume Exploitation
Attackers may use minimal probing or single-attempt exploitation that does not create volume-based anomalies.
Delayed Follow-On Activity
Attackers may delay administrative activity, outbound communication, or downstream movement beyond short correlation windows.
Payload and Traffic Variation
Attackers may alter request structure, timing, source infrastructure, session behavior, and traffic shape to avoid brittle signatures.
Visibility Reduction
Attackers may modify logging, forwarding, monitoring, policies, or traffic paths to reduce detection and investigation visibility.
Trusted-Path Abuse
Attackers may use compromised infrastructure, residential proxy networks, VPN services, expected regions, or cloud-hosted infrastructure to weaken source-risk signals.
Legitimate-Admin Blending
Attackers may attempt to blend into normal administrator behavior, expected commit patterns, approved management paths, or scheduled maintenance periods.
Rule Development Implications
Primary Rule Candidates
The strongest S25 candidates should focus on correlated suspicious portal activity plus firewall instability, administrative-control anomaly, configuration integrity change, visibility reduction, or firewall-originated outbound anomaly.
Secondary Rule Candidates
Secondary S25 candidates may focus on affected firewall instability, outbound anomalies, or administrative-control anomalies when portal telemetry is limited but affected-device exposure is confirmed.
Hunt-Only Candidates
Exposure-only findings, source-reputation-only findings, generic scanning, affected-version inventory, and standalone outbound anomalies should generally remain hunt, triage, remediation, or enrichment logic rather than compromise-level rules.
Conditional Candidates
Cloud exposure detections, downstream lateral movement detections, and forensic-confirmation workflows should be included only where telemetry availability and environmental scoping support reliable deployment.
Rejected Detection Paths
Payload-String-Only Detection
Do not rely on public exploit strings, proof-of-concept artifacts, or unvalidated payload patterns as mandatory detection conditions.
Exposure-Only Compromise Detection
Do not classify portal exposure alone as exploitation or compromise.
Source-Reputation-Only Detection
Do not classify source reputation alone as exploitation or compromise.
Endpoint-Agent-Only Detection
Do not require endpoint-agent telemetry from the firewall as a baseline condition for detection coverage.
Packet-Capture-Only Detection
Do not require full packet capture as a mandatory dependency for exploit-attempt or probable-exploitation detection.
Generic Firewall Access Detection
Do not deploy generic any-external-access-to-firewall detections without service context, portal scoping, source context, exposure state, and environmental baselining.
Affected-Version-Only Detection
Do not treat affected-version inventory alone as exploitation. Affected-version inventory should support prioritization, exposure management, and remediation tracking.
Overall Gap Assessment
The strongest detection path is behavioral correlation across portal exposure, suspicious portal-directed traffic, firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, and firewall-originated outbound communication.
The largest detection gaps are payload visibility, firewall endpoint-agent absence, variable portal logging, source attribution limits, post-exploitation artifact uncertainty, cloud telemetry variability, and retention quality.
Detection engineering should prioritize correlation-ready and telemetry-realistic rules that remain effective without full payload visibility, endpoint-agent instrumentation, static exploit artifacts, or proprietary environment-specific assumptions.
S25 Ultra-Tuned Detection Engineering Rules
NDR / Network Behavioral Analytics
Detection Viability Assessment
NDR / Network Behavioral Analytics has two rules for this EXP report.
NDR is viable because the strongest network detection opportunities for this activity are behavioral rather than signature-based. The rule set focuses on exposed firewall portal interaction followed by abnormal firewall-originated egress or validated downstream network behavior.
NDR is preferred over packet-signature-only detection because public reporting does not provide a stable exploit payload, validated byte pattern, or durable request signature for CVE-2026-0300.
Rule
Suspicious PAN-OS Portal Interaction Followed by Firewall-Originated Outbound Anomaly
Rule Format
NDR correlation pattern requiring platform field validation, asset-tag validation, baseline-function validation, and temporal-correlation adaptation before deployment.
Detection Purpose
· Detect suspicious inbound interaction with exposed PAN-OS User-ID Authentication Portal or Captive Portal services followed by abnormal outbound communication from the same firewall.
· Identify probable exploitation patterns without relying on static exploit strings, packet payload matching, proof-of-concept artifacts, attacker IP addresses, or source reputation alone.
· Prioritize firewall-originated communication that deviates from known update, licensing, logging, telemetry, monitoring, management, or vendor-support baselines.
· This rule does not confirm unauthorized code execution without corroborating firewall, forensic, vendor-supported, configuration, or incident-response evidence.
Detection Logic
· Identify inbound traffic from untrusted, internet-originating, newly observed, scanner-associated, anonymized, cloud-hosted, or otherwise unexpected sources to scoped PA-Series or VM-Series firewall assets.
· Require the destination firewall to have User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Require the source to be untrusted, high-risk, or otherwise locally validated as unexpected, and require the source IP not to be part of approved portal-source or approved scanner ranges.
· Correlate the suspicious inbound portal-directed event with outbound communication from the same firewall within a defensible investigation window.
· Prioritize outbound communication to newly observed destinations, rare autonomous systems, abnormal DNS destinations, unexpected TLS endpoints, unusual ports, unexpected egress paths, or destinations inconsistent with known firewall operations.
· Increase priority when outbound behavior is supported by firewall system logs, administrative-control anomalies, configuration changes, visibility reduction, or device instability from another telemetry source.
· Treat portal exposure, affected-version inventory, generic scanning, and source reputation as enrichment context, not standalone compromise evidence.
Required Telemetry
· NDR flow telemetry observing inbound traffic to PA-Series or VM-Series firewalls.
· NDR flow telemetry observing outbound communication from PA-Series or VM-Series firewalls.
· Asset identity for PA-Series and VM-Series firewalls.
· User-ID Authentication Portal or Captive Portal exposure context.
· Source IP address.
· Destination IP address.
· Source port and destination port.
· Protocol.
· Timestamp.
· Session duration.
· Byte and packet volume.
· Directionality.
· Sensor, interface, zone, segment, or cloud path context where available.
· DNS metadata where available.
· TLS metadata where available.
· Baseline of expected firewall egress destinations.
· Baseline of expected update, licensing, logging, telemetry, monitoring, vendor-support, and management traffic.
Engineering Implementation Instructions
· Validate NDR asset inventory for PA-Series and VM-Series firewalls before deployment.
· Tag scoped firewalls by role, exposure state, portal enablement, internet reachability, and management-plane egress profile.
· Validate platform field names for asset identity, source IP, destination IP, service, direction, timestamp, session duration, byte volume, packet volume, DNS metadata, TLS metadata, source-risk fields, and egress path.
· Define expected portal source ranges, approved scanner infrastructure, approved administrative networks, and expected business portal-use patterns before enabling alerting.
· Baseline normal firewall-originated destinations for update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management activity.
· Require same-firewall temporal correlation between inbound portal-directed activity and subsequent outbound anomaly.
· Validate the investigation window locally based on network latency, log latency, normal portal use, firewall egress frequency, and SOC triage requirements.
· Suppress approved scanning, approved exposure testing, known maintenance windows, and expected firewall egress only when asset, source, destination, timing, and change context are validated.
· Route alerts at higher priority when NDR correlation is supported by firewall system logs, administrative logs, configuration changes, visibility reduction, or device instability.
DRI Assessment
DRI
8.5 / 10
· The rule is behaviorally anchored to suspicious portal-facing activity followed by abnormal firewall-originated egress.
· The rule remains useful if attackers change payload structure, source infrastructure, request timing, user-agent values, or visible exploit characteristics.
· The score is supported by same-asset temporal correlation between inbound exploitation-facing activity and outbound behavior from firewall infrastructure.
· The score is constrained by dependence on NDR visibility, firewall asset mapping, egress baselining, and reliable portal exposure context.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.5 / 10
· Operational confidence depends on NDR sensor coverage, accurate firewall asset identity, flow retention, egress baseline quality, DNS or TLS enrichment, source-risk context, and exposure context.
· Operational confidence is reduced where firewall-originated egress is not visible, destination baselines are immature, source-risk context is unavailable, or portal exposure state is unknown.
· Full-telemetry confidence improves when NDR data is enriched with PAN-OS system logs, administrative audit logs, configuration logs, portal access telemetry, DNS metadata, and TLS metadata.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious network behavior associated with possible firewall exploitation, not confirmed unauthorized code execution.
· Normal firewall update, licensing, logging, telemetry, support, monitoring, DNS, NTP, and management traffic may overlap with outbound anomaly logic if baselines are incomplete.
· Approved scanning, penetration testing, exposure management, or legitimate portal use may overlap with suspicious inbound activity.
· Encrypted traffic may limit request-level visibility.
· Source attribution may be weakened by NAT, load balancers, cloud ingress paths, VPN services, residential proxies, or anonymization infrastructure.
· Confirmation requires correlation with firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
// NDR / Network Behavioral Analytics correlation pattern requiring platform field
// validation, asset-tag validation, source-risk validation, baseline-function
// validation, and temporal syntax adaptation before deployment.
//
// Phase 1 identifies suspicious inbound portal-directed activity.
// Phase 2 correlates the same firewall with follow-on outbound anomaly.
//
// Important source-filter correction:
// The source must be untrusted or locally high-risk AND must not be an approved
// portal source or approved scanner source. Do not use broad OR logic that allows
// approved portal sources to pass solely because they originate from an external zone.
PHASE 1 — Suspicious Inbound PAN-OS Portal Interaction
AssetRole IN ANY (
"PA-Series Firewall",
"VM-Series Firewall",
"PAN-OS Firewall"
)
AND DestinationAssetID IN SCOPED_PANOS_FIREWALLS
AND PortalExposureState IN ANY (
"enabled",
"exposed",
"under_investigation"
)
AND Direction = "inbound"
AND DestinationService IN ANY (
"tcp/443",
"tcp/6080",
"tcp/6081"
)
AND (
SourceZone IN ANY (
"untrust",
"internet",
"external"
)
OR SourceRisk IN ANY (
"scanner",
"anonymized",
"newly_observed",
"cloud_hosted_unexpected",
"high_risk"
)
)
AND SourceIP NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND SourceIP NOT IN APPROVED_SCANNER_SOURCE_RANGES
PHASE 2 — Same-Firewall Outbound Anomaly
Direction = "outbound"
AND SourceAssetID = PHASE_1.DestinationAssetID
AND Timestamp > PHASE_1.Timestamp
AND Timestamp <= PHASE_1.Timestamp + INVESTIGATION_WINDOW
AND (
DestinationIP IS NEW_FOR SourceAssetID
OR DestinationDomain IS NEW_FOR SourceAssetID
OR DestinationASN IS RARE_FOR SourceAssetID
OR DestinationPort NOT IN EXPECTED_FIREWALL_EGRESS_PORTS
OR EgressPath NOT IN EXPECTED_FIREWALL_EGRESS_PATHS
OR TLSJA3 IS RARE_FOR SourceAssetID
OR DNSQuery IS RARE_FOR SourceAssetID
OR SessionPattern = "beacon_like"
)
AND DestinationIP NOT IN EXPECTED_FIREWALL_VENDOR_DESTINATIONS
AND DestinationDomain NOT IN EXPECTED_FIREWALL_VENDOR_DOMAINS
AND DestinationIP NOT IN APPROVED_LOGGING_TELEMETRY_DESTINATIONS
AND DestinationIP NOT IN APPROVED_MANAGEMENT_DESTINATIONS
Rule
Suspicious PAN-OS Portal Interaction Followed by Validated Internal Reconnaissance or Newly Observed Access Path
Rule Format
Conditional NDR correlation pattern requiring platform field validation, internal sensor coverage validation, firewall-mediated path attribution validation, baseline-function validation, and temporal-correlation adaptation before deployment.
Detection Purpose
· Detect suspicious interaction with exposed PAN-OS User-ID Authentication Portal or Captive Portal services followed by validated internal reconnaissance, newly observed access paths, or unusual east-west communication associated with the same firewall or a confirmed firewall-mediated path.
· Identify possible post-compromise network expansion without relying on payload signatures, exploit strings, static attacker infrastructure, or endpoint-agent telemetry from the firewall.
· Support investigation of firewall-enabled access changes, newly permitted flows, or internal traffic behavior that may follow edge firewall compromise.
· This rule is conditional and should be deployed only where internal NDR visibility and firewall-mediated path attribution are validated.
Detection Logic
· Identify suspicious inbound portal-directed activity against a scoped PA-Series or VM-Series firewall.
· Require the source to be untrusted, high-risk, or otherwise locally validated as unexpected, and require the source IP not to be part of approved portal-source or approved scanner ranges.
· Require validated internal NDR visibility for the segments, zones, or paths controlled by the scoped firewall.
· Require validated attribution between the scoped firewall and subsequent internal traffic, either through same-firewall source identity, confirmed firewall-mediated path identity, or verified network-path mapping.
· Correlate suspicious portal-directed activity with subsequent internal reconnaissance, destination fan-out, port fan-out, new internal destination access, new segment access, service-discovery behavior, management-protocol access, or newly observed firewall-mediated access path.
· Increase priority when internal activity follows a firewall configuration change, NAT change, route change, policy modification, visibility reduction, or administrative-control anomaly.
· Treat the rule as conditional detection coverage, not universal NDR coverage. If internal visibility or firewall-mediated path attribution is weak, this logic should remain hunt guidance rather than an alerting rule.
· Do not classify internal activity as confirmed compromise without corroborating firewall, configuration, identity, endpoint, forensic, or incident-response evidence.
Required Telemetry
· NDR flow telemetry observing inbound traffic to scoped PAN-OS firewalls.
· NDR flow telemetry observing internal traffic paths through, from, or demonstrably mediated by scoped PAN-OS firewalls.
· Validated firewall asset identity.
· Validated firewall-mediated path attribution.
· Internal asset identity where available.
· Network segment, zone, route, interface, or sensor context.
· Source and destination IP addresses.
· Source and destination ports.
· Protocol.
· Timestamp.
· Session duration.
· Byte and packet volume.
· Directionality.
· Baseline of expected internal traffic paths.
· Baseline of expected firewall-mediated flows.
· Firewall policy, NAT, route, or configuration-change context where available.
Engineering Implementation Instructions
· Deploy only where NDR has reliable internal traffic visibility for the segments, routes, zones, or paths controlled by scoped PA-Series or VM-Series firewalls.
· Validate firewall asset identity, firewall-mediated path attribution, internal segment mapping, zone mapping, route context, and expected firewall-mediated traffic paths before deployment.
· Do not deploy this rule where internal NDR visibility is limited to internet-edge traffic only.
· Do not deploy this rule where the NDR platform cannot defensibly attribute internal activity to the scoped firewall or a firewall-mediated path.
· Define normal internal destination fan-out, port fan-out, management-plane access, service discovery patterns, and expected east-west communication involving firewall-controlled paths.
· Require temporal linkage between suspicious portal-directed activity and subsequent validated internal reconnaissance or newly observed access path.
· Use firewall policy, NAT, route, configuration-change, visibility-reduction, or administrative-control context as prioritization evidence when available.
· Tune approved vulnerability scanning, network discovery, maintenance, segmentation testing, routing changes, cloud networking changes, and approved management activity before alert deployment.
· Demote this logic to hunt guidance if internal traffic visibility, path attribution, segment mapping, or baselining is incomplete.
DRI Assessment
DRI
7.5 / 10
· The rule is behaviorally anchored to suspicious portal-facing activity followed by validated internal reconnaissance or newly observed firewall-mediated access behavior.
· The rule remains useful if attackers vary source infrastructure, request timing, payload structure, or post-compromise tooling.
· The score is supported by temporal linkage between edge-firewall interaction and downstream network behavior.
· The score is constrained by dependence on internal NDR visibility, path attribution, segmentation baselines, and the ability to distinguish legitimate network changes from suspicious expansion.
TCR Assessment
Operational TCR
6.0 / 10
Full-Telemetry TCR
8.0 / 10
· Operational confidence depends on east-west sensor coverage, validated firewall-mediated path attribution, asset mapping, route context, zone context, segmentation baselines, and flow retention.
· Operational confidence is reduced where internal traffic is not visible, firewall path attribution is weak, or network-change activity is frequent and poorly baselined.
· Full-telemetry confidence improves when NDR data is enriched with PAN-OS configuration logs, NAT changes, route changes, policy changes, identity logs, endpoint telemetry, and change-management records.
· Even under full telemetry conditions, this rule supports probable post-compromise activity and requires corroboration before confirmed-compromise classification.
Limitations
· This rule is conditional and should not be deployed where internal network visibility or firewall-mediated path attribution is insufficient.
· Legitimate vulnerability scanning, network discovery, segmentation testing, routing changes, policy updates, and cloud networking changes may overlap with this behavior.
· Firewall-mediated path attribution may be incomplete in environments with NAT, asymmetric routing, cloud transit gateways, load balancers, or complex segmentation.
· Low-volume or delayed internal activity may evade short correlation windows.
· Confirmation requires correlation with firewall logs, configuration evidence, endpoint telemetry, identity telemetry, forensic evidence, or validated incident-response findings.
Detection Query Pattern
// Conditional NDR / Network Behavioral Analytics correlation pattern requiring
// platform field validation, internal sensor coverage validation, firewall-mediated
// path attribution validation, baseline-function validation, source-risk validation,
// and temporal syntax adaptation before deployment.
//
// Phase 1 identifies suspicious inbound portal-directed activity.
// Phase 2 correlates validated firewall-mediated internal reconnaissance or newly
// observed access behavior within the investigation window.
//
// Deploy as alert logic only when internal NDR visibility and firewall-mediated
// path attribution are validated. Otherwise, retain as hunt guidance.
//
// Important source-filter correction:
// The source must be untrusted or locally high-risk AND must not be an approved
// portal source or approved scanner source. Do not use broad OR logic that allows
// approved portal sources to pass solely because they originate from an external zone.
PHASE 1 — Suspicious Inbound PAN-OS Portal Interaction
AssetRole IN ANY (
"PA-Series Firewall",
"VM-Series Firewall",
"PAN-OS Firewall"
)
AND DestinationAssetID IN SCOPED_PANOS_FIREWALLS
AND PortalExposureState IN ANY (
"enabled",
"exposed",
"under_investigation"
)
AND Direction = "inbound"
AND DestinationService IN ANY (
"tcp/443",
"tcp/6080",
"tcp/6081"
)
AND (
SourceZone IN ANY (
"untrust",
"internet",
"external"
)
OR SourceRisk IN ANY (
"scanner",
"anonymized",
"newly_observed",
"cloud_hosted_unexpected",
"high_risk"
)
)
AND SourceIP NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND SourceIP NOT IN APPROVED_SCANNER_SOURCE_RANGES
PHASE 2 — Validated Internal Reconnaissance or Newly Observed Access Path
Timestamp > PHASE_1.Timestamp
AND Timestamp <= PHASE_1.Timestamp + INVESTIGATION_WINDOW
AND InternalNDRVisibility = "validated"
AND FirewallPathAttribution = "validated"
AND (
SourceAssetID = PHASE_1.DestinationAssetID
OR FirewallPathAssetID = PHASE_1.DestinationAssetID
OR NetworkPath CONTAINS PHASE_1.DestinationAssetID
)
AND Direction IN ANY (
"internal",
"east_west",
"firewall_mediated"
)
AND (
DestinationFanOut IS HIGH_FOR SourceAssetID
OR DestinationPortFanOut IS HIGH_FOR SourceAssetID
OR DestinationIP IS NEW_FOR SourceAssetID
OR DestinationSegment IS NEW_FOR SourceAssetID
OR ServiceDiscoveryPattern = true
OR InternalManagementProtocol IN ANY (
"ssh",
"rdp",
"winrm",
"smb",
"ldap",
"kerberos",
"snmp"
)
OR AccessPath IS NEW_FOR FirewallPathAssetID
)
AND SourceIP NOT IN APPROVED_SCANNER_SOURCE_RANGES
AND ChangeWindow != "approved"
SentinelOne
Detection Viability Assessment
SentinelOne has one conditional rule for this EXP report.
SentinelOne is not viable as an endpoint-native detection source for direct PAN-OS firewall exploitation because PA-Series and VM-Series firewalls should not be assumed to provide SentinelOne endpoint-agent process, memory, or file telemetry.
SentinelOne is viable only where PAN-OS firewall logs are ingested into SentinelOne and are queryable with usable portal, traffic, system, administrative, configuration, and outbound communication fields.
This rule is a log-correlation rule using ingested PAN-OS telemetry. It must not be described as an endpoint-agent detection of initial PAN-OS exploitation.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability or Administrative-Control Anomaly
Rule Format
SentinelOne Deep Visibility correlation pattern requiring tenant field validation and STAR workflow adaptation before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by firewall instability, administrative-control anomalies, configuration changes, or visibility-impacting changes.
· Identify probable exploitation patterns without relying on CVE strings, public proof-of-concept artifacts, attacker IP addresses, source reputation alone, unvalidated payload strings, or endpoint-agent telemetry from the firewall.
· Support detection of suspicious post-interaction firewall behavior where PAN-OS logs are available inside SentinelOne.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious PAN-OS traffic, portal, or access events where User-ID Authentication Portal or Captive Portal services receive activity from untrusted, internet-originating, newly observed, scanner-associated, anonymized, or otherwise unexpected sources.
· Require the source to be untrusted, high-risk, or otherwise locally validated as unexpected, and require the source IP not to be part of approved portal-source or approved scanner ranges.
· Require the portal-directed event to target a scoped PA-Series or VM-Series firewall with User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Correlate the portal-directed event with a same-firewall PAN-OS system event indicating crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Alternatively, correlate the portal-directed event with a same-firewall PAN-OS administrative or configuration event indicating unexpected administrator login, account modification, privilege change, commit activity, configuration export, authentication-profile change, certificate change, logging change, policy modification, NAT change, routing change, or management-setting change.
· Require the instability, administrative, or configuration event to occur after the suspicious portal-directed event within a defensible investigation window.
· Treat exposure-only events, affected-version inventory, generic internet traffic, generic HTTPS or SSL traffic, and source reputation as enrichment or prioritization context, not as standalone compromise evidence.
· Do not classify activity as confirmed compromise without corroborating forensic evidence, vendor-supported confirmation, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Required Telemetry
· PAN-OS traffic logs or portal access logs ingested into SentinelOne.
· PAN-OS system logs ingested into SentinelOne.
· PAN-OS administrative audit logs ingested into SentinelOne.
· PAN-OS configuration logs ingested into SentinelOne.
· Firewall device identity.
· Timestamp.
· Source IP address.
· Destination IP address.
· Destination service, application, URL category, rule name, or portal indicator where available.
· Source zone, destination zone, interface, source-risk, or exposure context where available.
· System event type, severity, description, or subtype.
· Administrator username where available.
· Commit, configuration, certificate, authentication-profile, logging, policy, NAT, routing, or management-setting change fields where available.
· Asset context identifying PA-Series or VM-Series firewalls.
· User-ID Authentication Portal or Captive Portal enablement and exposure context where available.
Engineering Implementation Instructions
· Validate SentinelOne tenant field names for ingested PAN-OS log source, event type, device identity, source IP, destination IP, application, service, URL, rule name, source zone, destination zone, source-risk fields, event subtype, severity, description, username, action, configuration object, and timestamp before deployment.
· Confirm that PAN-OS traffic, system, administrative audit, and configuration logs are ingested into SentinelOne before enabling the rule.
· Confirm that SentinelOne STAR or the deployment workflow can correlate Phase 1 and Phase 2 results by same firewall identity and time window before enabling the rule as an alert.
· Scope the rule to PA-Series and VM-Series firewalls with User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Map local PAN-OS event names for portal traffic, service failure, crash, restart, fault, failover, administrator login, commit activity, configuration export, authentication-profile change, certificate change, logging change, policy change, NAT change, route change, and management-setting change.
· Require a same-firewall relationship between the suspicious portal-directed event and the subsequent instability, administrative, or configuration event.
· Validate the investigation window locally based on log latency, maintenance patterns, portal exposure, and SOC triage requirements.
· Tune expected administrator source ranges, approved maintenance windows, approved scanner infrastructure, approved portal-source ranges, normal commit behavior, expected portal use, and known firewall update, licensing, logging, telemetry, and management activity.
· Use exposure state, affected-version inventory, and source-risk context as prioritization fields rather than standalone alert conditions.
· Route alerts at higher priority when suspicious portal activity is followed by both device instability and administrative or configuration anomalies.
· Do not deploy this rule as endpoint-native SentinelOne coverage for direct PAN-OS exploitation.
DRI Assessment
DRI
8.5 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall instability or administrative-control anomaly rather than static exploit artifacts.
· The rule remains useful if attackers change source infrastructure, request timing, traffic shape, user-agent values, or visible payload structure.
· The score is supported by same-device temporal correlation between exploit-facing portal activity and post-interaction firewall behavior.
· The score is constrained by dependency on PAN-OS log ingestion into SentinelOne and variability in portal, administrative, configuration, and system log field availability.
TCR Assessment
Operational TCR
6.5 / 10
Full-Telemetry TCR
8.0 / 10
· Operational confidence depends on PAN-OS log ingestion quality, field normalization, portal visibility, administrative audit logging, configuration logging, system-event fidelity, device identity consistency, exposure context, source-risk context, and correlation-window support.
· Operational confidence is reduced where SentinelOne lacks complete PAN-OS system logs, configuration logs, administrative audit logs, reliable portal indicators, source-risk fields, or same-device correlation capability.
· Full-telemetry confidence improves when SentinelOne receives PAN-OS traffic, portal, system, administrative, configuration, and outbound communication logs with consistent timestamps and device identifiers.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule depends on PAN-OS firewall logs being ingested into SentinelOne.
· This rule depends on usable same-device and temporal correlation across PAN-OS traffic, system, administrative, and configuration logs.
· This rule does not detect direct PAN-OS exploitation through SentinelOne endpoint-agent telemetry.
· Portal access, administrator logins, commits, configuration changes, failovers, and restarts may occur during legitimate user activity or approved maintenance.
· Portal-specific fields and PAN-OS event names may vary by deployment, forwarding configuration, parser, and tenant normalization.
· Source attribution may be weakened by NAT, load balancers, VPN services, cloud ingress paths, residential proxies, or anonymization infrastructure.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
// SentinelOne Deep Visibility correlation pattern requiring tenant field validation
// and STAR workflow adaptation before deployment.
//
// Deployment model:
// Phase 1 identifies suspicious PAN-OS portal-directed activity on scoped firewalls.
// Phase 2 correlates the same firewall within the investigation window against
// instability, administrative-control, or configuration-change events.
//
// Required local validation:
// - Confirm PAN-OS logs are ingested into SentinelOne.
// - Validate tenant field names for log source, event type, device identity,
// source IP, destination IP, application, service, URL/path, rule name,
// source zone, destination zone, source-risk fields, event description,
// username, action, configuration object, and timestamp.
// - Validate that STAR or the deployment workflow can correlate Phase 1 and
// Phase 2 results by same firewall identity and time window.
// - Replace placeholders with local values before deployment.
//
// Important source-filter correction:
// The source must be untrusted or locally high-risk AND must not be an approved
// portal source or approved scanner source. Do not use broad OR logic that allows
// approved portal sources to pass solely because they originate from an external zone.
PHASE 1 — Suspicious PAN-OS Portal-Directed Activity
EventSource IN ANY (
"PAN-OS",
"Palo Alto Networks",
"Palo Alto Firewall",
"pan:traffic",
"pan:threat"
)
AND DeviceProduct IN ANY (
"PAN-OS",
"PA-Series",
"VM-Series"
)
AND DeviceID IN SCOPED_PANOS_FIREWALLS
AND EventType IN ANY (
"Traffic",
"Portal Access",
"Authentication Portal",
"Captive Portal",
"User-ID Portal"
)
AND (
AppName CONTAINS ANY (
"captive-portal",
"user-id",
"auth-portal"
)
OR UrlPath CONTAINS ANY (
"captive",
"user-id",
"portal"
)
OR RuleName CONTAINS ANY (
"User-ID",
"Captive Portal",
"Authentication Portal"
)
OR DestinationService IN ANY (
"tcp/443",
"tcp/6080",
"tcp/6081"
)
)
AND (
SourceZone IN ANY (
"untrust",
"internet",
"external"
)
OR SourceRisk IN ANY (
"scanner",
"anonymized",
"newly_observed",
"cloud_hosted_unexpected",
"high_risk"
)
)
AND SourceIP NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND SourceIP NOT IN APPROVED_SCANNER_SOURCE_RANGES
PHASE 2 — Same-Firewall Follow-On Instability, Administrative-Control, or Configuration Event
EventSource IN ANY (
"PAN-OS",
"Palo Alto Networks",
"Palo Alto Firewall",
"pan:system",
"pan:config"
)
AND DeviceProduct IN ANY (
"PAN-OS",
"PA-Series",
"VM-Series"
)
AND DeviceID = PHASE_1.DeviceID
AND Timestamp > PHASE_1.Timestamp
AND Timestamp <= PHASE_1.Timestamp + INVESTIGATION_WINDOW
AND (
(
EventType IN ANY (
"System",
"Health",
"HA",
"Service"
)
AND EventDescription CONTAINS ANY (
"crash",
"restart",
"fault",
"failover",
"service unavailable",
"service failed",
"management plane",
"captive portal",
"portal"
)
)
OR
(
EventType IN ANY (
"Configuration",
"Admin",
"Audit",
"System"
)
AND EventDescription CONTAINS ANY (
"commit",
"configuration export",
"admin login",
"administrator login",
"account created",
"account modified",
"privilege",
"authentication profile",
"certificate",
"logging",
"syslog",
"security policy",
"NAT",
"route",
"management setting"
)
)
)
AND EventDescription NOT CONTAINS ANY (
"scheduled maintenance",
"approved commit",
"software update",
"content update",
"license update"
)
AND (
SourceIP NOT IN APPROVED_ADMIN_SOURCE_RANGES
OR SourceIP IS EMPTY
)
Splunk
Detection Viability Assessment
Splunk has three rules for this EXP report.
Splunk is a strong detection surface for this activity because it can correlate PAN-OS traffic logs, system logs, administrative audit logs, configuration logs, network telemetry, DNS data, identity context, exposure context, and change context across a defensible investigation window.
Splunk is strongest when used to detect behaviorally linked activity: suspicious User-ID Authentication Portal or Captive Portal interaction followed by firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, or firewall-originated outbound anomalies.
Splunk rules must not depend on static exploit strings, public proof-of-concept artifacts, attacker IP addresses, source reputation alone, affected-version inventory alone, or generic traffic to firewall infrastructure.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Rule Format
Splunk SPL correlation search requiring PAN-OS sourcetype validation, field normalization, scoped firewall inventory, lookup validation, and temporal-window tuning before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by firewall crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Identify probable exploitation patterns where exploit-facing activity is followed by device-health impact.
· Avoid reliance on payload visibility, unvalidated exploit strings, public proof-of-concept artifacts, or source reputation alone.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious PAN-OS traffic, threat, or portal events where a scoped PA-Series or VM-Series firewall receives portal-directed activity from untrusted and unapproved sources.
· Require the destination firewall to have User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Correlate the portal-directed event with a same-firewall system, HA, service, health, crash, restart, or fault event occurring after the portal-directed event within a defensible investigation window.
· Increase priority when the source is unexpected, the portal is internet-reachable, the firewall is affected or under investigation, and the instability event is not explained by approved maintenance.
· Treat exposure-only findings, affected-version inventory, generic firewall access, and source reputation as enrichment context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS threat logs where available.
· PAN-OS system logs.
· PAN-OS HA, health, or service status logs where available.
· Firewall device identity.
· Source IP address.
· Destination IP address.
· Application, service, URL, rule name, interface, zone, or portal indicator where available.
· System event type, subtype, severity, and description.
· Timestamp.
· Scoped PA-Series or VM-Series firewall inventory.
· User-ID Authentication Portal or Captive Portal exposure context.
· Approved scanner and approved portal-source context.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate local Splunk index names, sourcetypes, CIM mapping, PAN-OS field names, lookup names, and timestamp normalization before deployment.
· Confirm that PAN-OS traffic, threat, and system logs are ingested with consistent firewall identity fields.
· Scope the search to PA-Series and VM-Series firewalls with User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Use lookup flags for scoped firewalls, approved scanner sources, approved portal sources, and maintenance windows instead of negative subsearch logic.
· Tune the portal-source filter so untrusted-zone traffic from approved portal sources does not automatically alert unless another locally validated risk condition is present.
· Tune the correlation window based on log latency, portal exposure, maintenance frequency, and SOC triage requirements.
· Suppress approved maintenance only when device identity, time window, event type, and change context are validated.
DRI Assessment
DRI
8.7 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall instability rather than brittle exploit artifacts.
· The rule remains useful if attackers change source infrastructure, traffic timing, visible request characteristics, or payload structure.
· The score is supported by temporal correlation between exploit-facing portal activity and device-health impact.
· The score is constrained by dependence on portal exposure context, PAN-OS system-log fidelity, lookup quality, and maintenance-window tuning.
TCR Assessment
Operational TCR
7.5 / 10
Full-Telemetry TCR
8.8 / 10
· Operational confidence depends on PAN-OS traffic-log quality, system-log quality, device identity consistency, source-zone context, portal-exposure context, lookup quality, and maintenance-window validation.
· Operational confidence is reduced where portal indicators are incomplete, system logs are not retained, firewall identity fields are inconsistent, or maintenance activity is poorly baselined.
· Full-telemetry confidence improves when Splunk receives PAN-OS traffic, threat, system, HA, administrative, configuration, DNS, and NDR telemetry with consistent device identity and timestamps.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious portal activity followed by firewall instability, not confirmed unauthorized code execution.
· Legitimate maintenance, upgrades, failover testing, service restarts, and approved operational activity may overlap with instability signals.
· Portal indicators may vary by PAN-OS logging configuration, parser, sourcetype, and local field normalization.
· Low-volume exploitation may not produce strong portal-traffic anomalies.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
`comment("Splunk SPL correlation search. Validate index, sourcetype, field names, lookups, firewall identity, and investigation window before deployment.")`
| multisearch
[
search index=pan_logs sourcetype IN ("pan:traffic","pan:threat")
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope portal_exposure_state firewall_platform
| where firewall_scope="scoped"
| where portal_exposure_state IN ("enabled","exposed","under_investigation")
| eval portal_indicator=if(
app IN ("captive-portal","user-id","auth-portal")
OR like(url,"%captive%")
OR like(url,"%user-id%")
OR like(url,"%portal%")
OR like(rule,"%User-ID%")
OR like(rule,"%Captive Portal%")
OR dest_port IN (443,6080,6081),
1,0
)
| where portal_indicator=1
| eval untrusted_source=if(src_zone IN ("untrust","internet","external"),1,0)
| lookup approved_portal_sources.csv src OUTPUT approved_portal_source
| lookup approved_scanner_sources.csv src OUTPUT approved_scanner_source
| where untrusted_source=1 AND isnull(approved_portal_source)
| where isnull(approved_scanner_source)
| eval event_stage="portal_activity"
| eval portal_time=_time
| rename src AS portal_src
| rename dest AS portal_dest
| rename app AS portal_app
| rename url AS portal_url
| rename rule AS portal_rule
| rename dest_port AS portal_dest_port
| rename src_zone AS portal_src_zone
| fields firewall_key portal_time portal_src portal_dest portal_app portal_url portal_rule portal_dest_port portal_src_zone event_stage
]
[
search index=pan_logs sourcetype="pan:system"
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope
| where firewall_scope="scoped"
| eval instability_indicator=if(
like(msg,"%crash%")
OR like(msg,"%restart%")
OR like(msg,"%fault%")
OR like(msg,"%failover%")
OR like(msg,"%service unavailable%")
OR like(msg,"%service failed%")
OR like(msg,"%management plane%")
OR like(msg,"%captive portal%")
OR like(msg,"%portal%"),
1,0
)
| where instability_indicator=1
| eval event_stage="instability"
| eval instability_time=_time
| rename eventtype AS instability_eventtype
| rename subtype AS instability_subtype
| rename severity AS instability_severity
| rename msg AS instability_message
| fields firewall_key instability_time instability_eventtype instability_subtype instability_severity instability_message event_stage
]
| stats
min(portal_time) AS first_portal_time
max(portal_time) AS last_portal_time
values(portal_src) AS portal_sources
values(portal_dest) AS portal_destinations
values(portal_app) AS portal_apps
values(portal_url) AS portal_urls
values(portal_rule) AS portal_rules
values(portal_dest_port) AS portal_destination_ports
values(portal_src_zone) AS portal_source_zones
min(instability_time) AS first_instability_time
max(instability_time) AS last_instability_time
values(instability_eventtype) AS instability_eventtypes
values(instability_subtype) AS instability_subtypes
values(instability_severity) AS instability_severities
values(instability_message) AS instability_messages
values(event_stage) AS event_stages
BY firewall_key
| where mvfind(event_stages,"portal_activity")>=0
AND mvfind(event_stages,"instability")>=0
AND first_instability_time > first_portal_time
AND first_instability_time <= first_portal_time + 3600
| lookup maintenance_windows.csv firewall_key OUTPUT maintenance_status maintenance_start maintenance_end
| where isnull(maintenance_status) OR maintenance_status!="approved"
| eval alert_title="Suspicious PAN-OS portal activity followed by firewall instability"
| eval severity="high"
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Rule Format
Splunk SPL correlation search requiring PAN-OS traffic, administrative audit, configuration-log, lookup, and field-normalization validation before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by administrative-control anomalies or configuration integrity changes.
· Identify probable post-interaction firewall control-plane activity that may indicate unauthorized administration, configuration tampering, visibility reduction, or traffic-enforcement change.
· Avoid dependence on CVE strings, static exploit artifacts, source reputation alone, or affected-version inventory alone.
· This rule does not confirm compromise without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious portal-directed traffic against a scoped PA-Series or VM-Series firewall from untrusted and unapproved sources.
· Require a same-firewall administrative or configuration event after the portal-directed activity within a defensible investigation window.
· Prioritize administrator login anomalies, account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, logging changes, policy changes, NAT changes, route changes, and management-setting changes.
· Increase priority when activity occurs outside approved maintenance, from unexpected administrator sources, or against firewalls with confirmed portal exposure.
· Treat exposure-only findings, normal commits, scheduled maintenance, and affected-version inventory as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS administrative audit logs.
· PAN-OS configuration logs.
· PAN-OS system logs where administrative events are recorded there.
· Firewall device identity.
· Timestamp.
· Source IP address.
· Destination IP address.
· Administrator username where available.
· Action, command, object, subtype, severity, and event description fields where available.
· Commit history.
· Configuration export records where available.
· Portal exposure context.
· Approved administrator source context.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate local Splunk indexes, sourcetypes, PAN-OS parser fields, CIM mappings, lookup names, and timestamp handling before deployment.
· Confirm that administrative and configuration events can be correlated to the same firewall identity as portal traffic.
· Use lookup flags for approved administrator sources, maintenance windows, scoped firewalls, approved portal sources, and approved scanners.
· Tune approved administrator source ranges, approved change windows, known automation, Panorama-driven commits, backup activity, scheduled exports, certificate renewal, and approved policy deployment workflows.
· Use affected-version inventory and exposure context as prioritization fields, not standalone alert conditions.
· Route alerts at higher priority when administrative-control or configuration changes are paired with device instability, visibility reduction, or outbound anomalies.
DRI Assessment
DRI
8.6 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by administrative-control or configuration integrity change.
· The rule remains useful if attackers change payload structure, source infrastructure, request timing, or visible exploit characteristics.
· The score is supported by direct correlation between exploit-facing activity and control-plane change behavior.
· The score is constrained by legitimate administrative overlap and dependency on administrative audit, configuration-log, and lookup quality.
TCR Assessment
Operational TCR
7.3 / 10
Full-Telemetry TCR
8.7 / 10
· Operational confidence depends on administrative audit logging, configuration-log fidelity, commit metadata, administrator identity fields, firewall identity consistency, and change-window context.
· Operational confidence is reduced where administrative events are incomplete, commits are frequent, automation activity is poorly baselined, or firewall identity fields are inconsistent.
· Full-telemetry confidence improves when Splunk receives PAN-OS traffic, system, administrative, configuration, identity-provider, privileged-access, change-management, and NDR telemetry.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction administrative or configuration behavior, not confirmed code execution.
· Legitimate administrator activity, automation, Panorama-driven changes, certificate renewal, backups, policy deployment, and approved maintenance may overlap with rule conditions.
· Field names and event descriptions vary by PAN-OS version, parser, sourcetype, and local normalization.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
`comment("Splunk SPL correlation search. Validate administrative/configuration sourcetypes, field names, lookups, and change-window logic before deployment.")`
| multisearch
[
search index=pan_logs sourcetype IN ("pan:traffic","pan:threat")
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope portal_exposure_state firewall_platform
| where firewall_scope="scoped"
| where portal_exposure_state IN ("enabled","exposed","under_investigation")
| eval portal_indicator=if(
app IN ("captive-portal","user-id","auth-portal")
OR like(url,"%captive%")
OR like(url,"%user-id%")
OR like(url,"%portal%")
OR like(rule,"%User-ID%")
OR like(rule,"%Captive Portal%")
OR dest_port IN (443,6080,6081),
1,0
)
| where portal_indicator=1
| eval untrusted_source=if(src_zone IN ("untrust","internet","external"),1,0)
| lookup approved_portal_sources.csv src OUTPUT approved_portal_source
| lookup approved_scanner_sources.csv src OUTPUT approved_scanner_source
| where untrusted_source=1 AND isnull(approved_portal_source)
| where isnull(approved_scanner_source)
| eval event_stage="portal_activity"
| eval portal_time=_time
| rename src AS portal_src
| rename dest AS portal_dest
| rename app AS portal_app
| rename url AS portal_url
| rename rule AS portal_rule
| rename dest_port AS portal_dest_port
| rename src_zone AS portal_src_zone
| fields firewall_key portal_time portal_src portal_dest portal_app portal_url portal_rule portal_dest_port portal_src_zone event_stage
]
[
search index=pan_logs sourcetype IN ("pan:config","pan:system")
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope
| where firewall_scope="scoped"
| eval control_indicator=if(
like(msg,"%commit%")
OR like(msg,"%configuration export%")
OR like(msg,"%admin login%")
OR like(msg,"%administrator login%")
OR like(msg,"%account created%")
OR like(msg,"%account modified%")
OR like(msg,"%privilege%")
OR like(msg,"%authentication profile%")
OR like(msg,"%certificate%")
OR like(msg,"%logging%")
OR like(msg,"%syslog%")
OR like(msg,"%security policy%")
OR like(msg,"%NAT%")
OR like(msg,"%route%")
OR like(msg,"%management setting%"),
1,0
)
| where control_indicator=1
| lookup approved_admin_sources.csv src_ip OUTPUT approved_admin_source
| eval event_stage="admin_or_config"
| eval control_time=_time
| rename user AS control_user
| rename admin AS control_admin
| rename src_ip AS control_src
| rename action AS control_action
| rename cmd AS control_command
| rename object AS control_object
| rename subtype AS control_subtype
| rename severity AS control_severity
| rename msg AS control_message
| fields firewall_key control_time control_user control_admin control_src approved_admin_source control_action control_command control_object control_subtype control_severity control_message event_stage
]
| stats
min(portal_time) AS first_portal_time
max(portal_time) AS last_portal_time
values(portal_src) AS portal_sources
values(portal_dest) AS portal_destinations
values(portal_app) AS portal_apps
values(portal_url) AS portal_urls
values(portal_rule) AS portal_rules
values(portal_dest_port) AS portal_destination_ports
values(portal_src_zone) AS portal_source_zones
min(control_time) AS first_control_time
max(control_time) AS last_control_time
values(control_user) AS control_users
values(control_admin) AS control_admins
values(control_src) AS control_sources
values(approved_admin_source) AS approved_admin_flags
values(control_action) AS control_actions
values(control_command) AS control_commands
values(control_object) AS changed_objects
values(control_subtype) AS control_subtypes
values(control_severity) AS control_severities
values(control_message) AS control_messages
values(event_stage) AS event_stages
BY firewall_key
| where mvfind(event_stages,"portal_activity")>=0
AND mvfind(event_stages,"admin_or_config")>=0
AND first_control_time > first_portal_time
AND first_control_time <= first_portal_time + 3600
| lookup maintenance_windows.csv firewall_key OUTPUT maintenance_status
| where (mvfind(approved_admin_flags,"true")<0 OR isnull(approved_admin_flags))
OR (isnull(maintenance_status) OR maintenance_status!="approved")
| eval alert_title="Suspicious PAN-OS portal activity followed by administrative-control or configuration anomaly"
| eval severity="high"
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Rule Format
Splunk SPL correlation search requiring PAN-OS traffic, configuration, system, network-flow, DNS, or proxy telemetry validation before deployment.
Detection Purpose
· Detect suspicious portal-directed activity followed by firewall-originated outbound anomalies or visibility-impacting logging and monitoring changes.
· Identify probable post-interaction behavior where a firewall begins communicating with unusual external infrastructure or where logging visibility is reduced after suspicious portal activity.
· Avoid reliance on static indicators, exploit strings, proof-of-concept artifacts, source reputation alone, or affected-version inventory alone.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious portal-directed traffic against a scoped PA-Series or VM-Series firewall from untrusted and unapproved sources.
· Correlate that event with same-firewall outbound communication to newly observed, rare, unexplained, or unapproved destinations within a defensible investigation window.
· Require outbound-anomaly logic to represent firewall-originated communication, not ordinary through-firewall transit traffic.
· Alternatively, correlate that event with logging, forwarding, audit, monitoring, or visibility-control changes on the same firewall.
· Prioritize outbound destinations inconsistent with expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, or management baselines.
· Treat standalone outbound anomalies, expected vendor communication, approved logging changes, and exposure-only findings as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS configuration logs.
· PAN-OS system logs.
· Firewall-originated outbound traffic records.
· DNS telemetry where available.
· TLS metadata where available.
· Proxy or egress telemetry where available.
· Firewall device identity.
· Timestamp.
· Source and destination IP address.
· Destination domain where available.
· Destination port and protocol.
· Session duration.
· Byte and packet volume.
· Logging, forwarding, audit, monitoring, or visibility-control configuration fields.
· Expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destination baselines.
Engineering Implementation Instructions
· Validate local Splunk indexes, sourcetypes, network-flow mappings, PAN-OS fields, DNS fields, TLS fields, destination-baseline lookups, and firewall-originated traffic indicators before deployment.
· Confirm that firewall-originated outbound communication can be distinguished from through-firewall transit traffic.
· Scope outbound logic to management-plane, control-plane, or firewall-originated traffic where available.
· Use firewall IP, firewall asset identity, traffic-role fields, interface context, or platform-specific flow direction fields to validate firewall-originated communication.
· Baseline expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destinations before enabling the rule.
· Map visibility-reduction events for log forwarding, syslog destination changes, threat logging, traffic logging, administrative audit logging, monitoring profiles, and logging policy changes.
· Require same-firewall temporal correlation between suspicious portal activity and outbound anomaly or visibility reduction.
· Suppress known vendor communication and approved visibility changes only when destination, device, timing, and change context are validated.
DRI Assessment
DRI
8.4 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by firewall-originated outbound anomaly or visibility reduction.
· The rule remains useful if attackers vary source infrastructure, payload structure, request timing, or follow-on communication destinations.
· The score is supported by correlation between exploit-facing activity and post-interaction egress or visibility-control behavior.
· The score is constrained by the need to distinguish firewall-originated traffic from transit traffic and by dependency on outbound baselines.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.5 / 10
· Operational confidence depends on firewall-originated traffic visibility, destination baselining, DNS or TLS enrichment, PAN-OS configuration logging, and consistent firewall identity fields.
· Operational confidence is reduced where outbound firewall traffic is mixed with transit traffic or expected vendor destinations are not baselined.
· Full-telemetry confidence improves when Splunk receives PAN-OS traffic, system, configuration, DNS, proxy, NDR, and egress telemetry with reliable device identity and destination context.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction egress or visibility reduction, not confirmed unauthorized code execution.
· Normal update, licensing, logging, telemetry, support, DNS, NTP, monitoring, and management traffic may overlap with outbound anomaly logic if baselines are incomplete.
· Approved logging changes, monitoring updates, syslog migrations, and maintenance activity may overlap with visibility-reduction logic.
· Encrypted traffic may limit destination or session detail.
· Confirmation requires correlation with firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
`comment("Splunk SPL correlation search. Validate firewall-originated egress visibility, baseline lookups, traffic-role fields, stage-specific field names, and visibility-change fields before deployment.")`
| multisearch
[
search index=pan_logs sourcetype IN ("pan:traffic","pan:threat")
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope portal_exposure_state firewall_platform
| where firewall_scope="scoped"
| where portal_exposure_state IN ("enabled","exposed","under_investigation")
| eval portal_indicator=if(
app IN ("captive-portal","user-id","auth-portal")
OR like(url,"%captive%")
OR like(url,"%user-id%")
OR like(url,"%portal%")
OR like(rule,"%User-ID%")
OR like(rule,"%Captive Portal%")
OR dest_port IN (443,6080,6081),
1,0
)
| where portal_indicator=1
| eval untrusted_source=if(src_zone IN ("untrust","internet","external"),1,0)
| lookup approved_portal_sources.csv src OUTPUT approved_portal_source
| lookup approved_scanner_sources.csv src OUTPUT approved_scanner_source
| where untrusted_source=1 AND isnull(approved_portal_source)
| where isnull(approved_scanner_source)
| eval event_stage="portal_activity"
| eval portal_time=_time
| rename src AS portal_src
| rename dest AS portal_dest
| rename app AS portal_app
| rename url AS portal_url
| rename rule AS portal_rule
| rename dest_port AS portal_dest_port
| rename src_zone AS portal_src_zone
| fields firewall_key portal_time portal_src portal_dest portal_app portal_url portal_rule portal_dest_port portal_src_zone event_stage
]
[
search index=network sourcetype IN ("pan:traffic","netflow","stream:tcp","dns","proxy")
| lookup scoped_panos_firewalls.csv firewall_ip AS src OUTPUT firewall_scope AS egress_firewall_scope firewall_key AS egress_firewall_key
| where egress_firewall_scope="scoped"
| eval firewall_key=coalesce(egress_firewall_key,src)
| eval firewall_originated=1
| lookup expected_firewall_vendor_destinations.csv dest OUTPUT expected_vendor_destination
| lookup approved_logging_telemetry_destinations.csv dest OUTPUT approved_logging_destination
| lookup approved_management_destinations.csv dest OUTPUT approved_management_destination
| where isnull(expected_vendor_destination)
AND isnull(approved_logging_destination)
AND isnull(approved_management_destination)
| eval event_stage="outbound_anomaly"
| eval outbound_time=_time
| rename src AS outbound_src
| rename dest AS outbound_dest
| rename dest_port AS outbound_dest_port
| rename proto AS outbound_proto
| rename query AS outbound_dns_query
| rename domain AS outbound_domain
| rename bytes AS outbound_bytes
| rename packets AS outbound_packets
| rename duration AS outbound_duration
| fields firewall_key outbound_time outbound_src outbound_dest outbound_dest_port outbound_proto outbound_dns_query outbound_domain outbound_bytes outbound_packets outbound_duration firewall_originated event_stage
]
[
search index=pan_logs sourcetype IN ("pan:config","pan:system")
| eval firewall_key=coalesce(device_name,host,dvc,dest)
| lookup scoped_panos_firewalls.csv firewall_key OUTPUT firewall_scope
| where firewall_scope="scoped"
| eval visibility_indicator=if(
like(msg,"%logging%")
OR like(msg,"%syslog%")
OR like(msg,"%log forwarding%")
OR like(msg,"%threat log%")
OR like(msg,"%traffic log%")
OR like(msg,"%audit log%")
OR like(msg,"%monitoring%")
OR like(msg,"%visibility%"),
1,0
)
| where visibility_indicator=1
| eval event_stage="visibility_reduction"
| eval visibility_time=_time
| rename user AS visibility_user
| rename action AS visibility_action
| rename object AS visibility_object
| rename subtype AS visibility_subtype
| rename severity AS visibility_severity
| rename msg AS visibility_message
| fields firewall_key visibility_time visibility_user visibility_action visibility_object visibility_subtype visibility_severity visibility_message event_stage
]
| stats
min(portal_time) AS first_portal_time
max(portal_time) AS last_portal_time
values(portal_src) AS portal_sources
values(portal_dest) AS portal_destinations
values(portal_app) AS portal_apps
values(portal_url) AS portal_urls
values(portal_rule) AS portal_rules
values(portal_dest_port) AS portal_destination_ports
values(portal_src_zone) AS portal_source_zones
min(outbound_time) AS first_outbound_time
max(outbound_time) AS last_outbound_time
values(outbound_src) AS outbound_sources
values(outbound_dest) AS outbound_destinations
values(outbound_dest_port) AS outbound_ports
values(outbound_proto) AS outbound_protocols
values(outbound_dns_query) AS outbound_dns_queries
values(outbound_domain) AS outbound_domains
values(outbound_bytes) AS outbound_byte_counts
values(outbound_packets) AS outbound_packet_counts
values(outbound_duration) AS outbound_durations
values(firewall_originated) AS firewall_originated_flags
min(visibility_time) AS first_visibility_time
max(visibility_time) AS last_visibility_time
values(visibility_user) AS visibility_users
values(visibility_action) AS visibility_actions
values(visibility_object) AS visibility_objects
values(visibility_subtype) AS visibility_subtypes
values(visibility_severity) AS visibility_severities
values(visibility_message) AS visibility_messages
values(event_stage) AS event_stages
BY firewall_key
| where mvfind(event_stages,"portal_activity")>=0
AND (
mvfind(event_stages,"outbound_anomaly")>=0
OR mvfind(event_stages,"visibility_reduction")>=0
)
AND (
(first_outbound_time > first_portal_time AND first_outbound_time <= first_portal_time + 3600 AND mvfind(firewall_originated_flags,"1")>=0)
OR
(first_visibility_time > first_portal_time AND first_visibility_time <= first_portal_time + 3600)
)
| lookup maintenance_windows.csv firewall_key OUTPUT maintenance_status
| where isnull(maintenance_status) OR maintenance_status!="approved"
| eval alert_title="Suspicious PAN-OS portal activity followed by firewall-originated outbound anomaly or visibility reduction"
| eval severity="high"
Elastic
Detection Viability Assessment
Elastic has three rules for this EXP report.
Elastic is viable because it can correlate PAN-OS traffic logs, threat logs, system logs, administrative logs, configuration logs, network telemetry, DNS data, asset context, and exception-list context when records are normalized into Elastic Common Schema or consistently mapped custom fields.
Elastic is strongest when used for sequence-based detection where suspicious User-ID Authentication Portal or Captive Portal activity is followed by same-firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, or firewall-originated outbound anomalies.
Elastic rules must not depend on static exploit strings, public proof-of-concept artifacts, attacker IP addresses, source reputation alone, affected-version inventory alone, generic firewall access, or packet payload visibility.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Rule Format
Elastic EQL sequence rule requiring ECS mapping validation, PAN-OS integration validation, scoped firewall asset inventory, Elastic exception-list validation, enrichment-field validation, and correlation-window tuning before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by firewall crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Identify probable exploitation patterns where exploit-facing activity is followed by device-health impact.
· Avoid reliance on payload visibility, exploit strings, proof-of-concept artifacts, source reputation alone, or affected-version inventory alone.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify PAN-OS traffic, threat, or portal events where a scoped PA-Series or VM-Series firewall receives portal-directed activity from untrusted and unapproved sources.
· Require the destination firewall to have User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Treat destination-port matching as a fallback portal indicator only when the destination asset is a scoped PAN-OS firewall and portal exposure context is present.
· Correlate the portal-directed event with a same-firewall system, service, health, HA, crash, restart, fault, or portal-interruption event after the portal-directed activity within a defensible investigation window.
· Increase priority when the portal is internet-reachable, the source is not approved, the firewall is affected or under investigation, and the instability event is not explained by approved maintenance.
· Treat exposure-only findings, affected-version inventory, generic firewall access, and source reputation as enrichment context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS threat logs where available.
· PAN-OS system logs.
· PAN-OS HA, health, or service status logs where available.
· Elastic asset context for scoped PA-Series and VM-Series firewalls.
· Firewall device identity.
· Source IP address.
· Destination IP address.
· Source zone, destination zone, interface, or exposure context where available.
· Application, service, URL, rule name, destination port, or portal indicator where available.
· System event type, severity, subtype, and message.
· Timestamp.
· Approved scanner, approved portal-source, and approved maintenance-window context.
Engineering Implementation Instructions
· Validate Elastic index names, PAN-OS integration fields, ECS mappings, custom field mappings, timestamp normalization, and event categorization before deployment.
· Implement placeholders such as scoped firewalls, approved sources, approved scanners, and maintenance windows as Elastic exception lists, value lists, enrichment indices, or locally mapped fields.
· Confirm that PAN-OS traffic, threat, and system logs are ingested with consistent firewall identity fields.
· Scope the rule to PA-Series and VM-Series firewalls with User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Validate local fields for firewall identity, source IP, destination IP, application, service, URL path, rule name, source zone, destination zone, destination port, event action, event category, event type, severity, and message.
· Tune the sequence window based on log latency, maintenance frequency, portal exposure, and SOC triage requirements.
· Suppress approved maintenance only when device identity, time window, event type, and change context are validated.
DRI Assessment
DRI
8.7 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall instability rather than exploit artifacts.
· The rule remains useful if attackers change source infrastructure, request timing, visible request characteristics, or payload structure.
· The score is supported by same-device temporal correlation between exploit-facing activity and device-health impact.
· The score is constrained by dependence on PAN-OS field normalization, portal exposure context, system-log fidelity, and maintenance-window tuning.
TCR Assessment
Operational TCR
7.4 / 10
Full-Telemetry TCR
8.8 / 10
· Operational confidence depends on PAN-OS log quality, ECS mapping quality, consistent firewall identity, portal-indicator fidelity, source-zone context, exposure context, and maintenance-window validation.
· Operational confidence is reduced where portal indicators are incomplete, system logs are not retained, firewall identity fields are inconsistent, or maintenance activity is poorly baselined.
· Full-telemetry confidence improves when Elastic receives PAN-OS traffic, threat, system, HA, administrative, configuration, DNS, endpoint, and NDR telemetry with consistent timestamps and device identity.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious portal activity followed by firewall instability, not confirmed unauthorized code execution.
· Legitimate maintenance, upgrades, failover testing, service restarts, and approved operational activity may overlap with instability signals.
· Portal indicators may vary by PAN-OS logging configuration, Elastic integration version, parser quality, and custom field mapping.
· Low-volume exploitation may not produce strong portal-traffic anomalies.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
/* Elastic EQL sequence rule.
Validate index names, ECS/custom field mappings, asset tags, exception lists,
enrichment fields, and sequence window before deployment.
Placeholder guidance:
- SCOPED_PANOS_FIREWALLS should be implemented as an Elastic value list,
exception list, asset enrichment, or locally mapped firewall inventory field.
- APPROVED_PORTAL_SOURCE_RANGES and APPROVED_SCANNER_SOURCE_RANGES should be
implemented as Elastic exception lists or enrichment-backed value lists.
- Portal port matching is fallback logic and should be used only with scoped
firewall identity and portal exposure context.
*/
sequence by observer.id with maxspan=1h
[network where
event.dataset in ("panw.panos", "panw.panos.traffic", "panw.panos.threat") and
observer.vendor == "Palo Alto Networks" and
observer.product in ("PAN-OS", "PA-Series", "VM-Series") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation") and
(
panw.panos.application in ("captive-portal", "user-id", "auth-portal") or
url.path : ("*captive*", "*user-id*", "*portal*") or
rule.name : ("*User-ID*", "*Captive Portal*", "*Authentication Portal*") or
(
destination.port in (443, 6080, 6081) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation")
)
) and
source.zone in ("untrust", "internet", "external") and
not source.ip in (APPROVED_PORTAL_SOURCE_RANGES) and
not source.ip in (APPROVED_SCANNER_SOURCE_RANGES)
]
[any where
event.dataset in ("panw.panos", "panw.panos.system") and
observer.vendor == "Palo Alto Networks" and
observer.product in ("PAN-OS", "PA-Series", "VM-Series") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
message : (
"*crash*",
"*restart*",
"*fault*",
"*failover*",
"*service unavailable*",
"*service failed*",
"*management plane*",
"*captive portal*",
"*portal*"
) and
not message : (
"*scheduled maintenance*",
"*approved maintenance*",
"*software update*",
"*content update*",
"*license update*"
)
]
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Rule Format
Elastic EQL sequence rule requiring PAN-OS traffic, administrative audit, configuration-log, ECS mapping, exception-list, and enrichment-field validation before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by administrative-control anomalies or configuration integrity changes.
· Identify probable post-interaction firewall control-plane activity that may indicate unauthorized administration, configuration tampering, visibility reduction, or traffic-enforcement change.
· Avoid dependence on CVE strings, static exploit artifacts, source reputation alone, affected-version inventory alone, or generic firewall access.
· This rule does not confirm compromise without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious portal-directed traffic against a scoped PA-Series or VM-Series firewall from untrusted and unapproved sources.
· Require a same-firewall administrative or configuration event after the portal-directed activity within a defensible investigation window.
· Prioritize administrator login anomalies, account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, logging changes, policy changes, NAT changes, route changes, and management-setting changes.
· Do not drop high-value administrative or configuration events solely because the administrator source IP is missing, inconsistently parsed, or normalized into a different field.
· Increase priority when activity occurs outside approved maintenance, from unexpected administrator sources, or against firewalls with confirmed portal exposure.
· Treat exposure-only findings, normal commits, scheduled maintenance, and affected-version inventory as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS threat logs where available.
· PAN-OS administrative audit logs.
· PAN-OS configuration logs.
· PAN-OS system logs where administrative events are recorded there.
· Firewall device identity.
· Timestamp.
· Source IP address where available.
· Destination IP address.
· Administrator username where available.
· Action, command, object, subtype, severity, and event message fields where available.
· Commit history.
· Configuration export records where available.
· Portal exposure context.
· Approved administrator source context.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate Elastic index names, PAN-OS integration fields, ECS mappings, custom field mappings, exception lists, enrichment fields, and timestamp handling before deployment.
· Implement approved administrator sources as exception lists, value lists, enrichment indices, or locally mapped fields, but do not require source IP to be present for every administrative or configuration event.
· Confirm that administrative and configuration events can be correlated to the same firewall identity as portal traffic.
· Map local event fields for administrator login, account change, privilege change, commit, configuration export, authentication-profile change, certificate change, logging change, policy change, NAT change, route change, and management-setting change.
· Tune known automation, Panorama-driven commits, backup activity, scheduled exports, certificate renewal, policy deployment workflows, and approved maintenance.
· Use affected-version inventory and exposure context as prioritization fields, not standalone alert conditions.
· Route alerts at higher priority when administrative-control or configuration changes are paired with device instability, visibility reduction, or outbound anomalies.
DRI Assessment
DRI
8.6 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by administrative-control or configuration integrity change.
· The rule remains useful if attackers change source infrastructure, payload structure, request timing, or visible exploit characteristics.
· The score is supported by same-firewall temporal correlation between exploit-facing activity and control-plane change behavior.
· The score is constrained by legitimate administrative overlap and dependency on administrative audit, configuration-log, and field-normalization quality.
TCR Assessment
Operational TCR
7.2 / 10
Full-Telemetry TCR
8.7 / 10
· Operational confidence depends on administrative audit logging, configuration-log fidelity, commit metadata, administrator identity fields, firewall identity consistency, ECS mapping quality, and change-window context.
· Operational confidence is reduced where administrative events are incomplete, commits are frequent, automation activity is poorly baselined, or firewall identity fields are inconsistent.
· Full-telemetry confidence improves when Elastic receives PAN-OS traffic, system, administrative, configuration, identity-provider, privileged-access, change-management, DNS, and NDR telemetry.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction administrative or configuration behavior, not confirmed code execution.
· Legitimate administrator activity, automation, Panorama-driven changes, certificate renewal, backups, policy deployment, and approved maintenance may overlap with rule conditions.
· Field names and event descriptions vary by PAN-OS version, Elastic integration version, parser quality, and local normalization.
· Administrator source IP may be missing, inconsistently parsed, or stored in a custom field depending on log source and parser behavior.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
/* Elastic EQL sequence rule.
Validate PAN-OS admin/config datasets, ECS/custom mappings, exception lists,
enrichment fields, and sequence window before deployment.
Placeholder guidance:
- SCOPED_PANOS_FIREWALLS should be an Elastic value list, exception list,
asset enrichment, or locally mapped firewall inventory field.
- APPROVED_PORTAL_SOURCE_RANGES, APPROVED_SCANNER_SOURCE_RANGES, and
APPROVED_ADMIN_SOURCE_RANGES should be Elastic exception lists or
enrichment-backed value lists.
- Admin/config events should not be suppressed solely because source.ip is
absent; missing source.ip should remain detectable when behavior is otherwise
suspicious.
*/
sequence by observer.id with maxspan=1h
[network where
event.dataset in ("panw.panos", "panw.panos.traffic", "panw.panos.threat") and
observer.vendor == "Palo Alto Networks" and
observer.product in ("PAN-OS", "PA-Series", "VM-Series") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation") and
(
panw.panos.application in ("captive-portal", "user-id", "auth-portal") or
url.path : ("*captive*", "*user-id*", "*portal*") or
rule.name : ("*User-ID*", "*Captive Portal*", "*Authentication Portal*") or
(
destination.port in (443, 6080, 6081) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation")
)
) and
source.zone in ("untrust", "internet", "external") and
not source.ip in (APPROVED_PORTAL_SOURCE_RANGES) and
not source.ip in (APPROVED_SCANNER_SOURCE_RANGES)
]
[any where
event.dataset in ("panw.panos", "panw.panos.system", "panw.panos.config") and
observer.vendor == "Palo Alto Networks" and
observer.product in ("PAN-OS", "PA-Series", "VM-Series") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
message : (
"*commit*",
"*configuration export*",
"*admin login*",
"*administrator login*",
"*account created*",
"*account modified*",
"*privilege*",
"*authentication profile*",
"*certificate*",
"*logging*",
"*syslog*",
"*security policy*",
"*NAT*",
"*route*",
"*management setting*"
) and
(
source.ip == null or
not source.ip in (APPROVED_ADMIN_SOURCE_RANGES)
) and
not message : (
"*scheduled maintenance*",
"*approved commit*",
"*approved change*",
"*content update*",
"*license update*"
)
]
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Rule Format
Elastic EQL sequence rule requiring PAN-OS traffic, configuration, system, network-flow, DNS, TLS, proxy, ECS mapping, exception-list, and firewall-originated traffic validation before deployment.
Detection Purpose
· Detect suspicious portal-directed activity followed by firewall-originated outbound anomalies or visibility-impacting logging and monitoring changes.
· Identify probable post-interaction behavior where a firewall begins communicating with unusual external infrastructure or where logging visibility is reduced after suspicious portal activity.
· Avoid reliance on static indicators, exploit strings, proof-of-concept artifacts, source reputation alone, affected-version inventory alone, or packet payload visibility.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious portal-directed traffic against a scoped PA-Series or VM-Series firewall from untrusted and unapproved sources.
· Correlate that event with same-firewall outbound communication to newly observed, rare, unexplained, or unapproved destinations within a defensible investigation window.
· Require outbound-anomaly logic to represent firewall-originated communication, not ordinary through-firewall transit traffic.
· Tie firewall-originated outbound traffic to the same firewall asset identity through observer identity, firewall source IP, local asset enrichment, or a validated traffic-role field.
· Alternatively, correlate suspicious portal activity with logging, forwarding, audit, monitoring, or visibility-control changes on the same firewall observer.
· Prioritize outbound destinations inconsistent with expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, or management baselines.
· Treat standalone outbound anomalies, expected vendor communication, approved logging changes, and exposure-only findings as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS configuration logs.
· PAN-OS system logs.
· Firewall-originated outbound traffic records.
· DNS telemetry where available.
· TLS metadata where available.
· Proxy or egress telemetry where available.
· Firewall device identity.
· Firewall source IP mapping.
· Traffic-role or firewall-originated indicator where available.
· Timestamp.
· Source and destination IP address.
· Destination domain where available.
· Destination port and protocol.
· Session duration.
· Byte and packet volume.
· Logging, forwarding, audit, monitoring, or visibility-control configuration fields.
· Expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destination baselines.
Engineering Implementation Instructions
· Validate Elastic index names, PAN-OS integration fields, network-flow mappings, ECS fields, DNS fields, TLS fields, proxy fields, exception lists, destination-baseline indices, and firewall-originated traffic indicators before deployment.
· Implement expected destinations, rare destinations, scoped firewall IPs, approved management destinations, and approved logging or telemetry destinations as Elastic exception lists, value lists, enrichment indices, or locally mapped fields.
· Confirm that firewall-originated outbound communication can be distinguished from through-firewall transit traffic.
· Scope outbound logic to management-plane, control-plane, or firewall-originated traffic where available.
· Use firewall IP, firewall asset identity, traffic-role fields, interface context, observer context, or flow direction fields to validate firewall-originated communication.
· Validate that the second sequence event represents either outbound traffic from the same firewall asset or a visibility-reduction event on the same firewall observer.
· Baseline expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destinations before enabling the rule.
· Map visibility-reduction events for log forwarding, syslog destination changes, threat logging, traffic logging, administrative audit logging, monitoring profiles, and logging policy changes.
· Require same-firewall temporal correlation between suspicious portal activity and outbound anomaly or visibility reduction.
· Suppress known vendor communication and approved visibility changes only when destination, device, timing, and change context are validated.
DRI Assessment
DRI
8.4 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by firewall-originated outbound anomaly or visibility reduction.
· The rule remains useful if attackers vary source infrastructure, payload structure, request timing, or follow-on communication destinations.
· The score is supported by same-firewall temporal correlation between exploit-facing activity and post-interaction egress or visibility-control behavior.
· The score is constrained by the need to distinguish firewall-originated traffic from transit traffic and by dependency on outbound baselines.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.5 / 10
· Operational confidence depends on firewall-originated traffic visibility, destination baselining, DNS or TLS enrichment, PAN-OS configuration logging, ECS mapping quality, firewall source-IP mapping, traffic-role interpretation, and consistent firewall identity fields.
· Operational confidence is reduced where outbound firewall traffic is mixed with transit traffic, expected vendor destinations are not baselined, or traffic-role fields are unavailable.
· Full-telemetry confidence improves when Elastic receives PAN-OS traffic, system, configuration, DNS, proxy, TLS, NDR, and egress telemetry with reliable device identity and destination context.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction egress or visibility reduction, not confirmed unauthorized code execution.
· Normal update, licensing, logging, telemetry, support, DNS, NTP, monitoring, and management traffic may overlap with outbound anomaly logic if baselines are incomplete.
· Approved logging changes, monitoring updates, syslog migrations, and maintenance activity may overlap with visibility-reduction logic.
· Encrypted traffic may limit destination or session detail.
· Firewall-originated traffic may be difficult to distinguish from transit traffic in environments without reliable source-IP mapping, observer context, interface context, or traffic-role fields.
· Confirmation requires correlation with firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
/* Elastic EQL sequence rule.
Validate firewall-originated egress visibility, ECS/custom field mappings,
destination-baseline exception lists, visibility-change fields, traffic-role
fields, observer identity, firewall source-IP mapping, and sequence window
before deployment.
Placeholder guidance:
- SCOPED_PANOS_FIREWALLS and SCOPED_PANOS_FIREWALL_IPS should be Elastic value
lists, exception lists, asset enrichments, or locally mapped fields.
- EXPECTED_FIREWALL_VENDOR_DESTINATIONS, EXPECTED_FIREWALL_VENDOR_DOMAINS,
APPROVED_LOGGING_TELEMETRY_DESTINATIONS, APPROVED_MANAGEMENT_DESTINATIONS,
NEW_OR_RARE_DESTINATIONS, NEW_OR_RARE_DOMAINS, and RARE_DESTINATION_ASNS
should be implemented as exception lists, enrichments, transforms, ML-backed
anomaly lists, or locally maintained value lists.
- The outbound branch must represent firewall-originated traffic from the same
firewall asset, not through-firewall transit traffic.
*/
sequence by observer.id with maxspan=1h
[network where
event.dataset in ("panw.panos", "panw.panos.traffic", "panw.panos.threat") and
observer.vendor == "Palo Alto Networks" and
observer.product in ("PAN-OS", "PA-Series", "VM-Series") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation") and
(
panw.panos.application in ("captive-portal", "user-id", "auth-portal") or
url.path : ("*captive*", "*user-id*", "*portal*") or
rule.name : ("*User-ID*", "*Captive Portal*", "*Authentication Portal*") or
(
destination.port in (443, 6080, 6081) and
panw.panos.portal_exposure_state in ("enabled", "exposed", "under_investigation")
)
) and
source.zone in ("untrust", "internet", "external") and
not source.ip in (APPROVED_PORTAL_SOURCE_RANGES) and
not source.ip in (APPROVED_SCANNER_SOURCE_RANGES)
]
[any where
(
(
event.category == "network" and
observer.id in (SCOPED_PANOS_FIREWALLS) and
source.ip in (SCOPED_PANOS_FIREWALL_IPS) and
network.direction == "outbound" and
panw.panos.traffic_role == "firewall_originated" and
not destination.ip in (EXPECTED_FIREWALL_VENDOR_DESTINATIONS) and
not destination.domain in (EXPECTED_FIREWALL_VENDOR_DOMAINS) and
not destination.ip in (APPROVED_LOGGING_TELEMETRY_DESTINATIONS) and
not destination.ip in (APPROVED_MANAGEMENT_DESTINATIONS) and
(
destination.ip in (NEW_OR_RARE_DESTINATIONS) or
destination.domain in (NEW_OR_RARE_DOMAINS) or
destination.as.number in (RARE_DESTINATION_ASNS) or
destination.port not in (EXPECTED_FIREWALL_EGRESS_PORTS)
)
)
or
(
event.dataset in ("panw.panos", "panw.panos.config", "panw.panos.system") and
observer.id in (SCOPED_PANOS_FIREWALLS) and
message : (
"*logging*",
"*syslog*",
"*log forwarding*",
"*threat log*",
"*traffic log*",
"*audit log*",
"*monitoring*",
"*visibility*"
) and
not message : (
"*scheduled maintenance*",
"*approved change*",
"*approved commit*"
)
)
)
]
QRadar
Detection Viability Assessment
QRadar has three rules for this EXP report.
QRadar is viable because it can correlate PAN-OS events, QRadar flows, asset context, reference sets, building blocks, custom properties, and CRE rule logic across a defensible investigation window.
QRadar should implement these detections as CRE rules supported by building blocks. AQL should be treated as validation, hunting, and rule-support logic, not as the primary replacement for CRE sequencing.
QRadar rules must not depend on static exploit strings, public proof-of-concept artifacts, attacker IP addresses, source reputation alone, affected-version inventory alone, generic firewall access, or packet payload visibility.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Rule Format
QRadar CRE rule using building-block correlation, supported by AQL validation patterns after PAN-OS DSM, custom property, reference set, and CRE timing validation.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by firewall crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Identify probable exploitation patterns where exploit-facing activity is followed by same-firewall device-health impact.
· Avoid reliance on payload visibility, unvalidated exploit strings, public proof-of-concept artifacts, source reputation alone, or affected-version inventory alone.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Create a portal-activity building block for PAN-OS events where scoped PA-Series or VM-Series firewalls receive User-ID Authentication Portal or Captive Portal activity from untrusted and unapproved sources.
· Create an instability building block for same-firewall PAN-OS system, HA, service, health, crash, restart, fault, portal-interruption, or management-plane instability events.
· Trigger the CRE rule when the instability building block fires on the same firewall after the portal-activity building block within the investigation window.
· Treat destination-port matching as fallback portal logic only when the firewall is scoped and portal exposure context is present.
· Treat exposure-only findings, affected-version inventory, generic firewall access, and source reputation as enrichment context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic events.
· PAN-OS threat events where available.
· PAN-OS system events.
· PAN-OS HA, health, or service status events where available.
· QRadar asset context for scoped PA-Series and VM-Series firewalls.
· Firewall identity or device name.
· Source IP address.
· Destination IP address.
· Source zone, destination zone, interface, or exposure context where available.
· Application, service, URL, rule name, destination port, or portal indicator where available.
· Event name, QID, category, severity, and payload message.
· Timestamp.
· Reference sets for scoped firewalls, approved scanner sources, approved portal sources, portal exposure state, and approved maintenance windows.
Engineering Implementation Instructions
· Validate PAN-OS DSM parsing, custom properties, QIDs, log source identifiers, event names, normalized fields, and timestamps before deployment.
· Implement scoped firewalls, approved portal sources, approved scanner sources, portal exposure state, and maintenance windows as QRadar reference sets or building blocks.
· Create a building block for suspicious PAN-OS portal activity using scoped firewall identity, portal exposure state, portal indicators, untrusted source context, and approved-source exclusions.
· Create a building block for PAN-OS firewall instability using validated QIDs, event names, categories, custom properties, or payload terms for crash, restart, fault, failover, portal interruption, service degradation, and management-plane instability.
· Configure the CRE rule to require same-firewall correlation between the portal-activity building block and the subsequent instability building block.
· Tune the CRE time window based on event latency, portal exposure, maintenance frequency, and SOC triage requirements.
· Suppress approved maintenance only when device identity, event type, time window, and change context are validated.
DRI Assessment
DRI
8.6 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall instability rather than exploit artifacts.
· The rule remains useful if attackers change source infrastructure, request timing, visible request characteristics, or payload structure.
· The score is supported by same-firewall temporal correlation between exploit-facing activity and device-health impact.
· The score is constrained by dependence on PAN-OS DSM quality, custom property availability, portal exposure context, system-event fidelity, and maintenance-window tuning.
TCR Assessment
Operational TCR
7.3 / 10
Full-Telemetry TCR
8.6 / 10
· Operational confidence depends on PAN-OS event quality, DSM parsing quality, custom property fidelity, consistent firewall identity, portal-indicator quality, source-zone context, exposure context, and maintenance-window validation.
· Operational confidence is reduced where portal indicators are incomplete, system events are not retained, firewall identity fields are inconsistent, or maintenance activity is poorly baselined.
· Full-telemetry confidence improves when QRadar receives PAN-OS traffic, threat, system, HA, administrative, configuration, DNS, flow, and NDR telemetry with consistent timestamps and device identity.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious portal activity followed by firewall instability, not confirmed unauthorized code execution.
· Legitimate maintenance, upgrades, failover testing, service restarts, and approved operational activity may overlap with instability signals.
· Portal indicators may vary by PAN-OS logging configuration, QRadar DSM version, custom property quality, and local normalization.
· AQL support patterns are validation aids and should not replace CRE same-firewall temporal correlation.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
-- QRadar AQL support pattern for Building Block 1.
-- Use this to validate suspicious PAN-OS portal activity candidates.
-- CRE correlation should be implemented with QRadar building blocks and time-window logic.
SELECT
"firewall_identity",
"source_ip",
"destination_ip",
"application",
"url_path",
"rule_name",
"destination_port",
"source_zone",
"qidname",
"payload",
STARTTIME
FROM events
WHERE
"log_source_type" ILIKE '%Palo Alto%'
AND "firewall_identity" IN REFERENCESET('Scoped PANOS Firewalls')
AND "portal_exposure_state" IN ('enabled','exposed','under_investigation')
AND (
"application" IN ('captive-portal','user-id','auth-portal')
OR "url_path" ILIKE '%captive%'
OR "url_path" ILIKE '%user-id%'
OR "url_path" ILIKE '%portal%'
OR "rule_name" ILIKE '%User-ID%'
OR "rule_name" ILIKE '%Captive Portal%'
OR (
"destination_port" IN (443,6080,6081)
AND "portal_exposure_state" IN ('enabled','exposed','under_investigation')
)
)
AND "source_zone" IN ('untrust','internet','external')
AND NOT "source_ip" IN REFERENCESET('Approved Portal Sources')
AND NOT "source_ip" IN REFERENCESET('Approved Scanner Sources')
LAST 1 HOURS;
-- QRadar AQL support pattern for Building Block 2.
-- Use this to validate same-firewall instability candidates.
SELECT
"firewall_identity",
"qidname",
"category",
"severity",
"payload",
STARTTIME
FROM events
WHERE
"log_source_type" ILIKE '%Palo Alto%'
AND "firewall_identity" IN REFERENCESET('Scoped PANOS Firewalls')
AND (
"payload" ILIKE '%crash%'
OR "payload" ILIKE '%restart%'
OR "payload" ILIKE '%fault%'
OR "payload" ILIKE '%failover%'
OR "payload" ILIKE '%service unavailable%'
OR "payload" ILIKE '%service failed%'
OR "payload" ILIKE '%management plane%'
OR "payload" ILIKE '%captive portal%'
OR "payload" ILIKE '%portal%'
)
AND NOT (
"payload" ILIKE '%scheduled maintenance%'
OR "payload" ILIKE '%approved maintenance%'
OR "payload" ILIKE '%software update%'
OR "payload" ILIKE '%content update%'
OR "payload" ILIKE '%license update%'
)
LAST 1 HOURS;
-- CRE implementation:
-- Trigger when Building Block 2 occurs on the same firewall_identity after
-- Building Block 1 within the approved investigation window.
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Rule Format
QRadar CRE rule using portal-activity and administrative/configuration building blocks, supported by AQL validation patterns after DSM, custom property, reference set, and CRE timing validation.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by administrative-control anomalies or configuration integrity changes.
· Identify probable post-interaction firewall control-plane activity that may indicate unauthorized administration, configuration tampering, visibility reduction, or traffic-enforcement change.
· Avoid dependence on CVE strings, static exploit artifacts, source reputation alone, affected-version inventory alone, or generic firewall access.
· This rule does not confirm compromise without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Reuse or create a portal-activity building block for suspicious User-ID Authentication Portal or Captive Portal activity from untrusted and unapproved sources.
· Create an administrative/configuration building block for same-firewall administrator login anomalies, account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, logging changes, policy changes, NAT changes, route changes, and management-setting changes.
· Trigger the CRE rule when the administrative/configuration building block fires on the same firewall after the portal-activity building block within the investigation window.
· Do not suppress high-value administrative or configuration events solely because administrator source IP is missing, inconsistently parsed, or normalized into a different custom property.
· Treat exposure-only findings, normal commits, scheduled maintenance, and affected-version inventory as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic events.
· PAN-OS threat events where available.
· PAN-OS administrative audit events.
· PAN-OS configuration events.
· PAN-OS system events where administrative activity is recorded there.
· Firewall identity or device name.
· Timestamp.
· Source IP address where available.
· Destination IP address.
· Administrator username where available.
· Action, command, object, QID, category, severity, subtype, and payload message where available.
· Commit history.
· Configuration export records where available.
· Portal exposure context.
· Approved administrator source reference set.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate QRadar log sources, DSM parsing, custom properties, QIDs, categories, reference sets, and timestamp handling before deployment.
· Implement approved administrator sources as QRadar reference sets or building blocks, but do not require administrator source IP to be present for every administrative or configuration event.
· Create a portal-activity building block using scoped firewall identity, portal exposure state, portal indicators, untrusted source context, and approved-source exclusions.
· Create an administrative/configuration building block using validated QIDs, event names, categories, payload terms, administrator identity fields, object fields, and configuration-action fields.
· Configure the CRE rule to require same-firewall correlation between the portal-activity building block and the subsequent administrative/configuration building block.
· Tune known automation, Panorama-driven commits, backup activity, scheduled exports, certificate renewal, policy deployment workflows, approved administrator sources, and approved maintenance.
· Use affected-version inventory and exposure context as prioritization fields, not standalone alert conditions.
· Route alerts at higher priority when administrative-control or configuration changes are paired with device instability, visibility reduction, or outbound anomalies.
DRI Assessment
DRI
8.5 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by administrative-control or configuration integrity change.
· The rule remains useful if attackers change source infrastructure, payload structure, request timing, or visible exploit characteristics.
· The score is supported by same-firewall temporal correlation between exploit-facing activity and control-plane change behavior.
· The score is constrained by legitimate administrative overlap and dependency on administrative audit, configuration-event, DSM, and custom-property quality.
TCR Assessment
Operational TCR
7.1 / 10
Full-Telemetry TCR
8.6 / 10
· Operational confidence depends on administrative audit logging, configuration-event fidelity, commit metadata, administrator identity fields, firewall identity consistency, DSM quality, custom-property quality, and change-window context.
· Operational confidence is reduced where administrative events are incomplete, commits are frequent, automation activity is poorly baselined, or firewall identity fields are inconsistent.
· Full-telemetry confidence improves when QRadar receives PAN-OS traffic, system, administrative, configuration, identity-provider, privileged-access, change-management, DNS, flow, and NDR telemetry.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction administrative or configuration behavior, not confirmed code execution.
· Legitimate administrator activity, automation, Panorama-driven changes, certificate renewal, backups, policy deployment, and approved maintenance may overlap with rule conditions.
· Field names and event descriptions vary by PAN-OS version, QRadar DSM version, custom property extraction, and local normalization.
· Administrator source IP may be missing, inconsistently parsed, or stored in a custom property depending on log source and parser behavior.
· AQL support patterns are validation aids and should not replace CRE same-firewall temporal correlation.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
-- QRadar AQL support pattern for administrative/configuration building block validation.
-- Use with a CRE rule that correlates this building block after suspicious portal activity
-- on the same firewall_identity within the investigation window.
SELECT
"firewall_identity",
"admin_source_ip",
"admin_user",
"qidname",
"category",
"payload",
STARTTIME
FROM events
WHERE
"log_source_type" ILIKE '%Palo Alto%'
AND "firewall_identity" IN REFERENCESET('Scoped PANOS Firewalls')
AND (
"payload" ILIKE '%commit%'
OR "payload" ILIKE '%configuration export%'
OR "payload" ILIKE '%admin login%'
OR "payload" ILIKE '%administrator login%'
OR "payload" ILIKE '%account created%'
OR "payload" ILIKE '%account modified%'
OR "payload" ILIKE '%privilege%'
OR "payload" ILIKE '%authentication profile%'
OR "payload" ILIKE '%certificate%'
OR "payload" ILIKE '%logging%'
OR "payload" ILIKE '%syslog%'
OR "payload" ILIKE '%security policy%'
OR "payload" ILIKE '%NAT%'
OR "payload" ILIKE '%route%'
OR "payload" ILIKE '%management setting%'
)
AND (
"admin_source_ip" IS NULL
OR NOT "admin_source_ip" IN REFERENCESET('Approved Admin Sources')
)
AND NOT (
"payload" ILIKE '%scheduled maintenance%'
OR "payload" ILIKE '%approved commit%'
OR "payload" ILIKE '%approved change%'
OR "payload" ILIKE '%content update%'
OR "payload" ILIKE '%license update%'
)
LAST 1 HOURS;
-- CRE implementation:
-- Trigger when this administrative/configuration building block occurs on the same
-- firewall_identity after the portal-activity building block within the approved
-- investigation window.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Rule Format
QRadar CRE rule using portal-activity, firewall-originated outbound anomaly, and visibility-reduction building blocks, supported by AQL validation patterns after DSM, flow, custom property, reference set, asset profile, and CRE timing validation.
Detection Purpose
· Detect suspicious portal-directed activity followed by firewall-originated outbound anomalies or visibility-impacting logging and monitoring changes.
· Identify probable post-interaction behavior where a firewall begins communicating with unusual external infrastructure or where logging visibility is reduced after suspicious portal activity.
· Avoid reliance on static indicators, exploit strings, proof-of-concept artifacts, source reputation alone, affected-version inventory alone, or packet payload visibility.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Reuse or create a portal-activity building block for suspicious User-ID Authentication Portal or Captive Portal activity from untrusted and unapproved sources.
· Create a firewall-originated outbound anomaly building block for scoped firewall assets communicating to newly observed, rare, unexplained, or unapproved destinations inconsistent with expected firewall egress baselines.
· Create a visibility-reduction building block for logging, forwarding, audit, monitoring, or visibility-control changes on the same firewall.
· Trigger the CRE rule when either the outbound anomaly building block or visibility-reduction building block fires on the same firewall after the portal-activity building block within the investigation window.
· Require outbound-anomaly logic to represent firewall-originated communication, not ordinary through-firewall transit traffic.
· Tie firewall-originated outbound traffic to the same firewall asset identity through log source identity, firewall source IP, custom property mapping, asset profile, flow source context, or validated traffic-role property.
· Treat standalone outbound anomalies, expected vendor communication, approved logging changes, and exposure-only findings as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic events.
· PAN-OS configuration events.
· PAN-OS system events.
· QRadar flow records for firewall-originated communication.
· DNS events where available.
· Proxy or egress events where available.
· Firewall identity or device name.
· Firewall source IP mapping.
· Traffic-role or firewall-originated custom property where available.
· Timestamp.
· Source and destination IP address.
· Destination domain where available.
· Destination port and protocol.
· Session duration.
· Byte and packet volume.
· Logging, forwarding, audit, monitoring, or visibility-control event fields.
· Expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destination reference sets.
Engineering Implementation Instructions
· Validate QRadar log sources, flow sources, PAN-OS DSM parsing, custom properties, QIDs, categories, reference sets, asset profiles, and timestamp handling before deployment.
· Implement expected destinations, rare destinations, scoped firewall IPs, approved management destinations, and approved logging or telemetry destinations as QRadar reference sets or building blocks.
· Confirm that firewall-originated outbound communication can be distinguished from through-firewall transit traffic.
· Create an outbound-anomaly building block using firewall source IP mapping, asset identity, flow source context, traffic-role custom property, or validated management/control-plane flow context.
· Create a visibility-reduction building block using validated QIDs, categories, custom properties, or payload terms for logging, syslog, log forwarding, threat logging, traffic logging, administrative audit logging, monitoring, and visibility changes.
· Configure the CRE rule to require same-firewall correlation between portal activity and either outbound anomaly or visibility reduction.
· Baseline expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destinations before enabling the rule.
· Suppress known vendor communication and approved visibility changes only when destination, device, timing, and change context are validated.
DRI Assessment
DRI
8.3 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by firewall-originated outbound anomaly or visibility reduction.
· The rule remains useful if attackers vary source infrastructure, payload structure, request timing, or follow-on communication destinations.
· The score is supported by same-firewall temporal correlation between exploit-facing activity and post-interaction egress or visibility-control behavior.
· The score is constrained by the need to distinguish firewall-originated traffic from transit traffic and by dependency on outbound baselines and QRadar flow/custom-property quality.
TCR Assessment
Operational TCR
6.9 / 10
Full-Telemetry TCR
8.4 / 10
· Operational confidence depends on firewall-originated flow visibility, destination baselining, DNS or proxy enrichment, PAN-OS configuration logging, DSM quality, custom-property quality, firewall source-IP mapping, traffic-role interpretation, and consistent firewall identity fields.
· Operational confidence is reduced where outbound firewall traffic is mixed with transit traffic or expected vendor destinations are not baselined.
· Full-telemetry confidence improves when QRadar receives PAN-OS traffic, system, configuration, DNS, proxy, flow, NDR, and egress telemetry with reliable device identity and destination context.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction egress or visibility reduction, not confirmed unauthorized code execution.
· Normal update, licensing, logging, telemetry, support, DNS, NTP, monitoring, and management traffic may overlap with outbound anomaly logic if baselines are incomplete.
· Approved logging changes, monitoring updates, syslog migrations, and maintenance activity may overlap with visibility-reduction logic.
· Encrypted traffic may limit destination or session detail.
· Firewall-originated traffic may be difficult to distinguish from transit traffic in environments without reliable source-IP mapping, log source identity, asset context, interface context, flow source context, or traffic-role custom properties.
· AQL support patterns are validation aids and should not replace CRE same-firewall temporal correlation.
· Confirmation requires correlation with firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
-- QRadar AQL support pattern for firewall-originated outbound anomaly validation.
-- Use with a CRE rule that correlates outbound anomaly after suspicious portal activity
-- on the same firewall_identity within the investigation window.
SELECT
"firewall_identity",
"source_ip",
"destination_ip",
"destination_domain",
"destination_port",
"protocol",
"bytes",
"packets",
"firewall_originated",
STARTTIME
FROM flows
WHERE
"firewall_identity" IN REFERENCESET('Scoped PANOS Firewalls')
AND "firewall_originated" = TRUE
AND NOT "destination_ip" IN REFERENCESET('Expected Firewall Vendor Destinations')
AND NOT "destination_domain" IN REFERENCESET('Expected Firewall Vendor Domains')
AND NOT "destination_ip" IN REFERENCESET('Approved Logging Telemetry Destinations')
AND NOT "destination_ip" IN REFERENCESET('Approved Management Destinations')
AND (
"destination_ip" IN REFERENCESET('New Or Rare Destinations')
OR "destination_domain" IN REFERENCESET('New Or Rare Domains')
OR "destination_asn" IN REFERENCESET('Rare Destination ASNs')
OR NOT "destination_port" IN REFERENCESET('Expected Firewall Egress Ports')
)
LAST 1 HOURS;
-- QRadar AQL support pattern for visibility-reduction building block validation.
SELECT
"firewall_identity",
"qidname",
"category",
"payload",
STARTTIME
FROM events
WHERE
"log_source_type" ILIKE '%Palo Alto%'
AND "firewall_identity" IN REFERENCESET('Scoped PANOS Firewalls')
AND (
"payload" ILIKE '%logging%'
OR "payload" ILIKE '%syslog%'
OR "payload" ILIKE '%log forwarding%'
OR "payload" ILIKE '%threat log%'
OR "payload" ILIKE '%traffic log%'
OR "payload" ILIKE '%audit log%'
OR "payload" ILIKE '%monitoring%'
OR "payload" ILIKE '%visibility%'
)
AND NOT (
"payload" ILIKE '%scheduled maintenance%'
OR "payload" ILIKE '%approved change%'
OR "payload" ILIKE '%approved commit%'
)
LAST 1 HOURS;
-- CRE implementation:
-- Trigger when the outbound-anomaly building block or visibility-reduction building
-- block occurs on the same firewall_identity after the portal-activity building block
-- within the approved investigation window.
SIGMA
Detection Viability Assessment
SIGMA has two rules for this EXP report.
SIGMA is viable as a portable detection format where PAN-OS traffic, threat, system, administrative, and configuration logs are normalized into consistent SIEM fields or mapped through backend-specific transformations.
SIGMA is strongest for portable correlation patterns that identify suspicious User-ID Authentication Portal or Captive Portal activity followed by same-firewall instability or administrative-control and configuration integrity anomalies.
SIGMA correlation support varies by backend. These rules must be implemented only where the target SIEM or SIGMA conversion pipeline can preserve same-firewall grouping, sequence ordering, temporal correlation, and exception handling. Where the backend cannot preserve those semantics, the logic should be converted into the target SIEM’s native correlation language.
SIGMA is not used here for firewall-originated egress baselining, rare-destination analysis, NDR-style behavioral analytics, or cloud-native exposure detection because those opportunities are better handled in Splunk, Elastic, QRadar, NDR, and cloud-native rule sections.
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Rule Format
SIGMA correlation pattern requiring backend support for temporal correlation, same-firewall grouping, field mapping, and exception handling before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by firewall crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Provide portable SIEM logic for probable exploitation patterns where exploit-facing portal activity is followed by same-firewall device-health impact.
· Avoid reliance on exploit strings, proof-of-concept artifacts, attacker IP addresses, source reputation alone, affected-version inventory alone, generic firewall access, or packet payload visibility.
· This rule does not confirm unauthorized code execution without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify PAN-OS traffic, threat, or portal events where scoped PA-Series or VM-Series firewalls receive portal-directed activity from untrusted and unapproved sources.
· Require the destination firewall to have User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Treat destination-port matching as fallback portal logic only when scoped firewall identity and portal exposure context are present.
· Correlate the portal-directed event with a same-firewall system, HA, service, health, crash, restart, fault, or portal-interruption event after the portal event within a defensible investigation window.
· Treat exposure-only findings, affected-version inventory, generic firewall access, and source reputation as enrichment context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS threat logs where available.
· PAN-OS system logs.
· PAN-OS HA, health, or service status logs where available.
· Firewall identity or device name.
· Source IP address.
· Destination IP address.
· Source zone, destination zone, interface, or exposure context where available.
· Application, service, URL, rule name, destination port, or portal indicator where available.
· System event type, subtype, severity, and message.
· Timestamp.
· Scoped PA-Series or VM-Series firewall inventory.
· Approved portal-source and approved scanner context.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate SIEM backend support for SIGMA correlation rules before deployment.
· Map local PAN-OS fields to normalized field names for firewall identity, source IP, destination IP, source zone, application, URL path, rule name, destination port, event message, event category, severity, and timestamp.
· Implement scoped firewalls, scoped firewall IPs, approved portal sources, approved scanner sources, portal exposure state, and maintenance windows as backend-supported lists, lookups, enrichment tables, value lists, or exception mechanisms.
· Require same-firewall correlation between suspicious portal activity and subsequent instability.
· Tune the correlation window based on log latency, portal exposure, maintenance frequency, and SOC triage requirements.
· Suppress approved maintenance only when firewall identity, event type, time window, and change context are validated.
· Do not deploy this rule as a single-event SIGMA match. It requires backend correlation support or conversion into native SIEM sequence logic.
DRI Assessment
DRI
8.2 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall instability rather than exploit artifacts.
· The rule remains useful if attackers change source infrastructure, visible request characteristics, timing, or payload structure.
· The score is supported by portable correlation between exploit-facing activity and device-health impact.
· The score is constrained by backend correlation support, field-mapping quality, portal exposure context, and system-log fidelity.
TCR Assessment
Operational TCR
6.8 / 10
Full-Telemetry TCR
8.2 / 10
· Operational confidence depends on SIEM normalization quality, PAN-OS parser fidelity, same-firewall identity mapping, portal-indicator availability, and maintenance-window handling.
· Operational confidence is reduced where SIGMA conversion cannot preserve temporal correlation, sequence ordering, same-firewall grouping, or backend exception handling.
· Full-telemetry confidence improves when the backend receives PAN-OS traffic, threat, system, HA, administrative, and configuration logs with consistent timestamps and device identity.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious portal activity followed by firewall instability, not confirmed unauthorized code execution.
· SIGMA portability depends on backend translation quality and correlation-rule support.
· Legitimate maintenance, failover testing, service restarts, and approved operational activity may overlap with instability signals.
· Portal indicators may vary by PAN-OS logging configuration, parser, and SIEM normalization.
· Backend-specific lists and exceptions must be implemented locally before production deployment.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
title: Suspicious PAN-OS Portal Activity Followed by Firewall Instability
id: cve-2026-0300-sigma-correlation-001
status: test
description: >
SIGMA correlation pattern for suspicious PAN-OS User-ID Authentication Portal
or Captive Portal activity followed by same-firewall instability within a
backend-defined correlation window. Requires backend support for temporal
correlation, same-firewall grouping, field mapping, and exception handling.
references:
- CVE-2026-0300
author: CyberDax
date: 2026/05/06
logsource:
product: pan-os
detection:
portal_activity:
observer.product|contains:
- PAN-OS
destination.ip|in:
- SCOPED_PANOS_FIREWALL_IPS
panos.portal_exposure_state:
- enabled
- exposed
- under_investigation
portal_indicator_app:
panos.application:
- captive-portal
- user-id
- auth-portal
portal_indicator_url:
url.path|contains:
- captive
- user-id
- portal
portal_indicator_rule:
rule.name|contains:
- User-ID
- Captive Portal
- Authentication Portal
portal_indicator_port_fallback:
destination.port:
- 443
- 6080
- 6081
source_scope:
source.zone:
- untrust
- internet
- external
approved_portal_source_filter:
source.ip|in:
- APPROVED_PORTAL_SOURCE_RANGES
approved_scanner_filter:
source.ip|in:
- APPROVED_SCANNER_SOURCE_RANGES
condition: >
portal_activity and
1 of portal_indicator_* and
source_scope and
not approved_portal_source_filter and
not approved_scanner_filter
correlation:
backend_requirement: >
Correlate this portal_activity condition with the follow_on_instability
condition on the same firewall identity after the portal event within the
backend-defined investigation window.
group_by:
- observer.id
sequence_order:
- portal_activity
- follow_on_instability
timespan: 1h
follow_on_instability:
description: >
Backend-native follow-on condition. Implement as a second SIGMA rule,
backend correlation clause, or SIEM-native sequence stage.
selection:
observer.product|contains:
- PAN-OS
observer.id|in:
- SCOPED_PANOS_FIREWALLS
message|contains:
- crash
- restart
- fault
- failover
- service unavailable
- service failed
- management plane
- captive portal
- portal
maintenance_filter:
message|contains:
- scheduled maintenance
- approved maintenance
- software update
- content update
- license update
condition: selection and not maintenance_filter
fields:
- observer.id
- observer.name
- source.ip
- source.zone
- destination.ip
- destination.port
- panos.application
- url.path
- rule.name
- message
falsepositives:
- Approved portal use from unapproved or unmapped sources
- Approved scanning
- Approved maintenance
- Failover testing
level: high
tags:
- attack.initial-access
- attack.t1190
- cve.2026.0300
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Rule Format
SIGMA correlation pattern requiring backend support for temporal correlation, same-firewall grouping, administrative/configuration event mapping, and exception handling before deployment.
Detection Purpose
· Detect suspicious interaction with PAN-OS User-ID Authentication Portal or Captive Portal services followed by administrative-control anomalies or configuration integrity changes.
· Provide portable SIEM logic for probable post-interaction firewall control-plane activity that may indicate unauthorized administration, configuration tampering, visibility reduction, or traffic-enforcement change.
· Avoid dependence on CVE strings, static exploit artifacts, source reputation alone, affected-version inventory alone, or generic firewall access.
· This rule does not confirm compromise without corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Detection Logic
· Identify suspicious portal-directed traffic against a scoped PA-Series or VM-Series firewall from untrusted and unapproved sources.
· Correlate the portal-directed event with a same-firewall administrative or configuration event after the portal event within a defensible investigation window.
· Prioritize administrator login anomalies, account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, logging changes, policy changes, NAT changes, route changes, and management-setting changes.
· Do not suppress high-value administrative or configuration events solely because administrator source IP is missing, inconsistently parsed, or normalized into a backend-specific field.
· Treat exposure-only findings, normal commits, scheduled maintenance, and affected-version inventory as context rather than standalone compromise evidence.
Required Telemetry
· PAN-OS traffic logs.
· PAN-OS threat logs where available.
· PAN-OS administrative audit logs.
· PAN-OS configuration logs.
· PAN-OS system logs where administrative activity is recorded there.
· Firewall identity or device name.
· Timestamp.
· Source IP address where available.
· Destination IP address.
· Administrator username where available.
· Action, command, object, subtype, severity, and event message fields where available.
· Commit history.
· Configuration export records where available.
· Portal exposure context.
· Approved administrator source context.
· Approved maintenance-window context.
Engineering Implementation Instructions
· Validate SIEM backend support for SIGMA correlation rules before deployment.
· Map local PAN-OS fields to normalized field names for firewall identity, source IP, destination IP, administrator username, action, command, object, event message, event category, severity, and timestamp.
· Implement scoped firewalls, scoped firewall IPs, approved portal sources, approved scanner sources, approved administrator sources, portal exposure state, and maintenance windows as backend-supported lists, lookups, enrichment tables, value lists, or exception mechanisms.
· Require same-firewall correlation between suspicious portal activity and subsequent administrative or configuration anomaly.
· Tune the correlation window based on log latency, maintenance frequency, automation frequency, and SOC triage requirements.
· Tune Panorama-driven commits, scheduled exports, certificate renewal, backup activity, policy deployment, and approved maintenance workflows before deployment.
· Do not deploy this rule as a single-event SIGMA match. It requires backend correlation support or conversion into native SIEM sequence logic.
DRI Assessment
DRI
8.1 / 10
· The rule is behaviorally anchored to suspicious portal-directed activity followed by same-firewall administrative-control or configuration integrity change.
· The rule remains useful if attackers change source infrastructure, request timing, visible request characteristics, or payload structure.
· The score is supported by portable correlation between exploit-facing activity and control-plane change behavior.
· The score is constrained by legitimate administrative overlap, backend correlation support, and PAN-OS field-mapping quality.
TCR Assessment
Operational TCR
6.7 / 10
Full-Telemetry TCR
8.1 / 10
· Operational confidence depends on administrative audit logging, configuration-log fidelity, commit metadata, administrator identity fields, SIEM normalization quality, and same-firewall identity mapping.
· Operational confidence is reduced where administrative events are incomplete, commits are frequent, automation is poorly baselined, or SIGMA conversion cannot preserve correlation semantics.
· Full-telemetry confidence improves when the backend receives PAN-OS traffic, system, administrative, configuration, identity-provider, privileged-access, and change-management context.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious post-interaction administrative or configuration behavior, not confirmed code execution.
· SIGMA portability depends on backend translation quality and correlation-rule support.
· Legitimate administrator activity, Panorama-driven changes, automation, certificate renewal, backups, policy deployment, and approved maintenance may overlap with rule conditions.
· Administrator source IP may be missing, inconsistently parsed, or stored in a backend-specific field.
· Backend-specific lists and exceptions must be implemented locally before production deployment.
· Confirmation requires correlation with forensic evidence, vendor-supported evidence, unauthorized configuration activity, unauthorized code execution evidence, attacker-controlled behavior, or validated incident-response findings.
Detection Query Pattern
title: Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
id: cve-2026-0300-sigma-correlation-002
status: test
description: >
SIGMA correlation pattern for suspicious PAN-OS User-ID Authentication Portal
or Captive Portal activity followed by same-firewall administrative-control
or configuration integrity anomaly within a backend-defined correlation window.
Requires backend support for temporal correlation, same-firewall grouping,
field mapping, and exception handling.
references:
- CVE-2026-0300
author: CyberDax
date: 2026/05/06
logsource:
product: pan-os
detection:
portal_activity:
observer.product|contains:
- PAN-OS
destination.ip|in:
- SCOPED_PANOS_FIREWALL_IPS
panos.portal_exposure_state:
- enabled
- exposed
- under_investigation
portal_indicator_app:
panos.application:
- captive-portal
- user-id
- auth-portal
portal_indicator_url:
url.path|contains:
- captive
- user-id
- portal
portal_indicator_rule:
rule.name|contains:
- User-ID
- Captive Portal
- Authentication Portal
portal_indicator_port_fallback:
destination.port:
- 443
- 6080
- 6081
source_scope:
source.zone:
- untrust
- internet
- external
approved_portal_source_filter:
source.ip|in:
- APPROVED_PORTAL_SOURCE_RANGES
approved_scanner_filter:
source.ip|in:
- APPROVED_SCANNER_SOURCE_RANGES
condition: >
portal_activity and
1 of portal_indicator_* and
source_scope and
not approved_portal_source_filter and
not approved_scanner_filter
correlation:
backend_requirement: >
Correlate this portal_activity condition with the follow_on_admin_or_config
condition on the same firewall identity after the portal event within the
backend-defined investigation window.
group_by:
- observer.id
sequence_order:
- portal_activity
- follow_on_admin_or_config
timespan: 1h
follow_on_admin_or_config:
description: >
Backend-native follow-on condition. Implement as a second SIGMA rule,
backend correlation clause, or SIEM-native sequence stage. Do not suppress
high-value events solely because source.ip is absent. Approved administrator
source tuning should be implemented in the target backend using local
exception handling rather than as a mandatory SIGMA selector.
selection:
observer.product|contains:
- PAN-OS
observer.id|in:
- SCOPED_PANOS_FIREWALLS
message|contains:
- commit
- configuration export
- admin login
- administrator login
- account created
- account modified
- privilege
- authentication profile
- certificate
- logging
- syslog
- security policy
- NAT
- route
- management setting
maintenance_filter:
message|contains:
- scheduled maintenance
- approved commit
- approved change
- content update
- license update
condition: selection and not maintenance_filter
fields:
- observer.id
- observer.name
- source.ip
- user.name
- destination.ip
- destination.port
- panos.application
- url.path
- rule.name
- message
falsepositives:
- Approved portal use
- Approved scanning
- Approved administrator activity
- Panorama-driven commits
- Scheduled backup or export activity
- Certificate renewal
- Approved policy deployment
level: high
tags:
- attack.initial-access
- attack.t1190
- cve.2026.0300
YARA
Final Disposition
No YARA rule is deployed for this report.
Detection Viability Assessment
YARA does not meet the deployment threshold for this report because available public detail does not provide a validated file artifact, memory artifact, malware payload, script sample, persistence artifact, or stable forensic object suitable for durable YARA matching.
Rule Rejection Rationale
Candidate YARA logic was rejected because it would require speculative strings, assumed payload content, generic PAN-OS artifact matching, or unsupported persistence assumptions.
Operational Use
YARA may become useful if vendor-supported forensic evidence, validated incident-response artifacts, malware samples, memory objects, scripts, or persistence files are later identified. Until then, YARA should remain out of S25 production rule coverage for CVE-2026-0300.
S25 Outcome
Zero YARA rules survived S25 validation.
AWS
Detection Viability Assessment
AWS has two conditional rules for this EXP report.
AWS is viable only for VM-Series firewall deployments hosted in AWS where CloudTrail, VPC Flow Logs, asset tags, security group data, route context, load balancer telemetry, ENI mapping, and firewall identity mapping are available.
AWS is not a detection surface for PA-Series hardware appliances outside AWS telemetry visibility.
AWS rules should focus on cloud-native exposure changes, public ingress paths to User-ID Authentication Portal or Captive Portal services, and firewall-originated outbound anomalies from VM-Series firewall infrastructure.
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Rule Format
AWS EventBridge / CloudTrail pre-filter supported by mandatory enrichment from AWS Config, resource tags, security group details, route context, public IP mapping, load balancer mapping, and VM-Series asset inventory.
Detection Purpose
· Detect AWS control-plane changes that may expose VM-Series User-ID Authentication Portal or Captive Portal services to untrusted networks.
· Identify security group, public IP, load balancer, route, or ingress-control changes that create or expand public reachability to scoped VM-Series firewall assets.
· Support exposure detection and urgent remediation without treating exposure alone as confirmed exploitation.
· This rule does not confirm exploitation unless correlated with suspicious portal activity, firewall instability, administrative-control anomalies, outbound anomalies, forensic evidence, or vendor-supported confirmation.
Detection Logic
· Use EventBridge to pre-filter AWS API activity that may modify security groups, network ACLs, public IP association, route tables, internet gateway attachment, load balancer listeners, target groups, or network interfaces associated with VM-Series firewall deployments.
· Do not treat the EventBridge match alone as the detection. Alert only after enrichment confirms scoped VM-Series infrastructure, portal-relevant ingress, public or untrusted reachability, unapproved source range, and unapproved change context.
· Require the affected asset to be a scoped VM-Series firewall, VM-Series firewall ENI, security group attached to VM-Series firewall infrastructure, or public ingress component forwarding traffic to VM-Series firewall portal services.
· Prioritize changes that allow public or untrusted ingress to locally validated User-ID Authentication Portal or Captive Portal services. Common candidate ports such as TCP 443, TCP 6080, and TCP 6081 should be treated as examples or fallback values, not universal portal-port assumptions.
· Increase priority when the change is performed outside approved change windows, by unexpected principals, from unusual locations, or without corresponding change-management context.
· Treat exposure changes as high-priority remediation and hunting triggers, not standalone proof of exploitation.
Required Telemetry
· AWS CloudTrail management events.
· EC2 security group change events.
· Network ACL change events where applicable.
· Route table change events.
· Internet gateway and public IP association events.
· Elastic Load Balancing listener, target group, and security group association events where applicable.
· AWS Config resource history where available.
· VM-Series instance, ENI, security group, target group, and load balancer asset tags.
· Locally validated User-ID Authentication Portal or Captive Portal port mapping.
· Approved change-window context.
· Approved administrator or automation role context.
· Known approved ingress source ranges.
Engineering Implementation Instructions
· Deploy only for AWS accounts and regions where VM-Series firewall inventory is maintained and tagged.
· Treat EventBridge as a pre-filter only. Route matching events to enrichment logic before alert generation.
· Tag VM-Series instances, ENIs, security groups, target groups, and load balancers with consistent firewall identity and exposure context.
· Validate locally configured User-ID Authentication Portal or Captive Portal ports before production alerting.
· Use locally validated portal ports as the primary port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· Implement approved ingress sources, approved automation roles, approved administrators, and approved change windows as AWS-native allowlists or enrichment data.
· Use EventBridge to detect relevant CloudTrail API activity, then enrich with resource tags, security group rule details, route context, public IP mapping, load balancer mapping, target group mapping, and exposure state before alerting.
· Do not alert on every security group, route, public IP, or load balancer change. Alert only when the affected resource is tied to scoped VM-Series firewall infrastructure and the enrichment confirms public or untrusted portal reachability.
· Route alerts at higher priority when exposure changes are followed by suspicious portal traffic, firewall instability, administrative-control anomalies, or firewall-originated outbound anomalies.
DRI Assessment
DRI
8.0 / 10
· The rule is behaviorally anchored to cloud control-plane changes that expose VM-Series firewall portal services.
· The rule remains useful regardless of exploit payload, attacker infrastructure, request shape, or public proof-of-concept changes.
· The score is supported by direct visibility into AWS exposure-changing actions affecting VM-Series infrastructure.
· The score is constrained because exposure change alone does not prove exploitation and requires correlation for compromise classification.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.4 / 10
· Operational confidence depends on CloudTrail coverage, AWS Config coverage, resource tagging quality, security group enrichment, route context, load balancer mapping, local portal-port validation, and change-window validation.
· Operational confidence is reduced where VM-Series assets are poorly tagged, CloudTrail is incomplete, load balancer paths are not mapped, or public exposure paths are not reconstructed.
· Full-telemetry confidence improves when CloudTrail, AWS Config, VPC Flow Logs, load balancer logs, route inventory, and asset inventory are available with consistent firewall identity.
· Even under full telemetry conditions, this rule supports exposure and hunt prioritization, not confirmed compromise by itself.
Limitations
· This rule detects exposure-changing AWS control-plane activity, not confirmed exploitation.
· EventBridge matches are pre-filter events and must not be treated as alerts without enrichment.
· Legitimate security group changes, load balancer changes, route changes, public IP changes, automation activity, and infrastructure deployment may overlap with rule conditions.
· Incomplete asset tagging can weaken VM-Series scoping.
· Custom portal ports, nonstandard ingress designs, and load-balanced paths require local validation.
· Confirmation requires correlation with portal activity, firewall logs, outbound anomalies, administrative anomalies, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
{
"source": ["aws.ec2", "aws.elasticloadbalancing"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": [
"ec2.amazonaws.com",
"elasticloadbalancing.amazonaws.com"
],
"eventName": [
"AuthorizeSecurityGroupIngress",
"ModifySecurityGroupRules",
"RevokeSecurityGroupIngress",
"CreateSecurityGroup",
"ModifyNetworkInterfaceAttribute",
"AssociateAddress",
"DisassociateAddress",
"CreateRoute",
"ReplaceRoute",
"AssociateRouteTable",
"AttachInternetGateway",
"CreateLoadBalancer",
"CreateListener",
"ModifyListener",
"RegisterTargets",
"SetSecurityGroups"
]
}
}
EventBridge pre-filter handling:
The EventBridge pattern is not the alert condition. It should route matching CloudTrail
events to enrichment logic.
Required enrichment conditions before alerting:
ResourceTag.Role IN (
"VM-Series Firewall",
"PAN-OS Firewall",
"Palo Alto VM-Series"
)
AND AffectedResource IN (
VM_SERIES_INSTANCE_IDS,
VM_SERIES_ENI_IDS,
VM_SERIES_SECURITY_GROUP_IDS,
VM_SERIES_LOAD_BALANCER_IDS,
VM_SERIES_TARGET_GROUP_IDS
)
AND ExposureChange = "public_or_untrusted_ingress_enabled"
AND DestinationPort IN (
LOCALLY_VALIDATED_PORTAL_PORTS
)
AND SourceCIDR NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND PrincipalArn NOT IN APPROVED_AUTOMATION_OR_ADMIN_ROLES
AND ChangeWindow != "approved"
Optional fallback port review:
Evaluate TCP 443, TCP 6080, and TCP 6081 only when local VM-Series portal
configuration confirms those ports are relevant.
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Rule Format
AWS VPC Flow Logs / CloudWatch Logs Insights or Athena correlation pattern requiring VM-Series ENI mapping, enrichment-derived traffic-role classification, flow-direction validation, destination-baseline enrichment, load balancer path validation, and temporal-window tuning before deployment.
Detection Purpose
· Detect suspicious inbound traffic to exposed VM-Series portal services followed by unusual outbound communication from the same VM-Series firewall infrastructure.
· Identify probable post-interaction cloud-network behavior without relying on exploit payload strings, packet capture, source reputation alone, or static attacker infrastructure.
· Prioritize firewall-originated outbound communication inconsistent with expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, or management baselines.
· This rule does not confirm unauthorized code execution without corroborating firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Logic
· Identify inbound VPC Flow Log records where untrusted or public sources communicate with scoped VM-Series firewall ENIs on locally validated portal services.
· Require the target asset to be a scoped VM-Series firewall ENI, firewall interface, or validated load-balanced path associated with User-ID Authentication Portal or Captive Portal exposure.
· Treat eni_role and traffic_role as enrichment-derived fields created from ENI mapping, firewall interface role, route context, asset tagging, flow direction, or validated firewall-path classification. They should not be assumed to exist natively in VPC Flow Logs.
· Correlate inbound portal-directed activity with outbound communication from the same VM-Series firewall ENI, firewall source IP, or validated firewall asset identity within a defensible investigation window.
· Prioritize outbound communication to newly observed, rare, unapproved, or unexpected destinations not associated with expected vendor, logging, telemetry, management, DNS, NTP, update, licensing, or monitoring activity.
· Treat inbound portal traffic alone, public exposure alone, approved scanning, and expected vendor communication as context rather than standalone compromise evidence.
Required Telemetry
· VPC Flow Logs for VM-Series firewall subnets and ENIs.
· VM-Series ENI and private IP mapping.
· ENI role enrichment derived from asset inventory, interface mapping, route context, or firewall deployment metadata.
· Traffic-role enrichment for firewall-originated versus through-firewall transit classification.
· Public IP and load balancer mapping where applicable.
· Load balancer access logs or target group mapping where the portal is exposed through ELB.
· Asset tags for VM-Series firewalls.
· Source IP address.
· Destination IP address.
· Source and destination port.
· Protocol.
· Flow direction or equivalent ENI role context.
· Action field.
· Bytes and packets.
· Start and end timestamps.
· Route 53 Resolver DNS logs where available.
· Expected firewall egress destination baselines.
· Approved scanner and approved portal-source context.
Engineering Implementation Instructions
· Deploy only where VPC Flow Logs can observe inbound portal traffic and firewall-originated outbound communication for scoped VM-Series firewall ENIs.
· Validate VM-Series ENI mapping, private IP mapping, public IP mapping, load balancer path mapping, target group mapping, and firewall role tagging before deployment.
· Derive eni_role from ENI tags, subnet role, route context, security group association, firewall interface mapping, or deployment metadata.
· Derive traffic_role from ENI role, source IP mapping, route context, interface role, flow direction, and known firewall management/control-plane paths.
· Confirm that outbound records represent firewall-originated communication rather than ordinary through-firewall transit traffic.
· Use locally validated portal ports as the primary portal-port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· If the portal is exposed through an NLB, ALB, Gateway Load Balancer, or other ingress layer, validate that VPC Flow Logs alone can preserve the necessary source, target, and firewall identity relationship. Where they cannot, require load balancer access logs, target group mapping, or additional enrichment before deploying the rule.
· Implement approved portal sources, approved scanner sources, expected vendor destinations, approved logging destinations, approved management destinations, and expected firewall egress ports as lookup tables, Athena reference data, CloudWatch metric filters, or enrichment logic.
· Baseline expected VM-Series egress destinations for update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management.
· Tune the correlation window based on VPC Flow Log delivery latency, expected portal use, firewall egress frequency, and SOC triage requirements.
· Route alerts at higher priority when AWS network evidence is supported by PAN-OS logs, configuration changes, device instability, administrative-control anomalies, or visibility reduction.
DRI Assessment
DRI
8.2 / 10
· The rule is behaviorally anchored to suspicious inbound portal activity followed by same-firewall outbound anomaly.
· The rule remains useful if attackers change payload structure, source infrastructure, request timing, or visible exploit characteristics.
· The score is supported by same-asset temporal correlation between exploit-facing cloud ingress and firewall-originated outbound behavior.
· The score is constrained by dependence on VPC Flow Log visibility, ENI mapping, firewall-originated traffic classification, load balancer path validation, and outbound baselining.
TCR Assessment
Operational TCR
6.8 / 10
Full-Telemetry TCR
8.3 / 10
· Operational confidence depends on VPC Flow Log coverage, VM-Series ENI mapping, firewall source-IP mapping, load balancer mapping, destination baselining, DNS enrichment, enrichment-derived traffic-role fields, and flow timestamp quality.
· Operational confidence is reduced where VPC Flow Logs are incomplete, load balancer paths obscure source-to-target relationships, firewall-originated traffic cannot be distinguished from transit traffic, or egress baselines are immature.
· Full-telemetry confidence improves when VPC Flow Logs are enriched with CloudTrail, Route 53 Resolver DNS logs, load balancer logs, PAN-OS logs, AWS Config, and asset inventory.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious cloud-network behavior associated with possible VM-Series compromise, not confirmed unauthorized code execution.
· VPC Flow Logs do not provide payload visibility and may not expose application-layer portal details.
· Normal update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management activity may overlap with outbound anomaly logic if baselines are incomplete.
· Approved scanning, penetration testing, exposure validation, or legitimate portal use may overlap with suspicious inbound activity.
· Firewall-originated traffic may be difficult to distinguish from through-firewall transit traffic without ENI role mapping, route context, interface-role mapping, and flow-path validation.
· Load-balanced portal paths may obscure the relationship between the external source, load balancer, target ENI, and VM-Series firewall unless load balancer access logs and target group mapping are available.
· Confirmation requires correlation with PAN-OS logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
-- AWS Athena support query for VPC Flow Logs.
-- Validate table names, field names, ENI mapping, enrichment fields, load balancer
-- path mapping, timestamps, and reference tables before deployment.
--
-- Timestamp assumption:
-- This pattern assumes start and end are epoch-second numeric fields from VPC Flow Logs.
-- If using timestamp-typed fields, replace numeric addition with date_add or equivalent
-- Athena timestamp arithmetic.
--
-- Enrichment assumption:
-- eni_role and traffic_role are enrichment-derived fields, not native VPC Flow Log fields.
WITH portal_activity AS (
SELECT
firewall_id,
interface_id,
srcaddr AS portal_source_ip,
dstaddr AS firewall_private_ip,
dstport AS portal_destination_port,
start AS portal_start_epoch,
end AS portal_end_epoch,
action
FROM vpc_flow_logs
WHERE
firewall_id IN (SELECT firewall_id FROM scoped_vmseries_firewalls)
AND eni_role IN ('vmseries_firewall', 'vmseries_portal_ingress')
AND action = 'ACCEPT'
AND dstport IN (SELECT destination_port FROM locally_validated_portal_ports)
AND srcaddr NOT IN (SELECT source_ip FROM approved_portal_sources)
AND srcaddr NOT IN (SELECT source_ip FROM approved_scanner_sources)
),
firewall_egress AS (
SELECT
firewall_id,
interface_id,
srcaddr AS firewall_source_ip,
dstaddr AS outbound_destination_ip,
dstport AS outbound_destination_port,
protocol,
bytes,
packets,
start AS outbound_start_epoch,
end AS outbound_end_epoch,
action
FROM vpc_flow_logs
WHERE
firewall_id IN (SELECT firewall_id FROM scoped_vmseries_firewalls)
AND eni_role IN ('vmseries_firewall', 'vmseries_management', 'vmseries_control_plane')
AND action = 'ACCEPT'
AND traffic_role = 'firewall_originated'
AND dstaddr NOT IN (SELECT destination_ip FROM expected_firewall_vendor_destinations)
AND dstaddr NOT IN (SELECT destination_ip FROM approved_logging_telemetry_destinations)
AND dstaddr NOT IN (SELECT destination_ip FROM approved_management_destinations)
AND (
dstaddr IN (SELECT destination_ip FROM new_or_rare_destinations)
OR dstport NOT IN (SELECT destination_port FROM expected_firewall_egress_ports)
)
)
SELECT
p.firewall_id,
p.portal_source_ip,
p.firewall_private_ip,
p.portal_destination_port,
p.portal_start_epoch,
e.outbound_destination_ip,
e.outbound_destination_port,
e.protocol,
e.bytes,
e.packets,
e.outbound_start_epoch
FROM portal_activity p
JOIN firewall_egress e
ON p.firewall_id = e.firewall_id
WHERE
e.outbound_start_epoch > p.portal_start_epoch
AND e.outbound_start_epoch <= p.portal_start_epoch + 3600
Azure
Detection Viability Assessment
Azure has two conditional rules for this EXP report.
Azure is viable only for VM-Series firewall deployments hosted in Azure where Azure Activity logs, NSG Flow Logs, resource inventory, public IP mapping, route context, load balancer telemetry, NIC mapping, and firewall identity mapping are available.
Azure is not a detection surface for PA-Series hardware appliances outside Azure telemetry visibility.
Azure rules should focus on cloud-native exposure changes, public ingress paths to User-ID Authentication Portal or Captive Portal services, and firewall-originated outbound anomalies from VM-Series firewall infrastructure.
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Rule Format
Azure Activity Log / Azure Monitor detection pattern supported by mandatory enrichment from Azure Resource Graph, NSG rule details, public IP mapping, route context, load balancer mapping, NIC mapping, and VM-Series asset inventory.
Detection Purpose
· Detect Azure control-plane changes that may expose VM-Series User-ID Authentication Portal or Captive Portal services to untrusted networks.
· Identify NSG, public IP, route table, load balancer, NAT rule, application gateway, or NIC changes that create or expand public reachability to scoped VM-Series firewall assets.
· Support exposure detection and urgent remediation without treating exposure alone as confirmed exploitation.
· This rule does not confirm exploitation unless correlated with suspicious portal activity, firewall instability, administrative-control anomalies, outbound anomalies, forensic evidence, or vendor-supported confirmation.
Detection Logic
· Use Azure Activity logs to identify control-plane operations that may modify NSGs, public IP associations, route tables, load balancer listeners, NAT rules, application gateway listeners, NIC associations, or inbound access paths associated with VM-Series firewall deployments.
· Do not treat the Azure Activity match alone as the detection. Alert only after enrichment confirms scoped VM-Series infrastructure, portal-relevant ingress, public or untrusted reachability, unapproved source range, and unapproved change context.
· Require the affected resource to be a scoped VM-Series firewall, VM-Series firewall NIC, NSG attached to VM-Series firewall infrastructure, public IP, load balancer, application gateway, NAT rule, or route component forwarding traffic to VM-Series firewall portal services.
· Prioritize changes that allow public or untrusted ingress to locally validated User-ID Authentication Portal or Captive Portal services. Common candidate ports such as TCP 443, TCP 6080, and TCP 6081 should be treated as examples or fallback values, not universal portal-port assumptions.
· Increase priority when the change is performed outside approved change windows, by unexpected principals, from unusual locations, or without corresponding change-management context.
· Treat exposure changes as high-priority remediation and hunting triggers, not standalone proof of exploitation.
Required Telemetry
· Azure Activity logs.
· Network Security Group rule change events.
· Public IP association and update events.
· Route table change events.
· Load balancer, NAT rule, and application gateway listener events where applicable.
· NIC association and configuration events.
· Azure Resource Graph or equivalent resource inventory.
· VM-Series instance, NIC, NSG, route table, public IP, load balancer, and application gateway tags.
· Locally validated User-ID Authentication Portal or Captive Portal port mapping.
· Approved change-window context.
· Approved administrator, service principal, managed identity, or automation context.
· Known approved ingress source ranges.
Engineering Implementation Instructions
· Deploy only for Azure subscriptions and regions where VM-Series firewall inventory is maintained and tagged.
· Treat Azure Activity matches as pre-filter events only. Route matching events to enrichment logic before alert generation.
· Tag VM-Series virtual machines, NICs, NSGs, public IPs, route tables, load balancers, NAT rules, and application gateways with consistent firewall identity and exposure context.
· Validate locally configured User-ID Authentication Portal or Captive Portal ports before production alerting.
· Use locally validated portal ports as the primary port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· Implement approved ingress sources, approved automation identities, approved administrators, approved service principals, and approved change windows as Azure-native watchlists, KQL reference tables, Sentinel watchlists, or enrichment data.
· Use Azure Activity to detect relevant control-plane activity, then enrich with resource tags, NSG rule details, route context, public IP mapping, load balancer mapping, application gateway mapping, NIC mapping, and exposure state before alerting.
· Do not alert on every NSG, route, public IP, load balancer, or application gateway change. Alert only when the affected resource is tied to scoped VM-Series firewall infrastructure and enrichment confirms public or untrusted portal reachability.
· Route alerts at higher priority when exposure changes are followed by suspicious portal traffic, firewall instability, administrative-control anomalies, or firewall-originated outbound anomalies.
DRI Assessment
DRI
8.0 / 10
· The rule is behaviorally anchored to Azure control-plane changes that expose VM-Series firewall portal services.
· The rule remains useful regardless of exploit payload, attacker infrastructure, request shape, or public proof-of-concept changes.
· The score is supported by direct visibility into Azure exposure-changing actions affecting VM-Series infrastructure.
· The score is constrained because exposure change alone does not prove exploitation and requires correlation for compromise classification.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.4 / 10
· Operational confidence depends on Azure Activity coverage, resource inventory quality, asset tagging, NSG enrichment, route context, load balancer mapping, application gateway mapping, local portal-port validation, and change-window validation.
· Operational confidence is reduced where VM-Series assets are poorly tagged, Activity logs are incomplete, ingress paths are not mapped, or public exposure paths are not reconstructed.
· Full-telemetry confidence improves when Azure Activity, Resource Graph, NSG Flow Logs, load balancer logs, application gateway logs, route inventory, and asset inventory are available with consistent firewall identity.
· Even under full telemetry conditions, this rule supports exposure and hunt prioritization, not confirmed compromise by itself.
Limitations
· This rule detects exposure-changing Azure control-plane activity, not confirmed exploitation.
· Azure Activity matches are pre-filter events and must not be treated as alerts without enrichment.
· Legitimate NSG changes, load balancer changes, route changes, public IP changes, application gateway changes, automation activity, and infrastructure deployment may overlap with rule conditions.
· Incomplete asset tagging can weaken VM-Series scoping.
· Custom portal ports, nonstandard ingress designs, and load-balanced paths require local validation.
· Confirmation requires correlation with portal activity, firewall logs, outbound anomalies, administrative anomalies, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
// Azure Activity pre-filter pattern.
// This is not the alert condition. Matching events require enrichment before alerting.
// Validate table names, operation names, resource tags, and watchlists before deployment.
AzureActivity
| where ResourceProviderValue in~ (
"Microsoft.Network",
"Microsoft.Compute"
)
| where OperationNameValue has_any (
"securityRules/write",
"networkSecurityGroups/write",
"networkInterfaces/write",
"publicIPAddresses/write",
"routeTables/write",
"routes/write",
"loadBalancers/write",
"loadBalancers/inboundNatRules/write",
"loadBalancers/loadBalancingRules/write",
"applicationGateways/write",
"virtualMachines/write"
)
| extend AffectedResourceId = tostring(_ResourceId)
| lookup kind=leftouter VMSeriesAzureAssets on $left.AffectedResourceId == $right.ResourceId
| where AssetRole in~ (
"VM-Series Firewall",
"PAN-OS Firewall",
"Palo Alto VM-Series",
"VM-Series NIC",
"VM-Series NSG",
"VM-Series Load Balancer",
"VM-Series Application Gateway",
"VM-Series Route Table"
)
| extend EnrichmentRequired = true
Azure Activity pre-filter handling:
The Azure Activity pattern is not the alert condition. It should route matching
events to enrichment logic.
Required enrichment conditions before alerting:
ResourceTag.Role IN (
"VM-Series Firewall",
"PAN-OS Firewall",
"Palo Alto VM-Series"
)
AND AffectedResource IN (
VM_SERIES_VM_IDS,
VM_SERIES_NIC_IDS,
VM_SERIES_NSG_IDS,
VM_SERIES_PUBLIC_IP_IDS,
VM_SERIES_LOAD_BALANCER_IDS,
VM_SERIES_APPLICATION_GATEWAY_IDS,
VM_SERIES_ROUTE_TABLE_IDS
)
AND ExposureChange = "public_or_untrusted_ingress_enabled"
AND DestinationPort IN (
LOCALLY_VALIDATED_PORTAL_PORTS
)
AND SourceCIDR NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND Caller NOT IN APPROVED_AUTOMATION_OR_ADMIN_IDENTITIES
AND ChangeWindow != "approved"
Optional fallback port review:
Evaluate TCP 443, TCP 6080, and TCP 6081 only when local VM-Series portal
configuration confirms those ports are relevant.
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Rule Format
Azure NSG Flow Logs / Traffic Analytics / Log Analytics KQL correlation pattern requiring VM-Series NIC mapping, enrichment-derived traffic-role classification, flow-direction validation, destination-baseline enrichment, load balancer path validation, and temporal-window tuning before deployment.
Detection Purpose
· Detect suspicious inbound traffic to exposed VM-Series portal services followed by unusual outbound communication from the same VM-Series firewall infrastructure.
· Identify probable post-interaction Azure network behavior without relying on exploit payload strings, packet capture, source reputation alone, or static attacker infrastructure.
· Prioritize firewall-originated outbound communication inconsistent with expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, or management baselines.
· This rule does not confirm unauthorized code execution without corroborating firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Logic
· Identify inbound NSG Flow Log or Traffic Analytics records where untrusted or public sources communicate with scoped VM-Series firewall NICs on locally validated portal services.
· Require the target asset to be a scoped VM-Series firewall NIC, firewall interface, or validated load-balanced path associated with User-ID Authentication Portal or Captive Portal exposure.
· Treat nic_role, flow_path_role, and traffic_role as enrichment-derived fields created from NIC mapping, firewall interface role, route context, asset tagging, flow direction, or validated firewall-path classification. They should not be assumed to exist natively in Azure flow telemetry.
· Correlate inbound portal-directed activity with outbound communication from the same VM-Series firewall NIC, firewall private IP, or validated firewall asset identity within a defensible investigation window.
· Prioritize outbound communication to newly observed, rare, unapproved, or unexpected destinations not associated with expected vendor, logging, telemetry, management, DNS, NTP, update, licensing, or monitoring activity.
· Treat inbound portal traffic alone, public exposure alone, approved scanning, and expected vendor communication as context rather than standalone compromise evidence.
Required Telemetry
· NSG Flow Logs or Traffic Analytics for VM-Series firewall subnets and NICs.
· VM-Series NIC and private IP mapping.
· NIC role enrichment derived from asset inventory, interface mapping, route context, or firewall deployment metadata.
· Traffic-role enrichment for firewall-originated versus through-firewall transit classification.
· Public IP and load balancer mapping where applicable.
· Load balancer access logs, application gateway logs, or backend pool mapping where portal access traverses Azure ingress services.
· Asset tags for VM-Series firewalls.
· Source IP address.
· Destination IP address.
· Source and destination port.
· Protocol.
· Flow direction or equivalent NIC role context.
· Flow action.
· Bytes and packets where available.
· Start and end timestamps.
· Azure DNS logs or DNS proxy telemetry where available.
· Expected firewall egress destination baselines.
· Approved scanner and approved portal-source context.
Engineering Implementation Instructions
· Deploy only where NSG Flow Logs, Traffic Analytics, or equivalent Azure network telemetry can observe inbound portal traffic and firewall-originated outbound communication for scoped VM-Series firewall NICs.
· Validate VM-Series NIC mapping, private IP mapping, public IP mapping, load balancer path mapping, application gateway path mapping, backend pool mapping, and firewall role tagging before deployment.
· Derive nic_role from NIC tags, subnet role, route context, NSG association, firewall interface mapping, or deployment metadata.
· Derive traffic_role from NIC role, source IP mapping, route context, interface role, flow direction, and known firewall management/control-plane paths.
· Confirm that outbound records represent firewall-originated communication rather than ordinary through-firewall transit traffic.
· Use locally validated portal ports as the primary portal-port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· If the portal is exposed through Azure Load Balancer, Application Gateway, Gateway Load Balancer, or another ingress layer, validate that network flow logs alone can preserve the necessary source, target, and firewall identity relationship. Where they cannot, require load balancer logs, application gateway logs, backend pool mapping, or additional enrichment before deploying the rule.
· Implement approved portal sources, approved scanner sources, expected vendor destinations, approved logging destinations, approved management destinations, and expected firewall egress ports as Sentinel watchlists, Log Analytics lookup tables, KQL datatables, or enrichment logic.
· Baseline expected VM-Series egress destinations for update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management.
· Tune the correlation window based on flow-log delivery latency, expected portal use, firewall egress frequency, and SOC triage requirements.
· Route alerts at higher priority when Azure network evidence is supported by PAN-OS logs, configuration changes, device instability, administrative-control anomalies, or visibility reduction.
DRI Assessment
DRI
8.2 / 10
· The rule is behaviorally anchored to suspicious inbound portal activity followed by same-firewall outbound anomaly.
· The rule remains useful if attackers change payload structure, source infrastructure, request timing, or visible exploit characteristics.
· The score is supported by same-asset temporal correlation between exploit-facing Azure ingress and firewall-originated outbound behavior.
· The score is constrained by dependence on NSG Flow Log or Traffic Analytics visibility, NIC mapping, firewall-originated traffic classification, load balancer path validation, and outbound baselining.
TCR Assessment
Operational TCR
6.8 / 10
Full-Telemetry TCR
8.3 / 10
· Operational confidence depends on NSG Flow Log or Traffic Analytics coverage, VM-Series NIC mapping, firewall private-IP mapping, load balancer mapping, application gateway mapping, destination baselining, DNS enrichment, enrichment-derived traffic-role fields, and flow timestamp quality.
· Operational confidence is reduced where flow logs are incomplete, load balancer paths obscure source-to-target relationships, firewall-originated traffic cannot be distinguished from transit traffic, or egress baselines are immature.
· Full-telemetry confidence improves when flow telemetry is enriched with Azure Activity, Azure Resource Graph, Azure DNS logs, load balancer logs, application gateway logs, PAN-OS logs, and asset inventory.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious Azure network behavior associated with possible VM-Series compromise, not confirmed unauthorized code execution.
· NSG Flow Logs and Traffic Analytics do not provide payload visibility and may not expose application-layer portal details.
· Normal update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management activity may overlap with outbound anomaly logic if baselines are incomplete.
· Approved scanning, penetration testing, exposure validation, or legitimate portal use may overlap with suspicious inbound activity.
· Firewall-originated traffic may be difficult to distinguish from through-firewall transit traffic without NIC role mapping, route context, interface-role mapping, and flow-path validation.
· Load-balanced portal paths may obscure the relationship between the external source, ingress component, backend pool, target NIC, and VM-Series firewall unless load balancer logs, application gateway logs, and backend mapping are available.
· Confirmation requires correlation with PAN-OS logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
// Azure Log Analytics / Sentinel KQL support query.
// Validate table names, field names, NIC mapping, enrichment fields, load balancer
// path mapping, timestamps, and watchlists before deployment.
//
// Timestamp assumption:
// This pattern assumes TimeGenerated is a timestamp field. Adjust binning and
// correlation logic based on the flow-log schema in use.
//
// Enrichment assumption:
// nic_role and traffic_role are enrichment-derived fields, not native fields in
// all Azure flow telemetry sources.
let InvestigationWindow = 1h;
let PortalPorts = materialize(LocallyValidatedPortalPorts | project DestinationPort);
let PortalActivity =
AzureNetworkFlow
| where FirewallId in (ScopedVMSeriesFirewalls | project FirewallId)
| where nic_role in~ ("vmseries_firewall", "vmseries_portal_ingress")
| where FlowAction =~ "Allow"
| where DestinationPort in (PortalPorts)
| where SourceIp !in (ApprovedPortalSources | project SourceIp)
| where SourceIp !in (ApprovedScannerSources | project SourceIp)
| project
FirewallId,
PortalTime = TimeGenerated,
PortalSourceIp = SourceIp,
FirewallPrivateIp = DestinationIp,
PortalDestinationPort = DestinationPort,
PortalProtocol = Protocol;
let FirewallEgress =
AzureNetworkFlow
| where FirewallId in (ScopedVMSeriesFirewalls | project FirewallId)
| where nic_role in~ ("vmseries_firewall", "vmseries_management", "vmseries_control_plane")
| where FlowAction =~ "Allow"
| where traffic_role =~ "firewall_originated"
| where DestinationIp !in (ExpectedFirewallVendorDestinations | project DestinationIp)
| where DestinationIp !in (ApprovedLoggingTelemetryDestinations | project DestinationIp)
| where DestinationIp !in (ApprovedManagementDestinations | project DestinationIp)
| where DestinationIp in (NewOrRareDestinations | project DestinationIp)
or DestinationPort !in (ExpectedFirewallEgressPorts | project DestinationPort)
| project
FirewallId,
EgressTime = TimeGenerated,
FirewallSourceIp = SourceIp,
OutboundDestinationIp = DestinationIp,
OutboundDestinationPort = DestinationPort,
OutboundProtocol = Protocol,
Bytes,
Packets;
PortalActivity
| join kind=inner FirewallEgress on FirewallId
| where EgressTime > PortalTime
| where EgressTime <= PortalTime + InvestigationWindow
GCP
Detection Viability Assessment
GCP has two conditional rules for this EXP report.
GCP is viable only for VM-Series firewall deployments hosted in Google Cloud where Cloud Audit Logs, VPC Flow Logs, asset inventory, firewall rule context, external IP mapping, route context, load balancer telemetry, network interface mapping, and firewall identity mapping are available.
GCP is not a detection surface for PA-Series hardware appliances outside Google Cloud telemetry visibility.
GCP rules should focus on cloud-native exposure changes, public ingress paths to User-ID Authentication Portal or Captive Portal services, and firewall-originated outbound anomalies from VM-Series firewall infrastructure.
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Rule Format
GCP Cloud Audit Logs / Security Command Center / Cloud Logging detection pattern supported by mandatory enrichment from Cloud Asset Inventory, VPC firewall rule details, external IP mapping, route context, load balancer mapping, network interface mapping, and VM-Series asset inventory.
Detection Purpose
· Detect GCP control-plane changes that may expose VM-Series User-ID Authentication Portal or Captive Portal services to untrusted networks.
· Identify VPC firewall rule, external IP, route, forwarding rule, target proxy, backend service, load balancer, instance, or network interface changes that create or expand public reachability to scoped VM-Series firewall assets.
· Support exposure detection and urgent remediation without treating exposure alone as confirmed exploitation.
· This rule does not confirm exploitation unless correlated with suspicious portal activity, firewall instability, administrative-control anomalies, outbound anomalies, forensic evidence, or vendor-supported confirmation.
Detection Logic
· Use Cloud Audit Logs to identify control-plane operations that may modify VPC firewall rules, external IP associations, routes, forwarding rules, target proxies, backend services, instance network interfaces, or load balancer paths associated with VM-Series firewall deployments.
· Do not treat the Cloud Audit Logs match alone as the detection. Alert only after enrichment confirms scoped VM-Series infrastructure, portal-relevant ingress, public or untrusted reachability, unapproved source range, and unapproved change context.
· Require the affected resource to be a scoped VM-Series firewall instance, VM-Series network interface, VPC firewall rule, external IP, forwarding rule, backend service, target proxy, route, or load-balanced ingress component forwarding traffic to VM-Series firewall portal services.
· Prioritize changes that allow public or untrusted ingress to locally validated User-ID Authentication Portal or Captive Portal services. Common candidate ports such as TCP 443, TCP 6080, and TCP 6081 should be treated as examples or fallback values, not universal portal-port assumptions.
· Increase priority when the change is performed outside approved change windows, by unexpected principals, from unusual locations, or without corresponding change-management context.
· Treat exposure changes as high-priority remediation and hunting triggers, not standalone proof of exploitation.
Required Telemetry
· GCP Cloud Audit Logs.
· VPC firewall rule change events.
· External IP association and update events.
· Route change events.
· Forwarding rule, backend service, target proxy, URL map, and load balancer change events where applicable.
· Compute instance and network interface change events.
· Cloud Asset Inventory or equivalent resource inventory.
· VM-Series instance, network interface, VPC firewall rule, route, external IP, backend service, forwarding rule, and load balancer labels.
· Locally validated User-ID Authentication Portal or Captive Portal port mapping.
· Approved change-window context.
· Approved user, service account, automation identity, or deployment pipeline context.
· Known approved ingress source ranges.
Engineering Implementation Instructions
· Deploy only for GCP projects and regions where VM-Series firewall inventory is maintained and labeled.
· Treat Cloud Audit Logs matches as pre-filter events only. Route matching events to enrichment logic before alert generation.
· Label VM-Series instances, network interfaces, firewall rules, external IPs, routes, forwarding rules, backend services, target proxies, and load balancer resources with consistent firewall identity and exposure context.
· Validate locally configured User-ID Authentication Portal or Captive Portal ports before production alerting.
· Use locally validated portal ports as the primary port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· Implement approved ingress sources, approved automation identities, approved service accounts, approved users, approved deployment pipelines, and approved change windows as Security Command Center mute rules, Cloud Logging exclusions, BigQuery reference tables, Chronicle reference lists, or enrichment data.
· Use Cloud Audit Logs to detect relevant control-plane activity, then enrich with resource labels, VPC firewall rule details, route context, external IP mapping, forwarding rule mapping, backend service mapping, load balancer mapping, network interface mapping, and exposure state before alerting.
· Do not alert on every VPC firewall rule, route, external IP, forwarding rule, backend service, load balancer, or instance change. Alert only when the affected resource is tied to scoped VM-Series firewall infrastructure and enrichment confirms public or untrusted portal reachability.
· Route alerts at higher priority when exposure changes are followed by suspicious portal traffic, firewall instability, administrative-control anomalies, or firewall-originated outbound anomalies.
DRI Assessment
DRI
8.0 / 10
· The rule is behaviorally anchored to GCP control-plane changes that expose VM-Series firewall portal services.
· The rule remains useful regardless of exploit payload, attacker infrastructure, request shape, or public proof-of-concept changes.
· The score is supported by direct visibility into GCP exposure-changing actions affecting VM-Series infrastructure.
· The score is constrained because exposure change alone does not prove exploitation and requires correlation for compromise classification.
TCR Assessment
Operational TCR
7.0 / 10
Full-Telemetry TCR
8.4 / 10
· Operational confidence depends on Cloud Audit Logs coverage, Cloud Asset Inventory quality, asset labeling, VPC firewall rule enrichment, route context, load balancer mapping, external IP mapping, local portal-port validation, and change-window validation.
· Operational confidence is reduced where VM-Series assets are poorly labeled, audit logs are incomplete, ingress paths are not mapped, or public exposure paths are not reconstructed.
· Full-telemetry confidence improves when Cloud Audit Logs, Cloud Asset Inventory, VPC Flow Logs, load balancer logs, route inventory, and asset inventory are available with consistent firewall identity.
· Even under full telemetry conditions, this rule supports exposure and hunt prioritization, not confirmed compromise by itself.
Limitations
· This rule detects exposure-changing GCP control-plane activity, not confirmed exploitation.
· Cloud Audit Logs matches are pre-filter events and must not be treated as alerts without enrichment.
· Legitimate VPC firewall rule changes, route changes, external IP changes, load balancer changes, automation activity, and infrastructure deployment may overlap with rule conditions.
· Incomplete asset labeling can weaken VM-Series scoping.
· Custom portal ports, nonstandard ingress designs, and load-balanced paths require local validation.
· Confirmation requires correlation with portal activity, firewall logs, outbound anomalies, administrative anomalies, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
Cloud Audit Logs pre-filter pattern.
This is not the alert condition. Matching events require enrichment before alerting.
Log source:
cloudaudit.googleapis.com/activity
Candidate method names:
compute.firewalls.insert
compute.firewalls.patch
compute.firewalls.update
compute.firewalls.delete
compute.instances.setTags
compute.instances.setLabels
compute.instances.addAccessConfig
compute.instances.updateNetworkInterface
compute.routes.insert
compute.routes.patch
compute.routes.update
compute.forwardingRules.insert
compute.forwardingRules.patch
compute.forwardingRules.setTarget
compute.backendServices.insert
compute.backendServices.patch
compute.backendServices.update
compute.targetHttpProxies.insert
compute.targetHttpsProxies.insert
compute.targetTcpProxies.insert
compute.urlMaps.insert
compute.urlMaps.patch
compute.urlMaps.update
Required enrichment conditions before alerting:
ResourceLabel.Role IN (
"VM-Series Firewall",
"PAN-OS Firewall",
"Palo Alto VM-Series"
)
AND AffectedResource IN (
VM_SERIES_INSTANCE_IDS,
VM_SERIES_NETWORK_INTERFACE_IDS,
VM_SERIES_VPC_FIREWALL_RULE_IDS,
VM_SERIES_EXTERNAL_IP_IDS,
VM_SERIES_ROUTE_IDS,
VM_SERIES_FORWARDING_RULE_IDS,
VM_SERIES_BACKEND_SERVICE_IDS,
VM_SERIES_TARGET_PROXY_IDS,
VM_SERIES_LOAD_BALANCER_IDS
)
AND ExposureChange = "public_or_untrusted_ingress_enabled"
AND DestinationPort IN (
LOCALLY_VALIDATED_PORTAL_PORTS
)
AND SourceCIDR NOT IN APPROVED_PORTAL_SOURCE_RANGES
AND PrincipalEmail NOT IN APPROVED_AUTOMATION_OR_ADMIN_IDENTITIES
AND ChangeWindow != "approved"
Optional fallback port review:
Evaluate TCP 443, TCP 6080, and TCP 6081 only when local VM-Series portal
configuration confirms those ports are relevant.
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Rule Format
GCP VPC Flow Logs / Cloud Logging / BigQuery correlation pattern requiring VM-Series network interface mapping, enrichment-derived traffic-role classification, flow-direction validation, destination-baseline enrichment, load balancer path validation, and temporal-window tuning before deployment.
Detection Purpose
· Detect suspicious inbound traffic to exposed VM-Series portal services followed by unusual outbound communication from the same VM-Series firewall infrastructure.
· Identify probable post-interaction GCP network behavior without relying on exploit payload strings, packet capture, source reputation alone, or static attacker infrastructure.
· Prioritize firewall-originated outbound communication inconsistent with expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, or management baselines.
· This rule does not confirm unauthorized code execution without corroborating firewall logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Logic
· Identify inbound VPC Flow Log records where untrusted or public sources communicate with scoped VM-Series firewall network interfaces on locally validated portal services.
· Require the target asset to be a scoped VM-Series firewall network interface, firewall interface, or validated load-balanced path associated with User-ID Authentication Portal or Captive Portal exposure.
· Treat interface_role, flow_path_role, and traffic_role as enrichment-derived fields created from network interface mapping, firewall interface role, route context, asset labels, flow direction, or validated firewall-path classification. They should not be assumed to exist natively in GCP VPC Flow Logs.
· Correlate inbound portal-directed activity with outbound communication from the same VM-Series firewall network interface, firewall private IP, or validated firewall asset identity within a defensible investigation window.
· Prioritize outbound communication to newly observed, rare, unapproved, or unexpected destinations not associated with expected vendor, logging, telemetry, management, DNS, NTP, update, licensing, or monitoring activity.
· Treat inbound portal traffic alone, public exposure alone, approved scanning, and expected vendor communication as context rather than standalone compromise evidence.
Required Telemetry
· VPC Flow Logs for VM-Series firewall subnets and network interfaces.
· VM-Series network interface and private IP mapping.
· Network interface role enrichment derived from asset inventory, interface mapping, route context, or firewall deployment metadata.
· Traffic-role enrichment for firewall-originated versus through-firewall transit classification.
· External IP and load balancer mapping where applicable.
· Cloud Load Balancing logs, backend service mapping, forwarding rule mapping, or target proxy mapping where portal access traverses GCP ingress services.
· Asset labels for VM-Series firewalls.
· Source IP address.
· Destination IP address.
· Source and destination port.
· Protocol.
· Flow direction or equivalent network interface role context.
· Flow action where available.
· Bytes and packets where available.
· Start and end timestamps.
· Cloud DNS logs or DNS proxy telemetry where available.
· Expected firewall egress destination baselines.
· Approved scanner and approved portal-source context.
Engineering Implementation Instructions
· Deploy only where VPC Flow Logs, Cloud Logging, or equivalent GCP network telemetry can observe inbound portal traffic and firewall-originated outbound communication for scoped VM-Series firewall network interfaces.
· Validate VM-Series network interface mapping, private IP mapping, external IP mapping, load balancer path mapping, backend service mapping, forwarding rule mapping, target proxy mapping, and firewall role labeling before deployment.
· Derive interface_role from network interface labels, subnet role, route context, VPC firewall rule association, firewall interface mapping, or deployment metadata.
· Derive traffic_role from interface role, source IP mapping, route context, interface role, flow direction, and known firewall management/control-plane paths.
· Confirm that outbound records represent firewall-originated communication rather than ordinary through-firewall transit traffic.
· Use locally validated portal ports as the primary portal-port list. Treat TCP 443, TCP 6080, and TCP 6081 as candidate fallback values only when confirmed for the deployment.
· If the portal is exposed through External Application Load Balancer, Network Load Balancer, proxy, Gateway Load Balancer pattern, or another ingress layer, validate that network flow logs alone can preserve the necessary source, target, and firewall identity relationship. Where they cannot, require load balancer logs, backend service mapping, forwarding rule mapping, target proxy mapping, or additional enrichment before deploying the rule.
· Implement approved portal sources, approved scanner sources, expected vendor destinations, approved logging destinations, approved management destinations, and expected firewall egress ports as Chronicle reference lists, BigQuery reference tables, Cloud Logging labels, Security Command Center custom modules, or enrichment logic.
· Baseline expected VM-Series egress destinations for update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management.
· Tune the correlation window based on VPC Flow Log delivery latency, expected portal use, firewall egress frequency, and SOC triage requirements.
· Route alerts at higher priority when GCP network evidence is supported by PAN-OS logs, configuration changes, device instability, administrative-control anomalies, or visibility reduction.
DRI Assessment
DRI
8.2 / 10
· The rule is behaviorally anchored to suspicious inbound portal activity followed by same-firewall outbound anomaly.
· The rule remains useful if attackers change payload structure, source infrastructure, request timing, or visible exploit characteristics.
· The score is supported by same-asset temporal correlation between exploit-facing GCP ingress and firewall-originated outbound behavior.
· The score is constrained by dependence on VPC Flow Log visibility, network interface mapping, firewall-originated traffic classification, load balancer path validation, and outbound baselining.
TCR Assessment
Operational TCR
6.8 / 10
Full-Telemetry TCR
8.3 / 10
· Operational confidence depends on VPC Flow Log coverage, VM-Series network interface mapping, firewall private-IP mapping, load balancer mapping, backend service mapping, destination baselining, DNS enrichment, enrichment-derived traffic-role fields, and flow timestamp quality.
· Operational confidence is reduced where flow logs are incomplete, load balancer paths obscure source-to-target relationships, firewall-originated traffic cannot be distinguished from transit traffic, or egress baselines are immature.
· Full-telemetry confidence improves when flow telemetry is enriched with Cloud Audit Logs, Cloud Asset Inventory, Cloud DNS logs, load balancer logs, PAN-OS logs, and asset inventory.
· Even under full telemetry conditions, this rule supports probable exploitation and requires corroboration before confirmed-compromise classification.
Limitations
· This rule detects suspicious GCP network behavior associated with possible VM-Series compromise, not confirmed unauthorized code execution.
· VPC Flow Logs do not provide payload visibility and may not expose application-layer portal details.
· Normal update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management activity may overlap with outbound anomaly logic if baselines are incomplete.
· Approved scanning, penetration testing, exposure validation, or legitimate portal use may overlap with suspicious inbound activity.
· Firewall-originated traffic may be difficult to distinguish from through-firewall transit traffic without network interface role mapping, route context, interface-role mapping, and flow-path validation.
· Load-balanced portal paths may obscure the relationship between the external source, ingress component, backend service, target interface, and VM-Series firewall unless load balancer logs, backend service mapping, forwarding rule mapping, and target proxy mapping are available.
· Confirmation requires correlation with PAN-OS logs, configuration evidence, forensic evidence, vendor-supported findings, or validated incident-response evidence.
Detection Query Pattern
-- GCP BigQuery support query for VPC Flow Logs exported to BigQuery.
-- Validate dataset names, field names, interface mapping, enrichment fields,
-- load balancer path mapping, timestamps, and reference tables before deployment.
--
-- Timestamp assumption:
-- This pattern assumes start_time and end_time are timestamp fields.
-- If using epoch-second fields, replace TIMESTAMP_ADD logic with numeric epoch arithmetic.
--
-- Enrichment assumption:
-- interface_role and traffic_role are enrichment-derived fields, not native fields
-- in all GCP VPC Flow Log schemas.
WITH portal_activity AS (
SELECT
firewall_id,
interface_id,
src_ip AS portal_source_ip,
dest_ip AS firewall_private_ip,
dest_port AS portal_destination_port,
start_time AS portal_start_time,
end_time AS portal_end_time,
action
FROM `PROJECT.DATASET.vpc_flow_logs_enriched`
WHERE
firewall_id IN (SELECT firewall_id FROM `PROJECT.DATASET.scoped_vmseries_firewalls`)
AND interface_role IN ('vmseries_firewall', 'vmseries_portal_ingress')
AND action = 'ACCEPT'
AND dest_port IN (SELECT destination_port FROM `PROJECT.DATASET.locally_validated_portal_ports`)
AND src_ip NOT IN (SELECT source_ip FROM `PROJECT.DATASET.approved_portal_sources`)
AND src_ip NOT IN (SELECT source_ip FROM `PROJECT.DATASET.approved_scanner_sources`)
),
firewall_egress AS (
SELECT
firewall_id,
interface_id,
src_ip AS firewall_source_ip,
dest_ip AS outbound_destination_ip,
dest_port AS outbound_destination_port,
protocol,
bytes_sent AS bytes,
packets_sent AS packets,
start_time AS outbound_start_time,
end_time AS outbound_end_time,
action
FROM `PROJECT.DATASET.vpc_flow_logs_enriched`
WHERE
firewall_id IN (SELECT firewall_id FROM `PROJECT.DATASET.scoped_vmseries_firewalls`)
AND interface_role IN ('vmseries_firewall', 'vmseries_management', 'vmseries_control_plane')
AND action = 'ACCEPT'
AND traffic_role = 'firewall_originated'
AND dest_ip NOT IN (SELECT destination_ip FROM `PROJECT.DATASET.expected_firewall_vendor_destinations`)
AND dest_ip NOT IN (SELECT destination_ip FROM `PROJECT.DATASET.approved_logging_telemetry_destinations`)
AND dest_ip NOT IN (SELECT destination_ip FROM `PROJECT.DATASET.approved_management_destinations`)
AND (
dest_ip IN (SELECT destination_ip FROM `PROJECT.DATASET.new_or_rare_destinations`)
OR dest_port NOT IN (SELECT destination_port FROM `PROJECT.DATASET.expected_firewall_egress_ports`)
)
)
SELECT
p.firewall_id,
p.portal_source_ip,
p.firewall_private_ip,
p.portal_destination_port,
p.portal_start_time,
e.outbound_destination_ip,
e.outbound_destination_port,
e.protocol,
e.bytes,
e.packets,
e.outbound_start_time
FROM portal_activity p
JOIN firewall_egress e
ON p.firewall_id = e.firewall_id
WHERE
e.outbound_start_time > p.portal_start_time
AND e.outbound_start_time <= TIMESTAMP_ADD(p.portal_start_time, INTERVAL 1 HOUR)
S26 — Threat-to-Rule Traceability Matrix
Traceability Purpose
This section maps the primary threat behaviors associated with [EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 to the S25 detection coverage model.
The purpose of this section is to demonstrate that the detection strategy is behaviorally aligned to the threat model, preserves the distinction between exposure, exploit attempt, probable exploitation, and confirmed compromise, and avoids unsupported single-signal compromise claims.
The S25 detection coverage model includes primary, supporting, conditional, and confirmation-only coverage across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, artifact-based coverage, AWS, Azure, and GCP.
Threat Behavior Coverage
Exposed User-ID Authentication Portal or Captive Portal Reachability
Primary Coverage
· AWS.
· Azure.
· GCP.
Supporting Coverage
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
· NDR / Network Behavioral Analytics.
· SentinelOne.
Coverage Type
· Conditional cloud-native exposure detection.
· Remediation and hunt-prioritization support.
· Rule scoping and enrichment for non-cloud systems.
Traceability Assessment
· Covered as an exposure-management and retrospective-hunting trigger.
· Not treated as exploitation or confirmed compromise by itself.
· Cloud-native exposure coverage applies only to VM-Series deployments with validated provider telemetry, asset mapping, ingress-path mapping, and enrichment.
· Exposure state supports prioritization for Splunk, Elastic, QRadar, SIGMA, NDR / Network Behavioral Analytics, and SentinelOne but does not independently establish compromise.
Suspicious Portal-Directed Activity Against Scoped PA-Series or VM-Series Firewalls
Primary Coverage
· NDR / Network Behavioral Analytics.
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Supporting Coverage
· AWS.
· Azure.
· GCP.
Coverage Type
· Cross-platform initiating behavior.
· Exploit-attempt and correlation anchor.
Traceability Assessment
· Covered as the initiating event for correlated detection.
· Supports exploit-attempt alerting when activity is abnormal, targeted, or high-risk.
· Does not support confirmed-compromise classification without follow-on behavior, forensic evidence, vendor-supported evidence, unauthorized configuration evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
· Cloud coverage applies where VM-Series firewall ingress telemetry is available and mapped to the scoped firewall asset.
Suspicious Portal-Directed Activity Followed by Firewall Instability
Primary Coverage
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
· SentinelOne.
Supporting Coverage
· NDR / Network Behavioral Analytics.
Coverage Type
· Primary behavioral correlation.
· High-confidence probable-exploitation pathway.
Traceability Assessment
· Covered by same-firewall temporal correlation between suspicious portal activity and crash, restart, fault, failover, portal interruption, service degradation, or management-plane instability.
· Strong detection path because it does not require payload visibility, static exploit strings, public proof-of-concept artifacts, or attacker infrastructure indicators.
· NDR / Network Behavioral Analytics may increase priority when device instability is available through firewall logs, SIEM enrichment, or adjacent telemetry.
· Still requires corroboration before confirmed-compromise classification.
Suspicious Portal-Directed Activity Followed by Administrative-Control Anomaly
Primary Coverage
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Supporting Coverage
· NDR / Network Behavioral Analytics.
Coverage Type
· Primary behavioral correlation.
· High-confidence probable-exploitation or post-interaction control-plane risk pathway.
Traceability Assessment
· Covered where suspicious portal activity is followed by administrator login anomalies, account changes, privilege changes, commit activity, configuration export, authentication-profile changes, certificate changes, logging changes, policy changes, NAT changes, route changes, or management-setting changes.
· Same-firewall correlation is required before probable-exploitation classification.
· Missing or inconsistently parsed administrator source IP must not suppress otherwise high-value administrative or configuration events.
· Detection supports probable exploitation or post-interaction control-plane risk, not confirmed compromise by itself.
Suspicious Portal-Directed Activity Followed by Configuration Integrity Change
Primary Coverage
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Supporting Coverage
· NDR / Network Behavioral Analytics.
Coverage Type
· Primary behavioral correlation.
· High-confidence post-interaction control-plane risk pathway.
Traceability Assessment
· Covered where suspicious portal activity is followed by unexpected modification to security policy, NAT policy, routing, logging behavior, authentication profiles, certificates, management access, administrative accounts, object configuration, or traffic-enforcement behavior.
· NDR / Network Behavioral Analytics can increase confidence when internal access paths or firewall-mediated traffic changes appear after policy, NAT, route, or configuration changes.
· Configuration integrity changes are strong post-interaction signals when they occur outside approved change windows or expected administrative workflows.
· Confirmation still requires corroborating forensic, vendor-supported, configuration, administrative, or incident-response evidence.
Suspicious Portal-Directed Activity Followed by Visibility Reduction
Primary Coverage
· Splunk.
· Elastic.
· QRadar.
Supporting Coverage
· SentinelOne.
· SIGMA.
· NDR / Network Behavioral Analytics.
Coverage Type
· Primary behavioral correlation where configuration or system telemetry is available.
· Supporting confidence signal for probable exploitation.
Traceability Assessment
· Covered where suspicious portal activity is followed by logging, forwarding, audit, monitoring, or visibility-control changes.
· Strong signal when changes reduce investigative visibility and are not explained by approved maintenance, approved commits, or validated change-management activity.
· SIGMA and SentinelOne support related administrative and configuration-change coverage, while Splunk, Elastic, and QRadar provide the strongest dedicated visibility-reduction detection paths.
· Not sufficient for confirmed-compromise classification without corroboration.
Suspicious Portal-Directed Activity Followed by Firewall-Originated Outbound Anomaly
Primary Coverage
· NDR / Network Behavioral Analytics.
· Splunk.
· Elastic.
· QRadar.
· AWS.
· Azure.
· GCP.
Supporting Coverage
· SentinelOne.
Coverage Type
· Primary behavioral correlation.
· Conditional by firewall-originated traffic visibility, destination baseline quality, and traffic-role validation.
Traceability Assessment
· Covered where suspicious portal activity is followed by outbound communication from the same firewall asset to newly observed, rare, unexplained, or unapproved destinations.
· Strongest when firewall-originated traffic can be distinguished from through-firewall transit traffic.
· Cloud coverage applies only to VM-Series deployments with flow telemetry, interface or ENI or NIC mapping, load balancer path validation, and enrichment-derived traffic-role classification.
· Standalone outbound anomaly without portal linkage remains hunt-grade unless paired with exposure, instability, administrative anomaly, configuration change, visibility reduction, downstream activity, forensic evidence, or vendor-supported confirmation.
Firewall-Originated Communication to New, Rare, or Unexpected Destinations
Primary Coverage
· NDR / Network Behavioral Analytics.
· Splunk.
· Elastic.
· QRadar.
· AWS.
· Azure.
· GCP.
Supporting Coverage
· DNS telemetry.
· Proxy telemetry.
· TLS metadata.
· Cloud flow telemetry.
· NDR enrichment.
· Firewall asset inventory.
Coverage Type
· Primary when correlated to suspicious portal activity.
· Hunt-grade when standalone.
Traceability Assessment
· Covered where outbound baselines exist for update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destinations.
· Detection strength depends on reliable firewall identity, source-IP mapping, interface context, route context, and traffic-role interpretation.
· Should not classify all firewall egress as suspicious.
· Should not classify outbound anomaly alone as confirmed compromise.
Internal Reconnaissance or Newly Observed Firewall-Mediated Access Path After Suspicious Portal Interaction
Primary Coverage
· NDR / Network Behavioral Analytics.
Supporting Coverage
· Splunk.
· Elastic.
· QRadar.
· Identity telemetry.
· Endpoint telemetry.
· Change-management records.
· PAN-OS configuration logs.
Coverage Type
· Conditional downstream behavior coverage.
· Hunt guidance when internal visibility or firewall-mediated path attribution is incomplete.
Traceability Assessment
· Covered only where internal NDR visibility and firewall-mediated path attribution are validated.
· Detection applies to internal reconnaissance, destination fan-out, port fan-out, new internal destination access, new segment access, service-discovery behavior, management-protocol access, or newly observed firewall-mediated access paths.
· Should not be deployed as universal NDR coverage.
· Should be demoted to hunt guidance where internal sensor coverage, route context, segmentation baselines, or path attribution are weak.
Cloud Control-Plane Change Exposing VM-Series Portal Services
Primary Coverage
· AWS.
· Azure.
· GCP.
Supporting Coverage
· Cloud asset inventory.
· Cloud flow logs.
· Load balancer logs.
· PAN-OS logs.
· Route context.
· Public IP mapping.
· Security group, NSG, or VPC firewall rule context.
Coverage Type
· Conditional cloud-native exposure detection.
· VM-Series only.
Traceability Assessment
· Covered for cloud-hosted VM-Series deployments where control-plane telemetry and enrichment are available.
· AWS EventBridge, Azure Activity Logs, and GCP Cloud Audit Logs are pre-filter sources only; enrichment is mandatory before alerting.
· Exposure-changing cloud activity supports remediation and hunt prioritization.
· Cloud exposure change does not establish exploitation or confirmed compromise without correlated portal traffic, firewall instability, administrative-control anomaly, outbound anomaly, forensic evidence, or vendor-supported confirmation.
Cloud Flow Evidence Showing Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Primary Coverage
· AWS.
· Azure.
· GCP.
Supporting Coverage
· PAN-OS logs.
· NDR telemetry.
· DNS telemetry.
· Load balancer logs.
· Route context.
· Asset inventory.
· Interface, ENI, or NIC mapping.
Coverage Type
· Conditional cloud-native behavioral correlation.
· VM-Series only.
Traceability Assessment
· Covered where provider flow telemetry can observe inbound portal traffic and firewall-originated outbound communication from the same VM-Series asset.
· Requires validated interface, ENI, or NIC mapping and enrichment-derived traffic-role classification.
· Requires load balancer or ingress path validation where source-to-target relationships may be obscured.
· Supports probable exploitation only when same-asset temporal correlation and baseline validation are present.
Static Indicator and Payload Artifact Coverage
Primary Coverage
· Supplemental enrichment only when validated.
Supporting Coverage
· Firewall logs.
· Network telemetry.
· Vendor-supported findings.
· Incident-response evidence.
Coverage Type
· Boundary condition.
· Not a mandatory production detection dependency.
Traceability Assessment
· Detection does not depend on static exploit strings, public proof-of-concept fragments, or unvalidated payload details as mandatory conditions.
· Static indicators may be useful as enrichment when validated, but they are not the governing detection model.
· Behavior-led correlation remains the primary coverage path.
File, Memory, Malware, Script, or Persistence Artifact Coverage
Primary Coverage
· Future conditional coverage only if validated artifacts become available.
Supporting Coverage
· Vendor-supported forensic evidence.
· Validated incident-response artifacts.
· Malware samples, scripts, memory objects, or persistence files if confirmed.
Coverage Type
· Boundary condition.
· Future conditional coverage.
Traceability Assessment
· Artifact-based detection is not included in production coverage unless validated file, memory, malware, script, persistence, or stable forensic artifacts become available.
· Current detection coverage should not assume persistence files, malware family identifiers, payload names, file paths, process names, or command strings.
· If validated artifacts emerge, artifact-based coverage can be reassessed and added through the appropriate detection system.
Confirmed Unauthorized Code Execution or Confirmed Compromise
Primary Coverage
· No single S25 detection rule independently confirms compromise.
Supporting Coverage
· Forensic evidence.
· Vendor-supported evidence.
· Unauthorized configuration evidence.
· Unauthorized code execution evidence.
· Malicious persistence.
· Attacker-controlled behavior.
· Validated incident-response findings.
Coverage Type
· Confirmation workflow.
· Outside standalone rule classification.
Traceability Assessment
· S25 rules support detection, triage, hunt prioritization, and probable-exploitation classification.
· Confirmed compromise requires corroboration beyond rule logic.
· This prevents exposure-only, source-reputation-only, affected-version-only, or single-event detections from being overclassified.
Rule-to-Threat Traceability
NDR / Network Behavioral Analytics
Rule
Suspicious PAN-OS Portal Interaction Followed by Firewall-Originated Outbound Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall-originated outbound anomaly.
· New or rare destination communication.
· Abnormal DNS behavior.
· Unexpected TLS endpoint.
· Rare autonomous system.
· Unexpected destination port.
· Unexpected egress path.
· Beacon-like firewall egress behavior.
Evidence Strength
· Supports probable exploitation when suspicious portal activity and outbound anomaly are temporally correlated to the same firewall and outbound behavior is baselined.
Deployment Status
· Deployed where NDR visibility, firewall asset mapping, portal exposure context, outbound baselines, and firewall-originated egress classification are validated.
Traceability Assessment
· Strong coverage for network-observable post-interaction behavior.
· Does not require payload visibility or static exploit signatures.
· Requires reliable distinction between firewall-originated egress and ordinary transit traffic.
NDR / Network Behavioral Analytics
Rule
Suspicious PAN-OS Portal Interaction Followed by Validated Internal Reconnaissance or Newly Observed Access Path
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Validated internal reconnaissance.
· Destination fan-out.
· Port fan-out.
· New internal destination access.
· New segment access.
· Service-discovery behavior.
· Internal management-protocol access.
· Newly observed firewall-mediated access path.
Evidence Strength
· Supports probable post-compromise activity only where internal visibility and firewall-mediated path attribution are validated.
Deployment Status
· Conditional deployment only.
· Hunt guidance where internal NDR visibility, path attribution, segment mapping, or baselining is incomplete.
Traceability Assessment
· Useful for downstream expansion coverage.
· Not universal NDR coverage.
· Requires defensible temporal linkage between portal interaction and internal network behavior.
SentinelOne
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability or Administrative-Control Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall instability.
· Administrative-control anomaly.
· Configuration change.
· Visibility-impacting change.
Evidence Strength
· Supports probable exploitation where PAN-OS traffic, system, administrative, and configuration logs are ingested and correlated by same firewall identity.
Deployment Status
· Conditional deployment only where PAN-OS logs are available in SentinelOne and Deep Visibility or STAR workflow adaptation can preserve same-firewall temporal correlation.
Traceability Assessment
· Correctly scoped as log-correlation coverage.
· Not endpoint-agent detection of direct PAN-OS exploitation.
· Strong conditional coverage where PAN-OS logs are normalized and queryable inside SentinelOne.
Splunk
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall crash.
· Firewall restart.
· Fault event.
· Failover activity.
· Portal interruption.
· Service degradation.
· Management-plane instability.
Evidence Strength
· Supports probable exploitation when same-firewall temporal correlation is validated.
Deployment Status
· Deployed where PAN-OS traffic, threat, and system logs are ingested with validated field normalization and lookup context.
Traceability Assessment
· Strong rule-grade coverage for exploit-facing activity followed by device-health impact.
· Does not require exploit payload visibility.
Splunk
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Administrator login anomaly.
· Account change.
· Privilege change.
· Commit activity.
· Configuration export.
· Authentication-profile change.
· Certificate change.
· Policy change.
· NAT change.
· Route change.
· Management-setting change.
Evidence Strength
· Supports probable exploitation or post-interaction control-plane risk when same-firewall correlation is validated.
Deployment Status
· Deployed where PAN-OS traffic, administrative audit, configuration, and system logs support same-firewall correlation.
Traceability Assessment
· Strong control-plane integrity coverage.
· Requires tuning for approved administrator sources, approved maintenance, automation, Panorama-driven commits, backups, certificate renewal, and policy deployment workflows.
Splunk
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall-originated outbound anomaly.
· Logging change.
· Forwarding change.
· Audit visibility change.
· Monitoring change.
· Visibility-control modification.
Evidence Strength
· Supports probable exploitation when same-firewall correlation and firewall-originated egress classification are validated.
Deployment Status
· Deployed where firewall-originated outbound traffic can be distinguished from transit traffic and visibility-reduction events are mapped.
Traceability Assessment
· Strong coverage for post-interaction egress and stealth-enabling changes.
· Requires destination baselines and careful suppression of known vendor, logging, telemetry, and management destinations.
Elastic
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall instability.
· System-health impact.
· Service degradation.
· Portal interruption.
· Management-plane instability.
Evidence Strength
· Supports probable exploitation where ECS or custom field mappings preserve same-firewall sequence correlation.
Deployment Status
· Deployed with Elastic EQL sequence validation, PAN-OS integration validation, scoped firewall asset inventory, exception-list validation, and enrichment-field validation.
Traceability Assessment
· Strong sequence-based coverage for portal activity followed by device-health impact.
· Requires reliable observer identity and event normalization.
Elastic
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Administrative-control anomaly.
· Configuration integrity change.
· Commit anomaly.
· Configuration export.
· Authentication-profile change.
· Certificate change.
· Policy, NAT, route, logging, or management-setting change.
Evidence Strength
· Supports probable exploitation or post-interaction control-plane risk when same-firewall EQL sequence correlation is validated.
Deployment Status
· Deployed where PAN-OS administrative and configuration events are mapped to ECS or locally validated custom fields.
Traceability Assessment
· Strong control-plane coverage.
· Should not suppress high-value administrative or configuration events solely because administrator source IP is missing.
Elastic
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall-originated outbound anomaly.
· New or rare destination.
· Rare domain.
· Rare ASN.
· Unexpected egress port.
· Visibility-reduction event.
Evidence Strength
· Supports probable exploitation when same-firewall sequence correlation and traffic-role validation are present.
Deployment Status
· Deployed where firewall-originated traffic classification, observer identity, firewall source-IP mapping, and destination-baseline exception lists are validated.
Traceability Assessment
· Strong egress and visibility-reduction coverage.
· Requires reliable distinction between firewall-originated traffic and through-firewall transit traffic.
QRadar
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall crash.
· Restart.
· Fault.
· Failover.
· Portal interruption.
· Service degradation.
· Management-plane instability.
Evidence Strength
· Supports probable exploitation when QRadar CRE correlation links portal-activity and instability building blocks on the same firewall.
Deployment Status
· Deployed as CRE and building-block correlation with AQL used for validation, hunting, and rule support.
Traceability Assessment
· Strong QRadar-native coverage.
· AQL support patterns should not replace CRE same-firewall temporal correlation.
QRadar
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Administrator login anomaly.
· Account change.
· Privilege change.
· Commit activity.
· Configuration export.
· Authentication-profile change.
· Certificate change.
· Logging change.
· Policy change.
· NAT change.
· Route change.
· Management-setting change.
Evidence Strength
· Supports probable exploitation or post-interaction control-plane risk where CRE correlation links portal-activity and administrative/configuration building blocks.
Deployment Status
· Deployed as CRE and building-block correlation with validated DSM parsing, custom properties, QIDs, reference sets, and timestamp handling.
Traceability Assessment
· Strong native SIEM correlation coverage.
· Administrative source IP should be used for tuning but not required for every high-value event.
QRadar
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall-Originated Outbound Anomaly or Visibility Reduction
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Firewall-originated outbound anomaly.
· Rare or new destination.
· Logging change.
· Forwarding change.
· Audit visibility change.
· Monitoring change.
· Visibility-control modification.
Evidence Strength
· Supports probable exploitation when CRE correlation links portal activity to outbound anomaly or visibility reduction on the same firewall.
Deployment Status
· Deployed as CRE and building-block correlation with AQL support after flow, asset, custom property, and reference-set validation.
Traceability Assessment
· Strong QRadar-native coverage when firewall-originated flow classification is reliable.
· Requires reference sets and building blocks for expected destinations, rare destinations, scoped firewall IPs, approved management destinations, and approved logging or telemetry destinations.
SIGMA
Rule
Suspicious PAN-OS Portal Activity Followed by Firewall Instability
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Same-firewall instability.
· Crash, restart, fault, failover, portal interruption, service failure, or management-plane instability.
Evidence Strength
· Supports probable exploitation where backend correlation semantics are preserved.
Deployment Status
· Portable correlation pattern requiring backend support for same-firewall grouping, sequence ordering, temporal correlation, field mapping, and exception handling.
Traceability Assessment
· Useful portable coverage where the target backend can preserve sequence behavior.
· Should be converted into native SIEM logic where SIGMA conversion cannot preserve correlation.
SIGMA
Rule
Suspicious PAN-OS Portal Activity Followed by Administrative-Control or Configuration Integrity Anomaly
Threat Behaviors Covered
· Suspicious portal-directed activity.
· Same-firewall administrative-control anomaly.
· Configuration integrity anomaly.
· Commit activity.
· Configuration export.
· Account or privilege change.
· Authentication-profile, certificate, logging, policy, NAT, route, or management-setting change.
Evidence Strength
· Supports probable exploitation where backend correlation semantics are preserved.
Deployment Status
· Portable correlation pattern requiring backend support for same-firewall grouping, sequence ordering, temporal correlation, field mapping, and exception handling.
Traceability Assessment
· Useful portable control-plane traceability.
· Requires backend correlation support or native SIEM implementation where conversion cannot preserve sequence behavior.
Artifact-Based Coverage
Rule
Future conditional coverage only
Threat Behaviors Covered
· File artifact matching if validated.
· Memory artifact matching if validated.
· Malware payload matching if validated.
· Script sample matching if validated.
· Persistence artifact matching if validated.
· Stable forensic object matching if validated.
Evidence Strength
· Future conditional.
· Not included in production coverage without validated artifacts.
Deployment Status
· Not deployed as production coverage unless validated artifacts become available.
Traceability Assessment
· Current detection relies on behavior-led correlation rather than unvalidated artifacts.
· Future artifact-based coverage can be added if validated forensic, vendor-supported, or incident-response artifacts emerge.
AWS
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Threat Behaviors Covered
· AWS control-plane exposure change.
· Security group change.
· Public IP association.
· Route change.
· Load balancer or target group change.
· Public or untrusted ingress path to VM-Series portal services.
Evidence Strength
· Exposure and hunt trigger.
· Not exploitation by itself.
Deployment Status
· Conditional VM-Series deployment only.
· EventBridge pre-filter plus mandatory enrichment.
Traceability Assessment
· Strong cloud-native exposure coverage for AWS VM-Series environments.
· Requires CloudTrail, AWS Config or equivalent inventory, tags, route context, public IP mapping, load balancer mapping, and locally validated portal ports.
AWS
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Threat Behaviors Covered
· Inbound portal traffic.
· VM-Series firewall-originated outbound anomaly.
· New or rare destination.
· Unexpected egress port.
· Unapproved destination inconsistent with expected firewall egress baselines.
Evidence Strength
· Supports probable exploitation when ENI mapping, VPC Flow Logs, traffic-role enrichment, destination baselines, and same-firewall temporal correlation are validated.
Deployment Status
· Conditional VM-Series deployment only.
Traceability Assessment
· Strong conditional AWS behavioral coverage.
· Requires validated ENI role, traffic role, load balancer path mapping, and firewall-originated egress classification.
Azure
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Threat Behaviors Covered
· Azure control-plane exposure change.
· NSG change.
· Public IP association.
· Route table change.
· Load balancer, NAT rule, application gateway, or NIC change.
· Public or untrusted ingress path to VM-Series portal services.
Evidence Strength
· Exposure and hunt trigger.
· Not exploitation by itself.
Deployment Status
· Conditional VM-Series deployment only.
· Azure Activity Log pre-filter plus mandatory enrichment.
Traceability Assessment
· Strong cloud-native exposure coverage for Azure VM-Series environments.
· Requires resource inventory, tags, route context, public IP mapping, load balancer or application gateway mapping, NIC mapping, and locally validated portal ports.
Azure
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Threat Behaviors Covered
· Inbound portal traffic.
· VM-Series firewall-originated outbound anomaly.
· New or rare destination.
· Unexpected egress port.
· Unapproved destination inconsistent with expected firewall egress baselines.
Evidence Strength
· Supports probable exploitation when NIC mapping, flow telemetry, traffic-role enrichment, destination baselines, and same-firewall temporal correlation are validated.
Deployment Status
· Conditional VM-Series deployment only.
Traceability Assessment
· Strong conditional Azure behavioral coverage.
· Requires validated NIC role, traffic role, load balancer or application gateway path mapping, and firewall-originated egress classification.
GCP
Rule
VM-Series Portal Exposure Change Enabling Public Access to PAN-OS Authentication Portal Services
Threat Behaviors Covered
· GCP control-plane exposure change.
· VPC firewall rule change.
· External IP association.
· Route change.
· Forwarding rule, target proxy, backend service, or load balancer change.
· Public or untrusted ingress path to VM-Series portal services.
Evidence Strength
· Exposure and hunt trigger.
· Not exploitation by itself.
Deployment Status
· Conditional VM-Series deployment only.
· Cloud Audit Logs pre-filter plus mandatory enrichment.
Traceability Assessment
· Strong cloud-native exposure coverage for GCP VM-Series environments.
· Requires Cloud Asset Inventory or equivalent inventory, labels, route context, external IP mapping, load balancer mapping, network interface mapping, and locally validated portal ports.
GCP
Rule
Suspicious Inbound Portal Traffic Followed by VM-Series Firewall-Originated Outbound Anomaly
Threat Behaviors Covered
· Inbound portal traffic.
· VM-Series firewall-originated outbound anomaly.
· New or rare destination.
· Unexpected egress port.
· Unapproved destination inconsistent with expected firewall egress baselines.
Evidence Strength
· Supports probable exploitation when network interface mapping, VPC Flow Logs, traffic-role enrichment, destination baselines, and same-firewall temporal correlation are validated.
Deployment Status
· Conditional VM-Series deployment only.
Traceability Assessment
· Strong conditional GCP behavioral coverage.
· Requires validated interface role, traffic role, load balancer path mapping, and firewall-originated egress classification.
Coverage Classification
Primary Behavioral Correlation
Covered Behaviors
· Suspicious portal-directed activity followed by firewall instability.
· Suspicious portal-directed activity followed by administrative-control anomaly.
· Suspicious portal-directed activity followed by configuration integrity change.
· Suspicious portal-directed activity followed by visibility reduction.
· Suspicious portal-directed activity followed by firewall-originated outbound anomaly.
Rule Systems
· NDR / Network Behavioral Analytics.
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Assessment
· This is the strongest S25 coverage category.
· It supports probable-exploitation classification when correlation is validated.
· It does not independently establish confirmed compromise.
Conditional Cloud-Native Coverage
Covered Behaviors
· VM-Series portal exposure changes.
· Cloud-flow evidence of inbound portal traffic followed by firewall-originated outbound anomaly.
Rule Systems
· AWS.
· Azure.
· GCP.
Assessment
· Strong conditional coverage for VM-Series deployments.
· Does not apply to non-cloud PA-Series hardware.
· Requires cloud telemetry, asset mapping, ingress-path validation, interface mapping, enrichment logic, and traffic-role classification.
Conditional Internal Expansion Coverage
Covered Behaviors
· Internal reconnaissance after suspicious portal interaction.
· Newly observed access path.
· Firewall-mediated east-west behavior.
· Destination or port fan-out.
· Internal management-protocol access.
Rule Systems
· NDR / Network Behavioral Analytics.
Assessment
· Valid only where internal visibility and firewall-mediated path attribution are validated.
· Should remain hunt guidance when visibility or attribution is incomplete.
Portable Correlation Coverage
Covered Behaviors
· Suspicious portal activity followed by instability.
· Suspicious portal activity followed by administrative-control or configuration integrity anomaly.
Rule Systems
· SIGMA.
Assessment
· Useful where backend conversion preserves same-firewall grouping, temporal correlation, sequence ordering, and exception handling.
· Should be implemented directly in the target SIEM where SIGMA conversion cannot preserve correlation semantics.
Artifact-Based Coverage
Covered Behaviors
· File artifact matching.
· Memory artifact matching.
· Malware payload matching.
· Script sample matching.
· Persistence artifact matching.
· Stable forensic object matching.
Rule Systems
· Future conditional artifact-based coverage.
Assessment
· Not included in production coverage without validated artifacts.
· Future conditional coverage requires vendor-supported forensic evidence or validated incident-response artifacts.
Confirmation Coverage
Covered Behaviors
· Unauthorized code execution.
· Malicious persistence.
· Unauthorized configuration activity.
· Attacker-controlled behavior.
· Vendor-supported compromise evidence.
· Validated incident-response findings.
Rule Systems
· No single S25 detection rule.
Assessment
· Confirmation remains an incident-response and forensic classification.
· S25 rules support detection, triage, and probable-exploitation classification.
· Confirmed compromise requires corroboration beyond detection logic.
Threat-Stage Traceability
Exposure
Detection Objective
· Identify externally reachable User-ID Authentication Portal or Captive Portal services.
Mapped S25 Rule Coverage
· AWS Rule 1.
· Azure Rule 1.
· GCP Rule 1.
· Exposure context inside Splunk, Elastic, QRadar, SIGMA, NDR / Network Behavioral Analytics, and SentinelOne.
Expected Alert Classification
· Exposed.
· Remediation trigger.
· Retrospective-hunting trigger.
Exploit Attempt
Detection Objective
· Identify suspicious portal-directed activity without confirmed follow-on behavior.
Mapped S25 Rule Coverage
· Portal activity stages across Splunk, Elastic, QRadar, SIGMA, NDR / Network Behavioral Analytics, SentinelOne, AWS Rule 2, Azure Rule 2, and GCP Rule 2.
Expected Alert Classification
· Attempted exploitation.
· Hunt trigger.
· Elevated triage when source-risk and exposure context are present.
Probable Exploitation
Detection Objective
· Correlate suspicious portal activity with instability, administrative anomaly, configuration change, visibility reduction, outbound anomaly, or downstream activity.
Mapped S25 Rule Coverage
· NDR / Network Behavioral Analytics Rules 1–2.
· SentinelOne Rule 1.
· Splunk Rules 1–3.
· Elastic Rules 1–3.
· QRadar Rules 1–3.
· SIGMA Rules 1–2.
· AWS Rule 2.
· Azure Rule 2.
· GCP Rule 2.
Expected Alert Classification
· Probable exploitation.
Post-Exploitation Activity
Detection Objective
· Identify control-plane tampering, visibility reduction, outbound communication, internal reconnaissance, or newly observed access paths after suspicious portal activity.
Mapped S25 Rule Coverage
· NDR / Network Behavioral Analytics Rule 2.
· SentinelOne Rule 1.
· Splunk Rules 2–3.
· Elastic Rules 2–3.
· QRadar Rules 2–3.
Expected Alert Classification
· Probable post-compromise activity.
· Requires corroboration before confirmed-compromise classification.
Confirmed Compromise
Detection Objective
· Confirm unauthorized code execution, malicious persistence, unauthorized configuration activity, attacker-controlled behavior, or vendor-supported compromise evidence.
Mapped S25 Rule Coverage
· No standalone S25 rule.
· Incident-response and forensic confirmation required.
Expected Alert Classification
· Confirmed compromise only when corroborating evidence is present.
Coverage Boundaries
Static Indicator Boundary
Boundary
Detection does not depend on static exploit strings, public proof-of-concept fragments, attacker infrastructure, or unvalidated payload details as mandatory detection conditions.
Operational Handling
· Use validated static indicators only as supplemental enrichment.
· Preserve behavior-led correlation as the primary detection model.
Exposure Boundary
Boundary
Portal exposure creates urgent remediation and hunting requirements, but exposure alone does not establish exploitation.
Operational Handling
· Use exposure findings for access restriction, mitigation validation, patch prioritization, and retrospective hunting.
· Require suspicious activity and follow-on behavior before probable-exploitation classification.
Source Context Boundary
Boundary
Source reputation and source-risk context support prioritization but do not independently establish exploitation or compromise.
Operational Handling
· Use source context as enrichment.
· Require behavioral correlation before escalating to probable exploitation.
Affected-Version Boundary
Boundary
Affected-version inventory supports exposure management and remediation prioritization but does not establish exploitation.
Operational Handling
· Use affected-version inventory for scope, prioritization, and retrospective hunting.
· Require activity-based evidence for exploit-attempt or probable-exploitation classification.
Cloud Coverage Boundary
Boundary
Cloud-native coverage applies only to VM-Series deployments where cloud telemetry, asset mapping, interface mapping, ingress-path mapping, and enrichment are available.
Operational Handling
· Apply AWS, Azure, and GCP detections only to validated VM-Series deployments.
· Use firewall-native and network-adjacent telemetry for non-cloud firewall coverage.
Artifact-Based Coverage Boundary
Boundary
Artifact-based detection is not included in production coverage unless validated file, memory, malware, script, persistence, or forensic artifacts become available.
Operational Handling
· Use behavioral correlation as the primary detection model.
· Reassess artifact-based coverage if vendor-supported forensic evidence or validated incident-response artifacts emerge.
Confirmation Boundary
Boundary
No single detection rule should independently classify confirmed compromise.
Operational Handling
· Confirmed compromise requires forensic evidence, vendor-supported evidence, unauthorized configuration evidence, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
Traceability Summary
The S25 rule set provides strong coverage for the highest-value detection paths: suspicious portal-directed activity correlated with firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, firewall-originated outbound anomalies, and conditional downstream activity.
The traceability mapping confirms that production coverage is aligned to durable behavior rather than brittle exploit strings, attacker infrastructure, affected-version inventory, packet payloads, endpoint-agent assumptions, or exposure-only logic.
Cloud-native rules provide conditional VM-Series coverage where provider telemetry, asset mapping, interface mapping, load balancer path validation, and enrichment-derived traffic-role classification are available.
Artifact-based coverage remains future conditional and should be added only if validated artifacts become available.
Confirmed compromise remains outside the scope of any single detection rule and requires forensic evidence, vendor-supported evidence, unauthorized configuration evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
S27 — Behavior & Log Artifacts
Artifact Purpose
This section identifies the behavior artifacts, log artifacts, enrichment artifacts, and investigative artifacts required to detect, triage, and validate suspected exploitation of PAN-OS User-ID Authentication Portal or Captive Portal exposure.
The artifact model supports the detection strategy by mapping observable evidence to suspicious portal-directed activity, firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, firewall-originated outbound anomalies, conditional downstream activity, and conditional VM-Series cloud exposure paths.
Artifact Interpretation Standard
Artifacts must be interpreted according to evidence strength.
Exposure artifacts identify risk and remediation urgency.
Portal-interaction artifacts may support exploit-attempt classification.
Post-interaction artifacts may support probable-exploitation classification when correlated with suspicious portal activity.
Confirmed-compromise classification requires forensic evidence, vendor-supported evidence, unauthorized configuration evidence, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
Portal Exposure Artifacts
Behavior
User-ID Authentication Portal or Captive Portal services are enabled and reachable from untrusted networks, internet-originating sources, cloud ingress paths, external load balancers, permissive security policies, or unmanaged scanning infrastructure.
Expected Log Artifacts
· PAN-OS configuration records showing User-ID Authentication Portal or Captive Portal enablement.
· Interface, zone, or policy records showing portal reachability.
· Security policy records permitting access to portal-relevant services.
· NAT, route, or public ingress records exposing the portal path.
· External attack-surface findings showing portal reachability.
· Cloud security group, NSG, VPC firewall rule, public IP, route, load balancer, forwarding rule, application gateway, or backend service records for VM-Series deployments.
Primary Investigative Value
· Establishes exposure state.
· Supports remediation urgency.
· Defines retrospective hunting scope.
· Does not establish exploitation or compromise by itself.
Portal-Directed Traffic Artifacts
Behavior
Untrusted, internet-originating, newly observed, scanner-associated, anonymized, cloud-hosted, or otherwise unexpected sources interact with exposed User-ID Authentication Portal or Captive Portal services.
Expected Log Artifacts
· PAN-OS traffic logs showing inbound connections to scoped PA-Series or VM-Series firewall assets.
· PAN-OS threat logs where available.
· Portal access logs where available.
· Source IP address.
· Destination IP address.
· Source zone.
· Destination zone.
· Interface.
· Application or service field.
· URL path or portal indicator where available.
· Rule name.
· Destination port.
· Session duration.
· Byte and packet volume.
· Timestamp.
· NDR flow records observing traffic to the firewall.
· Cloud flow records for VM-Series deployments.
Primary Investigative Value
· Supports exploit-attempt classification when activity is abnormal, targeted, or high-risk.
· Serves as the initiating event for correlation with post-interaction behavior.
· Must not be treated as confirmed compromise without corroborating evidence.
Source-Risk Artifacts
Behavior
Portal-directed traffic originates from sources that are unexpected, newly observed, scanner-associated, anonymized, cloud-hosted, VPN-associated, residential-proxy-associated, geographically unusual, or inconsistent with expected portal use.
Expected Log Artifacts
· Source-risk enrichment.
· Newly observed source records.
· Scanner or exposure-management classification.
· GeoIP enrichment.
· ASN enrichment.
· Hosting-provider or cloud-provider enrichment.
· VPN, proxy, or anonymization indicators.
· Approved portal-source lookup results.
· Approved scanner-source lookup results.
· Known business portal-use source context.
Primary Investigative Value
· Supports prioritization and source triage.
· Helps distinguish expected portal use from suspicious access.
· Must not be used as the sole basis for compromise classification.
Firewall Instability Artifacts
Behavior
Firewall instability, crash, restart, failover, service degradation, portal interruption, dataplane degradation, management-plane instability, or repeated fault activity occurs near suspicious portal-directed traffic.
Expected Log Artifacts
· PAN-OS system logs.
· Crash records.
· Fault records.
· Restart records.
· HA failover records.
· Portal service interruption messages.
· Management-plane health events.
· Dataplane or inspection-health events.
· Service unavailable messages.
· Service failed messages.
· Resource pressure or control-plane degradation indicators.
· Vendor-supported diagnostic references where available.
· Timestamped event sequence relative to suspicious portal activity.
Primary Investigative Value
· Strong probable-exploitation signal when temporally linked to suspicious portal activity.
· Does not require payload visibility.
· Requires maintenance-window and operational-change validation before escalation.
Administrative-Control Artifacts
Behavior
Administrative activity occurs after suspicious portal interaction and appears unexpected, anomalous, unauthorized, or inconsistent with normal firewall administration.
Expected Log Artifacts
· PAN-OS administrative audit logs.
· Administrator login records.
· Failed administrator authentication bursts.
· Successful administrator login from unusual source.
· New administrator account.
· Modified administrator account.
· Privilege change.
· Role assignment change.
· Authentication-profile assignment.
· Administrator source IP where available.
· Administrator username where available.
· Privileged-access-management records where available.
· Identity-provider records tied to firewall administration.
· Timestamped relationship to suspicious portal activity.
Primary Investigative Value
· Supports probable exploitation or post-interaction control-plane risk when correlated with suspicious portal activity.
· Must not be suppressed solely because administrator source IP is missing or inconsistently parsed.
· Requires validation against approved administrator sources, approved workflows, and approved change windows.
Configuration Integrity Artifacts
Behavior
Configuration, enforcement, trust, routing, NAT, logging, certificate, authentication-profile, or management-setting changes occur after suspicious portal interaction.
Expected Log Artifacts
· PAN-OS configuration logs.
· Commit history.
· Configuration diff records.
· Configuration export records.
· Configuration import records.
· Security policy changes.
· NAT policy changes.
· Route changes.
· Object changes.
· Authentication-profile changes.
· Certificate changes.
· TLS profile changes.
· Management access changes.
· Logging profile changes.
· Syslog destination changes.
· Monitoring destination changes.
· Commit user.
· Commit source.
· Commit timestamp.
· Change-management reference where available.
Primary Investigative Value
· Strong post-interaction control-plane signal.
· Supports probable-exploitation classification when temporally linked to suspicious portal activity.
· Requires validation against approved maintenance, expected automation, Panorama-driven commits, certificate renewal, backup activity, and scheduled policy deployment.
Visibility-Reduction Artifacts
Behavior
Logging, forwarding, audit, monitoring, or telemetry configuration is reduced, disabled, redirected, weakened, or altered near suspicious portal activity.
Expected Log Artifacts
· Log-forwarding configuration changes.
· Syslog destination changes.
· Traffic logging changes.
· Threat logging changes.
· Administrative audit logging changes.
· Monitoring profile changes.
· Visibility-related policy changes.
· Telemetry destination changes.
· Alert forwarding changes.
· Configuration commits tied to visibility-control objects.
· System logs showing log forwarding failure or interruption.
· Timestamped relationship to portal activity or administrative anomaly.
Primary Investigative Value
· High-value supporting signal because reduced visibility may indicate stealth or post-compromise operational preparation.
· Stronger when paired with administrative-control anomaly, configuration integrity change, or outbound anomaly.
· Requires approved-change validation before escalation.
Firewall-Originated Outbound Artifacts
Behavior
The firewall initiates outbound communication to newly observed, rare, unexplained, or unapproved destinations after suspicious portal-directed activity.
Expected Log Artifacts
· PAN-OS traffic logs showing firewall-originated communication.
· NDR flow records showing outbound traffic from firewall infrastructure.
· NetFlow or equivalent network records.
· DNS query records from firewall infrastructure.
· TLS metadata where available.
· Proxy or egress telemetry where available.
· Destination IP address.
· Destination domain.
· Destination port.
· Protocol.
· ASN.
· Session duration.
· Byte volume.
· Packet volume.
· Egress interface or path.
· Firewall source IP mapping.
· Traffic-role or firewall-originated indicator where available.
· Expected vendor, update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management destination baseline.
Primary Investigative Value
· Strong probable-exploitation signal when linked to suspicious portal activity.
· Requires reliable distinction between firewall-originated traffic and through-firewall transit traffic.
· Requires destination baselining to avoid false positives from normal firewall operations.
Downstream Activity Artifacts
Behavior
Internal reconnaissance, newly observed access paths, destination fan-out, port fan-out, internal management-protocol access, credential-use anomalies, or unusual east-west communication occurs after suspicious firewall interaction.
Expected Log Artifacts
· NDR internal flow records.
· Internal segment or zone flow records.
· Firewall-mediated path telemetry.
· Route and NAT change context.
· Destination fan-out artifacts.
· Port fan-out artifacts.
· New destination access records.
· Internal management-protocol usage.
· Identity-provider logs.
· Endpoint telemetry from affected internal systems where available.
· Administrator workstation telemetry.
· Change-management records.
· Timestamped linkage to suspicious firewall interaction.
Primary Investigative Value
· Supports probable post-compromise activity only when internal visibility and firewall-mediated path attribution are validated.
· Should remain hunt guidance where internal path attribution is incomplete.
· Requires corroboration before confirmed-compromise classification.
Cloud Control-Plane Artifacts
Behavior
For VM-Series deployments, cloud control-plane changes create or expand public reachability to portal services or alter firewall traffic paths.
Expected Log Artifacts
· AWS CloudTrail management events.
· Azure Activity logs.
· GCP Cloud Audit Logs.
· Security group changes.
· NSG changes.
· VPC firewall rule changes.
· Route table changes.
· Public IP association events.
· External IP association events.
· Load balancer listener changes.
· Target group or backend service changes.
· Forwarding rule changes.
· Application gateway changes.
· ENI, NIC, or network interface changes.
· Resource tags or labels.
· Asset inventory records.
· Approved automation identity context.
· Approved change-window context.
Primary Investigative Value
· Supports cloud exposure detection and remediation.
· Supports hunt prioritization for VM-Series deployments.
· Does not establish exploitation without correlated portal activity, instability, administrative anomaly, outbound anomaly, forensic evidence, or vendor-supported confirmation.
Cloud Flow Artifacts
Behavior
For VM-Series deployments, inbound portal traffic is followed by firewall-originated outbound anomaly from the same cloud-hosted firewall asset.
Expected Log Artifacts
· AWS VPC Flow Logs.
· Azure NSG Flow Logs or Traffic Analytics.
· GCP VPC Flow Logs.
· Cloud load balancer logs where applicable.
· Application gateway logs where applicable.
· Backend service or target group mapping.
· Interface, ENI, or NIC mapping.
· Firewall private IP mapping.
· Firewall public IP mapping.
· Enrichment-derived interface role.
· Enrichment-derived traffic role.
· Source IP address.
· Destination IP address.
· Destination port.
· Protocol.
· Flow action.
· Bytes and packets where available.
· Flow timestamp.
· Expected destination baseline.
Primary Investigative Value
· Supports conditional VM-Series probable-exploitation detection.
· Requires validated same-asset mapping and traffic-role classification.
· Requires load balancer or ingress-path validation when source-to-target relationships are obscured.
Artifact Boundaries
Unvalidated Payload Details
Boundary
Public proof-of-concept strings, exploit fragments, or unvalidated request patterns should not be required as mandatory production detection conditions.
Operational Handling
· Use validated static details only as supplemental enrichment.
· Preserve behavior-led correlation as the primary detection approach.
Standalone Source Context
Boundary
Source reputation and source-risk context support prioritization but do not independently establish exploitation.
Operational Handling
· Use source context as enrichment.
· Require behavioral correlation before escalating to probable exploitation.
Affected-Version Inventory
Boundary
Affected-version inventory identifies exposure and remediation priority but does not prove exploitation.
Operational Handling
· Use affected-version inventory for scoping, prioritization, and retrospective hunting.
· Require activity-based evidence for exploit-attempt or probable-exploitation classification.
Artifact-Based Matching
Boundary
Artifact-based matching should not be included in production coverage unless validated artifacts become available.
Operational Handling
· Use behavioral correlation as the primary detection model.
· Reassess artifact-based coverage if vendor-supported forensic evidence or validated incident-response artifacts emerge.
Artifact Summary
The strongest artifact paths are behavioral and correlation-ready.
They include suspicious portal-directed traffic, firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, firewall-originated outbound anomalies, conditional downstream activity, and conditional VM-Series cloud exposure and cloud-flow evidence.
The artifact model intentionally avoids dependence on payload strings, endpoint-agent telemetry from the firewall, full packet capture, source reputation alone, affected-version inventory alone, and unsupported forensic assumptions.
S28 — Detection Strategy and SOC Implementation Guidance
Figure 5
Implementation Purpose
This section provides operational guidance for implementing the Block 4 detection strategy in a SOC environment. It translates the detection model, primary artifacts, and S25 rule inventory into alerting, triage, tuning, escalation, and response workflows.
The implementation model must preserve the distinction between exposure, exploit attempt, probable exploitation, and confirmed compromise.
SOC Operating Model
Detection Posture
The SOC should treat suspected exploitation of PAN-OS User-ID Authentication Portal or Captive Portal exposure as a perimeter-integrity incident involving a security control, not as a conventional endpoint malware event.
Operational Priority
· Prioritize firewall-native logs first.
· Prioritize network-adjacent telemetry second.
· Use endpoint telemetry only for administrator workstation investigation, downstream activity validation, or internal expansion analysis.
· Use cloud telemetry conditionally for VM-Series deployments.
· Do not require endpoint-agent telemetry from the firewall as a baseline detection dependency.
Evidence Classification
Exposed
The portal is reachable from untrusted networks, but suspicious activity has not been confirmed.
Required SOC Action
· Validate exposure.
· Restrict access.
· Confirm mitigation status.
· Review affected-version and patch state.
· Begin retrospective hunting across the exposure window.
Targeted
Suspicious or abnormal portal-directed activity has occurred, but follow-on behavior has not been observed.
Required SOC Action
· Review portal traffic.
· Validate source context.
· Check firewall health.
· Review administrative activity.
· Review recent configuration changes.
· Increase monitoring for correlated post-interaction behavior.
Probable Exploitation
Suspicious portal activity is followed by firewall instability, administrative anomaly, configuration change, visibility reduction, firewall-originated outbound anomaly, or validated downstream activity.
Required SOC Action
· Escalate to incident response.
· Contain exposed portal access.
· Preserve logs.
· Review configuration integrity.
· Review administrator credentials and sessions.
· Review firewall-originated outbound communication.
· Hunt downstream from firewall-controlled paths.
· Engage vendor-supported diagnostic or forensic review where appropriate.
Confirmed Compromise
Unauthorized code execution, unauthorized configuration activity, malicious persistence, attacker-controlled behavior, vendor-supported evidence, or validated incident-response findings confirm compromise.
Required SOC Action
· Treat as confirmed firewall compromise.
· Execute incident-response plan.
· Rebuild or recover firewall from trusted baseline where required.
· Rotate relevant credentials.
· Validate configuration integrity.
· Validate downstream exposure.
· Notify executive stakeholders according to organizational incident severity criteria.
Deployment Sequence
Phase 1
Telemetry Validation
· Confirm PAN-OS traffic logs are ingested.
· Confirm PAN-OS system logs are ingested.
· Confirm PAN-OS threat logs are ingested where available.
· Confirm PAN-OS administrative audit logs are ingested.
· Confirm PAN-OS configuration logs are ingested.
· Confirm firewall identity is consistent across telemetry sources.
· Confirm timestamp normalization.
· Confirm source and destination fields.
· Confirm source zone and destination zone fields.
· Confirm portal indicators where available.
· Confirm firewall-originated egress visibility.
· Confirm maintenance-window data.
· Confirm approved portal-source and scanner-source data.
Phase 2
Asset and Exposure Scoping
· Identify scoped PA-Series and VM-Series firewalls.
· Identify User-ID Authentication Portal or Captive Portal enablement state.
· Identify public or untrusted ingress paths.
· Identify cloud ingress paths for VM-Series deployments.
· Identify approved portal-source ranges.
· Identify approved scanner infrastructure.
· Identify expected administrator source ranges.
· Identify expected firewall egress destinations.
· Identify maintenance windows and approved change workflows.
Phase 3
Baseline Development
· Baseline normal portal use.
· Baseline normal administrator login behavior.
· Baseline normal commit frequency.
· Baseline expected configuration-change patterns.
· Baseline normal firewall crash, restart, failover, and fault behavior.
· Baseline expected firewall-originated outbound destinations.
· Baseline expected update, licensing, logging, telemetry, monitoring, DNS, NTP, support, and management communication.
· Baseline expected cloud exposure paths for VM-Series deployments.
Phase 4
Rule Deployment
· Deploy S25 rules only after field validation.
· Use scoped firewall inventories.
· Use approved-source and scanner-source exclusions.
· Use maintenance-window context.
· Enable high-confidence correlation rules before hunt-grade analytics.
· Deploy cloud rules only for VM-Series assets with validated cloud telemetry and enrichment.
· Keep artifact-based coverage disabled until validated artifacts emerge.
Phase 5
Tuning and Feedback
· Review false positives from approved portal use.
· Review false positives from approved scanning.
· Review false positives from maintenance.
· Review false positives from Panorama-driven commits or automation.
· Review false positives from expected vendor destinations.
· Review false positives from cloud infrastructure changes.
· Refine source lists, asset inventories, exposure labels, and destination baselines.
· Preserve rule logic integrity while tuning environment-specific noise.
Alert Triage Workflow
Step 1
Confirm Firewall Scope
· Confirm the alert involves a scoped PA-Series or VM-Series firewall.
· Confirm the firewall has User-ID Authentication Portal or Captive Portal enabled, exposed, or under investigation.
· Confirm the firewall identity is consistent across correlated events.
Step 2
Classify Alert State
· Classify as exposed, targeted, probable exploitation, probable post-compromise activity, or confirmed compromise.
· Do not classify confirmed compromise from exposure, portal traffic, source reputation, or affected-version inventory alone.
Step 3
Validate Portal Activity
· Review source IP.
· Review source zone.
· Review source-risk context.
· Review destination service.
· Review portal indicator.
· Review rule name.
· Review application or URL path where available.
· Review approved portal-source and approved scanner-source context.
· Review activity timing and volume.
Step 4
Validate Follow-On Behavior
· Review firewall instability.
· Review administrative activity.
· Review configuration changes.
· Review visibility-reduction events.
· Review firewall-originated outbound communication.
· Review internal downstream activity where applicable.
· Review cloud exposure and flow telemetry for VM-Series deployments.
Step 5
Assess Operational Context
· Check maintenance windows.
· Check approved change records.
· Check approved administrator sources.
· Check Panorama or automation activity.
· Check scheduled backups.
· Check certificate renewal activity.
· Check policy deployment workflows.
· Check expected vendor or telemetry communication.
Step 6
Escalate When Correlation Holds
· Escalate when suspicious portal activity is followed by instability.
· Escalate when suspicious portal activity is followed by administrative-control anomaly.
· Escalate when suspicious portal activity is followed by configuration integrity change.
· Escalate when suspicious portal activity is followed by visibility reduction.
· Escalate when suspicious portal activity is followed by firewall-originated outbound anomaly.
· Escalate when suspicious portal activity is followed by validated downstream activity.
Step 7
Preserve Evidence
· Preserve PAN-OS traffic logs.
· Preserve PAN-OS system logs.
· Preserve PAN-OS administrative audit logs.
· Preserve PAN-OS configuration logs.
· Preserve commit history.
· Preserve configuration exports.
· Preserve NDR or flow records.
· Preserve cloud audit logs and flow logs for VM-Series deployments.
· Preserve administrator workstation telemetry where relevant.
· Preserve identity and privileged-access records where relevant.
Escalation Guidance
Low Severity
Exposure is confirmed, but no suspicious activity is observed.
Action
· Restrict access.
· Patch or mitigate.
· Validate portal disablement or source restriction.
· Conduct retrospective hunting.
Medium Severity
Suspicious portal-directed activity is observed without follow-on behavior.
Action
· Treat as targeted or attempted exploitation.
· Increase monitoring.
· Review firewall health.
· Review administrative and configuration logs.
· Perform targeted retrospective search.
High Severity
Suspicious portal-directed activity is followed by instability, administrative anomaly, configuration change, visibility reduction, or firewall-originated outbound anomaly.
Action
· Treat as probable exploitation.
· Escalate to incident response.
· Preserve evidence.
· Review configuration integrity.
· Investigate credential risk.
· Hunt for downstream activity.
· Engage vendor-supported diagnostics if appropriate.
Critical Severity
Confirmed unauthorized configuration activity, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, vendor-supported evidence, or validated incident-response findings are present.
Action
· Treat as confirmed compromise.
· Initiate full incident-response handling.
· Contain and recover firewall infrastructure.
· Rotate relevant credentials.
· Validate downstream systems.
· Conduct executive-level notification according to organizational policy.
Tuning Guidance
Approved Source Tuning
· Maintain approved portal-source ranges.
· Maintain approved scanner-source ranges.
· Maintain approved administrator source ranges.
· Do not allow approved-source tuning to suppress unrelated high-value post-interaction behavior.
· Revalidate approved sources after network changes.
Maintenance Tuning
· Maintain approved maintenance windows.
· Correlate maintenance suppression to device, event type, time window, and change context.
· Do not suppress instability automatically when suspicious portal activity occurs near the same window.
Administrative Tuning
· Baseline administrator usernames.
· Baseline administrator source locations.
· Baseline normal commit windows.
· Baseline Panorama-driven commits and automation workflows.
· Treat missing administrator source IP carefully.
· Do not allow missing administrator source IP to suppress high-value administrative or configuration events.
Outbound Egress Tuning
· Baseline firewall update destinations.
· Baseline licensing destinations.
· Baseline logging and telemetry destinations.
· Baseline management destinations.
· Baseline DNS, NTP, support, and monitoring destinations.
· Confirm firewall-originated traffic classification before alerting.
Cloud Tuning
· Validate VM-Series tags or labels.
· Validate ENI, NIC, or interface mapping.
· Validate load balancer or ingress path mapping.
· Validate route context.
· Validate public IP or external IP mapping.
· Validate cloud flow-log coverage.
· Validate locally configured portal ports.
· Treat cloud control-plane matches as pre-filter events requiring enrichment.
Response Guidance
Immediate Containment Considerations
· Restrict User-ID Authentication Portal or Captive Portal access to trusted sources.
· Disable public or untrusted portal exposure where operationally feasible.
· Apply vendor mitigation or patching guidance.
· Block unapproved ingress paths.
· Review security policy and NAT exposure.
· Review cloud ingress controls for VM-Series deployments.
Firewall Integrity Review
· Review configuration diffs.
· Review commit history.
· Review administrative sessions.
· Review account and privilege changes.
· Review authentication-profile changes.
· Review certificate changes.
· Review logging and forwarding changes.
· Review policy, NAT, route, and management-setting changes.
Credential and Identity Review
· Review firewall administrator accounts.
· Review privileged-access-management records.
· Review identity-provider activity tied to firewall administration.
· Review administrator workstation telemetry.
· Rotate credentials if unauthorized access is suspected or confirmed.
Outbound and Downstream Review
· Review firewall-originated outbound communication.
· Review new or rare destinations.
· Review DNS and TLS metadata.
· Review internal systems contacted after suspicious firewall interaction.
· Review newly permitted traffic paths.
· Review internal reconnaissance or lateral movement signals.
Operational Guardrails
· Do not treat all external portal traffic as exploitation.
· Do not treat exposure alone as compromise.
· Do not treat source reputation alone as compromise.
· Do not require packet payload visibility as a baseline dependency.
· Do not require endpoint-agent visibility on the firewall.
· Do not force artifact-based matching without validated artifacts.
· Do not apply cloud rules to non-cloud PA-Series appliances.
· Do not treat EventBridge, Azure Activity, or Cloud Audit Logs pre-filter matches as alerts without enrichment.
· Do not classify confirmed compromise without corroborating evidence.
S29 — Detection Coverage Summary
Coverage Purpose
This section summarizes the effective detection coverage achieved by Block 4. It identifies where the detection model is strong, where coverage depends on environmental telemetry, and where additional corroboration is required before compromise can be confirmed.
Overall Coverage Assessment
The Block 4 detection model provides strong behavior-led coverage for suspected exploitation of PAN-OS User-ID Authentication Portal or Captive Portal exposure.
The highest-confidence coverage is based on correlated behavior rather than single indicators. The strongest detection paths identify suspicious portal-directed activity followed by firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, or firewall-originated outbound anomalies.
The detection model is designed to support exposure management, exploit-attempt identification, probable-exploitation alerting, and confirmed-compromise investigation without overclassifying isolated signals.
Strong Coverage Areas
Suspicious Portal Activity Followed by Firewall Instability
Coverage Strength
Strong.
Primary Systems
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
· SentinelOne.
Supporting Systems
· NDR / Network Behavioral Analytics.
Assessment
· This is one of the strongest coverage areas because it links exploit-facing activity to same-firewall device-health impact.
· It remains effective without full payload visibility.
· It supports probable-exploitation classification when correlation is validated.
Suspicious Portal Activity Followed by Administrative-Control Anomaly
Coverage Strength
Strong.
Primary Systems
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Supporting Systems
· NDR / Network Behavioral Analytics.
Assessment
· This coverage area detects post-interaction control-plane behavior.
· It includes administrator login anomalies, account changes, privilege changes, commits, configuration exports, certificate changes, authentication-profile changes, logging changes, policy changes, NAT changes, route changes, and management-setting changes.
· It requires validation against approved administrator sources, maintenance windows, automation, and expected firewall-management workflows.
Suspicious Portal Activity Followed by Configuration Integrity Change
Coverage Strength
Strong.
Primary Systems
· SentinelOne.
· Splunk.
· Elastic.
· QRadar.
· SIGMA.
Supporting Systems
· NDR / Network Behavioral Analytics.
Assessment
· This coverage area identifies configuration changes after suspicious portal interaction that may alter enforcement, support unauthorized access, create new traffic paths, or affect visibility.
· It supports probable-exploitation or post-interaction control-plane risk classification when same-firewall temporal correlation is validated.
· It requires change-management and maintenance-window validation.
Suspicious Portal Activity Followed by Visibility Reduction
Coverage Strength
Strong where configuration and system logs are available.
Primary Systems
· Splunk.
· Elastic.
· QRadar.
Supporting Systems
· SentinelOne.
· SIGMA.
· NDR / Network Behavioral Analytics.
Assessment
· This coverage area identifies logging, forwarding, audit, monitoring, or visibility-control changes near suspicious portal activity.
· It is important because visibility reduction may impair detection, investigation, and response.
· It requires validation against approved logging changes, monitoring updates, and maintenance activity.
Suspicious Portal Activity Followed by Firewall-Originated Outbound Anomaly
Coverage Strength
Strong where firewall-originated traffic can be validated.
Primary Systems
· NDR / Network Behavioral Analytics.
· Splunk.
· Elastic.
· QRadar.
· AWS.
· Azure.
· GCP.
Supporting Systems
· SentinelOne where outbound PAN-OS logs are ingested.
Assessment
· This coverage area identifies unusual outbound communication from firewall infrastructure after suspicious portal-directed activity.
· It is strongest when outbound traffic can be confirmed as firewall-originated rather than ordinary through-firewall transit traffic.
· Coverage depends on destination baselines, source-IP mapping, interface context, route context, and traffic-role interpretation.
· Cloud coverage applies only to VM-Series deployments with validated flow telemetry and enrichment.
Conditional Coverage Areas
Internal Reconnaissance or Newly Observed Access Path
Coverage Strength
Conditional.
Primary System
· NDR / Network Behavioral Analytics.
Supporting Systems
· Splunk.
· Elastic.
· QRadar.
· Identity telemetry.
· Endpoint telemetry.
· PAN-OS configuration logs.
· Change-management records.
Assessment
· This coverage area is useful when internal NDR visibility and firewall-mediated path attribution are validated.
· It may identify internal reconnaissance, new access paths, destination fan-out, port fan-out, internal management-protocol access, or newly observed east-west behavior after suspicious firewall interaction.
· It should remain hunt guidance where internal visibility, path attribution, segmentation baselines, or route mapping are incomplete.
VM-Series Cloud Exposure Change
Coverage Strength
Conditional.
Primary Systems
· AWS.
· Azure.
· GCP.
Assessment
· This coverage area applies to VM-Series deployments where cloud control-plane telemetry, asset mapping, tags or labels, public ingress mapping, load balancer mapping, and locally validated portal-port context are available.
· It supports exposure management, remediation, and retrospective hunting.
· It does not apply to non-cloud PA-Series hardware.
· Exposure changes are not exploitation confirmation by themselves.
VM-Series Cloud Flow Correlation
Coverage Strength
Conditional.
Primary Systems
· AWS.
· Azure.
· GCP.
Assessment
· This coverage area applies where cloud flow telemetry can observe inbound portal traffic and firewall-originated outbound behavior from the same VM-Series asset.
· It requires ENI, NIC, or interface mapping.
· It requires enrichment-derived traffic-role classification.
· It requires load balancer or ingress-path validation.
· It supports probable-exploitation classification only when correlated and baselined.
SentinelOne PAN-OS Log Correlation
Coverage Strength
Conditional.
Primary System
· SentinelOne.
Assessment
· This coverage area is useful where PAN-OS logs are ingested into SentinelOne and correlation can be performed by same firewall identity and investigation window.
· It should be treated as PAN-OS log-correlation coverage.
· It should not be interpreted as endpoint-agent process, memory, or file visibility on the firewall.
SIGMA Portable Correlation
Coverage Strength
Conditional.
Primary System
· SIGMA.
Assessment
· This coverage area is useful where the target backend preserves correlation semantics, same-firewall grouping, sequence ordering, field mapping, and exception handling.
· Where backend conversion cannot preserve correlation behavior, the logic should be implemented directly in the target SIEM.
Coverage Boundaries
Artifact-Based DetectionBoundary
Artifact-based detection is not included in production coverage unless validated artifacts become available.
Reason
No validated file artifact, memory artifact, malware payload, script sample, persistence artifact, or stable forensic object is available for this activity.
Operational Handling
· Use behavioral correlation as the primary detection model.
· Reassess artifact-based detection if vendor-supported forensic evidence or validated incident-response artifacts become available.
Static IndicatorBoundary
The detection model does not depend on static exploit strings, public proof-of-concept fragments, or unvalidated payload details as mandatory detection conditions.
Reason
Static indicators may be incomplete, brittle, or quickly changed by attackers.
Operational Handling
· Use static indicators only as supplemental enrichment when validated.
· Preserve behavior-led correlation as the primary detection approach.
ExposureBoundary
Portal exposure creates urgent remediation and hunting requirements, but exposure alone does not establish exploitation.
Reason
A reachable portal indicates risk, not confirmed attacker success.
Operational Handling
· Use exposure findings for access restriction, mitigation validation, patch prioritization, and retrospective hunting.
· Require suspicious activity and follow-on behavior before probable-exploitation classification.
Source ContextBoundary
Source reputation and source-risk context support prioritization but do not independently establish exploitation or compromise.
Reason
Attackers may use changing infrastructure, compromised hosts, VPN services, cloud providers, residential proxies, or anonymization paths.
Operational Handling
· Use source context as enrichment.
· Require behavioral correlation before escalating to probable exploitation.
Affected-VersionBoundary
Affected-version inventory supports exposure management and remediation prioritization but does not establish exploitation.
Reason
A vulnerable or affected version identifies risk, not observed attacker behavior.
Operational Handling
· Use affected-version inventory for scope, prioritization, and retrospective hunting.
· Require activity-based evidence for exploit-attempt or probable-exploitation classification.
Cloud CoverageBoundary
Cloud-native coverage applies only to VM-Series deployments where cloud telemetry, asset mapping, interface mapping, ingress-path mapping, and enrichment are available.
Reason
Cloud-provider telemetry does not cover non-cloud PA-Series hardware appliances.
Operational Handling
· Apply AWS, Azure, and GCP detections only to validated VM-Series deployments.
· Use firewall-native and network-adjacent telemetry for non-cloud firewall coverage.
ConfirmationBoundary
No single detection rule should independently classify confirmed compromise.
Reason
Confirmed compromise requires corroborating evidence beyond detection logic.
Operational Handling
· Confirmed compromise requires forensic evidence, vendor-supported evidence, unauthorized configuration evidence, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
Coverage by Alert Classification
Exposed
Coverage
· Strong for VM-Series cloud exposure changes where cloud telemetry is available.
· Supported by firewall inventory, portal enablement state, external exposure data, and security policy review.
Classification Boundary
· Exposure only.
· Not exploitation.
· Not confirmed compromise.
Attempted Exploitation
Coverage
· Moderate to strong where suspicious portal-directed activity is visible.
· Stronger when portal access telemetry, source-risk context, and exposure state are available.
Classification Boundary
· Attempted exploitation unless paired with post-interaction behavior.
Probable Exploitation
Coverage
Strong.
Supporting Behaviors
· Portal activity followed by instability.
· Portal activity followed by administrative anomaly.
· Portal activity followed by configuration change.
· Portal activity followed by visibility reduction.
· Portal activity followed by firewall-originated outbound anomaly.
· Portal activity followed by validated downstream activity.
Classification Boundary
· Probable exploitation.
· Requires corroboration for confirmed compromise.
Confirmed Compromise
Coverage
Not assigned to any single S25 rule.
Required Evidence
· Forensic evidence.
· Vendor-supported evidence.
· Unauthorized configuration evidence.
· Unauthorized code execution evidence.
· Malicious persistence.
· Attacker-controlled behavior.
· Validated incident-response findings.
Classification Boundary
· Confirmed compromise only with corroborating evidence beyond detection logic.
Coverage Limitations
Payload Visibility Limitation
Many environments will not have full request payload visibility for portal-directed traffic.
Impact
· Detection cannot rely on packet capture, complete request bodies, or exploit strings.
· Behavioral correlation remains the primary detection model.
Firewall Endpoint-Agent Limitation
PA-Series and VM-Series firewalls should not be assumed to provide endpoint-agent process, memory, or file telemetry.
Impact
· Detection relies on firewall-native logs, network telemetry, configuration history, system-health records, and behavioral correlation.
Portal Logging Limitation
Portal-specific telemetry may vary by deployment and logging configuration.
Impact
· Rules must degrade gracefully when portal-specific fields are incomplete.
· Destination service, rule name, application, URL, and exposure context may be used as supporting indicators.
Outbound Baseline Limitation
Firewall-originated outbound anomaly detection depends on baseline maturity.
Impact
· Weak baselines can increase false positives.
· Expected vendor, logging, telemetry, monitoring, DNS, NTP, support, and management destinations must be maintained.
Cloud Telemetry Limitation
Cloud detection depends on provider logging, asset mapping, flow logs, route context, and load balancer path visibility.
Impact
· Cloud rules remain conditional.
· Cloud rules apply only to VM-Series deployments with sufficient telemetry and enrichment.
Source Attribution Limitation
NAT, load balancers, VPN services, residential proxies, anonymization infrastructure, and cloud ingress paths may weaken attribution.
Impact
· Source context should support prioritization.
· Source context should not be used as standalone compromise evidence.
Coverage Summary
Block 4 provides strong detection coverage for probable exploitation through correlated, behavior-led rule logic.
The strongest coverage exists where suspicious portal-directed activity can be correlated with same-firewall instability, administrative-control anomalies, configuration integrity changes, visibility reduction, or firewall-originated outbound anomalies.
Conditional coverage exists for internal expansion activity, VM-Series cloud exposure and flow telemetry, SentinelOne PAN-OS log correlation, and SIGMA portable correlation.
Coverage boundaries are intentionally defined to prevent overclassification of exposure-only findings, source context, affected-version inventory, static indicators, unsupported artifact assumptions, and single-rule confirmed-compromise conclusions.
S30 — Intelligence Maturity Assessment
Assessment Purpose
This section evaluates the maturity of the detection intelligence supporting Block 4. It assesses how well the available telemetry, rule logic, behavioral model, deployment assumptions, and validation requirements support reliable detection of active exploitation, probable exploitation, post-interaction activity, and confirmed-compromise workflows.
Overall Intelligence Maturity
Maturity Rating
High for behavior-led detection.
Rationale
The intelligence model is mature enough to support deployable detection because it does not rely on brittle exploit artifacts, static payload strings, attacker infrastructure, or endpoint-agent assumptions. It uses durable behavioral relationships between exposed portal interaction and post-interaction firewall behavior.
Primary Strength
The strongest intelligence basis is correlation between suspicious portal-directed activity and meaningful follow-on behavior.
Primary Follow-On Behaviors
· Firewall instability.
· Administrative-control anomaly.
· Configuration integrity change.
· Visibility reduction.
· Firewall-originated outbound anomaly.
· Conditional downstream activity.
· Conditional VM-Series cloud exposure and cloud-flow behavior.
Primary Constraint
The primary constraint is that public technical detail does not provide a complete payload, artifact, persistence, or forensic model. Confirmed compromise therefore remains dependent on vendor-supported evidence, forensic evidence, unauthorized configuration evidence, unauthorized code execution evidence, malicious persistence, attacker-controlled behavior, or validated incident-response findings.
Maturity by Intelligence Dimension
Threat Behavior Understanding
Maturity Rating
High.
Assessment
The report has a strong behavioral understanding of the detection problem. The firewall is treated as the exploitation target, the at-risk security control, and a potential post-compromise operating point.
Supporting Factors
· Clear separation between exposure, exploit attempt, probable exploitation, and confirmed compromise.
· Strong focus on portal-directed activity.
· Strong focus on firewall instability.
· Strong focus on control-plane integrity.
· Strong focus on configuration and visibility changes.
· Strong focus on firewall-originated outbound communication.
· Conditional recognition of downstream activity.
Residual Gap
The exact exploit internals, payload structure, and post-exploitation artifact model remain limited.
Telemetry Maturity
Maturity Rating
Moderate to High.
Assessment
Telemetry maturity is high where PAN-OS traffic, system, administrative, configuration, NDR, SIEM, DNS, proxy, TLS, and cloud telemetry are consistently collected and normalized.
Telemetry maturity is moderate where portal-specific logging, firewall-originated egress classification, administrator source fields, cloud flow logs, or load balancer path mapping are incomplete.
Supporting Factors
· Firewall-native telemetry is prioritized.
· Network-adjacent telemetry is integrated.
· Cloud telemetry is correctly treated as conditional.
· Endpoint telemetry is used only for downstream and administrator-workstation investigation.
· The detection strategy accounts for missing payload visibility and endpoint-agent gaps.
Residual Gap
Telemetry quality depends on local collection, normalization, retention, asset mapping, exposure-state tracking, and enrichment.
Detection Logic Maturity
Maturity Rating
High.
Assessment
Detection logic is mature because rules are behaviorally anchored, correlation-driven, and platform-specific. The rule set avoids unsupported single-signal compromise claims and is scoped according to telemetry availability.
Supporting Factors
· Network detection emphasizes behavior-led analytics.
· SentinelOne is scoped to PAN-OS log correlation.
· Splunk, Elastic, and QRadar use correlation-first detection patterns.
· QRadar is framed as CRE and building-block logic.
· SIGMA is limited to portable correlation patterns.
· Artifact-based matching remains dependent on validated evidence.
· AWS, Azure, and GCP are conditional to VM-Series deployments only.
· Cloud provider pre-filter matches require enrichment before alerting.
Residual Gap
Rule performance depends on local field mappings, lookups, exception lists, baseline maturity, and correlation-window tuning.
Variant Resistance Maturity
Maturity Rating
High.
Assessment
The detection model is resilient to attacker changes because it prioritizes behavior rather than brittle indicators.
Supporting Factors
· Does not depend on a single source IP.
· Does not depend on attacker infrastructure.
· Does not depend on public proof-of-concept strings.
· Does not depend on a stable payload pattern.
· Does not require full packet capture.
· Detects delayed follow-on behavior.
· Detects administrative and configuration changes after portal interaction.
· Detects firewall-originated egress anomalies.
· Detects visibility reduction.
· Accounts for source obfuscation and proxy infrastructure.
Residual Gap
Very low-volume exploitation, delayed operator activity, well-baselined legitimate-looking administrative activity, or successful visibility reduction can still reduce detection reliability.
Operational Deployability Maturity
Maturity Rating
Moderate to High.
Assessment
Operational deployability is strongest where firewall-native logs, network telemetry, SIEM normalization, asset context, approved-source context, maintenance context, and destination baselines are available. Deployability is conditional where telemetry depends on cloud provider logging, backend correlation conversion, PAN-OS log ingestion into third-party platforms, or internal path attribution.
Supporting Factors
· Rules include platform-specific deployment requirements.
· Conditional systems are clearly labeled.
· Cloud rules include enrichment requirements.
· SentinelOne avoids endpoint-agent overclaiming.
· SIGMA avoids unsupported portable logic.
· Artifact-based matching is not included without validated artifact evidence.
Residual Gap
Deployability depends on validated local mappings, approved-source lists, maintenance-window data, asset inventories, cloud enrichment pipelines, and destination baselines.
False Positive Control Maturity
Maturity Rating
Moderate to High.
Assessment
False positive control is mature where organizations maintain approved portal-source ranges, approved scanner ranges, approved administrator source ranges, maintenance windows, change-management records, and expected firewall egress baselines.
Supporting Factors
· Source filters require untrusted or high-risk context plus approved-source exclusion.
· Maintenance suppression requires device, timing, event type, and change context.
· Administrative behavior is validated against expected sources and workflows.
· Outbound anomaly detection requires expected destination baselines.
· Cloud control-plane events require enrichment before alerting.
Residual Gap
False positives may increase in environments with frequent firewall changes, weak change-management context, incomplete approved-source lists, immature egress baselines, or limited cloud asset tagging.
False Negative Risk Maturity
Maturity Rating
Moderate.
Assessment
False negative risk is acknowledged and partially mitigated through multi-signal correlation, but some gaps remain inherent to firewall exploitation telemetry.
Primary False Negative Drivers
· Low-volume portal activity.
· Single-attempt exploitation.
· Delayed follow-on activity.
· Missing portal-specific telemetry.
· Incomplete PAN-OS system logs.
· Incomplete administrative audit logs.
· Incomplete configuration logs.
· Weak firewall-originated egress visibility.
· Weak internal NDR visibility.
· Missing cloud flow logs.
· Load balancer path obscurity.
· Visibility reduction by the attacker.
· Legitimate-administrator blending.
Mitigation Approach
· Use longer retrospective hunting windows where exposure is confirmed.
· Correlate across multiple telemetry classes.
· Preserve logs quickly after suspicion.
· Monitor configuration and visibility changes.
· Maintain destination baselines.
· Validate cloud ingress paths.
· Use incident-response and vendor-supported diagnostics for confirmation.
Confirmation Maturity
Maturity Rating
Moderate.
Assessment
Detection maturity is high for probable exploitation, but confirmation maturity remains moderate because confirmed compromise depends on evidence outside the rule set.
Supporting Factors
· The report avoids single-rule confirmed-compromise claims.
· The report defines confirmation requirements.
· The report identifies forensic and vendor-supported evidence as necessary for confirmed compromise.
· The report treats unauthorized configuration activity and attacker-controlled behavior as confirmation pathways.
Residual Gap
Without forensic evidence, vendor-supported findings, unauthorized code execution evidence, malicious persistence, or validated incident-response findings, detection remains in probable-exploitation or post-interaction risk categories.
System-Level Maturity Assessment
NDR / Network Behavioral Analytics
Maturity Rating
High for firewall-originated outbound anomaly coverage; conditional moderate for downstream internal activity coverage.
Assessment
NDR is mature for detecting suspicious portal interaction followed by firewall-originated outbound anomaly when firewall asset mapping and outbound baselines exist.
Downstream internal activity coverage is mature only where internal NDR visibility and firewall-mediated path attribution are validated.
SentinelOne
Maturity Rating
Conditional Moderate to High.
Assessment
SentinelOne is mature where PAN-OS logs are ingested, normalized, and queryable. It should be treated as a PAN-OS log-correlation surface, not as endpoint-native firewall exploit detection.
Splunk
Maturity Rating
High.
Assessment
Splunk provides strong maturity because it can correlate PAN-OS traffic, system, administrative, configuration, network, DNS, exposure, and change context.
Elastic
Maturity Rating
High.
Assessment
Elastic provides strong maturity where ECS or custom field mappings support sequence correlation, exception lists, asset context, and firewall-originated traffic classification.
QRadar
Maturity Rating
High.
Assessment
QRadar provides strong maturity when implemented as CRE and building-block correlation with AQL used for validation and support.
SIGMA
Maturity Rating
Conditional Moderate.
Assessment
SIGMA is mature as a portable correlation pattern only where backend conversion preserves correlation semantics, same-firewall grouping, sequence ordering, and exception handling.
Artifact-Based Coverage
Maturity Rating
Future conditional.
Assessment
Artifact-based coverage may become useful if validated file, memory, malware, script, persistence, or forensic artifacts emerge. It is not included as production coverage without such validation.
AWS
Maturity Rating
Conditional Moderate to High.
Assessment
AWS is mature for VM-Series deployments with CloudTrail, VPC Flow Logs, asset tags, ENI mapping, route context, load balancer mapping, and enrichment-derived traffic-role fields.
Azure
Maturity Rating
Conditional Moderate to High.
Assessment
Azure is mature for VM-Series deployments with Azure Activity logs, NSG Flow Logs or Traffic Analytics, NIC mapping, load balancer or application gateway mapping, and enrichment-derived traffic-role fields.
GCP
Maturity Rating
Conditional Moderate to High.
Assessment
GCP is mature for VM-Series deployments with Cloud Audit Logs, VPC Flow Logs, Cloud Asset Inventory, network interface mapping, load balancer path mapping, and enrichment-derived traffic-role fields.
Priority Intelligence Improvements
Improve Portal Exposure Inventory
· Maintain current portal enablement state.
· Maintain external reachability state.
· Maintain cloud ingress path mapping.
· Maintain approved portal-source ranges.
· Maintain affected-version and patch state.
Improve Firewall-Originated Egress Baselines
· Baseline update destinations.
· Baseline licensing destinations.
· Baseline logging and telemetry destinations.
· Baseline monitoring destinations.
· Baseline management destinations.
· Baseline DNS and NTP destinations.
· Baseline support destinations.
Improve Administrative and Configuration Context
· Maintain approved administrator source ranges.
· Maintain administrator identity baselines.
· Maintain commit baselines.
· Maintain Panorama and automation context.
· Maintain certificate renewal context.
· Maintain policy deployment context.
· Maintain maintenance-window records.
Improve Cloud Enrichment
· Maintain VM-Series asset tags or labels.
· Maintain ENI, NIC, or interface mapping.
· Maintain load balancer and ingress path mapping.
· Maintain route context.
· Maintain public IP or external IP mapping.
· Maintain locally validated portal ports.
· Maintain enrichment-derived traffic-role classification.
Improve Retrospective Hunting
· Hunt across exposure windows.
· Hunt for portal activity preceding instability.
· Hunt for portal activity preceding configuration changes.
· Hunt for portal activity preceding outbound anomalies.
· Hunt for visibility reduction near suspicious portal traffic.
· Hunt for downstream access paths after suspected firewall compromise.
Intelligence Maturity Summary
The Block 4 intelligence program is mature enough to support deployment because it is behavior-led, correlation-driven, platform-specific, and honest about conditional telemetry requirements.
The strongest maturity areas are threat behavior understanding, detection logic design, variant resistance, and rule-to-threat alignment.
The main maturity constraints are local telemetry quality, portal logging variability, firewall-originated egress classification, cloud enrichment completeness, internal path attribution, and limited public forensic artifact detail.
Confirmed compromise remains outside the scope of any single S25 detection rule and requires corroborating forensic, vendor-supported, unauthorized configuration, unauthorized code execution, malicious persistence, attacker-controlled behavior, or incident-response evidence.
S31 — Telemetry Dependencies
Firewall-Native Telemetry
Effective detection and response depends on reliable PAN-OS telemetry from affected PA-Series and VM-Series firewalls. Required firewall-native sources include system logs, traffic logs, threat logs, configuration logs, administrative audit logs, commit history, administrator login records, configuration export records, crash records, fault events, failover events, portal service health records, and log-forwarding records.
Firewall-native telemetry should preserve device identity, timestamp, source and destination context, source and destination zone, interface context, rule name, application or service fields, administrator identity where available, commit metadata, configuration object names, action fields, severity, event subtype, and descriptive event text.
Portal and Exposure Telemetry
Organizations must maintain visibility into whether User-ID Authentication Portal or Captive Portal services are enabled, where they are reachable, and whether they are accessible from untrusted networks. Exposure validation should include interface configuration, zone policy, response-page configuration, external ingress paths, cloud security controls, load balancer paths, public IP association, attack-surface management records, and external reachability testing.
Portal telemetry should support identification of suspicious portal interaction from untrusted, newly observed, scanner-associated, anonymized, cloud-hosted, or otherwise unexpected sources.
Configuration and Administrative Telemetry
Configuration integrity is a primary dependency because suspected exploitation may affect the firewall control plane. Required telemetry includes administrator login history, administrative account changes, role changes, privilege changes, authentication-profile changes, certificate changes, policy changes, NAT changes, routing changes, logging changes, management-setting changes, configuration exports, and commit history.
Configuration and administrative records should be retained long enough to support historical review across the exposure window and any delayed follow-on activity.
Network and Firewall-Originated Egress Telemetry
Network telemetry must distinguish firewall-originated communication from ordinary through-firewall transit traffic. Required sources include firewall traffic logs, NetFlow or equivalent network records, DNS logs, TLS metadata where available, NDR telemetry, firewall-adjacent sensor data, cloud flow logs for VM-Series deployments, and egress records from management or control-plane interfaces.
Organizations should maintain baselines for expected firewall update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management destinations. Newly observed, rare, unexplained, or unapproved firewall-originated destinations should be reviewed when they occur near suspicious portal activity or control-plane anomalies.
Cloud Telemetry for VM-Series Deployments
For VM-Series firewalls, cloud telemetry is required to validate exposure and traffic-path changes. Relevant sources include security group changes, route table changes, public IP association, load balancer configuration, cloud flow logs, control-plane audit logs, IAM activity, ingress rule changes, network interface changes, and cloud-native exposure records.
Cloud telemetry should support assessment of whether portal services were reachable from public or untrusted paths and whether cloud network changes altered the firewall exposure surface.
Identity and Privileged-Access Telemetry
Identity telemetry should support investigation of firewall administrator activity, privileged-access workflows, and potential credential misuse. Required sources include identity-provider logs, privileged-access-management logs, multi-factor authentication records, administrator source locations, credential checkout records, administrator workstation telemetry, and change-management records.
These sources help determine whether administrative activity after suspicious portal interaction was approved, expected, or anomalous.
Downstream Telemetry
Downstream telemetry is conditional but important when suspected firewall compromise may have enabled internal access or traffic-path changes. Relevant sources include internal network telemetry, endpoint telemetry, authentication logs, server logs, identity logs, cloud workload telemetry, management-plane access logs, and records from systems contacted through newly observed or altered access paths.
Downstream telemetry should be used only where activity can be temporally and logically linked to suspected or confirmed firewall compromise.
Retention and Correlation Requirements
Telemetry must be retained long enough to support retrospective review of exposure, portal activity, instability, administrative behavior, configuration changes, outbound communication, and downstream activity.
Correlation requires consistent device identity, normalized timestamps, firewall role context, exposure state, administrator identity where available, network path context, and change-management context.
S32 — Detection Limitations
Exposure Does Not Equal Compromise
Externally reachable User-ID Authentication Portal or Captive Portal services create urgent remediation and hunting requirements, but exposure alone does not prove exploitation or compromise. Compromise-level assessment requires stronger behavioral, forensic, vendor-supported, configuration, unauthorized-code-execution, or incident-response evidence.
Payload Visibility May Be Limited
Many environments will not have complete request payload visibility for portal-directed traffic. Detection should not depend on full packet capture, public proof-of-concept strings, static exploit artifacts, or durable request patterns as mandatory conditions.
Firewall Endpoint-Agent Visibility Is Not Assumed
PA-Series and VM-Series firewalls should not be treated as conventional endpoint-agent telemetry sources. Direct process execution, memory inspection, and file-level monitoring may not be available through standard enterprise EDR tooling. Detection must rely primarily on firewall-native logs, configuration history, device-health records, network telemetry, and validated forensic evidence where available.
Portal Logging May Vary
Portal-specific logging can vary by PAN-OS version, forwarding configuration, deployment architecture, logging policy, and retention period. Some environments may have limited ability to reconstruct portal interaction detail.
Administrative Activity Can Be Ambiguous
Administrator logins, commits, policy changes, certificate changes, NAT changes, routing updates, logging changes, failovers, and restarts may occur during legitimate operations. Detection and response must account for approved maintenance, Panorama-driven commits, planned policy deployment, certificate renewal, backup activity, and documented change windows.
Firewall-Originated Traffic Can Be Hard to Separate
Firewall-originated communication may be difficult to distinguish from through-firewall transit traffic in environments with complex routing, NAT, cloud networking, load balancers, asymmetric traffic paths, or incomplete flow labeling. Egress investigation depends on accurate firewall asset mapping and management or control-plane path visibility.
Cloud Visibility Is Deployment-Dependent
VM-Series visibility depends on cloud provider logging, flow-log enablement, control-plane audit retention, route design, security group records, load balancer logging, and cloud network architecture. Incomplete cloud telemetry may weaken exposure validation and traffic-path reconstruction.
Source Attribution May Be Weak
Attacker source attribution may be obscured by NAT, VPN services, residential proxies, cloud-hosted infrastructure, compromised intermediaries, anonymized access paths, carrier-grade NAT, or load balancer fronting. Source reputation should support prioritization but should not be treated as standalone proof of compromise.
Post-Exploitation Evidence May Be Incomplete
Publicly confirmed post-exploitation details may remain limited. Organizations should not assume a named actor, malware family, persistence mechanism, credential-theft path, or complete post-exploitation playbook without validated evidence.
S33 — Defensive Control & Hardening Improvements
Restrict User-ID Authentication Portal Exposure
Restrict User-ID Authentication Portal or Captive Portal access to trusted internal sources only. Remove public internet reachability and eliminate untrusted ingress paths unless a documented business requirement exists and compensating controls are validated.
Disable Unnecessary Portal Services
Disable User-ID Authentication Portal or Captive Portal functionality where it is not required. Any retained portal deployment should have documented ownership, approved source ranges, logging requirements, and exposure validation.
Harden Interface and Response-Page Exposure
Review interface management profiles, response-page configuration, zone policy, service exposure, and externally reachable interfaces. Remove response-page exposure from untrusted ingress paths where it is not required.
Validate Patch and Mitigation Status
Track affected PAN-OS versions, fixed-version availability, mitigation status, and emergency change windows. Patch validation should be paired with historical compromise review for systems that were reachable from untrusted networks before remediation.
Strengthen Administrative Access Controls
Limit firewall administration to approved source networks, privileged-access workflows, strong multi-factor authentication, named administrator accounts, role-based access, and monitored management paths. Remove unused accounts, stale privileges, shared accounts, and unmanaged administrative access paths.
Protect Configuration Integrity
Increase oversight of commits, configuration exports, authentication-profile changes, certificate changes, policy changes, NAT changes, route changes, logging changes, and management-setting changes. Require change tickets, administrator attribution, expected source paths, peer review, and rollback readiness for high-risk firewall changes.
Baseline Firewall-Originated Communication
Create and maintain baselines for expected firewall update, licensing, logging, telemetry, monitoring, support, DNS, NTP, and management destinations. Investigate newly observed, rare, unexplained, or unapproved firewall-originated communication, especially when it occurs near suspicious portal activity or control-plane anomalies.
Strengthen Logging and Forwarding Controls
Ensure PAN-OS system, traffic, threat, configuration, administrative audit, and portal-related logs are forwarded to centralized logging platforms with sufficient retention. Monitor changes to syslog destinations, log-forwarding profiles, traffic logging, threat logging, administrative audit logging, and monitoring profiles.
Improve Exposure Management
Maintain current inventory of PA-Series and VM-Series firewalls, PAN-OS versions, portal enablement state, exposed interfaces, ingress paths, cloud exposure, and internet reachability. Reassess exposure after network changes, cloud changes, firewall upgrades, migration activity, policy changes, and new load balancer deployments.
Prepare Recovery and Integrity Procedures
Maintain tested procedures for firewall isolation, failover, configuration rollback, known-good configuration restoration, administrator credential rotation, certificate validation, log-forwarding validation, policy review, and firewall rebuild or replacement.
S34 — Defensive Control & Hardening Architecture
Figure 6
Perimeter Exposure Control Layer
The first defensive layer should eliminate unnecessary untrusted access to User-ID Authentication Portal or Captive Portal services. Portal access should be restricted through security policy, source restrictions, zone design, cloud security controls, load balancer configuration, and external exposure validation.
This layer should ensure that firewall-hosted authentication portal services are not broadly internet-accessible unless explicitly justified, controlled, monitored, and reviewed.
Firewall Control-Plane Protection Layer
The second layer should harden administrative and control-plane access. Firewall administration should require approved administrator identities, trusted source networks, privileged-access workflows, multi-factor authentication, role-based access control, and strong change-management linkage.
Administrative access should be separated from general user traffic, protected through dedicated management paths where possible, and monitored for unexpected source locations, abnormal login patterns, account changes, privilege changes, and unusual commit behavior.
Configuration Integrity Layer
The third layer should protect the firewall configuration from unauthorized or unexplained change. Commit activity, configuration exports, policy changes, NAT changes, routing changes, authentication-profile changes, certificate changes, logging changes, and management-setting changes should be logged, reviewed, and correlated with change-management records.
High-risk configuration changes should trigger review when they affect access paths, inspection behavior, logging visibility, administrative control, segmentation, or firewall-originated communication.
Visibility and Logging Resilience Layer
The fourth layer should preserve visibility even during suspected control-plane compromise. PAN-OS logs should be forwarded to centralized logging platforms, and changes to logging, syslog forwarding, threat logging, traffic logging, administrative auditing, and monitoring profiles should be monitored.
Logging destinations and monitoring paths should be protected from unauthorized change, and retention should support retrospective review across the full exposure and investigation window.
Firewall-Originated Egress Monitoring Layer
The fifth layer should monitor communication initiated by firewall infrastructure. Expected egress destinations should be baselined for vendor updates, licensing, telemetry, logging, support, DNS, NTP, monitoring, and management. New, rare, unexplained, or unapproved destinations should receive elevated scrutiny when paired with suspicious portal activity, instability, administrative anomalies, configuration changes, or visibility reduction.
Cloud Exposure Governance Layer
For VM-Series deployments, cloud security controls should govern public IP assignment, security group exposure, route tables, load balancer paths, network interfaces, IAM permissions, and cloud flow logging. Cloud change records should be reviewed when they expose portal services or alter traffic paths through the firewall.
Incident Response and Recovery Layer
The final layer should ensure that suspected firewall compromise can be handled as a perimeter-integrity incident. Response plans should include exposure validation, containment decision points, firewall isolation, high-availability failover review, known-good configuration recovery, administrator credential rotation, downstream hunting, legal and executive escalation criteria, and service restoration procedures.
S35 — Defensive Control Mapping Matrix
Portal Exposure Control
Required Improvement
Restrict User-ID Authentication Portal or Captive Portal access to trusted sources only.
Primary Risk Reduced
External exploitation of exposed firewall portal services.
Validation Evidence
Exposure scans, firewall policy review, interface review, and cloud ingress review.
Portal Service Minimization
Required Improvement
Disable portal functionality where not required.
Primary Risk Reduced
Unnecessary attack surface.
Validation Evidence
Portal enablement inventory, service configuration review, and change record.
Interface Hardening
Required Improvement
Remove unsafe response-page or portal exposure from untrusted interfaces.
Primary Risk Reduced
Untrusted access to firewall-hosted services.
Validation Evidence
Interface management profile review and zone policy review.
PAN-OS Patch Governance
Required Improvement
Validate affected versions, mitigation state, and fixed-release deployment.
Primary Risk Reduced
Continued vulnerability exposure.
Validation Evidence
Version inventory, change tickets, and patch validation records.
Administrative Access Control
Required Improvement
Restrict firewall administration to approved users, sources, and privileged workflows.
Primary Risk Reduced
Unauthorized control-plane access.
Validation Evidence
Administrator login logs, privileged-access-management logs, identity-provider logs, and source-range review.
Configuration Integrity Monitoring
Required Improvement
Monitor commits, exports, policy, NAT, routing, authentication-profile, certificate, and logging changes.
Primary Risk Reduced
Configuration tampering and traffic-path manipulation.
Validation Evidence
Configuration logs, commit history, and change-management records.
Logging Resilience
Required Improvement
Protect system, traffic, threat, configuration, and administrative audit logging.
Primary Risk Reduced
Visibility reduction and forensic gaps.
Validation Evidence
SIEM ingestion records, log-forwarding profiles, and retention validation.
Firewall-Originated Egress Monitoring
Required Improvement
Baseline expected firewall egress and investigate rare or unapproved destinations.
Primary Risk Reduced
Post-exploitation communication from firewall infrastructure.
Validation Evidence
Traffic logs, DNS logs, NDR records, and destination baseline.
Cloud Exposure Governance
Required Improvement
Monitor VM-Series public IPs, security groups, route tables, load balancers, and flow logs.
Primary Risk Reduced
Cloud-path exposure and untracked ingress changes.
Validation Evidence
Cloud audit logs, flow logs, route records, security group records, and load balancer records.
Change-Management Alignment
Required Improvement
Tie high-risk firewall changes to approved tickets and maintenance windows.
Primary Risk Reduced
Administrative ambiguity and response delay.
Validation Evidence
Change tickets, approval records, and administrator attribution.
Credential Containment
Required Improvement
Rotate or review administrator credentials after suspected exploitation.
Primary Risk Reduced
Misuse of privileged access.
Validation Evidence
IAM logs, privileged-access-management records, MFA events, and password or token rotation records.
Recovery Readiness
Required Improvement
Maintain known-good configuration, rollback, rebuild, and failover procedures.
Primary Risk Reduced
Prolonged outage or untrusted firewall state.
Validation Evidence
Backup validation, restore tests, high-availability review, and recovery runbooks.
Downstream Hunting
Required Improvement
Review internal access paths after suspected firewall compromise.
Primary Risk Reduced
Enterprise intrusion expansion.
Validation Evidence
Internal network telemetry, endpoint logs, identity logs, and service access records.
S36 —Intelligence Maturity Assessment
Overall Intelligence Maturity
Moderate to High.
The intelligence picture is mature enough to support executive prioritization, emergency exposure reduction, retrospective hunting, and behavior-led detection planning. The vulnerability is understood as an active edge-firewall exploitation risk affecting exposed User-ID Authentication Portal or Captive Portal services on PA-Series and VM-Series firewalls.
Maturity is strongest for exposure management, portal reachability assessment, firewall-native telemetry requirements, control-plane integrity review, and probable-exploitation classification.
Maturity is lower for actor attribution, full post-exploitation tradecraft, malware usage, persistence method, confirmed downstream intrusion paths, and durable payload-level indicators.
Exposure Intelligence Maturity
High.
Exposure conditions can be assessed through firewall inventory, PAN-OS version tracking, portal enablement status, interface and zone configuration, external reachability testing, cloud exposure records, and ingress-path review.
Detection Intelligence Maturity
Moderate to High.
Detection can be supported through correlated signals involving portal activity, firewall instability, administrative anomalies, configuration changes, visibility reduction, firewall-originated outbound communication, and downstream activity. Confidence depends on telemetry quality, retention, baseline maturity, and the ability to distinguish firewall-originated traffic from through-firewall traffic.
Adversary Tradecraft Maturity
Moderate.
The exploitation path is clear at the exposure and initial-access level, but complete post-exploitation tradecraft should remain unresolved unless validated by vendor guidance, government reporting, forensic evidence, or incident-response findings.
Response Readiness Maturity
Moderate to High.
Organizations with current firewall inventory, centralized PAN-OS logging, change-management linkage, administrator access monitoring, firewall egress baselines, cloud exposure records, and tested recovery procedures should be able to scope and respond effectively. Readiness is lower where portal exposure is unknown, logs are short-retained, configuration history is incomplete, or administrative changes are poorly attributed.
Confidence Constraints
· Actor identity is not confirmed.
· Malware usage is not confirmed.
· Persistence behavior is not confirmed.
· Complete payload or exploit artifact detail is not available as a durable detection basis.
· Downstream intrusion activity should remain conditional unless linked to suspected or confirmed firewall compromise.
· Confirmed compromise requires stronger forensic, vendor-supported, configuration, unauthorized-code-execution, or incident-response evidence.
S37 — Strategic Defensive Improvements
Establish Firewall Exposure Governance
Create a recurring control to validate exposed PA-Series and VM-Series firewalls, User-ID Authentication Portal or Captive Portal enablement, internet reachability, untrusted ingress paths, cloud exposure, and response-page configuration. Treat unexpected portal exposure as a high-priority remediation item.
Make Firewall Control-Plane Integrity a Formal Security Objective
Treat firewall control-plane integrity as a governed security outcome. Administrative access, commit activity, configuration exports, policy changes, NAT changes, routing changes, certificate changes, authentication-profile changes, and logging changes should be monitored with the same rigor applied to privileged identity systems.
Strengthen Change-Control Enforcement for Firewall Infrastructure
Require high-risk firewall changes to be tied to approved maintenance windows, administrator identity, source location, business justification, peer review, and rollback planning. Unexplained changes should trigger immediate review when they occur near suspicious portal activity or exposure windows.
Improve Firewall-Originated Egress Visibility
Build a maintained baseline of expected firewall-originated communication and alert on unusual destinations, rare DNS activity, unexpected TLS sessions, abnormal ports, or unapproved egress paths. This control should apply to both physical and VM-Series firewall deployments.
Centralize and Extend PAN-OS Log Retention
Forward system, traffic, threat, configuration, administrative audit, portal-related, crash, and failover logs to a centralized platform with retention sufficient for retrospective hunting. Ensure timestamps, device identity, administrator identity, source context, and configuration metadata are preserved.
Integrate Cloud and Firewall Exposure Management
For VM-Series deployments, integrate cloud security posture management, cloud flow logs, route-table monitoring, security group monitoring, load balancer logging, public IP tracking, and firewall inventory. Cloud ingress changes should be reviewed for portal exposure impact.
Operationalize Firewall Compromise Response
Create a response playbook for suspected firewall control-plane compromise. The playbook should cover exposure validation, suspicious portal activity review, device-health review, configuration integrity review, administrator credential review, firewall-originated egress analysis, downstream hunting, containment decision points, known-good restore, and executive escalation.
Strengthen Administrator Credential Protection
Review privileged accounts, administrative roles, authentication profiles, multi-factor enforcement, source restrictions, privileged-access-management workflows, and stale administrator credentials. Rotate credentials when suspected exploitation aligns with administrative anomalies or configuration changes.
Validate Recovery and Rebuild Readiness
Test restoration from known-good configuration, high-availability failover procedures, firewall rebuild steps, certificate recovery, policy validation, NAT and route validation, log-forwarding restoration, and emergency change procedures. Recovery readiness is critical when firewall integrity cannot be trusted.
Measure Defensive Readiness After Mitigation
After patching, portal restriction, or portal disablement, validate that exposure is removed, logging is intact, configuration history is preserved, administrative access is controlled, firewall egress is baselined, and historical compromise review has been completed for any firewall that was reachable from untrusted networks.
S38 — Attack Economics & Organizational Impact Model
Figure 7
Adversary Cost Advantage
[EXP] Active Exploitation of PAN-OS User-ID Authentication Portal for Edge Firewall Compromise — CVE-2026-0300 creates favorable attack economics when exposed firewall portal services are reachable from untrusted networks. Attackers can focus on externally visible infrastructure, identify reachable User-ID Authentication Portal or Captive Portal services, and attempt exploitation without first gaining access to an internal endpoint, user account, phishing path, or downstream application.
The attacker advantage is strongest where organizations expose affected PA-Series or VM-Series firewall services to the public internet, lack complete portal telemetry, maintain weak firewall-originated egress baselines, or cannot rapidly distinguish exposure from attempted exploitation, probable exploitation, and confirmed compromise.
Defender Cost Disadvantage
Defender cost is elevated because the firewall is both the target and the security control under trust review. If exploitation is suspected, response may require more than patching or portal restriction. The organization may need to validate firewall integrity, review configuration history, inspect administrative activity, reconstruct commit timelines, validate policy and NAT behavior, confirm logging continuity, review firewall-originated communication, rotate administrator credentials, and hunt downstream activity.
The cost disadvantage increases when telemetry is incomplete, firewall-originated traffic cannot be separated from through-firewall transit traffic, configuration changes are poorly tied to approved maintenance, or affected firewalls protect production ingress, regulated environments, cloud workloads, customer-facing services, or high-value segmentation boundaries.
Operational Leverage for Attackers
Successful exploitation of a firewall control plane can provide attackers with outsized operational leverage. A compromised firewall may affect traffic enforcement, segmentation trust, inspection behavior, logging visibility, administrative confidence, and downstream access paths. Even limited attacker control or uncertainty about control-plane integrity can force broad defensive action.
Attackers do not need to immediately demonstrate broad downstream compromise to create organizational impact. Suspicious portal activity followed by firewall instability, administrative-control anomalies, configuration changes, visibility reduction, or firewall-originated outbound communication can trigger incident-response escalation, emergency change activity, business-continuity planning, and executive oversight.
Organizational Impact Model
The organizational impact model should be based on exposure, evidence strength, firewall role, telemetry confidence, and downstream dependency.
Low Impact
Low impact applies when affected firewalls were not externally reachable, portal access was already restricted, mitigations were applied quickly, logs are preserved, suspicious portal activity is not observed, and no instability, administrative anomaly, configuration change, visibility reduction, outbound anomaly, or downstream activity is linked to the exposure.
Organizational impact remains meaningful because the organization must still validate inventory, exposure state, mitigation status, telemetry retention, and historical activity during the active exploitation window.
Moderate Impact
Moderate impact applies when affected firewalls were reachable from untrusted networks, suspicious portal interaction occurred, telemetry is incomplete, or limited instability, administrative anomalies, configuration changes, visibility changes, or firewall-originated outbound behavior require investigation without confirmed downstream compromise.
Organizational impact may include incident-response mobilization, change freezes, executive updates, firewall integrity review, administrative credential review, configuration reconstruction, selective downstream hunting, legal readiness, customer assurance planning, and temporary operational disruption.
High Impact
High impact applies when firewall compromise is confirmed or strongly suspected, unauthorized configuration activity is identified, visibility was reduced, firewall-originated outbound communication indicates suspicious post-interaction behavior, or downstream intrusion activity is linked to the affected firewall.
Organizational impact may include firewall isolation, rebuild or replacement, emergency architecture changes, credential rotation at scale, configuration reconstruction, production-impacting maintenance, downstream compromise assessment, legal and regulatory review, customer assurance, insurance engagement, and board-level governance.
Economic Pressure Points
· Number of exposed PA-Series and VM-Series firewalls.
· Duration of portal exposure before mitigation or patch validation.
· Firewall role in production ingress, cloud transit, branch connectivity, regulated environments, customer-facing services, remote access, or segmentation.
· Quality and retention of PAN-OS system, traffic, threat, configuration, administrative audit, crash, failover, and portal-related logs.
· Ability to distinguish firewall-originated egress from through-firewall transit traffic.
· Completeness of administrative audit records, commit history, configuration exports, and change-management linkage.
· Need for administrator credential review or rotation.
· Need for firewall isolation, failover, rebuild, replacement, or known-good configuration restoration.
· Scope of downstream hunting required when suspected firewall compromise may have altered access paths or weakened segmentation.
· Customer, regulatory, insurance, legal, and executive-governance obligations.
S39 — Economic Impact & Organizational Exposure
Estimated Economic Exposure
Estimated economic exposure should be modeled through three scenario bands.
Low Impact Scenario
Estimated impact $500K to $3M.
This scenario applies when exposure is limited or quickly eliminated, telemetry is preserved, suspicious portal activity is not observed, and no post-interaction firewall instability, administrative-control anomaly, configuration change, visibility reduction, firewall-originated outbound anomaly, or downstream activity is identified.
Primary cost drivers include emergency inventory validation, exposure review, mitigation confirmation, patch planning, telemetry preservation, limited retrospective hunting, and executive tracking.
Moderate Impact Scenario
Estimated impact $5M to $30M.
This scenario applies when one or more affected firewalls were reachable from untrusted networks during the active exploitation window, suspicious portal-directed activity occurred, telemetry is incomplete, or limited post-interaction anomalies require investigation without confirmed downstream compromise.
Primary cost drivers include incident-response mobilization, firewall-native log review, configuration integrity validation, commit and export review, administrator credential review, firewall egress analysis, maintenance-window reconstruction, segmentation validation, selective downstream hunting, detection tuning, legal assessment, executive coordination, and customer or regulator readiness planning.
High Impact Scenario
Estimated impact $40M to $200M or higher.
This scenario applies when firewall compromise is confirmed or strongly suspected on externally reachable PA-Series or VM-Series firewalls supporting production, regulated, customer-facing, cloud, branch, or high-value segmentation environments.
Primary cost drivers include firewall isolation, rebuild or replacement, emergency architecture changes, credential rotation at scale, configuration reconstruction, policy and route validation, downstream compromise assessment, customer assurance, legal and regulatory review, cyber-insurance engagement, business-continuity coordination, and board-level incident governance.
Annualized Risk Exposure
Estimated annualized risk exposure is $10M to $75M or higher.
This estimate depends on affected firewall count, external exposure duration, active exploitation conditions, firewall role criticality, segmentation dependency, regulated-system footprint, telemetry completeness, configuration integrity confidence, administrator credential exposure, downstream intrusion evidence, containment complexity, customer assurance requirements, and legal or regulatory obligations.
Organizational Exposure Factors
Perimeter Dependency
Exposure is highest where affected firewalls protect production ingress, internet-facing services, regulated environments, branch connectivity, cloud workloads, remote access paths, or high-value segmentation boundaries.
Control-Plane Trust
Organizational exposure increases when firewall integrity cannot be proven after suspicious portal interaction. Even without confirmed downstream compromise, uncertainty around administrative control, configuration state, and logging reliability can create significant response burden.
Visibility Confidence
Exposure increases when logs are incomplete, short-retained, inconsistently forwarded, or missing configuration and administrative audit detail. Limited visibility can force broader containment and longer investigation windows.
Change-Control Confidence
Exposure increases when commits, policy changes, NAT changes, route changes, certificate changes, logging changes, authentication-profile changes, or management-setting changes cannot be tied to approved maintenance, known administrators, or documented change activity.
Downstream Dependency
Exposure increases when suspected firewall compromise could affect access to internal systems, cloud workloads, identity services, management platforms, customer environments, regulated systems, or other high-value assets.
Customer and Regulatory Exposure
Exposure increases when affected firewalls protect customer-facing systems, regulated data environments, critical business services, or contractual security commitments. Customer assurance, regulatory review, insurance reporting, and executive communications may be required even when confirmed compromise remains unresolved.
Residual Economic Risk
Residual economic risk remains after patching or portal restriction when the firewall was reachable from untrusted networks before remediation. Patching reduces future exposure, but it does not prove that pre-remediation exploitation did not occur.
Residual risk should remain elevated until historical portal activity, firewall-health records, administrative audit logs, configuration history, log-forwarding state, firewall-originated outbound communication, and relevant downstream telemetry have been reviewed.
S40 — References
Vendor / Platform Documentation
Palo Alto Networks Security Advisory — CVE-2026-0300 PAN-OS User-ID Authentication Portal vulnerability
· hxxps://security.paloaltonetworks[.]com/CVE-2026-0300
Palo Alto Networks Documentation — PAN-OS User-ID and Authentication Portal documentation
· hxxps://docs.paloaltonetworks[.]com/pan-os
Vulnerability Records
CVE Record — CVE-2026-0300 vulnerability details
· hxxps://www.cve[.]org/CVERecord?id=CVE-2026-0300
NVD Record — CVE-2026-0300 vulnerability details
· hxxps://nvd.nist[.]gov/vuln/detail/CVE-2026-0300
Known Exploited Vulnerabilities
CISA Known Exploited Vulnerabilities Catalog — CVE-2026-0300 status
· hxxps://www.cisa[.]gov/known-exploited-vulnerabilities-catalog
Security Vendor Analysis
BleepingComputer — Palo Alto Networks warns of firewall RCE zero-day exploited in attacks
· hxxps://www.bleepingcomputer[.]com/news/security/palo-alto-networks-warns-of-actively-exploited-firewall-zero-day/
The Hacker News — Palo Alto PAN-OS flaw under active exploitation enables remote code execution
· hxxps://thehackernews[.]com/2026/05/palo-alto-pan-os-flaw-under-active.html
SecurityWeek — Palo Alto Networks to Patch Zero-Day Exploited to Hack Firewalls
· hxxps://www.securityweek[.]com/palo-alto-networks-to-patch-zero-day-exploited-to-hack-firewalls/
Threat Tradecraft and Intrusion Patterns
MITRE ATT&CK Framework — Enterprise Matrix
· hxxps://attack.mitre[.]org
