[EXP] GlobalProtect Authentication-Lineage Bypass and Trusted VPN Session Compromise

Report Type: EXP

Threat Category: Remote-Access Trust Abuse / Authentication-Lineage Bypass

Assessment Date: May 30, 2026

Primary Impact Domain: Remote-Access Trust and VPN Session Integrity

Secondary Impact Domains: Identity and Access Control; Privileged Access; Internal Network Access; Cloud and SaaS Control Planes; Developer, Source-Code, and CI/CD Environments; Backup and Recovery Infrastructure

Affected Asset Class: Internet-facing GlobalProtect portals and gateways; PAN-OS remote-access infrastructure; VPN user sessions; privileged and third-party VPN accounts; identity-provider, MFA, SAML, certificate, HIP, and device-posture validation paths; downstream internal, cloud, SaaS, developer-platform, source-code, CI/CD, and backup systems reachable through trusted VPN access

Threat Objective Classification: Establish or abuse trusted GlobalProtect VPN access without a complete and expected authentication lineage, enabling suspicious or unauthorized activity to appear legitimate while creating potential access to internal systems, privileged resources, identity infrastructure, cloud consoles, SaaS administration portals, developer platforms, source-code repositories, CI/CD environments, and backup infrastructure.

BLUF

‍ GlobalProtect authentication-lineage bypass and trusted VPN session compromise create material enterprise risk by weakening confidence in the remote-access path organizations rely on for workforce, administrator, third-party, and operational connectivity. The risk is driven by VPN session establishment or trusted-session use where expected identity-provider authentication, MFA or conditional-access decisions, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, device posture, or tunnel evidence is missing, incomplete, inconsistent, or behaviorally implausible. This report is not focused only on a single CVE or isolated edge-device exploit; it assesses GlobalProtect trusted-session compromise as a remote-access trust failure that can expose internal systems, privileged resources, identity services, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, and backup infrastructure. Immediate executive action is required to validate GlobalProtect authentication lineage, confirm remote-access telemetry integrity, harden exposed portals and gateways, and ensure suspicious VPN sessions are treated as trust-impacting events.

Executive Risk Translation

GlobalProtect authentication-lineage bypass shifts the business risk from perimeter exposure to loss of confidence in trusted remote access. The primary concern is that an attacker may establish or abuse a VPN session that appears legitimate while identity, MFA, certificate, posture, gateway, or session evidence does not reconcile. If the organization cannot prove that a VPN session followed the expected authentication path, response may expand into session revocation, credential resets, privileged-account review, identity-provider validation, firewall and VPN configuration review, cloud and SaaS access scoping, endpoint investigation, and broader assurance work across internal systems reached through the VPN path. This creates financial, operational, governance, and regulatory exposure beyond the firewall or VPN appliance itself.

S3 — Why This Matters Now

·        GlobalProtect portals and gateways are high-value remote-access control points because they sit between internet-facing users and internal enterprise resources.

·        Trusted VPN sessions can carry higher business impact than ordinary failed perimeter attempts because downstream systems may treat the activity as authorized.

·        Authentication-lineage gaps create uncertainty about whether identity-provider authentication, MFA, conditional access, SAML validation, certificate checks, HIP evaluation, device posture, gateway assignment, and tunnel establishment occurred as expected.

·        A suspicious VPN session can expose identity services, domain controllers, privileged management systems, jump hosts, file shares, backup systems, cloud consoles, SaaS administration portals, developer platforms, source-code repositories, and CI/CD environments.

·        Organizations may struggle to distinguish malicious trusted-session use from legitimate travel, mobile carrier changes, third-party support, SASE routing, regional gateway failover, VPN client upgrades, administrator workflows, or incident-response activity.

·        Missing identity-provider, MFA, HIP, certificate, or posture evidence may reflect logging gaps or ingestion delay, but it still creates a management problem because the organization cannot prove the trusted-access path remained intact.

·        The highest-risk condition occurs when suspicious VPN establishment is followed by internal reconnaissance, identity-service interaction, privileged resource access, administrative protocol use, cloud or SaaS control-plane activity, credential access, token access, or lateral movement.

S4 — Key Judgments

·        GlobalProtect authentication-lineage bypass is a remote-access trust risk, not only a vulnerability-management issue.

·        The primary enterprise risk is unauthorized or suspicious VPN session establishment where the expected authentication, MFA, certificate, posture, gateway, or session evidence cannot be reconciled.

·        A tunnel-established event without validated identity-provider, MFA, SAML, certificate, HIP, device-posture, gateway-assignment, or session-token evidence is the strongest executive risk signal when telemetry completeness has been validated.

·        Suspicious VPN access involving privileged, administrative, security, third-party, contractor, dormant, stale, recently re-enabled, service-adjacent, or low-frequency accounts materially increases business exposure.

·        Downstream access to identity infrastructure, domain controllers, privileged management systems, backup systems, developer environments, cloud consoles, SaaS administration portals, source-code systems, or CI/CD infrastructure is a major risk amplifier.

·        A vulnerable GlobalProtect version, unfamiliar source IP, unusual ASN, new geography, failed authentication event, or isolated portal request should not be treated as confirmed compromise without supporting session, identity, posture, or downstream behavior.

·        The most damaging outcome occurs when trusted VPN access enables credential validation, privileged internal access, lateral movement, cloud or SaaS control-plane activity, data access, ransomware staging, extortion, or loss of confidence in remote-access telemetry.

S5 — Executive Risk Summary

Business Risk

GlobalProtect authentication-lineage bypass can undermine confidence in the organization’s ability to control, validate, and investigate trusted remote access. Risk increases when affected VPN sessions involve privileged users, administrators, security staff, third parties, contractors, service-adjacent accounts, dormant accounts, low-frequency VPN users, or access to high-value internal, cloud, SaaS, developer, source-code, CI/CD, or backup environments.

Technical Cause

The risk is driven by gaps or inconsistencies between GlobalProtect portal activity, gateway authentication, tunnel establishment, identity-provider authentication, MFA or conditional-access decisions, SAML assertion context, certificate validation, HIP evaluation, device posture, gateway assignment, authentication cookies, session tokens, and downstream access behavior.

Threat Posture

The threat posture is elevated because trusted VPN session compromise can give attackers a path from internet-facing remote access into internal enterprise resources while appearing to downstream systems as a legitimate user session. The posture becomes critical when suspicious VPN establishment is followed by internal reconnaissance, identity-service access, privileged protocol use, credential validation, cloud or SaaS administrative activity, developer-platform access, or lateral movement.

Executive Decision Requirement

Executives must require measurable assurance that GlobalProtect authentication lineage can be reconstructed, exposed portals and gateways are patched and hardened, privileged and third-party VPN use is tightly governed, and response teams can rapidly validate, revoke, scope, and investigate suspicious trusted VPN sessions.

S6 — Executive Cost Summary

GlobalProtect authentication-lineage bypass and trusted VPN session compromise create scenario-based financial exposure when an organization must prove or disprove whether a trusted VPN session was legitimately established. The estimated impact is driven by remote-access trust restoration, authentication-lineage reconstruction, session revocation, credential reset activity, identity-provider and MFA validation, SAML and certificate review, HIP and device-posture review, GlobalProtect portal and gateway configuration validation, privileged VPN account scoping, downstream internal access analysis, and cloud, SaaS, developer-platform, source-code, CI/CD, or backup exposure assessment.

Low Impact Scenario

Rapid detection confirms attempted exploitation, suspicious portal or gateway interaction, isolated authentication-lineage uncertainty, or a small number of suspicious GlobalProtect events. No unauthorized tunnel establishment is confirmed, no privileged or third-party VPN account is abused, no internal reconnaissance occurs, no cloud or SaaS control-plane activity is linked, no credential or token exposure is identified, and telemetry is sufficient to validate the session path quickly; estimated impact $750K – $3M.

Moderate Impact Scenario

Confirmed or strongly suspected trusted VPN session compromise requires the organization to treat remote access as a trust-failure event even without confirmed ransomware, confirmed data theft, or full enterprise compromise. Response requires VPN session revocation, credential resets, MFA and conditional-access validation, SAML and identity-provider review, HIP and certificate posture validation, GlobalProtect portal and gateway configuration review, privileged and third-party VPN account scoping, internal access reconstruction, endpoint triage, SOC surge activity, and downstream validation of cloud, SaaS, developer-platform, source-code, CI/CD, or backup exposure; estimated impact $5M – $18M.

High Impact Scenario

Trusted VPN access becomes an enterprise-impact pathway when it leads to privileged internal access, identity-service interaction, domain-controller exposure, credential validation, lateral movement, cloud or SaaS control-plane activity, source-code or CI/CD exposure, backup-system access, data access, ransomware staging, extortion, or broad loss of confidence in remote-access and identity controls. The upper end of this range applies only when the trusted VPN path forces enterprise-scale restoration of GlobalProtect access, identity controls, privileged accounts, endpoint evidence, internal access paths, cloud and SaaS sessions, backup trust, or business-critical systems reached through the suspicious VPN path; estimated impact $25M – $100M+.

S6A — Key Cost Drivers

·        Number and criticality of suspicious or confirmed GlobalProtect VPN sessions.

·        Whether affected sessions involve privileged, administrative, security, third-party, contractor, dormant, stale, recently re-enabled, service-adjacent, or low-frequency VPN accounts.

·        Ability to reconstruct authentication lineage across GlobalProtect portal events, gateway events, identity-provider authentication, MFA decisions, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, tunnel establishment, authentication-cookie context, and session-token context.

·        Scope of session revocation, credential reset, token review, certificate review, MFA review, conditional-access review, HIP-policy review, and privileged-account validation.

·        Scope of GlobalProtect portal, gateway, PAN-OS, authentication profile, gateway assignment, HIP profile, certificate configuration, split-tunnel, and remote-access policy review.

·        Extent of internal access from the suspicious VPN session, including access to identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, databases, file shares, or sensitive business applications.

·        Evidence of internal reconnaissance, credential validation, token access, credential theft, persistence, remote administration tooling, lateral movement, outbound communication, or post-session endpoint activity.

·        Need to validate downstream cloud, SaaS, developer-platform, source-code, CI/CD, privileged application, and backup-system exposure after suspicious VPN access.

·        Completeness and reliability of GlobalProtect, PAN-OS, identity-provider, MFA, HIP, endpoint, NDR, DNS, proxy, cloud, SaaS, and SIEM telemetry.

·        Degree to which split tunneling, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, proxy paths, or third-party access paths reduce visibility, source attribution, or session-linkage confidence.

·        Need for external incident response, forensic support, legal review, insurance coordination, customer communication, regulatory analysis, executive reporting, or board-level governance when trusted remote access cannot be validated quickly.

Most Likely Scenario Justification

Moderate scenario is most likely because a suspected GlobalProtect trusted-session compromise can create significant investigation, containment, and assurance cost even when ransomware, confirmed data theft, or full enterprise compromise is not proven. The estimate moves toward the lower end when authentication-lineage evidence is complete, session linkage is reliable, identity-provider and MFA evidence reconcile quickly, internal access is limited, privileged resources are not touched, and cloud or SaaS linkage is ruled out. The estimate moves toward the upper end when authentication-lineage evidence is incomplete, privileged or third-party accounts are involved, internal reconnaissance occurs, high-value systems are accessed, cloud or SaaS control-plane activity must be scoped, or missing telemetry forces broader validation of remote-access trust.

S6B — Compliance and Risk Context

Figure 1

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

GlobalProtect Trusted VPN Session Compromise and Remote-Access Trust Failure

Risk Description

Adversaries may establish or abuse GlobalProtect VPN sessions where expected authentication-lineage evidence, identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, device posture, gateway assignment, authentication-cookie state, session-token state, or tunnel evidence is missing, incomplete, inconsistent, or behaviorally implausible. This may allow trusted remote access to internal systems, privileged resources, identity infrastructure, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, or backup infrastructure while reducing confidence in session legitimacy and incident scoping.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $5M – $20M+ for materially exposed enterprise environments with internet-facing GlobalProtect dependency, privileged or third-party VPN use, and meaningful downstream identity, cloud, SaaS, developer-platform, source-code, CI/CD, or backup exposure. Exposure may exceed $25M where trusted VPN access is tied to privileged identity paths, cloud or SaaS administration, source-code systems, CI/CD environments, backup infrastructure, ransomware or extortion impact, incomplete telemetry, or broad remote-access trust restoration.

S7 — Risk Drivers

·        Internet-facing GlobalProtect portals and gateways are high-value access paths into enterprise environments.

·        Trusted VPN sessions may be treated as legitimate by downstream internal systems, cloud systems, SaaS platforms, and security controls.

·        Authentication-lineage gaps can make it difficult to prove whether identity-provider authentication, MFA, SAML validation, certificate checks, HIP evaluation, device posture, gateway assignment, and tunnel establishment occurred correctly.

·        Privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts can materially increase downstream exposure.

·        Split tunneling, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, mobile networks, and third-party access paths can reduce visibility and source-attribution confidence.

·        Missing or delayed GlobalProtect, PAN-OS, identity-provider, MFA, HIP, endpoint, internal network, cloud, SaaS, or SIEM telemetry can force broader investigation and assurance work.

·        VPN-authenticated access to identity services, domain controllers, jump hosts, privileged management systems, backup platforms, endpoint-management systems, developer environments, source-code systems, CI/CD platforms, or sensitive applications increases business impact.

·        Cloud, SaaS, source-code, CI/CD, and developer-platform activity after suspicious VPN access can expand the incident beyond the perimeter-access layer.

·        Legitimate travel, vendor support, helpdesk activity, administrator workflows, security testing, incident response, regional gateway failover, VPN client upgrades, and identity-provider maintenance can resemble suspicious activity and increase triage burden.

·        Incomplete change-control records, weak account baselines, weak device baselines, incomplete gateway inventories, and inconsistent session identifiers reduce confidence during response.

S8 — Bottom Line for Executives

GlobalProtect authentication-lineage bypass should be treated as a high-priority remote-access trust risk because it can allow suspicious or unauthorized activity to enter the environment through a channel that downstream systems may already trust. The key executive concern is not only whether a portal or gateway was vulnerable, but whether the organization can prove each VPN session followed the expected authentication path and whether any suspicious trusted session reached privileged internal, cloud, SaaS, developer, source-code, CI/CD, or backup resources. Response must focus on validating authentication lineage, restoring confidence in remote-access controls, revoking suspicious sessions, scoping downstream access, and ensuring privileged VPN activity can be investigated quickly and reliably.

S9 — Board-Level Takeaway

GlobalProtect trusted-session compromise turns remote access into a board-level trust and governance issue. The risk is not limited to firewall exposure; it is the possibility that attackers can use or appear to use a legitimate VPN path while authentication, MFA, posture, gateway, or session evidence does not reconcile. Leadership should require measurable assurance that GlobalProtect authentication lineage is visible, exposed portals and gateways are hardened, privileged VPN use is governed, suspicious sessions are revoked quickly, and downstream access to identity, cloud, SaaS, developer, source-code, CI/CD, backup, and business-critical systems can be scoped with confidence.

S10 — Threat Overview

GlobalProtect authentication-lineage bypass and trusted VPN session compromise describe adversary behavior intended to obtain, establish, or abuse a trusted VPN session when the expected remote-access authentication sequence does not reconcile. The behavior is most relevant when a VPN tunnel appears valid while supporting identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, device posture, gateway assignment, authentication-cookie state, session-token state, or client configuration retrieval evidence is missing, incomplete, inconsistent, or behaviorally implausible.

·        This is not only a single-CVE, single-request, or edge-device vulnerability model.

·        The core threat behavior is abuse of a trusted remote-access path where authentication lineage cannot be proven.

·        The primary risk is loss of confidence in the VPN session layer used to separate trusted users from untrusted internet-facing access.

·        GlobalProtect portal, gateway, identity-provider, MFA, SAML, certificate, HIP, device-posture, and tunnel evidence may appear incomplete or inconsistent while downstream systems treat the session as authorized.

·        The behavior can allow attackers to reach internal systems, identity services, privileged resources, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, or backup infrastructure through a trusted access channel.

·        Current proof-point activity should support the relevance of the behavior class but should not narrow the report into a single-CVE or single-proof-of-concept analysis.

S11 — Threat Classification and Type

Threat Type

Remote-access trust abuse and authentication-lineage failure

Threat Sub-Type

GlobalProtect trusted VPN session compromise, portal-to-gateway sequencing anomaly, authentication-lineage bypass, SAML or MFA evidence mismatch, HIP or device-posture inconsistency, gateway-assignment anomaly, session-token inconsistency, authentication-cookie inconsistency, and downstream trusted-session misuse.

Operational Classification

Intrusion-enabling remote-access trust failure

Primary Function

Obtain or abuse trusted VPN access without a complete and expected authentication lineage, allowing suspicious activity to appear authorized while the organization loses confidence in session legitimacy, remote-access control integrity, and downstream scoping evidence.

S12 — Campaign or Activity Overview

Figure 2

This report assesses GlobalProtect authentication-lineage bypass and trusted VPN session compromise as a behavior class rather than a single campaign. The activity pattern involves attackers attempting to establish, inherit, replay, or abuse trusted VPN access where the expected relationship between portal activity, identity-provider authentication, MFA decision, SAML context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, tunnel establishment, and internal access does not align.

·        The activity is best understood as a remote-access trust failure rather than a simple perimeter scan or isolated failed authentication event.

·        Adversaries may target exposed GlobalProtect portals or gateways, authentication flows, session-state transitions, authentication cookies, session tokens, certificate context, HIP posture, or gateway-assignment behavior.

·        The behavior may involve direct bypass attempts, stolen or replayed session material, abused valid accounts, inconsistent identity-provider evidence, mismatched MFA context, posture inconsistency, or trusted-session misuse after abnormal portal or gateway interaction.

·        The activity may remain limited to suspicious session establishment, or it may progress into internal reconnaissance, identity-service access, privileged resource access, administrative protocol use, endpoint activity, cloud control-plane access, SaaS administration, developer-platform access, source-code access, CI/CD interaction, or backup-system exposure.

·        The activity becomes highest risk when suspicious VPN session establishment involves privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts.

·        The report should remain focused on durable behavior and authentication-lineage failure rather than one exploit string, one request path, one user-agent, one source IP, one PAN-OS version, or one proof-of-concept pattern.

S13 — Targets and Exposure Surface

The exposure surface includes internet-facing GlobalProtect portals and gateways, authentication dependencies, posture validation paths, VPN session-state evidence, privileged VPN users, and downstream systems reachable through trusted remote access.

·        Internet-facing GlobalProtect portals and gateways.

·        PAN-OS remote-access infrastructure supporting GlobalProtect portal, gateway, authentication, policy, HIP, and tunnel functions.

·        Organizations with SAML, OIDC, MFA, conditional-access, certificate-based authentication, HIP enforcement, or device-posture dependencies tied to GlobalProtect access.

·        VPN users with privileged, administrative, security, helpdesk, remote-access, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency account profiles.

·        Gateway-assignment, gateway-selection, split-tunnel, regional gateway, SASE routing, ZTNA overlay, proxy, NAT, carrier-grade NAT, mobile network, and third-party access paths that can complicate source attribution and session linkage.

·        Identity infrastructure, domain controllers, privileged management systems, jump hosts, firewall management interfaces, VPN administration interfaces, endpoint-management systems, backup systems, source-code systems, CI/CD infrastructure, databases, file shares, and sensitive internal applications reachable through VPN access.

·        Cloud consoles, cloud APIs, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD platforms, and privileged business applications accessed after VPN establishment.

·        Environments with incomplete GlobalProtect portal logs, gateway logs, HIP logs, tunnel-established events, authentication-cookie context, session-token context, identity-provider logs, MFA logs, endpoint telemetry, internal network telemetry, or cloud and SaaS audit logs.

·        Environments with weak account baselines, weak device baselines, incomplete gateway inventories, incomplete certificate inventories, limited change-control evidence, or inconsistent session identifiers across VPN, identity, endpoint, network, cloud, and SIEM telemetry.

S14 — Sectors / Countries Affected

Sectors Affected

·        Financial services.

·        Healthcare and life sciences.

·        Technology and software development.

·        Manufacturing and industrial operations.

·        Energy and utilities.

·        Retail and e-commerce.

·        Education and research institutions.

·        Government and public-sector organizations.

·        Telecommunications and managed infrastructure providers.

·        Legal, consulting, and professional services organizations with high-value remote access.

·        Organizations with internet-facing GlobalProtect portals or gateways, privileged VPN users, third-party VPN access, remote administrator access, cloud or SaaS administration, source-code systems, CI/CD environments, backup infrastructure, or regulated data environments.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because GlobalProtect remote-access infrastructure is broadly deployed across enterprise environments.

·        Countries with large enterprise remote-work populations, regulated industries, cloud administration dependencies, government operations, critical infrastructure, technology development, or high-value business-service environments may face elevated operational exposure.

·        Country-specific impact should be assessed by GlobalProtect exposure, patch posture, authentication architecture, MFA enforcement, HIP and certificate policy, privileged VPN access, telemetry quality, third-party access governance, and incident-response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require enough technical capability to understand GlobalProtect portal and gateway behavior, authentication sequencing, identity-provider dependencies, MFA or conditional-access flow, SAML assertion context, certificate validation, HIP posture, gateway assignment, session-state transitions, authentication-cookie use, session-token behavior, and downstream VPN-authenticated access. The behavior can be performed through direct exploitation, valid-account abuse, session-material misuse, or trusted-session abuse, but effective use requires operational judgment and awareness of how remote-access evidence is generated and validated.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may involve probing exposed GlobalProtect portals or gateways from hosting providers, mobile networks, residential proxy infrastructure, or anonymization services. Higher-maturity activity involves source rotation, infrastructure that resembles normal remote work, SASE-adjacent egress paths, stolen or replayed session material, low-noise VPN session use, delayed internal access, or downstream cloud, SaaS, identity, developer-platform, source-code, CI/CD, or backup-system activity.

Operational Scale

Single-session to enterprise-scale

Operational scale ranges from one suspicious VPN session to broader enterprise impact when attackers target privileged users, third-party accounts, remote administrators, multiple VPN users, multiple gateways, identity services, domain controllers, privileged management systems, cloud control planes, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, or backup infrastructure.

Escalation Likelihood

High

Escalation likelihood is high when suspicious VPN session establishment involves privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts. Escalation likelihood increases further when the VPN session is followed by internal reconnaissance, identity-service interaction, privileged protocol use, endpoint activity, credential validation, cloud or SaaS control-plane access, source-code access, CI/CD interaction, backup-system access, or lateral movement.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        GlobalProtect portals and gateways are internet-facing access points for enterprise remote access.

·        Attackers benefit directly from obtaining trusted VPN access because downstream systems may treat the session as authorized.

·        Authentication-lineage gaps can reduce confidence in whether identity-provider authentication, MFA, SAML validation, certificate checks, HIP evaluation, device posture, gateway assignment, and tunnel establishment occurred correctly.

·        Privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, and low-frequency VPN accounts create high-value access opportunities.

·        Remote-work, travel, mobile carrier networks, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, regional gateway failover, and third-party support can complicate source attribution and increase attacker cover.

·        Incomplete GlobalProtect, identity-provider, MFA, HIP, endpoint, internal network, cloud, SaaS, or SIEM telemetry increases attacker opportunity and response uncertainty.

·        Internal systems reachable through trusted VPN access may include identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, source-code systems, CI/CD platforms, databases, file shares, and sensitive business applications.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup dependencies increase the value of a trusted VPN session beyond the remote-access layer.

Most Likely Targets

·        Internet-facing GlobalProtect portals and gateways.

·        Organizations with exposed or difficult-to-validate PAN-OS and GlobalProtect patch posture.

·        Privileged VPN users and remote administrators.

·        Third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Environments using SAML, MFA, conditional access, certificate validation, HIP enforcement, or device posture for GlobalProtect access.

·        Identity infrastructure, domain controllers, privileged management systems, jump hosts, firewall management interfaces, and VPN administration interfaces reachable through VPN access.

·        Backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, databases, file shares, and sensitive internal applications.

·        Cloud consoles, SaaS administration portals, developer platforms, source-code repositories, CI/CD platforms, and privileged business applications accessed after VPN establishment.

·        Environments with incomplete VPN session telemetry, weak account baselines, inconsistent session identifiers, split-tunnel visibility gaps, limited internal network telemetry, or poor change-control evidence.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1: Exposed Remote-Access Entry Point or Valid Access

The adversary targets internet-facing GlobalProtect remote-access infrastructure or attempts to use valid credentials to reach the VPN environment. Exploit-driven activity maps to public-facing application exposure, while credential-driven or account-driven activity maps to valid-account use.

·        T1190 — Exploit Public-Facing Application.

·        T1078 — Valid Accounts.

Stage 2: Session Material or Authentication Context Abuse

The adversary attempts to obtain, reuse, replay, or abuse authentication material or session context associated with a trusted VPN path. This stage captures session-material and authentication-context abuse without overstating direct modification of the authentication process.

·        T1550 — Use Alternate Authentication Material.

Stage 3: Trusted VPN Session Establishment

The adversary establishes or abuses an external remote-access session that downstream systems may treat as legitimate even when authentication-lineage, posture, gateway, or session evidence is incomplete, mismatched, or suspicious.

·        T1133 — External Remote Services.

Stage 4: Internal Discovery After VPN Access

After VPN access, the adversary may identify reachable systems, user context, account relationships, and internal resources available from the trusted access path.

·        T1018 — Remote System Discovery.

·        T1087 — Account Discovery.

Stage 5: Remote Access Expansion or Lateral Movement Path

If the trusted VPN session is not contained, the adversary may use remote services to access additional systems or expand from the initial VPN-enabled position.

·        T1021 — Remote Services.

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

GlobalProtect authentication-lineage bypass and trusted VPN session compromise begin when an adversary targets the remote-access trust path rather than only the perimeter device. The attacker’s objective is to obtain, establish, or abuse a VPN session that appears trusted while the expected relationship between portal activity, identity-provider authentication, MFA decision, SAML context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, tunnel establishment, and downstream access does not reconcile. The attack path is defined by exposed remote-access access, authentication-lineage failure, trusted VPN session establishment, downstream internal access, and potential expansion into privileged, identity, cloud, SaaS, developer, source-code, CI/CD, or backup environments.

Stage 1: Exposed Remote-Access Entry Point or Valid Access

The adversary targets internet-facing GlobalProtect portal or gateway infrastructure, abuses valid credentials, or attempts to use session material, authentication context, or access conditions associated with the remote-access environment. This stage creates the opportunity to interact with the VPN trust path and test whether portal, gateway, identity-provider, MFA, certificate, HIP, or session-state controls can be bypassed, replayed, mismatched, or abused.

Stage 2: Authentication-Lineage Failure

The adversary attempts to create or use a VPN authentication sequence where expected evidence does not align. This may involve missing identity-provider evidence, missing MFA or conditional-access evidence, mismatched SAML context, certificate inconsistency, HIP or device-posture inconsistency, unexpected gateway assignment, authentication-cookie inconsistency, session-token inconsistency, or portal-to-gateway sequencing gaps. The key risk signal is not a single failed login or single suspicious source; it is the inability to prove that the VPN session followed the expected authentication path.

Stage 3: Trusted VPN Session Establishment

The adversary establishes or abuses a GlobalProtect VPN session that downstream systems may treat as legitimate. The session may appear valid at the gateway or tunnel layer while the supporting authentication lineage remains incomplete, delayed, mismatched, or behaviorally implausible. This stage converts the activity from perimeter exposure into a remote-access trust event because the organization must determine whether the VPN session should have been trusted.

Stage 4: Downstream Internal Access

After VPN establishment, the adversary may access internal systems through the trusted remote-access path. This can include DNS activity, LDAP or Kerberos interaction, SMB access, RDP, SSH, WinRM, database access, file-share access, jump-host access, privileged-management access, identity-service interaction, firewall management access, VPN administration access, endpoint-management access, backup-system access, or sensitive application access. The risk increases when the activity reaches systems outside the user’s normal role or access history.

Stage 5: Control-Plane and High-Value Resource Exposure

If the trusted VPN session is not contained, the adversary may use the access path to reach cloud consoles, cloud APIs, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD systems, privileged business applications, or backup infrastructure. This stage expands the incident beyond VPN access by creating potential exposure to identity control planes, administrative systems, sensitive data, source-code assets, automation pipelines, and recovery infrastructure.

Stage 6: Expansion Path

If not contained, the trusted VPN session may become a launch point for broader compromise. The adversary may validate credentials, access remote services, use administrative protocols, move laterally, stage tools, abuse privileged resources, or continue activity from infrastructure that resembles legitimate remote work. Response burden increases because defenders must investigate both the attacker’s actions and whether the VPN, identity, posture, and session evidence remained trustworthy during the compromise window.

S19 — Attack Chain Risk Amplification Summary

GlobalProtect authentication-lineage bypass amplifies risk because it attacks the trust path used to grant remote access. The chain becomes materially more dangerous when a VPN session appears valid while the organization cannot prove that identity-provider authentication, MFA, SAML validation, certificate checks, HIP evaluation, device posture, gateway assignment, and tunnel establishment occurred correctly.

·        Exposed GlobalProtect portals and gateways provide an internet-facing path into remote-access infrastructure.

·        Valid credentials, stolen session material, replayed authentication context, or authentication-lineage gaps can allow suspicious activity to resemble legitimate VPN use.

·        Portal-to-gateway sequencing gaps reduce confidence that the VPN session followed the expected authentication path.

·        Missing or inconsistent identity-provider, MFA, SAML, certificate, HIP, device-posture, authentication-cookie, or session-token evidence creates remote-access trust uncertainty.

·        Trusted VPN session establishment increases risk because downstream systems may treat the session as authorized.

·        Privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts increase business impact.

·        Internal access after suspicious VPN establishment increases risk when it reaches identity infrastructure, domain controllers, jump hosts, privileged management systems, backup systems, endpoint-management platforms, file shares, databases, or sensitive applications.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, or backup activity after suspicious VPN access expands the event beyond the perimeter-access layer.

·        Split tunneling, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, proxy paths, and third-party access paths can reduce visibility and attribution confidence.

·        Response burden increases because teams must validate both attacker activity and whether remote-access, identity, posture, and session evidence remained trustworthy.

S20 — Tactics, Techniques, and Procedures

Figure 3

Remote-Access Exposure and Access Attempt

Adversaries may target internet-facing GlobalProtect portals or gateways, attempt exploit-driven access, use valid credentials, or test remote-access conditions that allow interaction with the VPN trust path. This activity may resemble scanning, failed authentication, legitimate travel, third-party access, or normal remote-work behavior unless it is followed by authentication-lineage gaps, suspicious tunnel establishment, or downstream trusted-session use.

Authentication-Lineage and Trusted Session Abuse

Adversaries may attempt to obtain, establish, inherit, replay, or abuse a GlobalProtect VPN session where the expected authentication sequence does not reconcile. Relevant signals include missing identity-provider evidence, missing MFA or conditional-access evidence, mismatched SAML context, certificate inconsistency, HIP or device-posture inconsistency, unexpected gateway assignment, authentication-cookie inconsistency, session-token inconsistency, incomplete portal-to-gateway sequencing, or tunnel establishment without expected precursor activity. The session becomes risk-relevant when downstream systems treat the VPN connection as legitimate despite incomplete, mismatched, delayed, or behaviorally implausible supporting evidence.

Source, Account, and Posture Context Manipulation

Adversaries may use infrastructure that resembles legitimate remote access, including hosting providers, residential proxy infrastructure, mobile carrier networks, anonymization services, SASE-adjacent egress paths, compromised infrastructure, or locations that overlap with normal user behavior. They may also use privileged, third-party, dormant, stale, recently re-enabled, service-adjacent, or low-frequency accounts to increase access value while blending into expected VPN patterns. Device posture, certificate context, client version, operating-system profile, HIP result, or gateway assignment may be inconsistent with the claimed user or endpoint.

Internal Discovery and Privileged Resource Access

After VPN access, adversaries may perform discovery, query identity services, validate account access, enumerate reachable systems, or identify high-value internal destinations. Activity may include DNS lookups, LDAP or Kerberos interaction, SMB access, RDP, SSH, WinRM, database access, file-share access, jump-host access, privileged-management access, or access to systems outside the user’s normal role. The activity becomes higher risk when it reaches domain controllers, identity infrastructure, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, databases, or sensitive business applications.

Cloud, SaaS, Developer-Platform, and Backup Exposure

Adversaries may use VPN-enabled access to reach cloud consoles, cloud APIs, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD systems, privileged business applications, or backup infrastructure. This activity should be treated as related only when timing, identity, device, source path, session context, or incident-response evidence links it to suspicious VPN establishment. When validated, this path expands the incident from remote-access trust uncertainty into control-plane, business-application, recovery, or software-supply-chain exposure.

Credential, Token, and Expansion Path

Adversaries may use the suspicious VPN session as a path to credential validation, token access, browser credential-store exposure, cloud CLI use, SaaS administration, source-code access, CI/CD interaction, recurring account access, remote services, administrative protocol use, tool staging, or movement into additional systems. This behavior should be treated as a conditional high-risk follow-on path, not assumed from VPN activity alone unless endpoint, identity, cloud, SaaS, developer-platform, network, or incident-response evidence supports the linkage.

S20A — Adversary Tradecraft Summary

GlobalProtect authentication-lineage bypass targets remote-access trust rather than VPN exposure alone. The adversary objective is to obtain or abuse a VPN session that appears trusted while the organization cannot prove the expected identity, MFA, posture, gateway, or session sequence. The tradecraft is effective because it can blend with legitimate remote work, travel, vendor access, SASE routing, mobile networks, administrator activity, and normal VPN operations while forcing responders to validate both the session and the downstream activity that followed it.

·        The core tradecraft pattern is trusted VPN access without complete and expected authentication lineage.

·        The behavior is not dependent on a single CVE, exploit string, request path, user-agent, source IP, PAN-OS version, or proof-of-concept pattern.

·        Adversaries may use exploit-driven access, valid credentials, stolen or replayed session material, inconsistent authentication context, or trusted-session abuse.

·        The strongest operational risk occurs when suspicious VPN establishment is followed by internal reconnaissance, identity-service interaction, privileged resource access, administrative protocol use, cloud or SaaS control-plane activity, developer-platform access, source-code access, CI/CD interaction, backup-system access, credential validation, or lateral movement.

·        Detection requires visibility into both GlobalProtect session behavior and the authentication-lineage evidence that should support the session.

·        Response requires treating suspicious trusted VPN sessions as trust-impacting events, not routine remote-access anomalies.

·        The behavior remains durable because the adversary objective is trusted access with weakened session confidence, regardless of the specific exploit mechanism or infrastructure used.

S21 — Detection Strategy Overview

Detection Philosophy

Detection for this report must treat GlobalProtect authentication-lineage bypass and trusted VPN session compromise as a staged remote-access trust failure rather than a single edge-device exploit. The core detection objective is to identify when an attacker establishes, attempts to establish, or abuses a VPN session that appears trusted while the expected authentication sequence is missing, incomplete, inconsistent, or behaviorally implausible.

For this report, authentication lineage means the expected progression from portal request to identity-provider authentication, MFA or conditional-access decision, certificate or device-posture validation, HIP evaluation, gateway assignment, tunnel establishment, and internal access. Detection should focus on gaps, mismatches, or impossible transitions across that sequence, especially where GlobalProtect portal authentication events, gateway authentication events, tunnel-established events, HIP match results, HIP report results, client configuration retrieval, authentication cookies, session tokens, or SAML assertions do not reconcile with each other.

The strongest detection value comes from correlating VPN-edge telemetry with identity-provider evidence, MFA or conditional-access context, certificate posture, HIP evaluation, gateway assignment, client configuration retrieval, and post-connection internal activity. A GlobalProtect connection from an unusual source is not enough by itself to prove compromise. A failed authentication event is not enough by itself to prove bypass. Missing identity-provider evidence may reflect a logging gap, ingestion delay, parser issue, or retention problem rather than confirmed authentication bypass.

This detection strategy should remain behavior-led and variant-resilient. It should not depend on one CVE identifier, one exploit string, one request path, one user-agent, one source IP, one PAN-OS version, one certificate configuration, or one proof-of-concept pattern because an attacker can alter exploit mechanics, infrastructure, timing, session behavior, and post-access actions without changing the underlying operational model.

Primary Detection Anchors

·        GlobalProtect portal authentication events that do not align with expected identity-provider authentication, MFA, conditional-access, SAML, certificate, HIP, or device-posture evidence.

·        GlobalProtect gateway authentication events that do not align with portal authentication, gateway assignment, SAML assertion context, authentication cookie use, session-token state, or expected tunnel establishment.

·        Tunnel-established events where the expected portal request, identity-provider authentication, MFA or conditional-access decision, certificate validation, HIP evaluation, or gateway-selection sequence is absent, incomplete, delayed, or inconsistent.

·        HIP match results, HIP report results, device-posture values, certificate context, endpoint identity, client version, operating-system profile, or GlobalProtect client configuration retrieval that is missing, downgraded, newly observed, or inconsistent with the claimed user or endpoint.

·        Gateway selection or gateway-assignment anomalies involving unexpected gateway choice, unusual region assignment, unfamiliar source infrastructure, inconsistent user mapping, or session behavior that does not match normal GlobalProtect routing patterns.

·        SAML assertion, identity-provider session, MFA result, authentication cookie, or session-token context that does not reconcile with the GlobalProtect portal, gateway, user, device, source IP, timestamp, or tunnel session.

·        Successful VPN connection from a source IP, ASN, geography, hosting provider, anonymization network, carrier network, device fingerprint, client version, or operating-system profile that is inconsistent with the claimed user’s normal access history.

·        GlobalProtect authentication or session events involving dormant, stale, recently re-enabled, third-party, contractor, service-adjacent, privileged, administrative, or low-frequency accounts.

·        VPN session establishment followed by internal access to identity services, domain controllers, VPN administration interfaces, firewall management interfaces, jump hosts, privileged management systems, file shares, cloud consoles, SaaS administration portals, development environments, or backup infrastructure.

·        VPN-authenticated traffic followed by internal discovery, credential validation, LDAP or Kerberos activity, SMB enumeration, RDP, SSH, WinRM, database access, administrative share access, or sensitive application probing.

Detection Prioritization Model

·        Highest priority should be assigned to tunnel-established events where the firewall or gateway shows a valid VPN session but the expected identity-provider, MFA, certificate, HIP, conditional-access, gateway-assignment, or device-posture evidence is absent, incomplete, delayed, or inconsistent.

·        Highest priority should be assigned to successful VPN session establishment involving privileged, administrative, remote-access, security, third-party, service-adjacent, or low-frequency accounts when authentication-lineage artifacts do not reconcile.

·        High priority should be assigned to portal-to-gateway sequencing gaps where portal authentication, client configuration retrieval, gateway authentication, gateway assignment, tunnel establishment, and policy evaluation do not occur in an expected order.

·        High priority should be assigned to VPN sessions from unfamiliar infrastructure when followed by internal reconnaissance, identity-service access, privileged application access, sensitive file-share access, administrative protocol use, or cloud and SaaS control-plane interaction.

·        High priority should be assigned to abnormal GlobalProtect portal or gateway interaction followed by successful session establishment, especially when the activity involves unknown patch posture, vulnerable PAN-OS exposure, internet-facing gateways, or missing compensating controls.

·        Medium priority should be assigned to VPN sessions from new geographies, ASNs, device profiles, client versions, or operating-system profiles when downstream behavior remains limited but the access pattern is materially unfamiliar.

·        Medium priority should be assigned to repeated failed, malformed, incomplete, or scanner-like GlobalProtect interactions where no successful tunnel establishment is confirmed but the pattern suggests probing or bypass attempts against exposed portal or gateway services.

·        Lower priority should be assigned to isolated failed authentication attempts, isolated scanning, single-source probing, or new source IP use that aligns with expected travel, carrier NAT, corporate routing changes, approved third-party access, known remote-work patterns, SASE routing, or documented VPN client changes.

Correlation Strategy

Correlation must separate exposed GlobalProtect infrastructure, suspected bypass activity, unauthorized VPN session establishment, suspicious trusted-session use, and confirmed downstream compromise.

VPN-edge compromise suspicion should require at least one strong GlobalProtect-side anchor. Acceptable anchors include abnormal portal interaction, abnormal gateway interaction, unexpected session-state transition, portal-to-gateway sequencing gaps, gateway-assignment anomaly, tunnel-established event without expected precursor activity, client configuration retrieval anomaly, authentication cookie inconsistency, session-token inconsistency, HIP mismatch, or successful VPN access after abnormal pre-session behavior.

Authentication-lineage suspicion should require at least one strong identity or access-control anchor. Acceptable anchors include missing identity-provider authentication, missing MFA evidence, mismatched SAML assertion, mismatched certificate context, unexpected conditional-access outcome, absent HIP result, mismatched user identity, mismatched source IP, mismatched device identifier, impossible login sequence, or session creation that cannot be reconciled with normal authentication evidence.

Downstream compromise suspicion should require at least one strong post-session anchor. Acceptable anchors include internal discovery, identity-service access, credential validation, lateral movement, privileged protocol use, access to sensitive systems, abnormal data access, remote administration activity, cloud control-plane interaction, SaaS administration activity, or endpoint activity inconsistent with the user’s role and history.

A vulnerable GlobalProtect version alone must not be treated as active exploitation. A failed authentication event alone must not be treated as bypass. A new VPN source IP alone must not be treated as compromise. A tunnel-established event alone must not be treated as malicious unless authentication-lineage, gateway-sequencing, posture, or downstream behavior supports escalation.

Internal discovery is not automatically GlobalProtect compromise unless it is temporally and behaviorally linked to suspicious VPN session establishment, missing authentication-lineage evidence, or unauthorized trusted-session use. Cloud and SaaS anomalies should remain downstream investigative leads unless they can be tied to a suspicious VPN session, trusted-session abuse, credential theft, token abuse, or other validated post-session activity.

Confirmed campaign-aligned escalation should require evidence from at least two stages of the chain. Preferred escalation paths include abnormal portal or gateway activity followed by unauthorized session establishment, tunnel establishment without matching identity-provider or MFA evidence, portal-to-gateway sequencing gaps followed by internal reconnaissance, or trusted VPN access followed by privileged identity, cloud, SaaS, or lateral-movement behavior.

Telemetry Prioritization

·        GlobalProtect portal authentication events.

·        GlobalProtect gateway authentication events.

·        GlobalProtect tunnel-established events.

·        GlobalProtect gateway-assignment and gateway-selection logs.

·        GlobalProtect client configuration retrieval events.

·        GlobalProtect HIP match results and HIP report results.

·        GlobalProtect authentication cookie, session-token, user mapping, and session-state telemetry where available.

·        PAN-OS traffic, threat, system, configuration, authentication, management, and administrative logs associated with the affected firewall, portal, gateway, and VPN edge.

·        Identity-provider logs, including SAML, OIDC, directory authentication, MFA, conditional-access, device-compliance, risk-based access, session, token, assertion, and policy-decision events.

·        Endpoint and VPN client telemetry showing GlobalProtect client version, device identity, certificate use, network adapter creation, process activity, source address context, operating-system profile, and post-connection behavior where available.

·        Network telemetry showing internal access after VPN establishment, including DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, HTTP/S, database, file-share, jump-host, identity-service, and administrative-protocol traffic.

·        EDR telemetry from internal systems accessed after suspicious VPN session establishment.

·        Cloud identity, SaaS, and cloud control-plane logs where VPN-authenticated access is followed by privileged cloud, SaaS, identity, or administrative activity.

·        Asset inventory, VPN user inventory, privileged account inventory, third-party access inventory, device inventory, certificate inventory, gateway inventory, and approved remote-access source baselines.

·        Vulnerability, patch, exposure, internet-facing asset, and compensating-control context for GlobalProtect portals and gateways.

Detection Design Constraints

·        Detection must not rely only on CVE-2026-0257 because the report scope is authentication-lineage bypass and trusted VPN session compromise, not a single-vulnerability report.

·        Detection must not rely only on GlobalProtect version metadata because version posture may be incomplete, delayed, hidden behind operational processes, or unavailable in centralized telemetry.

·        Detection must not rely only on source IP, ASN, geography, user-agent, client version, or device fingerprint because legitimate remote-access patterns may vary and attackers can rotate infrastructure.

·        Detection must distinguish unauthorized VPN session establishment from legitimate travel, carrier NAT, corporate routing changes, SASE routing, disaster-recovery access, vendor access, third-party support, VPN client upgrades, and remote-work changes.

·        Detection must distinguish missing authentication-lineage evidence from telemetry delay, ingestion gaps, identity-provider outages, log-retention limits, SAML logging differences, MFA-provider visibility gaps, parser failure, or timestamp skew.

·        Detection must distinguish suspicious post-VPN behavior from legitimate administrator, helpdesk, engineering, security, IT operations, vulnerability management, and incident-response workflows.

·        Detection must avoid attributing internal discovery, cloud anomalies, SaaS anomalies, identity anomalies, or endpoint anomalies to GlobalProtect compromise unless the activity is temporally and behaviorally linked to suspicious VPN session establishment, missing authentication-lineage evidence, or unauthorized trusted-session use.

·        Detection must account for environments where VPN logs, identity-provider logs, MFA logs, HIP results, device posture results, endpoint telemetry, network telemetry, and cloud logs are stored in different platforms with inconsistent timestamps, user identifiers, device identifiers, source IPs, and session identifiers.

·        Detection must account for split-tunnel configurations where internal traffic visibility may be partial, delayed, or dependent on endpoint, EDR, DNS, proxy, firewall, or internal network telemetry.

Public Implementation Considerations

·        Maintain an inventory of GlobalProtect portals, gateways, exposed interfaces, affected PAN-OS versions, patch posture, gateway assignments, authentication methods, SAML providers, MFA providers, HIP profiles, certificate requirements, split-tunnel configuration, and compensating controls.

·        Establish normal patterns for GlobalProtect portal requests, portal authentication, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, HIP evaluation, client versions, source geographies, ASNs, remote-work locations, third-party access, and privileged-user VPN behavior.

·        Validate whether PAN-OS, GlobalProtect, identity-provider, MFA, conditional-access, endpoint, and SIEM logs share reliable identifiers for usernames, device IDs, source IPs, timestamps, SAML session context, gateway names, and VPN session records.

·        Confirm whether HIP logs, HIP reports, gateway authentication logs, gateway-assignment logs, and tunnel-established events are retained long enough to support investigation across delayed access, low-and-slow use, and post-session activity.

·        Confirm whether VPN split-tunnel configuration affects visibility into internal traffic, DNS resolution, SaaS access, cloud access, proxy coverage, endpoint network telemetry, or downstream investigation.

·        Confirm whether NAT, carrier-grade NAT, SASE routing, ZTNA overlays, proxy infrastructure, mobile networks, and third-party access paths affect source attribution, geography interpretation, ASN analysis, or source-risk scoring.

·        Validate that required telemetry can support correlation across PAN-OS, GlobalProtect, identity-provider, MFA, endpoint, network, EDR, cloud, SaaS, and SIEM data sources.

·        Test detections in hunt mode before alert-mode deployment to identify legitimate travel, carrier NAT, vendor access, helpdesk access, administrative workflows, security testing, VPN client updates, identity-provider maintenance, SASE routing changes, and incident-response activity.

·        Treat patch validation, exposed gateway review, privileged VPN account review, authentication-policy review, device-posture enforcement review, HIP-policy review, gateway-assignment review, and suspicious session scoping as local incident-response actions when bypass or unauthorized VPN access is suspected.

Variant Resilience Requirements

·        Detection should generalize beyond one GlobalProtect vulnerability, one proof-of-concept pattern, one request sequence, one source IP, one user-agent, one client version, or one portal and gateway interaction pattern.

·        Detection should identify the attacker behavior of obtaining trusted VPN access without a complete and expected authentication lineage even when exploit mechanics, infrastructure, timing, and post-session behavior change.

·        Detection should preserve coverage when attackers shift from direct exploit-driven access to stolen session material, replayed authentication context, abused certificates, authentication-cookie misuse, session-token misuse, device-posture inconsistency, identity-provider mismatch, or compromised low-frequency accounts.

·        Detection should preserve coverage when attackers use residential proxies, mobile carriers, cloud infrastructure, hosting providers, anonymization services, compromised infrastructure, SASE-adjacent routing, or source locations that resemble legitimate remote work.

·        Detection should preserve coverage when post-session behavior changes from internal reconnaissance to identity-service access, privileged application access, data staging, cloud control-plane activity, SaaS administration, developer-platform access, or lateral movement.

·        Detection should preserve coverage when attackers reduce noise by using short VPN sessions, delayed internal access, low-and-slow discovery, role-aware targeting, stolen valid accounts, or infrastructure that overlaps with legitimate business access.

Operational Detection Model

·        Identify GlobalProtect exposure, patch posture, portal and gateway configuration, authentication method, MFA enforcement, SAML integration, certificate requirements, HIP enforcement, split-tunnel behavior, gateway assignment, and logging coverage.

·        Detect abnormal GlobalProtect portal requests, portal authentication events, gateway authentication events, client configuration retrieval, gateway assignment, tunnel establishment, HIP evaluation, authentication-sequence gaps, and session-state transitions.

·        Detect successful VPN session establishment without matching identity-provider, MFA, certificate, SAML, HIP, device posture, conditional-access, authentication-cookie, session-token, or gateway-assignment evidence.

·        Detect portal-to-gateway sequencing gaps where portal request, identity-provider authentication, MFA or conditional-access decision, certificate or posture validation, HIP evaluation, gateway assignment, tunnel establishment, and internal access do not align.

·        Detect VPN session creation from unfamiliar infrastructure, geographies, ASNs, device profiles, client versions, or account contexts when paired with authentication-lineage inconsistency or suspicious post-session behavior.

·        Detect suspicious VPN session use involving internal discovery, identity-service interaction, privileged system access, administrative protocols, sensitive applications, or cloud and SaaS control planes.

·        Correlate VPN-edge, identity-provider, MFA, HIP, endpoint, network, and cloud or SaaS signals before escalating to probable trusted-session compromise.

·        Separate exposed vulnerable infrastructure, suspected bypass attempt, unauthorized VPN session establishment, suspicious trusted-session use, downstream investigative leads, and confirmed downstream compromise into distinct SOC outcomes.

S22 — Primary Detection Signals

Primary Detection Signals

·        GlobalProtect portal authentication events that do not align with expected identity-provider authentication, MFA, conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, device posture, user mapping, or session evidence.

·        GlobalProtect gateway authentication events that do not align with prior portal authentication, expected gateway assignment, GlobalProtect client configuration retrieval, SAML session context, authentication cookie state, session-token state, or tunnel-established events.

·        Tunnel-established events where the expected authentication sequence is absent, incomplete, delayed, or inconsistent across portal request, identity-provider authentication, MFA or conditional-access decision, certificate or device-posture validation, HIP evaluation, gateway assignment, gateway authentication, and internal access.

·        GlobalProtect client configuration retrieval from an unfamiliar source, device, user-agent, client version, operating-system profile, or source network shortly before suspicious gateway authentication or tunnel establishment.

·        Gateway selection or gateway-assignment behavior that does not match the user’s normal region, source geography, remote-access profile, assigned gateway, business unit, device posture, or expected VPN routing pattern.

·        HIP match results, HIP report results, certificate context, endpoint identity, client version, operating-system profile, or device-posture values that are missing, downgraded, newly observed, or inconsistent with the claimed user or endpoint.

·        SAML assertion, identity-provider session, MFA result, authentication cookie, or session-token context that does not reconcile with the GlobalProtect portal event, gateway event, user identity, device identity, source IP, timestamp, or tunnel session.

·        Successful VPN session establishment from unfamiliar infrastructure, including newly observed IPs, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE-adjacent routing, or source networks inconsistent with the user’s access history.

·        Successful VPN session establishment involving privileged, administrative, security, remote-access, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts.

·        VPN-authenticated traffic followed by internal access to identity services, domain controllers, privileged management systems, VPN administration interfaces, firewall management interfaces, jump hosts, sensitive file shares, development environments, backup infrastructure, cloud consoles, SaaS administration portals, or other high-value internal resources.

·        VPN-authenticated traffic followed by internal reconnaissance, credential validation, LDAP or Kerberos activity, SMB enumeration, RDP, SSH, WinRM, database probing, administrative share access, or abnormal authentication attempts across multiple internal systems.

Supporting Detection Signals

·        Repeated portal requests, gateway requests, authentication attempts, client configuration retrieval attempts, or tunnel-establishment attempts from unfamiliar infrastructure before a successful VPN session.

·        Multiple GlobalProtect authentication or session-state transitions that occur in an unusual order, compressed window, delayed sequence, or pattern inconsistent with normal portal-to-gateway behavior.

·        Portal authentication success without expected gateway behavior, gateway authentication success without expected portal behavior, or tunnel establishment without a complete portal-to-identity-to-gateway sequence.

·        GlobalProtect session creation shortly after suspicious HTTP/S interaction with the portal or gateway from scanner-like infrastructure, low-reputation infrastructure, hosting providers, anonymization services, or sources not associated with normal remote access.

·        GlobalProtect client version, operating-system profile, user-agent, or endpoint attributes that are new for the account, inconsistent with historical device use, or inconsistent with expected enterprise-managed endpoint posture.

·        Authentication attempts against multiple accounts from the same source infrastructure followed by successful VPN access for one account.

·        VPN session activity outside normal user access windows, outside known user travel patterns, outside approved vendor support windows, or from source infrastructure not associated with the user, business unit, or third-party access profile.

·        Short-lived VPN sessions followed by delayed internal access, repeated reconnects, unusual tunnel lifetimes, gateway changes, or low-and-slow internal activity inconsistent with the account’s normal usage.

·        Identity-provider, MFA, conditional-access, or device-compliance events showing deny, challenge, risk, failure, bypass, mismatch, or absent evaluation near the time of VPN session establishment.

·        Multiple users or accounts showing similar GlobalProtect anomalies from the same source IP, source ASN, geography, hosting provider, mobile carrier range, SASE egress point, or time window.

Exploit Attempt and Instability Signals

·        Malformed, incomplete, abnormal, or scanner-like requests to GlobalProtect portal or gateway services from unfamiliar infrastructure.

·        Repeated requests to portal, gateway, pre-authentication, client configuration, authentication, gateway-assignment, or tunnel-establishment paths that do not match normal GlobalProtect client behavior.

·        Portal or gateway interaction patterns that generate unusual response codes, repeated failures, abrupt session transitions, authentication-state changes, session resets, policy-evaluation anomalies, or unexpected success after prior malformed activity.

·        GlobalProtect portal or gateway behavior showing abnormal timing between portal request, identity-provider redirection, SAML response, MFA decision, client configuration retrieval, gateway assignment, gateway authentication, and tunnel establishment.

·        Authentication cookie, session-token, SAML assertion, certificate, or HIP evaluation inconsistencies observed during portal-to-gateway transition.

·        Repeated failed authentication, malformed authentication, or unusual session-initiation attempts followed by successful VPN access from the same source, related infrastructure, or adjacent infrastructure.

·        Increased probing of exposed GlobalProtect portals or gateways where affected version posture, patch posture, compensating controls, or logging coverage cannot be confirmed.

·        GlobalProtect system, authentication, gateway, or portal logs showing abnormal errors, rejected states, unexpected session creation, or instability near suspicious authentication-lineage activity.

Outbound Communication Signals

·        VPN-authenticated internal traffic from the newly established session to identity infrastructure, domain controllers, LDAP, Kerberos, SMB, RDP, SSH, WinRM, privileged management systems, internal web applications, databases, or administrative interfaces.

·        VPN-authenticated DNS activity that differs from the user’s normal access pattern, especially discovery-oriented lookups for internal domains, domain controllers, file servers, management systems, cloud connectors, or administrative services.

·        VPN session traffic involving unusual destination diversity, new internal destinations, rare service access, administrative protocol use, or access to sensitive network segments not normally reached by the account.

·        Internal traffic after VPN establishment that shows reconnaissance, authentication attempts, service enumeration, lateral-movement preparation, privileged resource access, or connections to systems outside the user’s normal role.

·        Cloud, SaaS, or identity-provider access occurring shortly after suspicious VPN establishment where the source path, user identity, session timing, device identity, or access pattern can be linked to the VPN session.

·        Endpoint or network telemetry showing the VPN-connected device communicating with external destinations after internal access, especially where the behavior suggests staging, tooling retrieval, command-and-control, credential validation, or data movement.

·        New or unusual outbound connections from internal systems touched by the VPN-authenticated session after suspicious access, especially when the touched system normally does not initiate those connections.

Persistence and Post-Exploitation Signals (Conditional)

·        VPN-authenticated access followed by changes to firewall policy, VPN configuration, GlobalProtect portal settings, gateway settings, authentication profiles, certificate configuration, HIP profiles, administrator accounts, or remote-access policy.

·        Creation, modification, or use of accounts, groups, service accounts, API tokens, application credentials, SSH keys, certificates, or access policies after suspicious VPN session establishment.

·        Identity-provider, directory, or access-control changes after suspicious VPN access, including MFA changes, conditional-access changes, group membership changes, password resets, disabled-control changes, or privileged-role assignment.

·        Endpoint activity on systems reached through the VPN session showing tool staging, script execution, credential dumping, remote administration tooling, persistence creation, scheduled task creation, service creation, registry run-key changes, or unauthorized agent deployment.

·        Suspicious access to backup systems, deployment systems, endpoint-management platforms, identity-management systems, cloud connectors, privileged access management systems, or remote administration infrastructure after VPN session establishment.

·        Recurrent VPN session establishment from similar infrastructure after credential reset, session revocation, firewall rule changes, gateway reassignment, or partial remediation.

·        Reuse of the same account, source infrastructure, certificate context, session artifact, or device identity across repeated suspicious VPN sessions.

Lateral Movement and Expansion Signals (Conditional)

·        VPN-authenticated access followed by LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, or administrative protocol activity against multiple internal systems.

·        VPN session activity followed by authentication attempts across multiple hosts, multiple accounts, multiple services, or multiple privileged resources.

·        Access from the VPN-connected user to domain controllers, identity infrastructure, management servers, jump hosts, privileged access workstations, administrative shares, or remote-management systems that the account does not normally use.

·        Internal host-to-host movement after the initial VPN-authenticated access, especially where the first internal system touched begins communicating with additional systems, identity services, cloud connectors, or administrative services.

·        Use of VPN-authenticated access to reach cloud control planes, SaaS administration portals, developer platforms, source-code systems, CI/CD infrastructure, backup platforms, or sensitive business applications.

·        Downstream identity, SaaS, cloud, or developer-platform anomalies following suspicious VPN establishment, including unusual token use, privileged role access, application consent changes, API activity, repository access, or administrative configuration changes.

·        Lateral movement or downstream expansion should be treated as related only when it is temporally and behaviorally linked to suspicious GlobalProtect session establishment, missing authentication-lineage evidence, trusted-session abuse, credential theft, token abuse, or incident-response validation.

Signal Usage Constraints

·        A vulnerable GlobalProtect version alone is an exposure signal, not proof of exploitation.

·        A suspicious portal or gateway request alone is an exploit-attempt signal, not proof of successful authentication bypass.

·        A failed authentication event alone is not proof of bypass.

·        Missing identity-provider, MFA, SAML, HIP, or device-posture evidence may reflect telemetry delay, ingestion failure, log-retention limits, parser failure, provider outage, or timestamp skew and must not be treated as proof of bypass without supporting evidence.

·        A tunnel-established event alone is not malicious unless authentication-lineage, gateway-sequencing, posture, source, or downstream behavior supports escalation.

·        A new VPN source IP, ASN, geography, device profile, client version, or operating-system profile is not compromise evidence by itself.

·        Gateway assignment changes should be validated against legitimate routing, failover, SASE architecture, disaster-recovery routing, regional gateway selection, load balancing, and expected GlobalProtect configuration behavior.

·        Carrier NAT, mobile networks, residential ISP changes, SASE egress, proxy infrastructure, ZTNA overlays, and third-party access paths can affect source attribution and should be validated before escalation.

·        Internal discovery is not automatically GlobalProtect compromise unless linked to suspicious VPN session establishment, missing authentication-lineage evidence, or unauthorized trusted-session use.

·        Cloud, SaaS, identity, and developer-platform anomalies should remain downstream investigative leads unless linked to suspicious VPN session evidence, trusted-session abuse, credential theft, token theft, or validated post-session activity.

·        Confirmed escalation should require evidence from more than one stage of the chain, such as portal or gateway anomaly followed by tunnel establishment, tunnel establishment without expected identity-provider evidence, VPN session establishment followed by internal reconnaissance, or trusted VPN access followed by privileged identity, cloud, SaaS, or lateral-movement behavior.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Endpoint telemetry should capture GlobalProtect client process activity, client launch behavior, client configuration retrieval, VPN adapter creation, tunnel establishment, reconnect behavior, disconnect behavior, and abnormal client-side session transitions where available.

·        Endpoint telemetry should capture process creation, command line, parent process, grandparent process, user context, process path, process hash, signer metadata, working directory, integrity level, timestamp, network connection context, and device identity where available.

·        Endpoint telemetry should capture GlobalProtect client version, operating-system profile, device identifier, hostname, certificate use, user identity, endpoint posture context, and managed-device state where available.

·        Endpoint telemetry should identify suspicious activity on systems accessed through a suspicious VPN session, including tool staging, script execution, credential-access behavior, remote administration tooling, persistence creation, and abnormal child-process activity.

·        Endpoint telemetry should preserve relationships between VPN session establishment, internal resource access, process execution, network connections, file activity, and user context so defenders can distinguish trusted-session compromise from unrelated administrator, developer, helpdesk, security operations, or incident-response activity.

·        Endpoint telemetry from privileged workstations, jump hosts, management servers, identity systems, backup systems, endpoint-management platforms, and high-value internal systems should be prioritized when those systems are accessed shortly after suspicious VPN session establishment.

Memory and Execution Telemetry

·        Memory and execution telemetry should capture suspicious process injection, credential-access behavior, token access, unusual module loads, unsigned or low-reputation DLL loading, script execution, and execution from user-writable or administrative staging paths after suspicious VPN-authenticated access.

·        EDR telemetry should identify suspicious execution on internal systems reached through the VPN session, especially where activity involves credential dumping, remote shell creation, script interpreters, administrative tooling, lateral-movement utilities, or living-off-the-land binaries.

·        Execution telemetry should capture abnormal use of PowerShell, command shell, WMI, WinRM, PsExec-like tools, SSH clients, RDP clients, LDAP tools, Kerberos tooling, database clients, cloud CLIs, SaaS administration tools, or other utilities inconsistent with the user’s normal role.

·        Memory telemetry should be treated as supporting evidence unless paired with suspicious VPN session establishment, internal access, process execution, credential access, persistence, outbound communication, or incident-response validation.

·        Execution telemetry should retain enough process lineage to determine whether suspicious internal activity occurred after the VPN session and whether it originated from the account, device, source path, or session under investigation.

Crash and Fault Telemetry

·        PAN-OS and GlobalProtect telemetry should capture portal errors, gateway errors, authentication failures, session-state errors, tunnel-establishment failures, gateway-assignment failures, HIP evaluation errors, client configuration retrieval failures, and unexpected session transitions.

·        GlobalProtect portal and gateway logs should preserve failed, malformed, incomplete, rejected, or abnormal authentication and session-initiation activity against exposed portal and gateway services.

·        System telemetry should capture abnormal service behavior, process instability, unexpected restarts, authentication-service errors, policy-evaluation errors, SAML handling errors, certificate validation errors, gateway instability, and portal instability near suspicious authentication-lineage activity.

·        Identity-provider and MFA telemetry should capture failed, denied, challenged, expired, mismatched, incomplete, bypassed, or policy-inconsistent authentication and access-decision events near suspicious VPN session establishment.

·        Crash and fault telemetry should be used as exploit-attempt or instability evidence, not as standalone proof of successful authentication bypass, unauthorized VPN session establishment, or trusted VPN session compromise.

File and Persistence Telemetry

·        File telemetry should capture suspicious tool staging, archive extraction, script creation, executable writes, DLL writes, credential-dump output, configuration exports, and unusual file access on systems reached after suspicious VPN session establishment.

·        Persistence telemetry should capture scheduled tasks, service creation, registry run-key changes, startup-folder writes, unauthorized agent deployment, SSH key placement, certificate changes, token storage, and recurring execution after suspicious VPN-authenticated access.

·        Firewall and remote-access configuration telemetry should capture changes to GlobalProtect portal settings, gateway settings, authentication profiles, HIP profiles, certificate configuration, administrator accounts, remote-access policy, split-tunnel configuration, routing behavior, and security policy.

·        Identity and access-control telemetry should capture account creation, account re-enablement, group membership changes, privileged role assignment, MFA changes, conditional-access changes, password resets, disabled-control changes, service-account changes, API token creation, application credential changes, and certificate enrollment after suspicious VPN access.

·        File and persistence telemetry should distinguish legitimate administrator, helpdesk, engineering, IT operations, software deployment, vulnerability management, and incident-response activity from unauthorized post-session modification.

Network and Outbound Communication Telemetry

·        Network telemetry should capture GlobalProtect portal requests, gateway requests, authentication events, client configuration retrieval, gateway assignment, gateway authentication, tunnel-established events, VPN session metadata, and VPN-authenticated internal traffic where available.

·        Network telemetry should capture source IP, source ASN, source geography, user-agent, client version, device identity, username, portal name, gateway name, gateway region, session identifier, tunnel identifier, source zone, destination zone, destination asset, application, protocol, port, bytes, duration, and timestamp where available.

·        Internal network telemetry should capture VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S, file-share, jump-host, privileged-management, cloud-connector, and administrative-protocol traffic.

·        DNS, proxy, firewall, NDR, secure web gateway, internal segmentation, and endpoint network telemetry should preserve enough session context to associate internal access with the VPN-connected user, device, source IP, gateway, and tunnel session.

·        Outbound communication telemetry should capture suspicious external communication from VPN-connected endpoints or internal systems touched by the VPN session, especially where activity suggests tooling retrieval, staging, command-and-control, credential validation, data movement, or post-access expansion.

·        Network telemetry should account for split-tunnel configurations, SASE routing, ZTNA overlays, proxy infrastructure, NAT, carrier-grade NAT, mobile networks, and third-party access paths that may affect visibility, routing, and attribution.

·        Network telemetry should retain enough history to identify delayed internal reconnaissance, low-and-slow access, repeated short VPN sessions, recurring source infrastructure, and repeated account use across related sessions.

Web and Application Telemetry (Conditional Availability)

·        GlobalProtect portal and gateway application telemetry should capture portal authentication, gateway authentication, client configuration retrieval, gateway assignment, HIP match results, HIP report results, tunnel establishment, session state, disconnects, reconnects, and policy-evaluation outcomes where available.

·        PAN-OS administrative telemetry should capture configuration changes, authentication profile changes, GlobalProtect portal changes, gateway changes, HIP profile changes, certificate changes, administrator logins, commit events, policy changes, and remote-access control changes.

·        Identity-provider application telemetry should capture SAML assertion context, OIDC context, MFA result, conditional-access result, device-compliance result, risk score, authentication method, session identifier, token issuance, source IP, user-agent, device identifier, and timestamp.

·        SaaS, cloud, and developer-platform telemetry should be collected for downstream investigation when suspicious VPN session establishment is followed by privileged cloud, SaaS, source-code, CI/CD, administrative, or sensitive application access.

·        Application telemetry from internal systems should capture authentication attempts, authorization failures, privileged actions, administrative changes, data access, unusual API activity, and abnormal user behavior after suspicious VPN-authenticated access.

·        Web and application telemetry should be used to validate post-session behavior and should not be used to attribute activity to GlobalProtect compromise unless linked to suspicious VPN session evidence.

Telemetry Availability Requirements

·        Confirm whether GlobalProtect portal logs, gateway logs, authentication logs, HIP logs, gateway-assignment logs, tunnel-established events, client configuration retrieval events, session identifiers, authentication cookie context, and session-token context are available and retained.

·        Confirm whether PAN-OS traffic, threat, system, authentication, configuration, management, and administrative logs are centrally collected and searchable.

·        Confirm whether identity-provider, MFA, conditional-access, SAML, OIDC, directory, device-compliance, and risk-based access logs can be joined to GlobalProtect events using reliable user, device, source IP, session, assertion, timestamp, or gateway identifiers.

·        Confirm whether endpoint telemetry can identify GlobalProtect client activity, device identity, certificate use, VPN adapter creation, process execution, network connections, file activity, and suspicious post-connection behavior.

·        Confirm whether internal network telemetry can associate VPN-authenticated traffic with users, devices, gateways, tunnel sessions, source IPs, and destination assets.

·        Confirm whether split-tunnel configuration, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, mobile networks, and third-party access paths change what internal, cloud, SaaS, DNS, or proxy activity is visible.

·        Confirm whether EDR, NDR, DNS, proxy, firewall, secure web gateway, identity, SaaS, cloud, and SIEM telemetry retain enough history to support delayed-access and low-and-slow investigations.

·        Confirm whether vulnerability, patch, exposure, asset inventory, gateway inventory, privileged account inventory, third-party access inventory, certificate inventory, and change-control records are available for enrichment.

Telemetry Limitations and Gaps

·        Some environments may not retain GlobalProtect portal, gateway, HIP, gateway-assignment, client configuration retrieval, tunnel-established, authentication cookie, or session-token telemetry with enough detail for full authentication-lineage reconstruction.

·        Missing identity-provider, MFA, SAML, HIP, device-posture, or conditional-access evidence may reflect logging gaps, ingestion delays, retention limits, parser issues, provider outages, timestamp skew, or integration limitations rather than confirmed bypass.

·        Split-tunnel configurations may prevent defenders from seeing some internal, cloud, SaaS, DNS, proxy, or endpoint network activity through centralized network controls.

·        SASE routing, ZTNA overlays, proxy infrastructure, NAT, carrier-grade NAT, mobile networks, and third-party access paths may reduce confidence in source attribution, geography analysis, ASN analysis, and device-to-session mapping.

·        VPN session identifiers, usernames, device identifiers, SAML identifiers, source IPs, gateway names, and timestamps may not align consistently across PAN-OS, GlobalProtect, identity-provider, MFA, endpoint, network, SaaS, cloud, and SIEM systems.

·        Internal discovery, cloud anomalies, SaaS anomalies, identity anomalies, and developer-platform anomalies may appear downstream of suspicious access but should remain investigative leads unless linked to suspicious VPN session evidence.

·        Legitimate travel, mobile carrier changes, regional gateway failover, disaster-recovery routing, VPN client upgrades, third-party support, helpdesk activity, administrator workflows, security testing, and incident-response activity can resemble suspicious VPN behavior without indicating compromise.

·        Static indicators, source IPs, user-agents, client versions, request paths, exploit strings, and CVE-specific patterns may rotate or be absent and should not be treated as the primary telemetry foundation.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Detection can identify GlobalProtect authentication-lineage failure by correlating portal requests, portal authentication, identity-provider authentication, MFA or conditional-access decisions, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, tunnel establishment, and internal access.

·        Detection can identify unauthorized or suspicious VPN session establishment when tunnel-established events occur without expected identity-provider, MFA, SAML, certificate, HIP, device-posture, authentication-cookie, session-token, or gateway-assignment evidence.

·        Detection can identify portal-to-gateway sequencing gaps when client configuration retrieval, gateway assignment, gateway authentication, and tunnel establishment do not align with normal GlobalProtect session flow.

·        Detection can identify suspicious GlobalProtect access from unfamiliar source infrastructure, including newly observed IPs, rare ASNs, unusual geographies, hosting providers, anonymization services, mobile carrier networks, residential proxy infrastructure, SASE egress points, or source networks inconsistent with the user’s access history.

·        Detection can identify higher-risk trusted-session abuse when suspicious VPN establishment involves privileged, administrative, security, remote-access, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts.

·        Detection can identify suspicious posture and device mismatches when HIP match results, HIP report results, certificate context, endpoint identity, GlobalProtect client version, operating-system profile, managed-device state, or posture values are missing, downgraded, newly observed, or inconsistent with the claimed user.

·        Detection can identify post-session internal access risk when VPN-authenticated traffic reaches identity services, domain controllers, privileged management systems, VPN administration interfaces, firewall management interfaces, jump hosts, sensitive file shares, backup infrastructure, development environments, cloud consoles, SaaS administration portals, or other high-value resources.

·        Detection can identify downstream expansion when suspicious VPN session establishment is followed by LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database access, administrative share access, credential validation, internal reconnaissance, or lateral-movement preparation.

·        Detection can improve confidence by correlating multiple stages of the chain, including portal anomaly to gateway anomaly, gateway anomaly to tunnel establishment, tunnel establishment to missing identity evidence, and trusted VPN access to internal reconnaissance or privileged resource access.

High-Value Detection Opportunities

·        Tunnel-established events without matching identity-provider authentication, MFA decision, SAML assertion context, certificate validation, HIP evaluation, or device-posture evidence.

·        Portal-to-gateway sequencing gaps involving client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, or policy evaluation.

·        GlobalProtect gateway authentication success without expected portal authentication, identity-provider evidence, or prior client configuration retrieval.

·        Authentication cookie, session-token, SAML assertion, certificate, or HIP result inconsistencies during portal-to-gateway transition.

·        VPN session establishment from unfamiliar infrastructure followed by internal reconnaissance, identity-service access, administrative protocol use, or sensitive application access.

·        Successful VPN access involving privileged, administrative, third-party, service-adjacent, dormant, stale, or low-frequency accounts.

·        VPN-authenticated access to domain controllers, identity infrastructure, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, or endpoint-management platforms.

·        VPN-authenticated traffic followed by cloud, SaaS, developer-platform, source-code, or CI/CD access that can be linked to the suspicious VPN session.

·        Multiple users or accounts showing similar GlobalProtect anomalies from the same source infrastructure, geography, ASN, hosting provider, mobile carrier range, SASE egress point, or time window.

Correlation Opportunities

·        Correlate GlobalProtect portal requests with portal authentication, identity-provider authentication, MFA outcome, conditional-access result, SAML assertion context, certificate validation, HIP evaluation, and client configuration retrieval.

·        Correlate GlobalProtect client configuration retrieval with gateway assignment, gateway authentication, tunnel establishment, source IP, user identity, device identity, client version, operating-system profile, and HIP result.

·        Correlate tunnel-established events with identity-provider, MFA, SAML, OIDC, conditional-access, certificate, HIP, device-compliance, authentication-cookie, and session-token evidence.

·        Correlate source infrastructure novelty with account sensitivity, prior user access history, device history, gateway selection, time window, travel patterns, vendor access profile, SASE routing, and third-party access context.

·        Correlate suspicious VPN session establishment with internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, and administrative-protocol traffic.

·        Correlate VPN-authenticated internal access with endpoint telemetry from systems touched by the session, including process execution, file activity, credential-access behavior, persistence, remote administration tooling, and outbound communication.

·        Correlate suspicious VPN access with cloud, SaaS, identity, developer-platform, CI/CD, source-code, and privileged application telemetry only when session timing, user identity, device identity, source path, or incident-response evidence supports linkage.

·        Correlate repeated short VPN sessions, reconnect behavior, gateway changes, delayed internal access, and recurring source infrastructure across multiple users or accounts.

·        Correlate GlobalProtect anomalies with patch posture, exposed gateway inventory, affected PAN-OS version context, compensating controls, change-control records, maintenance windows, and incident-response records.

Detection Gaps

·        Detection may miss authentication-lineage failure when GlobalProtect portal logs, gateway logs, HIP logs, gateway-assignment logs, tunnel-established events, client configuration retrieval events, authentication-cookie context, or session-token context are not retained.

·        Detection may miss bypass activity when identity-provider, MFA, SAML, OIDC, conditional-access, certificate, device-compliance, or risk-based access logs cannot be joined reliably to GlobalProtect events.

·        Detection may miss portal-to-gateway sequencing gaps when session identifiers, usernames, device identifiers, source IPs, SAML identifiers, gateway names, and timestamps do not align across PAN-OS, GlobalProtect, identity-provider, MFA, endpoint, network, SaaS, cloud, and SIEM systems.

·        Detection may miss suspicious internal access when split-tunnel configuration, SASE routing, ZTNA overlays, proxy paths, endpoint network controls, or incomplete internal network telemetry limit visibility.

·        Detection may miss source-infrastructure risk when NAT, carrier-grade NAT, mobile networks, SASE egress, proxy infrastructure, third-party access paths, and residential ISP changes obscure attribution.

·        Detection may miss low-and-slow abuse when VPN sessions are short, internal access is delayed, reconnaissance is minimal, or activity blends with the user’s normal access profile.

·        Detection may miss post-session compromise when suspicious behavior occurs on unmanaged devices, contractor systems, personal devices, third-party-managed endpoints, or systems without EDR coverage.

·        Detection may miss downstream cloud, SaaS, identity, or developer-platform abuse when activity appears to originate from valid credentials, valid tokens, or normal application sessions and cannot be tied back to suspicious VPN establishment.

·        Detection may miss exploitation when attackers use infrastructure, timing, user agents, client versions, gateway selection, or post-access behavior that overlaps with legitimate remote-work or vendor-support patterns.

False Positive and Noise Considerations

·        Legitimate travel, mobile carrier changes, residential ISP changes, regional gateway failover, disaster-recovery routing, SASE routing, VPN client upgrades, and remote-work changes can produce unfamiliar source or gateway patterns.

·        Approved vendor support, third-party access, contractor access, helpdesk activity, administrator workflows, vulnerability management, security testing, and incident-response activity can resemble suspicious VPN session use.

·        Identity-provider outages, MFA-provider issues, conditional-access changes, parser failures, ingestion delays, timestamp skew, log-retention limits, and SAML logging differences can create apparent authentication-lineage gaps.

·        Gateway assignment changes may reflect legitimate load balancing, failover, regional routing, gateway maintenance, policy changes, SASE architecture, or expected GlobalProtect configuration behavior.

·        HIP result changes, posture changes, certificate changes, client version changes, and operating-system profile changes may reflect legitimate endpoint updates, device replacement, patching, re-enrollment, or policy changes.

·        Internal discovery, administrative protocol use, cloud access, SaaS access, developer-platform access, and privileged application access may be legitimate for administrators, engineers, security staff, helpdesk users, or incident-response personnel.

·        Cloud, SaaS, identity, and developer-platform anomalies should not be promoted as GlobalProtect-linked findings unless session timing, identity, device, source path, or incident-response evidence supports the relationship.

·        Endpoint detections on systems touched after VPN access should be validated against normal administrator, software deployment, vulnerability management, EDR response, and incident-response workflows.

Coverage Improvement Opportunities

·        Improve GlobalProtect logging coverage for portal authentication, gateway authentication, client configuration retrieval, gateway assignment, tunnel establishment, HIP match results, HIP report results, session state, reconnects, disconnects, authentication cookies, and session-token context where available.

·        Improve identity-provider and MFA correlation by retaining SAML assertion context, OIDC context, MFA outcome, conditional-access decision, device-compliance result, risk score, token issuance, source IP, user-agent, device identifier, and timestamp.

·        Improve PAN-OS and SIEM normalization so VPN session identifiers, usernames, device identifiers, source IPs, gateway names, tunnel identifiers, SAML identifiers, timestamps, and policy outcomes can be joined reliably.

·        Improve internal network visibility for VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, and administrative-protocol traffic.

·        Improve endpoint visibility on privileged workstations, jump hosts, management servers, identity infrastructure, backup systems, endpoint-management platforms, and high-value internal systems accessed through VPN sessions.

·        Improve source-attribution enrichment for ASNs, geographies, hosting providers, mobile carrier networks, residential proxy infrastructure, SASE egress points, NAT, carrier-grade NAT, VPN egress, third-party access paths, and first-seen source infrastructure.

·        Improve baselines for normal GlobalProtect user behavior, privileged-user VPN activity, third-party access, client versions, gateway assignments, posture results, HIP results, certificate usage, source geography, access windows, and internal resource access.

·        Improve correlation between suspicious VPN session establishment and downstream identity, cloud, SaaS, developer-platform, CI/CD, source-code, and privileged application activity.

·        Improve change-control integration for GlobalProtect configuration updates, authentication-policy changes, MFA changes, conditional-access updates, HIP policy changes, gateway maintenance, SASE routing changes, vendor support, and incident-response activity.

Detection Confidence Model

·        Low confidence should be assigned to isolated exposure or weak anomaly signals, including vulnerable GlobalProtect version posture, unfamiliar source IP, new geography, new ASN, failed authentication, or one-off portal probing without session establishment.

·        Low confidence should be assigned to isolated missing identity-provider, MFA, SAML, HIP, or posture evidence until logging gaps, ingestion delays, provider outages, timestamp skew, and parser issues are ruled out.

·        Medium confidence should be assigned to suspicious portal or gateway activity paired with source novelty, abnormal session-state transitions, malformed request behavior, authentication errors, or unknown patch posture.

·        Medium confidence should be assigned to tunnel establishment with partial authentication-lineage inconsistency, unfamiliar source infrastructure, unusual gateway assignment, or posture mismatch when downstream behavior is limited.

·        High confidence should be assigned to tunnel establishment without expected identity-provider, MFA, SAML, certificate, HIP, posture, authentication-cookie, session-token, or gateway-assignment evidence when logging completeness has been validated.

·        High confidence should be assigned to suspicious VPN session establishment followed by internal reconnaissance, identity-service access, privileged resource access, administrative protocol use, abnormal authentication attempts, or access to systems outside the user’s normal role.

·        Confirmed trusted-session compromise confidence should require multiple linked stages, such as portal or gateway anomaly followed by tunnel establishment, tunnel establishment with missing authentication lineage, or suspicious VPN access followed by downstream internal or control-plane activity.

·        Confirmed downstream compromise confidence should require endpoint, identity, cloud, SaaS, file, persistence, command-and-control, credential-access, token-access, or incident-response evidence linked to the suspicious VPN session.

Operational Gaps Requiring Validation

·        Confirm whether the organization operates exposed GlobalProtect portals or gateways affected by the current proof point or by related authentication-lineage bypass risk.

·        Confirm whether GlobalProtect portal, gateway, HIP, gateway-assignment, client configuration retrieval, tunnel-established, authentication-cookie, and session-token telemetry are available and retained.

·        Confirm whether PAN-OS traffic, threat, system, authentication, configuration, management, and administrative logs are centrally collected and searchable.

·        Confirm whether identity-provider, MFA, SAML, OIDC, conditional-access, certificate, device-compliance, and risk-based access logs can be joined reliably to GlobalProtect events.

·        Confirm whether split-tunnel configuration, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, mobile networks, and third-party access paths affect visibility or source attribution.

·        Confirm whether endpoint telemetry can identify GlobalProtect client behavior, process execution, network connections, file activity, suspicious post-connection behavior, and activity on systems reached through VPN access.

·        Confirm whether internal network telemetry can link VPN-authenticated traffic to users, devices, gateways, tunnel sessions, source IPs, and destination assets.

·        Confirm whether cloud, SaaS, identity, developer-platform, CI/CD, source-code, and privileged application logs are available for downstream investigation after suspicious VPN session establishment.

·        Confirm whether baselines exist for normal VPN user behavior, privileged-user VPN behavior, third-party access, posture results, gateway assignment, source infrastructure, and internal resource access.

·        Confirm whether change-control records, incident-response records, vendor-support records, maintenance windows, authentication-policy changes, and GlobalProtect configuration changes are available for triage.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics has three rules for this EXP report.

·        NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior associated with GlobalProtect authentication-lineage failure, portal-to-gateway sequencing gaps, trusted VPN session establishment, VPN-authenticated internal access, identity-service interaction, privileged protocol use, and downstream expansion.

·        NDR / Network Behavioral Analytics is strongest where network-flow telemetry, VPN session telemetry, PAN-OS telemetry, GlobalProtect portal logs, GlobalProtect gateway logs, DNS telemetry, proxy telemetry, secure web gateway logs, identity-provider context, MFA context, HIP context, endpoint enrichment, source enrichment, asset inventory, gateway inventory, privileged-account inventory, and SIEM correlation can be combined.

·        NDR / Network Behavioral Analytics can identify suspicious sequencing between portal interaction, gateway interaction, tunnel establishment, source infrastructure novelty, VPN-authenticated internal access, identity-service access, administrative protocol activity, and downstream cloud, SaaS, or developer-platform access where correlated telemetry exists.

·        NDR / Network Behavioral Analytics is not a standalone source for confirming successful authentication bypass, GlobalProtect exploitation, identity-provider failure, MFA bypass, HIP bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution because network telemetry may not fully observe authentication state, SAML assertion context, MFA decisions, endpoint posture results, session-token state, authentication-cookie state, or endpoint process execution.

·        NDR / Network Behavioral Analytics rules must be correlated with PAN-OS logs, GlobalProtect portal logs, GlobalProtect gateway logs, HIP logs, gateway-assignment logs, identity-provider logs, MFA logs, endpoint telemetry, EDR telemetry, DNS logs, proxy logs, secure web gateway logs, cloud logs, SaaS logs, asset inventory, vulnerability context, change-control records, and incident-response evidence before classifying activity as probable compromise.

·        NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for suspicious VPN session establishment, trusted-session abuse scoping, internal reconnaissance detection, privileged resource access triage, and downstream expansion investigation, not direct CVE confirmation or standalone compromise confirmation.

·        NDR / Network Behavioral Analytics rules should not generate high-confidence alerting from a vulnerable GlobalProtect version alone, unfamiliar source IP alone, unusual ASN alone, geography anomaly alone, gateway change alone, tunnel establishment alone, internal DNS activity alone, cloud access alone, SaaS access alone, or administrative protocol activity alone.

Rule

GlobalProtect Tunnel Establishment With Authentication-Lineage or Portal-to-Gateway Sequencing Anomaly

Rule Format

NDR behavioral VPN authentication-lineage correlation rule suitable for network-flow telemetry, VPN session telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, PAN-OS telemetry, GlobalProtect portal logs, GlobalProtect gateway logs, gateway-assignment context, HIP context, identity-provider enrichment, MFA enrichment, source enrichment, asset inventory, gateway inventory, privileged-account enrichment, and SIEM correlation after GlobalProtect field validation, portal-to-gateway sequence validation, session-identifier validation, source-context validation, timing-window tuning, telemetry-completeness validation, and environment-specific allowlisting.

Detection Purpose

·        Detect GlobalProtect tunnel-established behavior where the expected portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, or client configuration retrieval evidence is absent, incomplete, delayed, mismatched, or inconsistent.

·        Identify network-visible trusted VPN session establishment that may indicate authentication-lineage failure, portal-to-gateway sequencing failure, unauthorized VPN session creation, or trusted remote-access session compromise.

·        Prioritize activity involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts.

·        Support early escalation when tunnel establishment occurs from unfamiliar infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, mobile carrier networks, residential proxy infrastructure, SASE egress points, or source networks inconsistent with the user’s access history.

·        Preserve separation between suspicious VPN establishment and confirmed compromise by requiring supporting identity, MFA, HIP, endpoint, internal network, cloud, SaaS, or incident-response evidence before classifying the activity as probable compromise.

·        This rule does not prove successful authentication bypass, CVE-2026-0257 exploitation, identity-provider bypass, MFA bypass, endpoint compromise, credential theft, token theft, cloud compromise, or actor attribution without supporting GlobalProtect, identity, endpoint, cloud, SaaS, or incident-response evidence.

Detection Logic

·        Identify GlobalProtect tunnel-established events or VPN session establishment events associated with internet-facing portals, gateways, or known remote-access infrastructure.

·        Correlate tunnel establishment with expected precursor events, including portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, and gateway authentication.

·        Prioritize tunnel establishment where expected precursor events are absent, incomplete, delayed, mismatched, or inconsistent after local telemetry completeness, ingestion delay, timestamp alignment, and join reliability have been validated.

·        Prioritize cases where portal authentication exists without expected gateway sequencing, gateway authentication exists without expected portal sequencing, tunnel establishment occurs without expected client configuration retrieval, or gateway assignment does not align with user, source, device, or policy context.

·        Prioritize mismatches involving username, user principal name, device identifier, source IP, session identifier, SAML identifier, tunnel identifier, gateway name, portal name, timestamp, client version, operating-system profile, HIP result, certificate context, authentication-cookie context, or session-token context.

·        Increase confidence when the account is privileged, administrative, security-related, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, rarely used for VPN, or associated with sensitive access.

·        Increase confidence when the source infrastructure is newly observed, rare for the user, rare for the tenant, associated with hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, unusual geographies, or ASNs not normally associated with the account.

·        Increase confidence when tunnel establishment is followed by internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, or administrative-protocol traffic.

·        Reduce severity when behavior aligns with approved travel, mobile carrier use, regional gateway failover, SASE routing, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, approved vendor access, helpdesk activity, security testing, incident response, or documented change-control activity.

·        Do not classify missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence as bypass until telemetry delay, ingestion gaps, provider outage, parser failure, retention limits, timestamp skew, and local join failure have been reviewed.

·        Do not treat tunnel establishment, source novelty, gateway change, vulnerable version posture, or missing telemetry as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        VPN session telemetry.

·        PAN-OS traffic logs.

·        PAN-OS system logs.

·        PAN-OS authentication logs.

·        PAN-OS configuration logs where available.

·        GlobalProtect portal logs.

·        GlobalProtect gateway logs.

·        GlobalProtect authentication events.

·        GlobalProtect client configuration retrieval events where available.

·        GlobalProtect gateway-assignment events where available.

·        GlobalProtect tunnel-established events.

·        GlobalProtect session-state events.

·        GlobalProtect HIP match results where available.

·        GlobalProtect HIP report results where available.

·        Authentication-cookie context where available.

·        Session-token context where available.

·        Identity-provider logs.

·        SAML assertion context.

·        MFA logs.

·        Conditional-access logs where available.

·        Certificate validation context where available.

·        Device-compliance or posture context where available.

·        DNS logs where available.

·        Proxy logs where available.

·        Secure web gateway logs where available.

·        Endpoint telemetry where available.

·        EDR telemetry where available.

·        Source IP, source ASN, source geography, source reputation, network type, hosting provider, first-seen timestamp, and source history where available.

·        Username, user principal name, account type, privilege level, business unit, device identity, endpoint identity, client version, operating-system profile, portal name, gateway name, gateway region, session identifier, tunnel identifier, and timestamp where available.

·        Asset inventory.

·        Gateway inventory.

·        VPN user inventory.

·        Privileged account inventory.

·        Third-party access inventory.

·        Certificate inventory where available.

·        Approved remote-access source baselines.

·        Approved vendor access records.

·        Approved travel records where available.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build GlobalProtect asset groups covering internet-facing portals, gateways, VPN edge interfaces, gateway regions, gateway clusters, firewall appliances, remote-access infrastructure, and known GlobalProtect management boundaries.

·        Build GlobalProtect event groups for portal request, portal authentication, identity-provider authentication, MFA decision, SAML assertion, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, session state, reconnect, disconnect, and policy evaluation.

·        Build authentication-lineage sequence logic that evaluates whether expected precursor events occur before tunnel establishment within locally validated timing windows.

·        Build mismatch groups for username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, authentication cookie, session token, gateway name, portal name, client version, operating-system profile, HIP result, certificate context, and timestamp.

·        Build source-risk groups for newly observed sources, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, proxy infrastructure, low-reputation sources, and sources inconsistent with normal user access history.

·        Build account-risk groups for privileged users, administrators, security staff, remote-access administrators, third-party accounts, contractor accounts, service-adjacent accounts, dormant accounts, stale accounts, recently re-enabled accounts, low-frequency VPN users, and users with access to sensitive systems.

·        Build internal follow-on groups for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, and administrative-protocol activity after tunnel establishment.

·        Validate whether NDR, PAN-OS, GlobalProtect, identity-provider, MFA, HIP, endpoint, DNS, proxy, secure web gateway, EDR, cloud, SaaS, and SIEM telemetry can reliably join on user, device, source IP, session identifier, tunnel identifier, gateway, portal, timestamp, and account context.

·        Use short correlation windows for expected portal-to-gateway authentication sequencing and tunnel establishment.

·        Use moderate correlation windows for delayed identity-provider evidence, delayed MFA evidence, HIP log delay, gateway-assignment lag, and session-state reconciliation.

·        Use longer correlation windows for delayed internal access, repeated short VPN sessions, recurring source infrastructure, or low-and-slow post-session activity.

·        Add severity weighting for privileged account use, missing authentication-lineage evidence after telemetry completeness validation, gateway-sequencing anomalies, suspicious source infrastructure, vulnerable or unknown patch posture, unfamiliar device context, and internal follow-on activity.

·        Treat source novelty, gateway changes, missing telemetry, HIP mismatch, or tunnel establishment as confidence amplifiers, not standalone compromise criteria.

·        Use change-control records, approved vendor records, travel records, SASE routing changes, gateway maintenance records, identity-provider maintenance records, VPN client upgrade records, helpdesk records, security-testing records, and incident-response records as triage evidence.

·        Validate all environment variables, field mappings, source groups, account groups, GlobalProtect event groups, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until field availability, correlation reliability, telemetry completeness, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to durable authentication-lineage and portal-to-gateway sequencing gaps rather than static CVE strings, known exploit strings, known source IPs, fixed request paths, user-agent values, or payload indicators.

·        The rule remains useful if an adversary changes source infrastructure, timing, client version, user-agent, portal interaction pattern, gateway interaction pattern, authentication artifact usage, or post-session activity.

·        The score is supported by the durability of tunnel establishment without expected precursor evidence, gateway sequencing anomalies, identity-provider mismatch, MFA mismatch, HIP mismatch, session-state inconsistency, source novelty, and internal follow-on behavior.

·        The score is constrained by missing GlobalProtect logs, incomplete HIP logs, identity-provider logging gaps, MFA telemetry gaps, split-tunnel visibility limits, timestamp skew, NAT, carrier-grade NAT, SASE routing, and inconsistent session identifiers.

·        The rule is durable as a trusted-session establishment detector but should not be treated as standalone proof of authentication bypass, exploit success, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on GlobalProtect portal logs, gateway logs, tunnel-established events, HIP results, gateway-assignment context, identity-provider logs, MFA logs, reliable session identifiers, source enrichment, account enrichment, and SIEM join quality.

·        Operational confidence is reduced where identity-provider evidence is delayed, MFA logs are incomplete, HIP events are missing, authentication cookies are unavailable, session-token context is unavailable, or tunnel events cannot be reliably joined to portal and gateway events.

·        Operational confidence is reduced where split-tunnel routing, SASE egress, carrier-grade NAT, mobile networks, regional gateway failover, third-party access, or VPN client upgrades create legitimate source or sequencing changes.

·        Full-telemetry confidence improves when tunnel-established events are enriched with PAN-OS logs, GlobalProtect portal and gateway logs, HIP logs, identity-provider logs, MFA logs, endpoint telemetry, DNS logs, internal network telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation or actor attribution.

Limitations

·        This rule detects suspicious GlobalProtect authentication-lineage or portal-to-gateway sequencing behavior, not confirmed exploitation by itself.

·        NDR may not observe identity-provider session state, MFA decision details, SAML assertion contents, authentication cookie contents, session-token contents, HIP report contents, or endpoint posture results without enrichment.

·        Missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence may reflect telemetry delay, ingestion failure, retention limits, parser failure, provider outage, or timestamp skew rather than successful bypass.

·        Legitimate travel, mobile carrier use, SASE routing, regional gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, and incident response can create similar patterns.

·        The rule may miss bypass activity where attackers produce apparently complete authentication-lineage artifacts, use valid credentials, abuse legitimate session material, or operate within normal user source and device patterns.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR GlobalProtect authentication-lineage and portal-to-gateway sequencing correlation query pattern requiring platform syntax validation, GlobalProtect event validation, portal-to-gateway sequence validation, identity-provider join validation, MFA join validation, HIP join validation, source enrichment validation, account enrichment validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS GlobalProtectTunnelEstablished

WHERE GlobalProtectTunnelEstablished.EventType IN ANY (
"GlobalProtect Tunnel Established",
"VPN Session Established",
"Gateway Tunnel Established",
"Remote Access Session Established"
)

AND GlobalProtectTunnelEstablished.DestinationAsset IN ASSET_GROUP (
"GlobalProtect Portals",
"GlobalProtect Gateways",
"Internet Facing VPN Gateways",
"PAN-OS Remote Access Infrastructure",
"GlobalProtect Gateway Clusters"
)

AND GlobalProtectTunnelEstablished.User IN ASSET_GROUP (
"VPN Users",
"Privileged VPN Users",
"Administrative Users",
"Security Users",
"Third Party VPN Users",
"Contractor VPN Users",
"Low Frequency VPN Users"
)

AND (
GlobalProtectTunnelEstablished.SourceContext IN ANY (
"newly_observed_source",
"rare_asn",
"unusual_geography",
"hosting_provider_source",
"anonymization_service",
"residential_proxy_infrastructure",
"mobile_carrier_network",
"sase_egress_source",
"source_not_in_user_baseline"
)

OR GlobalProtectTunnelEstablished.AccountContext IN ANY (
"privileged_account",
"administrative_account",
"security_account",
"third_party_account",
"contractor_account",
"service_adjacent_account",
"dormant_account",
"stale_account",
"recently_reenabled_account",
"low_frequency_vpn_user"
)

OR GlobalProtectTunnelEstablished.SessionPattern IN ANY (
"unexpected_gateway_assignment",
"missing_portal_precursor",
"missing_gateway_precursor",
"missing_client_config_retrieval",
"portal_to_gateway_sequence_gap",
"tunnel_without_expected_identity_evidence",
"session_identifier_mismatch",
"authentication_cookie_inconsistency",
"session_token_inconsistency",
"hip_result_inconsistency"
)
)

AND TELEMETRY_COMPLETENESS_VALIDATED FOR (
"GlobalProtect Portal Logs",
"GlobalProtect Gateway Logs",
"Identity Provider Logs",
"MFA Logs",
"HIP Logs",
"Gateway Assignment Logs",
"Tunnel Established Events"
)

AND EVENT_NOT_FOUND WITHIN ENV_GP_PORTAL_TO_TUNNEL_WINDOW (
GlobalProtectEvent AS ExpectedPortalOrIdentityEvidence
WHERE ExpectedPortalOrIdentityEvidence.User IN SAME_USER(GlobalProtectTunnelEstablished.User)
AND ExpectedPortalOrIdentityEvidence.SourceIP IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(GlobalProtectTunnelEstablished.SourceIP)
AND ExpectedPortalOrIdentityEvidence.EventType IN ANY (
"Portal Authentication Success",
"Identity Provider Authentication Success",
"MFA Success",
"Conditional Access Success",
"SAML Assertion Validated",
"Certificate Validated",
"HIP Evaluation Completed",
"Client Configuration Retrieved",
"Gateway Assigned",
"Gateway Authentication Success"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GP_INTERNAL_FOLLOWON_WINDOW (
NetworkEvent AS VpnInternalFollowOn
WHERE VpnInternalFollowOn.User IN SAME_USER(GlobalProtectTunnelEstablished.User)
AND VpnInternalFollowOn.SessionId IN SAME_SESSION_OR_USER_WINDOW(GlobalProtectTunnelEstablished.SessionId)
AND VpnInternalFollowOn.Direction IN ANY (
"VPN_TO_INTERNAL",
"REMOTE_ACCESS_TO_INTERNAL",
"CLIENT_TO_INTERNAL"
)
AND VpnInternalFollowOn.ProtocolOrService IN ANY (
"DNS",
"LDAP",
"KERBEROS",
"SMB",
"RDP",
"SSH",
"WINRM",
"WMI",
"DATABASE",
"HTTP_INTERNAL",
"FILE_SHARE",
"ADMIN_PROTOCOL"
)
AND VpnInternalFollowOn.DestinationAsset IN ASSET_GROUP (
"Identity Infrastructure",
"Domain Controllers",
"Privileged Management Systems",
"Jump Hosts",
"Firewall Management Interfaces",
"VPN Administration Interfaces",
"Backup Systems",
"Endpoint Management Platforms",
"Sensitive Internal Applications"
)
)

AND NOT ChangeContext IN ANY (
"approved_travel",
"approved_vendor_access",
"approved_third_party_support",
"approved_sase_routing_change",
"approved_gateway_maintenance",
"approved_identity_provider_maintenance",
"approved_vpn_client_upgrade",
"approved_disaster_recovery_routing",
"approved_security_testing",
"approved_incident_response"
)

Rule

GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access

Rule Format

NDR behavioral trusted-session follow-on correlation rule suitable for network-flow telemetry, VPN session telemetry, internal DNS telemetry, NDR metadata, firewall logs, proxy logs, secure web gateway logs, PAN-OS telemetry, GlobalProtect session context, identity enrichment, account enrichment, asset criticality enrichment, privileged resource inventory, and SIEM correlation after VPN session mapping, internal destination validation, privileged-resource validation, source-context validation, baseline validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious internal activity following GlobalProtect VPN session establishment where the VPN-connected account accesses identity services, privileged resources, administrative protocols, sensitive applications, or internal systems inconsistent with normal behavior.

·        Identify trusted VPN session misuse after suspicious session establishment, authentication-lineage inconsistency, source infrastructure novelty, gateway-sequencing anomaly, or high-risk account use.

·        Prioritize VPN-authenticated internal reconnaissance, credential validation, identity-service access, administrative protocol use, jump-host access, management-plane access, and sensitive resource access.

·        Support escalation when suspicious VPN session activity leads to LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database access, file-share enumeration, administrative share access, privileged management access, or access to systems outside the user’s normal role.

·        Preserve separation between suspicious trusted-session use and confirmed compromise by requiring additional endpoint, identity, cloud, SaaS, file, persistence, credential-access, token-access, or incident-response evidence before classifying downstream compromise as confirmed.

·        This rule does not prove authentication bypass, exploit success, credential theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify GlobalProtect VPN session establishment or remote-access session activity for a user, device, source IP, gateway, tunnel identifier, or session identifier.

·        Prioritize sessions already associated with authentication-lineage gaps, source infrastructure novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency VPN use, vulnerable or unknown patch posture, or suspicious GlobalProtect portal or gateway behavior.

·        Detect internal network activity after VPN session establishment involving DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, internal web application, or administrative-protocol traffic.

·        Prioritize internal access to domain controllers, identity infrastructure, privileged management systems, firewall management interfaces, VPN administration interfaces, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        Increase confidence when activity involves many internal destinations, rare services for the user, first-seen internal destinations, administrative protocols, repeated authentication attempts, failed internal logons, credential validation, share enumeration, or access outside the user’s normal role.

·        Increase confidence when internal activity begins shortly after suspicious VPN session establishment, follows repeated short sessions, follows reconnect behavior, follows unusual gateway assignment, or appears after delayed low-and-slow access.

·        Increase confidence when endpoint telemetry from internal systems shows process execution, remote administration tooling, suspicious child processes, tool staging, credential-access behavior, or outbound follow-on from systems reached through the VPN session.

·        Reduce severity when activity matches approved administrator duties, helpdesk activity, engineering workflows, vulnerability management, security testing, incident response, scheduled maintenance, backup activity, software deployment, or documented third-party support.

·        Do not attribute internal reconnaissance or privileged resource access to GlobalProtect compromise without session linkage, suspicious VPN establishment evidence, abnormal account behavior, or incident-response validation.

·        Do not treat internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, or database activity as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        VPN session telemetry.

·        PAN-OS traffic logs.

·        GlobalProtect session context.

·        GlobalProtect tunnel-established events.

·        GlobalProtect gateway context.

·        GlobalProtect user mapping.

·        Internal DNS logs.

·        LDAP logs where available.

·        Kerberos logs where available.

·        SMB telemetry where available.

·        RDP telemetry where available.

·        SSH telemetry where available.

·        WinRM telemetry where available.

·        WMI telemetry where available.

·        Database access logs where available.

·        File-share access telemetry where available.

·        Firewall logs.

·        Internal segmentation telemetry.

·        NDR metadata.

·        Proxy logs where available.

·        Secure web gateway logs where available.

·        Endpoint telemetry where available.

·        EDR telemetry where available.

·        Identity logs where available.

·        User identity, device identity, source IP, gateway, session identifier, tunnel identifier, source zone, destination zone, destination asset, application, protocol, port, bytes, duration, and timestamp where available.

·        Asset criticality inventory.

·        Privileged resource inventory.

·        Identity infrastructure inventory.

·        Domain controller inventory.

·        Jump-host inventory.

·        Management-plane inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory where available.

·        Normal VPN user behavior baselines.

·        Normal internal resource access baselines.

·        Approved administrator workflow records.

·        Approved helpdesk records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build VPN session groups covering GlobalProtect tunnel-established events, remote-access sessions, gateway context, tunnel identifiers, session identifiers, source IPs, users, devices, and gateway assignments.

·        Build internal resource groups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, and high-value business applications.

·        Build internal protocol groups for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S internal, file-share, and administrative protocol activity.

·        Build suspicious internal behavior groups for first-seen destinations, rare user-to-destination pairs, rare services for the user, destination diversity, administrative protocol use, failed authentication bursts, credential validation, share enumeration, cross-segment access, and access outside the account’s normal role.

·        Build session-risk enrichment groups for authentication-lineage gaps, missing identity evidence, source novelty, gateway sequencing anomalies, privileged account use, third-party account use, low-frequency VPN use, unknown patch posture, and suspicious portal or gateway behavior.

·        Validate whether NDR, PAN-OS, GlobalProtect, DNS, firewall, proxy, secure web gateway, endpoint, identity, EDR, and SIEM telemetry can reliably join on user, device, source IP, gateway, session identifier, tunnel identifier, destination asset, timestamp, and account context.

·        Use short correlation windows for internal access immediately after suspicious VPN session establishment.

·        Use moderate correlation windows for delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Use longer correlation windows when suspicious VPN access is followed by delayed endpoint telemetry, identity telemetry, cloud access, SaaS access, or incident-response evidence.

·        Add severity weighting for identity-service access, domain controller access, privileged management access, administrative protocol use, sensitive application access, destination novelty, account sensitivity, and session-risk context.

·        Treat internal access anomalies as confidence amplifiers, not standalone proof of GlobalProtect compromise.

·        Use approved administrator records, helpdesk records, vendor records, vulnerability management records, security-testing records, maintenance windows, software deployment records, backup schedules, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, VPN session groups, internal resource groups, protocol groups, behavior groups, enrichment fields, timing windows, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until session linkage, field availability, asset inventory, resource baselines, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to durable trusted-session misuse and post-session internal access behavior rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or request paths.

·        The rule remains useful if an adversary changes initial exploit mechanics, source infrastructure, VPN client attributes, gateway selection, timing, internal destination order, or post-session access sequence.

·        The score is supported by the durability of VPN-authenticated internal reconnaissance, identity-service access, administrative protocol use, privileged resource access, and access outside normal user baselines.

·        The score is constrained by split-tunnel visibility, incomplete internal network telemetry, weak asset inventory, NAT, SASE routing, incomplete VPN session mapping, and legitimate administrator or vendor workflows.

·        The rule is durable as a trusted-session misuse detector but should not be treated as standalone proof of authentication bypass, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, internal network visibility, DNS coverage, asset inventory, privileged resource inventory, user baselines, account enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, ZTNA overlays, endpoint-only access paths, incomplete internal telemetry, or weak session identifiers prevent reliable linkage between VPN sessions and internal access.

·        Operational confidence is reduced where administrators, engineers, helpdesk users, vulnerability management tools, security testing, incident response, or third-party support commonly access privileged systems through VPN.

·        Full-telemetry confidence improves when VPN session context is enriched with endpoint telemetry, EDR telemetry, identity logs, firewall logs, DNS logs, internal resource telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        This rule detects suspicious VPN-authenticated internal behavior, not authentication bypass by itself.

·        NDR may not observe endpoint process execution, user intent, credential theft, token theft, file activity, or exact authentication state without enrichment.

·        Split tunneling, SASE routing, ZTNA overlays, proxy paths, endpoint-only telemetry, NAT, carrier-grade NAT, and mobile networks may reduce visibility or attribution.

·        Legitimate administrator, helpdesk, engineering, security testing, vulnerability management, incident-response, vendor-support, and software-deployment workflows can produce similar behavior.

·        The rule may miss low-and-slow activity that remains within the user’s normal access profile or uses expected internal resources.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR GlobalProtect trusted VPN session follow-on query pattern requiring platform syntax validation, VPN session validation, internal destination validation, privileged-resource validation, source-context validation, user-baseline validation, session-linkage validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS GlobalProtectVpnSession

WHERE GlobalProtectVpnSession.EventType IN ANY (
"GlobalProtect Tunnel Established",
"VPN Session Established",
"Remote Access Session Established"
)

AND GlobalProtectVpnSession.User IN ASSET_GROUP (
"VPN Users",
"Privileged VPN Users",
"Administrative Users",
"Third Party VPN Users",
"Contractor VPN Users",
"Low Frequency VPN Users"
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GP_SESSION_RISK_WINDOW (
GlobalProtectEvent AS GpSessionRiskContext
WHERE GpSessionRiskContext.User IN SAME_USER(GlobalProtectVpnSession.User)
AND GpSessionRiskContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_portal_or_gateway_activity"
)
)

AND EVENT_NEAR WITHIN ENV_GP_INTERNAL_ACTIVITY_WINDOW (
NetworkEvent AS VpnInternalActivity
WHERE VpnInternalActivity.User IN SAME_USER(GlobalProtectVpnSession.User)
AND VpnInternalActivity.Direction IN ANY (
"VPN_TO_INTERNAL",
"REMOTE_ACCESS_TO_INTERNAL",
"CLIENT_TO_INTERNAL"
)
AND VpnInternalActivity.ProtocolOrService IN ANY (
"DNS",
"LDAP",
"KERBEROS",
"SMB",
"RDP",
"SSH",
"WINRM",
"WMI",
"DATABASE",
"HTTP_INTERNAL",
"FILE_SHARE",
"ADMIN_PROTOCOL"
)
AND (
VpnInternalActivity.DestinationAsset IN ASSET_GROUP (
"Identity Infrastructure",
"Domain Controllers",
"Jump Hosts",
"Privileged Management Systems",
"Firewall Management Interfaces",
"VPN Administration Interfaces",
"Backup Systems",
"Endpoint Management Platforms",
"Source Code Systems",
"CI/CD Infrastructure",
"Sensitive File Shares",
"Databases",
"High Value Business Applications"
)
OR VpnInternalActivity.ActivityPattern IN ANY (
"first_seen_internal_destination",
"rare_user_to_destination_pair",
"rare_service_for_user",
"destination_diversity",
"administrative_protocol_use",
"failed_authentication_burst",
"credential_validation_pattern",
"share_enumeration",
"cross_segment_access",
"access_outside_user_role"
)
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent AS InternalEndpointFollowOn
WHERE InternalEndpointFollowOn.Asset IN SAME_DESTINATION_SET(VpnInternalActivity.DestinationAsset)
AND InternalEndpointFollowOn.EventType IN ANY (
"Remote Administration Tooling",
"Suspicious Process Execution",
"Credential Access Behavior",
"Tool Staging",
"Persistence Attempt",
"Outbound Follow On Communication",
"Suspicious Child Process"
)
)

AND NOT ChangeContext IN ANY (
"approved_administrator_activity",
"approved_helpdesk_activity",
"approved_vendor_support",
"approved_security_testing",
"approved_vulnerability_management",
"approved_incident_response",
"approved_maintenance_window",
"approved_backup_activity",
"approved_software_deployment"
)

Rule

GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity

Rule Format

NDR behavioral VPN-to-control-plane correlation rule suitable for network-flow telemetry, VPN session telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, cloud access telemetry, SaaS access telemetry, developer-platform telemetry, identity enrichment, account enrichment, destination enrichment, GlobalProtect session context, and SIEM correlation after VPN-to-cloud linkage validation, user and device validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect cloud, SaaS, developer-platform, source-code, CI/CD, or control-plane activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, session window, or incident timeline.

·        Identify downstream control-plane exposure after trusted VPN session compromise without treating cloud, SaaS, or developer-platform anomalies as standalone evidence of GlobalProtect compromise.

·        Prioritize activity involving privileged cloud roles, administrative SaaS actions, source-code access, CI/CD changes, application credential changes, token use, access-key activity, repository access, or security-control modification.

·        Support escalation when suspicious VPN access is followed by cloud, SaaS, identity, or developer-platform behavior inconsistent with the account’s normal role, device history, source path, or access baseline.

·        Preserve separation between suspicious VPN-linked downstream activity and confirmed cloud or SaaS compromise by requiring additional identity, cloud, SaaS, endpoint, file, persistence, credential-access, token-access, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, cloud compromise, SaaS compromise, developer-platform compromise, token theft, credential theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious or high-risk GlobalProtect VPN session establishment involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or internal follow-on activity.

·        Correlate the VPN session window with cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane access by the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Prioritize downstream actions involving privileged role access, administrative console access, IAM changes, MFA changes, conditional-access changes, application consent changes, API token creation, access-key creation, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, security-control changes, or data export.

·        Increase confidence when downstream access occurs from the same source IP, same device, same user, same VPN session window, same authentication session, same identity-provider session, or same incident sequence as the suspicious VPN session.

·        Increase confidence when downstream activity is rare for the user, new for the device, outside normal access windows, directed at sensitive tenants, directed at privileged applications, or inconsistent with the account’s role.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, unusual session creation, suspicious OAuth consent, CLI usage, API activity, or post-session administrative behavior.

·        Reduce severity when downstream activity aligns with approved administrator workflows, cloud operations, SaaS administration, developer workflows, CI/CD maintenance, incident response, vendor support, security testing, or documented change-control activity.

·        Do not attribute cloud, SaaS, identity, developer-platform, source-code, or CI/CD anomalies to GlobalProtect compromise without VPN session linkage, source path linkage, identity linkage, device linkage, or incident-response validation.

·        Do not treat cloud or SaaS anomalies as compromise evidence by themselves.

Required Telemetry

·        Network-flow telemetry.

·        VPN session telemetry.

·        GlobalProtect session context.

·        GlobalProtect tunnel-established events.

·        PAN-OS traffic logs.

·        DNS logs.

·        Proxy logs where available.

·        Secure web gateway logs where available.

·        Cloud access logs where available.

·        SaaS access logs where available.

·        Identity-provider logs.

·        Developer-platform logs where available.

·        Source-code platform logs where available.

·        CI/CD platform logs where available.

·        Cloud control-plane audit logs where available.

·        User identity, device identity, source IP, VPN gateway, session identifier, tunnel identifier, identity-provider session, destination domain, application, protocol, timestamp, action, and result where available.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Approved administrator workflow records.

·        Approved developer workflow records.

·        Approved cloud operations records.

·        Approved SaaS administration records.

·        Approved CI/CD maintenance records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build suspicious VPN session groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, suspicious portal behavior, suspicious gateway behavior, and internal follow-on activity.

·        Build cloud and SaaS destination groups covering cloud consoles, cloud APIs, identity administration portals, SaaS administration portals, developer platforms, source-code platforms, CI/CD platforms, application management portals, and privileged business applications.

·        Build control-plane action groups for IAM changes, role assignment, access-key creation, API token creation, service-account use, application consent changes, MFA changes, conditional-access changes, repository access, repository cloning, CI/CD workflow modification, secret access, audit-log access, security-control changes, and data export.

·        Build linkage logic using user identity, device identity, source IP, VPN session window, tunnel identifier, gateway, identity-provider session, authentication session, destination application, and incident timeline.

·        Build downstream-risk groups for rare user activity, first-seen destination, privileged role use, sensitive tenant access, sensitive repository access, unusual API activity, source path mismatch, device mismatch, access outside normal windows, and activity outside expected role.

·        Validate whether NDR, VPN session telemetry, GlobalProtect logs, DNS logs, proxy logs, secure web gateway logs, identity-provider logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, endpoint telemetry, and SIEM telemetry can reliably join on user, device, source IP, session window, destination, application, and timestamp.

·        Use short correlation windows when cloud, SaaS, or developer-platform activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed administrative activity, repository access, token use, CI/CD activity, source-code access, or cloud API activity after suspicious VPN establishment.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, or session continuity supports delayed linkage.

·        Add severity weighting for privileged role access, sensitive tenant access, source-code access, CI/CD access, application credential changes, access-key creation, token activity, security-control changes, data export, and verified VPN session linkage.

·        Treat downstream cloud, SaaS, identity, source-code, and CI/CD anomalies as investigative leads unless linked to suspicious VPN session evidence.

·        Use approved administrator records, cloud operations records, SaaS administration records, developer workflow records, CI/CD maintenance records, vendor-support records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, VPN session groups, cloud and SaaS destination groups, developer-platform groups, control-plane action groups, linkage fields, timing windows, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, destination validation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked downstream control-plane activity rather than static exploit strings, CVE identifiers, source IPs, domains, user-agent values, or isolated cloud anomalies.

·        The rule remains useful if an adversary changes cloud service, SaaS target, developer platform, API sequence, access method, source infrastructure, token use pattern, or post-session timing.

·        The score is supported by the durability of suspicious VPN session linkage, privileged cloud or SaaS action, developer-platform access, source-code access, CI/CD interaction, and control-plane behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-cloud linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, device mismatch, and incomplete SaaS or developer-platform logs.

·        The rule is durable as a downstream exposure detector but should not be treated as standalone proof of GlobalProtect compromise or cloud compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, identity-provider logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, DNS or proxy visibility, source enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, cloud session reuse, token reuse, identity federation, source IP changes, or inconsistent device identifiers make VPN-to-cloud linkage uncertain.

·        Operational confidence is reduced where administrators, developers, cloud engineers, SaaS administrators, DevOps teams, vendors, or incident responders commonly perform control-plane actions after VPN access.

·        Full-telemetry confidence improves when cloud, SaaS, and developer-platform events are enriched with VPN session evidence, identity-provider session context, endpoint telemetry, source path evidence, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious downstream control-plane activity linked to suspicious VPN sessions, not authentication bypass or cloud compromise by itself.

·        NDR may not observe full cloud action contents, SaaS administrative context, token origin, browser session context, device posture, or endpoint process execution without enrichment.

·        Cloud, SaaS, identity, source-code, and CI/CD activity may be legitimate for administrators, developers, cloud engineers, DevOps staff, vendors, or incident responders.

·        VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, or source IP transformation obscures path attribution.

·        The rule may miss downstream abuse that occurs outside the correlation window, from reused tokens, from a different device, from a different source path, or through a pre-existing cloud session.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR GlobalProtect-linked VPN session to cloud, SaaS, and developer-platform control-plane activity query pattern requiring platform syntax validation, VPN session validation, identity-linkage validation, source-path validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS SuspiciousGlobalProtectVpnSession

WHERE SuspiciousGlobalProtectVpnSession.EventType IN ANY (
"GlobalProtect Tunnel Established",
"VPN Session Established",
"Remote Access Session Established"
)

AND SuspiciousGlobalProtectVpnSession.SessionRiskContext IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)

AND EVENT_NEAR WITHIN ENV_GP_TO_CONTROL_PLANE_WINDOW (
NetworkOrApplicationEvent AS DownstreamControlPlaneActivity
WHERE DownstreamControlPlaneActivity.User IN SAME_USER(SuspiciousGlobalProtectVpnSession.User)
AND (
DownstreamControlPlaneActivity.SourceIP IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnSession.SourceIP)
OR DownstreamControlPlaneActivity.DeviceId IN SAME_DEVICE(SuspiciousGlobalProtectVpnSession.DeviceId)
OR DownstreamControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnSession.IdentitySession)
OR DownstreamControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnSession.Timestamp)
)
AND DownstreamControlPlaneActivity.DestinationApplication IN ASSET_GROUP (
"Cloud Consoles",
"Cloud APIs",
"Identity Administration Portals",
"SaaS Administration Portals",
"Developer Platforms",
"Source Code Platforms",
"CI/CD Platforms",
"Privileged Business Applications"
)
AND (
DownstreamControlPlaneActivity.Action IN ANY (
"IAM Change",
"Role Assignment",
"Access Key Created",
"API Token Created",
"Service Account Used",
"Application Consent Changed",
"MFA Changed",
"Conditional Access Changed",
"Repository Accessed",
"Repository Cloned",
"CI/CD Workflow Modified",
"Secret Accessed",
"Audit Log Accessed",
"Security Control Changed",
"Data Exported"
)
OR DownstreamControlPlaneActivity.ActivityPattern IN ANY (
"rare_user_activity",
"first_seen_destination",
"privileged_role_use",
"sensitive_tenant_access",
"sensitive_repository_access",
"unusual_api_activity",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role"
)
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_OR_IDENTITY_CONTEXT_WINDOW (
EndpointOrIdentityEvent AS SupportingContext
WHERE SupportingContext.User IN SAME_USER(SuspiciousGlobalProtectVpnSession.User)
AND SupportingContext.EventType IN ANY (
"Credential Access Behavior",
"Token Access",
"Browser Credential Store Access",
"Suspicious OAuth Consent",
"Cloud CLI Usage",
"Unusual Session Creation",
"Suspicious API Activity",
"Post Session Administrative Behavior"
)
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_saas_administration",
"approved_developer_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

SentinelOne

Detection Viability Assessment

SentinelOne has three rules for this EXP report.

·        SentinelOne is viable for detecting endpoint-side behavior associated with GlobalProtect authentication-lineage bypass and trusted VPN session compromise, including GlobalProtect client activity, VPN adapter creation, suspicious post-connection process execution, tool staging, credential-access behavior, remote administration activity, persistence, and activity on internal systems reached through suspicious VPN access.

·        SentinelOne is strongest where Deep Visibility telemetry, process telemetry, command-line telemetry, parent-child process relationships, Storyline context, file telemetry, DLL-load telemetry, network telemetry, GlobalProtect client process context, VPN adapter context, DNS enrichment, proxy enrichment, secure web gateway enrichment, identity enrichment, and SIEM correlation can be combined.

·        SentinelOne can identify post-session endpoint behavior even when the GlobalProtect authentication-lineage gap, portal-to-gateway sequencing anomaly, SAML mismatch, MFA mismatch, HIP mismatch, authentication-cookie inconsistency, or session-token inconsistency is observed through PAN-OS, GlobalProtect, identity-provider, MFA, NDR, SIEM, or cloud telemetry rather than directly inside SentinelOne.

·        SentinelOne is not a standalone source for confirming GlobalProtect exploitation, successful authentication bypass, identity-provider bypass, MFA bypass, HIP bypass, SAML assertion misuse, session-token misuse, authentication-cookie misuse, cloud compromise, or actor attribution.

·        SentinelOne detections must be correlated with PAN-OS logs, GlobalProtect portal logs, GlobalProtect gateway logs, HIP logs, identity-provider logs, MFA logs, NDR telemetry, DNS logs, proxy logs, secure web gateway logs, cloud logs, SaaS logs, change-control records, and incident-response evidence before classifying endpoint behavior as GlobalProtect-linked compromise.

·        SentinelOne should be treated as endpoint confirmation, endpoint triage, and post-session behavior coverage for suspected trusted VPN session misuse, not standalone proof of the GlobalProtect exploit path.

·        SentinelOne rules should not generate high-confidence campaign attribution from GlobalProtect client activity alone, VPN adapter creation alone, PowerShell execution alone, command-shell execution alone, internal network connections alone, persistence alone, credential-access indicators alone, or SentinelOne behavioral alerts alone without suspicious VPN session context or validated post-session linkage.

Rule

GlobalProtect Client Session Followed by Suspicious Endpoint Execution or Tool Staging

Rule Format

SentinelOne endpoint behavioral correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, GlobalProtect client process context, VPN adapter context, parent-child process relationships, Storyline context, file telemetry, network telemetry, DNS enrichment, proxy enrichment, identity enrichment, suspicious VPN session enrichment, and SIEM correlation after endpoint field validation, GlobalProtect process mapping, VPN adapter validation, suspicious session-context validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious process execution, script execution, tool staging, archive extraction, executable retrieval, DLL staging, or command-line activity that occurs shortly after GlobalProtect client activity, VPN adapter creation, tunnel establishment, reconnect behavior, or suspicious VPN session context.

·        Identify endpoint behavior that may follow unauthorized VPN session establishment or trusted VPN session misuse without requiring SentinelOne to independently prove authentication bypass.

·        Prioritize suspicious post-connection execution involving PowerShell, command shell, WMI, WinRM, script hosts, archive utilities, remote administration tools, credential-access utilities, cloud CLIs, SaaS administration tools, or living-off-the-land binaries.

·        Support escalation when suspicious endpoint execution occurs on privileged workstations, administrative workstations, developer workstations, third-party endpoints, contractor endpoints, or systems associated with sensitive internal access.

·        Preserve separation between suspicious post-VPN endpoint behavior and confirmed compromise by requiring corroborating session context, file activity, persistence, credential access, network follow-on, identity evidence, or incident-response validation before classifying endpoint compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, identity-provider bypass, MFA bypass, credential theft, token theft, cloud compromise, or actor attribution without supporting GlobalProtect, identity, network, cloud, SaaS, or incident-response evidence.

Detection Logic

·        Identify GlobalProtect client process activity, VPN adapter creation, tunnel establishment context, reconnect behavior, or endpoint activity enriched with suspicious GlobalProtect session context.

·        Prioritize endpoint execution that occurs after suspicious VPN session establishment involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, source novelty, gateway-assignment anomalies, privileged-account use, third-party-account use, low-frequency VPN use, or missing identity evidence after telemetry completeness validation.

·        Detect suspicious process creation involving PowerShell, command shell, WMI, WinRM, wscript, cscript, mshta, rundll32, regsvr32, certutil, bitsadmin, curl, wget, archive utilities, remote administration tools, credential-access utilities, cloud CLIs, SaaS administration tools, or other locally relevant execution tools.

·        Prioritize command lines involving encoded execution, hidden windows, execution-policy bypass, no-profile execution, remote retrieval, direct IP access, suspicious command chaining, credential access, token access, archive extraction, user-writable path execution, or execution from temporary directories.

·        Prioritize file writes, archive extraction, script creation, executable creation, DLL creation, or tool staging in Downloads, Temp, AppData, ProgramData, Public, browser cache, user profile paths, administrative staging paths, or other user-writable locations.

·        Increase confidence when suspicious execution shares the same SentinelOne Storyline as GlobalProtect client activity, VPN adapter creation, suspicious network activity, or internal resource access.

·        Increase confidence when endpoint activity is followed by internal connections to identity infrastructure, domain controllers, jump hosts, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, or sensitive applications.

·        Increase confidence when the endpoint activity is followed by credential access, token access, persistence creation, suspicious outbound communication, remote administration behavior, or SentinelOne behavioral threat indicators.

·        Reduce severity when activity matches approved administrator workflows, helpdesk activity, software deployment, VPN troubleshooting, security testing, vulnerability management, developer workflows, cloud operations, incident response, and documented change-control activity.

·        Do not classify post-VPN endpoint execution as GlobalProtect-linked compromise without suspicious VPN session context, GlobalProtect client linkage, VPN adapter context, session timing, internal access linkage, or incident-response validation.

·        Do not treat PowerShell, command shell, tool staging, or GlobalProtect client activity as compromise evidence by itself.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation events.

·        Process termination events where available.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        User identity.

·        Device identity.

·        Working directory.

·        Integrity level.

·        Process start time.

·        SentinelOne Storyline context.

·        GlobalProtect client process telemetry.

·        VPN adapter creation telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        Proxy enrichment where available.

·        Secure web gateway enrichment where available.

·        File creation telemetry.

·        File modification telemetry.

·        Archive extraction telemetry where available.

·        DLL load telemetry where available.

·        Script execution telemetry.

·        PowerShell telemetry.

·        Command-shell telemetry.

·        WMI and WinRM telemetry where available.

·        SentinelOne behavioral indicators.

·        SentinelOne threat indicators.

·        Suspicious GlobalProtect session enrichment.

·        Authentication-lineage context from SIEM where available.

·        Portal-to-gateway sequencing context from SIEM where available.

·        Identity-provider and MFA enrichment where available.

·        Approved administrator workflow baselines.

·        Approved helpdesk workflow baselines.

·        Approved software deployment baselines.

·        Approved developer workflow baselines.

·        Approved security testing baselines.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build GlobalProtect process groups covering PanGPS, PanGPA, GlobalProtect client processes, VPN service processes, VPN adapter creation context, reconnect behavior, and locally observed GlobalProtect endpoint components.

·        Build suspicious execution groups covering PowerShell, command shell, WMI, WinRM, wscript, cscript, mshta, rundll32, regsvr32, certutil, bitsadmin, curl, wget, archive utilities, remote administration tools, credential-access tools, cloud CLIs, SaaS administration tools, developer tools, and locally relevant living-off-the-land binaries.

·        Build suspicious command-line groups for encoded execution, hidden windows, execution-policy bypass, no-profile execution, remote retrieval, direct IP access, suspicious command chaining, credential access, token access, archive extraction, user-writable path execution, and temporary-path execution.

·        Build file-staging groups for Downloads, Temp, AppData, ProgramData, Public, browser cache, user profile paths, administrative staging paths, script directories, archive extraction paths, and locally observed staging locations.

·        Build suspicious session enrichment groups using SIEM, NDR, PAN-OS, GlobalProtect, identity-provider, MFA, HIP, DNS, proxy, and secure web gateway context that identifies authentication-lineage gaps, portal-to-gateway sequencing anomalies, source novelty, gateway-assignment anomalies, high-risk account use, or suspicious internal follow-on behavior.

·        Build post-execution groups for credential access, token access, persistence creation, suspicious outbound communication, remote administration tooling, internal resource access, and SentinelOne behavioral threat indicators.

·        Validate SentinelOne field availability for process ancestry, command line, file path, user identity, device identity, Storyline ID, network connections, DNS enrichment, file writes, DLL loads, script execution, and behavioral indicators.

·        Validate SIEM joins between SentinelOne telemetry, GlobalProtect telemetry, PAN-OS logs, identity-provider logs, MFA logs, NDR telemetry, DNS logs, proxy logs, and secure web gateway logs.

·        Use short correlation windows when GlobalProtect client activity or suspicious VPN context is followed immediately by process execution, tool staging, file creation, or network activity.

·        Use moderate correlation windows when VPN session activity is followed by delayed execution, file staging, credential access, token access, or persistence.

·        Use longer correlation windows only when SentinelOne Storyline continuity, VPN session evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for suspicious VPN session context, privileged account use, sensitive endpoint role, suspicious process ancestry, encoded command content, remote retrieval, user-writable path execution, credential access, token access, persistence, and internal follow-on activity.

·        Treat GlobalProtect client activity, VPN adapter creation, suspicious command execution, and tool staging as confidence amplifiers, not standalone proof of compromise.

·        Build allowlists for approved administrator scripts, helpdesk procedures, software deployment tools, VPN troubleshooting, developer workflows, security testing, vulnerability management, cloud operations, incident response, and known automation.

·        Do not enable alert mode until process grouping, command-line parsing, VPN context enrichment, Storyline correlation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious endpoint execution after GlobalProtect client or suspicious VPN session context rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or request paths.

·        The rule remains useful if an adversary changes source infrastructure, client timing, tool choice, command syntax, staging path, execution method, or post-session sequence.

·        The score is supported by the durability of GlobalProtect-linked process execution, suspicious command lines, tool staging, user-writable path execution, credential access, token access, persistence, and Storyline correlation.

·        The score is constrained by legitimate administrator activity, helpdesk workflows, software deployment, developer tooling, VPN troubleshooting, incomplete command-line telemetry, missing GlobalProtect client context, and weak SIEM enrichment.

·        The rule is durable as endpoint post-session behavior coverage but should not be treated as standalone proof of authentication bypass or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne process telemetry, command-line visibility, Storyline continuity, file telemetry, network telemetry, GlobalProtect client context, VPN adapter context, DNS enrichment, and suspicious session enrichment.

·        Operational confidence is reduced where GlobalProtect client context is unavailable, command lines are truncated, process ancestry is incomplete, VPN adapter activity is not captured, or SentinelOne telemetry cannot be joined to GlobalProtect session context.

·        Operational confidence is reduced in administrator, developer, helpdesk, cloud operations, security testing, vulnerability management, and incident-response environments where post-VPN execution may be legitimate.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with PAN-OS logs, GlobalProtect logs, identity-provider logs, MFA logs, HIP logs, NDR telemetry, internal network telemetry, cloud logs, SaaS logs, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        SentinelOne cannot independently confirm GlobalProtect authentication bypass, identity-provider bypass, MFA bypass, HIP bypass, or portal-to-gateway sequencing failure without external enrichment.

·        GlobalProtect client activity and VPN adapter creation may be normal and should not be treated as suspicious without session context or post-connection behavior.

·        PowerShell, command shell, remote administration tooling, cloud CLIs, developer tools, and file staging may be legitimate in administrator, developer, helpdesk, cloud operations, security testing, and incident-response workflows.

·        Missing command-line telemetry, incomplete process ancestry, weak Storyline continuity, or missing GlobalProtect enrichment can reduce confidence.

·        This rule may miss activity that uses approved tooling, blends with normal administrator workflows, executes outside the correlation window, or does not produce suspicious endpoint artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility query pattern requiring tenant syntax validation, endpoint field validation, GlobalProtect process validation, VPN adapter validation, suspicious session enrichment validation, command-line parsing validation, Storyline validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS PostVpnSuspiciousExecution

WHERE PostVpnSuspiciousExecution.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"Script Execution",
"DLL Load",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND PostVpnSuspiciousExecution.AgentComputerName IN ASSET_GROUP (
"Managed User Endpoints",
"Privileged Workstations",
"Administrative Workstations",
"Developer Workstations",
"Third Party Endpoints",
"Contractor Endpoints",
"High Risk User Endpoints",
"Endpoints With Suspicious GlobalProtect Session Context"
)

AND EVENT_NEAR WITHIN ENV_GP_ENDPOINT_CONTEXT_WINDOW (
SentinelOneEndpointEvent AS GlobalProtectClientContext
WHERE GlobalProtectClientContext.AgentComputerName IN SAME_DEVICE(PostVpnSuspiciousExecution.AgentComputerName)
AND (
GlobalProtectClientContext.ProcName IN ANY (
"PanGPS.exe",
"PanGPA.exe",
"GlobalProtect.exe"
)
OR GlobalProtectClientContext.EventType IN ANY (
"VPN Adapter Created",
"GlobalProtect Client Started",
"GlobalProtect Reconnect",
"GlobalProtect Tunnel Established",
"VPN Session Context Enriched"
)
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GP_SUSPICIOUS_SESSION_CONTEXT_WINDOW (
SecurityEvent AS SuspiciousVpnContext
WHERE SuspiciousVpnContext.UserOrDevice IN SAME_USER_OR_DEVICE(PostVpnSuspiciousExecution.UserOrDevice)
AND SuspiciousVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence_after_validation",
"missing_mfa_evidence_after_validation",
"missing_hip_evidence_after_validation",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)

AND (
PostVpnSuspiciousExecution.TgtProcName IN ANY (
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"wmic.exe",
"winrm.vbs",
"certutil.exe",
"bitsadmin.exe",
"curl.exe",
"wget.exe",
"python.exe",
"node.exe",
"ssh.exe"
)

OR PostVpnSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"-enc",
"-encodedcommand",
"executionpolicy bypass",
"-nop",
"-noprofile",
"-w hidden",
"downloadstring",
"invoke-webrequest",
"invoke-expression",
"frombase64string",
"certutil",
"bitsadmin",
"curl",
"wget",
"http://",
"https://",
"appdata",
"temp",
"users\public",
"programdata",
"credential",
"token",
"dump",
"secret"
)

OR PostVpnSuspiciousExecution.TgtFilePath CONTAINS ANY (
"\Downloads\",
"\AppData\",
"\Temp\",
"\ProgramData\",
"\Users\Public\"
)

OR PostVpnSuspiciousExecution.BehavioralIndicator IN ANY (
"Suspicious Process Execution",
"Credential Access Behavior",
"Token Access",
"Persistence Attempt",
"Suspicious Child Process",
"Outbound Follow On Communication",
"Remote Administration Tooling",
"Tool Staging"
)
)

AND NOT PostVpnSuspiciousExecution.AgentComputerName IN ASSET_GROUP (
"Approved Administrator Workstations",
"Approved Developer Workstations",
"Approved Helpdesk Workstations",
"Approved Software Deployment Systems",
"Approved Security Testing Systems",
"Approved Incident Response Systems"
)

AND NOT PostVpnSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"approved_admin_script",
"approved_helpdesk_procedure",
"approved_software_deployment",
"approved_vpn_troubleshooting",
"approved_security_testing",
"approved_incident_response"
)

Rule

Suspicious Activity on Internal Systems Reached Through a GlobalProtect VPN Session

Rule Format

SentinelOne endpoint behavioral internal-system correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, Storyline context, file telemetry, network telemetry, DNS enrichment, identity enrichment, asset criticality enrichment, GlobalProtect session enrichment, NDR enrichment, and SIEM correlation after destination-system validation, VPN session linkage validation, endpoint field validation, process lineage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious endpoint activity on internal systems that were reached through a suspicious or high-risk GlobalProtect VPN session.

·        Identify post-session behavior on domain controllers, identity infrastructure, jump hosts, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, database servers, file servers, or high-value business systems.

·        Prioritize process execution, credential access, token access, remote administration tooling, persistence, tool staging, suspicious child processes, outbound follow-on communication, or file activity that occurs after VPN-authenticated access to the internal system.

·        Support escalation when activity on the internal system can be linked to the VPN-connected user, source device, tunnel session, session window, identity session, or incident timeline.

·        Preserve separation between suspicious internal endpoint behavior and confirmed compromise by requiring session linkage, endpoint evidence, identity evidence, file evidence, persistence, command-and-control behavior, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify internal systems accessed after suspicious or high-risk GlobalProtect VPN session establishment.

·        Prioritize internal systems with high criticality, including domain controllers, identity infrastructure, jump hosts, privileged access workstations, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, database servers, file servers, and sensitive business systems.

·        Detect suspicious endpoint activity on those systems, including suspicious process execution, remote administration tooling, command-line activity, script execution, credential-access behavior, token access, file staging, persistence, unauthorized agent deployment, suspicious child processes, or outbound follow-on communication.

·        Increase confidence when suspicious endpoint activity occurs shortly after VPN-authenticated access from the suspicious session.

·        Increase confidence when activity involves the same user, source device, destination system, identity session, VPN session window, remote logon session, or incident timeline.

·        Increase confidence when endpoint behavior occurs after internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, or administrative-protocol activity from the VPN-connected session.

·        Increase confidence when multiple internal systems show similar suspicious activity after the same VPN session, same source device, same user, same account, or same external source infrastructure.

·        Reduce severity when activity aligns with approved administrator workflows, helpdesk actions, software deployment, backup operations, vulnerability management, security testing, EDR response, incident response, vendor support, or documented maintenance.

·        Do not attribute suspicious activity on an internal system to GlobalProtect compromise without VPN session linkage, internal access evidence, identity linkage, endpoint evidence, or incident-response validation.

·        Do not treat endpoint alerts on systems touched after VPN access as GlobalProtect-linked compromise by themselves.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation events.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File execution telemetry.

·        DLL load telemetry where available.

·        Registry modification telemetry where available.

·        Scheduled task telemetry where available.

·        Service creation telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        User identity.

·        Device identity.

·        Hostname.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        Working directory.

·        Integrity level.

·        Timestamp.

·        Remote logon context where available.

·        GlobalProtect session enrichment.

·        VPN session linkage enrichment.

·        Internal access enrichment from NDR or SIEM.

·        Asset criticality enrichment.

·        Domain controller inventory.

·        Identity infrastructure inventory.

·        Jump-host inventory.

·        Privileged management inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory.

·        Sensitive application inventory.

·        Approved administrator workflow records.

·        Approved helpdesk workflow records.

·        Approved software deployment baselines.

·        Approved backup schedules.

·        Approved vulnerability management records.

·        Approved security testing records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build internal high-value asset groups covering domain controllers, identity infrastructure, jump hosts, privileged access workstations, privileged management systems, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, database servers, file servers, and sensitive business systems.

·        Build VPN-linked destination groups using NDR, PAN-OS, GlobalProtect, firewall, DNS, proxy, identity, or SIEM telemetry showing that a suspicious VPN session reached the internal system.

·        Build suspicious endpoint behavior groups for suspicious process execution, remote administration tooling, PowerShell, command shell, WMI, WinRM, script hosts, credential-access behavior, token access, tool staging, persistence creation, scheduled task creation, service creation, registry modification, unauthorized agent deployment, suspicious child processes, and outbound follow-on communication.

·        Build linkage logic using user identity, device identity, destination hostname, VPN session window, tunnel identifier, remote logon context, identity session, source IP, destination asset, and incident timeline.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file activity, registry activity, service creation, scheduled tasks, network connections, user identity, device identity, and timestamp.

·        Validate SIEM joins between SentinelOne telemetry, NDR telemetry, PAN-OS logs, GlobalProtect session context, firewall logs, DNS logs, identity logs, asset inventory, and incident-response evidence.

·        Use short correlation windows when suspicious endpoint behavior occurs immediately after VPN-authenticated internal access.

·        Use moderate correlation windows for delayed process execution, tool staging, credential access, persistence, outbound communication, or repeated access to the same internal system.

·        Use longer correlation windows only when Storyline continuity, VPN session evidence, identity evidence, asset access evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for domain controller access, identity infrastructure access, privileged management access, backup-system access, endpoint-management access, source-code access, CI/CD access, credential access, token access, persistence, outbound follow-on, and multiple affected internal systems.

·        Treat endpoint alerts on touched systems as confidence amplifiers, not standalone proof of GlobalProtect compromise.

·        Build allowlists for approved administrator workflows, helpdesk actions, software deployment, backup activity, vulnerability management, EDR response, security testing, vendor support, maintenance windows, and incident-response activity.

·        Do not enable alert mode until VPN session linkage, destination validation, asset inventory, process lineage, Storyline joins, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious activity on internal systems reached through a VPN session rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or GlobalProtect request patterns.

·        The rule remains useful if an adversary changes the initial access method, source infrastructure, VPN session timing, internal path, tool choice, staging path, or post-access sequence.

·        The score is supported by the durability of suspicious process execution, credential access, token access, persistence, remote administration tooling, tool staging, and outbound follow-on behavior on high-value internal systems.

·        The score is constrained by weak VPN session linkage, incomplete internal access telemetry, legitimate administrator activity, missing remote logon context, incomplete Storyline continuity, and limited asset inventory.

·        The rule is durable as endpoint confirmation coverage but should not be treated as standalone proof of GlobalProtect exploitation or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne endpoint telemetry, Storyline continuity, internal access enrichment, VPN session linkage, asset inventory, identity context, process telemetry, file telemetry, and SIEM join quality.

·        Operational confidence is reduced where endpoint telemetry cannot be tied to VPN session activity, internal access logs are incomplete, remote logon context is missing, or high-value asset inventory is weak.

·        Operational confidence is reduced where administrators, helpdesk users, vulnerability management tools, software deployment systems, backup systems, EDR responders, vendors, or incident responders commonly perform similar activity.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with NDR telemetry, GlobalProtect session context, PAN-OS logs, firewall logs, DNS logs, identity logs, internal resource telemetry, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        SentinelOne cannot independently prove that the internal system was reached through a suspicious GlobalProtect VPN session without external VPN, network, identity, or SIEM enrichment.

·        Suspicious endpoint behavior on an internal system may be unrelated to the VPN session unless timing, identity, device, session, or incident-response evidence supports linkage.

·        Legitimate administrator, helpdesk, software deployment, backup, vulnerability management, security testing, EDR response, vendor-support, and incident-response workflows can produce similar endpoint behavior.

·        Missing remote logon context, incomplete process lineage, weak Storyline continuity, missing network enrichment, or incomplete asset inventory can reduce confidence.

·        This rule may miss activity that remains within approved tooling, uses expected administrator pathways, occurs outside the correlation window, or does not generate endpoint artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility query pattern requiring tenant syntax validation, endpoint field validation, internal asset validation, VPN session linkage validation, Storyline validation, process lineage validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS InternalSystemSuspiciousActivity

WHERE InternalSystemSuspiciousActivity.AgentComputerName IN ASSET_GROUP (
"Domain Controllers",
"Identity Infrastructure",
"Jump Hosts",
"Privileged Access Workstations",
"Privileged Management Systems",
"Management Servers",
"Backup Systems",
"Endpoint Management Platforms",
"Source Code Systems",
"CI/CD Systems",
"Database Servers",
"File Servers",
"Sensitive Business Systems"
)

AND InternalSystemSuspiciousActivity.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"File Execution",
"DLL Load",
"Registry Modified",
"Scheduled Task Created",
"Service Created",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND EVENT_NEAR WITHIN ENV_GP_INTERNAL_ACCESS_CONTEXT_WINDOW (
SecurityEvent AS VpnLinkedInternalAccess
WHERE VpnLinkedInternalAccess.DestinationAsset IN SAME_DEVICE(InternalSystemSuspiciousActivity.AgentComputerName)
AND VpnLinkedInternalAccess.EventPattern IN ANY (
"vpn_authenticated_access",
"globalprotect_session_reached_internal_system",
"suspicious_vpn_session_reached_internal_system",
"vpn_linked_privileged_resource_access",
"vpn_linked_identity_service_access",
"vpn_linked_admin_protocol_activity"
)
)

AND (
InternalSystemSuspiciousActivity.TgtProcName IN ANY (
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"wmic.exe",
"winrm.vbs",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"psexec.exe",
"procdump.exe",
"rclone.exe",
"ssh.exe",
"python.exe",
"node.exe"
)

OR InternalSystemSuspiciousActivity.TgtProcCmdLine CONTAINS ANY (
"-enc",
"-encodedcommand",
"executionpolicy bypass",
"downloadstring",
"invoke-webrequest",
"invoke-expression",
"credential",
"token",
"dump",
"lsass",
"ntds",
"sam",
"shadow",
"secrets",
"admin$",
"c$",
"psexec",
"wmic",
"winrm",
"rclone"
)

OR InternalSystemSuspiciousActivity.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Persistence Attempt",
"Remote Administration Tooling",
"Tool Staging",
"Suspicious Child Process",
"Outbound Follow On Communication",
"Unauthorized Agent Deployment"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GP_LINKAGE_CONTEXT_WINDOW (
SecurityEvent AS SupportingVpnContext
WHERE SupportingVpnContext.UserOrDevice IN SAME_USER_OR_DEVICE(InternalSystemSuspiciousActivity.UserOrDevice)
AND SupportingVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence_after_validation",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)

AND NOT InternalSystemSuspiciousActivity.AgentComputerName IN ASSET_GROUP (
"Approved Software Deployment Systems",
"Approved Backup Systems",
"Approved Vulnerability Management Systems",
"Approved Security Testing Systems",
"Approved EDR Response Systems",
"Approved Incident Response Systems"
)

AND NOT InternalSystemSuspiciousActivity.TgtProcCmdLine CONTAINS ANY (
"approved_admin_script",
"approved_helpdesk_action",
"approved_software_deployment",
"approved_backup_activity",
"approved_vulnerability_scan",
"approved_security_testing",
"approved_edr_response",
"approved_incident_response"
)

Rule

GlobalProtect-Linked Endpoint Credential or Token Access Followed by Cloud, SaaS, or Developer-Platform Activity

Rule Format

SentinelOne endpoint-to-control-plane correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, file telemetry, browser credential-store telemetry, token-access telemetry, Storyline context, network telemetry, DNS enrichment, proxy enrichment, GlobalProtect session enrichment, identity enrichment, cloud enrichment, SaaS enrichment, developer-platform enrichment, and SIEM correlation after credential-access validation, token-access validation, VPN linkage validation, control-plane linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect endpoint credential-access or token-access behavior after suspicious GlobalProtect VPN session context when followed by cloud, SaaS, source-code, CI/CD, developer-platform, or control-plane activity.

·        Identify a post-session path where trusted VPN access may enable credential theft, token theft, browser credential-store access, cloud CLI use, SaaS administration, source-code access, or developer-platform interaction.

·        Prioritize endpoint behavior involving credential dumping, token access, browser credential-store access, secret access, cloud CLI activity, suspicious OAuth consent, API token creation, access-key use, repository access, or CI/CD interaction.

·        Support escalation when endpoint credential or token access is temporally and behaviorally linked to suspicious VPN session context and downstream cloud, SaaS, identity, developer-platform, source-code, or CI/CD activity.

·        Preserve separation between suspicious endpoint-to-control-plane behavior and confirmed compromise by requiring credential-access evidence, token-access evidence, downstream control-plane evidence, identity evidence, cloud evidence, SaaS evidence, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, cloud compromise, SaaS compromise, developer-platform compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify endpoint credential-access behavior, token-access behavior, browser credential-store access, secret access, suspicious OAuth consent behavior, cloud CLI use, developer CLI use, API token activity, or access-key-related activity.

·        Correlate endpoint credential or token activity to suspicious GlobalProtect VPN context, including authentication-lineage gaps, portal-to-gateway sequencing anomalies, unexpected gateway assignment, suspicious source infrastructure, high-risk account use, or suspicious internal follow-on activity.

·        Correlate endpoint credential or token activity to downstream cloud, SaaS, identity, source-code, CI/CD, or developer-platform activity involving the same user, device, source path, identity session, Storyline, destination application, or incident timeline.

·        Prioritize downstream activity involving privileged role access, administrative SaaS actions, IAM changes, MFA changes, conditional-access changes, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, secret access, access-key creation, API token creation, or data export.

·        Increase confidence when endpoint credential or token access occurs on a device or internal system tied to suspicious VPN access.

·        Increase confidence when downstream control-plane activity is rare for the user, new for the device, outside normal access windows, directed at sensitive tenants or repositories, or inconsistent with the user’s normal role.

·        Increase confidence when the SentinelOne Storyline connects suspicious execution, credential access, token access, network activity, and downstream application access.

·        Reduce severity when activity matches approved administrator workflows, cloud operations, SaaS administration, developer workflows, CI/CD maintenance, incident response, vendor support, security testing, or documented change-control activity.

·        Do not attribute cloud, SaaS, identity, developer-platform, source-code, or CI/CD activity to GlobalProtect compromise without endpoint evidence, VPN session linkage, identity linkage, device linkage, source-path linkage, or incident-response validation.

·        Do not treat credential-access indicators, token-access indicators, cloud CLI use, SaaS activity, or developer-platform activity as compromise evidence by themselves.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation telemetry.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        Browser credential-store access telemetry where available.

·        Token-access telemetry where available.

·        Registry telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        Proxy enrichment where available.

·        Secure web gateway enrichment where available.

·        User identity.

·        Device identity.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        Working directory.

·        Timestamp.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        Identity-provider enrichment.

·        Cloud access enrichment where available.

·        SaaS access enrichment where available.

·        Developer-platform enrichment where available.

·        Source-code platform enrichment where available.

·        CI/CD platform enrichment where available.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Approved administrator workflow records.

·        Approved cloud operations records.

·        Approved SaaS administration records.

·        Approved developer workflow records.

·        Approved CI/CD maintenance records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build credential-access groups covering credential dumping, LSASS access, browser credential-store access, token access, secret access, cloud credential file access, API key access, service-account credential access, SSH key access, and access to locally relevant credential stores.

·        Build control-plane tool groups covering cloud CLIs, SaaS administration tools, developer CLIs, source-code tools, CI/CD tools, secret-management tools, browser-based administration, and locally relevant administrative utilities.

·        Build suspicious VPN context enrichment groups using SIEM, NDR, PAN-OS, GlobalProtect, identity-provider, MFA, HIP, DNS, proxy, and secure web gateway context that identifies authentication-lineage gaps, portal-to-gateway sequencing anomalies, source novelty, gateway-assignment anomalies, high-risk account use, or suspicious internal follow-on behavior.

·        Build downstream control-plane groups for cloud consoles, cloud APIs, identity administration portals, SaaS administration portals, developer platforms, source-code platforms, CI/CD platforms, privileged business applications, and sensitive repositories.

·        Build sensitive action groups for privileged role access, IAM changes, MFA changes, conditional-access changes, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, secret access, access-key creation, API token creation, and data export.

·        Build linkage logic using user identity, device identity, source IP, identity session, SentinelOne Storyline, VPN session window, tunnel identifier, destination application, and incident timeline.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file activity, browser credential-store access, registry activity, network connections, user identity, device identity, and timestamp.

·        Validate SIEM joins between SentinelOne telemetry, GlobalProtect telemetry, PAN-OS logs, identity-provider logs, MFA logs, NDR telemetry, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, DNS logs, proxy logs, and secure web gateway logs.

·        Use short correlation windows when credential access, token access, cloud CLI use, or developer-platform activity occurs immediately after suspicious VPN context.

·        Use moderate correlation windows for delayed cloud, SaaS, source-code, CI/CD, or developer-platform activity after endpoint credential or token access.

·        Use longer correlation windows only when Storyline continuity, identity evidence, VPN session evidence, endpoint evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for suspicious VPN context, credential-access behavior, token-access behavior, sensitive tenant access, source-code access, CI/CD access, privileged role use, access-key creation, API token creation, secret access, security-control changes, and data export.

·        Treat credential-access indicators and downstream control-plane activity as confidence amplifiers unless linked through endpoint, VPN, identity, device, source-path, or incident-response evidence.

·        Build allowlists for approved cloud operations, SaaS administration, developer workflows, CI/CD maintenance, vendor support, security testing, incident response, change-control activity, and known automation.

·        Do not enable alert mode until credential-access validation, token-access validation, VPN linkage, identity correlation, source-path correlation, downstream application validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to endpoint credential or token access followed by downstream control-plane activity rather than static exploit strings, CVE identifiers, source IPs, domains, user-agent values, or isolated cloud anomalies.

·        The rule remains useful if an adversary changes cloud service, SaaS target, developer platform, token use pattern, CLI tool, credential store, source infrastructure, or post-session timing.

·        The score is supported by the durability of credential access, token access, browser credential-store access, cloud CLI use, source-code access, CI/CD interaction, privileged role access, and downstream control-plane behavior.

·        The score is constrained by legitimate administrator and developer workflows, weak VPN linkage, incomplete browser credential telemetry, incomplete token telemetry, cloud session reuse, identity federation complexity, and incomplete cloud, SaaS, or developer-platform logs.

·        The rule is durable as endpoint-to-control-plane exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or cloud compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne process telemetry, Storyline continuity, credential-access visibility, token-access visibility, cloud and SaaS enrichment, developer-platform logs, VPN session enrichment, identity-provider context, and SIEM correlation quality.

·        Operational confidence is reduced where browser credential-store access is not visible, token telemetry is limited, cloud CLI usage is common, developer workflows are noisy, or VPN-to-cloud linkage is uncertain.

·        Operational confidence is reduced where administrators, developers, cloud engineers, SaaS administrators, DevOps teams, vendors, or incident responders commonly perform credential, token, cloud, SaaS, or CI/CD operations.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with GlobalProtect session context, PAN-OS logs, NDR telemetry, identity-provider logs, MFA logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint-to-control-plane triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        SentinelOne cannot independently prove GlobalProtect exploitation, authentication bypass, cloud compromise, SaaS compromise, or developer-platform compromise without external enrichment.

·        Credential-access and token-access indicators may be noisy in administrator, developer, cloud operations, CI/CD, security testing, and incident-response environments.

·        VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, identity federation, token reuse, cloud session reuse, or source IP transformation obscures path attribution.

·        The rule may miss downstream abuse that occurs from a different device, different source path, reused token, pre-existing session, or outside the correlation window.

·        Missing browser credential telemetry, token telemetry, command-line telemetry, Storyline continuity, cloud logs, SaaS logs, developer-platform logs, or source-code logs can reduce confidence.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne endpoint-to-control-plane correlation query pattern requiring tenant syntax validation, endpoint field validation, credential-access validation, token-access validation, VPN linkage validation, cloud and SaaS enrichment validation, developer-platform enrichment validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS EndpointCredentialOrTokenAccess

WHERE EndpointCredentialOrTokenAccess.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Access",
"File Creation",
"Registry Access",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND (
EndpointCredentialOrTokenAccess.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Browser Credential Store Access",
"Secret Access",
"Suspicious OAuth Consent",
"Cloud CLI Usage",
"Suspicious API Activity"
)

OR EndpointCredentialOrTokenAccess.TgtProcCmdLine CONTAINS ANY (
"lsass",
"ntds",
"sam",
"shadow",
"secrets",
"credential",
"token",
"oauth",
"apikey",
"accesskey",
"aws",
"az",
"gcloud",
"kubectl",
"gh",
"git clone",
"vault",
"secret"
)

OR EndpointCredentialOrTokenAccess.TgtFilePath CONTAINS ANY (
".aws\credentials",
".azure",
"gcloud",
".kube\config",
".ssh\",
"known_hosts",
"cookies",
"login data",
"local state",
"tokens",
"secrets"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GP_SUSPICIOUS_SESSION_CONTEXT_WINDOW (
SecurityEvent AS SuspiciousVpnContext
WHERE SuspiciousVpnContext.UserOrDevice IN SAME_USER_OR_DEVICE(EndpointCredentialOrTokenAccess.UserOrDevice)
AND SuspiciousVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity",
"suspicious_globalprotect_session_context"
)
)

AND EVENT_NEAR WITHIN ENV_ENDPOINT_TO_CONTROL_PLANE_WINDOW (
NetworkOrApplicationEvent AS DownstreamControlPlaneActivity
WHERE DownstreamControlPlaneActivity.User IN SAME_USER(EndpointCredentialOrTokenAccess.User)
AND (
DownstreamControlPlaneActivity.DeviceId IN SAME_DEVICE(EndpointCredentialOrTokenAccess.DeviceId)
OR DownstreamControlPlaneActivity.SourceIP IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(EndpointCredentialOrTokenAccess.SourceIP)
OR DownstreamControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(EndpointCredentialOrTokenAccess.IdentitySession)
OR DownstreamControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(EndpointCredentialOrTokenAccess.Timestamp)
)
AND DownstreamControlPlaneActivity.DestinationApplication IN ASSET_GROUP (
"Cloud Consoles",
"Cloud APIs",
"Identity Administration Portals",
"SaaS Administration Portals",
"Developer Platforms",
"Source Code Platforms",
"CI/CD Platforms",
"Privileged Business Applications"
)
AND (
DownstreamControlPlaneActivity.Action IN ANY (
"IAM Change",
"Role Assignment",
"Access Key Created",
"API Token Created",
"Service Account Used",
"Application Consent Changed",
"MFA Changed",
"Conditional Access Changed",
"Repository Accessed",
"Repository Cloned",
"CI/CD Workflow Modified",
"Secret Accessed",
"Security Control Changed",
"Data Exported"
)
OR DownstreamControlPlaneActivity.ActivityPattern IN ANY (
"rare_user_activity",
"first_seen_destination",
"privileged_role_use",
"sensitive_tenant_access",
"sensitive_repository_access",
"unusual_api_activity",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role"
)
)
)

AND NOT EndpointCredentialOrTokenAccess.AgentComputerName IN ASSET_GROUP (
"Approved Administrator Workstations",
"Approved Developer Workstations",
"Approved Cloud Operations Workstations",
"Approved CI/CD Systems",
"Approved Security Testing Systems",
"Approved Incident Response Systems"
)

AND NOT EndpointCredentialOrTokenAccess.TgtProcCmdLine CONTAINS ANY (
"approved_cloud_operation",
"approved_developer_workflow",
"approved_cicd_maintenance",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Splunk

Detection Viability Assessment

Splunk has three rules for this EXP report.

·        Splunk is viable for detecting GlobalProtect authentication-lineage failure, portal-to-gateway sequencing gaps, suspicious VPN session establishment, trusted VPN session misuse, and downstream control-plane activity because the detection model requires multi-source correlation across PAN-OS, GlobalProtect, identity-provider, MFA, HIP, endpoint, network, cloud, SaaS, and SIEM-enriched telemetry.

·        Splunk is strongest where PAN-OS traffic, system, authentication, and configuration logs are normalized with GlobalProtect portal logs, GlobalProtect gateway logs, tunnel-established events, HIP results, gateway-assignment context, identity-provider logs, MFA logs, endpoint telemetry, DNS telemetry, internal network telemetry, cloud logs, SaaS logs, asset inventory, account enrichment, and change-control context.

·        Splunk can correlate GlobalProtect tunnel establishment with portal authentication, gateway authentication, client configuration retrieval, SAML assertion context, MFA outcome, HIP evaluation, certificate validation, source infrastructure, account sensitivity, and post-session activity.

·        Splunk is not a standalone source for confirming successful exploitation, authentication bypass, identity-provider bypass, MFA bypass, HIP bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution unless the relevant telemetry sources are present and correlated.

·        Splunk detections must account for telemetry delay, ingestion gaps, parser failure, timestamp skew, provider outage, log-retention limits, NAT, carrier-grade NAT, SASE routing, split tunneling, and inconsistent identifiers before escalating missing authentication-lineage evidence.

·        Splunk rules should be treated as correlation and triage content, not one-click production logic, until local index names, sourcetypes, CIM mappings, field mappings, enrichment sources, timing windows, and exception logic are validated.

·        Splunk rules should not generate high-confidence alerting from vulnerable version posture alone, source novelty alone, tunnel establishment alone, missing identity evidence alone, endpoint alerting alone, internal discovery alone, cloud access alone, SaaS activity alone, or developer-platform activity alone.

Rule

GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence

Rule Format

Splunk multi-source authentication-lineage correlation rule suitable for PAN-OS logs, GlobalProtect portal logs, GlobalProtect gateway logs, GlobalProtect tunnel-established events, GlobalProtect gateway-assignment events, GlobalProtect HIP logs, identity-provider logs, MFA logs, SAML or OIDC context, certificate validation context, endpoint enrichment, source enrichment, account enrichment, asset inventory, and SIEM correlation after index validation, sourcetype validation, CIM mapping validation, GlobalProtect field validation, identity-provider field validation, timing-window tuning, telemetry-completeness validation, and environment-specific allowlisting.

Detection Purpose

·        Detect GlobalProtect tunnel-established events where expected authentication-lineage evidence is absent, incomplete, delayed, mismatched, or inconsistent after telemetry completeness has been validated.

·        Identify potential authentication-lineage failure, portal-to-gateway sequencing gaps, unauthorized VPN session establishment, or trusted remote-access session compromise.

·        Prioritize tunnel establishment involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Support escalation when suspicious tunnel establishment occurs from unfamiliar infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, mobile carrier networks, residential proxy infrastructure, SASE egress points, or source networks inconsistent with user history.

·        Preserve separation between suspicious VPN session establishment and confirmed compromise by requiring supporting GlobalProtect, identity, MFA, HIP, endpoint, internal network, cloud, SaaS, or incident-response evidence before classifying the activity as probable compromise.

·        This rule does not prove CVE-2026-0257 exploitation, authentication bypass, identity-provider bypass, MFA bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify GlobalProtect tunnel-established or VPN session establishment events from validated PAN-OS, GlobalProtect, or remote-access sourcetypes.

·        Correlate tunnel establishment with expected precursor events, including portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion validation, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, and gateway authentication.

·        Prioritize tunnel establishment where expected precursor evidence is absent, incomplete, delayed, mismatched, or inconsistent after ingestion delay, timestamp alignment, parser quality, log retention, and join reliability have been validated.

·        Prioritize session mismatches involving username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, gateway name, portal name, timestamp, client version, operating-system profile, HIP result, certificate context, authentication-cookie context, or session-token context.

·        Increase confidence when the account is privileged, administrative, security-related, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, rarely used for VPN, or associated with sensitive access.

·        Increase confidence when source infrastructure is newly observed, rare for the user, rare for the environment, associated with hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, unusual geographies, or ASNs not normally associated with the account.

·        Increase confidence when tunnel establishment is followed by internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, or administrative-protocol activity.

·        Reduce severity when behavior aligns with approved travel, mobile carrier use, regional gateway failover, SASE routing, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, incident response, or documented change-control activity.

·        Do not classify missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence as bypass until telemetry delay, ingestion gaps, provider outage, parser failure, retention limits, timestamp skew, and local join failure have been reviewed.

·        Do not treat tunnel establishment, source novelty, gateway change, vulnerable version posture, or missing telemetry as compromise evidence by itself.

Required Telemetry

·        Splunk indexes containing PAN-OS traffic logs.

·        Splunk indexes containing PAN-OS system logs.

·        Splunk indexes containing PAN-OS authentication logs.

·        Splunk indexes containing PAN-OS configuration logs where available.

·        Splunk indexes containing GlobalProtect portal logs.

·        Splunk indexes containing GlobalProtect gateway logs.

·        Splunk indexes containing GlobalProtect authentication events.

·        Splunk indexes containing GlobalProtect tunnel-established events.

·        Splunk indexes containing GlobalProtect client configuration retrieval events where available.

·        Splunk indexes containing GlobalProtect gateway-assignment events where available.

·        Splunk indexes containing GlobalProtect session-state events.

·        Splunk indexes containing HIP match results where available.

·        Splunk indexes containing HIP report results where available.

·        Authentication-cookie context where available.

·        Session-token context where available.

·        Identity-provider logs.

·        SAML or OIDC assertion context.

·        MFA logs.

·        Conditional-access logs where available.

·        Certificate validation context where available.

·        Device-compliance or posture context where available.

·        DNS logs where available.

·        Endpoint telemetry where available.

·        Source enrichment for IP, ASN, geography, reputation, network type, hosting provider, first-seen timestamp, and source history.

·        Account enrichment for username, user principal name, account type, privilege level, business unit, account status, and VPN usage frequency.

·        GlobalProtect enrichment for portal name, gateway name, gateway region, client version, operating-system profile, session identifier, tunnel identifier, and timestamp.

·        Asset inventory.

·        Gateway inventory.

·        VPN user inventory.

·        Privileged account inventory.

·        Third-party access inventory.

·        Approved remote-access source baselines.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Splunk index names, sourcetypes, field extractions, CIM mappings, data models, lookup tables, accelerated data models, and parsing behavior before production use.

·        Build normalized GlobalProtect event groups for portal request, portal authentication, identity-provider authentication, MFA decision, SAML assertion, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, reconnect, disconnect, and session state.

·        Build authentication-lineage correlation logic that evaluates whether expected precursor events occur before tunnel establishment within locally validated timing windows.

·        Build mismatch logic for username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, authentication cookie, session token, gateway name, portal name, client version, operating-system profile, HIP result, certificate context, and timestamp.

·        Build source-risk lookups for newly observed sources, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, proxy infrastructure, low-reputation sources, and sources inconsistent with user history.

·        Build account-risk lookups for privileged users, administrators, security staff, remote-access administrators, third-party accounts, contractor accounts, service-adjacent accounts, dormant accounts, stale accounts, recently re-enabled accounts, low-frequency VPN users, and users with sensitive access.

·        Build internal follow-on correlation for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, and administrative-protocol activity after tunnel establishment.

·        Use short correlation windows for expected portal-to-gateway authentication sequencing and tunnel establishment.

·        Use moderate correlation windows for delayed identity-provider evidence, delayed MFA evidence, HIP log delay, gateway-assignment lag, and session-state reconciliation.

·        Use longer correlation windows for delayed internal access, repeated short VPN sessions, recurring source infrastructure, or low-and-slow post-session activity.

·        Add severity weighting for privileged account use, missing authentication-lineage evidence after telemetry completeness validation, gateway-sequencing anomalies, suspicious source infrastructure, vulnerable or unknown patch posture, unfamiliar device context, and internal follow-on activity.

·        Treat source novelty, gateway changes, missing telemetry, HIP mismatch, or tunnel establishment as confidence amplifiers, not standalone compromise criteria.

·        Use approved travel records, vendor records, SASE routing changes, gateway maintenance records, identity-provider maintenance records, VPN client upgrade records, helpdesk records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indexes, sourcetypes, field mappings, lookups, macros, data-model acceleration, timing windows, enrichment fields, exception logic, parser behavior, and join logic before production deployment.

·        Do not enable alert mode until field availability, correlation reliability, telemetry completeness, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to durable authentication-lineage and portal-to-gateway sequencing gaps rather than static CVE strings, known exploit strings, source IPs, user-agent values, request paths, or payload indicators.

·        The rule remains useful if an adversary changes source infrastructure, timing, client version, user-agent, portal interaction pattern, gateway interaction pattern, authentication artifact usage, or post-session activity.

·        The score is supported by the durability of tunnel establishment without expected precursor evidence, gateway sequencing anomalies, identity-provider mismatch, MFA mismatch, HIP mismatch, session-state inconsistency, source novelty, and internal follow-on behavior.

·        The score is constrained by missing GlobalProtect logs, incomplete HIP logs, identity-provider logging gaps, MFA telemetry gaps, split-tunnel visibility limits, timestamp skew, NAT, carrier-grade NAT, SASE routing, inconsistent session identifiers, and local Splunk parsing quality.

·        The rule is durable as a SIEM correlation detector but should not be treated as standalone proof of authentication bypass, exploit success, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on GlobalProtect portal logs, gateway logs, tunnel-established events, HIP results, gateway-assignment context, identity-provider logs, MFA logs, reliable session identifiers, source enrichment, account enrichment, and Splunk join quality.

·        Operational confidence is reduced where identity-provider evidence is delayed, MFA logs are incomplete, HIP events are missing, authentication cookies are unavailable, session-token context is unavailable, or tunnel events cannot be reliably joined to portal and gateway events.

·        Operational confidence is reduced where split-tunnel routing, SASE egress, carrier-grade NAT, mobile networks, regional gateway failover, third-party access, or VPN client upgrades create legitimate source or sequencing changes.

·        Full-telemetry confidence improves when tunnel-established events are enriched with PAN-OS logs, GlobalProtect portal and gateway logs, HIP logs, identity-provider logs, MFA logs, endpoint telemetry, DNS logs, internal network telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation or actor attribution.

Limitations

This rule detects suspicious GlobalProtect authentication-lineage or portal-to-gateway sequencing behavior, not confirmed exploitation by itself.

Splunk may not contain identity-provider session state, MFA decision details, SAML assertion contents, authentication cookie contents, session-token contents, HIP report contents, or endpoint posture results unless those sources are ingested and normalized.

Missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence may reflect telemetry delay, ingestion failure, retention limits, parser failure, provider outage, timestamp skew, or Splunk field-mapping issues rather than successful bypass.

Legitimate travel, mobile carrier use, SASE routing, regional gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, and incident response can create similar patterns.

The rule may miss bypass activity where attackers produce apparently complete authentication-lineage artifacts, use valid credentials, abuse legitimate session material, or operate within normal user source and device patterns.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk SPL correlation pattern requiring index validation, sourcetype validation, field extraction validation, GlobalProtect event validation, identity-provider join validation, MFA join validation, HIP join validation, timing-window tuning, telemetry-completeness validation, and environment-specific allowlisting before production deployment.

index=<panos_or_globalprotect_index> sourcetype=<globalprotect_gateway_or_panos_sourcetype>
(
event_type="GlobalProtect Tunnel Established"
OR event_type="VPN Session Established"
OR event_type="Gateway Tunnel Established"
OR event_type="Remote Access Session Established"
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| eval gp_src=coalesce(src_ip, source_ip, client_ip)
| eval gp_device=coalesce(device_id, endpoint_id, host, hostname)
| eval gp_session=coalesce(session_id, tunnel_id, gp_session_id)
| lookup vpn_user_risk_lookup gp_user OUTPUT account_risk, privilege_level, vpn_frequency
| lookup source_context_lookup gp_src OUTPUT source_context, source_asn, source_geo, source_reputation, source_first_seen
| eval session_risk=if(
account_risk IN ("privileged","administrative","third_party","contractor","service_adjacent","dormant","stale","recently_reenabled","low_frequency_vpn_user")
OR source_context IN ("newly_observed_source","rare_asn","unusual_geography","hosting_provider_source","anonymization_service","residential_proxy_infrastructure","mobile_carrier_network","sase_egress_source","source_not_in_user_baseline"),
1, 0
)
| join type=left gp_user gp_src [
search index=<identity_provider_or_mfa_index> sourcetype=<idp_or_mfa_sourcetype>
(
event_type="Identity Provider Authentication Success"
OR event_type="MFA Success"
OR event_type="Conditional Access Success"
OR event_type="SAML Assertion Validated"
OR event_type="Certificate Validated"
OR event_type="HIP Evaluation Completed"
OR event_type="Client Configuration Retrieved"
OR event_type="Gateway Assigned"
OR event_type="Gateway Authentication Success"
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| eval gp_src=coalesce(src_ip, source_ip, client_ip)
| stats latest(_time) as latest_auth_time values(event_type) as auth_events by gp_user gp_src
]
| eval missing_expected_auth=if(isnull(latest_auth_time),1,0)
| eval telemetry_complete=<local_telemetry_completeness_macro>
| where telemetry_complete=1 AND (missing_expected_auth=1 OR session_risk=1)
| lookup approved_remote_access_context gp_user gp_src OUTPUT approval_context
| where isnull(approval_context)
| table time gpuser gp_src gp_device gp_session gateway portal account_risk source_context auth_events latest_auth_time missing_expected_auth session_risk

Rule

GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access

Rule Format

Splunk multi-source VPN follow-on correlation rule suitable for PAN-OS traffic logs, GlobalProtect session context, internal DNS logs, firewall logs, endpoint telemetry, identity logs, asset inventory, privileged-resource lookups, account enrichment, network telemetry, and SIEM correlation after index validation, sourcetype validation, CIM mapping validation, VPN session mapping, internal destination validation, privileged-resource validation, baseline validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious internal activity following GlobalProtect VPN session establishment where the VPN-connected account accesses identity services, privileged resources, administrative protocols, sensitive applications, or systems inconsistent with normal behavior.

·        Identify trusted VPN session misuse after suspicious session establishment, authentication-lineage inconsistency, source infrastructure novelty, gateway-sequencing anomaly, or high-risk account use.

·        Prioritize VPN-authenticated internal reconnaissance, credential validation, identity-service access, administrative protocol use, jump-host access, management-plane access, and sensitive resource access.

·        Support escalation when VPN session activity leads to LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database access, file-share enumeration, administrative share access, privileged management access, or access outside the user’s normal role.

·        Preserve separation between suspicious trusted-session use and confirmed compromise by requiring additional endpoint, identity, cloud, SaaS, file, persistence, credential-access, token-access, or incident-response evidence before classifying downstream compromise as confirmed.

·        This rule does not prove authentication bypass, exploit success, credential theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify GlobalProtect VPN session establishment or remote-access session activity for a user, device, source IP, gateway, tunnel identifier, or session identifier.

·        Prioritize sessions associated with authentication-lineage gaps, source infrastructure novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency VPN use, vulnerable or unknown patch posture, or suspicious GlobalProtect portal or gateway behavior.

·        Detect internal network activity after VPN establishment involving DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, internal web application, or administrative-protocol traffic.

·        Prioritize internal access to domain controllers, identity infrastructure, privileged management systems, firewall management interfaces, VPN administration interfaces, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        Increase confidence when activity involves many internal destinations, rare services for the user, first-seen internal destinations, administrative protocols, repeated authentication attempts, failed internal logons, credential validation, share enumeration, or access outside the user’s normal role.

·        Increase confidence when internal activity begins shortly after suspicious VPN session establishment, follows repeated short sessions, follows reconnect behavior, follows unusual gateway assignment, or appears after delayed low-and-slow access.

·        Increase confidence when endpoint telemetry from internal systems shows process execution, remote administration tooling, suspicious child processes, tool staging, credential-access behavior, or outbound follow-on from systems reached through the VPN session.

·        Reduce severity when activity matches approved administrator duties, helpdesk activity, engineering workflows, vulnerability management, security testing, incident response, scheduled maintenance, backup activity, software deployment, or documented third-party support.

·        Do not attribute internal reconnaissance or privileged resource access to GlobalProtect compromise without session linkage, suspicious VPN establishment evidence, abnormal account behavior, or incident-response validation.

·        Do not treat internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, or database activity as compromise evidence by itself.

Required Telemetry

·        Splunk indexes containing PAN-OS traffic logs.

·        Splunk indexes containing GlobalProtect session context.

·        Splunk indexes containing GlobalProtect tunnel-established events.

·        Splunk indexes containing internal DNS logs.

·        Splunk indexes containing firewall logs.

·        Splunk indexes containing internal segmentation telemetry where available.

·        Splunk indexes containing endpoint telemetry where available.

·        Splunk indexes containing EDR telemetry where available.

·        Splunk indexes containing identity logs where available.

·        Splunk indexes containing LDAP logs where available.

·        Splunk indexes containing Kerberos logs where available.

·        Splunk indexes containing SMB telemetry where available.

·        Splunk indexes containing RDP telemetry where available.

·        Splunk indexes containing SSH telemetry where available.

·        Splunk indexes containing WinRM telemetry where available.

·        Splunk indexes containing WMI telemetry where available.

·        Splunk indexes containing database access logs where available.

·        User identity, device identity, source IP, gateway, session identifier, tunnel identifier, source zone, destination zone, destination asset, application, protocol, port, bytes, duration, and timestamp where available.

·        Asset criticality inventory.

·        Privileged resource inventory.

·        Identity infrastructure inventory.

·        Domain controller inventory.

·        Jump-host inventory.

·        Management-plane inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory where available.

·        Normal VPN user behavior baselines.

·        Normal internal resource access baselines.

·        Approved administrator workflow records.

·        Approved helpdesk records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Splunk index names, sourcetypes, CIM mappings, Network Traffic data model mappings, Authentication data model mappings, Endpoint data model mappings, field aliases, lookups, macros, and data-model acceleration before production use.

·        Build VPN session correlation using GlobalProtect tunnel-established events, remote-access sessions, gateway context, tunnel identifiers, session identifiers, source IPs, users, devices, and gateway assignments.

·        Build internal resource lookups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, and high-value business applications.

·        Build internal protocol groups for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S internal, file-share, and administrative protocol activity.

·        Build suspicious behavior logic for first-seen destinations, rare user-to-destination pairs, rare services for the user, destination diversity, administrative protocol use, failed authentication bursts, credential validation, share enumeration, cross-segment access, and access outside the account’s normal role.

·        Build session-risk enrichment for authentication-lineage gaps, missing identity evidence, source novelty, gateway sequencing anomalies, privileged account use, third-party account use, low-frequency VPN use, unknown patch posture, and suspicious portal or gateway behavior.

·        Validate whether Splunk telemetry can reliably join on user, device, source IP, gateway, session identifier, tunnel identifier, destination asset, timestamp, and account context.

·        Use short correlation windows for internal access immediately after suspicious VPN session establishment.

·        Use moderate correlation windows for delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Use longer correlation windows when suspicious VPN access is followed by delayed endpoint telemetry, identity telemetry, cloud access, SaaS access, or incident-response evidence.

·        Add severity weighting for identity-service access, domain controller access, privileged management access, administrative protocol use, sensitive application access, destination novelty, account sensitivity, and session-risk context.

·        Treat internal access anomalies as confidence amplifiers, not standalone proof of GlobalProtect compromise.

·        Use approved administrator records, helpdesk records, vendor records, vulnerability management records, security-testing records, maintenance windows, software deployment records, backup schedules, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indexes, sourcetypes, field mappings, lookups, macros, timing windows, enrichment fields, exception logic, parser behavior, and join logic before production deployment.

·        Do not enable alert mode until session linkage, field availability, asset inventory, resource baselines, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to durable trusted-session misuse and post-session internal access behavior rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or request paths.

·        The rule remains useful if an adversary changes initial exploit mechanics, source infrastructure, VPN client attributes, gateway selection, timing, internal destination order, or post-session access sequence.

·        The score is supported by the durability of VPN-authenticated internal reconnaissance, identity-service access, administrative protocol use, privileged resource access, and access outside normal user baselines.

·        The score is constrained by split-tunnel visibility, incomplete internal network telemetry, weak asset inventory, NAT, SASE routing, incomplete VPN session mapping, legitimate administrator or vendor workflows, and local Splunk field quality.

·        The rule is durable as a trusted-session misuse detector but should not be treated as standalone proof of authentication bypass, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, internal network visibility, DNS coverage, asset inventory, privileged resource inventory, user baselines, account enrichment, and Splunk correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, ZTNA overlays, endpoint-only access paths, incomplete internal telemetry, or weak session identifiers prevent reliable linkage between VPN sessions and internal access.

·        Operational confidence is reduced where administrators, engineers, helpdesk users, vulnerability management tools, security testing, incident response, or third-party support commonly access privileged systems through VPN.

·        Full-telemetry confidence improves when VPN session context is enriched with endpoint telemetry, EDR telemetry, identity logs, firewall logs, DNS logs, internal resource telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

This rule detects suspicious VPN-authenticated internal behavior, not authentication bypass by itself.

Splunk may not observe endpoint process execution, user intent, credential theft, token theft, file activity, or exact authentication state unless relevant sources are ingested and correlated.

Split tunneling, SASE routing, ZTNA overlays, proxy paths, endpoint-only telemetry, NAT, carrier-grade NAT, and mobile networks may reduce visibility or attribution.

Legitimate administrator, helpdesk, engineering, security testing, vulnerability management, incident-response, vendor-support, and software-deployment workflows can produce similar behavior.

The rule may miss low-and-slow activity that remains within the user’s normal access profile or uses expected internal resources.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk SPL correlation pattern requiring index validation, sourcetype validation, CIM mapping validation, VPN session validation, internal destination validation, privileged-resource lookup validation, user-baseline validation, session-linkage validation, timing-window tuning, and environment-specific allowlisting before production deployment.

index=<panos_or_globalprotect_index> sourcetype=<globalprotect_or_panos_sourcetype>
(
event_type="GlobalProtect Tunnel Established"
OR event_type="VPN Session Established"
OR event_type="Remote Access Session Established"
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| eval gp_src=coalesce(src_ip, source_ip, client_ip)
| eval gp_session=coalesce(session_id, tunnel_id, gp_session_id)
| lookup vpn_session_risk_lookup gp_user gp_session OUTPUT session_risk_context
| lookup vpn_user_risk_lookup gp_user OUTPUT account_risk, privilege_level, vpn_frequency
| join type=inner gp_user [
search index=<network_or_dns_or_firewall_index> sourcetype=<internal_network_sourcetype>
(
app IN ("dns","ldap","kerberos","smb","rdp","ssh","winrm","wmi","database")
OR dest_port IN (53,88,135,139,389,445,3389,5985,5986)
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| lookup privileged_resource_lookup dest OUTPUT resource_type, criticality
| lookup user_internal_access_baseline gp_user dest OUTPUT baseline_status
| eval internal_suspicious=if(
criticality IN ("high","critical")
OR resource_type IN ("domain_controller","identity_infrastructure","jump_host","privileged_management","backup_system","endpoint_management","source_code","cicd","sensitive_file_share")
OR baseline_status IN ("first_seen","rare_for_user","outside_user_role"),
1, 0
)
| stats earliest(_time) as first_internal_time values(app) as apps values(dest) as internal_dests values(resource_type) as resource_types values(criticality) as criticalities by gp_user
]
| where internal_suspicious=1 OR session_risk_context IN ("authentication_lineage_gap","portal_to_gateway_sequence_gap","source_not_in_user_baseline","privileged_account_vpn_use","low_frequency_vpn_user")
| lookup approved_admin_activity gp_user internal_dests OUTPUT approval_context
| where isnull(approval_context)
| table time gpuser gp_src gp_session session_risk_context account_risk internal_dests resource_types criticalities apps first_internal_time

Rule

GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity

Rule Format

Splunk multi-source VPN-to-control-plane correlation rule suitable for PAN-OS logs, GlobalProtect session context, DNS logs, proxy logs, secure web gateway logs, identity-provider logs, cloud audit logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, endpoint telemetry, account enrichment, destination enrichment, and SIEM correlation after index validation, sourcetype validation, CIM mapping validation, VPN-to-cloud linkage validation, identity-linkage validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect cloud, SaaS, developer-platform, source-code, CI/CD, or control-plane activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Identify downstream control-plane exposure after trusted VPN session compromise without treating cloud, SaaS, or developer-platform anomalies as standalone evidence of GlobalProtect compromise.

·        Prioritize activity involving privileged cloud roles, administrative SaaS actions, source-code access, CI/CD changes, application credential changes, token use, access-key activity, repository access, or security-control modification.

·        Support escalation when suspicious VPN access is followed by cloud, SaaS, identity, or developer-platform behavior inconsistent with the account’s normal role, device history, source path, or access baseline.

·        Preserve separation between suspicious VPN-linked downstream activity and confirmed cloud or SaaS compromise by requiring additional identity, cloud, SaaS, endpoint, file, persistence, credential-access, token-access, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, cloud compromise, SaaS compromise, developer-platform compromise, token theft, credential theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious or high-risk GlobalProtect VPN session establishment involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or internal follow-on activity.

·        Correlate the VPN session window with cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane access by the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Prioritize downstream actions involving privileged role access, administrative console access, IAM changes, MFA changes, conditional-access changes, application consent changes, API token creation, access-key creation, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, security-control changes, or data export.

·        Increase confidence when downstream access occurs from the same source IP, same device, same user, same VPN session window, same authentication session, same identity-provider session, or same incident sequence as the suspicious VPN session.

·        Increase confidence when downstream activity is rare for the user, new for the device, outside normal access windows, directed at sensitive tenants, directed at privileged applications, or inconsistent with the account’s role.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, unusual session creation, suspicious OAuth consent, CLI usage, API activity, or post-session administrative behavior.

·        Reduce severity when downstream activity aligns with approved administrator workflows, cloud operations, SaaS administration, developer workflows, CI/CD maintenance, incident response, vendor support, security testing, or documented change-control activity.

·        Do not attribute cloud, SaaS, identity, developer-platform, source-code, or CI/CD anomalies to GlobalProtect compromise without VPN session linkage, source path linkage, identity linkage, device linkage, or incident-response validation.

·        Do not treat cloud or SaaS anomalies as compromise evidence by themselves.

Required Telemetry

·        Splunk indexes containing GlobalProtect tunnel-established events.

·        Splunk indexes containing PAN-OS traffic logs.

·        Splunk indexes containing GlobalProtect session context.

·        Splunk indexes containing DNS logs.

·        Splunk indexes containing proxy logs where available.

·        Splunk indexes containing secure web gateway logs where available.

·        Splunk indexes containing identity-provider logs.

·        Splunk indexes containing cloud audit logs where available.

·        Splunk indexes containing SaaS logs where available.

·        Splunk indexes containing developer-platform logs where available.

·        Splunk indexes containing source-code platform logs where available.

·        Splunk indexes containing CI/CD platform logs where available.

·        Splunk indexes containing endpoint telemetry where available.

·        User identity, device identity, source IP, VPN gateway, session identifier, tunnel identifier, identity-provider session, destination domain, application, protocol, timestamp, action, and result where available.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Approved administrator workflow records.

·        Approved developer workflow records.

·        Approved cloud operations records.

·        Approved SaaS administration records.

·        Approved CI/CD maintenance records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Splunk index names, sourcetypes, CIM mappings, Cloud data model mappings where available, Authentication data model mappings, Endpoint data model mappings, field aliases, lookups, macros, and data-model acceleration before production use.

·        Build suspicious VPN session lookups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, suspicious portal behavior, suspicious gateway behavior, and internal follow-on activity.

·        Build cloud and SaaS destination lookups covering cloud consoles, cloud APIs, identity administration portals, SaaS administration portals, developer platforms, source-code platforms, CI/CD platforms, application management portals, and privileged business applications.

·        Build control-plane action groups for IAM changes, role assignment, access-key creation, API token creation, service-account use, application consent changes, MFA changes, conditional-access changes, repository access, repository cloning, CI/CD workflow modification, secret access, audit-log access, security-control changes, and data export.

·        Build linkage logic using user identity, device identity, source IP, VPN session window, tunnel identifier, gateway, identity-provider session, authentication session, destination application, and incident timeline.

·        Build downstream-risk logic for rare user activity, first-seen destination, privileged role use, sensitive tenant access, sensitive repository access, unusual API activity, source path mismatch, device mismatch, access outside normal windows, and activity outside expected role.

·        Validate whether Splunk telemetry can reliably join on user, device, source IP, session window, destination, application, action, and timestamp.

·        Use short correlation windows when cloud, SaaS, or developer-platform activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed administrative activity, repository access, token use, CI/CD activity, source-code access, or cloud API activity after suspicious VPN establishment.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, or session continuity supports delayed linkage.

·        Add severity weighting for privileged role access, sensitive tenant access, source-code access, CI/CD access, application credential changes, access-key creation, token activity, security-control changes, data export, and verified VPN session linkage.

·        Treat downstream cloud, SaaS, identity, source-code, and CI/CD anomalies as investigative leads unless linked to suspicious VPN session evidence.

·        Use approved administrator records, cloud operations records, SaaS administration records, developer workflow records, CI/CD maintenance records, vendor-support records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indexes, sourcetypes, field mappings, lookups, macros, timing windows, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, destination validation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked downstream control-plane activity rather than static exploit strings, CVE identifiers, source IPs, domains, user-agent values, or isolated cloud anomalies.

·        The rule remains useful if an adversary changes cloud service, SaaS target, developer platform, API sequence, access method, source infrastructure, token use pattern, or post-session timing.

·        The score is supported by the durability of suspicious VPN session linkage, privileged cloud or SaaS action, developer-platform access, source-code access, CI/CD interaction, and control-plane behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-cloud linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, device mismatch, incomplete SaaS or developer-platform logs, and local Splunk field quality.

·        The rule is durable as downstream exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or cloud compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, identity-provider logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, DNS or proxy visibility, source enrichment, and Splunk correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, cloud session reuse, token reuse, identity federation, source IP changes, or inconsistent device identifiers make VPN-to-cloud linkage uncertain.

·        Operational confidence is reduced where administrators, developers, cloud engineers, SaaS administrators, DevOps teams, vendors, or incident responders commonly perform control-plane actions after VPN access.

·        Full-telemetry confidence improves when cloud, SaaS, and developer-platform events are enriched with VPN session evidence, identity-provider session context, endpoint telemetry, source path evidence, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious downstream control-plane activity linked to suspicious VPN sessions, not authentication bypass or cloud compromise by itself.

Splunk may not observe full cloud action contents, SaaS administrative context, token origin, browser session context, device posture, or endpoint process execution unless those sources are ingested and normalized.

Cloud, SaaS, identity, source-code, and CI/CD activity may be legitimate for administrators, developers, cloud engineers, DevOps staff, vendors, or incident responders.

VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, or source IP transformation obscures path attribution.

The rule may miss downstream abuse that occurs outside the correlation window, from reused tokens, from a different device, from a different source path, or through a pre-existing cloud session.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk SPL correlation pattern requiring index validation, sourcetype validation, identity-linkage validation, source-path validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific allowlisting before production deployment.

index=<panos_or_globalprotect_index> sourcetype=<globalprotect_or_panos_sourcetype>
(
event_type="GlobalProtect Tunnel Established"
OR event_type="VPN Session Established"
OR event_type="Remote Access Session Established"
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| eval gp_src=coalesce(src_ip, source_ip, client_ip)
| eval gp_device=coalesce(device_id, endpoint_id, host, hostname)
| eval gp_session=coalesce(session_id, tunnel_id, gp_session_id)
| lookup vpn_session_risk_lookup gp_user gp_session OUTPUT session_risk_context
| where session_risk_context IN ("authentication_lineage_gap","portal_to_gateway_sequence_gap","missing_identity_provider_evidence","missing_mfa_evidence","missing_hip_evidence","unexpected_gateway_assignment","source_not_in_user_baseline","privileged_account_vpn_use","third_party_account_vpn_use","low_frequency_vpn_user","suspicious_internal_followon_activity")
| join type=inner gp_user [
search index=<cloud_or_saas_or_developer_platform_index> sourcetype=<cloud_saas_dev_sourcetype>
(
action IN ("IAM Change","Role Assignment","Access Key Created","API Token Created","Service Account Used","Application Consent Changed","MFA Changed","Conditional Access Changed","Repository Accessed","Repository Cloned","CI/CD Workflow Modified","Secret Accessed","Audit Log Accessed","Security Control Changed","Data Exported")
OR activity_pattern IN ("rare_user_activity","first_seen_destination","privileged_role_use","sensitive_tenant_access","sensitive_repository_access","unusual_api_activity","source_path_mismatch","device_mismatch","outside_normal_access_window","activity_outside_expected_role")
)
| eval gp_user=coalesce(user, src_user, username, user_principal_name)
| eval control_src=coalesce(src_ip, source_ip, client_ip)
| lookup approved_control_plane_activity gp_user action OUTPUT approval_context
| where isnull(approval_context)
| stats earliest(_time) as first_control_time values(action) as actions values(activity_pattern) as activity_patterns values(dest) as control_dests values(control_src) as control_sources by gp_user
]
| table time gpuser gp_src gp_device gp_session session_risk_context actions activity_patterns control_dests control_sources first_control_time

Elastic

Detection Viability Assessment

Elastic has three rules for this EXP report.

·        Elastic is viable for detecting GlobalProtect authentication-lineage failure, portal-to-gateway sequencing gaps, trusted VPN session establishment, VPN-authenticated internal access, and downstream cloud or SaaS activity when PAN-OS, GlobalProtect, identity-provider, MFA, HIP, endpoint, network, DNS, cloud, SaaS, and enrichment telemetry are ingested into Elastic.

·        Elastic is strongest where Elastic Agent, Beats, integrations, ECS-normalized firewall logs, PAN-OS logs, GlobalProtect logs, identity-provider logs, MFA logs, endpoint telemetry, DNS logs, internal network telemetry, cloud audit logs, SaaS logs, asset inventory, account enrichment, and source enrichment can be correlated.

·        Elastic can support durable behavioral detection by correlating tunnel establishment, missing or inconsistent authentication-lineage evidence, source novelty, gateway-assignment anomalies, account sensitivity, internal reconnaissance, privileged protocol use, endpoint behavior, and downstream control-plane activity.

·        Elastic is not a standalone source for confirming successful exploitation, authentication bypass, identity-provider bypass, MFA bypass, HIP bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution unless the required telemetry is present, normalized, and correlated.

·        Elastic detections must account for ingestion delay, ECS mapping gaps, parser issues, timestamp skew, provider outage, log-retention limits, NAT, carrier-grade NAT, SASE routing, split tunneling, missing session identifiers, and inconsistent field mappings before escalating missing authentication-lineage evidence.

·        Elastic rules should be treated as implementation-ready behavioral patterns requiring local index, data stream, ECS field, ingest pipeline, enrichment, exception, threshold, and correlation-window validation before production deployment.

·        Elastic rules should not generate high-confidence alerting from vulnerable version posture alone, source novelty alone, tunnel establishment alone, missing identity evidence alone, endpoint alerting alone, internal discovery alone, cloud access alone, SaaS activity alone, or developer-platform activity alone.

Rule

GlobalProtect Tunnel Establishment With Missing Authentication-Lineage Evidence

Rule Format

Elastic EQL / KQL behavioral correlation rule suitable for ECS-normalized PAN-OS logs, GlobalProtect portal logs, GlobalProtect gateway logs, tunnel-established events, gateway-assignment events, HIP results, identity-provider logs, MFA logs, SAML or OIDC context, certificate validation context, endpoint enrichment, source enrichment, account enrichment, asset inventory, and Elastic Security correlation after index validation, data-stream validation, ECS mapping validation, ingest-pipeline validation, field validation, telemetry-completeness validation, timing-window tuning, and environment-specific exception handling.

Detection Purpose

·        Detect GlobalProtect tunnel-established events where expected authentication-lineage evidence is absent, incomplete, delayed, mismatched, or inconsistent after telemetry completeness has been validated.

·        Identify potential authentication-lineage failure, portal-to-gateway sequencing gap, unauthorized VPN session establishment, or trusted remote-access session compromise.

·        Prioritize tunnel establishment involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Support escalation when suspicious tunnel establishment occurs from unfamiliar infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, mobile carrier networks, residential proxy infrastructure, SASE egress points, or sources inconsistent with the user’s access history.

·        Preserve separation between suspicious VPN session establishment and confirmed compromise by requiring supporting GlobalProtect, identity, MFA, HIP, endpoint, internal network, cloud, SaaS, or incident-response evidence before classifying the activity as probable compromise.

·        This rule does not prove CVE-2026-0257 exploitation, authentication bypass, identity-provider bypass, MFA bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify GlobalProtect tunnel-established or VPN session establishment events from validated PAN-OS or GlobalProtect Elastic indices, data streams, or integrations.

·        Correlate tunnel establishment with expected precursor events, including portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion validation, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, and gateway authentication.

·        Prioritize tunnel establishment where expected precursor evidence is absent, incomplete, delayed, mismatched, or inconsistent after ingestion delay, timestamp alignment, parser quality, log retention, ECS field mapping, and join reliability have been validated.

·        Prioritize mismatches involving username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, gateway name, portal name, timestamp, client version, operating-system profile, HIP result, certificate context, authentication-cookie context, or session-token context.

·        Increase confidence when the account is privileged, administrative, security-related, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, rarely used for VPN, or associated with sensitive access.

·        Increase confidence when source infrastructure is newly observed, rare for the user, rare for the environment, associated with hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, unusual geographies, or ASNs not normally associated with the account.

·        Increase confidence when tunnel establishment is followed by internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, or administrative-protocol activity.

·        Reduce severity when behavior aligns with approved travel, mobile carrier use, regional gateway failover, SASE routing, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, incident response, or documented change-control activity.

·        Do not classify missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence as bypass until telemetry delay, ingestion gaps, provider outage, parser failure, retention limits, timestamp skew, ECS mapping failure, and local join failure have been reviewed.

·        Do not treat tunnel establishment, source novelty, gateway change, vulnerable version posture, or missing telemetry as compromise evidence by itself.

Required Telemetry

·        Elastic indices or data streams containing PAN-OS traffic logs.

·        Elastic indices or data streams containing PAN-OS system logs.

·        Elastic indices or data streams containing PAN-OS authentication logs.

·        Elastic indices or data streams containing PAN-OS configuration logs where available.

·        Elastic indices or data streams containing GlobalProtect portal logs.

·        Elastic indices or data streams containing GlobalProtect gateway logs.

·        Elastic indices or data streams containing GlobalProtect authentication events.

·        Elastic indices or data streams containing GlobalProtect tunnel-established events.

·        Elastic indices or data streams containing GlobalProtect client configuration retrieval events where available.

·        Elastic indices or data streams containing GlobalProtect gateway-assignment events where available.

·        Elastic indices or data streams containing GlobalProtect session-state events.

·        Elastic indices or data streams containing HIP match results where available.

·        Elastic indices or data streams containing HIP report results where available.

·        Authentication-cookie context where available.

·        Session-token context where available.

·        Identity-provider logs.

·        SAML or OIDC assertion context.

·        MFA logs.

·        Conditional-access logs where available.

·        Certificate validation context where available.

·        Device-compliance or posture context where available.

·        DNS logs where available.

·        Endpoint telemetry where available.

·        Source enrichment for IP, ASN, geography, reputation, network type, hosting provider, first-seen timestamp, and source history.

·        Account enrichment for username, user principal name, account type, privilege level, business unit, account status, and VPN usage frequency.

·        GlobalProtect enrichment for portal name, gateway name, gateway region, client version, operating-system profile, session identifier, tunnel identifier, and timestamp.

·        Asset inventory.

·        Gateway inventory.

·        VPN user inventory.

·        Privileged account inventory.

·        Third-party access inventory.

·        Approved remote-access source baselines.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Elastic index names, data streams, ECS mappings, ingest pipelines, field aliases, event categories, event actions, event datasets, rule exceptions, enrich policies, transform jobs, and correlation behavior before production use.

·        Build normalized GlobalProtect event groups for portal request, portal authentication, identity-provider authentication, MFA decision, SAML assertion, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, reconnect, disconnect, and session state.

·        Build authentication-lineage correlation logic that evaluates whether expected precursor events occur before tunnel establishment within locally validated timing windows.

·        Build mismatch logic for username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, authentication cookie, session token, gateway name, portal name, client version, operating-system profile, HIP result, certificate context, and timestamp.

·        Build source-risk enrichment for newly observed sources, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, proxy infrastructure, low-reputation sources, and sources inconsistent with user history.

·        Build account-risk enrichment for privileged users, administrators, security staff, remote-access administrators, third-party accounts, contractor accounts, service-adjacent accounts, dormant accounts, stale accounts, recently re-enabled accounts, low-frequency VPN users, and users with sensitive access.

·        Build internal follow-on correlation for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, and administrative-protocol activity after tunnel establishment.

·        Use short correlation windows for expected portal-to-gateway authentication sequencing and tunnel establishment.

·        Use moderate correlation windows for delayed identity-provider evidence, delayed MFA evidence, HIP log delay, gateway-assignment lag, and session-state reconciliation.

·        Use longer correlation windows for delayed internal access, repeated short VPN sessions, recurring source infrastructure, or low-and-slow post-session activity.

·        Add severity weighting for privileged account use, missing authentication-lineage evidence after telemetry completeness validation, gateway-sequencing anomalies, suspicious source infrastructure, vulnerable or unknown patch posture, unfamiliar device context, and internal follow-on activity.

·        Treat source novelty, gateway changes, missing telemetry, HIP mismatch, or tunnel establishment as confidence amplifiers, not standalone compromise criteria.

·        Use approved travel records, vendor records, SASE routing changes, gateway maintenance records, identity-provider maintenance records, VPN client upgrade records, helpdesk records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indices, data streams, ECS fields, ingest pipelines, enrichment sources, exception lists, rule schedules, lookback windows, correlation windows, parser behavior, and local schema mappings before production deployment.

·        Do not enable alert mode until field availability, correlation reliability, telemetry completeness, false-positive rate, rule performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to durable authentication-lineage and portal-to-gateway sequencing gaps rather than static CVE strings, known exploit strings, source IPs, user-agent values, request paths, or payload indicators.

·        The rule remains useful if an adversary changes source infrastructure, timing, client version, user-agent, portal interaction pattern, gateway interaction pattern, authentication artifact usage, or post-session activity.

·        The score is supported by the durability of tunnel establishment without expected precursor evidence, gateway sequencing anomalies, identity-provider mismatch, MFA mismatch, HIP mismatch, session-state inconsistency, source novelty, and internal follow-on behavior.

·        The score is constrained by missing GlobalProtect logs, incomplete HIP logs, identity-provider logging gaps, MFA telemetry gaps, split-tunnel visibility limits, timestamp skew, NAT, carrier-grade NAT, SASE routing, inconsistent session identifiers, and local Elastic mapping quality.

·        The rule is durable as a SIEM correlation detector but should not be treated as standalone proof of authentication bypass, exploit success, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on GlobalProtect portal logs, gateway logs, tunnel-established events, HIP results, gateway-assignment context, identity-provider logs, MFA logs, reliable session identifiers, source enrichment, account enrichment, and Elastic correlation quality.

·        Operational confidence is reduced where identity-provider evidence is delayed, MFA logs are incomplete, HIP events are missing, authentication cookies are unavailable, session-token context is unavailable, or tunnel events cannot be reliably joined to portal and gateway events.

·        Operational confidence is reduced where split-tunnel routing, SASE egress, carrier-grade NAT, mobile networks, regional gateway failover, third-party access, or VPN client upgrades create legitimate source or sequencing changes.

·        Full-telemetry confidence improves when tunnel-established events are enriched with PAN-OS logs, GlobalProtect portal and gateway logs, HIP logs, identity-provider logs, MFA logs, endpoint telemetry, DNS logs, internal network telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation or actor attribution.

Limitations

This rule detects suspicious GlobalProtect authentication-lineage or portal-to-gateway sequencing behavior, not confirmed exploitation by itself.

Elastic may not contain identity-provider session state, MFA decision details, SAML assertion contents, authentication cookie contents, session-token contents, HIP report contents, or endpoint posture results unless those sources are ingested and normalized.

Missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence may reflect telemetry delay, ingestion failure, retention limits, parser failure, provider outage, timestamp skew, or Elastic field-mapping issues rather than successful bypass.

Legitimate travel, mobile carrier use, SASE routing, regional gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, and incident response can create similar patterns.

The rule may miss bypass activity where attackers produce apparently complete authentication-lineage artifacts, use valid credentials, abuse legitimate session material, or operate within normal user source and device patterns.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic EQL / KQL correlation pattern requiring index validation, data-stream validation, ECS mapping validation, GlobalProtect event validation, identity-provider join validation, MFA join validation, HIP join validation, timing-window tuning, telemetry-completeness validation, and environment-specific exception handling before production deployment.

sequence by user.name with maxspan=30m
[any where event.action in ("globalprotect_tunnel_established", "vpn_session_established", "gateway_tunnel_established", "remote_access_session_established")
and destination.domain in ("globalprotect_portals", "globalprotect_gateways", "panos_remote_access_infrastructure")
and (
user.risk.name in ("privileged_account", "administrative_account", "third_party_account", "contractor_account", "service_adjacent_account", "dormant_account", "stale_account", "recently_reenabled_account", "low_frequency_vpn_user")
or source.risk.name in ("newly_observed_source", "rare_asn", "unusual_geography", "hosting_provider_source", "anonymization_service", "residential_proxy_infrastructure", "mobile_carrier_network", "sase_egress_source", "source_not_in_user_baseline")
or event.risk.name in ("unexpected_gateway_assignment", "missing_portal_precursor", "missing_gateway_precursor", "missing_client_config_retrieval", "portal_to_gateway_sequence_gap", "tunnel_without_expected_identity_evidence", "session_identifier_mismatch", "authentication_cookie_inconsistency", "session_token_inconsistency", "hip_result_inconsistency")
)
]
until [any where event.action in ("approved_travel", "approved_vendor_access", "approved_sase_routing_change", "approved_gateway_maintenance", "approved_identity_provider_maintenance", "approved_vpn_client_upgrade", "approved_security_testing", "approved_incident_response")]

Supplemental KQL condition:

event.module:("panw" or "globalprotect") and event.action:("globalprotect_tunnel_established" or "vpn_session_established") and cyberdax.telemetry_completeness.validated:true and not cyberdax.authentication_lineage.expected_evidence_present:true

Rule

GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access

Rule Format

Elastic EQL / KQL VPN follow-on correlation rule suitable for ECS-normalized PAN-OS traffic logs, GlobalProtect session context, internal DNS logs, firewall logs, endpoint telemetry, identity logs, asset inventory, privileged-resource enrichment, account enrichment, network telemetry, and Elastic Security correlation after index validation, data-stream validation, ECS mapping validation, VPN session mapping, internal destination validation, privileged-resource validation, baseline validation, timing-window tuning, and environment-specific exception handling.

Detection Purpose

·        Detect suspicious internal activity following GlobalProtect VPN session establishment where the VPN-connected account accesses identity services, privileged resources, administrative protocols, sensitive applications, or systems inconsistent with normal behavior.

·        Identify trusted VPN session misuse after suspicious session establishment, authentication-lineage inconsistency, source infrastructure novelty, gateway-sequencing anomaly, or high-risk account use.

·        Prioritize VPN-authenticated internal reconnaissance, credential validation, identity-service access, administrative protocol use, jump-host access, management-plane access, and sensitive resource access.

·        Support escalation when VPN session activity leads to LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database access, file-share enumeration, administrative share access, privileged management access, or access outside the user’s normal role.

·        Preserve separation between suspicious trusted-session use and confirmed compromise by requiring additional endpoint, identity, cloud, SaaS, file, persistence, credential-access, token-access, or incident-response evidence before classifying downstream compromise as confirmed.

·        This rule does not prove authentication bypass, exploit success, credential theft, endpoint compromise, cloud compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify GlobalProtect VPN session establishment or remote-access session activity for a user, device, source IP, gateway, tunnel identifier, or session identifier.

·        Prioritize sessions associated with authentication-lineage gaps, source infrastructure novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency VPN use, vulnerable or unknown patch posture, or suspicious GlobalProtect portal or gateway behavior.

·        Detect internal network activity after VPN establishment involving DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, internal web application, or administrative-protocol traffic.

·        Prioritize internal access to domain controllers, identity infrastructure, privileged management systems, firewall management interfaces, VPN administration interfaces, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        Increase confidence when activity involves many internal destinations, rare services for the user, first-seen internal destinations, administrative protocols, repeated authentication attempts, failed internal logons, credential validation, share enumeration, or access outside the user’s normal role.

·        Increase confidence when internal activity begins shortly after suspicious VPN session establishment, follows repeated short sessions, follows reconnect behavior, follows unusual gateway assignment, or appears after delayed low-and-slow access.

·        Increase confidence when endpoint telemetry from internal systems shows process execution, remote administration tooling, suspicious child processes, tool staging, credential-access behavior, or outbound follow-on from systems reached through the VPN session.

·        Reduce severity when activity matches approved administrator duties, helpdesk activity, engineering workflows, vulnerability management, security testing, incident response, scheduled maintenance, backup activity, software deployment, or documented third-party support.

·        Do not attribute internal reconnaissance or privileged resource access to GlobalProtect compromise without session linkage, suspicious VPN establishment evidence, abnormal account behavior, or incident-response validation.

·        Do not treat internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, or database activity as compromise evidence by itself.

Required Telemetry

·        Elastic indices or data streams containing PAN-OS traffic logs.

·        Elastic indices or data streams containing GlobalProtect session context.

·        Elastic indices or data streams containing GlobalProtect tunnel-established events.

·        Elastic indices or data streams containing internal DNS logs.

·        Elastic indices or data streams containing firewall logs.

·        Elastic indices or data streams containing internal segmentation telemetry where available.

·        Elastic indices or data streams containing endpoint telemetry where available.

·        Elastic indices or data streams containing EDR telemetry where available.

·        Elastic indices or data streams containing identity logs where available.

·        Elastic indices or data streams containing LDAP logs where available.

·        Elastic indices or data streams containing Kerberos logs where available.

·        Elastic indices or data streams containing SMB telemetry where available.

·        Elastic indices or data streams containing RDP telemetry where available.

·        Elastic indices or data streams containing SSH telemetry where available.

·        Elastic indices or data streams containing WinRM telemetry where available.

·        Elastic indices or data streams containing WMI telemetry where available.

·        Elastic indices or data streams containing database access logs where available.

·        User identity, device identity, source IP, gateway, session identifier, tunnel identifier, source zone, destination zone, destination asset, application, protocol, port, bytes, duration, and timestamp where available.

·        Asset criticality inventory.

·        Privileged resource inventory.

·        Identity infrastructure inventory.

·        Domain controller inventory.

·        Jump-host inventory.

·        Management-plane inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory where available.

·        Normal VPN user behavior baselines.

·        Normal internal resource access baselines.

·        Approved administrator workflow records.

·        Approved helpdesk records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Elastic index names, data streams, ECS mappings, Network event mappings, Authentication event mappings, Endpoint event mappings, field aliases, enrich policies, exception lists, rule schedules, lookback windows, and correlation behavior before production use.

·        Build VPN session correlation using GlobalProtect tunnel-established events, remote-access sessions, gateway context, tunnel identifiers, session identifiers, source IPs, users, devices, and gateway assignments.

·        Build internal resource enrichment covering identity infrastructure, domain controllers, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, and high-value business applications.

·        Build internal protocol groups for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S internal, file-share, and administrative protocol activity.

·        Build suspicious behavior logic for first-seen destinations, rare user-to-destination pairs, rare services for the user, destination diversity, administrative protocol use, failed authentication bursts, credential validation, share enumeration, cross-segment access, and access outside the account’s normal role.

·        Build session-risk enrichment for authentication-lineage gaps, missing identity evidence, source novelty, gateway sequencing anomalies, privileged account use, third-party account use, low-frequency VPN use, unknown patch posture, and suspicious portal or gateway behavior.

·        Validate whether Elastic telemetry can reliably join on user, device, source IP, gateway, session identifier, tunnel identifier, destination asset, timestamp, and account context.

·        Use short correlation windows for internal access immediately after suspicious VPN session establishment.

·        Use moderate correlation windows for delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Use longer correlation windows when suspicious VPN access is followed by delayed endpoint telemetry, identity telemetry, cloud access, SaaS access, or incident-response evidence.

·        Add severity weighting for identity-service access, domain controller access, privileged management access, administrative protocol use, sensitive application access, destination novelty, account sensitivity, and session-risk context.

·        Treat internal access anomalies as confidence amplifiers, not standalone proof of GlobalProtect compromise.

·        Use approved administrator records, helpdesk records, vendor records, vulnerability management records, security-testing records, maintenance windows, software deployment records, backup schedules, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indices, data streams, ECS fields, ingest pipelines, enrich policies, exception lists, rule schedules, lookback windows, correlation windows, parser behavior, and local schema mappings before production deployment.

·        Do not enable alert mode until session linkage, field availability, asset inventory, resource baselines, false-positive rate, rule performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to durable trusted-session misuse and post-session internal access behavior rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or request paths.

·        The rule remains useful if an adversary changes initial exploit mechanics, source infrastructure, VPN client attributes, gateway selection, timing, internal destination order, or post-session access sequence.

·        The score is supported by the durability of VPN-authenticated internal reconnaissance, identity-service access, administrative protocol use, privileged resource access, and access outside normal user baselines.

·        The score is constrained by split-tunnel visibility, incomplete internal network telemetry, weak asset inventory, NAT, SASE routing, incomplete VPN session mapping, legitimate administrator or vendor workflows, and local Elastic field quality.

·        The rule is durable as a trusted-session misuse detector but should not be treated as standalone proof of authentication bypass, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, internal network visibility, DNS coverage, asset inventory, privileged resource inventory, user baselines, account enrichment, and Elastic correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, ZTNA overlays, endpoint-only access paths, incomplete internal telemetry, or weak session identifiers prevent reliable linkage between VPN sessions and internal access.

·        Operational confidence is reduced where administrators, engineers, helpdesk users, vulnerability management tools, security testing, incident response, or third-party support commonly access privileged systems through VPN.

·        Full-telemetry confidence improves when VPN session context is enriched with endpoint telemetry, EDR telemetry, identity logs, firewall logs, DNS logs, internal resource telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

This rule detects suspicious VPN-authenticated internal behavior, not authentication bypass by itself.

Elastic may not observe endpoint process execution, user intent, credential theft, token theft, file activity, or exact authentication state unless relevant sources are ingested and correlated.

Split tunneling, SASE routing, ZTNA overlays, proxy paths, endpoint-only telemetry, NAT, carrier-grade NAT, and mobile networks may reduce visibility or attribution.

Legitimate administrator, helpdesk, engineering, security testing, vulnerability management, incident-response, vendor-support, and software-deployment workflows can produce similar behavior.

The rule may miss low-and-slow activity that remains within the user’s normal access profile or uses expected internal resources.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic EQL / KQL correlation pattern requiring index validation, data-stream validation, ECS mapping validation, VPN session validation, internal destination validation, privileged-resource enrichment validation, user-baseline validation, session-linkage validation, timing-window tuning, and environment-specific exception handling before production deployment.

sequence by user.name with maxspan=2h
[any where event.action in ("globalprotect_tunnel_established", "vpn_session_established", "remote_access_session_established")
and user.risk.name in ("authentication_lineage_gap", "portal_to_gateway_sequence_gap", "source_not_in_user_baseline", "privileged_account_vpn_use", "low_frequency_vpn_user")
]
[network where network.direction in ("outbound", "internal")
and (
destination.port in (53, 88, 135, 139, 389, 445, 3389, 5985, 5986)
or network.application in ("dns", "ldap", "kerberos", "smb", "rdp", "ssh", "winrm", "wmi", "database")
or destination.risk.name in ("domain_controller", "identity_infrastructure", "jump_host", "privileged_management", "backup_system", "endpoint_management", "source_code", "cicd", "sensitive_file_share")
or event.risk.name in ("first_seen_internal_destination", "rare_user_to_destination_pair", "rare_service_for_user", "destination_diversity", "administrative_protocol_use", "failed_authentication_burst", "credential_validation_pattern", "share_enumeration", "cross_segment_access", "access_outside_user_role")
)
]

Supplemental KQL condition:

event.module:("panw" or "globalprotect" or "network") and cyberdax.vpn_session.risk:("authentication_lineage_gap" or "portal_to_gateway_sequence_gap" or "source_not_in_user_baseline" or "privileged_account_vpn_use" or "low_frequency_vpn_user") and cyberdax.internal_access.suspicious:true and not cyberdax.change_context.approved:true

Rule

GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity

Rule Format

Elastic EQL / KQL VPN-to-control-plane correlation rule suitable for ECS-normalized PAN-OS logs, GlobalProtect session context, DNS logs, proxy logs, secure web gateway logs, identity-provider logs, cloud audit logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, endpoint telemetry, account enrichment, destination enrichment, and Elastic Security correlation after index validation, data-stream validation, ECS mapping validation, VPN-to-cloud linkage validation, identity-linkage validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific exception handling.

Detection Purpose

·        Detect cloud, SaaS, developer-platform, source-code, CI/CD, or control-plane activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Identify downstream control-plane exposure after trusted VPN session compromise without treating cloud, SaaS, or developer-platform anomalies as standalone evidence of GlobalProtect compromise.

·        Prioritize activity involving privileged cloud roles, administrative SaaS actions, source-code access, CI/CD changes, application credential changes, token use, access-key activity, repository access, or security-control modification.

·        Support escalation when suspicious VPN access is followed by cloud, SaaS, identity, or developer-platform behavior inconsistent with the account’s normal role, device history, source path, or access baseline.

·        Preserve separation between suspicious VPN-linked downstream activity and confirmed cloud or SaaS compromise by requiring additional identity, cloud, SaaS, endpoint, file, persistence, credential-access, token-access, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, cloud compromise, SaaS compromise, developer-platform compromise, token theft, credential theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious or high-risk GlobalProtect VPN session establishment involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or internal follow-on activity.

·        Correlate the VPN session window with cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane access by the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Prioritize downstream actions involving privileged role access, administrative console access, IAM changes, MFA changes, conditional-access changes, application consent changes, API token creation, access-key creation, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, security-control changes, or data export.

·        Increase confidence when downstream access occurs from the same source IP, same device, same user, same VPN session window, same authentication session, same identity-provider session, or same incident sequence as the suspicious VPN session.

·        Increase confidence when downstream activity is rare for the user, new for the device, outside normal access windows, directed at sensitive tenants, directed at privileged applications, or inconsistent with the account’s role.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, unusual session creation, suspicious OAuth consent, CLI usage, API activity, or post-session administrative behavior.

·        Reduce severity when downstream activity aligns with approved administrator workflows, cloud operations, SaaS administration, developer workflows, CI/CD maintenance, incident response, vendor support, security testing, or documented change-control activity.

·        Do not attribute cloud, SaaS, identity, developer-platform, source-code, or CI/CD anomalies to GlobalProtect compromise without VPN session linkage, source path linkage, identity linkage, device linkage, or incident-response validation.

·        Do not treat cloud or SaaS anomalies as compromise evidence by themselves.

Required Telemetry

·        Elastic indices or data streams containing GlobalProtect tunnel-established events.

·        Elastic indices or data streams containing PAN-OS traffic logs.

·        Elastic indices or data streams containing GlobalProtect session context.

·        Elastic indices or data streams containing DNS logs.

·        Elastic indices or data streams containing proxy logs where available.

·        Elastic indices or data streams containing secure web gateway logs where available.

·        Elastic indices or data streams containing identity-provider logs.

·        Elastic indices or data streams containing cloud audit logs where available.

·        Elastic indices or data streams containing SaaS logs where available.

·        Elastic indices or data streams containing developer-platform logs where available.

·        Elastic indices or data streams containing source-code platform logs where available.

·        Elastic indices or data streams containing CI/CD platform logs where available.

·        Elastic indices or data streams containing endpoint telemetry where available.

·        User identity, device identity, source IP, VPN gateway, session identifier, tunnel identifier, identity-provider session, destination domain, application, protocol, timestamp, action, and result where available.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Approved administrator workflow records.

·        Approved developer workflow records.

·        Approved cloud operations records.

·        Approved SaaS administration records.

·        Approved CI/CD maintenance records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Validate local Elastic index names, data streams, ECS mappings, Cloud event mappings where available, Authentication event mappings, Endpoint event mappings, field aliases, enrich policies, exception lists, rule schedules, lookback windows, and correlation behavior before production use.

·        Build suspicious VPN session enrichment covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, suspicious portal behavior, suspicious gateway behavior, and internal follow-on activity.

·        Build cloud and SaaS destination enrichment covering cloud consoles, cloud APIs, identity administration portals, SaaS administration portals, developer platforms, source-code platforms, CI/CD platforms, application management portals, and privileged business applications.

·        Build control-plane action groups for IAM changes, role assignment, access-key creation, API token creation, service-account use, application consent changes, MFA changes, conditional-access changes, repository access, repository cloning, CI/CD workflow modification, secret access, audit-log access, security-control changes, and data export.

·        Build linkage logic using user identity, device identity, source IP, VPN session window, tunnel identifier, gateway, identity-provider session, authentication session, destination application, and incident timeline.

·        Build downstream-risk logic for rare user activity, first-seen destination, privileged role use, sensitive tenant access, sensitive repository access, unusual API activity, source path mismatch, device mismatch, access outside normal windows, and activity outside expected role.

·        Validate whether Elastic telemetry can reliably join on user, device, source IP, session window, destination, application, action, and timestamp.

·        Use short correlation windows when cloud, SaaS, or developer-platform activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed administrative activity, repository access, token use, CI/CD activity, source-code access, or cloud API activity after suspicious VPN establishment.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, or session continuity supports delayed linkage.

·        Add severity weighting for privileged role access, sensitive tenant access, source-code access, CI/CD access, application credential changes, access-key creation, token activity, security-control changes, data export, and verified VPN session linkage.

·        Treat downstream cloud, SaaS, identity, source-code, and CI/CD anomalies as investigative leads unless linked to suspicious VPN session evidence.

·        Use approved administrator records, cloud operations records, SaaS administration records, developer workflow records, CI/CD maintenance records, vendor-support records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, indices, data streams, ECS fields, ingest pipelines, enrich policies, exception lists, rule schedules, lookback windows, correlation windows, parser behavior, and local schema mappings before production deployment.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, destination validation, field availability, false-positive rate, rule performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked downstream control-plane activity rather than static exploit strings, CVE identifiers, source IPs, domains, user-agent values, or isolated cloud anomalies.

·        The rule remains useful if an adversary changes cloud service, SaaS target, developer platform, API sequence, access method, source infrastructure, token use pattern, or post-session timing.

·        The score is supported by the durability of suspicious VPN session linkage, privileged cloud or SaaS action, developer-platform access, source-code access, CI/CD interaction, and control-plane behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-cloud linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, device mismatch, incomplete SaaS or developer-platform logs, and local Elastic field quality.

·        The rule is durable as downstream exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or cloud compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, identity-provider logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, DNS or proxy visibility, source enrichment, and Elastic correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, cloud session reuse, token reuse, identity federation, source IP changes, or inconsistent device identifiers make VPN-to-cloud linkage uncertain.

·        Operational confidence is reduced where administrators, developers, cloud engineers, SaaS administrators, DevOps teams, vendors, or incident responders commonly perform control-plane actions after VPN access.

·        Full-telemetry confidence improves when cloud, SaaS, and developer-platform events are enriched with VPN session evidence, identity-provider session context, endpoint telemetry, source path evidence, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious downstream control-plane activity linked to suspicious VPN sessions, not authentication bypass or cloud compromise by itself.

Elastic may not observe full cloud action contents, SaaS administrative context, token origin, browser session context, device posture, or endpoint process execution unless those sources are ingested and normalized.

Cloud, SaaS, identity, source-code, and CI/CD activity may be legitimate for administrators, developers, cloud engineers, DevOps staff, vendors, or incident responders.

VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, or source IP transformation obscures path attribution.

The rule may miss downstream abuse that occurs outside the correlation window, from reused tokens, from a different device, from a different source path, or through a pre-existing cloud session.

The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic EQL / KQL correlation pattern requiring index validation, data-stream validation, identity-linkage validation, source-path validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific exception handling before production deployment.

sequence by user.name with maxspan=4h
[any where event.action in ("globalprotect_tunnel_established", "vpn_session_established", "remote_access_session_established")
and user.risk.name in ("authentication_lineage_gap", "portal_to_gateway_sequence_gap", "missing_identity_provider_evidence", "missing_mfa_evidence", "missing_hip_evidence", "unexpected_gateway_assignment", "source_not_in_user_baseline", "privileged_account_vpn_use", "third_party_account_vpn_use", "low_frequency_vpn_user", "suspicious_internal_followon_activity")
]
[any where event.action in ("iam_change", "role_assignment", "access_key_created", "api_token_created", "service_account_used", "application_consent_changed", "mfa_changed", "conditional_access_changed", "repository_accessed", "repository_cloned", "cicd_workflow_modified", "secret_accessed", "audit_log_accessed", "security_control_changed", "data_exported")
or event.risk.name in ("rare_user_activity", "first_seen_destination", "privileged_role_use", "sensitive_tenant_access", "sensitive_repository_access", "unusual_api_activity", "source_path_mismatch", "device_mismatch", "outside_normal_access_window", "activity_outside_expected_role")
]

Supplemental KQL condition:

cyberdax.vpn_session.risk:("authentication_lineage_gap" or "portal_to_gateway_sequence_gap" or "source_not_in_user_baseline" or "privileged_account_vpn_use" or "low_frequency_vpn_user") and cyberdax.control_plane.activity_suspicious:true and not cyberdax.change_context.approved:true

QRadar

Detection Viability Assessment

QRadar has three rules for this EXP report.

·        QRadar is viable because GlobalProtect authentication-lineage bypass and trusted VPN session compromise can be detected through normalized PAN-OS events, GlobalProtect portal and gateway logs, identity-provider logs, MFA logs, HIP results, endpoint telemetry, network events, DNS events, proxy events, cloud and SaaS events where available, user context, asset context, reference sets, building blocks, custom event properties, and offense correlation.

·        QRadar is strongest when GlobalProtect, PAN-OS, identity-provider, MFA, HIP, endpoint, DNS, firewall, proxy, cloud, SaaS, and asset telemetry are parsed into reliable DSM mappings, custom event properties, reference sets, building blocks, normalized event categories, and offense rules.

·        QRadar can correlate tunnel establishment, missing authentication-lineage evidence, portal-to-gateway sequencing gaps, gateway-assignment anomalies, source novelty, privileged-account VPN use, internal reconnaissance, privileged resource access, and downstream cloud or SaaS control-plane activity into one offense.

·        QRadar should not infer GlobalProtect compromise from tunnel establishment alone, source novelty alone, vulnerable version posture alone, missing identity evidence alone, internal DNS activity alone, internal administrative-protocol use alone, cloud access alone, SaaS access alone, or developer-platform activity alone.

·        QRadar rules must remain behavior-led, reference-set-driven, custom-property-dependent, building-block-dependent, correlation-dependent, and locally validated before alert-mode deployment.

Rule

GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence

Rule Format

QRadar CRE correlation rule with supporting AQL hunt pattern suitable for PAN-OS events, GlobalProtect portal events, GlobalProtect gateway events, identity-provider events, MFA events, HIP events, source-enrichment events, asset context, user context, reference sets, building blocks, custom event properties, and offense correlation.

Detection Purpose

Detect GlobalProtect tunnel establishment where expected authentication-lineage evidence is absent, incomplete, delayed, mismatched, or inconsistent after telemetry completeness has been validated.

Detection Logic

·        Identify GlobalProtect tunnel establishment, gateway tunnel establishment, VPN session establishment, or remote-access session establishment events.

·        Correlate tunnel establishment with expected precursor activity, including portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion validation, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, and gateway authentication.

·        Prioritize sessions where expected precursor evidence is absent, delayed, mismatched, or inconsistent after ingestion delay, timestamp skew, DSM parsing quality, log retention, custom event property extraction, and local correlation reliability have been validated.

·        Prioritize mismatches involving username, user principal name, source IP, device identifier, SAML identifier, session identifier, tunnel identifier, gateway name, portal name, client version, operating-system profile, HIP result, authentication-cookie context, session-token context, certificate context, or event timestamp.

·        Increase confidence when the VPN account is privileged, administrative, security-related, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, rarely used for VPN, or associated with sensitive internal access.

·        Increase confidence when the source IP, ASN, geography, hosting category, SASE egress path, mobile carrier path, or proxy category is new, rare, anomalous, or inconsistent with the user’s baseline.

·        Increase confidence when tunnel establishment is followed by internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, or administrative-protocol activity.

·        Do not trigger solely on tunnel establishment, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, source novelty, gateway change, vulnerable version posture, or GlobalProtect log presence.

Required Telemetry

·        PAN-OS traffic events.

·        PAN-OS system events.

·        PAN-OS authentication events.

·        PAN-OS configuration events where available.

·        GlobalProtect portal events.

·        GlobalProtect gateway events.

·        GlobalProtect authentication events.

·        GlobalProtect tunnel-established events.

·        GlobalProtect client configuration retrieval events where available.

·        GlobalProtect gateway-assignment events where available.

·        GlobalProtect session-state events.

·        HIP match results where available.

·        HIP report results where available.

·        Identity-provider authentication events.

·        SAML or OIDC assertion context where available.

·        MFA events.

·        Conditional-access events where available.

·        Certificate validation context where available.

·        Authentication-cookie context where available.

·        Session-token context where available.

·        DNS events where available.

·        Endpoint or EDR events where available.

·        User identity.

·        User principal name.

·        Source IP.

·        Source host where available.

·        Device ID where available.

·        Portal name.

·        Gateway name.

·        Gateway region.

·        Session ID.

·        Tunnel ID.

·        Client version.

·        Operating-system profile.

·        Event time.

·        Source enrichment for ASN, geography, reputation, network type, hosting category, proxy category, SASE egress category, environmental prevalence, and first-seen timestamp where available.

·        Asset and user-role enrichment.

·        Reference sets for privileged VPN users, administrative users, third-party VPN users, contractor VPN users, dormant accounts, recently re-enabled accounts, approved travel, approved vendor access, approved SASE routing changes, approved gateway maintenance, approved identity-provider maintenance, approved VPN client upgrades, approved security testing, and approved incident-response activity.

Engineering Implementation Instructions

·        Build QRadar custom event properties for username, user principal name, source IP, source host, device ID, portal name, gateway name, gateway region, session ID, tunnel ID, SAML identifier, client version, operating-system profile, HIP result, event action, event category, authentication result, authentication method, MFA result, certificate result, authentication-cookie indicator, session-token indicator, and normalized authentication-lineage label.

·        Build GlobalProtect building blocks for portal request, portal authentication success, identity-provider authentication success, MFA or conditional-access success, SAML assertion validated, certificate validated, HIP evaluation completed, client configuration retrieved, gateway assigned, gateway authentication success, tunnel established, reconnect, disconnect, and session-state update.

·        Build authentication-lineage building blocks for missing portal precursor, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, missing client configuration retrieval, missing gateway authentication, portal-to-gateway sequence gap, session identifier mismatch, authentication-cookie inconsistency, session-token inconsistency, and gateway-assignment anomaly.

·        Build reference sets for privileged VPN users, administrative users, security users, third-party VPN users, contractor VPN users, service-adjacent users, dormant accounts, stale accounts, recently re-enabled accounts, low-frequency VPN users, sensitive-access users, approved travel, approved vendor access, approved SASE routing changes, approved identity-provider maintenance, approved gateway maintenance, approved VPN client upgrades, approved security testing, and approved incident response.

·        Build source-risk reference sets for newly observed VPN sources, rare ASNs, unusual geographies, hosting-provider sources, anonymization or proxy sources, residential proxy sources, mobile carrier sources, SASE egress sources, low-reputation sources, and sources inconsistent with user history.

·        Build follow-on internal activity building blocks for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database access, file-share access, jump-host access, privileged-management access, identity-service access, and administrative-protocol activity after tunnel establishment.

·        Map placeholder labels such as “GlobalProtect Tunnel Established,” “Identity Provider Authentication Success,” “MFA or Conditional Access Success,” “HIP Evaluation Completed,” “Client Configuration Retrieved,” “Gateway Assigned,” “Portal-to-Gateway Sequence Gap,” and “Tunnel Without Expected Identity Evidence” to local QRadar DSM categories, custom event properties, reference-set matches, building blocks, offense rules, or saved searches before deployment.

·        Implement production correlation through QRadar CRE rule tests, building blocks, reference sets, reference maps, custom event properties, offense chaining, saved searches, and QRadar Use Case Manager content.

·        Use AQL as a supporting hunting, validation, and tuning pattern rather than the primary deployable correlation mechanism.

·        Use short correlation windows for portal-to-gateway authentication sequencing and tunnel establishment.

·        Use moderate correlation windows for delayed identity-provider evidence, delayed MFA evidence, HIP log delay, gateway-assignment lag, and session-state reconciliation.

·        Use longer correlation windows for delayed internal access, repeated short VPN sessions, recurring source infrastructure, or low-and-slow post-session activity.

·        Add severity weighting for privileged-account use, missing authentication-lineage evidence after telemetry completeness validation, portal-to-gateway sequencing gap, suspicious source infrastructure, unusual gateway assignment, unknown patch posture, unfamiliar device context, and internal follow-on activity.

·        Suppress only when user, source, gateway, session timing, identity-provider evidence, maintenance window, travel record, vendor record, routing path, and change context match approved remote-access workflows.

·        Do not enable alert mode until QRadar log sources, DSM parsing, custom event properties, reference sets, building blocks, AQL field names, offense routing, correlation windows, false-positive rates, rule performance, telemetry completeness validation, and SOC triage workflows are validated.

DRI Assessment

DRI

8.5 / 10

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

Limitations

This rule detects suspicious GlobalProtect authentication-lineage or portal-to-gateway sequencing behavior, not confirmed exploitation by itself. Missing identity-provider, MFA, SAML, HIP, certificate, authentication-cookie, session-token, or posture evidence may reflect telemetry delay, ingestion failure, provider outage, retention limits, timestamp skew, DSM parser failure, custom-property extraction issues, or local correlation gaps rather than successful bypass. Legitimate travel, mobile carrier use, SASE routing, regional gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, and incident response can create similar telemetry. The rule must not infer CVE-2026-0257 exploitation, endpoint compromise, credential theft, token theft, cloud compromise, SaaS compromise, lateral movement, or actor attribution without supporting evidence.

Detection Query Pattern

QRadar CRE rule pattern with supporting property-placeholder pseudo-AQL for hunting and validation. Production deployment should use CRE rule tests, building blocks, reference sets, event properties, offense chaining, saved searches, and QRadar Use Case Manager logic. AQL is included only to show the intended property relationships and hunting logic.

Required CRE / building-block sequence

Building block 1

GlobalProtect tunnel establishment, gateway tunnel establishment, VPN session establishment, or remote-access session establishment for the same username, source IP, device ID, session ID, tunnel ID, or asset.

Building block 2

Expected authentication-lineage evidence is missing, delayed, mismatched, or incomplete for the same username, source IP, device ID, session ID, tunnel ID, or asset within the configured portal-to-gateway sequencing window.

Building block 3

One or more risk amplifiers are present, including privileged VPN user, third-party VPN user, dormant or recently re-enabled account, source not in user baseline, rare ASN, unusual geography, hosting-provider source, anonymization source, mobile carrier source, SASE egress source, gateway-assignment anomaly, authentication-cookie inconsistency, session-token inconsistency, or HIP mismatch.

Optional confidence increase

Internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, or administrative-protocol activity after tunnel establishment.

Offense-generation condition

Generate an offense only when tunnel establishment is correlated with missing or inconsistent authentication-lineage evidence and at least one validated risk amplifier, and the session is not explained by approved travel, approved vendor access, approved SASE routing, approved gateway maintenance, approved identity-provider maintenance, approved VPN client upgrade, approved security testing, or approved incident-response activity.

Property-placeholder mapping requirement

The following property names are placeholders and must be mapped to local QRadar custom event properties or normalized properties before use: username, user_principal_name, sourceip, source_host, device_id, portal_name, gateway_name, session_id, tunnel_id, saml_identifier, client_version, os_profile, hip_result, auth_result, mfa_result, certificate_result, event_action, event_category, lineage_status, source_risk, and gateway_assignment.

Supporting property-placeholder pseudo-AQL hunt pattern

SELECT
sourceip,
username,
user_principal_name,
source_host,
device_id,
portal_name,
gateway_name,
session_id,
tunnel_id,
MIN(starttime) AS first_seen,
MAX(starttime) AS last_seen,
"event_action",
"event_category",
"auth_result",
"mfa_result",
"certificate_result",
"hip_result",
"lineage_status",
"source_risk",
"gateway_assignment"
FROM events
WHERE
(
"event_action" IN (
'GlobalProtect Tunnel Established',
'Gateway Tunnel Established',
'VPN Session Established',
'Remote Access Session Established'
)
OR "event_category" IN (
'GlobalProtect Session',
'VPN Session',
'Remote Access Session'
)
)
AND
(
"lineage_status" IN (
'Missing Portal Authentication',
'Missing Identity Provider Authentication',
'Missing MFA Evidence',
'Missing SAML Assertion',
'Missing Certificate Validation',
'Missing HIP Evaluation',
'Missing Client Configuration Retrieval',
'Missing Gateway Authentication',
'Portal-to-Gateway Sequence Gap',
'Session Identifier Mismatch',
'Authentication Cookie Inconsistency',
'Session Token Inconsistency',
'Gateway Assignment Anomaly'
)
OR "source_risk" IN (
'Newly Observed VPN Source',
'Rare ASN',
'Unusual Geography',
'Hosting Provider Source',
'Anonymization Source',
'Residential Proxy Source',
'Mobile Carrier Source',
'SASE Egress Source',
'Source Not In User Baseline'
)
)
AND NOT REFERENCESETCONTAINS('Approved Travel', username)
AND NOT REFERENCESETCONTAINS('Approved Vendor Access', username)
AND NOT REFERENCESETCONTAINS('Approved SASE Routing Change Sources', sourceip)
AND NOT REFERENCESETCONTAINS('Approved Gateway Maintenance Windows', gateway_name)
AND NOT REFERENCESETCONTAINS('Approved Security Testing Sources', sourceip)
GROUP BY
sourceip,
username,
user_principal_name,
source_host,
device_id,
portal_name,
gateway_name,
session_id,
tunnel_id,
"event_action",
"event_category",
"auth_result",
"mfa_result",
"certificate_result",
"hip_result",
"lineage_status",
"source_risk",
"gateway_assignment"

Rule

GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access

Rule Format

QRadar CRE correlation rule with supporting AQL hunt pattern suitable for PAN-OS traffic events, GlobalProtect session context, internal DNS events, firewall events, identity events, endpoint events where available, asset context, user context, privileged-resource reference sets, building blocks, custom event properties, and offense correlation.

Detection Purpose

Detect suspicious internal reconnaissance, administrative protocol activity, identity-service access, privileged resource access, or sensitive application access following a suspicious or high-risk GlobalProtect VPN session.

Detection Logic

·        Identify GlobalProtect VPN session establishment or remote-access session activity for a user, source IP, device, gateway, session ID, tunnel ID, or asset.

·        Prioritize sessions associated with authentication-lineage gaps, portal-to-gateway sequencing anomalies, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, unexpected gateway assignment, unknown patch posture, or suspicious GlobalProtect portal or gateway behavior.

·        Detect internal network activity after VPN establishment involving DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, internal web application, or administrative-protocol traffic.

·        Prioritize access to domain controllers, identity infrastructure, privileged management systems, firewall management interfaces, VPN administration interfaces, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, sensitive file shares, databases, and high-value business applications.

·        Increase confidence when internal activity involves many destinations, rare services for the user, first-seen internal destinations, administrative protocols, repeated authentication attempts, failed internal logons, credential validation, share enumeration, cross-segment access, or access outside the account’s normal role.

·        Increase confidence when endpoint telemetry from reached systems shows suspicious process execution, remote administration tooling, suspicious child processes, tool staging, credential-access behavior, persistence, or outbound follow-on activity.

·        Do not classify internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, or file-share activity as GlobalProtect-linked compromise without VPN session linkage, suspicious establishment evidence, abnormal account behavior, or incident-response validation.

Required Telemetry

·        PAN-OS traffic events.

·        GlobalProtect session events.

·        GlobalProtect tunnel-established events.

·        Internal DNS events.

·        Firewall events.

·        Internal segmentation events where available.

·        Identity events where available.

·        LDAP events where available.

·        Kerberos events where available.

·        SMB telemetry where available.

·        RDP telemetry where available.

·        SSH telemetry where available.

·        WinRM telemetry where available.

·        WMI telemetry where available.

·        Database access events where available.

·        Endpoint or EDR events where available.

·        User identity.

·        User principal name.

·        Source IP.

·        Source host.

·        Device ID where available.

·        Destination IP.

·        Destination host.

·        Destination asset.

·        Destination port.

·        Application.

·        Protocol.

·        Session ID.

·        Tunnel ID.

·        Gateway name.

·        Event time.

·        Asset profile data identifying domain controllers, identity infrastructure, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, sensitive file shares, databases, and high-value applications.

·        Reference sets for privileged resources, approved administrator systems, approved helpdesk systems, approved vendor-support systems, approved vulnerability-management systems, approved security-testing systems, approved maintenance windows, approved software-deployment systems, approved backup systems, and approved incident-response systems.

Engineering Implementation Instructions

·        Build QRadar custom event properties for username, user principal name, source IP, source host, device ID, destination IP, destination host, destination asset, destination port, protocol, application, gateway name, session ID, tunnel ID, event action, event category, authentication result, logon result, asset criticality, resource type, baseline status, and normalized internal-access label.

·        Build VPN session building blocks for GlobalProtect tunnel establishment, remote-access session establishment, suspicious GlobalProtect session context, authentication-lineage gap, portal-to-gateway sequence gap, unexpected gateway assignment, source not in user baseline, privileged account VPN use, third-party account VPN use, and low-frequency VPN user.

·        Build internal activity building blocks for DNS activity, LDAP activity, Kerberos activity, SMB activity, RDP activity, SSH activity, WinRM activity, WMI activity, database access, file-share access, administrative protocol activity, identity-service access, privileged-resource access, and sensitive-application access.

·        Build internal resource reference sets for domain controllers, identity infrastructure, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, sensitive file shares, databases, and high-value business applications.

·        Build suspicious behavior building blocks for first-seen internal destination, rare user-to-destination pair, rare service for user, destination diversity, administrative protocol use, failed authentication burst, credential validation pattern, share enumeration, cross-segment access, and access outside expected role.

·        Map placeholder labels such as “Suspicious GlobalProtect Session Context,” “VPN Authenticated LDAP Activity,” “VPN Authenticated Administrative Protocol Activity,” “Privileged Resource Access,” and “Access Outside Expected Role” to local QRadar DSM categories, custom event properties, reference sets, building blocks, offense rules, saved searches, or flow events before deployment.

·        Implement production correlation through QRadar CRE rule tests, building blocks, reference sets, reference maps, custom event properties, offense chaining, saved searches, and QRadar Use Case Manager content.

·        Use AQL as a supporting hunting, validation, and tuning pattern rather than the primary deployable correlation mechanism.

·        Use short correlation windows for immediate internal access after suspicious VPN session establishment.

·        Use moderate correlation windows for delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Use longer correlation windows only when identity evidence, endpoint evidence, asset access evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for identity-service access, domain-controller access, privileged-management access, administrative-protocol use, sensitive application access, destination novelty, account sensitivity, source-risk context, and repeated internal access attempts.

·        Suppress approved administrator activity, helpdesk activity, vendor support, vulnerability management, security testing, maintenance windows, software deployment, backup activity, and incident-response workflows only when user, source, destination, protocol, timing, and change context match approved baselines.

·        Do not enable alert mode until QRadar log sources, DSM parsing, custom event properties, reference sets, building blocks, AQL field names, offense routing, internal asset mappings, correlation windows, false-positive rates, rule performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

Limitations

This rule detects suspicious VPN-authenticated internal behavior after GlobalProtect session establishment, not authentication bypass or compromise by itself. Legitimate administrator, helpdesk, engineering, vendor-support, vulnerability-management, security-testing, incident-response, software-deployment, and backup workflows may access privileged resources through VPN. The rule may miss low-and-slow activity that remains within the user’s normal access profile, activity hidden by split tunneling, activity obscured by SASE routing or NAT, or internal access not represented in QRadar telemetry. It must not infer endpoint compromise, credential theft, token theft, lateral movement, cloud compromise, SaaS compromise, ransomware deployment, or actor attribution without supporting evidence.

Detection Query Pattern

QRadar CRE rule pattern with supporting property-placeholder pseudo-AQL for hunting and validation. Production deployment should use CRE rule tests, building blocks, reference sets, event properties, offense chaining, saved searches, and QRadar Use Case Manager logic. AQL is included only to show the intended property relationships and hunting logic.

Required CRE / building-block sequence

Building block 1

GlobalProtect tunnel establishment, remote-access session establishment, or suspicious GlobalProtect session context for the same username, source IP, source host, device ID, session ID, tunnel ID, or asset.

Building block 2

Internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, sensitive application, or administrative-protocol activity from the same username, source IP, source host, device ID, session ID, tunnel ID, or asset within the configured VPN-to-internal-access window.

Building block 3

One or more suspicious internal access conditions are present, including first-seen internal destination, rare user-to-destination pair, rare service for user, destination diversity, administrative protocol use, failed authentication burst, credential validation pattern, share enumeration, cross-segment access, or access outside expected role.

Optional confidence increase

Endpoint process execution, remote administration tooling, tool staging, credential-access behavior, persistence creation, suspicious child-process creation, outbound follow-on activity, or additional internal systems reached through the same VPN session.

Offense-generation condition

Generate an offense only when a GlobalProtect VPN session building block is correlated with suspicious internal activity or privileged resource access, and the user, source, destination, protocol, timing, or activity is not explained by approved administrator, helpdesk, vendor-support, vulnerability-management, security-testing, maintenance, software-deployment, backup, or incident-response workflows.

Property-placeholder mapping requirement

The following property names are placeholders and must be mapped to local QRadar custom event properties or normalized properties before use: username, user_principal_name, sourceip, source_host, device_id, destinationip, destination_host, destination_asset, destination_port, protocol, application, gateway_name, session_id, tunnel_id, event_action, event_category, resource_type, asset_criticality, baseline_status, and internal_access_label.

Supporting property-placeholder pseudo-AQL hunt pattern

SELECT
sourceip,
username,
user_principal_name,
source_host,
device_id,
destinationip,
destination_host,
destination_asset,
destination_port,
protocol,
application,
gateway_name,
session_id,
tunnel_id,
MIN(starttime) AS first_seen,
MAX(starttime) AS last_seen,
"event_action",
"event_category",
"resource_type",
"asset_criticality",
"baseline_status",
"internal_access_label"
FROM events
WHERE
(
"event_action" IN (
'GlobalProtect Tunnel Established',
'VPN Session Established',
'Remote Access Session Established',
'Suspicious GlobalProtect Session Context'
)
OR "event_category" IN (
'GlobalProtect Session',
'VPN Session',
'Remote Access Session'
)
)
AND
(
"application" IN (
'DNS',
'LDAP',
'Kerberos',
'SMB',
'RDP',
'SSH',
'WinRM',
'WMI',
'Database',
'File Share',
'Administrative Protocol'
)
OR destination_port IN (53,88,135,139,389,445,3389,5985,5986)
OR "resource_type" IN (
'Domain Controller',
'Identity Infrastructure',
'Jump Host',
'Privileged Management System',
'Firewall Management Interface',
'VPN Administration Interface',
'Backup System',
'Endpoint Management Platform',
'Source Code System',
'CI/CD System',
'Sensitive File Share',
'Database',
'High Value Application'
)
OR "baseline_status" IN (
'First Seen Internal Destination',
'Rare User To Destination Pair',
'Rare Service For User',
'Access Outside User Role',
'Cross Segment Access'
)
)
AND NOT REFERENCESETCONTAINS('Approved Administrator Systems', source_host)
AND NOT REFERENCESETCONTAINS('Approved Helpdesk Systems', source_host)
AND NOT REFERENCESETCONTAINS('Approved Vendor Support Systems', source_host)
AND NOT REFERENCESETCONTAINS('Approved Security Testing Systems', source_host)
AND NOT REFERENCESETCONTAINS('Approved Incident Response Systems', source_host)
GROUP BY
sourceip,
username,
user_principal_name,
source_host,
device_id,
destinationip,
destination_host,
destination_asset,
destination_port,
protocol,
application,
gateway_name,
session_id,
tunnel_id,
"event_action",
"event_category",
"resource_type",
"asset_criticality",
"baseline_status",
"internal_access_label"

Rule

GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity

Rule Format

QRadar CRE correlation rule with supporting AQL hunt pattern suitable for GlobalProtect session context, PAN-OS events, DNS events, proxy events, secure web gateway events, identity-provider events, cloud audit events, SaaS events, developer-platform events, source-code events, CI/CD events, endpoint events where available, custom event properties, reference sets, building blocks, and offense correlation.

Detection Purpose

Detect cloud, SaaS, source-code, CI/CD, developer-platform, or identity control-plane activity that follows a suspicious GlobalProtect VPN session and can be linked to the same user, source path, device, identity session, VPN session window, or incident timeline.

Detection Logic

·        Identify suspicious or high-risk GlobalProtect VPN sessions involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity evidence after validation, suspicious source infrastructure, privileged-account use, third-party-account use, low-frequency VPN use, suspicious portal behavior, suspicious gateway behavior, or internal follow-on activity.

·        Correlate the VPN session window with downstream cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane activity by the same user, source IP, source host, device ID, identity session, session window, or incident timeline.

·        Prioritize downstream actions involving IAM changes, role assignment, access-key creation, API-token creation, service-account use, application-consent changes, MFA changes, conditional-access changes, repository access, repository cloning, CI/CD workflow modification, secret access, audit-log access, security-control changes, or data export.

·        Increase confidence when downstream activity is rare for the user, first seen for the destination, outside normal access windows, directed at sensitive tenants, directed at sensitive repositories, inconsistent with the account role, or associated with privileged role use.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, unusual session creation, suspicious OAuth consent, CLI usage, API activity, or post-session administrative behavior.

·        Do not classify cloud, SaaS, identity, developer-platform, source-code, or CI/CD anomalies as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, or incident-response validation.

Required Telemetry

·        GlobalProtect tunnel-established events.

·        PAN-OS traffic events.

·        GlobalProtect session context.

·        DNS events.

·        Proxy events where available.

·        Secure web gateway events where available.

·        Identity-provider events.

·        Cloud audit events where available.

·        SaaS audit events where available.

·        Developer-platform events where available.

·        Source-code platform events where available.

·        CI/CD platform events where available.

·        Endpoint or EDR events where available.

·        User identity.

·        User principal name.

·        Source IP.

·        Source host.

·        Device ID where available.

·        VPN gateway.

·        Session ID.

·        Tunnel ID.

·        Identity-provider session ID where available.

·        Destination domain.

·        Destination application.

·        Event action.

·        Event result.

·        Event time.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Reference sets for approved cloud operations, approved SaaS administration, approved developer workflows, approved CI/CD maintenance, approved vendor support, approved security testing, approved incident response, and approved change control.

Engineering Implementation Instructions

·        Build QRadar custom event properties for username, user principal name, source IP, source host, device ID, destination domain, destination application, action, result, identity-provider session ID, VPN session ID, tunnel ID, gateway name, cloud account, tenant ID, repository name, CI/CD environment, service account, access key ID, API token indicator, role name, privilege level, event category, and normalized control-plane activity label.

·        Build suspicious VPN session building blocks for authentication-lineage gap, portal-to-gateway sequence gap, missing identity evidence after validation, missing MFA evidence after validation, missing HIP evidence after validation, unexpected gateway assignment, source not in user baseline, privileged account VPN use, third-party account VPN use, low-frequency VPN user, and suspicious internal follow-on activity.

·        Build downstream control-plane building blocks for cloud IAM change, cloud role assignment, access key creation, API token creation, service account use, application consent change, MFA change, conditional access change, repository access, repository clone, CI/CD workflow modification, secret access, audit log access, security control change, and data export.

·        Build downstream-risk building blocks for rare user activity, first-seen destination, privileged role use, sensitive tenant access, sensitive repository access, unusual API activity, source-path mismatch, device mismatch, outside-normal-window activity, and activity outside expected role.

·        Build reference sets for privileged cloud users, SaaS administrators, developer-platform administrators, sensitive tenants, sensitive repositories, privileged applications, approved cloud operations, approved SaaS administration, approved developer workflows, approved CI/CD maintenance, approved vendor support, approved security testing, approved incident response, and approved change control.

·        Map placeholder values such as “Cloud IAM Change,” “API Token Created,” “Repository Cloned,” “CI/CD Workflow Modified,” “Secret Accessed,” “Source-Path Mismatch,” and “Sensitive Tenant Access” to local QRadar DSM categories, cloud audit events, SaaS audit events, developer-platform logs, source-code platform logs, CI/CD logs, custom event properties, building blocks, reference sets, or offense rules before deployment.

·        Implement production correlation through QRadar CRE rule tests, building blocks, reference sets, reference maps, custom event properties, offense chaining, saved searches, and QRadar Use Case Manager content.

·        Use AQL as a supporting hunting, validation, and tuning pattern rather than the primary deployable correlation mechanism.

·        Use short correlation windows when cloud, SaaS, or developer-platform activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed administrative activity, repository access, token use, CI/CD activity, source-code access, or cloud API activity after suspicious VPN establishment.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, source-path evidence, or session continuity supports delayed linkage.

·        Add severity weighting for suspicious VPN session context, privileged role access, sensitive tenant access, source-code access, CI/CD access, application credential changes, access-key creation, API-token creation, secret access, security-control changes, data export, and verified VPN session linkage.

·        Suppress approved cloud operations, SaaS administration, developer workflows, CI/CD maintenance, vendor support, security testing, incident response, and change-control activity only when user, source, device, destination, action, timing, and change context match approved workflows.

·        Do not enable alert mode until QRadar log sources, DSM parsing, custom event properties, cloud/SaaS/developer log mappings, reference sets, building blocks, AQL field names, offense routing, correlation windows, false-positive rates, rule performance, and SOC triage workflows are validated.

DRI Assessment

DRI

7.5 / 10

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

Limitations

This rule detects suspicious downstream control-plane activity linked to suspicious VPN sessions, not authentication bypass, cloud compromise, SaaS compromise, developer-platform compromise, or source-code compromise by itself. Legitimate administrators, cloud engineers, SaaS administrators, developers, DevOps teams, vendors, security testers, and incident responders may perform similar activity after VPN access. VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, source IP transformation, or inconsistent device identifiers obscure path attribution. The rule may miss downstream abuse that occurs outside the correlation window, from reused tokens, from a different device, from a different source path, or through a pre-existing session. It must not infer credential theft, token theft, data theft, cloud compromise, SaaS compromise, developer-platform compromise, or actor attribution without supporting identity, endpoint, cloud, SaaS, network, or incident-response evidence.

Detection Query Pattern

QRadar CRE rule pattern with supporting property-placeholder pseudo-AQL for hunting and validation. Production deployment should use CRE rule tests, building blocks, reference sets, event properties, offense chaining, saved searches, and QRadar Use Case Manager logic. AQL is included only to show the intended property relationships and hunting logic.

Required CRE / building-block sequence

Building block 1

Suspicious GlobalProtect VPN session context, authentication-lineage gap, portal-to-gateway sequence gap, source not in user baseline, privileged account VPN use, third-party account VPN use, low-frequency VPN use, or suspicious internal follow-on activity for the same username, source IP, source host, device ID, VPN session ID, tunnel ID, or asset.

Building block 2

Cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane activity by the same username, source IP, source host, device ID, identity-provider session ID, or incident window within the configured VPN-to-control-plane activity window.

Building block 3

One or more sensitive downstream actions are present, including IAM change, role assignment, access-key creation, API-token creation, service-account use, application-consent change, MFA change, conditional-access change, repository access, repository clone, CI/CD workflow modification, secret access, audit-log access, security-control change, or data export.

Optional confidence increase

Rare user activity, first-seen destination, privileged-role use, sensitive-tenant access, sensitive-repository access, unusual API activity, source-path mismatch, device mismatch, activity outside normal access window, credential-access indicator, token-access indicator, browser credential-store access, suspicious OAuth consent, CLI usage, or incident-response evidence.

Offense-generation condition

Generate an offense only when suspicious GlobalProtect VPN session context is correlated with downstream control-plane activity and at least one sensitive downstream action or downstream-risk condition, and the activity is not explained by approved cloud operations, approved SaaS administration, approved developer workflow, approved CI/CD maintenance, approved vendor support, approved security testing, approved incident response, or approved change control.

Property-placeholder mapping requirement

The following property names are placeholders and must be mapped to local QRadar custom event properties or normalized properties before use: username, user_principal_name, sourceip, source_host, device_id, destination_domain, destination_application, action, result, identity_provider_session_id, vpn_session_id, tunnel_id, gateway_name, cloud_account, tenant_id, repository_name, cicd_environment, service_account, access_key_id, role_name, privilege_level, event_category, vpn_session_risk, control_plane_activity, and downstream_risk.

Supporting property-placeholder pseudo-AQL hunt pattern

SELECT
sourceip,
username,
user_principal_name,
source_host,
device_id,
destination_domain,
destination_application,
identity_provider_session_id,
vpn_session_id,
tunnel_id,
gateway_name,
cloud_account,
tenant_id,
repository_name,
cicd_environment,
MIN(starttime) AS first_seen,
MAX(starttime) AS last_seen,
"action",
"result",
"event_category",
"vpn_session_risk",
"control_plane_activity",
"downstream_risk",
"service_account",
"access_key_id",
"role_name",
"privilege_level"
FROM events
WHERE
(
"vpn_session_risk" IN (
'Authentication Lineage Gap',
'Portal-to-Gateway Sequence Gap',
'Missing Identity Provider Evidence',
'Missing MFA Evidence',
'Missing HIP Evidence',
'Unexpected Gateway Assignment',
'Source Not In User Baseline',
'Privileged Account VPN Use',
'Third Party Account VPN Use',
'Low Frequency VPN User',
'Suspicious Internal Follow-On Activity'
)
OR "event_action" IN (
'GlobalProtect Tunnel Established',
'Suspicious GlobalProtect Session Context'
)
)
AND
(
"control_plane_activity" IN (
'Cloud IAM Change',
'Cloud Role Assignment',
'Access Key Created',
'API Token Created',
'Service Account Used',
'Application Consent Changed',
'MFA Changed',
'Conditional Access Changed',
'Repository Accessed',
'Repository Cloned',
'CI/CD Workflow Modified',
'Secret Accessed',
'Audit Log Accessed',
'Security Control Changed',
'Data Exported'
)
OR "downstream_risk" IN (
'Rare User Activity',
'First Seen Destination',
'Privileged Role Use',
'Sensitive Tenant Access',
'Sensitive Repository Access',
'Unusual API Activity',
'Source Path Mismatch',
'Device Mismatch',
'Outside Normal Access Window',
'Activity Outside Expected Role'
)
)
AND NOT REFERENCESETCONTAINS('Approved Cloud Operations Users', username)
AND NOT REFERENCESETCONTAINS('Approved SaaS Administration Users', username)
AND NOT REFERENCESETCONTAINS('Approved Developer Workflow Users', username)
AND NOT REFERENCESETCONTAINS('Approved CI/CD Maintenance Users', username)
AND NOT REFERENCESETCONTAINS('Approved Security Testing Users', username)
AND NOT REFERENCESETCONTAINS('Approved Incident Response Users', username)
GROUP BY
sourceip,
username,
user_principal_name,
source_host,
device_id,
destination_domain,
destination_application,
identity_provider_session_id,
vpn_session_id,
tunnel_id,
gateway_name,
cloud_account,
tenant_id,
repository_name,
cicd_environment,
"action",
"result",
"event_category",
"vpn_session_risk",
"control_plane_activity",
"downstream_risk",
"service_account",
"access_key_id",
"role_name",
"privilege_level"

SIGMA

Detection Viability Assessment

SIGMA has three rules for this EXP report.

·        SIGMA is viable for expressing portable detection logic for GlobalProtect authentication-lineage failure, portal-to-gateway sequencing gaps, suspicious VPN session establishment, trusted VPN session misuse, and downstream control-plane activity across SIEM platforms that support correlation, enrichment, and local field mapping.

·        SIGMA is strongest where PAN-OS, GlobalProtect, identity-provider, MFA, HIP, endpoint, network, DNS, proxy, cloud, SaaS, and enrichment telemetry are normalized into stable field names before translation into Splunk, Elastic, QRadar, Microsoft Sentinel, Chronicle, or another SIEM platform.

·        SIGMA can define durable behavioral detection patterns for tunnel establishment without expected authentication-lineage evidence, suspicious VPN-authenticated internal access, and VPN-linked cloud, SaaS, or developer-platform activity.

·        SIGMA is not a standalone deployment mechanism for confirming GlobalProtect exploitation, successful authentication bypass, identity-provider bypass, MFA bypass, HIP bypass, credential theft, token theft, endpoint compromise, cloud compromise, or actor attribution.

·        SIGMA rules must be translated, field-mapped, timing-window validated, enrichment-tested, exception-tested, and performance-tested in the target SIEM before alert-mode deployment.

·        SIGMA rules should not generate high-confidence alerting from vulnerable version posture alone, source novelty alone, tunnel establishment alone, missing identity evidence alone, endpoint alerting alone, internal discovery alone, cloud access alone, SaaS activity alone, or developer-platform activity alone.

Rule

GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence

Rule Format

SIGMA behavioral correlation rule pattern suitable for SIEM translation where GlobalProtect tunnel-established events can be correlated with portal authentication, gateway authentication, identity-provider authentication, MFA outcome, SAML or OIDC context, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, source enrichment, account enrichment, and telemetry-completeness validation.

Detection Purpose

·        Detect GlobalProtect tunnel-established or VPN session-established activity where expected authentication-lineage evidence is absent, incomplete, delayed, mismatched, or inconsistent after telemetry completeness has been validated.

·        Identify potential authentication-lineage failure, portal-to-gateway sequencing gaps, unauthorized VPN session establishment, or trusted VPN session compromise.

·        Prioritize sessions involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Support escalation when suspicious tunnel establishment occurs from unfamiliar infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, or source networks inconsistent with user history.

·        Preserve separation between suspicious VPN establishment and confirmed compromise by requiring identity, endpoint, network, cloud, SaaS, or incident-response evidence before classifying the activity as probable compromise.

Detection Logic

·        Identify GlobalProtect tunnel-established, VPN session-established, gateway tunnel-established, or remote-access session-established events.

·        Correlate the tunnel-established event with expected precursor evidence, including portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion validation, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, and gateway authentication.

·        Prioritize events where expected precursor evidence is missing or mismatched after ingestion delay, parser behavior, timestamp skew, telemetry retention, and join reliability have been validated.

·        Prioritize mismatches involving username, user principal name, device identifier, source IP, session identifier, SAML identifier, tunnel identifier, gateway name, portal name, client version, operating-system profile, HIP result, certificate context, authentication-cookie context, session-token context, or timestamp.

·        Increase confidence when the account is privileged, administrative, security-related, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, rarely used for VPN, or associated with sensitive access.

·        Increase confidence when the source infrastructure is newly observed, rare for the user, rare for the tenant, associated with hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, unusual geographies, or ASNs not normally associated with the user.

·        Reduce severity when behavior aligns with approved travel, mobile carrier use, regional gateway failover, SASE routing, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, approved vendor access, helpdesk activity, security testing, incident response, or documented change-control activity.

·        Do not classify missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence as bypass until telemetry delay, ingestion gaps, provider outage, parser failure, retention limits, timestamp skew, and local join failure have been reviewed.

Required Telemetry

·        PAN-OS traffic logs.

·        PAN-OS system logs.

·        PAN-OS authentication logs.

·        PAN-OS configuration logs where available.

·        GlobalProtect portal logs.

·        GlobalProtect gateway logs.

·        GlobalProtect authentication events.

·        GlobalProtect client configuration retrieval events where available.

·        GlobalProtect gateway-assignment events where available.

·        GlobalProtect tunnel-established events.

·        GlobalProtect session-state events.

·        GlobalProtect HIP match results where available.

·        GlobalProtect HIP report results where available.

·        Authentication-cookie context where available.

·        Session-token context where available.

·        Identity-provider logs.

·        SAML or OIDC context.

·        MFA logs.

·        Conditional-access logs where available.

·        Certificate validation context where available.

·        Device-compliance or posture context where available.

·        Source enrichment.

·        Account enrichment.

·        Gateway inventory.

·        VPN user inventory.

·        Privileged account inventory.

·        Approved travel records where available.

·        Approved vendor access records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Translate the SIGMA rule into the target SIEM only after validating local log sources, field names, event actions, event categories, parser behavior, enrichment sources, and correlation capability.

·        Build normalized GlobalProtect event categories for portal request, portal authentication, identity-provider authentication, MFA decision, SAML assertion, certificate validation, HIP evaluation, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, reconnect, disconnect, and session state.

·        Build authentication-lineage correlation logic that evaluates whether expected precursor events occur before tunnel establishment within locally validated timing windows.

·        Build mismatch logic for username, user principal name, device identifier, source IP, SAML identifier, session identifier, tunnel identifier, authentication cookie, session token, gateway name, portal name, client version, operating-system profile, HIP result, certificate context, and timestamp.

·        Build source-risk enrichment for newly observed sources, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, proxy infrastructure, low-reputation sources, and sources inconsistent with user history.

·        Build account-risk enrichment for privileged users, administrators, security staff, remote-access administrators, third-party accounts, contractor accounts, service-adjacent accounts, dormant accounts, stale accounts, recently re-enabled accounts, low-frequency VPN users, and users with sensitive access.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for user, device, source, destination, event action, session identifier, tunnel identifier, gateway, portal, identity-provider session, MFA result, SAML or OIDC context, HIP result, certificate context, telemetry-completeness status, account-risk context, source-risk context, session-risk context, and change-control context.

·        Validate event-action normalization across PAN-OS, GlobalProtect, identity-provider, MFA, HIP, endpoint, network, DNS, proxy, cloud, SaaS, source-code, CI/CD, and SIEM telemetry before relying on translated rule behavior.

·        Validate backend support for correlation, sequence logic, negative matching, enrichment joins, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for portal-to-gateway sequencing, identity-provider correlation, MFA correlation, HIP correlation, gateway-assignment reconciliation, tunnel establishment, repeated short sessions, delayed internal access, and low-and-slow post-session behavior.

·        Validate exception handling for approved travel, vendor access, SASE routing changes, gateway failover, gateway maintenance, identity-provider maintenance, VPN client upgrades, helpdesk activity, security testing, incident response, and documented change-control activity.

·        Use short correlation windows for expected portal-to-gateway authentication sequencing and tunnel establishment.

·        Use moderate correlation windows for delayed identity-provider evidence, delayed MFA evidence, HIP log delay, gateway-assignment lag, and session-state reconciliation.

·        Use longer correlation windows for delayed internal access, repeated short VPN sessions, recurring source infrastructure, or low-and-slow post-session activity.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until SIEM translation accuracy, field availability, correlation reliability, telemetry completeness, false-positive rate, rule performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to durable authentication-lineage and portal-to-gateway sequencing gaps rather than static CVE strings, known exploit strings, source IPs, user-agent values, request paths, or payload indicators.

·        The rule remains useful if an adversary changes source infrastructure, timing, client version, user-agent, portal interaction pattern, gateway interaction pattern, authentication artifact usage, or post-session activity.

·        The score is supported by the durability of tunnel establishment without expected precursor evidence, gateway sequencing anomalies, identity-provider mismatch, MFA mismatch, HIP mismatch, session-state inconsistency, source novelty, and account-risk context.

·        The score is constrained by missing GlobalProtect logs, incomplete HIP logs, identity-provider logging gaps, MFA telemetry gaps, split-tunnel visibility limits, timestamp skew, NAT, carrier-grade NAT, SASE routing, inconsistent session identifiers, and target-SIEM field-mapping quality.

·        The rule is durable as a portable SIEM correlation pattern but should not be treated as standalone proof of authentication bypass, exploit success, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on GlobalProtect portal logs, gateway logs, tunnel-established events, HIP results, gateway-assignment context, identity-provider logs, MFA logs, reliable session identifiers, source enrichment, account enrichment, and target-SIEM correlation quality.

·        Operational confidence is reduced where identity-provider evidence is delayed, MFA logs are incomplete, HIP events are missing, authentication cookies are unavailable, session-token context is unavailable, or tunnel events cannot be reliably joined to portal and gateway events.

·        Operational confidence is reduced where SIGMA translation removes correlation detail, changes field behavior, weakens sequence logic, or depends on fields that are not present in the target SIEM.

·        Full-telemetry confidence improves when tunnel-established events are enriched with PAN-OS logs, GlobalProtect portal and gateway logs, HIP logs, identity-provider logs, MFA logs, endpoint telemetry, DNS logs, internal network telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation or actor attribution.

Limitations

·        This rule detects suspicious GlobalProtect authentication-lineage or portal-to-gateway sequencing behavior, not confirmed exploitation by itself.

·        SIGMA translation quality depends on the target SIEM’s support for sequence logic, joins, lookups, enrichment, negative matching, and timing-window handling.

·        Missing identity-provider, MFA, SAML, HIP, certificate, or posture evidence may reflect telemetry delay, ingestion failure, retention limits, parser failure, provider outage, timestamp skew, or field-mapping issues rather than successful bypass.

·        Legitimate travel, mobile carrier use, SASE routing, regional gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, gateway maintenance, approved vendor access, helpdesk activity, security testing, and incident response can create similar patterns.

·        The rule may miss bypass activity where attackers produce apparently complete authentication-lineage artifacts, use valid credentials, abuse legitimate session material, or operate within normal user source and device patterns.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA-style correlation pattern requiring target-SIEM translation validation, local field mapping, GlobalProtect event validation, telemetry-completeness validation, VPN session validation, identity-provider join validation, MFA join validation, HIP join validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIGMA rule without backend-specific translation.

title: GlobalProtect Tunnel Establishment Without Complete Authentication Lineage Evidence
id: cyberdax-globalprotect-auth-lineage-gap
status: test
description: Detects GlobalProtect tunnel establishment where expected authentication-lineage evidence is absent, incomplete, delayed, or inconsistent after telemetry completeness has been validated.
logsource:
product: pan-os
service: globalprotect
detection:
selection_tunnel:
event.action:
- globalprotect_tunnel_established
- vpn_session_established
- gateway_tunnel_established
- remote_access_session_established
selection_risk_context:
cyberdax.account.context:
- privileged_account
- administrative_account
- security_account
- third_party_account
- contractor_account
- service_adjacent_account
- dormant_account
- stale_account
- recently_reenabled_account
- low_frequency_vpn_user
cyberdax.source.context:
- newly_observed_source
- rare_asn
- unusual_geography
- hosting_provider_source
- anonymization_service
- residential_proxy_infrastructure
- mobile_carrier_network
- sase_egress_source
- source_not_in_user_baseline
cyberdax.session.context:
- unexpected_gateway_assignment
- missing_portal_precursor
- missing_gateway_precursor
- missing_client_config_retrieval
- portal_to_gateway_sequence_gap
- tunnel_without_expected_identity_evidence
- session_identifier_mismatch
- authentication_cookie_inconsistency
- session_token_inconsistency
- hip_result_inconsistency
selection_validation:
cyberdax.telemetry_completeness.validated: true
filter_approved_context:
cyberdax.change_context.approved:
- approved_travel
- approved_vendor_access
- approved_sase_routing_change
- approved_gateway_maintenance
- approved_identity_provider_maintenance
- approved_vpn_client_upgrade
- approved_security_testing
- approved_incident_response
- approved_change_control
condition: selection_tunnel and selection_risk_context and selection_validation and not filter_approved_context
fields:

·        user.name

·        source.ip

·        source.as.organization.name

·        source.geo.country_name

·        host.name

·        panw.panos.virtual_system

·        panw.panos.source_zone

·        panw.panos.destination_zone

·        cyberdax.gateway.name

·        cyberdax.portal.name

·        cyberdax.session.id

·        cyberdax.tunnel.id

·        cyberdax.authentication_lineage.status

·        cyberdax.session.context
falsepositives:

·        Approved travel

·        Mobile carrier source changes

·        SASE routing changes

·        Gateway failover

·        VPN client upgrade

·        Identity-provider maintenance

·        Approved vendor support

·        Security testing

·        Incident response

·        Approved change control
level: high

Rule

GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access

Rule Format

SIGMA behavioral follow-on correlation rule suitable for SIEM translation where GlobalProtect VPN session events can be linked to internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, administrative-protocol, endpoint, and asset-criticality telemetry.

Detection Purpose

·        Detect suspicious internal activity after GlobalProtect VPN session establishment where the VPN-connected account accesses identity services, privileged resources, administrative protocols, sensitive applications, or internal systems inconsistent with normal behavior.

·        Identify trusted VPN session misuse after suspicious session establishment, authentication-lineage inconsistency, source infrastructure novelty, gateway-sequencing anomaly, or high-risk account use.

·        Prioritize VPN-authenticated internal reconnaissance, credential validation, identity-service access, administrative protocol use, jump-host access, management-plane access, and sensitive resource access.

·        Preserve separation between suspicious trusted-session use and confirmed compromise by requiring endpoint, identity, file, persistence, credential-access, token-access, cloud, SaaS, or incident-response evidence before classifying downstream compromise as confirmed.

Detection Logic

·        Identify GlobalProtect VPN session establishment or remote-access session activity for a user, device, source IP, gateway, tunnel identifier, or session identifier.

·        Prioritize sessions associated with authentication-lineage gaps, source infrastructure novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency VPN use, vulnerable or unknown patch posture, or suspicious GlobalProtect portal or gateway behavior.

·        Detect internal network activity after VPN establishment involving DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, identity-service, internal web application, or administrative-protocol traffic.

·        Prioritize internal access to domain controllers, identity infrastructure, privileged management systems, firewall management interfaces, VPN administration interfaces, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        Increase confidence when activity involves many internal destinations, rare services for the user, first-seen internal destinations, administrative protocols, repeated authentication attempts, failed internal logons, credential validation, share enumeration, or access outside the user’s normal role.

·        Increase confidence when endpoint telemetry from internal systems shows process execution, remote administration tooling, suspicious child processes, tool staging, credential-access behavior, persistence, or outbound follow-on from systems reached through the VPN session.

·        Reduce severity when activity matches approved administrator duties, helpdesk activity, engineering workflows, vulnerability management, security testing, incident response, scheduled maintenance, backup activity, software deployment, or documented third-party support.

·        Do not attribute internal reconnaissance or privileged resource access to GlobalProtect compromise without session linkage, suspicious VPN establishment evidence, abnormal account behavior, or incident-response validation.

Required Telemetry

·        PAN-OS traffic logs.

·        GlobalProtect session context.

·        GlobalProtect tunnel-established events.

·        GlobalProtect gateway context.

·        GlobalProtect user mapping.

·        Internal DNS logs.

·        LDAP logs where available.

·        Kerberos logs where available.

·        SMB telemetry where available.

·        RDP telemetry where available.

·        SSH telemetry where available.

·        WinRM telemetry where available.

·        WMI telemetry where available.

·        Database access logs where available.

·        File-share access telemetry where available.

·        Firewall logs.

·        Internal segmentation telemetry.

·        Endpoint telemetry where available.

·        EDR telemetry where available.

·        Identity logs where available.

·        User identity.

·        Device identity.

·        Source IP.

·        Gateway.

·        Session identifier.

·        Tunnel identifier.

·        Source zone.

·        Destination zone.

·        Destination asset.

·        Application.

·        Protocol.

·        Port.

·        Bytes.

·        Duration.

·        Timestamp.

·        Asset criticality inventory.

·        Privileged resource inventory.

·        Normal VPN user behavior baselines.

·        Normal internal resource access baselines.

·        Approved administrator workflow records.

·        Approved helpdesk records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Translate the SIGMA rule into the target SIEM only after validating local field mappings for user, source IP, device, VPN session, tunnel ID, gateway, destination asset, protocol, application, port, account risk, asset criticality, and baseline status.

·        Build VPN session groups covering GlobalProtect tunnel-established events, remote-access sessions, gateway context, tunnel identifiers, session identifiers, source IPs, users, devices, and gateway assignments.

·        Build internal resource groups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, and high-value business applications.

·        Build internal protocol groups for DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S internal, file-share, and administrative protocol activity.

·        Build suspicious internal behavior groups for first-seen destinations, rare user-to-destination pairs, rare services for the user, destination diversity, administrative protocol use, failed authentication bursts, credential validation, share enumeration, cross-segment access, and access outside the account’s normal role.

·        Build session-risk enrichment for authentication-lineage gaps, missing identity evidence, source novelty, gateway sequencing anomalies, privileged account use, third-party account use, low-frequency VPN use, unknown patch posture, and suspicious portal or gateway behavior.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for user, device, source IP, VPN session, tunnel identifier, gateway, destination asset, destination zone, source zone, application, protocol, port, account-risk context, asset criticality, internal-access pattern, baseline status, and change-control context.

·        Validate event-action normalization across PAN-OS, GlobalProtect, firewall, DNS, proxy, NDR, identity, endpoint, EDR, internal resource, and SIEM telemetry before relying on translated rule behavior.

·        Validate backend support for VPN session linkage, internal network correlation, asset-criticality enrichment, user-baseline comparison, enrichment joins, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for VPN session establishment, immediate internal access, delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Validate exception handling for approved administrator activity, helpdesk activity, vendor support, security testing, vulnerability management, incident response, maintenance windows, backup activity, software deployment, and documented change-control activity.

·        Use short correlation windows for internal access immediately after suspicious VPN session establishment.

·        Use moderate correlation windows for delayed reconnaissance, delayed privileged resource access, repeated reconnects, repeated short VPN sessions, and low-and-slow movement.

·        Use longer correlation windows only when VPN session evidence, identity evidence, endpoint evidence, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until session linkage, field availability, asset inventory, resource baselines, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to durable trusted-session misuse and post-session internal access behavior rather than static exploit strings, source IPs, user-agent values, CVE identifiers, or request paths.

·        The rule remains useful if an adversary changes initial exploit mechanics, source infrastructure, VPN client attributes, gateway selection, timing, internal destination order, or post-session access sequence.

·        The score is supported by the durability of VPN-authenticated internal reconnaissance, identity-service access, administrative protocol use, privileged resource access, destination novelty, and access outside normal user baselines.

·        The score is constrained by split-tunnel visibility, incomplete internal network telemetry, weak asset inventory, NAT, SASE routing, incomplete VPN session mapping, legitimate administrator workflows, and target-SIEM translation quality.

·        The rule is durable as a trusted-session misuse detector but should not be treated as standalone proof of authentication bypass, endpoint compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, internal network visibility, DNS coverage, asset inventory, privileged resource inventory, user baselines, account enrichment, and target-SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, ZTNA overlays, endpoint-only access paths, incomplete internal telemetry, or weak session identifiers prevent reliable linkage between VPN sessions and internal access.

·        Operational confidence is reduced where administrators, engineers, helpdesk users, vulnerability management tools, security testing, incident response, or third-party support commonly access privileged systems through VPN.

·        Full-telemetry confidence improves when VPN session context is enriched with endpoint telemetry, EDR telemetry, identity logs, firewall logs, DNS logs, internal resource telemetry, cloud logs, SaaS logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        This rule detects suspicious VPN-authenticated internal behavior, not authentication bypass by itself.

·        SIGMA translation quality depends on whether the target SIEM can correlate VPN session context with downstream internal activity within the required timing windows.

·        Split tunneling, SASE routing, ZTNA overlays, proxy paths, endpoint-only telemetry, NAT, carrier-grade NAT, and mobile networks may reduce visibility or attribution.

·        Legitimate administrator, helpdesk, engineering, security testing, vulnerability management, incident-response, vendor-support, and software-deployment workflows can produce similar behavior.

·        The rule may miss low-and-slow activity that remains within the user’s normal access profile or uses expected internal resources.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA-style correlation pattern requiring target-SIEM translation validation, local field mapping, VPN session validation, internal destination validation, privileged-resource validation, user-baseline validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIGMA rule without backend-specific translation.

title: GlobalProtect Trusted VPN Session Followed By Internal Reconnaissance Or Privileged Resource Access
id: cyberdax-globalprotect-vpn-internal-recon-privileged-access
status: test
description: Detects internal reconnaissance, privileged resource access, or administrative protocol use after suspicious or high-risk GlobalProtect VPN session establishment.
logsource:
category: network
detection:
selection_vpn_session:
event.action:
- globalprotect_tunnel_established
- vpn_session_established
- remote_access_session_established
selection_session_risk:
cyberdax.vpn_session.risk:
- authentication_lineage_gap
- portal_to_gateway_sequence_gap
- missing_identity_provider_evidence
- missing_mfa_evidence
- missing_hip_evidence
- unexpected_gateway_assignment
- source_not_in_user_baseline
- privileged_account_vpn_use
- third_party_account_vpn_use
- low_frequency_vpn_user
- suspicious_portal_or_gateway_activity
selection_internal_activity:
network.direction:
- vpn_to_internal
- remote_access_to_internal
- client_to_internal
network.protocol:
- dns
- ldap
- kerberos
- smb
- rdp
- ssh
- winrm
- wmi
- database
- http_internal
- file_share
- admin_protocol
selection_privileged_resource:
cyberdax.destination.resource_type:
- identity_infrastructure
- domain_controller
- jump_host
- privileged_management_system
- firewall_management_interface
- vpn_administration_interface
- backup_system
- endpoint_management_platform
- source_code_system
- cicd_infrastructure
- sensitive_file_share
- database
- high_value_business_application
selection_behavior:
cyberdax.internal_access.pattern:
- first_seen_internal_destination
- rare_user_to_destination_pair
- rare_service_for_user
- destination_diversity
- administrative_protocol_use
- failed_authentication_burst
- credential_validation_pattern
- share_enumeration
- cross_segment_access
- access_outside_user_role
filter_approved_context:
cyberdax.change_context.approved:
- approved_administrator_activity
- approved_helpdesk_activity
- approved_vendor_support
- approved_security_testing
- approved_vulnerability_management
- approved_incident_response
- approved_maintenance_window
- approved_backup_activity
- approved_software_deployment
- approved_change_control
condition: selection_vpn_session and selection_session_risk and selection_internal_activity and 1 of selection_privileged_resource,selection_behavior and not filter_approved_context
fields:

·        user.name

·        source.ip

·        host.name

·        destination.ip

·        destination.domain

·        destination.port

·        network.protocol

·        cyberdax.gateway.name

·        cyberdax.session.id

·        cyberdax.tunnel.id

·        cyberdax.destination.resource_type

·        cyberdax.internal_access.pattern
falsepositives:

·        Administrator workflows

·        Helpdesk activity

·        Vulnerability management

·        Security testing

·        Incident response

·        Vendor support

·        Backup activity

·        Software deployment
level: high

Rule

GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity

Rule Format

SIGMA behavioral VPN-to-control-plane correlation rule suitable for SIEM translation where suspicious GlobalProtect VPN session context can be linked to cloud, SaaS, identity, developer-platform, source-code, CI/CD, or privileged control-plane activity using user identity, source IP, device identity, identity-provider session, VPN session window, destination application, and incident timeline.

Detection Purpose

·        Detect cloud, SaaS, developer-platform, source-code, CI/CD, or control-plane activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, session window, or incident timeline.

·        Identify downstream control-plane exposure after trusted VPN session compromise without treating cloud, SaaS, or developer-platform anomalies as standalone evidence of GlobalProtect compromise.

·        Prioritize privileged cloud roles, administrative SaaS actions, source-code access, CI/CD changes, application credential changes, token use, access-key activity, repository access, or security-control modification.

·        Preserve separation between suspicious VPN-linked downstream activity and confirmed cloud or SaaS compromise by requiring additional identity, cloud, SaaS, endpoint, file, persistence, credential-access, token-access, or incident-response evidence before classifying compromise as confirmed.

Detection Logic

·        Identify suspicious or high-risk GlobalProtect VPN session establishment involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or internal follow-on activity.

·        Correlate the VPN session window with cloud, SaaS, identity, source-code, developer-platform, CI/CD, or control-plane access by the same user, device, source path, identity session, VPN session window, or incident timeline.

·        Prioritize downstream actions involving privileged role access, administrative console access, IAM changes, MFA changes, conditional-access changes, application consent changes, API token creation, access-key creation, repository cloning, source-code access, CI/CD variable access, workflow modification, service-account use, security-control changes, or data export.

·        Increase confidence when downstream access occurs from the same source IP, same device, same user, same VPN session window, same authentication session, same identity-provider session, or same incident sequence as the suspicious VPN session.

·        Increase confidence when downstream activity is rare for the user, new for the device, outside normal access windows, directed at sensitive tenants, directed at privileged applications, or inconsistent with the account’s role.

·        Reduce severity when downstream activity aligns with approved administrator workflows, cloud operations, SaaS administration, developer workflows, CI/CD maintenance, incident response, vendor support, security testing, or documented change-control activity.

·        Do not attribute cloud, SaaS, identity, developer-platform, source-code, or CI/CD anomalies to GlobalProtect compromise without VPN session linkage, source path linkage, identity linkage, device linkage, or incident-response validation.

Required Telemetry

·        VPN session telemetry.

·        GlobalProtect session context.

·        GlobalProtect tunnel-established events.

·        PAN-OS traffic logs.

·        DNS logs.

·        Proxy logs where available.

·        Secure web gateway logs where available.

·        Cloud access logs where available.

·        SaaS access logs where available.

·        Identity-provider logs.

·        Developer-platform logs where available.

·        Source-code platform logs where available.

·        CI/CD platform logs where available.

·        Cloud control-plane audit logs where available.

·        User identity.

·        Device identity.

·        Source IP.

·        VPN gateway.

·        Session identifier.

·        Tunnel identifier.

·        Identity-provider session.

·        Destination domain.

·        Application.

·        Protocol.

·        Timestamp.

·        Action.

·        Result.

·        Cloud account inventory.

·        SaaS tenant inventory.

·        Developer-platform inventory.

·        Source-code repository inventory.

·        CI/CD environment inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Application credential inventory.

·        Approved administrator workflow records.

·        Approved developer workflow records.

·        Approved cloud operations records.

·        Approved SaaS administration records.

·        Approved CI/CD maintenance records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Translate the SIGMA rule into the target SIEM only after validating cloud, SaaS, identity, developer-platform, source-code, CI/CD, and VPN field mappings.

·        Build suspicious VPN session groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, suspicious portal behavior, suspicious gateway behavior, and internal follow-on activity.

·        Build cloud and SaaS destination groups covering cloud consoles, cloud APIs, identity administration portals, SaaS administration portals, developer platforms, source-code platforms, CI/CD platforms, application management portals, and privileged business applications.

·        Build control-plane action groups for IAM changes, role assignment, access-key creation, API token creation, service-account use, application consent changes, MFA changes, conditional-access changes, repository access, repository cloning, CI/CD workflow modification, secret access, audit-log access, security-control changes, and data export.

·        Build linkage logic using user identity, device identity, source IP, VPN session window, tunnel identifier, gateway, identity-provider session, authentication session, destination application, and incident timeline.

·        Build downstream-risk groups for rare user activity, first-seen destination, privileged role use, sensitive tenant access, sensitive repository access, unusual API activity, source path mismatch, device mismatch, access outside normal windows, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for user, device, source IP, VPN session, tunnel identifier, gateway, identity-provider session, authentication session, destination application, destination domain, cloud account, SaaS tenant, event action, result, downstream-risk pattern, VPN-linkage status, and change-control context.

·        Validate event-action normalization across GlobalProtect, PAN-OS, identity-provider, MFA, DNS, proxy, secure web gateway, cloud, SaaS, developer-platform, source-code, CI/CD, endpoint, EDR, and SIEM telemetry before relying on translated rule behavior.

·        Validate backend support for VPN-to-control-plane linkage, identity-session correlation, source-path validation, device correlation, cloud and SaaS enrichment, developer-platform enrichment, enrichment joins, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate cloud, SaaS, or developer-platform activity after suspicious VPN establishment, delayed administrative activity, repository access, token use, CI/CD activity, source-code access, cloud API activity, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, SaaS administration, developer workflows, CI/CD maintenance, vendor support, security testing, incident response, and documented change-control activity.

·        Use short correlation windows when cloud, SaaS, or developer-platform activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed administrative activity, repository access, token use, CI/CD activity, source-code access, or cloud API activity after suspicious VPN establishment.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, or session continuity supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, destination validation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked downstream control-plane activity rather than static exploit strings, CVE identifiers, source IPs, domains, user-agent values, or isolated cloud anomalies.

·        The rule remains useful if an adversary changes cloud service, SaaS target, developer platform, API sequence, access method, source infrastructure, token use pattern, or post-session timing.

·        The score is supported by the durability of suspicious VPN session linkage, privileged cloud or SaaS action, developer-platform access, source-code access, CI/CD interaction, and control-plane behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-cloud linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, device mismatch, incomplete SaaS or developer-platform logs, and target-SIEM translation quality.

·        The rule is durable as downstream exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or cloud compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, identity-provider logs, cloud logs, SaaS logs, developer-platform logs, source-code logs, CI/CD logs, DNS or proxy visibility, source enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, cloud session reuse, token reuse, identity federation, source IP changes, or inconsistent device identifiers make VPN-to-cloud linkage uncertain.

·        Operational confidence is reduced where administrators, developers, cloud engineers, SaaS administrators, DevOps teams, vendors, or incident responders commonly perform control-plane actions after VPN access.

·        Full-telemetry confidence improves when cloud, SaaS, and developer-platform events are enriched with VPN session evidence, identity-provider session context, endpoint telemetry, source path evidence, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious downstream control-plane activity linked to suspicious VPN sessions, not authentication bypass or cloud compromise by itself.

·        SIGMA translation quality depends on whether the target SIEM can correlate VPN session evidence with cloud, SaaS, identity, source-code, developer-platform, and CI/CD telemetry.

·        Cloud, SaaS, identity, source-code, and CI/CD activity may be legitimate for administrators, developers, cloud engineers, DevOps staff, vendors, or incident responders.

·        VPN-to-cloud linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, or source IP transformation obscures path attribution.

·        The rule may miss downstream abuse that occurs outside the correlation window, from reused tokens, from a different device, from a different source path, or through a pre-existing cloud session.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA-style correlation pattern requiring target-SIEM translation validation, local field mapping, VPN session validation, identity-linkage validation, source-path validation, destination validation, control-plane action validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIGMA rule without backend-specific translation.

title: GlobalProtect Linked VPN Session Followed By Cloud SaaS Or Developer Platform Control Plane Activity
id: cyberdax-globalprotect-vpn-control-plane-activity
status: test
description: Detects cloud, SaaS, identity, source-code, CI/CD, or developer-platform control-plane activity linked to suspicious GlobalProtect VPN session context.
logsource:
category: application
detection:
selection_suspicious_vpn:
cyberdax.vpn_session.risk:
- authentication_lineage_gap
- portal_to_gateway_sequence_gap
- missing_identity_provider_evidence
- missing_mfa_evidence
- missing_hip_evidence
- unexpected_gateway_assignment
- source_not_in_user_baseline
- privileged_account_vpn_use
- third_party_account_vpn_use
- low_frequency_vpn_user
- suspicious_internal_followon_activity
selection_control_plane_destination:
cyberdax.destination.application_type:
- cloud_console
- cloud_api
- identity_administration_portal
- saas_administration_portal
- developer_platform
- source_code_platform
- cicd_platform
- privileged_business_application
selection_sensitive_action:
event.action:
- iam_change
- role_assignment
- access_key_created
- api_token_created
- service_account_used
- application_consent_changed
- mfa_changed
- conditional_access_changed
- repository_accessed
- repository_cloned
- cicd_workflow_modified
- secret_accessed
- audit_log_accessed
- security_control_changed
- data_exported
selection_downstream_risk:
cyberdax.control_plane.pattern:
- rare_user_activity
- first_seen_destination
- privileged_role_use
- sensitive_tenant_access
- sensitive_repository_access
- unusual_api_activity
- source_path_mismatch
- device_mismatch
- outside_normal_access_window
- activity_outside_expected_role
selection_linkage:
cyberdax.vpn_linkage.validated: true
filter_approved_context:
cyberdax.change_context.approved:
- approved_cloud_operations
- approved_saas_administration
- approved_developer_workflow
- approved_cicd_maintenance
- approved_vendor_support
- approved_security_testing
- approved_incident_response
- approved_change_control
condition: selection_suspicious_vpn and selection_control_plane_destination and selection_linkage and 1 of selection_sensitive_action,selection_downstream_risk and not filter_approved_context
fields:

·        user.name

·        source.ip

·        host.name

·        device.id

·        cloud.account.id

·        cloud.provider

·        destination.domain

·        event.action

·        cyberdax.vpn_session.risk

·        cyberdax.vpn_linkage.validated

·        cyberdax.control_plane.pattern
falsepositives:

·        Approved cloud operations

·        SaaS administration

·        Developer workflow

·        CI/CD maintenance

·        Vendor support

·        Security testing

·        Incident response

·        Approved change control
level: high

YARA

Detection Viability Assessment

YARA has zero primary rules for this EXP report.

·        YARA is not recommended for primary S25 detection because the governing detection model is behavior-led, not artifact-led.

·        The report’s strongest detection coverage comes from GlobalProtect authentication-lineage gaps, portal-to-gateway sequencing anomalies, trusted VPN session establishment, missing or inconsistent identity-provider evidence, missing or inconsistent MFA evidence, SAML or OIDC mismatch, HIP or device-posture inconsistency, gateway-assignment anomalies, unfamiliar source infrastructure, privileged or low-frequency account VPN use, VPN-authenticated internal reconnaissance, identity-service access, administrative protocol use, and downstream cloud, SaaS, or developer-platform correlation where applicable.

·        YARA does not observe GlobalProtect portal authentication, gateway authentication, tunnel establishment, authentication-lineage sequence gaps, identity-provider authentication, MFA decisions, conditional-access decisions, SAML or OIDC assertion context, certificate validation, HIP evaluation, gateway assignment, VPN session state, source infrastructure novelty, user-to-device correlation, post-session internal access, cloud activity, SaaS activity, or identity-session correlation.

·        YARA can support optional investigative hunting if responders recover a stable artifact during incident response, such as a webshell, loader, dropper, staged script, exploit payload, credential-access tool, remote-access tool, memory artifact, configuration artifact, encoded payload, suspicious binary, or reusable file-content pattern linked to suspicious VPN session establishment or downstream activity.

·        Including a primary YARA rule would create unnecessary artifact dependency and would be weaker than the accepted behavior-led rule sets for NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, and SIGMA.

·        YARA should remain a conditional investigative control rather than a primary detection system unless stable artifact evidence becomes available from the affected environment.

·        YARA should not be used to infer successful GlobalProtect exploitation, authentication bypass, trusted VPN session compromise, credential theft, token theft, endpoint compromise, identity compromise, cloud compromise, SaaS compromise, lateral movement, persistence, data access, or actor attribution without supporting endpoint, identity, cloud, SaaS, network, file, memory, or incident-response evidence.

Final Disposition

No primary YARA rule is included.

AWS

Detection Viability Assessment

AWS has three rules for this EXP report.

·        AWS is viable for detecting downstream cloud-control-plane, IAM, security-control, data-access, secrets-access, and workload-access activity that may follow GlobalProtect authentication-lineage failure, trusted VPN session compromise, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        AWS is strongest where CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, VPC Flow Logs, Route 53 Resolver logs, AWS Organizations logs, AWS Config, Security Hub, identity-provider logs, VPN session context, DNS or proxy telemetry, endpoint telemetry, source enrichment, account enrichment, and SIEM correlation can be combined.

·        AWS can identify suspicious post-VPN cloud behavior involving console access, role assumption, IAM changes, access-key creation, policy modification, security-control modification, sensitive data access, secret retrieval, key-management activity, workload access, cross-account activity, unusual API usage, and activity inconsistent with the user’s normal cloud role.

·        AWS is not a standalone source for confirming GlobalProtect exploitation, successful authentication bypass, MFA bypass, HIP bypass, endpoint compromise, credential theft, token theft, SaaS compromise, or actor attribution.

·        AWS detections must be correlated with GlobalProtect session evidence, PAN-OS logs, identity-provider evidence, MFA evidence, endpoint telemetry, network telemetry, source-path evidence, change-control records, and incident-response findings before classifying activity as probable GlobalProtect-linked compromise.

·        AWS rules should not generate high-confidence alerting from cloud activity alone, role assumption alone, access-key creation alone, console login alone, GuardDuty findings alone, unusual API usage alone, sensitive data access alone, or source-IP novelty alone without suspicious VPN session context or validated identity-path linkage.

Rule

GlobalProtect-Linked AWS Console or API Activity From Suspicious VPN Session Context

Rule Format

AWS cloud-control-plane correlation rule suitable for CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, VPC Flow Logs, Route 53 Resolver logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, AWS account inventory, privileged-role inventory, and SIEM correlation after AWS field validation, VPN-to-AWS linkage validation, identity-session validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect AWS console or API activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, source path, identity-provider session, device, VPN session window, authentication session, or incident timeline.

·        Identify possible downstream cloud exposure following trusted VPN session compromise, authentication-lineage failure, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        Prioritize activity involving privileged AWS roles, unusual role assumption, administrative API calls, first-seen regions, first-seen services, sensitive account access, cross-account activity, cloud-security-control interaction, or access inconsistent with the user’s normal AWS role.

·        Preserve separation between suspicious AWS activity and confirmed compromise by requiring supporting VPN session evidence, identity evidence, endpoint evidence, cloud evidence, credential-access evidence, token-access evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, AWS compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify AWS console access, API activity, role assumption, federated authentication, IAM Identity Center activity, STS activity, or CloudTrail events associated with a user or role that can be linked to suspicious GlobalProtect VPN session context.

·        Prioritize AWS activity after VPN sessions involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, source novelty, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on activity.

·        Detect AWS activity involving privileged role use, administrative API calls, IAM changes, STS AssumeRole activity, console login, first-seen region use, first-seen service use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive accounts.

·        Increase confidence when AWS activity shares the same user, identity-provider session, source IP, device identity, authentication session, VPN session window, or incident timeline as suspicious GlobalProtect activity.

·        Increase confidence when AWS activity involves IAM, Organizations, CloudTrail, GuardDuty, Security Hub, Config, KMS, Secrets Manager, S3, EC2, Lambda, EKS, RDS, Backup, Systems Manager, or other sensitive services not normally used by the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, cloud CLI use, unusual session creation, suspicious OAuth consent, or post-session administrative behavior.

·        Reduce severity when AWS activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, or documented change-control activity.

·        Do not attribute AWS activity to GlobalProtect compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

·        Do not treat AWS console activity, API activity, role assumption, GuardDuty findings, CloudTrail anomalies, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where available.

·        AWS IAM logs and configuration context.

·        AWS IAM Identity Center logs where available.

·        AWS STS events.

·        AWS Organizations logs where available.

·        AWS Config logs where available.

·        AWS Security Hub findings where available.

·        Amazon GuardDuty findings where available.

·        VPC Flow Logs where available.

·        Route 53 Resolver logs where available.

·        AWS console login events.

·        CloudTrail userIdentity fields.

·        CloudTrail sourceIPAddress fields.

·        CloudTrail userAgent fields.

·        CloudTrail eventSource fields.

·        CloudTrail eventName fields.

·        CloudTrail recipientAccountId fields.

·        CloudTrail awsRegion fields.

·        Identity-provider logs.

·        MFA logs.

·        Conditional-access logs where available.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS traffic and authentication logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        AWS account inventory.

·        AWS organization inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build suspicious GlobalProtect VPN session groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build AWS identity groups covering IAM users, IAM roles, federated users, IAM Identity Center users, privileged roles, break-glass roles, automation roles, CI/CD roles, service accounts, cross-account roles, and externally trusted roles.

·        Build AWS sensitive service groups covering IAM, STS, Organizations, CloudTrail, GuardDuty, Security Hub, Config, KMS, Secrets Manager, S3, EC2, Lambda, EKS, RDS, Backup, Systems Manager, and other locally sensitive services.

·        Build AWS high-risk action groups for ConsoleLogin, AssumeRole, CreateAccessKey, AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, CreatePolicyVersion, SetDefaultPolicyVersion, UpdateAssumeRolePolicy, CreateUser, CreateLoginProfile, AddUserToGroup, CreateRole, PassRole, DisableMFADevice, DeleteVirtualMFADevice, StopLogging, DeleteTrail, UpdateTrail, PutBucketPolicy, GetSecretValue, Decrypt, and security-control modification.

·        Build linkage logic using user identity, identity-provider session, source IP, device identity, VPN session window, authentication session, tunnel identifier, gateway, destination application, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, CloudTrail userAgent, and incident timeline.

·        Build AWS anomaly groups for first-seen region, first-seen service, rare API call, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive account access, and cross-account activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, AWS principal ID, user identity, role name, assumed-role session name, source IP, user agent, event source, event name, region, result, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, identity-provider logs, MFA logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-AWS linkage, identity-session correlation, source-path validation, device correlation, CloudTrail enrichment, AWS account enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate AWS access after suspicious VPN establishment, delayed role assumption, delayed administrative activity, delayed cloud API activity, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, vendor support, security testing, incident response, break-glass use, and documented change-control activity.

·        Use short correlation windows when AWS console or API activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed role assumption, administrative activity, secret access, S3 access, cloud API activity, or security-control interaction after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, CloudTrail continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, CloudTrail field availability, AWS account inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked AWS control-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated AWS anomalies.

·        The rule remains useful if an adversary changes AWS service target, API sequence, role path, source infrastructure, session timing, token use pattern, or post-session cloud activity.

·        The score is supported by the durability of suspicious VPN session linkage, privileged role use, administrative API activity, first-seen service or region use, source-path mismatch, and AWS behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-AWS linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, assumed-role abstraction, incomplete CloudTrail coverage, and target-SIEM translation quality.

·        The rule is durable as downstream AWS exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or AWS compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, CloudTrail coverage, IAM Identity Center telemetry, identity-provider logs, MFA logs, AWS account inventory, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, NAT, identity federation, cloud session reuse, token reuse, assumed-role naming, inconsistent source IPs, or missing device identifiers make VPN-to-AWS linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform AWS administrative actions after VPN access.

·        Full-telemetry confidence improves when AWS events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider session context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS control-plane activity linked to suspicious VPN sessions, not GlobalProtect authentication bypass or AWS compromise by itself.

·        AWS may not preserve enough source-path, device, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        CloudTrail activity may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        VPN-to-AWS linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, assumed-role abstraction, or source IP transformation obscures path attribution.

·        The rule may miss AWS abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation role, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS cloud-control-plane correlation pattern requiring target-SIEM translation validation, CloudTrail field validation, VPN session validation, identity-linkage validation, source-path validation, AWS account validation, sensitive action validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsControlPlaneActivity
WHERE AwsControlPlaneActivity.eventName IN ANY (
"ConsoleLogin",
"AssumeRole",
"CreateAccessKey",
"AttachUserPolicy",
"AttachRolePolicy",
"PutUserPolicy",
"PutRolePolicy",
"CreatePolicyVersion",
"SetDefaultPolicyVersion",
"UpdateAssumeRolePolicy",
"CreateUser",
"CreateLoginProfile",
"AddUserToGroup",
"CreateRole",
"PassRole",
"DisableMFADevice",
"DeleteVirtualMFADevice",
"StopLogging",
"DeleteTrail",
"UpdateTrail",
"PutBucketPolicy",
"GetSecretValue",
"Decrypt"
)
AND AwsControlPlaneActivity.userIdentity.type IN ANY (
"IAMUser",
"AssumedRole",
"FederatedUser",
"Root"
)
AND AwsControlPlaneActivity.recipientAccountId IN ASSET_GROUP (
"Sensitive AWS Accounts",
"Production AWS Accounts",
"Security Tooling Accounts",
"Identity Management Accounts",
"Backup Accounts",
"Developer Platform Accounts"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AWS_CONTROL_PLANE_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AwsControlPlaneActivity.userIdentity)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AwsControlPlaneActivity.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AwsControlPlaneActivity.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AwsControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AwsControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_region",
"first_seen_service",
"rare_api_call",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_account_access",
"cross_account_activity"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

GlobalProtect-Linked AWS IAM or Security-Control Modification

Rule Format

AWS IAM and security-control correlation rule suitable for CloudTrail, IAM, AWS Organizations, AWS Config, Security Hub, GuardDuty, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, privileged-role inventory, and SIEM correlation after AWS IAM field validation, privileged-action validation, VPN-to-AWS linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect AWS IAM, AWS Organizations, CloudTrail, GuardDuty, Security Hub, AWS Config, KMS, S3, or security-control modifications after suspicious GlobalProtect VPN session context.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following trusted VPN session compromise.

·        Prioritize changes involving privileged roles, access keys, trust policies, inline policies, managed policy attachment, role creation, role assumption paths, logging controls, monitoring controls, encryption controls, bucket policies, security findings, and organization-level controls.

·        Preserve separation between suspicious AWS modification and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, CloudTrail evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, AWS compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

·        Identify IAM, Organizations, CloudTrail, GuardDuty, Security Hub, AWS Config, KMS, S3, or security-control modification events in CloudTrail or related AWS telemetry.

·        Correlate modification events with suspicious GlobalProtect VPN session context involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or suspicious internal follow-on activity.

·        Prioritize IAM activity involving CreateAccessKey, CreateUser, CreateLoginProfile, CreateRole, UpdateAssumeRolePolicy, AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, CreatePolicyVersion, SetDefaultPolicyVersion, PassRole, AddUserToGroup, CreatePolicy, or privilege-expanding trust-policy changes.

·        Prioritize security-control activity involving StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, DeleteDetector, UpdateDetector, BatchDisableStandards, DisableSecurityHub, PutBucketPolicy, PutKeyPolicy, ScheduleKeyDeletion, or changes that reduce visibility, encryption, alerting, monitoring, or access control.

·        Increase confidence when changes affect production accounts, security tooling accounts, identity-management accounts, backup accounts, developer-platform accounts, cross-account trust paths, privileged roles, or sensitive data services.

·        Increase confidence when activity is rare for the user, rare for the account, outside normal access windows, uses unusual user agents, follows suspicious VPN activity, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, or documented change-control activity.

·        Do not classify AWS IAM or security-control modification as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS IAM events.

·        AWS STS events.

·        AWS Organizations events where available.

·        AWS Config configuration history.

·        AWS Security Hub findings where available.

·        Amazon GuardDuty findings where available.

·        AWS KMS events where available.

·        Amazon S3 data and management events where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        Endpoint telemetry where available.

·        DNS or proxy logs where available.

·        AWS account inventory.

·        AWS organization inventory.

·        Privileged role inventory.

·        Cross-account trust inventory.

·        Service-account inventory.

·        Security tooling inventory.

·        Sensitive data-service inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build AWS IAM modification groups covering user creation, access-key creation, login-profile creation, role creation, role policy updates, trust-policy updates, managed-policy attachment, inline-policy changes, policy-version creation, default-policy-version changes, group membership changes, PassRole usage, and privilege-expanding trust relationships.

·        Build AWS security-control modification groups covering CloudTrail changes, GuardDuty changes, Security Hub changes, AWS Config changes, KMS policy changes, S3 bucket policy changes, logging changes, monitoring changes, encryption changes, and alerting-control changes.

·        Build sensitive AWS account groups covering production accounts, identity-management accounts, security tooling accounts, backup accounts, developer-platform accounts, shared-services accounts, and accounts containing sensitive workloads or sensitive data.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build linkage logic using user identity, role session name, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, principal ID, role name, assumed-role session name, event source, event name, source IP, user agent, region, request parameters, response elements, error code, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across CloudTrail, IAM, STS, AWS Organizations, AWS Config, GuardDuty, Security Hub, KMS, S3, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-AWS linkage, identity-session correlation, source-path validation, CloudTrail request-parameter parsing, AWS account enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate IAM or security-control modification after suspicious VPN establishment, delayed administrative activity, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, vendor support, security testing, incident response, and documented change-control activity.

·        Use short correlation windows when IAM or security-control changes occur immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed IAM changes, policy changes, role changes, logging changes, monitoring changes, encryption changes, or security-control modifications after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, CloudTrail continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, CloudTrail field availability, AWS account inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to AWS IAM and security-control modification after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, access-key usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of IAM changes, policy changes, role changes, trust-policy modification, access-key creation, logging modification, monitoring-control changes, and security-control weakening after suspicious remote-access context.

·        The score is constrained by weak VPN-to-AWS linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete CloudTrail coverage, and target-SIEM translation quality.

·        The rule is durable as AWS persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of GlobalProtect compromise or AWS compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on CloudTrail coverage, IAM telemetry, AWS account inventory, privileged-role inventory, identity-provider logs, VPN session mapping, source enrichment, change-control records, and SIEM correlation quality.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make IAM or security-control changes through VPN access.

·        Operational confidence is reduced where assumed-role naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete request-parameter parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when AWS modification events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS IAM or security-control modification linked to suspicious VPN context, not GlobalProtect exploitation or AWS compromise by itself.

·        CloudTrail may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar IAM or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying IAM or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        AWS activity should not be attributed to GlobalProtect compromise without VPN session linkage, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS IAM and security-control modification correlation pattern requiring target-SIEM translation validation, CloudTrail field validation, IAM action validation, security-control action validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsIamOrSecurityModification
WHERE AwsIamOrSecurityModification.eventName IN ANY (
"CreateAccessKey",
"CreateUser",
"CreateLoginProfile",
"CreateRole",
"UpdateAssumeRolePolicy",
"AttachUserPolicy",
"AttachRolePolicy",
"PutUserPolicy",
"PutRolePolicy",
"CreatePolicy",
"CreatePolicyVersion",
"SetDefaultPolicyVersion",
"AddUserToGroup",
"PassRole",
"StopLogging",
"DeleteTrail",
"UpdateTrail",
"PutEventSelectors",
"DeleteDetector",
"UpdateDetector",
"BatchDisableStandards",
"DisableSecurityHub",
"PutBucketPolicy",
"PutKeyPolicy",
"ScheduleKeyDeletion"
)
AND AwsIamOrSecurityModification.recipientAccountId IN ASSET_GROUP (
"Production AWS Accounts",
"Security Tooling Accounts",
"Identity Management Accounts",
"Backup Accounts",
"Developer Platform Accounts",
"Shared Services Accounts",
"Sensitive Data Accounts"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AWS_MODIFICATION_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AwsIamOrSecurityModification.userIdentity)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AwsIamOrSecurityModification.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AwsIamOrSecurityModification.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AwsIamOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AwsIamOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsIamOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"access_key_created",
"trust_policy_modified",
"policy_version_changed",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"encryption_control_modified",
"cross_account_trust_modified",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

GlobalProtect-Linked AWS Data, Secrets, or Workload Access After Suspicious VPN Context

Rule Format

AWS data and workload access correlation rule suitable for CloudTrail data events, S3 data events, KMS events, Secrets Manager events, Systems Manager events, EC2 events, Lambda events, RDS events, EKS events, VPC Flow Logs, Route 53 Resolver logs, GuardDuty findings, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, sensitive-asset inventory, and SIEM correlation after AWS data-event validation, workload validation, VPN-to-AWS linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect sensitive AWS data, secrets, key-management, workload, or remote-management access after suspicious GlobalProtect VPN session context.

·        Identify downstream cloud exposure where trusted VPN session compromise may lead to secret retrieval, data access, workload discovery, remote command execution, snapshot access, backup access, or cloud-hosted system interaction.

·        Prioritize activity involving Secrets Manager, KMS decrypt operations, S3 data access, Systems Manager session or command activity, EC2 instance interaction, Lambda function access, RDS snapshot or backup access, EKS activity, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious AWS data or workload access and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, CloudTrail evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, AWS compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify AWS data, secrets, key-management, workload, or remote-management events after suspicious GlobalProtect VPN session context.

·        Correlate AWS data or workload access with suspicious VPN activity involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on behavior.

·        Prioritize GetSecretValue, Decrypt, GetObject, ListBuckets, ListObjects, StartSession, SendCommand, CreateSnapshot, CopySnapshot, DescribeInstances, GetFunction, ListFunctions, DescribeDBSnapshots, RestoreDBInstanceFromDBSnapshot, EKS cluster access, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive buckets, secrets, KMS keys, production instances, backup data, database snapshots, administrative Systems Manager paths, EKS clusters, or developer-platform workloads.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows suspicious VPN session activity, or lacks approved change-control context.

·        Increase confidence when GuardDuty, Security Hub, endpoint telemetry, DNS telemetry, proxy telemetry, or VPC Flow Logs show supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, or documented change-control activity.

·        Do not classify AWS data, secrets, or workload access as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat AWS data access, secret access, KMS use, Systems Manager activity, workload access, GuardDuty findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where available.

·        Amazon S3 data events where available.

·        AWS KMS events.

·        AWS Secrets Manager events.

·        AWS Systems Manager events.

·        Amazon EC2 events.

·        AWS Lambda events.

·        Amazon RDS events where available.

·        Amazon EKS events where available.

·        AWS Backup events where available.

·        VPC Flow Logs where available.

·        Route 53 Resolver logs where available.

·        GuardDuty findings where available.

·        Security Hub findings where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        AWS account inventory.

·        Sensitive S3 bucket inventory.

·        Secrets Manager inventory.

·        KMS key inventory.

·        Production workload inventory.

·        Backup inventory.

·        Database and snapshot inventory.

·        EKS cluster inventory.

·        Systems Manager managed-instance inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build sensitive AWS data groups covering sensitive S3 buckets, production data buckets, backup buckets, regulated-data buckets, Secrets Manager secrets, KMS keys, RDS snapshots, database backups, EBS snapshots, Lambda functions, EKS clusters, Systems Manager managed instances, and production workloads.

·        Build AWS sensitive action groups for GetSecretValue, Decrypt, GetObject, ListBuckets, ListObjects, StartSession, SendCommand, CreateSnapshot, CopySnapshot, DescribeInstances, GetFunction, ListFunctions, DescribeDBSnapshots, RestoreDBInstanceFromDBSnapshot, DescribeCluster, and locally sensitive workload-access events.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build source-path and identity linkage logic using user identity, role session name, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, backup access, workload remote-management activity, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, principal ID, role name, assumed-role session name, event source, event name, source IP, user agent, region, resource ARN, bucket name, secret name, key ID, instance ID, function name, database snapshot identifier, EKS cluster name, response result, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across CloudTrail management events, CloudTrail data events, S3 data events, KMS events, Secrets Manager events, Systems Manager events, EC2 events, Lambda events, RDS events, EKS events, VPC Flow Logs, Route 53 Resolver logs, GuardDuty, Security Hub, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-AWS linkage, identity-session correlation, source-path validation, resource-ARN parsing, sensitive-asset enrichment, cloud-account enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate data, secrets, or workload access after suspicious VPN establishment, delayed secret retrieval, delayed KMS use, delayed data access, delayed Systems Manager activity, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, vendor support, security testing, incident response, emergency access, and documented change-control activity.

·        Use short correlation windows when AWS data, secrets, or workload access occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed secrets access, KMS use, S3 data access, Systems Manager activity, workload access, backup access, or snapshot activity after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, CloudTrail continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, CloudTrail data-event availability, sensitive-asset inventory, AWS account inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to AWS data, secrets, key-management, and workload access after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the AWS service target, data-access sequence, role path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, KMS decrypt operations, sensitive S3 access, Systems Manager activity, workload access, backup access, snapshot interaction, and sensitive cloud-resource access after suspicious remote-access context.

·        The score is constrained by weak VPN-to-AWS linkage, incomplete CloudTrail data events, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, assumed-role abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as AWS data and workload exposure coverage but should not be treated as standalone proof of GlobalProtect compromise, AWS compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on CloudTrail management events, CloudTrail data events, sensitive-asset inventory, AWS account inventory, identity-provider logs, VPN session mapping, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where S3 data events, KMS events, Secrets Manager events, Systems Manager events, workload events, or VPC Flow Logs are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive AWS data or workloads after VPN access.

·        Full-telemetry confidence improves when AWS data and workload activity is enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, VPC Flow Logs, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS data, secrets, or workload access linked to suspicious VPN context, not GlobalProtect exploitation or AWS compromise by itself.

·        CloudTrail data events may not be enabled for all buckets, objects, workloads, or sensitive resources.

·        AWS may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation roles, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, CloudTrail data-event validation, resource-field validation, sensitive-asset validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsSensitiveResourceAccess
WHERE AwsSensitiveResourceAccess.eventName IN ANY (
"GetSecretValue",
"Decrypt",
"GetObject",
"ListBuckets",
"ListObjects",
"StartSession",
"SendCommand",
"CreateSnapshot",
"CopySnapshot",
"DescribeInstances",
"GetFunction",
"ListFunctions",
"DescribeDBSnapshots",
"RestoreDBInstanceFromDBSnapshot",
"DescribeCluster"
)
AND AwsSensitiveResourceAccess.Resource IN ASSET_GROUP (
"Sensitive S3 Buckets",
"Production Data Buckets",
"Backup Buckets",
"Regulated Data Buckets",
"Secrets Manager Secrets",
"KMS Keys",
"RDS Snapshots",
"Database Backups",
"EBS Snapshots",
"Lambda Functions",
"EKS Clusters",
"Systems Manager Managed Instances",
"Production Workloads"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AWS_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AwsSensitiveResourceAccess.userIdentity)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AwsSensitiveResourceAccess.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AwsSensitiveResourceAccess.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AwsSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AwsSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"backup_access",
"workload_remote_management_activity",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

Azure

Detection Viability Assessment

Azure has three rules for this EXP report.

·        Azure is viable for detecting downstream identity-plane, cloud-control-plane, resource-access, key-vault, workload, and administrative activity that may follow GlobalProtect authentication-lineage failure, trusted VPN session compromise, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        Azure is strongest where Microsoft Entra ID sign-in logs, Entra ID audit logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Microsoft Defender for Cloud alerts, Azure Key Vault logs, Storage logs, Azure Monitor logs, identity-provider telemetry, MFA context, GlobalProtect session context, endpoint telemetry, DNS or proxy telemetry, source enrichment, tenant inventory, subscription inventory, and SIEM correlation can be combined.

·        Azure can identify suspicious post-VPN cloud behavior involving privileged role use, administrative portal activity, Azure Resource Manager operations, role assignment, application or service-principal changes, conditional-access changes, Key Vault access, storage access, workload interaction, and activity inconsistent with the user’s normal cloud role.

·        Azure is not a standalone source for confirming GlobalProtect exploitation, successful authentication bypass, MFA bypass, HIP bypass, endpoint compromise, credential theft, token theft, SaaS compromise, or actor attribution.

·        Azure detections must be correlated with GlobalProtect session evidence, PAN-OS logs, Entra ID sign-in evidence, MFA evidence, endpoint telemetry, network telemetry, source-path evidence, change-control records, and incident-response findings before classifying activity as probable GlobalProtect-linked compromise.

·        Azure rules should not generate high-confidence alerting from cloud activity alone, role assignment alone, Azure portal access alone, Entra ID sign-in novelty alone, Key Vault access alone, storage access alone, Defender for Cloud alerting alone, or source-IP novelty alone without suspicious VPN session context or validated identity-path linkage.

Rule

GlobalProtect-Linked Azure Portal, Entra ID, or Resource Manager Activity From Suspicious VPN Session Context

Rule Format

Azure cloud-control-plane correlation rule suitable for Microsoft Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Azure Monitor logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, privileged-role inventory, tenant inventory, subscription inventory, and SIEM correlation after Azure field validation, VPN-to-Azure linkage validation, identity-session validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect Azure portal, Microsoft Entra ID, Azure Resource Manager, or administrative API activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, identity-provider session, VPN session window, authentication session, or incident timeline.

·        Identify possible downstream Azure exposure following trusted VPN session compromise, authentication-lineage failure, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        Prioritize activity involving privileged Azure roles, administrative portal access, Azure Resource Manager operations, first-seen subscriptions, first-seen resource groups, first-seen services, unusual source paths, unusual user agents, and access inconsistent with the user’s normal Azure role.

·        Preserve separation between suspicious Azure activity and confirmed compromise by requiring supporting VPN session evidence, identity evidence, endpoint evidence, cloud evidence, credential-access evidence, token-access evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, Azure compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

Identify Azure portal access, Entra ID sign-in activity, Azure Resource Manager activity, administrative API activity, role use, service-principal activity, managed-identity activity, or Azure Activity events associated with a user, role, service principal, or identity that can be linked to suspicious GlobalProtect VPN session context.

·        Prioritize Azure activity after VPN sessions involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, source novelty, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on activity.

·        Detect Azure activity involving privileged role use, administrative operations, role assignment, first-seen subscription use, first-seen resource group use, first-seen service use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive tenants, subscriptions, or resource groups.

·        Increase confidence when Azure activity shares the same user, device, identity-provider session, source IP, authentication session, VPN session window, or incident timeline as suspicious GlobalProtect activity.

·        Increase confidence when Azure activity involves Microsoft Entra ID, Azure Resource Manager, subscriptions, management groups, Key Vault, Storage, virtual machines, network security groups, Azure Firewall, Azure Kubernetes Service, Azure SQL, Backup, Recovery Services, Defender for Cloud, Sentinel, or other sensitive services not normally used by the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, Azure CLI use, PowerShell cloud-administration activity, unusual session creation, suspicious OAuth consent, or post-session administrative behavior.

·        Reduce severity when Azure activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, or documented change-control activity.

·        Do not attribute Azure activity to GlobalProtect compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

·        Do not treat Azure portal activity, Entra ID sign-in novelty, Resource Manager activity, role use, Defender for Cloud findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID risk events where available.

·        Microsoft Entra ID conditional-access logs where available.

·        Microsoft Entra ID MFA context.

·        Service-principal sign-in logs where available.

·        Managed-identity activity where available.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure Monitor logs where available.

·        Microsoft Defender for Cloud alerts where available.

·        Microsoft Sentinel logs where available.

·        Azure subscription inventory.

·        Azure tenant inventory.

·        Management group inventory where available.

·        Privileged role inventory.

·        Service-principal inventory.

·        Managed-identity inventory.

·        Azure portal access context.

·        User identity.

·        Device identity.

·        Source IP.

·        User agent.

·        Application ID.

·        Resource ID.

·        Subscription ID.

·        Tenant ID.

·        Operation name.

·        Result.

·        Timestamp.

·        Identity-provider logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS traffic and authentication logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build suspicious GlobalProtect VPN session groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build Azure identity groups covering users, privileged users, administrators, service principals, managed identities, break-glass accounts, automation identities, CI/CD identities, externally trusted identities, guest users, and third-party identities.

·        Build Azure sensitive service groups covering Microsoft Entra ID, Azure Resource Manager, subscriptions, management groups, Key Vault, Storage, virtual machines, network security groups, Azure Firewall, Azure Kubernetes Service, Azure SQL, Backup, Recovery Services vaults, Defender for Cloud, Sentinel, and other locally sensitive services.

·        Build Azure high-risk action groups for privileged role use, role assignment, owner or contributor activity, Azure portal administration, service-principal activity, managed-identity activity, resource creation, resource deletion, policy change, network security group modification, Key Vault access, Storage access, virtual machine command execution, and security-control interaction.

·        Build linkage logic using user identity, device identity, identity-provider session, source IP, user agent, authentication session, VPN session window, tunnel identifier, gateway, destination application, tenant ID, subscription ID, application ID, resource ID, and incident timeline.

·        Build Azure anomaly groups for first-seen subscription, first-seen resource group, first-seen service, rare operation, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive tenant access, and cross-tenant or cross-subscription activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, user identity, device identity, service principal, managed identity, source IP, user agent, operation name, result, application ID, identity-provider session, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across Entra ID sign-in logs, Entra ID audit logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Defender for Cloud, Azure Monitor, identity-provider logs, MFA logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-Azure linkage, identity-session correlation, source-path validation, device correlation, Azure Activity enrichment, tenant enrichment, subscription enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate Azure access after suspicious VPN establishment, delayed role use, delayed administrative activity, delayed Resource Manager activity, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, vendor support, security testing, incident response, break-glass use, and documented change-control activity.

·        Use short correlation windows when Azure portal, Entra ID, or Resource Manager activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed role use, administrative activity, Key Vault access, Storage access, Resource Manager operations, or security-control interaction after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Azure Activity continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, Azure field availability, tenant inventory, subscription inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked Azure control-plane and identity-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated Azure anomalies.

·        The rule remains useful if an adversary changes Azure service target, API sequence, role path, source infrastructure, session timing, token use pattern, or post-session cloud activity.

·        The score is supported by the durability of suspicious VPN session linkage, privileged role use, administrative operation, first-seen service or subscription use, source-path mismatch, and Azure behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-Azure linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, service-principal abstraction, incomplete Azure logging, and target-SIEM translation quality.

·        The rule is durable as downstream Azure exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or Azure compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, identity-provider logs, MFA logs, tenant inventory, subscription inventory, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, NAT, identity federation, cloud session reuse, token reuse, service-principal naming, inconsistent source IPs, or missing device identifiers make VPN-to-Azure linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform Azure administrative actions after VPN access.

·        Full-telemetry confidence improves when Azure events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider session context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious Azure identity-plane or control-plane activity linked to suspicious VPN sessions, not GlobalProtect authentication bypass or Azure compromise by itself.

·        Azure may not preserve enough source-path, device, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Azure portal, Entra ID, and Azure Activity events may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        VPN-to-Azure linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, service-principal abstraction, or source IP transformation obscures path attribution.

·        The rule may miss Azure abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation identity, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure identity-plane and control-plane correlation pattern requiring target-SIEM translation validation, Entra ID field validation, Azure Activity field validation, VPN session validation, identity-linkage validation, source-path validation, tenant and subscription validation, sensitive action validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrIdentityEvent AS AzureControlPlaneActivity
WHERE AzureControlPlaneActivity.OperationName IN ANY (
"UserLoggedIn",
"InteractiveUserSignIn",
"ServicePrincipalSignIn",
"RoleAssignmentCreated",
"RoleAssignmentUpdated",
"AddMemberToRole",
"AddOwnerToApplication",
"AddPasswordCredential",
"AddKeyCredential",
"CreateServicePrincipal",
"UpdateApplication",
"CreateOrUpdateResource",
"DeleteResource",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/policyAssignments/write",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.KeyVault/vaults/read",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Compute/virtualMachines/runCommand/action"
)
AND AzureControlPlaneActivity.IdentityType IN ANY (
"User",
"ServicePrincipal",
"ManagedIdentity",
"FederatedIdentity"
)
AND AzureControlPlaneActivity.SubscriptionId IN ASSET_GROUP (
"Sensitive Azure Subscriptions",
"Production Azure Subscriptions",
"Security Tooling Subscriptions",
"Identity Management Subscriptions",
"Backup Subscriptions",
"Developer Platform Subscriptions"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AZURE_CONTROL_PLANE_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AzureControlPlaneActivity.User)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AzureControlPlaneActivity.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AzureControlPlaneActivity.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AzureControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AzureControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_subscription",
"first_seen_resource_group",
"first_seen_service",
"rare_operation",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_tenant_access",
"cross_subscription_activity"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

GlobalProtect-Linked Azure Identity, Role, or Security-Control Modification

Rule Format

Azure identity, role, and security-control correlation rule suitable for Entra ID audit logs, Entra ID sign-in logs, Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Azure Policy events, Key Vault logs, Storage logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, privileged-role inventory, tenant inventory, subscription inventory, and SIEM correlation after Azure identity-field validation, privileged-action validation, VPN-to-Azure linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect Azure identity, role, service-principal, application, conditional-access, policy, logging, monitoring, or security-control modifications after suspicious GlobalProtect VPN session context.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following trusted VPN session compromise.

·        Prioritize changes involving privileged role assignments, service-principal credentials, application credentials, app ownership, conditional-access policies, authentication methods, security defaults, logging controls, monitoring controls, policy assignments, network security groups, Key Vault permissions, and storage access controls.

·        Preserve separation between suspicious Azure modification and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, Azure audit evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, Azure compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

Identify Entra ID, Azure Activity, Azure Resource Manager, Azure Policy, Defender for Cloud, Key Vault, Storage, or security-control modification events in Azure telemetry.

·        Correlate modification events with suspicious GlobalProtect VPN session context involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or suspicious internal follow-on activity.

·        Prioritize identity and role activity involving role assignment, group membership change, privileged role activation, app owner addition, application update, service-principal creation, service-principal credential creation, application credential creation, authentication-method change, conditional-access change, or privileged access configuration change.

·        Prioritize security-control activity involving policy assignment changes, diagnostic setting changes, log profile changes, Defender for Cloud changes, security alert suppression, network security group changes, Key Vault access-policy changes, storage access changes, or changes that reduce visibility, encryption, monitoring, alerting, or access control.

·        Increase confidence when changes affect production subscriptions, identity-management tenants, security tooling subscriptions, backup subscriptions, developer-platform subscriptions, privileged roles, sensitive applications, cross-tenant trust paths, Key Vaults, storage accounts, or sensitive workloads.

·        Increase confidence when activity is rare for the user, rare for the tenant, outside normal access windows, uses unusual user agents, follows suspicious VPN activity, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, or documented change-control activity.

·        Do not classify Azure identity, role, or security-control modification as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

Microsoft Entra ID audit logs.

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID risk events where available.

·        Microsoft Entra ID conditional-access logs where available.

·        Microsoft Entra ID authentication-method logs where available.

·        Service-principal sign-in logs where available.

·        Managed-identity activity where available.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure Policy events where available.

·        Defender for Cloud alerts where available.

·        Azure Monitor logs where available.

·        Azure diagnostic setting logs where available.

·        Key Vault logs where available.

·        Storage account logs where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        Endpoint telemetry where available.

·        DNS or proxy logs where available.

·        Tenant inventory.

·        Subscription inventory.

·        Privileged role inventory.

·        Service-principal inventory.

·        Application registration inventory.

·        Managed-identity inventory.

·        Cross-tenant trust inventory.

·        Security tooling inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build Azure identity modification groups covering role assignment, role activation, group membership changes, privileged role changes, app owner additions, application updates, service-principal creation, service-principal credential additions, app credential additions, authentication-method changes, conditional-access changes, and privileged access configuration changes.

·        Build Azure security-control modification groups covering policy assignment changes, diagnostic setting changes, log profile changes, Defender for Cloud changes, alert suppression changes, network security group changes, Key Vault permission changes, storage access changes, monitoring changes, logging changes, encryption changes, and access-control changes.

·        Build sensitive Azure tenant and subscription groups covering production subscriptions, identity-management tenants, security tooling subscriptions, backup subscriptions, developer-platform subscriptions, shared-services subscriptions, and subscriptions containing sensitive workloads or sensitive data.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build linkage logic using user identity, service-principal identity, managed identity, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, tenant ID, subscription ID, resource ID, Azure Activity fields, Entra ID audit fields, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, user identity, service principal, managed identity, role name, app ID, source IP, user agent, operation name, result, request parameters, modified properties, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across Entra ID audit logs, Entra ID sign-in logs, Entra ID authentication-method logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Azure Policy, Defender for Cloud, Azure Monitor, Key Vault, Storage, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-Azure linkage, identity-session correlation, source-path validation, Azure audit-field parsing, tenant enrichment, subscription enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate identity, role, or security-control modification after suspicious VPN establishment, delayed administrative activity, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, vendor support, security testing, incident response, and documented change-control activity.

·        Use short correlation windows when identity, role, or security-control changes occur immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed identity changes, role changes, policy changes, logging changes, monitoring changes, encryption changes, or security-control modifications after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Azure Activity continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, Azure field availability, tenant inventory, subscription inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to Azure identity, role, and security-control modification after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, app credential usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of role assignments, privileged role changes, service-principal credential changes, app credential changes, conditional-access changes, policy changes, diagnostic-setting changes, network security group changes, and security-control weakening after suspicious remote-access context.

·        The score is constrained by weak VPN-to-Azure linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete Azure logging, service-principal abstraction, and target-SIEM translation quality.

·        The rule is durable as Azure persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of GlobalProtect compromise or Azure compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Entra ID audit coverage, Azure Activity coverage, tenant inventory, subscription inventory, privileged-role inventory, identity-provider logs, VPN session mapping, source enrichment, change-control records, and SIEM correlation quality.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make identity, role, or security-control changes through VPN access.

·        Operational confidence is reduced where service-principal naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete modified-property parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when Azure modification events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious Azure identity, role, or security-control modification linked to suspicious VPN context, not GlobalProtect exploitation or Azure compromise by itself.

·        Azure logs may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar identity, role, or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying identity or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        Azure activity should not be attributed to GlobalProtect compromise without VPN session linkage, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure identity, role, and security-control modification correlation pattern requiring target-SIEM translation validation, Entra ID audit-field validation, Azure Activity field validation, privileged-action validation, security-control action validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrAuditEvent AS AzureIdentityOrSecurityModification
WHERE AzureIdentityOrSecurityModification.OperationName IN ANY (
"RoleAssignmentCreated",
"RoleAssignmentUpdated",
"AddMemberToRole",
"AddMemberToGroup",
"AddOwnerToApplication",
"AddPasswordCredential",
"AddKeyCredential",
"CreateServicePrincipal",
"UpdateServicePrincipal",
"UpdateApplication",
"UpdateConditionalAccessPolicy",
"UpdateAuthenticationMethodsPolicy",
"DisableSecurityDefaults",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/policyAssignments/write",
"Microsoft.Insights/diagnosticSettings/write",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.KeyVault/vaults/accessPolicies/write",
"Microsoft.Storage/storageAccounts/write"
)
AND AzureIdentityOrSecurityModification.SubscriptionId IN ASSET_GROUP (
"Production Azure Subscriptions",
"Security Tooling Subscriptions",
"Identity Management Subscriptions",
"Backup Subscriptions",
"Developer Platform Subscriptions",
"Shared Services Subscriptions",
"Sensitive Data Subscriptions"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AZURE_MODIFICATION_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AzureIdentityOrSecurityModification.User)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AzureIdentityOrSecurityModification.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AzureIdentityOrSecurityModification.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AzureIdentityOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AzureIdentityOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureIdentityOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"service_principal_credential_added",
"application_credential_added",
"conditional_access_modified",
"authentication_method_modified",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"network_security_group_modified",
"key_vault_access_modified",
"cross_tenant_trust_modified",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

GlobalProtect-Linked Azure Data, Secrets, or Workload Access After Suspicious VPN Context

Rule Format

Azure data, secrets, and workload access correlation rule suitable for Key Vault logs, Storage logs, Azure Activity logs, Azure Resource Manager events, Azure SQL logs, virtual machine activity, AKS activity, Backup and Recovery Services logs, Defender for Cloud alerts, Azure Monitor logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, account enrichment, sensitive-asset inventory, and SIEM correlation after Azure data-event validation, workload validation, VPN-to-Azure linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect sensitive Azure data, secrets, key-management, workload, or remote-management access after suspicious GlobalProtect VPN session context.

·        Identify downstream cloud exposure where trusted VPN session compromise may lead to secret retrieval, storage access, workload discovery, remote command execution, backup access, database access, or cloud-hosted system interaction.

·        Prioritize activity involving Key Vault secret retrieval, key operations, storage account access, blob access, virtual machine run command, Azure SQL access, AKS activity, backup vault access, Recovery Services activity, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious Azure data or workload access and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, Azure audit evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, Azure compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

Identify Azure data, secrets, key-management, workload, or remote-management events after suspicious GlobalProtect VPN session context.

·        Correlate Azure data or workload access with suspicious VPN activity involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on behavior.

·        Prioritize Key Vault secret access, key access, Storage account key retrieval, blob access, virtual machine run command, snapshot access, backup access, Azure SQL administrative access, AKS cluster interaction, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive Key Vaults, storage accounts, production workloads, backup vaults, databases, AKS clusters, administrative virtual machines, developer-platform workloads, or sensitive resource groups.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows suspicious VPN session activity, or lacks approved change-control context.

·        Increase confidence when Defender for Cloud, endpoint telemetry, DNS telemetry, proxy telemetry, Azure Monitor, or network telemetry shows supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, or documented change-control activity.

·        Do not classify Azure data, secrets, or workload access as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat Azure data access, Key Vault access, storage access, VM run command, workload access, Defender for Cloud findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

Azure Activity logs.

·        Azure Resource Manager events.

·        Key Vault diagnostic logs.

·        Storage account logs.

·        Blob access logs where available.

·        Azure SQL logs where available.

·        Virtual machine activity where available.

·        Azure VM run command events.

·        AKS activity where available.

·        Backup logs where available.

·        Recovery Services vault logs where available.

·        Defender for Cloud alerts where available.

·        Azure Monitor logs where available.

·        Network telemetry where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        Tenant inventory.

·        Subscription inventory.

·        Sensitive storage account inventory.

·        Sensitive Key Vault inventory.

·        Key inventory.

·        Secret inventory.

·        Production workload inventory.

·        Backup inventory.

·        Database inventory.

·        AKS cluster inventory.

·        Virtual machine inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build sensitive Azure data groups covering sensitive storage accounts, production storage accounts, regulated-data containers, Key Vault secrets, Key Vault keys, production virtual machines, Azure SQL databases, backup vaults, Recovery Services vaults, AKS clusters, developer-platform workloads, and sensitive resource groups.

·        Build Azure sensitive action groups for Key Vault secret retrieval, Key Vault key operations, storage account key listing, blob access, virtual machine run command, snapshot access, backup access, database administrative access, AKS cluster interaction, and locally sensitive workload-access events.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build source-path and identity linkage logic using user identity, service-principal identity, managed identity, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, tenant ID, subscription ID, resource ID, Azure Activity fields, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, backup access, workload remote-management activity, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, resource group, user identity, service principal, managed identity, source IP, user agent, operation name, result, Key Vault name, secret name, key name, storage account, container name, blob name, VM name, database name, AKS cluster name, response result, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across Azure Activity logs, Azure Resource Manager events, Key Vault logs, Storage logs, Blob logs, Azure SQL logs, VM activity, AKS activity, Backup logs, Recovery Services logs, Defender for Cloud, Azure Monitor, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-Azure linkage, identity-session correlation, source-path validation, resource-ID parsing, sensitive-asset enrichment, tenant enrichment, subscription enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate data, secrets, or workload access after suspicious VPN establishment, delayed secret retrieval, delayed key use, delayed storage access, delayed VM run command, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, vendor support, security testing, incident response, emergency access, and documented change-control activity.

·        Use short correlation windows when Azure data, secrets, or workload access occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed secret access, key use, storage access, VM run command, workload access, backup access, or database activity after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Azure Activity continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, Azure data-event availability, sensitive-asset inventory, tenant inventory, subscription inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to Azure data, secrets, key-management, and workload access after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the Azure service target, data-access sequence, role path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, key operations, sensitive storage access, virtual machine run command, workload access, backup access, database interaction, and sensitive cloud-resource access after suspicious remote-access context.

·        The score is constrained by weak VPN-to-Azure linkage, incomplete data-access logging, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, service-principal abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as Azure data and workload exposure coverage but should not be treated as standalone proof of GlobalProtect compromise, Azure compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Azure Activity logs, Key Vault logs, Storage logs, sensitive-asset inventory, tenant inventory, subscription inventory, identity-provider logs, VPN session mapping, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where Key Vault logs, Storage logs, Blob logs, Azure SQL logs, VM activity, AKS activity, Backup logs, Recovery Services logs, or Defender for Cloud telemetry are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive Azure data or workloads after VPN access.

·        Full-telemetry confidence improves when Azure data and workload activity is enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, network telemetry, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

This rule detects suspicious Azure data, secrets, or workload access linked to suspicious VPN context, not GlobalProtect exploitation or Azure compromise by itself.

·        Azure data and resource-access logs may not be enabled for all storage accounts, Key Vaults, workloads, databases, or sensitive resources.

·        Azure may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation identities, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, Azure data-event validation, resource-field validation, sensitive-asset validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrResourceEvent AS AzureSensitiveResourceAccess
WHERE AzureSensitiveResourceAccess.OperationName IN ANY (
"Microsoft.KeyVault/vaults/secrets/read",
"Microsoft.KeyVault/vaults/keys/read",
"Microsoft.KeyVault/vaults/decrypt/action",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
"Microsoft.Compute/virtualMachines/runCommand/action",
"Microsoft.Compute/snapshots/read",
"Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems/read",
"Microsoft.Sql/servers/databases/read",
"Microsoft.ContainerService/managedClusters/listClusterUserCredential/action",
"Microsoft.ContainerService/managedClusters/read"
)
AND AzureSensitiveResourceAccess.ResourceId IN ASSET_GROUP (
"Sensitive Storage Accounts",
"Production Storage Accounts",
"Regulated Data Containers",
"Key Vault Secrets",
"Key Vault Keys",
"Production Virtual Machines",
"Azure SQL Databases",
"Backup Vaults",
"Recovery Services Vaults",
"AKS Clusters",
"Developer Platform Workloads",
"Sensitive Resource Groups"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_AZURE_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(AzureSensitiveResourceAccess.User)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
AzureSensitiveResourceAccess.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR AzureSensitiveResourceAccess.User IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR AzureSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR AzureSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"backup_access",
"workload_remote_management_activity",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

GCP

Detection Viability Assessment

GCP has three rules for this EXP report.

·        GCP is viable for detecting downstream identity-plane, cloud-control-plane, IAM, service-account, key-management, data-access, workload, and administrative activity that may follow GlobalProtect authentication-lineage failure, trusted VPN session compromise, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        GCP is strongest where Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Cloud Logging, identity-provider telemetry, MFA context, GlobalProtect session context, endpoint telemetry, DNS or proxy telemetry, source enrichment, organization inventory, project inventory, and SIEM correlation can be combined.

·        GCP can identify suspicious post-VPN cloud behavior involving privileged IAM activity, administrative API calls, service-account changes, service-account key creation, service-account impersonation, policy modification, workload access, Secret Manager access, Cloud Storage access, Kubernetes interaction, BigQuery access, and activity inconsistent with the user’s normal cloud role.

·        GCP is not a standalone source for confirming GlobalProtect exploitation, successful authentication bypass, MFA bypass, HIP bypass, endpoint compromise, credential theft, token theft, SaaS compromise, or actor attribution.

·        GCP detections must be correlated with GlobalProtect session evidence, PAN-OS logs, identity-provider evidence, MFA evidence, endpoint telemetry, network telemetry, source-path evidence, change-control records, and incident-response findings before classifying activity as probable GlobalProtect-linked compromise.

·        GCP rules should not generate high-confidence alerting from cloud activity alone, IAM activity alone, service-account activity alone, Cloud Console access alone, Cloud Audit Log novelty alone, Secret Manager access alone, Cloud Storage access alone, Security Command Center findings alone, or source-IP novelty alone without suspicious VPN session context or validated identity-path linkage.

Rule

GlobalProtect-Linked GCP Console, IAM, or API Activity From Suspicious VPN Session Context

Rule Format

GCP cloud-control-plane correlation rule suitable for Cloud Audit Logs, Admin Activity logs, IAM logs, service-account activity, Security Command Center findings, Cloud Logging, VPC Flow Logs, Cloud DNS logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, organization inventory, project inventory, privileged-role inventory, service-account inventory, and SIEM correlation after GCP field validation, VPN-to-GCP linkage validation, identity-session validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect GCP Console, IAM, Admin Activity, or cloud API activity that occurs after suspicious GlobalProtect VPN session establishment and can be linked to the same user, device, source path, identity-provider session, VPN session window, authentication session, or incident timeline.

·        Identify possible downstream GCP exposure following trusted VPN session compromise, authentication-lineage failure, credential theft, token theft, or unauthorized use of a VPN-authenticated identity path.

·        Prioritize activity involving privileged GCP roles, Cloud Console administration, IAM policy interaction, administrative API calls, first-seen projects, first-seen services, unusual source paths, unusual user agents, and access inconsistent with the user’s normal GCP role.

·        Preserve separation between suspicious GCP activity and confirmed compromise by requiring supporting VPN session evidence, identity evidence, endpoint evidence, cloud evidence, credential-access evidence, token-access evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, GCP compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify GCP Console access, Cloud Audit Log activity, Admin Activity events, IAM activity, service-account activity, or administrative API events associated with a user, role, service account, or identity that can be linked to suspicious GlobalProtect VPN session context.

·        Prioritize GCP activity after VPN sessions involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, source novelty, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on activity.

·        Detect GCP activity involving privileged role use, IAM policy interaction, service-account activity, administrative API calls, first-seen project use, first-seen service use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive organizations, folders, or projects.

·        Increase confidence when GCP activity shares the same user, device, identity-provider session, source IP, authentication session, VPN session window, or incident timeline as suspicious GlobalProtect activity.

·        Increase confidence when GCP activity involves IAM, Cloud Resource Manager, service accounts, Cloud Storage, Secret Manager, Cloud KMS, Compute Engine, GKE, Cloud SQL, BigQuery, Cloud Functions, Cloud Run, Cloud Build, Cloud Logging, or Security Command Center in a manner not normally associated with the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, gcloud CLI use, cloud-administration activity, unusual session creation, suspicious OAuth consent, or post-session administrative behavior.

·        Reduce severity when GCP activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, or documented change-control activity.

·        Do not attribute GCP activity to GlobalProtect compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

·        Do not treat GCP Console activity, IAM activity, service-account activity, Admin Activity logs, Security Command Center findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        GCP Cloud Audit Logs.

·        GCP Admin Activity logs.

·        GCP Data Access logs where available.

·        GCP IAM logs.

·        GCP service-account activity.

·        GCP Cloud Logging.

·        GCP Security Command Center findings where available.

·        GCP VPC Flow Logs where available.

·        GCP Cloud DNS logs where available.

·        GCP organization inventory.

·        GCP folder inventory where available.

·        GCP project inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Workload identity inventory.

·        Workload inventory.

·        User identity.

·        Device identity.

·        Source IP.

·        User agent.

·        Principal email.

·        Service-account name.

·        Organization ID.

·        Folder ID.

·        Project ID.

·        Method name.

·        Service name.

·        Resource name.

·        Result.

·        Timestamp.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS traffic and authentication logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build suspicious GlobalProtect VPN session groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build GCP identity groups covering users, privileged users, administrators, service accounts, workload identities, break-glass accounts, automation identities, CI/CD identities, externally trusted identities, guest identities, and third-party identities.

·        Build GCP sensitive service groups covering IAM, Cloud Resource Manager, service accounts, Cloud Storage, Secret Manager, Cloud KMS, Compute Engine, GKE, Cloud SQL, BigQuery, Cloud Functions, Cloud Run, Cloud Build, Cloud Logging, Security Command Center, and other locally sensitive services.

·        Build GCP high-risk action groups for privileged role use, IAM policy interaction, service-account creation, service-account key creation, service-account impersonation, organization policy change, project creation, project deletion, logging change, storage access, secret access, KMS decrypt, workload administration, Kubernetes interaction, and security-control interaction.

·        Build linkage logic using user identity, device identity, identity-provider session, source IP, user agent, authentication session, VPN session window, tunnel identifier, gateway, destination application, organization ID, folder ID, project ID, principal email, service account, resource name, method name, and incident timeline.

·        Build GCP anomaly groups for first-seen project, first-seen folder, first-seen organization, first-seen service, rare operation, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive project access, and cross-project or cross-organization activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, principal email, service account, user identity, device identity, source IP, user agent, method name, service name, result, identity-provider session, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Cloud Logging, Security Command Center, VPC Flow Logs, Cloud DNS logs, identity-provider logs, MFA logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-GCP linkage, identity-session correlation, source-path validation, device correlation, Cloud Audit Log enrichment, organization enrichment, project enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate GCP access after suspicious VPN establishment, delayed privileged role use, delayed administrative activity, delayed API activity, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, vendor support, security testing, incident response, break-glass use, and documented change-control activity.

·        Use short correlation windows when GCP Console, IAM, or API activity occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed role use, administrative activity, service-account activity, Secret Manager access, Cloud Storage access, workload activity, or security-control interaction after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Cloud Audit Log continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, GCP field availability, organization inventory, project inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to VPN-linked GCP identity-plane and control-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated GCP anomalies.

·        The rule remains useful if an adversary changes GCP service target, API sequence, role path, source infrastructure, session timing, token use pattern, or post-session cloud activity.

·        The score is supported by the durability of suspicious VPN session linkage, privileged role use, administrative operation, first-seen service or project use, source-path mismatch, and GCP behavior outside normal account baselines.

·        The score is constrained by weak VPN-to-GCP linkage, identity federation complexity, split-tunnel routing, SASE egress, NAT, cloud session reuse, token reuse, service-account abstraction, incomplete GCP logging, and target-SIEM translation quality.

·        The rule is durable as downstream GCP exposure coverage but should not be treated as standalone proof of GlobalProtect compromise or GCP compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable VPN session mapping, Cloud Audit Logs, Admin Activity logs, IAM logs, identity-provider logs, MFA logs, organization inventory, project inventory, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where split tunneling, SASE routing, NAT, identity federation, cloud session reuse, token reuse, service-account naming, inconsistent source IPs, or missing device identifiers make VPN-to-GCP linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform GCP administrative actions after VPN access.

·        Full-telemetry confidence improves when GCP events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider session context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious GCP identity-plane or control-plane activity linked to suspicious VPN sessions, not GlobalProtect authentication bypass or GCP compromise by itself.

·        GCP may not preserve enough source-path, device, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        GCP Console, IAM, service-account, and Admin Activity events may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        VPN-to-GCP linkage may be weak where split tunneling, SASE egress, NAT, cloud session reuse, token reuse, identity federation, service-account abstraction, or source IP transformation obscures path attribution.

·        The rule may miss GCP abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation identity, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP identity-plane and control-plane correlation pattern requiring target-SIEM translation validation, Cloud Audit Log field validation, Admin Activity field validation, VPN session validation, identity-linkage validation, source-path validation, organization and project validation, sensitive action validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditOrIdentityEvent AS GcpControlPlaneActivity
WHERE GcpControlPlaneActivity.MethodName IN ANY (
"SetIamPolicy",
"GetIamPolicy",
"CreateServiceAccount",
"CreateServiceAccountKey",
"ServiceAccountImpersonation",
"CreateProject",
"DeleteProject",
"UpdateProject",
"SetOrgPolicy",
"CreateRole",
"UpdateRole",
"storage.buckets.get",
"storage.objects.get",
"secretmanager.secrets.get",
"secretmanager.versions.access",
"cloudkms.cryptoKeyVersions.useToDecrypt",
"compute.instances.setMetadata",
"container.clusters.get",
"bigquery.jobs.create"
)
AND GcpControlPlaneActivity.PrincipalType IN ANY (
"User",
"ServiceAccount",
"FederatedIdentity",
"WorkloadIdentity"
)
AND GcpControlPlaneActivity.ProjectId IN ASSET_GROUP (
"Sensitive GCP Projects",
"Production GCP Projects",
"Security Tooling Projects",
"Identity Management Projects",
"Backup Projects",
"Developer Platform Projects"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_GCP_CONTROL_PLANE_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(GcpControlPlaneActivity.PrincipalEmail)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
GcpControlPlaneActivity.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR GcpControlPlaneActivity.PrincipalEmail IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR GcpControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR GcpControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_project",
"first_seen_folder",
"first_seen_organization",
"first_seen_service",
"rare_operation",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_project_access",
"cross_project_activity"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

GlobalProtect-Linked GCP IAM, Service Account, or Security-Control Modification

Rule Format

GCP IAM, service-account, and security-control correlation rule suitable for Cloud Audit Logs, Admin Activity logs, IAM logs, service-account activity, organization policy logs, Security Command Center findings, Cloud Logging configuration events, Cloud KMS logs, Cloud Storage logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, organization inventory, project inventory, privileged-role inventory, service-account inventory, and SIEM correlation after GCP identity-field validation, privileged-action validation, VPN-to-GCP linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect GCP IAM, service-account, organization-policy, logging, monitoring, or security-control modifications after suspicious GlobalProtect VPN session context.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following trusted VPN session compromise.

·        Prioritize changes involving IAM policy updates, custom role changes, service-account creation, service-account key creation, service-account impersonation, organization policy changes, logging changes, monitoring changes, KMS changes, storage permission changes, firewall rule changes, and security-control modifications.

·        Preserve separation between suspicious GCP modification and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, Cloud Audit Log evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, GCP compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

·        Identify IAM, service-account, organization-policy, Cloud Logging, Cloud Monitoring, Security Command Center, Cloud KMS, Cloud Storage, firewall, or security-control modification events in GCP telemetry.

·        Correlate modification events with suspicious GlobalProtect VPN session context involving authentication-lineage gaps, source novelty, gateway sequencing anomalies, privileged accounts, third-party accounts, low-frequency users, suspicious portal behavior, suspicious gateway behavior, or suspicious internal follow-on activity.

·        Prioritize identity and role activity involving SetIamPolicy, CreateRole, UpdateRole, CreateServiceAccount, CreateServiceAccountKey, service-account impersonation, workload identity changes, organization policy changes, or privilege-expanding policy updates.

·        Prioritize security-control activity involving Cloud Logging sink changes, audit-log configuration changes, monitoring alert changes, Security Command Center changes, Cloud KMS policy changes, Cloud Storage IAM changes, firewall rule changes, or changes that reduce visibility, encryption, monitoring, alerting, or access control.

·        Increase confidence when changes affect production projects, identity-management projects, security tooling projects, backup projects, developer-platform projects, privileged roles, sensitive service accounts, cross-project trust paths, KMS keys, storage buckets, or sensitive workloads.

·        Increase confidence when activity is rare for the user, rare for the project, outside normal access windows, uses unusual user agents, follows suspicious VPN activity, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, or documented change-control activity.

·        Do not classify GCP IAM, service-account, or security-control modification as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

·        GCP Cloud Audit Logs.

·        GCP Admin Activity logs.

·        GCP Data Access logs where available.

·        GCP IAM logs.

·        GCP service-account activity.

·        GCP organization policy logs where available.

·        GCP Cloud Logging configuration events.

·        GCP Cloud Monitoring events where available.

·        GCP Security Command Center findings where available.

·        GCP Cloud KMS logs where available.

·        GCP Cloud Storage logs where available.

·        GCP firewall rule logs or configuration events where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        Endpoint telemetry where available.

·        DNS or proxy logs where available.

·        Organization inventory.

·        Folder inventory where available.

·        Project inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Workload identity inventory.

·        Cross-project trust inventory.

·        Security tooling inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build GCP identity modification groups covering IAM policy changes, custom role creation, custom role updates, service-account creation, service-account key creation, service-account impersonation, workload identity changes, organization policy changes, and privilege-expanding policy updates.

·        Build GCP security-control modification groups covering Cloud Logging sink changes, audit-log configuration changes, monitoring alert changes, Security Command Center changes, Cloud KMS policy changes, Cloud Storage IAM changes, firewall rule changes, logging changes, monitoring changes, encryption changes, and access-control changes.

·        Build sensitive GCP organization and project groups covering production projects, identity-management projects, security tooling projects, backup projects, developer-platform projects, shared-services projects, and projects containing sensitive workloads or sensitive data.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build linkage logic using user identity, service-account identity, workload identity, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, organization ID, folder ID, project ID, resource name, Cloud Audit Log fields, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, principal email, service account, role name, source IP, user agent, method name, service name, request parameters, response elements, result, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, organization policy logs, Cloud Logging configuration events, Cloud Monitoring, Security Command Center, Cloud KMS, Cloud Storage, firewall configuration telemetry, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-GCP linkage, identity-session correlation, source-path validation, Cloud Audit Log request-parameter parsing, organization enrichment, project enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate IAM, service-account, or security-control modification after suspicious VPN establishment, delayed administrative activity, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, vendor support, security testing, incident response, and documented change-control activity.

·        Use short correlation windows when IAM, service-account, or security-control changes occur immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed IAM changes, service-account changes, policy changes, logging changes, monitoring changes, encryption changes, or security-control modifications after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Cloud Audit Log continuity, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, GCP field availability, organization inventory, project inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to GCP IAM, service-account, and security-control modification after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, service-account usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of IAM policy changes, custom role changes, service-account creation, service-account key creation, service-account impersonation, organization policy changes, logging changes, monitoring-control changes, firewall rule changes, and security-control weakening after suspicious remote-access context.

·        The score is constrained by weak VPN-to-GCP linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete GCP logging, service-account abstraction, and target-SIEM translation quality.

·        The rule is durable as GCP persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of GlobalProtect compromise or GCP compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Audit Log coverage, Admin Activity coverage, IAM telemetry, organization inventory, project inventory, privileged-role inventory, identity-provider logs, VPN session mapping, source enrichment, change-control records, and SIEM correlation quality.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make IAM, service-account, or security-control changes through VPN access.

·        Operational confidence is reduced where service-account naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete request-parameter parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when GCP modification events are enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious GCP IAM, service-account, or security-control modification linked to suspicious VPN context, not GlobalProtect exploitation or GCP compromise by itself.

·        GCP logs may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar IAM, service-account, or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying IAM or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        GCP activity should not be attributed to GlobalProtect compromise without VPN session linkage, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP IAM, service-account, and security-control modification correlation pattern requiring target-SIEM translation validation, Cloud Audit Log field validation, IAM action validation, service-account action validation, security-control action validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditEvent AS GcpIamOrSecurityModification
WHERE GcpIamOrSecurityModification.MethodName IN ANY (
"SetIamPolicy",
"CreateRole",
"UpdateRole",
"CreateServiceAccount",
"CreateServiceAccountKey",
"ServiceAccountImpersonation",
"UpdateServiceAccount",
"SetOrgPolicy",
"CreateSink",
"UpdateSink",
"DeleteSink",
"UpdateAlertPolicy",
"UpdateSecurityCenterSettings",
"cloudkms.cryptoKeys.setIamPolicy",
"storage.buckets.setIamPolicy",
"compute.firewalls.insert",
"compute.firewalls.update",
"compute.firewalls.delete"
)
AND GcpIamOrSecurityModification.ProjectId IN ASSET_GROUP (
"Production GCP Projects",
"Security Tooling Projects",
"Identity Management Projects",
"Backup Projects",
"Developer Platform Projects",
"Shared Services Projects",
"Sensitive Data Projects"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_GCP_MODIFICATION_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(GcpIamOrSecurityModification.PrincipalEmail)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
GcpIamOrSecurityModification.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR GcpIamOrSecurityModification.PrincipalEmail IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR GcpIamOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR GcpIamOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpIamOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"service_account_created",
"service_account_key_created",
"service_account_impersonation",
"organization_policy_modified",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"kms_access_modified",
"storage_access_modified",
"cross_project_trust_modified",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

GlobalProtect-Linked GCP Data, Secrets, or Workload Access After Suspicious VPN Context

Rule Format

GCP data, secrets, and workload access correlation rule suitable for Cloud Audit Logs, Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine activity, GKE activity, BigQuery logs, Cloud SQL logs, Cloud Build logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, identity-provider telemetry, GlobalProtect session enrichment, source enrichment, organization inventory, project inventory, sensitive-asset inventory, and SIEM correlation after GCP data-event validation, workload validation, VPN-to-GCP linkage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect sensitive GCP data, secrets, key-management, workload, or remote-management access after suspicious GlobalProtect VPN session context.

·        Identify downstream cloud exposure where trusted VPN session compromise may lead to secret retrieval, storage access, workload discovery, remote command execution, database access, BigQuery access, Kubernetes access, or cloud-hosted system interaction.

·        Prioritize activity involving Secret Manager access, Cloud KMS decrypt operations, Cloud Storage object access, Compute Engine instance interaction, GKE cluster interaction, BigQuery job activity, Cloud SQL access, Cloud Build interaction, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious GCP data or workload access and confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, endpoint evidence, Cloud Audit Log evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove GlobalProtect exploitation, authentication bypass, GCP compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify GCP data, secrets, key-management, workload, or remote-management events after suspicious GlobalProtect VPN session context.

·        Correlate GCP data or workload access with suspicious VPN activity involving authentication-lineage gaps, portal-to-gateway sequencing anomalies, missing identity-provider evidence, missing MFA evidence, missing HIP evidence, unexpected gateway assignment, suspicious source infrastructure, privileged account use, third-party account use, low-frequency VPN use, or suspicious internal follow-on behavior.

·        Prioritize Secret Manager access, KMS decrypt operations, Cloud Storage object access, Compute Engine metadata or instance interaction, GKE cluster access, BigQuery job activity, Cloud SQL administrative access, Cloud Build interaction, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive storage buckets, secrets, KMS keys, production workloads, databases, BigQuery datasets, GKE clusters, administrative compute resources, developer-platform workloads, or sensitive projects.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows suspicious VPN session activity, or lacks approved change-control context.

·        Increase confidence when Security Command Center, endpoint telemetry, DNS telemetry, proxy telemetry, VPC Flow Logs, or Cloud Logging shows supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, or documented change-control activity.

·        Do not classify GCP data, secrets, or workload access as GlobalProtect-linked compromise without VPN session linkage, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat GCP data access, Secret Manager access, KMS use, Cloud Storage access, workload activity, Security Command Center findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        GCP Cloud Audit Logs.

·        GCP Admin Activity logs.

·        GCP Data Access logs where available.

·        Cloud Storage logs.

·        Secret Manager logs.

·        Cloud KMS logs.

·        Compute Engine logs where available.

·        GKE activity where available.

·        BigQuery audit logs where available.

·        Cloud SQL logs where available.

·        Cloud Build logs where available.

·        Security Command Center findings where available.

·        VPC Flow Logs where available.

·        Cloud DNS logs where available.

·        Identity-provider logs.

·        MFA logs.

·        GlobalProtect session enrichment.

·        Suspicious VPN session enrichment.

·        PAN-OS logs where available.

·        DNS or proxy logs where available.

·        Endpoint telemetry where available.

·        Organization inventory.

·        Project inventory.

·        Sensitive Cloud Storage inventory.

·        Secret Manager inventory.

·        KMS key inventory.

·        Production workload inventory.

·        Database inventory.

·        BigQuery dataset inventory.

·        GKE cluster inventory.

·        Compute Engine inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build sensitive GCP data groups covering sensitive Cloud Storage buckets, production storage buckets, regulated-data buckets, Secret Manager secrets, Cloud KMS keys, production Compute Engine instances, Cloud SQL databases, BigQuery datasets, GKE clusters, Cloud Build projects, developer-platform workloads, and sensitive projects.

·        Build GCP sensitive action groups for Secret Manager secret access, Cloud KMS decrypt operations, Cloud Storage object access, BigQuery job creation, Compute Engine metadata access, Compute Engine instance interaction, GKE cluster access, Cloud SQL access, Cloud Build interaction, and locally sensitive workload-access events.

·        Build suspicious GlobalProtect VPN context groups covering authentication-lineage gaps, portal-to-gateway sequencing gaps, missing identity evidence, suspicious source infrastructure, privileged account VPN use, third-party account VPN use, low-frequency VPN use, suspicious portal activity, suspicious gateway activity, and suspicious internal follow-on activity.

·        Build source-path and identity linkage logic using user identity, service-account identity, workload identity, identity-provider session, source IP, user agent, device identity, VPN session window, authentication session, tunnel identifier, gateway, organization ID, folder ID, project ID, resource name, Cloud Audit Log fields, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, workload access, Kubernetes access, database access, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, bucket name, object name, secret name, key name, instance name, database name, dataset name, GKE cluster name, principal email, service account, source IP, user agent, method name, service name, response result, identity-provider session, device identity, VPN session, tunnel identifier, gateway, source-path context, VPN-linkage status, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Admin Activity logs, Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine logs, GKE activity, BigQuery audit logs, Cloud SQL logs, Cloud Build logs, Security Command Center, VPC Flow Logs, Cloud DNS logs, identity-provider logs, GlobalProtect session context, PAN-OS logs, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for VPN-to-GCP linkage, identity-session correlation, source-path validation, resource-name parsing, sensitive-asset enrichment, organization enrichment, project enrichment, timing windows, exception handling, and query-performance controls.

·        Validate timing windows for immediate data, secrets, or workload access after suspicious VPN establishment, delayed secret retrieval, delayed KMS use, delayed storage access, delayed workload access, repeated cloud access, repeated short VPN sessions, and delayed linkage supported by incident-response evidence.

·        Validate exception handling for approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, vendor support, security testing, incident response, emergency access, and documented change-control activity.

·        Use short correlation windows when GCP data, secrets, or workload access occurs immediately after suspicious VPN establishment.

·        Use moderate correlation windows for delayed secret access, KMS use, Cloud Storage access, workload access, BigQuery activity, GKE activity, database activity, or Cloud Build activity after suspicious VPN establishment.

·        Use longer correlation windows only when identity evidence, endpoint evidence, VPN session evidence, Cloud Audit Log continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Validate query performance before alert-mode deployment.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until VPN linkage, source attribution, identity correlation, Data Access log availability, sensitive-asset inventory, organization inventory, project inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to GCP data, secrets, key-management, and workload access after suspicious VPN session context rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the GCP service target, data-access sequence, role path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, KMS decrypt operations, sensitive Cloud Storage access, BigQuery interaction, GKE activity, workload access, database interaction, and sensitive cloud-resource access after suspicious remote-access context.

·        The score is constrained by weak VPN-to-GCP linkage, incomplete Data Access logs, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, service-account abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as GCP data and workload exposure coverage but should not be treated as standalone proof of GlobalProtect compromise, GCP compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Audit Logs, Data Access logs, sensitive-asset inventory, organization inventory, project inventory, identity-provider logs, VPN session mapping, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where Data Access logs, Cloud Storage logs, Secret Manager logs, KMS logs, Compute Engine logs, GKE activity, BigQuery audit logs, Cloud SQL logs, Cloud Build logs, or VPC Flow Logs are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive GCP data or workloads after VPN access.

·        Full-telemetry confidence improves when GCP data and workload activity is enriched with GlobalProtect session context, PAN-OS logs, identity-provider context, MFA logs, endpoint telemetry, DNS logs, proxy logs, VPC Flow Logs, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious GCP data, secrets, or workload access linked to suspicious VPN context, not GlobalProtect exploitation or GCP compromise by itself.

·        GCP Data Access logs may not be enabled for all buckets, secrets, keys, workloads, databases, datasets, or sensitive resources.

·        GCP may not provide enough device, source-path, identity-provider session, or VPN-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation identities, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, GCP Data Access log validation, resource-field validation, sensitive-asset validation, VPN session validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditOrResourceEvent AS GcpSensitiveResourceAccess
WHERE GcpSensitiveResourceAccess.MethodName IN ANY (
"secretmanager.versions.access",
"cloudkms.cryptoKeyVersions.useToDecrypt",
"storage.objects.get",
"storage.buckets.get",
"bigquery.jobs.create",
"bigquery.tables.getData",
"compute.instances.get",
"compute.instances.setMetadata",
"container.clusters.get",
"container.clusters.getCredentials",
"sql.instances.get",
"cloudbuild.builds.create"
)
AND GcpSensitiveResourceAccess.ResourceName IN ASSET_GROUP (
"Sensitive Cloud Storage Buckets",
"Production Storage Buckets",
"Regulated Data Buckets",
"Secret Manager Secrets",
"Cloud KMS Keys",
"Production Compute Instances",
"Cloud SQL Databases",
"BigQuery Datasets",
"GKE Clusters",
"Cloud Build Projects",
"Developer Platform Workloads",
"Sensitive GCP Projects"
)
AND EVENT_NEAR WITHIN ENV_GP_TO_GCP_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS SuspiciousGlobalProtectVpnContext
WHERE SuspiciousGlobalProtectVpnContext.User IN SAME_USER_OR_IDENTITY(GcpSensitiveResourceAccess.PrincipalEmail)
AND SuspiciousGlobalProtectVpnContext.EventPattern IN ANY (
"authentication_lineage_gap",
"portal_to_gateway_sequence_gap",
"missing_identity_provider_evidence",
"missing_mfa_evidence",
"missing_hip_evidence",
"unexpected_gateway_assignment",
"source_not_in_user_baseline",
"privileged_account_vpn_use",
"third_party_account_vpn_use",
"low_frequency_vpn_user",
"suspicious_internal_followon_activity"
)
)
AND (
GcpSensitiveResourceAccess.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(SuspiciousGlobalProtectVpnContext.SourceIP)
OR GcpSensitiveResourceAccess.PrincipalEmail IN SAME_USER(SuspiciousGlobalProtectVpnContext.User)
OR GcpSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(SuspiciousGlobalProtectVpnContext.IdentitySession)
OR GcpSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(SuspiciousGlobalProtectVpnContext.Timestamp)
)
AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"workload_access",
"kubernetes_access",
"database_access",
"activity_outside_expected_role"
)
AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

S26 Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the report’s primary threat behaviors to the S25 detection model. The purpose is to show how each rule family supports detection of GlobalProtect authentication-lineage failure, trusted VPN session misuse, downstream identity exposure, internal access, and cloud-control-plane activity without overstating any single rule as standalone proof of exploitation or compromise.

Threat Behavior

GlobalProtect authentication-lineage gap or portal-to-gateway sequencing anomaly.

Mapped S25 Rule Coverage

·        NDR / Network Behavioral Analytics: GlobalProtect Portal-to-Gateway Authentication-Lineage Anomaly.

·        SentinelOne: Suspicious GlobalProtect Session Followed by Endpoint or Identity-Adjacent Activity.

·        Splunk: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

·        Elastic: GlobalProtect Tunnel Establishment With Missing or Inconsistent Authentication-Lineage Evidence.

·        QRadar: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

·        SIGMA: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

Detection Contribution

·        Identifies tunnel establishment or VPN session state where expected precursor authentication, identity-provider, MFA, SAML or OIDC, HIP, certificate, client configuration, or gateway-assignment evidence is missing, delayed, mismatched, or inconsistent.

·        Supports escalation when suspicious tunnel establishment aligns with source novelty, account-risk context, gateway-sequencing anomalies, or session-state inconsistency.

·        Preserves non-attribution guardrails by requiring telemetry-completeness validation and supporting evidence before classifying the activity as exploitation or compromise.

Traceability Confidence

High where GlobalProtect portal logs, gateway logs, tunnel-established events, identity-provider logs, MFA logs, HIP logs, gateway-assignment context, session identifiers, account enrichment, source enrichment, and telemetry-completeness validation are available.

Threat Behavior

Trusted VPN session misuse after suspicious GlobalProtect session establishment.

Mapped S25 Rule Coverage

·        NDR / Network Behavioral Analytics: Suspicious VPN-Authenticated Internal Access Following GlobalProtect Session Establishment.

·        SentinelOne: Suspicious GlobalProtect Session Followed by Endpoint or Identity-Adjacent Activity.

·        Splunk: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        Elastic: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        QRadar: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        SIGMA: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

Detection Contribution

·        Identifies suspicious internal access after VPN establishment, including identity-service access, administrative protocol use, privileged resource access, internal discovery, destination novelty, and access outside expected user baselines.

·        Supports triage of trusted-session misuse where suspicious VPN context can be linked to internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, or privileged-management activity.

·        Helps distinguish normal remote-access activity from suspicious post-session behavior when supported by asset inventory, user baselines, session linkage, and change-control context.

Traceability Confidence

High where VPN session identifiers, internal network telemetry, DNS logs, identity-service telemetry, endpoint telemetry, privileged-resource inventory, user baselines, and approved administrative workflow records are available.

Threat Behavior

Endpoint activity following suspicious VPN session context.

Mapped S25 Rule Coverage

·        SentinelOne: Suspicious GlobalProtect Session Followed by Endpoint or Identity-Adjacent Activity.

·        SentinelOne: Suspicious Remote-Access Session Followed by Credential, Token, or Persistence Behavior.

·        Splunk: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        Elastic: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        QRadar: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

·        SIGMA: GlobalProtect Trusted VPN Session Followed by Internal Reconnaissance or Privileged Resource Access.

Detection Contribution

·        Identifies endpoint behavior that may occur after suspicious VPN session activity, including suspicious child processes, administrative tooling, credential-access behavior, token-access behavior, persistence creation, script execution, remote-management activity, and suspicious outbound communication.

·        Provides supporting evidence when suspicious VPN session context is followed by host-level behavior on the VPN client, internal systems accessed through the VPN, or systems involved in post-session activity.

·        Strengthens investigation confidence when endpoint telemetry links process, file, registry, script, credential, token, or persistence behavior to the same user, device, source path, or incident window.

Traceability Confidence

Moderate to high where EDR telemetry, process lineage, command-line telemetry, file telemetry, registry telemetry, identity context, VPN session context, and incident timeline evidence are available.

Threat Behavior

Identity-provider, MFA, SAML, OIDC, HIP, certificate, or posture evidence inconsistency.

Mapped S25 Rule Coverage

·        NDR / Network Behavioral Analytics: GlobalProtect Portal-to-Gateway Authentication-Lineage Anomaly.

·        SentinelOne: Suspicious GlobalProtect Session Followed by Endpoint or Identity-Adjacent Activity.

·        Splunk: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

·        Elastic: GlobalProtect Tunnel Establishment With Missing or Inconsistent Authentication-Lineage Evidence.

·        QRadar: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

·        SIGMA: GlobalProtect Tunnel Establishment Without Complete Authentication-Lineage Evidence.

Detection Contribution

·        Identifies missing or inconsistent identity-provider, MFA, SAML or OIDC, HIP, certificate, posture, or authentication-context evidence around VPN session establishment.

·        Supports investigation of potential authentication-lineage failure where expected authentication or posture evidence is absent, delayed, mismatched, or inconsistent after telemetry completeness has been validated.

·        Prevents false confidence by requiring validation of ingestion delay, provider outage, parser behavior, timestamp skew, retention coverage, and local join reliability before treating missing evidence as suspicious.

Traceability Confidence

High where identity-provider logs, MFA logs, SAML or OIDC context, HIP logs, certificate context, device posture telemetry, GlobalProtect session events, and telemetry-completeness validation are available.

Threat Behavior

Cloud, SaaS, identity, source-code, or developer-platform activity after suspicious VPN session context.

Mapped S25 Rule Coverage

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        AWS: GlobalProtect-Linked AWS Console or API Activity From Suspicious VPN Session Context.

·        Azure: GlobalProtect-Linked Azure Portal, Entra ID, or Resource Manager Activity From Suspicious VPN Session Context.

·        GCP: GlobalProtect-Linked GCP Console, IAM, or API Activity From Suspicious VPN Session Context.

Detection Contribution

·        Identifies downstream cloud, SaaS, identity, source-code, CI/CD, or developer-platform activity that can be linked to suspicious VPN session context.

·        Supports exposure scoping where the same user, source path, identity-provider session, device, VPN session window, or incident timeline appears in downstream administrative activity.

·        Prioritizes privileged control-plane activity, administrative console access, API activity, token use, repository access, CI/CD changes, security-control interaction, and sensitive tenant, account, subscription, or project access.

·        Preserves non-attribution guardrails by requiring validated linkage before treating downstream activity as related to the suspicious GlobalProtect session.

Traceability Confidence

Moderate to high where VPN session mapping, identity-provider logs, cloud audit logs, SaaS logs, source-code platform logs, CI/CD logs, source enrichment, endpoint telemetry, and change-control records are available.

Threat Behavior

AWS control-plane, IAM, security-control, data, secrets, or workload activity after suspicious VPN session context.

Mapped S25 Rule Coverage

·        AWS: GlobalProtect-Linked AWS Console or API Activity From Suspicious VPN Session Context.

·        AWS: GlobalProtect-Linked AWS IAM or Security-Control Modification.

·        AWS: GlobalProtect-Linked AWS Data, Secrets, or Workload Access After Suspicious VPN Context.

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

Detection Contribution

·        Identifies AWS console access, API activity, role assumption, IAM changes, access-key creation, security-control modification, CloudTrail interaction, Secrets Manager access, KMS decrypt activity, S3 access, Systems Manager activity, workload access, and sensitive account interaction after suspicious VPN context.

·        Supports scoping of downstream AWS exposure where CloudTrail evidence can be linked to suspicious VPN activity by user, source path, identity-provider session, device, session window, or incident timeline.

·        Distinguishes cloud exposure from confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, sensitive-asset context, change-control review, and incident-response validation.

Traceability Confidence

Moderate to high where CloudTrail management events, CloudTrail data events, IAM Identity Center telemetry, STS events, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, VPN session context, and identity-provider evidence are available.

Threat Behavior

Azure identity-plane, control-plane, data, secrets, or workload activity after suspicious VPN session context.

Mapped S25 Rule Coverage

·        Azure: GlobalProtect-Linked Azure Portal, Entra ID, or Resource Manager Activity From Suspicious VPN Session Context.

·        Azure: GlobalProtect-Linked Azure Identity, Role, or Security-Control Modification.

·        Azure: GlobalProtect-Linked Azure Data, Secrets, or Workload Access After Suspicious VPN Context.

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

Detection Contribution

·        Identifies Azure portal activity, Entra ID sign-ins, Entra ID audit activity, Azure Resource Manager operations, privileged role use, service-principal changes, application credential changes, conditional-access changes, Key Vault access, Storage access, VM run command, AKS activity, backup access, and sensitive workload interaction after suspicious VPN context.

·        Supports scoping of downstream Azure exposure where Entra ID, Azure Activity, Key Vault, Storage, Defender for Cloud, Azure Monitor, endpoint evidence, and VPN session context can be correlated.

·        Distinguishes cloud exposure from confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, tenant and subscription context, sensitive-asset context, change-control review, and incident-response validation.

Traceability Confidence

Moderate to high where Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, Key Vault logs, Storage logs, Defender for Cloud alerts, Azure Monitor logs, VPN session context, identity-provider evidence, and endpoint telemetry are available.

Threat Behavior

GCP identity-plane, control-plane, data, secrets, or workload activity after suspicious VPN session context.

Mapped S25 Rule Coverage

·        GCP: GlobalProtect-Linked GCP Console, IAM, or API Activity From Suspicious VPN Session Context.

·        GCP: GlobalProtect-Linked GCP IAM, Service Account, or Security-Control Modification.

·        GCP: GlobalProtect-Linked GCP Data, Secrets, or Workload Access After Suspicious VPN Context.

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

Detection Contribution

·        Identifies GCP Console access, Cloud Audit Log activity, IAM activity, service-account activity, service-account key creation, service-account impersonation, organization-policy changes, logging changes, monitoring changes, firewall changes, Secret Manager access, KMS decrypt activity, Cloud Storage access, BigQuery activity, GKE activity, Cloud SQL access, Cloud Build interaction, and sensitive workload activity after suspicious VPN context.

·        Supports scoping of downstream GCP exposure where Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Security Command Center findings, Cloud Logging, VPC Flow Logs, Cloud DNS logs, endpoint evidence, and VPN session context can be correlated.

·        Distinguishes cloud exposure from confirmed compromise by requiring VPN linkage, identity linkage, source-path evidence, organization and project context, sensitive-asset context, change-control review, and incident-response validation.

Traceability Confidence

Moderate to high where Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Security Command Center, VPC Flow Logs, Cloud DNS logs, VPN session context, identity-provider evidence, and endpoint telemetry are available.

Threat Behavior

Security-control, logging, monitoring, role, policy, service-principal, or service-account modification after suspicious VPN session context.

Mapped S25 Rule Coverage

·        AWS: GlobalProtect-Linked AWS IAM or Security-Control Modification.

·        Azure: GlobalProtect-Linked Azure Identity, Role, or Security-Control Modification.

·        GCP: GlobalProtect-Linked GCP IAM, Service Account, or Security-Control Modification.

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

Detection Contribution

·        Identifies suspicious modification of IAM, policies, roles, service principals, service accounts, logging, monitoring, firewall rules, Key Vault or KMS access, CloudTrail or Cloud Logging behavior, GuardDuty or Defender controls, Security Hub or Security Command Center settings, and other security-control surfaces.

·        Supports identification of potential persistence, privilege escalation, defense evasion, access expansion, or visibility reduction following suspicious VPN session context.

·        Requires change-control validation and incident-response review before treating security-control modifications as malicious or GlobalProtect-linked.

Traceability Confidence

Moderate to high where cloud audit logs, IAM logs, identity-provider logs, security-control telemetry, privileged-role inventory, change-control records, and VPN session context are available.

Threat Behavior

Sensitive data, secrets, key-management, storage, backup, database, Kubernetes, or workload access after suspicious VPN session context.

Mapped S25 Rule Coverage

·        AWS: GlobalProtect-Linked AWS Data, Secrets, or Workload Access After Suspicious VPN Context.

·        Azure: GlobalProtect-Linked Azure Data, Secrets, or Workload Access After Suspicious VPN Context.

·        GCP: GlobalProtect-Linked GCP Data, Secrets, or Workload Access After Suspicious VPN Context.

·        Splunk: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        Elastic: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        QRadar: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

·        SIGMA: GlobalProtect-Linked VPN Session Followed by Cloud, SaaS, or Developer-Platform Control-Plane Activity.

Detection Contribution

·        Identifies suspicious access to sensitive cloud data, secrets, keys, storage, databases, backups, workloads, Kubernetes clusters, remote-management paths, and developer-platform workloads after suspicious VPN context.

·        Supports exposure scoping where sensitive-resource access can be linked to the same user, device, source path, identity-provider session, VPN session window, or incident timeline as suspicious GlobalProtect activity.

·        Requires sensitive-asset inventory, source-path validation, identity linkage, and incident-response confirmation before classifying activity as confirmed data theft, secret theft, workload compromise, or cloud compromise.

Traceability Confidence

Moderate to high where cloud data-access logs, secrets logs, key-management logs, workload logs, sensitive-asset inventory, VPN session context, identity-provider evidence, and endpoint telemetry are available.

Threat Behavior

Artifact-based detection or recovered payload identification.

Mapped S25 Rule Coverage

·        YARA: No primary YARA rule is included.

Detection Contribution

·        YARA does not provide primary coverage for this report because the governing detection model is behavior-led, not artifact-led.

·        YARA may support optional investigative hunting only if responders recover a stable artifact, such as a webshell, loader, dropper, staged script, exploit payload, credential-access tool, remote-access tool, memory artifact, configuration artifact, encoded payload, suspicious binary, or reusable file-content pattern linked to suspicious VPN session establishment or downstream activity.

·        YARA results should be treated as supporting forensic evidence only when temporally and behaviorally linked to the suspicious VPN session or downstream activity.

Traceability Confidence

Conditional and artifact-dependent. No primary YARA traceability is claimed without recovered and validated artifact evidence.

Overall Rule Coverage Assessment

·        The S25 rule model provides strongest coverage for authentication-lineage gaps, portal-to-gateway sequencing anomalies, trusted VPN session misuse, suspicious internal access, downstream cloud-control-plane activity, IAM and security-control modification, and sensitive cloud-resource access.

·        The model provides moderate to high coverage for downstream cloud exposure when VPN session evidence can be linked to identity-provider, endpoint, cloud, SaaS, source-code, CI/CD, or incident-response evidence.

·        The model provides limited primary coverage for artifact-only detection because the report is not centered on a stable malware sample, webshell body, dropper, payload, or binary artifact.

·        The model intentionally avoids single-signal attribution and does not treat vulnerable version posture, cloud activity, endpoint activity, source novelty, identity anomalies, or YARA artifact matches as standalone proof of GlobalProtect exploitation or compromise.

Traceability Qualification

·        Direct coverage applies when suspicious GlobalProtect session context is present and mapped rule logic can correlate authentication-lineage gaps, portal-to-gateway anomalies, trusted-session misuse, internal activity, or downstream cloud activity.

·        Coverage with adaptation applies when required telemetry exists but local field names, event actions, asset inventories, identity mappings, cloud inventories, or timing windows require environment-specific mapping.

·        Non-coverage applies where GlobalProtect logs, identity-provider logs, MFA evidence, HIP evidence, VPN session context, cloud audit logs, endpoint telemetry, internal network telemetry, or sensitive-asset inventories are unavailable.

·        No rule should be promoted to production alerting until local field mapping, telemetry completeness, exception handling, baseline validation, query performance, and SOC triage readiness are validated.

S27 — Behavior & Log Artifacts

Behavioral Artifact Summary

This report’s primary artifacts are behavior-led rather than exploit-string-led. The strongest artifacts are authentication-lineage gaps, portal-to-gateway sequencing inconsistencies, VPN session establishment anomalies, trusted VPN session misuse, identity-context mismatches, and downstream internal, endpoint, identity, cloud, SaaS, source-code, CI/CD, or developer-platform activity linked to suspicious GlobalProtect session context.

Primary Behavior Artifacts

·        GlobalProtect tunnel establishment without complete precursor authentication evidence.

·        Portal-to-gateway sequencing anomalies where gateway activity occurs without expected portal, identity-provider, MFA, SAML or OIDC, HIP, certificate, client-configuration, or gateway-assignment evidence.

·        VPN session establishment from unfamiliar source infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress points, or sources inconsistent with user history.

·        VPN session use by privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Missing or inconsistent identity-provider evidence after telemetry completeness, ingestion delay, timestamp skew, parser behavior, provider outage, and retention coverage have been validated.

·        Missing or inconsistent MFA, conditional-access, SAML, OIDC, HIP, certificate, device-posture, authentication-cookie, session-token, or gateway-assignment evidence after local join reliability has been validated.

·        Suspicious internal access after VPN establishment involving identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        VPN-authenticated use of administrative protocols, identity-service access, internal reconnaissance, destination novelty, cross-segment access, share enumeration, failed internal authentication bursts, credential validation, or access outside normal user role.

·        Endpoint activity following suspicious VPN session context, including suspicious child processes, administrative tooling, credential-access behavior, token-access behavior, persistence creation, script execution, remote-management activity, or suspicious outbound communication.

·        Downstream cloud, SaaS, identity, source-code, CI/CD, or developer-platform activity linked to suspicious VPN session context.

·        Cloud identity, role, policy, service-principal, service-account, logging, monitoring, security-control, key-management, storage, data, secrets, workload, Kubernetes, backup, or database activity following suspicious VPN session context.

Primary Log Artifacts

·        GlobalProtect portal logs.

·        GlobalProtect gateway logs.

·        GlobalProtect authentication logs.

·        GlobalProtect tunnel-established events.

·        GlobalProtect session-state events.

·        GlobalProtect HIP match and HIP report results where available.

·        GlobalProtect client configuration retrieval events where available.

·        GlobalProtect gateway-assignment events where available.

·        PAN-OS traffic logs.

·        PAN-OS system logs.

·        PAN-OS authentication logs.

·        PAN-OS configuration logs where available.

·        Identity-provider authentication logs.

·        MFA logs.

·        Conditional-access logs where available.

·        SAML or OIDC assertion context.

·        Certificate validation context where available.

·        Device-compliance or posture telemetry where available.

·        Internal DNS logs.

·        LDAP and Kerberos logs where available.

·        SMB, RDP, SSH, WinRM, WMI, database, file-share, and administrative-protocol telemetry where available.

·        Endpoint and EDR process telemetry.

·        Endpoint file, registry, service, scheduled-task, DLL-load, and persistence telemetry where available.

·        NDR, proxy, secure web gateway, firewall, and internal segmentation telemetry.

·        AWS CloudTrail, IAM, STS, IAM Identity Center, GuardDuty, Security Hub, Config, VPC Flow Logs, Route 53 Resolver, S3, KMS, Secrets Manager, Systems Manager, workload, and data-access logs where available.

·        Azure Entra ID, Azure Activity, Azure Resource Manager, Key Vault, Storage, Defender for Cloud, Azure Monitor, workload, and data-access logs where available.

·        GCP Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Security Command Center, VPC Flow Logs, Cloud DNS, Secret Manager, Cloud KMS, Cloud Storage, BigQuery, GKE, Cloud SQL, and Cloud Build logs where available.

·        SaaS administration logs where available.

·        Source-code, developer-platform, and CI/CD logs where available.

·        Change-control records.

·        Approved vendor-support records.

·        Approved administrator workflow records.

·        Incident-response records.

GlobalProtect-Specific Artifacts

·        Portal request and portal authentication events that do not reconcile with expected identity-provider, MFA, SAML, OIDC, certificate, HIP, device-posture, or conditional-access evidence.

·        Gateway authentication events that do not reconcile with expected portal authentication, gateway assignment, client configuration retrieval, authentication-cookie context, session-token context, or tunnel establishment.

·        Tunnel-established events without expected precursor activity.

·        Client configuration retrieval events from unusual sources, devices, users, client versions, operating-system profiles, or source networks.

·        Gateway selection or gateway assignment inconsistent with user history, region, source geography, policy, device posture, or expected routing.

·        Authentication-cookie, session-token, SAML assertion, certificate, HIP, or posture evidence inconsistent with portal, gateway, user, device, source IP, timestamp, or tunnel-session records.

·        Repeated short sessions, reconnect behavior, unusual tunnel lifetimes, gateway changes, or delayed internal access after suspicious VPN session establishment.

·        Successful VPN access following malformed, incomplete, abnormal, or scanner-like portal or gateway interaction.

Identity and Access-Control Artifacts

·        Identity-provider authentication events that are missing, delayed, denied, challenged, mismatched, incomplete, or inconsistent with GlobalProtect session evidence.

·        MFA or conditional-access events that do not reconcile with portal, gateway, tunnel, user, source, device, or timestamp context.

·        SAML or OIDC assertion context that does not match the expected user, device, source, identity-provider session, GlobalProtect event, or session timeline.

·        Authentication-method changes, MFA changes, conditional-access changes, password resets, privileged-role assignments, group membership changes, account re-enablement, or account creation after suspicious VPN access.

·        Service-account, service-principal, application credential, API token, SSH key, access key, or certificate changes following suspicious VPN session context.

·        Identity activity involving dormant, stale, recently re-enabled, third-party, contractor, privileged, administrative, security, or low-frequency accounts.

Endpoint and Host Artifacts

·        GlobalProtect client process activity, VPN adapter creation, reconnect behavior, tunnel establishment, or endpoint-side VPN context.

·        Suspicious process execution after GlobalProtect client activity or suspicious VPN context.

·        PowerShell, command shell, WMI, WinRM, script host, rundll32, regsvr32, certutil, bitsadmin, curl, wget, cloud CLI, SaaS administration, or developer CLI usage after suspicious VPN session context.

·        Encoded execution, execution-policy bypass, no-profile execution, hidden-window execution, suspicious command chaining, remote retrieval, direct IP access, credential access, token access, or user-writable path execution.

·        File writes, archive extraction, script creation, executable creation, DLL creation, or tool staging in Downloads, Temp, AppData, ProgramData, Public, browser cache, user profile paths, administrative staging paths, or other user-writable directories.

·        Suspicious activity on internal systems reached through the VPN session, including credential access, token access, remote administration, persistence, unauthorized agent deployment, suspicious child processes, or outbound follow-on communication.

·        Endpoint activity on domain controllers, identity systems, jump hosts, privileged workstations, management servers, backup systems, endpoint-management systems, source-code systems, CI/CD systems, database servers, file servers, or sensitive business systems.

Network and Internal Access Artifacts

·        VPN-authenticated traffic to DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, databases, file shares, jump hosts, privileged-management systems, identity infrastructure, or administrative interfaces.

·        First-seen internal destinations after suspicious VPN session establishment.

·        Rare user-to-destination pairs.

·        Rare service use for the account.

·        Destination diversity inconsistent with normal user behavior.

·        Cross-segment access.

·        Administrative protocol use outside expected role.

·        Failed internal authentication bursts.

·        Credential validation patterns.

·        Share enumeration.

·        Access to systems outside the user’s normal operational profile.

·        Internal systems touched by VPN-authenticated sessions later initiating unusual outbound communication, cloud access, SaaS access, data movement, tooling retrieval, or command-and-control-like traffic.

Cloud and SaaS Artifacts

·        AWS CloudTrail activity, IAM activity, STS activity, IAM Identity Center activity, access-key creation, role assumption, IAM policy changes, CloudTrail changes, GuardDuty changes, Security Hub changes, S3 access, Secrets Manager access, KMS decrypt activity, Systems Manager activity, workload access, or sensitive account access after suspicious VPN context.

·        Azure Entra ID sign-in activity, Entra ID audit activity, Azure Activity events, Azure Resource Manager operations, role assignments, service-principal changes, application credential changes, conditional-access changes, Key Vault access, Storage access, VM run command, AKS activity, backup access, or sensitive workload access after suspicious VPN context.

·        GCP Cloud Audit Log activity, Admin Activity logs, IAM activity, service-account activity, service-account key creation, service-account impersonation, organization-policy changes, logging changes, monitoring changes, firewall changes, Secret Manager access, Cloud KMS decrypt activity, Cloud Storage access, BigQuery activity, GKE activity, Cloud SQL activity, Cloud Build activity, or sensitive workload access after suspicious VPN context.

·        SaaS administration events, source-code access, repository cloning, developer-platform activity, CI/CD workflow modification, secret access, API token creation, application consent changes, audit-log access, security-control changes, or data export linked to suspicious VPN session context.

·        Cloud, SaaS, identity, source-code, and developer-platform anomalies should remain downstream investigative leads unless linked to suspicious VPN session evidence, trusted-session misuse, credential theft, token theft, or incident-response validation.

Artifact Interpretation Constraints

·        A vulnerable GlobalProtect version is an exposure artifact, not proof of exploitation.

·        A failed authentication event is not proof of bypass.

·        A suspicious portal or gateway request is not proof of successful VPN access.

·        A tunnel-established event is not malicious by itself.

·        Missing identity-provider, MFA, SAML, OIDC, HIP, certificate, posture, authentication-cookie, or session-token evidence may reflect telemetry gaps, ingestion delay, parser failure, retention limits, provider outage, timestamp skew, or join failure.

·        Source novelty, ASN novelty, geography novelty, device novelty, gateway change, or client-version novelty should be treated as a confidence amplifier, not standalone compromise evidence.

·        Internal discovery, endpoint alerts, cloud anomalies, SaaS anomalies, identity anomalies, developer-platform anomalies, or YARA artifact matches should not be attributed to GlobalProtect compromise without temporal and behavioral linkage.

·        Confirmed compromise should require evidence from multiple linked stages of the chain, such as suspicious GlobalProtect session context followed by internal reconnaissance, endpoint compromise evidence, credential or token access, control-plane activity, persistence, or incident-response validation.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

SOC Implementation Summary

SOC implementation should treat this report as a staged remote-access trust-failure model. The operational goal is to separate exposed GlobalProtect infrastructure, suspected bypass attempts, authentication-lineage inconsistency, unauthorized VPN session establishment, suspicious trusted-session use, downstream investigative leads, and confirmed compromise into distinct triage outcomes.

Initial Triage Priorities

·        Confirm whether the organization operates exposed GlobalProtect portals or gateways within the report scope.

·        Confirm affected PAN-OS and GlobalProtect version posture where available.

·        Confirm whether patch posture, compensating controls, authentication profile configuration, MFA enforcement, SAML or OIDC integration, certificate requirements, HIP profiles, gateway assignment, and split-tunnel behavior are known.

·        Confirm whether GlobalProtect portal logs, gateway logs, authentication logs, tunnel-established events, HIP logs, gateway-assignment logs, client configuration retrieval events, authentication-cookie context, and session-token context are retained.

·        Confirm whether identity-provider, MFA, conditional-access, SAML, OIDC, certificate, device-compliance, and risk-based access logs can be joined to GlobalProtect events.

·        Confirm whether VPN session context can be joined to endpoint telemetry, internal network telemetry, cloud logs, SaaS logs, developer-platform logs, and SIEM events.

·        Confirm whether normal baselines exist for GlobalProtect users, privileged VPN users, third-party access, gateway assignments, source geographies, source ASNs, client versions, device posture, HIP results, access windows, and internal resource access.

Triage Workflow

·        Start with the strongest GlobalProtect-side anchor, such as tunnel establishment without expected precursor evidence, portal-to-gateway sequencing anomaly, gateway-assignment mismatch, client configuration retrieval anomaly, HIP mismatch, authentication-cookie inconsistency, session-token inconsistency, or abnormal portal or gateway interaction followed by VPN session establishment.

·        Validate telemetry completeness before treating missing authentication-lineage evidence as suspicious.

·        Join GlobalProtect session evidence to identity-provider, MFA, SAML, OIDC, conditional-access, certificate, HIP, posture, and device-compliance evidence.

·        Review source context, including source IP, ASN, geography, hosting provider, anonymization service, residential proxy infrastructure, mobile carrier network, SASE egress point, first-seen timestamp, and user history.

·        Review account context, including privilege level, third-party status, contractor status, administrative role, security role, dormant status, stale status, recent re-enablement, low-frequency VPN usage, and sensitive access.

·        Review internal follow-on activity, including identity-service access, administrative protocol use, privileged resource access, internal discovery, destination novelty, cross-segment access, share enumeration, failed authentication bursts, and credential validation.

·        Review endpoint follow-on activity on the VPN-connected device and on internal systems reached through the VPN session.

·        Review downstream cloud, SaaS, identity, source-code, developer-platform, and CI/CD activity only when session timing, source path, user identity, device identity, identity session, or incident-response evidence supports linkage.

·        Apply change-control, approved travel, vendor access, helpdesk, administrator workflow, security testing, maintenance, SASE routing, gateway failover, VPN client upgrade, and incident-response context before escalation.

SOC Outcome Categories

·        Exposed infrastructure requiring patch or configuration review.

·        Suspected probing or exploit attempt against exposed portal or gateway services.

·        Authentication-lineage inconsistency requiring telemetry validation.

·        Suspicious tunnel establishment requiring identity, MFA, HIP, and gateway-sequence review.

·        Suspicious trusted VPN session use requiring internal access review.

·        Downstream investigative lead involving endpoint, identity, cloud, SaaS, source-code, CI/CD, or developer-platform activity.

·        Probable trusted-session compromise requiring containment and incident-response escalation.

·        Confirmed downstream compromise requiring incident-response handling, scoping, eradication, and recovery.

Hunt-Mode Deployment Guidance

·        Deploy new or revised detections in hunt mode before alert mode.

·        Validate parser behavior, field availability, field naming, timestamp alignment, session identifiers, user identifiers, device identifiers, source IP handling, gateway naming, and cloud identity mapping.

·        Validate timing windows for portal-to-gateway sequencing, identity-provider evidence, MFA evidence, HIP evidence, tunnel establishment, internal follow-on activity, endpoint behavior, cloud activity, SaaS activity, and developer-platform activity.

·        Validate exception handling for approved travel, mobile carrier use, residential ISP changes, SASE egress, gateway failover, disaster-recovery routing, VPN client upgrades, identity-provider maintenance, approved vendor access, helpdesk activity, administrator workflows, security testing, vulnerability management, incident response, and documented change-control activity.

·        Review historical matches to identify normal user behavior, normal privileged VPN usage, normal third-party access, normal cloud administration, normal developer workflows, normal helpdesk activity, normal security testing, and normal incident-response patterns.

·        Tune severity thresholds before enabling alert mode.

·        Confirm that SOC analysts have access to enrichment fields, supporting logs, triage notes, and escalation criteria.

Alert-Mode Promotion Criteria

·        Promote detections to alert mode only after field mappings are validated.

·        Promote detections only after telemetry completeness assumptions are tested.

·        Promote detections only after timing windows are tuned against local data.

·        Promote detections only after false-positive patterns are reviewed.

·        Promote detections only after query performance is validated.

·        Promote detections only after SOC triage procedures are documented.

·        Promote detections only after enrichment sources are available to analysts.

·        Promote detections only after exception logic is reviewed.

·        Promote detections only after incident-response evidence requirements are understood.

·        Promote detections only when alert routing, severity, ownership, and escalation paths are defined.

Escalation Guidance

·        Escalate when tunnel establishment occurs without expected identity-provider, MFA, SAML, OIDC, certificate, HIP, posture, authentication-cookie, session-token, or gateway-assignment evidence after telemetry completeness has been validated.

·        Escalate when suspicious tunnel establishment involves privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Escalate when suspicious VPN session establishment is followed by identity-service access, privileged resource access, internal reconnaissance, administrative protocol use, credential validation, share enumeration, failed internal authentication bursts, or access outside normal user role.

·        Escalate when suspicious VPN session context is followed by endpoint credential access, token access, suspicious process execution, persistence, tool staging, outbound follow-on communication, or suspicious activity on internal systems reached through the VPN session.

·        Escalate when suspicious VPN session context is followed by cloud IAM changes, role assignment, service-principal changes, service-account changes, access-key creation, token creation, conditional-access changes, logging changes, monitoring changes, security-control changes, secret access, key-management activity, storage access, workload access, or data export.

·        Escalate when multiple accounts, devices, gateways, internal systems, cloud resources, SaaS tenants, or developer platforms show related activity within the same incident window.

·        Escalate when evidence from at least two stages of the chain supports probable trusted-session compromise.

Containment and Response Considerations

·        Review and revoke suspicious GlobalProtect sessions.

·        Disable or reset affected user accounts where appropriate.

·        Revoke active identity-provider sessions and refresh tokens where appropriate.

·        Revoke or rotate exposed API keys, access keys, service-account keys, application credentials, SSH keys, certificates, and tokens where appropriate.

·        Review MFA enrollment, conditional-access configuration, authentication profiles, SAML or OIDC configuration, certificate requirements, HIP profiles, and gateway assignment.

·        Review GlobalProtect portal, gateway, authentication, HIP, and client configuration settings.

·        Review firewall policy, VPN configuration, administrator accounts, remote-access controls, and logging coverage.

·        Isolate or investigate endpoints and internal systems reached through suspicious VPN sessions.

·        Review cloud, SaaS, source-code, CI/CD, and developer-platform activity linked to suspicious VPN context.

·        Preserve relevant logs before retention windows expire.

·        Conduct incident-response scoping before making attribution or confirmed-compromise statements.

Analyst Guardrails

·        Do not treat vulnerable version posture as proof of exploitation.

·        Do not treat failed authentication as proof of bypass.

·        Do not treat a new source IP, ASN, geography, gateway, device, client version, or operating-system profile as proof of compromise.

·        Do not treat missing identity-provider, MFA, SAML, OIDC, HIP, certificate, posture, authentication-cookie, or session-token evidence as proof of bypass until telemetry completeness is validated.

·        Do not treat internal reconnaissance as GlobalProtect-linked unless it is tied to suspicious VPN session context.

·        Do not treat cloud, SaaS, source-code, CI/CD, or developer-platform anomalies as GlobalProtect-linked unless session timing, source path, user identity, device identity, identity session, or incident-response evidence supports linkage.

·        Do not use any single S25 rule as standalone proof of exploitation, compromise, or actor attribution.

·        Do not use YARA as primary detection unless a stable recovered artifact exists and is validated.

S29 — Detection Coverage Summary

Coverage Summary

The Block 4 detection model provides strong behavior-led coverage for GlobalProtect authentication-lineage failure, trusted VPN session misuse, internal follow-on activity, endpoint post-session behavior, and downstream cloud-control-plane exposure. Coverage is strongest when GlobalProtect telemetry, identity-provider logs, MFA evidence, HIP evidence, endpoint telemetry, internal network telemetry, cloud logs, SaaS logs, asset inventory, change-control records, and incident-response evidence can be correlated.

Strong Coverage Areas

·        GlobalProtect tunnel establishment without complete authentication-lineage evidence.

·        Portal-to-gateway sequencing anomalies.

·        Gateway assignment or gateway selection inconsistent with user, device, source, or policy context.

·        Missing or inconsistent identity-provider, MFA, SAML, OIDC, HIP, certificate, posture, authentication-cookie, or session-token evidence after telemetry completeness validation.

·        Suspicious VPN session establishment involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency VPN accounts.

·        Suspicious VPN session establishment from unfamiliar or high-risk source infrastructure.

·        VPN-authenticated internal access involving identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, endpoint-management platforms, source-code systems, CI/CD infrastructure, sensitive file shares, databases, or high-value business applications.

·        VPN-authenticated use of LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, or administrative-protocol activity outside normal role.

·        Endpoint activity after suspicious VPN context, including suspicious execution, credential access, token access, tool staging, persistence, and suspicious activity on internal systems reached through the VPN session.

·        Cloud, SaaS, source-code, CI/CD, developer-platform, identity, and control-plane activity linked to suspicious VPN session context.

·        AWS, Azure, and GCP IAM, security-control, data, secrets, key-management, workload, storage, backup, Kubernetes, and database activity after suspicious VPN context.

Moderate Coverage Areas

·        Exploit-attempt activity where no successful tunnel establishment is confirmed.

·        Suspicious portal or gateway probing when authentication-lineage evidence is incomplete.

·        Source-infrastructure novelty without downstream behavior.

·        Cloud, SaaS, identity, developer-platform, or CI/CD anomalies where VPN linkage is partial.

·        Endpoint behavior where GlobalProtect session context is inferred through SIEM, NDR, or identity enrichment rather than directly visible in endpoint telemetry.

·        Internal access where split tunneling, SASE routing, ZTNA overlays, NAT, proxy paths, or endpoint-only telemetry limits visibility.

·        Low-and-slow post-session activity where attacker behavior stays close to normal user baselines.

·        Suspicious activity involving valid credentials, reused sessions, reused tokens, expected cloud sessions, or expected administrator tooling.

Limited Coverage Areas

·        Artifact-only detection when no stable file, payload, script, memory artifact, webshell, binary, or reusable file-content pattern is recovered.

·        YARA-based detection without validated incident artifacts.

·        Authentication-lineage reconstruction where GlobalProtect portal, gateway, HIP, client configuration retrieval, gateway assignment, authentication-cookie, or session-token telemetry is unavailable.

·        Identity-provider, MFA, SAML, OIDC, conditional-access, certificate, or device-compliance correlation where identifiers cannot be joined reliably.

·        Source attribution in environments affected by NAT, carrier-grade NAT, mobile networks, SASE egress, proxy infrastructure, ZTNA overlays, residential ISP changes, or third-party access paths.

·        Cloud and SaaS activity that occurs through pre-existing sessions, reused tokens, different devices, different source paths, or outside validated correlation windows.

·        Endpoint activity on unmanaged devices, contractor systems, personal systems, third-party-managed endpoints, or assets without EDR coverage.

Systems With Primary Rule Coverage

·        NDR / Network Behavioral Analytics.

·        SentinelOne.

·        Splunk.

·        Elastic.

·        QRadar.

·        SIGMA.

·        AWS.

·        Azure.

·        GCP.

Systems With Conditional or No Primary Rule Coverage

·        YARA has no primary rules for this report.

·        YARA remains conditional and artifact-dependent.

·        YARA may support investigative hunting only if responders recover stable artifacts linked to suspicious VPN session establishment or downstream activity.

Coverage Strength by Detection Phase

·        Pre-session probing coverage is moderate where portal and gateway logs capture malformed, abnormal, scanner-like, or repeated interaction patterns.

·        Authentication-lineage coverage is strong where GlobalProtect, identity-provider, MFA, SAML, OIDC, HIP, certificate, posture, gateway-assignment, and tunnel-established telemetry can be joined.

·        VPN session establishment coverage is strong where tunnel events, gateway logs, portal logs, session identifiers, user context, device context, and source enrichment are available.

·        Trusted-session misuse coverage is strong where VPN session context can be correlated with internal DNS, identity-service, administrative-protocol, privileged-resource, and endpoint telemetry.

·        Endpoint follow-on coverage is moderate to strong where EDR telemetry and session enrichment can be joined.

·        Cloud and SaaS downstream coverage is moderate to strong where cloud audit logs, SaaS logs, identity-provider logs, source-path evidence, device evidence, and incident timelines can be correlated.

·        Artifact-based coverage is limited unless validated artifacts are recovered.

Coverage Confidence

·        High confidence applies when multiple linked stages are present, including suspicious GlobalProtect session context, validated authentication-lineage inconsistency, internal follow-on activity, endpoint evidence, cloud or SaaS activity, and incident-response validation.

·        Medium confidence applies when suspicious GlobalProtect session context exists with partial authentication-lineage inconsistency or limited downstream behavior.

·        Low confidence applies to isolated exposure posture, isolated failed authentication, isolated source novelty, isolated cloud activity, isolated endpoint alerting, or isolated artifact matches.

·        Confirmed compromise confidence requires evidence beyond S25 detection logic, including validated incident-response findings, endpoint compromise evidence, identity compromise evidence, cloud compromise evidence, credential or token theft evidence, persistence, data access, or other confirmed downstream activity.

Coverage Limitations

·        Coverage depends on local telemetry availability, parser quality, timestamp alignment, field mappings, session identifiers, identity mappings, source-path context, asset inventories, and enrichment.

·        Coverage depends on whether GlobalProtect logs retain enough detail to reconstruct portal-to-identity-to-gateway-to-tunnel sequencing.

·        Coverage depends on whether identity-provider, MFA, SAML, OIDC, conditional-access, HIP, certificate, and device-compliance evidence can be joined to GlobalProtect events.

·        Coverage depends on whether split-tunnel routing, SASE architecture, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, residential ISP changes, and third-party access paths reduce visibility.

·        Coverage depends on whether cloud, SaaS, source-code, CI/CD, and developer-platform logs are retained and normalized.

·        Coverage depends on whether SOC analysts can access enrichment, change-control records, approved workflow records, and incident-response context.

·        Coverage should not be interpreted as universal prevention, universal exploit detection, or standalone attribution.

S30 — Intelligence Maturity Assessment

Intelligence Maturity Summary

The detection model for this report reflects a mature behavior-led intelligence posture. It moves beyond CVE-only, IOC-only, version-only, and artifact-only detection by focusing on authentication-lineage integrity, trusted VPN session behavior, identity linkage, endpoint follow-on activity, internal access patterns, and downstream cloud-control-plane exposure.

Current Maturity Level

High.

Maturity Rationale

·        The model identifies GlobalProtect authentication-lineage failure as a staged trust-chain problem rather than a single exploit event.

·        The model separates exposure, suspected probing, authentication-lineage inconsistency, suspicious session establishment, trusted-session misuse, downstream investigative leads, and confirmed compromise.

·        The model uses durable behavioral anchors that remain useful when source infrastructure, user-agent values, exploit strings, client versions, timing, post-session actions, or cloud targets change.

·        The model avoids single-signal attribution and requires supporting evidence before declaring exploitation, compromise, cloud compromise, SaaS compromise, credential theft, token theft, or actor attribution.

·        The model includes network, endpoint, SIEM, SIGMA, and cloud-native coverage across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

·        The model correctly treats YARA as conditional and artifact-dependent rather than forcing weak artifact-led coverage into a behavior-led report.

·        The model supports SOC operations through hunt-mode deployment, field validation, timing-window tuning, exception handling, false-positive review, query-performance testing, and triage readiness.

Intelligence Strengths

·        Strong behavior-led framing.

·        Strong authentication-lineage reconstruction model.

·        Strong separation of suspicious activity from confirmed compromise.

·        Strong non-attribution discipline.

·        Strong coverage across VPN-edge, identity, endpoint, internal network, cloud, SaaS, source-code, and CI/CD telemetry.

·        Strong variant resilience against changes in source infrastructure, exploit mechanics, user-agent values, request paths, client versions, timing, and downstream activity.

·        Strong support for SOC triage and incident scoping.

·        Strong cloud downstream exposure model across AWS, Azure, and GCP.

·        Strong support for future amendment if new CVEs, proof-of-concept behavior, actor adoption, cloud abuse, or post-exploitation behavior emerges.

Maturity Constraints

·        Full maturity depends on GlobalProtect portal, gateway, HIP, gateway-assignment, client configuration retrieval, tunnel-established, authentication-cookie, and session-token telemetry availability.

·        Full maturity depends on reliable identity-provider, MFA, SAML, OIDC, conditional-access, certificate, and device-compliance correlation.

·        Full maturity depends on endpoint telemetry coverage for VPN-connected devices and internal systems reached through suspicious VPN sessions.

·        Full maturity depends on internal network visibility for VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, and administrative-protocol activity.

·        Full maturity depends on cloud, SaaS, source-code, developer-platform, and CI/CD log availability.

·        Full maturity depends on source enrichment, account enrichment, asset inventory, gateway inventory, privileged-account inventory, third-party access inventory, cloud inventory, sensitive-asset inventory, and change-control integration.

·        Full maturity depends on local SIEM field mappings, parser reliability, timestamp alignment, query performance, exception handling, and SOC triage readiness.

·        Full maturity is reduced in environments with split tunneling, SASE routing, ZTNA overlays, proxy infrastructure, NAT, carrier-grade NAT, mobile networks, residential ISP changes, unmanaged endpoints, contractor devices, or weak cloud session attribution.

Operational Maturity Requirements

·        Maintain current GlobalProtect portal and gateway inventory.

·        Maintain current PAN-OS and GlobalProtect patch posture.

·        Maintain GlobalProtect authentication profile, SAML or OIDC provider, MFA provider, HIP profile, certificate, gateway assignment, split-tunnel, and logging configuration inventory.

·        Maintain VPN user, privileged VPN user, administrator, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, and low-frequency account inventories.

·        Maintain source baselines for normal VPN user geographies, ASNs, remote-work locations, vendor access, SASE egress points, mobile carrier ranges, residential ISP patterns, and third-party access paths.

·        Maintain baselines for normal GlobalProtect portal requests, portal authentication, client configuration retrieval, gateway assignment, gateway authentication, tunnel establishment, HIP evaluation, client versions, operating-system profiles, and internal resource access.

·        Maintain internal asset inventories for domain controllers, identity infrastructure, jump hosts, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, sensitive file shares, databases, and high-value applications.

·        Maintain cloud inventories for AWS accounts, Azure tenants and subscriptions, GCP organizations and projects, privileged roles, service principals, service accounts, managed identities, sensitive storage, secrets, keys, workloads, Kubernetes clusters, databases, and backup systems.

·        Maintain change-control, vendor-support, helpdesk, maintenance, security-testing, vulnerability-management, software-deployment, cloud-operations, developer-workflow, CI/CD-maintenance, and incident-response records for triage.

Detection Engineering Maturity Requirements

·        Validate all local field mappings before production alerting.

·        Validate event-action normalization across PAN-OS, GlobalProtect, identity-provider, MFA, endpoint, NDR, proxy, DNS, cloud, SaaS, source-code, CI/CD, and SIEM telemetry.

·        Validate portal-to-gateway sequence logic.

·        Validate authentication-lineage correlation logic.

·        Validate VPN session linkage.

·        Validate endpoint and internal destination linkage.

·        Validate cloud, SaaS, source-code, and CI/CD linkage.

·        Validate source-path handling where NAT, SASE, proxy, ZTNA, mobile carrier, residential ISP, or third-party access paths may transform source attribution.

·        Validate timing windows for immediate, delayed, repeated, and low-and-slow activity.

·        Validate exception handling.

·        Validate baseline false-positive rates.

·        Validate query performance.

·        Validate SOC triage workflow.

·        Validate enrichment availability.

·        Validate incident-response evidence requirements.

·        Do not enable alert mode until these local validation requirements are complete.

Recommended Maturity Improvements

·        Improve GlobalProtect logging coverage for portal, gateway, authentication, HIP, gateway assignment, client configuration retrieval, tunnel establishment, reconnect, disconnect, authentication-cookie, and session-token context.

·        Improve identity-provider and MFA retention for SAML, OIDC, MFA, conditional-access, device-compliance, risk-based access, session, token, assertion, and policy-decision events.

·        Improve endpoint coverage for VPN-connected systems and high-value internal systems reached through VPN sessions.

·        Improve internal network visibility for VPN-authenticated access to identity services, privileged resources, administrative protocols, databases, file shares, jump hosts, and management systems.

·        Improve cloud audit coverage for AWS, Azure, and GCP.

·        Improve SaaS, source-code, developer-platform, and CI/CD logging for downstream investigation.

·        Improve enrichment for source reputation, ASN, geography, hosting providers, anonymization services, residential proxy infrastructure, mobile carrier networks, SASE egress, vendor access, and first-seen source activity.

·        Improve user, device, gateway, session, tunnel, SAML, source, identity-provider, cloud identity, and asset identifier consistency across telemetry platforms.

·        Improve change-control integration for remote-access changes, authentication-policy changes, MFA changes, conditional-access changes, HIP changes, gateway maintenance, SASE routing, vendor access, cloud operations, developer workflows, CI/CD maintenance, and incident response.

·        Improve SOC runbooks for suspicious VPN session establishment, authentication-lineage validation, trusted-session misuse, downstream cloud exposure, and confirmed compromise escalation.

Residual Intelligence Risk

Residual risk remains where attackers use valid credentials, valid tokens, reused cloud sessions, expected administrator pathways, legitimate remote-access locations, SASE egress, third-party access paths, or low-and-slow post-session behavior that blends with expected user activity.

Residual risk also remains where telemetry is incomplete, identity linkage is weak, session identifiers are inconsistent, source attribution is transformed, cloud logs are incomplete, endpoint coverage is absent, or SOC teams cannot access change-control and incident-response context.

The detection model reduces residual risk by requiring multiple linked behavioral stages, but it does not eliminate the need for local validation, incident-response review, and environment-specific tuning.

Final Intelligence Maturity Assessment

The Block 4 detection model is mature and operationally useful for identifying GlobalProtect authentication-lineage bypass and trusted VPN session compromise when required telemetry is available and locally validated. It is strongest as a behavior-led detection and triage model and should not be interpreted as a universal exploit-confirmation or actor-attribution framework.

S31 — Telemetry Dependencies

GlobalProtect authentication-lineage bypass and trusted VPN session compromise require telemetry that can prove whether a VPN session followed the expected remote-access trust sequence. The central dependency is the ability to connect GlobalProtect portal activity, gateway activity, identity-provider authentication, MFA or conditional-access decisions, SAML context, certificate validation, HIP posture, tunnel establishment, and downstream access behavior into a single session-lineage model.

GlobalProtect Portal and Gateway Telemetry

·        GlobalProtect portal authentication events, gateway authentication events, client configuration retrieval, gateway assignment, tunnel establishment, session state, reconnects, disconnects, and policy-evaluation outcomes.

·        Portal name, gateway name, gateway region, user identity, source IP, source geography, source ASN, client version, operating-system profile, device identifier, session identifier, tunnel identifier, timestamp, authentication result, and gateway-selection context where available.

·        Direct evidence of portal-to-gateway sequencing is required for high-confidence detection of authentication-lineage gaps, trusted-session misuse, or unauthorized VPN session establishment.

Identity-Provider and MFA Telemetry

·        Identity-provider authentication events, SAML assertion context, OIDC context, MFA challenge result, conditional-access result, device-compliance result, risk score, authentication method, source IP, user-agent, device identifier, identity-provider session identifier, and timestamp.

·        Successful, failed, denied, challenged, expired, bypassed, mismatched, or policy-inconsistent identity and MFA events near GlobalProtect session establishment.

·        Identity-provider and MFA telemetry are required to determine whether the VPN session followed the expected identity and access-control path rather than relying only on GlobalProtect tunnel state.

SAML, Certificate, HIP, and Device-Posture Telemetry

·        SAML assertion context, certificate validation context, certificate identity, certificate issuer, certificate age, HIP match result, HIP report result, device posture, endpoint identity, operating-system profile, managed-device state, and GlobalProtect client version.

·        Previous and current posture state, HIP profile, certificate context, device identifier, client configuration retrieval behavior, and gateway assignment where available.

·        Posture telemetry is required to distinguish malicious authentication-lineage inconsistency from legitimate device re-enrollment, policy update, certificate rotation, endpoint replacement, or GlobalProtect client upgrade activity.

PAN-OS and Remote-Access Infrastructure Telemetry

·        PAN-OS traffic logs, threat logs, system logs, authentication logs, configuration logs, management logs, administrative logs, commit events, portal changes, gateway changes, authentication profile changes, HIP profile changes, certificate changes, policy changes, and remote-access configuration changes.

·        Exposed interface inventory, portal inventory, gateway inventory, affected PAN-OS version context, patch posture, compensating controls, split-tunnel configuration, gateway routing, and remote-access policy context.

·        PAN-OS telemetry is required to connect remote-access behavior to firewall configuration, portal exposure, gateway behavior, administrative changes, and local infrastructure state.

Endpoint and VPN Client Telemetry

·        GlobalProtect client process activity, VPN client launch, client configuration retrieval, VPN adapter creation, reconnect behavior, disconnect behavior, source network context, endpoint identity, certificate use, process execution, parent-child process relationships, command-line arguments, network connections, and device posture context.

·        Endpoint telemetry from systems accessed through the VPN session, including process execution, tool staging, credential-access behavior, remote administration tooling, persistence creation, file activity, outbound communication, and suspicious child-process activity.

·        Endpoint telemetry is required to validate whether suspicious VPN access produced post-session behavior on the endpoint or on internal systems reached through the trusted VPN path.

Network and Internal Access Telemetry

·        VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S, file-share, jump-host, privileged-management, cloud-connector, and administrative-protocol traffic.

·        Source IP, source ASN, source geography, gateway, tunnel identifier, session identifier, user identity, device identity, destination asset, destination zone, protocol, port, bytes, duration, and timestamp where available.

·        Internal network telemetry is required to determine whether suspicious VPN establishment led to internal reconnaissance, identity-service interaction, privileged resource access, lateral-movement preparation, or high-value resource exposure.

Cloud, SaaS, and Developer-Platform Telemetry

·        Cloud control-plane audit logs, cloud console access, cloud API activity, SaaS administration activity, identity administration activity, developer-platform access, source-code repository access, CI/CD workflow activity, API token creation, access-key activity, application consent changes, privileged role access, repository cloning, secret access, and data export events.

·        User identity, device identity, source path, identity-provider session, VPN session window, destination application, action, result, timestamp, and privileged role context where available.

·        Cloud, SaaS, and developer-platform telemetry should be used for downstream exposure scoping and should not be attributed to GlobalProtect compromise unless linked to suspicious VPN session evidence.

Asset, Account, and Change-Control Telemetry

·        VPN user inventory, privileged account inventory, third-party access inventory, contractor account inventory, dormant and stale account inventory, low-frequency VPN user inventory, gateway inventory, certificate inventory, device inventory, cloud tenant inventory, SaaS tenant inventory, source-code inventory, CI/CD inventory, and backup-system inventory.

·        Approved travel records, vendor-support records, helpdesk records, administrator workflow records, change-control records, maintenance windows, VPN client upgrade records, SASE routing changes, identity-provider maintenance records, and incident-response records.

·        Asset, account, and change-control context is required to separate suspicious trusted-session activity from legitimate remote-work, administrative, vendor, security-testing, or incident-response activity.

S32 — Detection Limitations

Detection of GlobalProtect authentication-lineage bypass and trusted VPN session compromise is limited by whether the organization can reconstruct the expected remote-access trust sequence. Environments that rely only on VPN tunnel-established events, source IP novelty, vulnerable version posture, or isolated failed authentication events will not have enough evidence for high-confidence detection.

Primary Limitations

·        Missing GlobalProtect portal logs reduce the ability to prove whether portal authentication or client configuration retrieval occurred before gateway access.

·        Missing GlobalProtect gateway logs reduce the ability to validate gateway authentication, gateway assignment, tunnel establishment, reconnect behavior, and session-state transitions.

·        Missing identity-provider telemetry prevents reliable validation of whether the VPN session followed expected identity authentication.

·        Missing MFA or conditional-access telemetry prevents reliable validation of whether the VPN session satisfied expected access-control decisions.

·        Missing SAML, OIDC, certificate, HIP, or device-posture telemetry weakens the ability to distinguish legitimate session establishment from authentication-lineage failure.

·        Missing session identifiers, tunnel identifiers, SAML identifiers, device identifiers, or consistent usernames can break correlation across GlobalProtect, identity-provider, MFA, endpoint, cloud, SaaS, and SIEM telemetry.

·        Missing internal network telemetry can prevent defenders from determining whether a suspicious VPN session reached identity services, privileged resources, sensitive applications, or lateral-movement paths.

·        Missing cloud, SaaS, source-code, CI/CD, or developer-platform telemetry can obscure downstream exposure after suspicious VPN access.

·        Poor timestamp normalization can break sequence logic between portal activity, identity-provider authentication, MFA decisions, gateway authentication, tunnel establishment, and post-session internal access.

·        Split-tunnel configurations, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, residential proxy infrastructure, and third-party access paths can reduce source-attribution confidence.

Detection Boundary

·        A vulnerable GlobalProtect version is an exposure signal, not proof of active exploitation.

·        A failed authentication event is not proof of authentication bypass.

·        A suspicious source IP, ASN, geography, user-agent, client version, or device profile is not compromise evidence by itself.

·        A tunnel-established event is not malicious by itself unless authentication-lineage, gateway-sequencing, posture, source, or downstream behavior supports escalation.

·        Missing identity-provider, MFA, SAML, HIP, certificate, or device-posture evidence may reflect telemetry delay, ingestion failure, log-retention limits, parser failure, provider outage, timestamp skew, or integration gaps.

·        Internal discovery is not automatically GlobalProtect compromise unless it is temporally and behaviorally linked to suspicious VPN session establishment, missing authentication-lineage evidence, or unauthorized trusted-session use.

·        Cloud, SaaS, identity, and developer-platform anomalies should remain downstream investigative leads unless linked to suspicious VPN session evidence, trusted-session abuse, credential theft, token theft, or validated post-session activity.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized. A GlobalProtect session may be analytically suspicious but unsuitable for high-confidence alerting if the organization cannot prove the authentication lineage, session linkage, and downstream activity within bounded and locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making GlobalProtect remote-access trust measurable, enforceable, and recoverable after suspicious session activity. The objective is not only to patch exposed portals and gateways, but to prove that VPN sessions follow the expected identity, MFA, posture, gateway, and tunnel sequence.

GlobalProtect Exposure and Patch Governance

·        Maintain a complete inventory of internet-facing GlobalProtect portals, gateways, gateway clusters, exposed interfaces, gateway regions, affected PAN-OS versions, and compensating controls.

·        Validate patch posture for GlobalProtect portals and gateways on a defined schedule and during active exploitation windows.

·        Prioritize remediation for exposed portals and gateways supporting privileged users, third-party users, remote administrators, cloud administrators, developer access, source-code access, CI/CD access, or backup administration.

·        Treat unknown patch posture, unmanaged exposed gateways, or incomplete gateway inventories as remote-access trust risks.

Authentication-Lineage Enforcement

·        Require strong authentication sequencing across GlobalProtect portal access, identity-provider authentication, MFA or conditional access, SAML assertion validation, certificate validation, HIP evaluation, gateway assignment, gateway authentication, and tunnel establishment.

·        Monitor for tunnel establishment without expected identity-provider, MFA, SAML, certificate, HIP, posture, gateway-assignment, authentication-cookie, or session-token evidence.

·        Validate that GlobalProtect, identity-provider, MFA, certificate, HIP, and SIEM telemetry can be joined reliably using user, device, source IP, session, assertion, gateway, and timestamp context.

·        Treat unexplained authentication-lineage gaps as trust-impacting events requiring investigation before the session is considered legitimate.

Privileged and Third-Party VPN Access Governance

·        Apply stricter access controls to privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, and low-frequency VPN accounts.

·        Require MFA, conditional access, device posture, certificate validation, and limited gateway assignment for high-risk VPN users.

·        Review third-party and contractor VPN access for least privilege, expiration, business justification, source restrictions, and monitored access windows.

·        Disable or restrict dormant, stale, recently re-enabled, and low-frequency VPN accounts that lack current business justification.

HIP, Certificate, Device-Posture, and Gateway Controls

·        Define expected HIP profiles, certificate requirements, client versions, operating-system profiles, managed-device states, gateway assignments, and gateway-routing patterns by user group and endpoint class.

·        Monitor for missing, downgraded, newly observed, or inconsistent HIP results, certificate context, endpoint identity, client version, operating-system profile, or device-posture values.

·        Validate gateway-assignment logic, regional gateway selection, split-tunnel configuration, failover behavior, SASE routing, and ZTNA overlays against expected remote-access architecture.

·        Treat unexpected gateway assignment or posture mismatch as a confidence amplifier when paired with authentication-lineage gaps or suspicious downstream activity.

Session Revocation and Remote-Access Trust Restoration

·        Create response procedures for suspicious GlobalProtect session revocation, credential reset, token review, certificate review, MFA review, conditional-access validation, and HIP-policy validation.

·        Require rapid scoping of all sessions tied to affected users, devices, source infrastructure, gateways, identity-provider sessions, SAML assertions, authentication cookies, or session tokens.

·        Validate whether suspicious VPN sessions reached identity infrastructure, privileged resources, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, or backup infrastructure.

·        Require remote-access trust restoration before returning affected VPN users, gateways, accounts, or devices to normal operation.

SOC and Incident Response Hardening

·        Treat suspicious trusted VPN sessions as trust-impacting events rather than routine remote-access anomalies.

·        Add playbook steps for validating portal-to-gateway sequencing, identity-provider evidence, MFA evidence, SAML context, certificate context, HIP result, device posture, gateway assignment, tunnel establishment, and downstream internal access.

·        Require responders to determine whether suspicious VPN access was followed by internal reconnaissance, identity-service interaction, privileged resource access, cloud or SaaS control-plane activity, developer-platform access, source-code access, CI/CD interaction, credential validation, token access, or lateral movement.

·        Use change-control records, vendor-support records, travel records, SASE routing changes, gateway maintenance, identity-provider maintenance, VPN client upgrade records, security-testing records, and incident-response records as triage evidence.

S34 — Defensive Control & Hardening Architecture

The defensive architecture should treat GlobalProtect authentication lineage as a monitored trust layer rather than an assumed condition. The architecture must connect remote-access infrastructure, identity-provider evidence, MFA decisions, posture validation, session state, endpoint context, internal network activity, and downstream cloud or SaaS activity into a single validation model.

Architecture Layer 1: GlobalProtect Exposure and Remote-Access Inventory

GlobalProtect exposure and inventory telemetry establishes what remote-access infrastructure exists and whether it is hardened. This layer captures internet-facing portals, gateways, gateway clusters, exposed interfaces, PAN-OS version posture, patch status, compensating controls, gateway assignments, split-tunnel configuration, and remote-access policy.

Architecture Layer 2: Authentication-Lineage Validation

Authentication-lineage validation proves whether the session followed the expected trust sequence. This layer joins portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, client configuration retrieval, tunnel establishment, and session state.

Architecture Layer 3: Device, Posture, and Certificate Assurance

Device and posture assurance validates whether the claimed endpoint should have been trusted. This layer captures HIP match results, HIP report results, certificate context, endpoint identity, managed-device state, GlobalProtect client version, operating-system profile, device posture, authentication-cookie context, and session-token context.

Architecture Layer 4: User, Account, and Source Context

User, account, and source context determines whether the session aligns with expected behavior. This layer includes privileged-user status, third-party access status, contractor status, stale or dormant account status, low-frequency VPN behavior, user baseline, device baseline, source IP, ASN, geography, network type, SASE path, NAT context, and approved remote-access patterns.

Architecture Layer 5: Post-Session Internal and Control-Plane Monitoring

Post-session monitoring determines whether the trusted VPN path was used for follow-on activity. This layer captures DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, cloud-console, SaaS-administration, developer-platform, source-code, CI/CD, and backup-system access after VPN establishment.

Architecture Layer 6: SOC Correlation and Trust-Restoration Workflow

SOC correlation joins suspicious VPN session establishment with authentication-lineage evidence and post-session activity. Response workflow requires session revocation, credential reset decisioning, MFA and identity-provider validation, certificate and HIP validation, gateway review, privileged account review, downstream access scoping, and remote-access trust restoration.

Architecture Outcome

The architecture should enable the organization to answer five questions during an incident:

·        Did the VPN session follow the expected authentication lineage?

·        Did the session involve a trusted user, trusted device, expected gateway, and expected posture context?

·        Was any lineage gap explained by approved change, telemetry delay, provider outage, routing behavior, or maintenance?

·        Did the session reach internal identity, privileged, cloud, SaaS, developer, source-code, CI/CD, or backup resources?

·        Can remote-access trust be restored with confidence before the user, device, gateway, or account returns to normal operation?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        GlobalProtect portal and gateway patch governance.

·        Internet-facing remote-access asset inventory.

·        Strong MFA and conditional-access enforcement.

·        Certificate-based access enforcement where appropriate.

·        HIP and device-posture enforcement.

·        Gateway-assignment governance.

·        Split-tunnel and remote-access policy governance.

·        Least-privilege VPN access.

·        Privileged VPN account restrictions.

·        Third-party and contractor access expiration.

·        Dormant and stale VPN account disablement.

·        Source restrictions for high-risk access where operationally feasible.

·        Strong authentication for VPN and firewall administration.

·        Change-control governance for GlobalProtect configuration.

Detective Controls

·        GlobalProtect portal and gateway authentication monitoring.

·        Portal-to-gateway sequencing correlation.

·        Tunnel-established event monitoring.

·        Identity-provider and MFA correlation.

·        SAML, certificate, HIP, and device-posture validation.

·        Authentication-cookie and session-token inconsistency monitoring where available.

·        Gateway-assignment anomaly detection.

·        Source novelty and source-risk enrichment.

·        Privileged and third-party VPN account monitoring.

·        VPN-authenticated internal access monitoring.

·        Identity-service and privileged-resource access monitoring.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup access correlation after suspicious VPN establishment.

·        Multi-stage correlation across VPN-edge, identity, endpoint, network, cloud, SaaS, and SIEM telemetry.

Responsive Controls

·        Suspicious VPN session revocation.

·        Credential reset and credential-risk review.

·        MFA session review and reauthentication enforcement.

·        Identity-provider session review.

·        Certificate review and certificate revocation where needed.

·        HIP and device-posture validation.

·        Gateway-assignment review.

·        Firewall and VPN configuration validation.

·        Privileged and third-party account scoping.

·        Endpoint triage for VPN-connected systems.

·        Internal access scoping.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup exposure review.

·        Remote-access trust restoration before return to normal operation.

·        Incident playbooks for trusted VPN session compromise.

Governance Controls

·        Known-good GlobalProtect authentication-lineage model.

·        Approved remote-access architecture documentation.

·        Approved GlobalProtect portal and gateway inventory.

·        Approved privileged VPN user inventory.

·        Approved third-party and contractor access inventory.

·        Approved source and geography baselines where feasible.

·        Approved device, certificate, HIP, and posture baselines.

·        Gateway-assignment and routing documentation.

·        SASE, ZTNA, proxy, NAT, and split-tunnel documentation.

·        Change-control records for GlobalProtect, identity-provider, MFA, HIP, certificate, and routing changes.

·        Executive reporting for high-risk remote-access trust failures.

·        Risk-register tracking for GlobalProtect trusted-session compromise exposure.

Control Mapping Summary

The strongest control posture combines prevention of unauthorized or weakly validated VPN access, detection of authentication-lineage failure, and response workflows that restore remote-access trust. Controls should be prioritized for internet-facing GlobalProtect portals and gateways, privileged VPN users, third-party access, remote administrators, identity infrastructure, cloud and SaaS administration, source-code systems, CI/CD environments, and backup infrastructure.

S31 — Telemetry Dependencies

GlobalProtect authentication-lineage bypass and trusted VPN session compromise require telemetry that can prove whether a VPN session followed the expected remote-access trust sequence. The central dependency is the ability to connect GlobalProtect portal activity, gateway activity, identity-provider authentication, MFA or conditional-access decisions, SAML context, certificate validation, HIP posture, tunnel establishment, and downstream access behavior into a single session-lineage model.

GlobalProtect Portal and Gateway Telemetry

·        GlobalProtect portal authentication events, gateway authentication events, client configuration retrieval, gateway assignment, tunnel establishment, session state, reconnects, disconnects, and policy-evaluation outcomes.

·        Portal name, gateway name, gateway region, user identity, source IP, source geography, source ASN, client version, operating-system profile, device identifier, session identifier, tunnel identifier, timestamp, authentication result, and gateway-selection context where available.

·        Direct evidence of portal-to-gateway sequencing is required for high-confidence detection of authentication-lineage gaps, trusted-session misuse, or unauthorized VPN session establishment.

Identity-Provider and MFA Telemetry

·        Identity-provider authentication events, SAML assertion context, OIDC context, MFA challenge result, conditional-access result, device-compliance result, risk score, authentication method, source IP, user-agent, device identifier, identity-provider session identifier, and timestamp.

·        Successful, failed, denied, challenged, expired, bypassed, mismatched, or policy-inconsistent identity and MFA events near GlobalProtect session establishment.

·        Identity-provider and MFA telemetry are required to determine whether the VPN session followed the expected identity and access-control path rather than relying only on GlobalProtect tunnel state.

SAML, Certificate, HIP, and Device-Posture Telemetry

·        SAML assertion context, certificate validation context, certificate identity, certificate issuer, certificate age, HIP match result, HIP report result, device posture, endpoint identity, operating-system profile, managed-device state, and GlobalProtect client version.

·        Previous and current posture state, HIP profile, certificate context, device identifier, client configuration retrieval behavior, and gateway assignment where available.

·        Posture telemetry is required to distinguish malicious authentication-lineage inconsistency from legitimate device re-enrollment, policy update, certificate rotation, endpoint replacement, or GlobalProtect client upgrade activity.

PAN-OS and Remote-Access Infrastructure Telemetry

·        PAN-OS traffic logs, threat logs, system logs, authentication logs, configuration logs, management logs, administrative logs, commit events, portal changes, gateway changes, authentication profile changes, HIP profile changes, certificate changes, policy changes, and remote-access configuration changes.

·        Exposed interface inventory, portal inventory, gateway inventory, affected PAN-OS version context, patch posture, compensating controls, split-tunnel configuration, gateway routing, and remote-access policy context.

·        PAN-OS telemetry is required to connect remote-access behavior to firewall configuration, portal exposure, gateway behavior, administrative changes, and local infrastructure state.

Endpoint and VPN Client Telemetry

·        GlobalProtect client process activity, VPN client launch, client configuration retrieval, VPN adapter creation, reconnect behavior, disconnect behavior, source network context, endpoint identity, certificate use, process execution, parent-child process relationships, command-line arguments, network connections, and device posture context.

·        Endpoint telemetry from systems accessed through the VPN session, including process execution, tool staging, credential-access behavior, remote administration tooling, persistence creation, file activity, outbound communication, and suspicious child-process activity.

·        Endpoint telemetry is required to validate whether suspicious VPN access produced post-session behavior on the endpoint or on internal systems reached through the trusted VPN path.

Network and Internal Access Telemetry

·        VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, HTTP/S, file-share, jump-host, privileged-management, cloud-connector, and administrative-protocol traffic.

·        Source IP, source ASN, source geography, gateway, tunnel identifier, session identifier, user identity, device identity, destination asset, destination zone, protocol, port, bytes, duration, and timestamp where available.

·        Internal network telemetry is required to determine whether suspicious VPN establishment led to internal reconnaissance, identity-service interaction, privileged resource access, lateral-movement preparation, or high-value resource exposure.

Cloud, SaaS, and Developer-Platform Telemetry

·        Cloud control-plane audit logs, cloud console access, cloud API activity, SaaS administration activity, identity administration activity, developer-platform access, source-code repository access, CI/CD workflow activity, API token creation, access-key activity, application consent changes, privileged role access, repository cloning, secret access, and data export events.

·        User identity, device identity, source path, identity-provider session, VPN session window, destination application, action, result, timestamp, and privileged role context where available.

·        Cloud, SaaS, and developer-platform telemetry should be used for downstream exposure scoping and should not be attributed to GlobalProtect compromise unless linked to suspicious VPN session evidence.

Asset, Account, and Change-Control Telemetry

·        VPN user inventory, privileged account inventory, third-party access inventory, contractor account inventory, dormant and stale account inventory, low-frequency VPN user inventory, gateway inventory, certificate inventory, device inventory, cloud tenant inventory, SaaS tenant inventory, source-code inventory, CI/CD inventory, and backup-system inventory.

·        Approved travel records, vendor-support records, helpdesk records, administrator workflow records, change-control records, maintenance windows, VPN client upgrade records, SASE routing changes, identity-provider maintenance records, and incident-response records.

·        Asset, account, and change-control context is required to separate suspicious trusted-session activity from legitimate remote-work, administrative, vendor, security-testing, or incident-response activity.

S32 — Detection Limitations

Detection of GlobalProtect authentication-lineage bypass and trusted VPN session compromise is limited by whether the organization can reconstruct the expected remote-access trust sequence. Environments that rely only on VPN tunnel-established events, source IP novelty, vulnerable version posture, or isolated failed authentication events will not have enough evidence for high-confidence detection.

Primary Limitations

·        Missing GlobalProtect portal logs reduce the ability to prove whether portal authentication or client configuration retrieval occurred before gateway access.

·        Missing GlobalProtect gateway logs reduce the ability to validate gateway authentication, gateway assignment, tunnel establishment, reconnect behavior, and session-state transitions.

·        Missing identity-provider telemetry prevents reliable validation of whether the VPN session followed expected identity authentication.

·        Missing MFA or conditional-access telemetry prevents reliable validation of whether the VPN session satisfied expected access-control decisions.

·        Missing SAML, OIDC, certificate, HIP, or device-posture telemetry weakens the ability to distinguish legitimate session establishment from authentication-lineage failure.

·        Missing session identifiers, tunnel identifiers, SAML identifiers, device identifiers, or consistent usernames can break correlation across GlobalProtect, identity-provider, MFA, endpoint, cloud, SaaS, and SIEM telemetry.

·        Missing internal network telemetry can prevent defenders from determining whether a suspicious VPN session reached identity services, privileged resources, sensitive applications, or lateral-movement paths.

·        Missing cloud, SaaS, source-code, CI/CD, or developer-platform telemetry can obscure downstream exposure after suspicious VPN access.

·        Poor timestamp normalization can break sequence logic between portal activity, identity-provider authentication, MFA decisions, gateway authentication, tunnel establishment, and post-session internal access.

·        Split-tunnel configurations, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, residential proxy infrastructure, and third-party access paths can reduce source-attribution confidence.

Detection Boundary

·        A vulnerable GlobalProtect version is an exposure signal, not proof of active exploitation.

·        A failed authentication event is not proof of authentication bypass.

·        A suspicious source IP, ASN, geography, user-agent, client version, or device profile is not compromise evidence by itself.

·        A tunnel-established event is not malicious by itself unless authentication-lineage, gateway-sequencing, posture, source, or downstream behavior supports escalation.

·        Missing identity-provider, MFA, SAML, HIP, certificate, or device-posture evidence may reflect telemetry delay, ingestion failure, log-retention limits, parser failure, provider outage, timestamp skew, or integration gaps.

·        Internal discovery is not automatically GlobalProtect compromise unless it is temporally and behaviorally linked to suspicious VPN session establishment, missing authentication-lineage evidence, or unauthorized trusted-session use.

·        Cloud, SaaS, identity, and developer-platform anomalies should remain downstream investigative leads unless linked to suspicious VPN session evidence, trusted-session abuse, credential theft, token theft, or validated post-session activity.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized. A GlobalProtect session may be analytically suspicious but unsuitable for high-confidence alerting if the organization cannot prove the authentication lineage, session linkage, and downstream activity within bounded and locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making GlobalProtect remote-access trust measurable, enforceable, and recoverable after suspicious session activity. The objective is not only to patch exposed portals and gateways, but to prove that VPN sessions follow the expected identity, MFA, posture, gateway, and tunnel sequence.

GlobalProtect Exposure and Patch Governance

·        Maintain a complete inventory of internet-facing GlobalProtect portals, gateways, gateway clusters, exposed interfaces, gateway regions, affected PAN-OS versions, and compensating controls.

·        Validate patch posture for GlobalProtect portals and gateways on a defined schedule and during active exploitation windows.

·        Prioritize remediation for exposed portals and gateways supporting privileged users, third-party users, remote administrators, cloud administrators, developer access, source-code access, CI/CD access, or backup administration.

·        Treat unknown patch posture, unmanaged exposed gateways, or incomplete gateway inventories as remote-access trust risks.

Authentication-Lineage Enforcement

·        Require strong authentication sequencing across GlobalProtect portal access, identity-provider authentication, MFA or conditional access, SAML assertion validation, certificate validation, HIP evaluation, gateway assignment, gateway authentication, and tunnel establishment.

·        Monitor for tunnel establishment without expected identity-provider, MFA, SAML, certificate, HIP, posture, gateway-assignment, authentication-cookie, or session-token evidence.

·        Validate that GlobalProtect, identity-provider, MFA, certificate, HIP, and SIEM telemetry can be joined reliably using user, device, source IP, session, assertion, gateway, and timestamp context.

·        Treat unexplained authentication-lineage gaps as trust-impacting events requiring investigation before the session is considered legitimate.

Privileged and Third-Party VPN Access Governance

·        Apply stricter access controls to privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, and low-frequency VPN accounts.

·        Require MFA, conditional access, device posture, certificate validation, and limited gateway assignment for high-risk VPN users.

·        Review third-party and contractor VPN access for least privilege, expiration, business justification, source restrictions, and monitored access windows.

·        Disable or restrict dormant, stale, recently re-enabled, and low-frequency VPN accounts that lack current business justification.

HIP, Certificate, Device-Posture, and Gateway Controls

·        Define expected HIP profiles, certificate requirements, client versions, operating-system profiles, managed-device states, gateway assignments, and gateway-routing patterns by user group and endpoint class.

·        Monitor for missing, downgraded, newly observed, or inconsistent HIP results, certificate context, endpoint identity, client version, operating-system profile, or device-posture values.

·        Validate gateway-assignment logic, regional gateway selection, split-tunnel configuration, failover behavior, SASE routing, and ZTNA overlays against expected remote-access architecture.

·        Treat unexpected gateway assignment or posture mismatch as a confidence amplifier when paired with authentication-lineage gaps or suspicious downstream activity.

Session Revocation and Remote-Access Trust Restoration

·        Create response procedures for suspicious GlobalProtect session revocation, credential reset, token review, certificate review, MFA review, conditional-access validation, and HIP-policy validation.

·        Require rapid scoping of all sessions tied to affected users, devices, source infrastructure, gateways, identity-provider sessions, SAML assertions, authentication cookies, or session tokens.

·        Validate whether suspicious VPN sessions reached identity infrastructure, privileged resources, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, or backup infrastructure.

·        Require remote-access trust restoration before returning affected VPN users, gateways, accounts, or devices to normal operation.

SOC and Incident Response Hardening

·        Treat suspicious trusted VPN sessions as trust-impacting events rather than routine remote-access anomalies.

·        Add playbook steps for validating portal-to-gateway sequencing, identity-provider evidence, MFA evidence, SAML context, certificate context, HIP result, device posture, gateway assignment, tunnel establishment, and downstream internal access.

·        Require responders to determine whether suspicious VPN access was followed by internal reconnaissance, identity-service interaction, privileged resource access, cloud or SaaS control-plane activity, developer-platform access, source-code access, CI/CD interaction, credential validation, token access, or lateral movement.

·        Use change-control records, vendor-support records, travel records, SASE routing changes, gateway maintenance, identity-provider maintenance, VPN client upgrade records, security-testing records, and incident-response records as triage evidence.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat GlobalProtect authentication lineage as a monitored trust layer rather than an assumed condition. The architecture must connect remote-access infrastructure, identity-provider evidence, MFA decisions, posture validation, session state, endpoint context, internal network activity, and downstream cloud or SaaS activity into a single validation model.

Architecture Layer 1: GlobalProtect Exposure and Remote-Access Inventory

GlobalProtect exposure and inventory telemetry establishes what remote-access infrastructure exists and whether it is hardened. This layer captures internet-facing portals, gateways, gateway clusters, exposed interfaces, PAN-OS version posture, patch status, compensating controls, gateway assignments, split-tunnel configuration, and remote-access policy.

Architecture Layer 2: Authentication-Lineage Validation

Authentication-lineage validation proves whether the session followed the expected trust sequence. This layer joins portal request, portal authentication, identity-provider authentication, MFA or conditional-access decision, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, client configuration retrieval, tunnel establishment, and session state.

Architecture Layer 3: Device, Posture, and Certificate Assurance

Device and posture assurance validates whether the claimed endpoint should have been trusted. This layer captures HIP match results, HIP report results, certificate context, endpoint identity, managed-device state, GlobalProtect client version, operating-system profile, device posture, authentication-cookie context, and session-token context.

Architecture Layer 4: User, Account, and Source Context

User, account, and source context determines whether the session aligns with expected behavior. This layer includes privileged-user status, third-party access status, contractor status, stale or dormant account status, low-frequency VPN behavior, user baseline, device baseline, source IP, ASN, geography, network type, SASE path, NAT context, and approved remote-access patterns.

Architecture Layer 5: Post-Session Internal and Control-Plane Monitoring

Post-session monitoring determines whether the trusted VPN path was used for follow-on activity. This layer captures DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, cloud-console, SaaS-administration, developer-platform, source-code, CI/CD, and backup-system access after VPN establishment.

Architecture Layer 6: SOC Correlation and Trust-Restoration Workflow

SOC correlation joins suspicious VPN session establishment with authentication-lineage evidence and post-session activity. Response workflow requires session revocation, credential reset decisioning, MFA and identity-provider validation, certificate and HIP validation, gateway review, privileged account review, downstream access scoping, and remote-access trust restoration.

Architecture Outcome

The architecture should enable the organization to answer five questions during an incident:

·        Did the VPN session follow the expected authentication lineage?

·        Did the session involve a trusted user, trusted device, expected gateway, and expected posture context?

·        Was any lineage gap explained by approved change, telemetry delay, provider outage, routing behavior, or maintenance?

·        Did the session reach internal identity, privileged, cloud, SaaS, developer, source-code, CI/CD, or backup resources?

·        Can remote-access trust be restored with confidence before the user, device, gateway, or account returns to normal operation?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        GlobalProtect portal and gateway patch governance.

·        Internet-facing remote-access asset inventory.

·        Strong MFA and conditional-access enforcement.

·        Certificate-based access enforcement where appropriate.

·        HIP and device-posture enforcement.

·        Gateway-assignment governance.

·        Split-tunnel and remote-access policy governance.

·        Least-privilege VPN access.

·        Privileged VPN account restrictions.

·        Third-party and contractor access expiration.

·        Dormant and stale VPN account disablement.

·        Source restrictions for high-risk access where operationally feasible.

·        Strong authentication for VPN and firewall administration.

·        Change-control governance for GlobalProtect configuration.

Detective Controls

·        GlobalProtect portal and gateway authentication monitoring.

·        Portal-to-gateway sequencing correlation.

·        Tunnel-established event monitoring.

·        Identity-provider and MFA correlation.

·        SAML, certificate, HIP, and device-posture validation.

·        Authentication-cookie and session-token inconsistency monitoring where available.

·        Gateway-assignment anomaly detection.

·        Source novelty and source-risk enrichment.

·        Privileged and third-party VPN account monitoring.

·        VPN-authenticated internal access monitoring.

·        Identity-service and privileged-resource access monitoring.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup access correlation after suspicious VPN establishment.

·        Multi-stage correlation across VPN-edge, identity, endpoint, network, cloud, SaaS, and SIEM telemetry.

Responsive Controls

·        Suspicious VPN session revocation.

·        Credential reset and credential-risk review.

·        MFA session review and reauthentication enforcement.

·        Identity-provider session review.

·        Certificate review and certificate revocation where needed.

·        HIP and device-posture validation.

·        Gateway-assignment review.

·        Firewall and VPN configuration validation.

·        Privileged and third-party account scoping.

·        Endpoint triage for VPN-connected systems.

·        Internal access scoping.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup exposure review.

·        Remote-access trust restoration before return to normal operation.

·        Incident playbooks for trusted VPN session compromise.

Governance Controls

·        Known-good GlobalProtect authentication-lineage model.

·        Approved remote-access architecture documentation.

·        Approved GlobalProtect portal and gateway inventory.

·        Approved privileged VPN user inventory.

·        Approved third-party and contractor access inventory.

·        Approved source and geography baselines where feasible.

·        Approved device, certificate, HIP, and posture baselines.

·        Gateway-assignment and routing documentation.

·        SASE, ZTNA, proxy, NAT, and split-tunnel documentation.

·        Change-control records for GlobalProtect, identity-provider, MFA, HIP, certificate, and routing changes.

·        Executive reporting for high-risk remote-access trust failures.

·        Risk-register tracking for GlobalProtect trusted-session compromise exposure.

Control Mapping Summary

The strongest control posture combines prevention of unauthorized or weakly validated VPN access, detection of authentication-lineage failure, and response workflows that restore remote-access trust. Controls should be prioritized for internet-facing GlobalProtect portals and gateways, privileged VPN users, third-party access, remote administrators, identity infrastructure, cloud and SaaS administration, source-code systems, CI/CD environments, and backup infrastructure.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

GlobalProtect authentication-lineage bypass and trusted VPN session compromise are well-defined behavior classes, but organization-specific maturity depends on whether remote-access telemetry can be correlated with identity-provider, MFA, SAML, certificate, HIP, device-posture, session-state, and downstream access evidence. Many environments can observe VPN session establishment, but fewer can reconstruct full authentication lineage and distinguish malicious trusted-session abuse from legitimate remote work, travel, vendor access, SASE routing, gateway failover, administrator workflows, or incident-response activity.

Strengths

·        The behavior pattern is durable because it focuses on trusted VPN session misuse rather than one CVE, exploit string, request path, source IP, user-agent, or proof-of-concept pattern.

·        The core sequence is analytically clear: exposed remote-access path or valid access, authentication-lineage failure, trusted VPN session establishment, downstream internal access, and potential expansion.

·        Detection opportunities are strong where GlobalProtect, PAN-OS, identity-provider, MFA, HIP, endpoint, network, cloud, SaaS, and SIEM telemetry can be correlated.

·        Defensive controls can be mapped directly to GlobalProtect hardening, authentication-lineage validation, privileged VPN governance, device-posture enforcement, telemetry validation, and incident-response workflows.

·        S17 TTP coverage can remain lean while still capturing the core operational chain.

Maturity Gaps

·        GlobalProtect portal, gateway, HIP, gateway-assignment, client configuration retrieval, tunnel-established, authentication-cookie, and session-token telemetry may not be retained with enough detail for full lineage reconstruction.

·        Identity-provider, MFA, SAML, OIDC, conditional-access, certificate, and device-compliance logs may not join cleanly to GlobalProtect events.

·        Split-tunnel configurations, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, mobile networks, and third-party access paths may reduce source-attribution confidence.

·        Session identifiers, usernames, device identifiers, SAML identifiers, gateway names, source IPs, and timestamps may not align across telemetry sources.

·        Internal network telemetry may not capture enough VPN-authenticated traffic to scope downstream access.

·        Cloud, SaaS, source-code, CI/CD, developer-platform, and backup logs may not be linked to the suspicious VPN session with enough confidence.

·        Organizations may over-rely on tunnel-established events or source-IP anomalies rather than validating the full authentication lineage.

Maturity Improvement Priorities

·        Normalize GlobalProtect portal, gateway, tunnel, HIP, gateway-assignment, authentication-cookie, and session-token telemetry.

·        Improve identity-provider, MFA, SAML, OIDC, conditional-access, certificate, and device-posture correlation with GlobalProtect sessions.

·        Define known-good authentication-lineage sequences for GlobalProtect access by user class, device class, gateway, region, and authentication method.

·        Improve privileged VPN user, third-party access, dormant account, stale account, low-frequency user, and remote-administrator baselines.

·        Improve internal network visibility for VPN-authenticated DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, privileged-management, and administrative-protocol traffic.

·        Improve downstream correlation with cloud, SaaS, identity, developer-platform, source-code, CI/CD, and backup activity.

·        Add trusted VPN session compromise validation steps to SOC and incident-response playbooks.

Maturity Outlook

Maturity can improve quickly if the organization prioritizes authentication-lineage reconstruction and session-to-downstream correlation. The highest-value improvements are GlobalProtect portal and gateway telemetry normalization, identity-provider and MFA joins, HIP and device-posture visibility, session identifier reliability, privileged VPN account baselines, internal network visibility, and downstream cloud/SaaS/developer-platform correlation.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can obtain or abuse trusted GlobalProtect access without detection and reduce the response burden when authentication-lineage evidence does not reconcile. The objective is measurable remote-access trust, not GlobalProtect deployment alone.

Priority 1: Establish Authentication-Lineage Assurance as a Security Metric

·        Define measurable GlobalProtect authentication-lineage metrics for portal authentication, identity-provider authentication, MFA decision, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, tunnel establishment, and internal access.

·        Track authentication-lineage completeness for privileged users, third-party users, remote administrators, high-risk user groups, and sensitive gateway paths.

·        Report unresolved authentication-lineage gaps as remote-access trust risks.

·        Treat unexplained lineage gaps on privileged or third-party sessions as executive-relevant control failures.

Priority 2: Harden Internet-Facing GlobalProtect Exposure

·        Maintain a live inventory of internet-facing portals, gateways, gateway clusters, exposed interfaces, PAN-OS versions, patch posture, and compensating controls.

·        Prioritize exposed GlobalProtect remediation based on privileged access, third-party access, downstream access, cloud/SaaS dependency, and backup-system exposure.

·        Validate exposed gateway posture during active exploitation windows and after emergency changes.

·        Reduce unmanaged or unknown GlobalProtect exposure.

Priority 3: Strengthen Privileged and Third-Party VPN Governance

·        Reduce standing VPN access for privileged, administrative, third-party, contractor, dormant, stale, recently re-enabled, service-adjacent, and low-frequency accounts.

·        Enforce stricter MFA, conditional access, certificate validation, HIP posture, device compliance, and session monitoring for high-risk VPN users.

·        Require expiration, justification, source restrictions where feasible, and access-window governance for third-party VPN access.

·        Review privileged VPN access paths to identity infrastructure, management systems, cloud consoles, SaaS administration, source-code systems, CI/CD platforms, and backup infrastructure.

Priority 4: Improve Session-to-Internal-Access Visibility

·        Improve telemetry that links VPN sessions to internal DNS, LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, jump-host, privileged-management, and administrative-protocol activity.

·        Baseline normal internal access by VPN user, device, gateway, role, business unit, and remote-access profile.

·        Prioritize detection for VPN sessions that reach identity infrastructure, domain controllers, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, or sensitive business applications.

·        Validate split-tunnel, SASE, ZTNA, proxy, NAT, carrier-grade NAT, mobile network, and third-party access effects on visibility and attribution.

Priority 5: Improve Cloud, SaaS, Developer-Platform, and Backup Correlation

·        Correlate suspicious VPN sessions with cloud consoles, cloud APIs, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD environments, privileged business applications, and backup infrastructure.

·        Monitor privileged cloud and SaaS actions after suspicious VPN establishment, including role changes, access-key creation, API token creation, application consent changes, repository access, CI/CD workflow changes, secret access, and data export.

·        Treat downstream cloud, SaaS, developer, source-code, CI/CD, and backup activity as investigative leads unless linked to suspicious VPN session evidence.

·        Build incident-response workflows that scope remote-access trust impact across internal and cloud-connected systems.

Priority 6: Strengthen SOC Response to Remote-Access Trust Failure

·        Create or update playbooks for GlobalProtect authentication-lineage failure and trusted VPN session compromise.

·        Require responders to validate portal-to-gateway sequencing, identity-provider evidence, MFA evidence, SAML context, certificate context, HIP result, device posture, gateway assignment, tunnel establishment, and downstream activity.

·        Require rapid session revocation, credential-risk review, MFA review, certificate review, HIP validation, gateway review, and privileged-account scoping when suspicious trusted-session activity is confirmed.

·        Require remote-access trust restoration before affected users, devices, accounts, or gateways return to normal operation.

Strategic Outcome

The organization should be able to prove that GlobalProtect VPN sessions follow the expected authentication lineage, detect when trusted-session evidence does not reconcile, scope downstream access with confidence, and restore remote-access trust before attackers convert a suspicious VPN session into broader enterprise compromise.

S38 — Attack Economics & Organizational Impact Model

GlobalProtect authentication-lineage bypass and trusted VPN session compromise change the economics of intrusion by allowing adversaries to pursue trusted remote access instead of defeating every downstream control directly. When a VPN session appears legitimate but the expected authentication, MFA, posture, gateway, or session evidence does not reconcile, the attacker can increase access value while forcing defenders to validate whether the remote-access trust path remained intact.

Adversary Economic Advantage

·        Trusted VPN access can reduce attacker friction by placing activity behind an access channel that internal systems may already treat as authorized.

·        Authentication-lineage gaps can allow attackers to exploit uncertainty between GlobalProtect portal activity, gateway authentication, identity-provider evidence, MFA decisions, SAML context, HIP posture, certificate validation, and tunnel establishment.

·        Valid-account abuse, stolen or replayed session material, authentication-cookie misuse, session-token misuse, or posture inconsistency can reduce the need for noisy exploitation after initial access.

·        Suspicious VPN activity can blend with legitimate remote work, travel, mobile carrier use, SASE routing, ZTNA overlays, vendor access, third-party support, administrator workflows, or helpdesk activity.

·        A successful trusted-session compromise shifts attacker effort from broad exploitation to targeted abuse of remote-access trust, downstream identity access, privileged resources, cloud consoles, SaaS administration, developer platforms, source-code systems, CI/CD environments, or backup infrastructure.

·        The attacker benefits when defenders cannot quickly determine whether a session was legitimately established, whether the account was trusted, whether the device posture was valid, or whether downstream access was authorized.

Defender Cost Expansion

·        The organization must investigate both the suspicious VPN activity and the integrity of the remote-access controls used to validate that activity.

·        Response teams may need to reconstruct GlobalProtect portal activity, gateway activity, identity-provider authentication, MFA decisions, SAML context, certificate validation, HIP posture, gateway assignment, tunnel establishment, session-token state, and authentication-cookie state.

·        Session revocation, credential resets, MFA review, conditional-access review, certificate review, HIP-policy review, gateway review, and privileged-account scoping may be required even when ransomware, confirmed data theft, or full enterprise compromise is not proven.

·        Internal access scoping may be required across identity services, domain controllers, jump hosts, privileged management systems, endpoint-management systems, file shares, databases, cloud consoles, SaaS administration portals, source-code systems, CI/CD platforms, and backup systems.

·        Response cost increases when split tunneling, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, mobile networks, proxy paths, or third-party access paths reduce source attribution and session-linkage confidence.

·        High-value VPN users create disproportionate exposure because a single suspicious trusted session involving privileged, administrative, security, third-party, contractor, service-adjacent, dormant, stale, recently re-enabled, or low-frequency accounts can expand scoping requirements quickly.

Organizational Impact Model

Remote-Access Trust Impact

The organization must determine whether the VPN session followed the expected authentication lineage and whether the session should have been trusted.

Identity and Access-Control Impact

The organization must determine whether identity-provider authentication, MFA, conditional-access, SAML, certificate, HIP, device-posture, gateway-assignment, authentication-cookie, and session-token evidence remained complete and trustworthy.

Internal Access Impact

The organization must determine whether the suspicious VPN session reached internal identity services, privileged resources, administrative interfaces, file shares, databases, jump hosts, endpoint-management platforms, or sensitive applications.

Control-Plane Impact

The organization must determine whether the suspicious VPN path enabled cloud console access, SaaS administration, identity administration, developer-platform access, source-code access, CI/CD interaction, privileged business application access, or backup-system exposure.

Recovery Impact

The organization must restore remote-access trust through session revocation, credential review, MFA validation, certificate review, HIP validation, gateway review, configuration validation, telemetry review, account scoping, and downstream exposure assessment.

Governance Impact

Leadership may need to treat confirmed trusted VPN session compromise as an executive incident because the affected control path governs access to internal systems, identity resources, cloud and SaaS platforms, developer environments, backup infrastructure, and business-critical systems.

Economic Impact Summary

GlobalProtect authentication-lineage bypass is economically powerful for adversaries because it can convert an internet-facing remote-access path into a trusted internal access channel. The organization’s financial exposure grows when it cannot quickly prove who authenticated, what device was trusted, which gateway was used, whether MFA and posture checks occurred, what internal systems were reached, and whether downstream cloud, SaaS, developer-platform, or backup activity was related to the suspicious VPN session.

S39 — Economic Impact & Organizational Exposure

Figure 7

GlobalProtect authentication-lineage bypass and trusted VPN session compromise create organizational exposure by increasing uncertainty around remote-access trust, identity integrity, downstream access, and response scope. Exposure rises when suspicious VPN sessions involve privileged users, third-party accounts, incomplete authentication-lineage evidence, high-value internal systems, cloud or SaaS control planes, developer platforms, source-code systems, CI/CD environments, or backup infrastructure.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether the activity remains an attempted or isolated GlobalProtect event, becomes a confirmed or strongly suspected trusted-session compromise, or expands into privileged internal access, identity infrastructure, cloud/SaaS administration, developer-platform exposure, backup access, ransomware staging, extortion, or broad remote-access trust restoration.

Low Impact Scenario

Estimated $750K – $3M.

This scenario applies when suspicious GlobalProtect activity is detected quickly, no unauthorized tunnel establishment is confirmed, no privileged or third-party VPN account is abused, no internal reconnaissance occurs, no cloud or SaaS control-plane activity is linked, no credential or token exposure is identified, and telemetry is sufficient to validate the session path quickly.

Moderate Impact Scenario

Estimated $5M – $18M.

This scenario applies when confirmed or strongly suspected trusted VPN session compromise requires session revocation, credential resets, MFA and conditional-access validation, identity-provider review, SAML and certificate review, HIP and device-posture validation, GlobalProtect portal and gateway review, privileged and third-party account scoping, endpoint triage, SOC surge activity, internal access reconstruction, and downstream validation of cloud, SaaS, developer-platform, source-code, CI/CD, or backup exposure.

High Impact Scenario

Estimated $25M – $100M+.

This scenario applies when trusted VPN access becomes an enterprise-impact pathway involving privileged internal access, identity-service interaction, domain-controller exposure, credential validation, lateral movement, cloud or SaaS control-plane activity, source-code or CI/CD exposure, backup-system access, data access, ransomware staging, extortion, or broad loss of confidence in remote-access and identity controls. The upper range applies only when the trusted VPN path forces enterprise-scale restoration of GlobalProtect access, identity controls, privileged accounts, endpoint evidence, internal access paths, cloud and SaaS sessions, backup trust, or business-critical systems reached through the suspicious VPN path.

Annualized Risk Exposure

Estimated $5M – $20M+ for materially exposed enterprise environments with internet-facing GlobalProtect dependency, privileged or third-party VPN use, and meaningful downstream identity, cloud, SaaS, developer-platform, source-code, CI/CD, or backup exposure. Exposure may exceed $25M where trusted VPN access is tied to privileged identity paths, cloud or SaaS administration, source-code systems, CI/CD environments, backup infrastructure, ransomware or extortion impact, incomplete telemetry, or broad remote-access trust restoration.

Operational Dependency

Operational dependency is high where GlobalProtect provides primary remote access for employees, administrators, security teams, developers, third parties, contractors, or operational support teams. Dependency increases when VPN access is required for identity infrastructure, privileged management systems, source-code repositories, CI/CD platforms, backup systems, sensitive applications, cloud administration, SaaS administration, or business-critical environments.

Control Trust

Control trust is reduced when the organization cannot prove that GlobalProtect portal authentication, identity-provider authentication, MFA decision, SAML assertion context, certificate validation, HIP evaluation, gateway assignment, gateway authentication, tunnel establishment, and internal access occurred in the expected sequence. Control trust is further reduced when authentication-cookie state, session-token state, client configuration retrieval, device posture, or gateway-selection evidence is incomplete or inconsistent.

Visibility Confidence

Visibility confidence is highest when GlobalProtect, PAN-OS, identity-provider, MFA, SAML, HIP, endpoint, network, cloud, SaaS, developer-platform, source-code, CI/CD, and SIEM telemetry can be joined reliably. Visibility confidence is reduced where split tunneling, SASE routing, ZTNA overlays, proxy paths, NAT, carrier-grade NAT, mobile networks, third-party access paths, inconsistent identifiers, or timestamp skew prevent reliable session reconstruction.

Change-Control Confidence

Change-control confidence is high when GlobalProtect configuration changes, gateway maintenance, authentication-policy updates, MFA changes, HIP-policy changes, certificate rotations, SASE routing changes, VPN client upgrades, vendor support, helpdesk activity, security testing, and incident-response actions are documented and attributable. Confidence is reduced when change-control records are incomplete, delayed, inconsistent, or unavailable during suspicious session review.

Downstream Dependency

Downstream dependency is high when VPN access reaches identity infrastructure, domain controllers, jump hosts, privileged management systems, firewall management interfaces, VPN administration interfaces, endpoint-management systems, file shares, databases, cloud consoles, SaaS administration portals, developer platforms, source-code repositories, CI/CD systems, backup infrastructure, or sensitive business applications. These dependencies increase the impact of even a single suspicious trusted VPN session.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious VPN access may have reached regulated data, customer systems, privileged business applications, source-code repositories, CI/CD environments, backup infrastructure, cloud administration, SaaS administration, or identity control planes. Exposure also increases when incomplete telemetry prevents timely confirmation of whether sensitive systems were accessed, whether data was exposed, or whether downstream compromise occurred.

Residual Economic Risk

Residual economic risk remains after containment if the organization cannot prove that suspicious sessions were revoked, affected credentials were reset or validated, certificates and tokens were reviewed, MFA and conditional-access evidence reconciled, HIP and device-posture evidence was trustworthy, downstream access was scoped, and remote-access trust was restored. Residual risk is highest where session identifiers, identity evidence, device evidence, cloud logs, SaaS logs, internal network telemetry, or endpoint telemetry are incomplete.

Proof-of-Concept Behavioral Coverage Assessment

This assessment is anchored to CVE-2026-0257, but the detection model is intentionally behavior-led so it can demonstrate reusable coverage across related GlobalProtect and PAN-OS remote-access trust failures. The coverage model is designed to show how the same detection strategy can remain relevant when different exploit mechanisms produce the same operational outcomes.

The model should not be read as universal exploit detection or universal zero-day prevention. It demonstrates coverage when a known CVE, new proof-of-concept, or future zero-day produces observable authentication-lineage gaps, portal-to-gateway sequencing anomalies, SAML or certificate inconsistency, session fixation or impersonation behavior, unauthorized VPN session establishment, suspicious trusted-session use, or downstream internal, cloud, SaaS, developer-platform, source-code, CI/CD, or backup activity.

CVE / Proof-of-Concept Behavioral Coverage Scope

This assessment is anchored to CVE-2026-0257, a GlobalProtect portal and gateway authentication-bypass exposure that can allow unauthorized VPN connection establishment. The same detection model is also applicable to related GlobalProtect and PAN-OS trust failures where the exploit or abuse path affects SAML validation, certificate validation, user impersonation, session fixation, authentication-control integrity, management-plane trust, or downstream access through a trusted remote-access path.

Detection Engineering Coverage Interpretation

Coverage is strongest when proof-of-concept or exploit activity results in observable GlobalProtect portal or gateway anomalies, portal-to-gateway sequencing gaps, tunnel establishment without expected authentication-lineage evidence, suspicious source context, high-risk account use, HIP or certificate inconsistency, SAML or session inconsistency, impersonation behavior, or downstream internal activity. Coverage is weaker when exploit activity produces fully consistent authentication-lineage artifacts, uses valid accounts within normal baselines, or leaves no observable difference in GlobalProtect, identity, MFA, HIP, endpoint, network, cloud, or SaaS telemetry.

Direct Coverage

Direct behavioral coverage applies to the following CVEs when exploitation or abuse produces observable GlobalProtect authentication-lineage gaps, SAML or certificate inconsistency, session impersonation, unauthorized or suspicious VPN establishment, trusted-session misuse, or downstream access through the VPN path:

·        CVE-2026-0257 — GlobalProtect portal and gateway authentication bypass that can allow unauthorized VPN connection establishment.

·        CVE-2020-2021 — PAN-OS SAML authentication bypass affecting resources protected by SAML SSO, including GlobalProtect Gateway and GlobalProtect Portal.

·        CVE-2020-2050 — GlobalProtect client certificate verification authentication bypass allowing invalid certificate checks to be bypassed.

·        CVE-2024-5918 — GlobalProtect improper certificate validation enabling an authorized user with a crafted certificate to connect as another legitimate user.

·        CVE-2024-3388 — GlobalProtect Gateway user impersonation enabling an authenticated attacker to impersonate another user and send packets to internal assets.

·        CVE-2024-8691 — GlobalProtect Portal user impersonation enabling a malicious authenticated GlobalProtect user to impersonate another GlobalProtect user.

·        CVE-2025-0126 — GlobalProtect SAML login session fixation enabling impersonation of a legitimate authorized GlobalProtect user.

Coverage With Adaptation

Coverage with adaptation applies to related authentication-control or management-plane vulnerabilities where the local incident shows authentication-control bypass, credential or session abuse, management-plane access, configuration tampering, or downstream activity that can be linked to GlobalProtect trust, remote-access control integrity, or VPN-enabled exposure.

·        CVE-2026-0265 — PAN-OS authentication bypass when Cloud Authentication Service is enabled.

·        CVE-2025-0133 — GlobalProtect Gateway and Portal reflected XSS that may support credential, browser-session, or trusted-domain abuse paths.

·        CVE-2024-0012 — PAN-OS management web interface authentication bypass that may support management-plane access, configuration tampering, or chained activity affecting remote-access control integrity.

Limited / Non-Direct Coverage

Limited or non-direct coverage applies where the CVE produces availability or instability signals but does not, by itself, prove authentication-lineage bypass or trusted VPN session compromise.

·        CVE-2026-0227 — GlobalProtect Gateway and Portal denial-of-service or service-instability behavior. This can support exploit-attempt or instability triage when paired with GlobalProtect portal or gateway anomalies, but it should not be counted as direct trusted-session compromise coverage.

Direct Coverage Conditions

Direct coverage applies when proof-of-concept or exploit activity produces one or more of the following behaviors:

·        Abnormal GlobalProtect portal or gateway interaction before VPN session establishment.

·        Portal-to-gateway sequencing gaps.

·        Tunnel-established events without expected identity-provider, MFA, SAML, certificate, HIP, device-posture, authentication-cookie, session-token, or gateway-assignment evidence.

·        SAML validation inconsistency, certificate validation inconsistency, session fixation, user impersonation, or authentication-cookie/session-token inconsistency.

·        Suspicious VPN session establishment involving privileged, third-party, dormant, stale, recently re-enabled, service-adjacent, or low-frequency accounts.

·        VPN session establishment from unfamiliar infrastructure, rare ASNs, unusual geographies, hosting providers, anonymization services, mobile carrier networks, residential proxy infrastructure, SASE egress points, or source networks inconsistent with the user’s access history.

·        Suspicious VPN session establishment followed by internal reconnaissance, identity-service access, privileged resource access, administrative protocol use, cloud or SaaS control-plane access, developer-platform access, source-code access, CI/CD interaction, backup-system access, credential validation, or lateral movement.

Coverage With Adaptation Conditions

Coverage with adaptation applies when activity uses a novel exploit mechanism, altered request path, different user-agent, new source infrastructure, replayed authentication material, abused certificates, alternate session-token behavior, authentication-cookie misuse, low-noise session establishment, management-plane access, configuration tampering, or credential/session abuse but still creates lineage, session, posture, source, account, control-plane, or downstream anomalies. Adaptation may require local tuning for field names, session identifiers, timing windows, identity-provider joins, MFA joins, HIP logs, certificate fields, gateway-assignment logic, management-plane telemetry, split-tunnel behavior, cloud/SaaS linkage, and exception lists.

Non-Coverage Conditions

Non-coverage applies when activity does not create observable session or downstream differences in available telemetry. This includes scenarios where:

·        The attacker uses valid credentials and a trusted device from expected infrastructure with complete authentication-lineage evidence.

·        The exploit creates a VPN session that appears fully valid across GlobalProtect, identity-provider, MFA, SAML, HIP, certificate, gateway, and tunnel telemetry.

·        The activity affects only availability or service stability without authentication-lineage, session, account, posture, or downstream access impact.

·        Required GlobalProtect, identity, MFA, HIP, endpoint, internal network, cloud, SaaS, or SIEM telemetry is unavailable.

·        Session identifiers, timestamps, user identifiers, device identifiers, gateway names, or source IPs cannot be joined reliably.

·        Split-tunnel, SASE routing, ZTNA overlays, NAT, carrier-grade NAT, proxy paths, mobile networks, or third-party access paths prevent reliable attribution.

·        Downstream cloud, SaaS, developer-platform, source-code, CI/CD, or backup activity cannot be linked to the suspicious VPN session.

·        Activity remains limited to scanning, probing, or denial-of-service behavior without session establishment or downstream behavior.

Current Coverage Count

Current behavior-led coverage directly supports 7 CVEs where the documented behavior aligns with GlobalProtect authentication bypass, SAML bypass, certificate validation failure, session fixation, user impersonation, or trusted-session misuse. The model also supports 3 additional CVEs with adaptation where the activity can be linked to remote-access trust, authentication-control integrity, session abuse, management-plane impact, or downstream access. One related GlobalProtect availability issue is treated as limited or non-direct coverage because it supports exploit-attempt or instability triage rather than trusted-session compromise.

Coverage Qualification

Coverage is strong for behaviorally visible trusted-session compromise and weaker for silent valid-session abuse where all required authentication-lineage evidence appears normal. The report should not claim universal exploit detection, universal CVE coverage, or standalone attribution. Detection confidence depends on telemetry completeness, field mapping, local baselines, session linkage, identity-provider correlation, MFA correlation, HIP visibility, source enrichment, internal network visibility, cloud/SaaS logging, endpoint telemetry, false-positive testing, and SOC triage readiness.

Zero-Day Coverage Interpretation

The purpose of this S39 coverage model is to show that the detection strategy is not limited to the known exploit mechanics of CVE-2026-0257. Future zero-day or proof-of-concept activity affecting GlobalProtect or adjacent PAN-OS remote-access trust paths should still be detectable when it produces the same operational behaviors: missing or inconsistent authentication lineage, portal-to-gateway sequencing failure, SAML or certificate mismatch, session fixation or impersonation, unauthorized VPN session establishment, suspicious source or account context, downstream internal access, or remote-access trust restoration requirements. The model should not be presented as universal zero-day prevention; it is behavior-led coverage for zero-day activity that becomes visible through the trusted-session chain.

Executive Exposure Statement

The organization’s economic exposure is highest when GlobalProtect trusted-session compromise creates uncertainty around who authenticated, what device was trusted, what gateway was used, whether MFA and posture controls were enforced, what internal systems were reached, and whether downstream cloud, SaaS, developer, source-code, CI/CD, or backup activity was related. The strategic risk is not only unauthorized VPN access; it is the possibility that the remote-access trust layer failed during the period when the organization depended on it to protect internal access.

S40 — References

Vendor / Platform Documentation

·        Palo Alto Networks Security Advisory — CVE-2026-0257 PAN-OS: GlobalProtect Authentication Bypass Vulnerabilities — hxxps://security[.]paloaltonetworks[.]com/CVE-2026-0257

·        Palo Alto Networks Security Advisory — CVE-2026-0265 PAN-OS: Authentication Bypass with Cloud Authentication Service Enabled — hxxps://security[.]paloaltonetworks[.]com/CVE-2026-0265

·        Palo Alto Networks Security Advisory — CVE-2026-0227 PAN-OS: Firewall Denial of Service in GlobalProtect Gateway and Portal — hxxps://security[.]paloaltonetworks[.]com/CVE-2026-0227

·        Palo Alto Networks TechDocs — GlobalProtect Documentation — hxxps://docs[.]paloaltonetworks[.]com/globalprotect

·        Palo Alto Networks TechDocs — GlobalProtect User Authentication — hxxps://docs[.]paloaltonetworks[.]com/globalprotect/administration/globalprotect-user-authentication

·        Palo Alto Networks TechDocs — GlobalProtect for Internal HIP Checking and User-Based Access — hxxps://docs[.]paloaltonetworks[.]com/globalprotect/administration/globalprotect-quick-configs/globalprotect-for-internal-hip-checking-and-user-based-access

·        Palo Alto Networks Security Advisories — hxxps://security[.]paloaltonetworks[.]com/

Threat Technique Framework

·        MITRE ATT&CK — Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Security Vendor Analysis

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        NVD — CVE-2020-2021 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2020-2021

·        NVD — CVE-2020-2050 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2020-2050

·        NVD — CVE-2024-5918 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-5918

·        NVD — CVE-2024-3388 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-3388

·        NVD — CVE-2024-8691 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-8691

·        NVD — CVE-2025-0126 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-0126

·        NVD — CVE-2025-0133 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-0133

·        NVD — CVE-2024-0012 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-0012

Threat Tradecraft and Intrusion Patterns

·       The Hacker News — PAN-OS GlobalProtect Authentication Bypass Under Active Exploitation — hxxps://thehackernews[.]com/2026/05/pan-os-globalprotect-authentication[.]html