You Can't Sigma a Buffer Overflow: Post-Exploitation Detection for CVE-2026-0300

Zero-days are designed to be invisible. A buffer overflow in a network appliance doesn’t show up in your SIEM. It doesn’t spawn a suspicious process. It doesn’t drop a file in a temp directory. It exploits a parsing mistake in memory, at a layer your detection tooling was never designed to see.

That’s the honest truth about CVE-2026-0300 — a critical unauthenticated RCE in the PAN-OS User-ID Authentication Portal, disclosed by Palo Alto Networks Unit 42 on May 6, 2026. You cannot write a Sigma rule that catches the initial exploit. The vulnerability lives in nginx memory on the firewall appliance itself. Standard log sources simply don’t reach there.

But here’s the thing: the exploit is one moment. Everything that comes after is a campaign. And campaigns leave tracks.

Unit 42’s threat brief on CL-STA-1132 — the likely state-sponsored cluster exploiting this CVE — documents a detailed post-exploitation chain. Every step of that chain is detectable. None of those detections require you to have seen this specific CVE before. They’re behavioral rules that apply to the next edge device compromise too, and the one after that.

That’s the game worth playing.

The Pyramid of Pain and Where to Focus

If you’ve spent time in detection engineering, you know the Pyramid of Pain — David Bianco’s framework for thinking about which indicators are most costly for attackers to change. At the bottom: IP addresses and hashes. Easy to rotate, minimal pain for the attacker when you block them. At the top: TTPs (tactics, techniques, and procedures). Hard to change, because they reflect how the attacker fundamentally operates.

This doesn’t mean we skip IOC rules. We don’t. IOCs go into your blocklists and your threat intel platform on day one — they may catch the same attacker infrastructure being reused, and that’s valuable. We’ll write those rules too.

But IOCs are where we start, not where we stop. The behavioral rules are where we build durable detection that outlasts this campaign, this CVE, and this threat actor.

Let’s build both.

The Post-Exploitation Chain

Unit 42 documented the following sequence after successful exploitation of CVE-2026-0300:

1. Shellcode injected into an nginx worker process (initial access established)
2. Immediate log cleanup — crash logs, nginx crash records, core dump files deleted
3. Tunneling tools deployed — EarthWorm and ReverseSocks5 dropped to /var/tmp/ with root privileges
4. Active Directory enumeration — using the firewall’s service account credentials against domain root and DomainDnsZones
5. SAML flood against the first device — forcing failover so a second HA device became internet-facing and exploitable
6. Second device compromised — same playbook repeated
7. Anti-forensic cleanup — ptrace injection evidence deleted from audit log, SUID binary removed

Seven steps. Six of them are detectable with behavioral Sigma rules. Let’s build them.

Rule 1: IOC Coverage — Because the Bottom of the Pyramid Still Matters

Before we get to behavior, let’s cover the indicators Unit 42 published. These should go into your SIEM and your threat intel platform immediately. Yes, the attacker can rotate IPs. Yes, the hash changes when they recompile. Write the rules anyway — they may catch infrastructure reuse, lateral movement by the same actor, or a copycat using the same tooling.

title: CVE-2026-0300 CL-STA-1132 Known IOC Match
id: f1a3c5e7-9b2d-4f6a-8c0e-2a4b6d8f0e1c
status: stable
description: >
  Matches known indicators of compromise associated with CVE-2026-0300
  exploitation by CL-STA-1132, a likely state-sponsored threat cluster.
  Covers C2 IP addresses, EarthWorm malware hash, attacker user-agent string,
  and known malicious download URLs. IOC rules are the bottom of the Pyramid
  of Pain — write them, but don't stop here.  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1090/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.command_and_control
  - attack.t1090
  - cve.2026-0300
  - cl-sta-1132-suite
logsource:
  category: proxy
  product: any
detection:
  selection_ip:
    dst_ip:
      - "67.206.213.86"
      - "136.0.8.48"
      - "146.70.100.69"
      - "149.104.66.84"
  selection_url:
    cs-uri|contains:
      - "146.70.100.69:8000/php_sess"
      - "github.com/Acebond/ReverseSocks5/releases/download/v2.2.0"
  selection_useragent:
    cs-user-agent|contains: "Safari/532.31 Mozilla/5.5"
  selection_hash:
    # Match in EDR telemetry or file event logs
    Hashes|contains: "e11f69b49b6f2e829454371c31ebf86893f82a042dae3f2faf63dcd84f97a584"
  condition: selection_ip or selection_url or selection_useragent or selection_hash
falsepositives:
  - Highly unlikely for IP and hash matches. User-agent string is malformed
    and does not match any known legitimate browser.
level: critical

Note on the user-agent: The attacker’s user-agent (Safari/532.31 Mozilla/5.5) is deliberately malformed — it combines an outdated Safari version string with a fictional Mozilla version. No legitimate browser generates this string. A hit on this pattern alone is high-confidence.

Rule 2: SOCKS5 Tunneling Tool Executed from World-Writable Directory

Technique: T1090 — Proxy | T1572 — Protocol Tunneling

This is the highest-value behavioral rule in the suite. EarthWorm was deployed to /var/tmp/linuxupdate, /var/tmp/linuxap, and /var/tmp/linuxda — world-writable temp paths with names masquerading as system processes. The combination of SOCKS5 tooling executed from a temp directory, with a system-sounding binary name, is almost never legitimate.

The rule doesn’t care about the binary name or hash. It cares about the behavior: a SOCKS5 or network tunneling capability executing from a path no legitimate software deployment system would use.

title: SOCKS5 or Tunneling Tool Executed from World-Writable Temp Directory on Linux
id: 2b4d6f8a-0c2e-4a6c-8e0b-1d3f5a7c9e2f
status: experimental
description: >
  Detects execution of known SOCKS5 proxy and network tunneling tools from
  world-writable directories (/tmp, /var/tmp, /dev/shm) on Linux hosts.
  Legitimate infrastructure tools are deployed to managed paths. Execution
  from temp paths with system-sounding names is a strong indicator of
  post-exploitation tool staging, as observed in CL-STA-1132 exploitation
  of CVE-2026-0300 (EarthWorm deployed to /var/tmp/).  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1090/
  - https://attack.mitre.org/techniques/T1572/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.command_and_control
  - attack.t1090
  - attack.t1572
  - cl-sta-1132-suite
logsource:
  category: process_creation
  product: linux
detection:
  selection_path:
    Image|startswith:
      - "/tmp/"
      - "/var/tmp/"
      - "/dev/shm/"
  selection_tools:
    # Known tunneling/proxy tool names — extend as new tools emerge
    Image|endswith:
      - "/ew"
      - "/earthworm"
      - "/socks5"
      - "/rsocks"
      - "/revsocks"
      - "/frpc"
      - "/chisel"
      - "/ligolo"
      - "/npc"
    # Also catch system-name masquerading from temp paths
  selection_masquerade:
    Image|startswith:
      - "/tmp/"
      - "/var/tmp/"
      - "/dev/shm/"
    Image|endswith:
      - "/linuxupdate"
      - "/update"
      - "/systemd"
      - "/kworker"
      - "/kthread"
  condition: selection_path and (selection_tools or selection_masquerade)
falsepositives:
  - Developer testing of network tools in temp directories
  - Some CI/CD pipeline agents that execute downloaded binaries from /tmp
    (scope suppression to known CI hostnames)
level: high

Tuning tip: On network infrastructure hosts (firewalls, routers, VPN concentrators), raise this to critical. These devices should never be executing user-built binaries from temp paths. On general-purpose Linux servers, the false positive rate is low but non-zero — add suppression for known build agent hostnames.

Rule 3: Binary Downloaded Directly from GitHub Releases on Infrastructure Device

Technique: T1105 — Ingress Tool Transfer

ReverseSocks5 was pulled directly from github.com/Acebond/ReverseSocks5/releases/download/ by the compromised PAN-OS device. This is a pattern, not a one-time event. State actors and ransomware operators alike pull open-source post-exploitation tools directly from GitHub release pages because it’s fast, the binaries are pre-compiled, and the download blends with legitimate developer traffic.

On a firewall, router, or VPN appliance, an outbound request to github.com/*/releases/download/ for a compressed binary is essentially never legitimate. The rule targets this pattern in proxy or DNS logs.

title: Network Infrastructure Device Downloading Binary from GitHub Releases
id: 9e1c3a5f-7b2d-4e8a-b0c4-5d7f9a1b3c6e
status: experimental
description: >
  Detects outbound HTTP/HTTPS requests from network infrastructure device IPs
  to GitHub release download paths for compressed binaries. This pattern was
  observed during CL-STA-1132 exploitation of CVE-2026-0300, where
  ReverseSocks5 was downloaded directly from GitHub. Legitimate firewall and
  appliance processes do not pull binaries from GitHub release pages.  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1105/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.command_and_control
  - attack.t1105
  - cl-sta-1132-suite
logsource:
  category: proxy
  product: any
detection:
  selection:
    cs-host|endswith: "github.com"
    cs-uri-stem|contains: "/releases/download/"
    cs-uri-stem|endswith:
      - ".tar.gz"
      - ".zip"
      - ".tgz"
      - ".gz"
      - ".elf"
      - ".bin"
  filter_known_legitimate:
    # Exclude known developer workstation IP ranges
    # Replace with your actual developer subnet CIDR
    src_ip|startswith:
      - "10.10.50."    # Example: developer VLAN
  condition: selection and not filter_known_legitimate
falsepositives:
  - Developer workstations pulling open-source tools from GitHub (exclude by subnet)
  - Automated build pipelines downloading release artifacts
level: high

Tuning tip: The precision of this rule comes from the source IP. Scope it to your infrastructure device IP ranges — firewall management IPs, out-of-band management networks, appliance subnets. A hit from a developer laptop is expected. A hit from your firewall’s management IP is a five-alarm signal.

Rule 4: Service Account Performing LDAP Enumeration or DNS Zone Query

Technique: T1018 — Remote System Discovery | T1087 — Account Discovery

After establishing access, CL-STA-1132 used the PAN-OS firewall’s service account credentials to enumerate Active Directory — targeting domain root and DomainDnsZones. This detection doesn’t live on the firewall. It lives on your domain controllers, in Windows Security Event logs.

The signal is a service account — one with a naming convention typical of network infrastructure (svc-panos, svc-uid, svc-firewall) — suddenly performing LDAP queries or DNS zone lookups it has never performed before, or performing them from an unexpected source IP.

title: Network Infrastructure Service Account Performing AD or DNS Enumeration
id: 4c6e8a0b-2d4f-4c8a-9e1b-3f5a7c9e1d3f
status: experimental
description: >
  Detects service accounts associated with network infrastructure devices
  (firewalls, VPN appliances) performing LDAP enumeration or DNS zone queries
  against Active Directory. CL-STA-1132 used PAN-OS service account credentials
  to enumerate domain root and DomainDnsZones after compromising the firewall
  via CVE-2026-0300. This behavior is anomalous for infrastructure service
  accounts which normally perform only authentication-related operations.  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1018/
  - https://attack.mitre.org/techniques/T1087/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.discovery
  - attack.t1018
  - attack.t1087.002
  - cl-sta-1132-suite
logsource:
  product: windows
  service: security
detection:
  selection_ldap:
    EventID: 4662
    ObjectType|contains:
      - "domainDNS"
      - "organizationalUnit"
      - "group"
      - "user"
    SubjectUserName|contains:
      # Adjust to match your infrastructure service account naming convention
      - "svc-pan"
      - "svc-fw"
      - "svc-uid"
      - "svc-vpn"
      - "svc-firewall"
      - "svc-radius"
  selection_dns_zone:
    EventID: 4662
    ObjectName|contains:
      - "DomainDnsZones"
      - "ForestDnsZones"
    SubjectUserName|contains:
      - "svc-pan"
      - "svc-fw"
      - "svc-uid"
      - "svc-vpn"
      - "svc-firewall"
      - "svc-radius"
  condition: selection_ldap or selection_dns_zone
falsepositives:
  - Legitimate User-ID agent operations that require AD queries (verify
    against expected account behavior baseline)
  - Initial provisioning of a new firewall integration
level: high

Tuning tip: Tune the service account name patterns to match your naming conventions exactly. The more specific your filter, the higher the precision. If your PAN-OS service account is named CORP\svc-panos-prod, add that verbatim. Broad patterns here reduce precision unnecessarily.

Rule 5: Audit Log or Core Dump File Deletion on Linux

Technique: T1070.002 — Indicator Removal: Clear Linux or Mac System Logs

This is the most broadly applicable rule in the entire suite. Anti-forensic log deletion is not unique to PAN-OS. It is standard operating procedure for any sophisticated attacker on any Linux host. CL-STA-1132 deleted crash kernel messages, nginx crash entries, core dump files, ptrace injection evidence, and a SUID binary — all within hours of achieving access.

The behavior is consistent: an attacker with root access removes the evidence of their presence. On a network appliance, any process touching audit logs, crash dumps, or core files outside of a scheduled maintenance window is suspicious. On any Linux host, deletion of audit log content by a non-system process warrants investigation.

title: Audit Log or Core Dump Deletion on Linux Host
id: 7d9f1b3e-5a7c-4d9f-8b1e-3c5e7a9f1b4d
status: stable
description: >
  Detects deletion of audit logs, crash dumps, or core files on Linux hosts.
  This anti-forensic technique was observed in CL-STA-1132 post-exploitation
  of CVE-2026-0300, where the attacker systematically deleted nginx crash
  records, kernel crash messages, ptrace injection evidence, and core dump
  files. This behavior is consistent with post-exploitation cleanup across
  many threat actor campaigns regardless of the initial access vector.  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1070/002/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.defense_evasion
  - attack.t1070.002
  - cl-sta-1132-suite
logsource:
  category: process_creation
  product: linux
detection:
  selection_rm:
    Image|endswith:
      - "/rm"
      - "/shred"
      - "/unlink"
  selection_targets:
    CommandLine|contains:
      - "/var/log/audit"
      - "/var/log/nginx"
      - "/var/crash"
      - "/var/core"
      - "/tmp/core"
      - "/var/tmp/core"
      - ".core"
      - "crash.log"
      - "audit.log"
      - "kern.log"
  filter_legitimate:
    # Common log rotation processes
    ParentImage|endswith:
      - "/logrotate"
      - "/systemd"
    User: "root"
  selection_core_glob:
    CommandLine|contains:
      - "core.*"
      - "*.core"
    Image|endswith: "/rm"
  condition: (selection_rm and selection_targets and not filter_legitimate) or selection_core_glob
falsepositives:
  - Legitimate log rotation if logrotate filter doesn't catch the parent process
  - Disk cleanup scripts run by system administrators (suppress by scheduled
    maintenance window time range or by admin account name)
level: high

On network appliances specifically: Raise this to critical. A PAN-OS device, Cisco ASA, Juniper SRX, or any similar appliance has no business reason for an operator to be manually deleting audit logs. Any hit from an infrastructure device IP in your asset inventory should page immediately.

Rule 6: SAML Authentication Flood Against a Single Service Provider

Technique: T1499.002 — Endpoint Denial of Service: Service Exhaustion Flood

CL-STA-1132 flooded the first compromised device with SAML requests to force a failover, promoting the second HA device to active — which then became the new internet-facing target for exploitation. This is a creative technique: weaponizing a high-availability failover mechanism as an attack primitive.

The detection lives in your IdP logs. A burst of SAML authentication requests targeting a single service provider (SP) entity ID from a concentrated source, resulting in a high failure rate, is the signal. This rule is particularly relevant for organizations running HA pairs of network appliances that authenticate via SAML.

title: SAML Authentication Flood Against Single Service Provider
id: 3e5a7c9b-1d3f-4e6a-8c0d-2b4f6a8c0e3f
status: experimental
description: >
  Detects a high volume of SAML authentication failures targeting a single
  service provider entity ID within a short window. CL-STA-1132 used this
  technique to force HA failover on a PAN-OS pair, making the second device
  internet-facing and exploitable. High-volume SAML floods may also precede
  session hijacking or brute-force attacks against federated identity systems.  
references:
  - https://unit42.paloaltonetworks.com/captive-portal-zero-day/
  - https://attack.mitre.org/techniques/T1499/002/
author: Cyber Mixology
date: 2026-05-10
tags:
  - attack.impact
  - attack.t1499.002
  - cl-sta-1132-suite
logsource:
  product: okta
  service: system_log
detection:
  selection:
    eventType: "user.authentication.auth_via_saml"
    outcome.result: "FAILURE"
  timeframe: 5m
  condition: selection | count() by target.alternateId > 20
falsepositives:
  - Misconfigured SP with broken SAML metadata causing legitimate auth failures
  - Automated testing or integration verification tools
level: high

Tuning tip: The threshold of 20 failures in 5 minutes is conservative. In most environments, a broken SAML configuration generates a handful of failures — not a flood. Adjust the threshold based on your IdP’s baseline. The key is the spike pattern, not the absolute number.

Thinking in Suites: The Tag That Ties It Together

Every rule above carries the tag cl-sta-1132-suite. But look at what these rules actually detect:

• Tunneling tools in temp directories — any Linux compromise
• GitHub binary downloads from infra devices — any edge device attack
• Service account AD enumeration — any firewall or VPN breach
• Audit log deletion — any sophisticated Linux attacker
• SAML floods — any federated identity abuse

Only the SAML rule and the IOC rule are campaign-specific. The other four detect behaviors that nation-state actors, ransomware operators, and financially motivated intruders all use — because they work, and because they’re hard to change.

Tag these rules with cl-sta-1132-suite for correlation, but think of them as permanent additions to your detection library. When the next edge device zero-day drops — and it will — these rules are already watching.

Build a correlation condition in your SIEM: two or more rules from this suite firing on the same source IP or service account within 24 hours elevates to a critical case. One rule firing is a signal. Two is a pattern. Three is an incident.

What This Campaign Teaches Us

Unit 42 noted something important in their conclusion: CL-STA-1132 operated with deliberate restraint. They used open-source tools, maintained intermittent interactive sessions over weeks, and kept their footprint small. That operational discipline was specifically designed to stay below automated alerting thresholds.

The IOC rule will catch them if they reuse infrastructure. The behavioral rules catch the technique regardless of who’s running it or what tooling they bring next time.

That’s the difference between chasing the attacker and watching the playbook.

Write both. Build the suite. Keep watching.

Unit 42’s full threat brief on CVE-2026-0300 and CL-STA-1132 is available at unit42.paloaltonetworks.com. The MITRE ATT&CK techniques referenced in this post map directly to the techniques documented in that advisory — cross-referencing both is worthwhile for building a complete picture of this campaign.