Hunting Ransomware Initial Access in Palo Alto GlobalProtect Logs

Introduction

A report flagged by CyberSecurityNews describes ransomware operators abusing a Palo Alto GlobalProtect flaw to slip quiet VPN access into enterprise networks — a familiar headline, but not the interesting part. What keeps my attention is everything that happens after the login. On most networks, a successful GlobalProtect authentication is the single most trusted event in the SIEM, and almost nobody hunts it. This post covers the log sources, artifacts, and pivots I would actually run to hunt that trust, not how to guess a CVE number.

What the Report Claims and What It Leaves Unnamed

Start with what the report establishes. Ransomware operators are exploiting a GlobalProtect flaw to get stealthy VPN access, and exposed remote-access infrastructure is functioning as an initial access vector. That claim fits a pattern the industry has watched play out repeatedly.

Now the gaps. The available source material does not name a CVE identifier, does not list affected PAN-OS versions, and does not identify a victim set or an exploitation timeline. I am not going to invent any of that. If you need the specifics before you take action, they have to come from the vendor advisory for the exact bug in question.

What is documented is the precedent. In April 2024, Palo Alto published an advisory for CVE-2024-3400, a command-injection vulnerability in the GlobalProtect feature of PAN-OS. It was exploited in the wild, added to CISA's Known Exploited Vulnerabilities catalog, and hotfixed across affected PAN-OS versions. That history matters for one reason: GlobalProtect's pre-authentication web surface has been attacked before, so a hunting playbook built around it keeps its value even when the current bug ID is unknown.

Why GlobalProtect Is a Ransomware Initial Access Target

GlobalProtect has two roles that people blur together. The portal handles configuration retrieval, client certificate negotiation, and pre-login endpoints. The gateway handles authentication and establishes the tunnel. Both expose HTTP(S) endpoints that must be reachable from the internet for the product to function at all — a hardened GlobalProtect deployment is still an internet-facing web application with a pre-auth attack surface bolted to it.

My position here has not changed in years: the specific flaw is not the interesting part. What matters is what a single successful pre-auth request buys an operator. No endpoint agent involved, no user interaction, no browser session to steal. If the request lands, the appliance — which by design sits on the trusted side of the firewall — becomes an authenticated internal position. That is a different risk class from a bug in a web app that only leaks a database row.

The misconfigurations that turn a bad day into a breach are boringly common:

• local authentication fallback left enabled alongside SSO, handing an attacker a second door
• MFA not enforced on gateway authentication specifically (people enforce it on the portal and assume it covers both)
• split tunnel disabled, so the tunnel routes every internal subnet rather than the minimum required
• the same interface serving portal and gateway, which widens the exposed surface for no business benefit

The Pre-Auth Surface Is the Whole Game

An unauthenticated client hitting a GlobalProtect portal can reach configuration retrieval endpoints, pre-login endpoints, and the HIP and client-certificate negotiation paths. You cannot blanket-block these — they are the product. What you can do is wrap them in telemetry: log every request, alert on abnormal volumes from a single source, and alert on requests that arrive with no matching client registration. I would rather carry noisy telemetry on the pre-auth surface than keep a clean log file and no visibility.

What a VPN Session Gives an Operator

Once a tunnel is up — under a legitimate account, a compromised account, or an account created during the intrusion — the operator holds an internal RFC1918 position, reachability to SMB, RDP, and WinRM, and line of sight to internal admin planes. Worse, that traffic leaves a sanctioned VPN egress and reads to most controls as trusted internal-to-internal traffic. That is the handoff to ransomware staging, lateral movement, and eventually domain compromise, and it is why I treat the gateway as a detection surface and not just a connectivity appliance.

The GlobalProtect Log Sources Worth Keeping

The operational reality: GlobalProtect and system logs on many appliances are retained for 30 to 90 days, while ransomware dwell time can comfortably exceed that. Export to syslog or a SIEM, then verify the export actually works — a broken syslog destination discovered mid-incident is worse than having no retention plan at all.

Hunting Ransomware Initial Access in GlobalProtect and System Logs

One caveat before any query: PAN-OS field names and log schemas differ across major versions. Check against your own schema before you run anything below.

Step 1 — Baseline Successful Auth and Find the Outliers

Start in the CLI to get a feel for the data, then move to the SIEM for scale.

## On the appliance
show log globalprotect direction equal backward
show log system direction equal backward
## Narrow it down
show log globalprotect direction equal backward | match "gateway-auth"

The output shape looks roughly like this. Treat it as a template for the fields you care about, not a literal transcript — column order and event names vary by PAN-OS version.

Time                 Event                 User       Src IP         Gateway      Status
2025-xx-xx 03:41:07  gateway-auth-success  j.reyes    203.0.113.44   GP-GW-01     success
2025-xx-xx 03:41:06  portal-auth-success   j.reyes    203.0.113.44   GP-PORTAL-01 success
2025-xx-xx 03:44:12  gateway-auth-failed   svc-update 198.51.100.7  GP-GW-01     failed

What I look for in that noise:

• successful gateway auth from a country or ASN that never appears in my baseline
• gateway auth from a source IP with no preceding portal-auth stage — legitimate clients usually hit the portal first
• logins at hours completely outside the org's working pattern
• a burst of failures followed by a single success from the same source

The same hunt in SPL, written to surface rare-but-successful rather than loud-and-failing:

index=pan sourcetype=pan:globalprotect
| eval user=coalesce(user, srcuser), action=lower(action)
| where action="success"
| stats count min(_time) as first_seen max(_time) as last_seen dc(src) as src_count by user, src
| where count < 3
| sort first_seen

A hit row looks like this — one success, one source, one user:

That is a lead worth five minutes, nothing more.

Step 2 — Hunt the Post-Exploitation File Artifacts

For CVE-2024-3400 specifically, Palo Alto's advisory and Unit 42's write-up documented that exploitation left files on the appliance, in the portal images directory. The check is:

ls -la /var/appweb/sslvpndocs/global-protect/portal/images/

Output that warrants immediate escalation:

-rw-r--r-- 1 nobody nobody  23 Mar 26 04:12 suspiciousfile.txt

The rule for that directory is simple: any file you did not put there is a strong indicator. Be precise about scope, though — this check is confirmed for CVE-2024-3400 only. It is not a universal GlobalProtect IOC, and treating it as one produces both false confidence and false positives. Where it does apply, correlate the file timestamps against system-log entries from the same window; an unexplained file plus a daemon restart at 04:12 tells a much stronger story than either signal alone.

Step 3 — Pivot From the Gateway Into the Network

Take the authenticating username and source IP from the GlobalProtect log and walk outward:

1. Authentication logs on the same appliance — did the same session authenticate more than once, or against more than one service?
2. HIP Match — did the connecting device present a valid posture profile, or none at all?
3. Traffic logs — within minutes of the tunnel coming up, did that source touch SMB, RDP, or WinRM on internal hosts?
4. Windows security events on the internal side — 4624/4625-style logon activity for the same username, from the VPN pool address.
5. Account and admin-plane changes — new service accounts, new group memberships, new local admins.

Which of those I tested versus which are general advice: the GlobalProtect-to-Authentication and GlobalProtect-to-Traffic pivots are the ones I have run and would build a detection around. The Windows-side correlation is standard practice, but it depends entirely on your log pipeline actually carrying the VPN pool addresses — worth verifying before you trust it.

Benign Versus Suspicious Patterns

I would escalate on row four first — new ASN plus immediate internal file-share or remote-desktop activity. It is the shortest path from "odd login" to "active intrusion," and it needs no baseline tuning to mean something.

Hardening Remote-Access Gateways Before the Next Crew Arrives

Patch cadence on internet-facing VPN appliances is the single highest-value control here. Everything below it is defense in depth. In priority order:

1. Inventory and patch every PAN-OS instance exposing GlobalProtect, and verify the version actually running rather than the version someone intended to install.
2. Restrict portal and gateway access to known source ranges where business allows, and keep the management plane off the internet entirely — no exceptions.
3. Enforce MFA on gateway authentication and remove local-account fallback.
4. Enable Threat Prevention and confirm the vendor's published signatures for the relevant advisory are active and not in alert-only mode.
5. Alert in the SIEM on successful GlobalProtect auth from never-before-seen ASNs, and on HIP failures for privileged users.
6. Extend retention and verify syslog export. You cannot hunt dwell time you have already deleted.

What I Confirmed and What I Did Not

Confirmed from public sources: a report describes ransomware operators using a GlobalProtect flaw for stealthy VPN access; CVE-2024-3400 exists with a vendor advisory, in-the-wild exploitation, and a CISA KEV listing; and the portal images directory check is documented for that CVE.

Not tested or not available: the specific CVE, affected versions, and exploitation timeline for the current report; the exact field names in your PAN-OS version; and whether these queries return the same results on appliances other than the ones I have worked with. The queries here are written to be adaptable, not copy-paste-guaranteed. Run them against a known-good login first so you know what a baseline hit looks like.

Further Reading

• Palo Alto Networks security advisory for CVE-2024-3400 — vendor advisory, including affected versions and hotfix guidance
• Unit 42 write-up on CVE-2024-3400 exploitation — original research covering observed post-exploitation behavior
• NVD record for CVE-2024-3400 — CVE record with CVSS scoring and references
• CISA Known Exploited Vulnerabilities catalog — government KEV list

For log schema and field definitions, the PAN-OS Admin Guide's logging section is the reference to check against your running version rather than trusting a blog post.

The gateway is the front door. It should be the loudest thing in your SIEM.