CVE-2026-0257：GlobalProtect Cookie 偽造到 Qilin 勒索軟體

更新日期：2026 年 7 月 25 日。 CVE-2026-0257 是 Palo Alto Networks PAN-OS GlobalProtect Portal／Gateway 的 Authentication Override Cookie 驗證缺陷。攻擊者在特定設定下，不需要密碼或 MFA，就能偽造伺服器會接受的 Cookie，建立未授權 VPN 連線。CISA 已將它列入 Known Exploited Vulnerabilities；最新事件調查又確認 Qilin ransomware affiliates 正用它取得初始存取，從 VPN 邊界一路推進到網域加密與雙重勒索。

這個漏洞最值得研究的不是某段神奇 payload，而是一個常被誤解的密碼學界線：用公開金鑰加密，只能讓持有私鑰的伺服器解密；它不能證明資料是由可信任使用者產生。如果伺服器把「能被我解密」誤當成「一定是我簽發」，任何拿到公開金鑰的人都可能製作看似合法的權杖。

60 秒重點摘要

• 漏洞：CVE-2026-0257，CWE-565 Reliance on Cookies without Validation and Integrity Checking。
• 影響：未授權攻擊者可偽造 GlobalProtect Authentication Override Cookie，冒用指定使用者並建立 VPN 連線。
• 必要設定：GlobalProtect Portal 或 Gateway 啟用 Authentication Override Cookie，且 Cookie 憑證曾與 HTTPS 或其他可取得公開憑證的功能共用。
• 根因：易受攻擊流程依賴 RSA 加密／解密來接受 Cookie，卻沒有提供足以證明 Cookie 簽發者的獨立完整性驗證。
• 公開 POC：Rapid7 的研究會從 TLS Certificate Chain 取得公開金鑰，逐一建立測試 Cookie，再判斷 Portal／Gateway 是否接受；本文分析流程，但不提供可直接偽造登入的實作。
• 實際攻擊：Rapid7 從 5 月 17 日觀察成功利用；Arctic Wolf 在 6 月多起事件中確認，攻擊者由此進入內網，最後部署 Qilin ransomware。
• 修補：升級到 Palo Alto 公告的安全 PAN-OS／Prisma Access 版本；若無法立即更新，停用 Authentication Override，或產生一張從未與其他功能共用的新專用憑證。
• 偵測：關聯 auth_method=Cookie、本機管理員、異常裝置名稱／MAC、VPN IP Assignment、/ssl-vpn/hipreport.esp 與 /ssl-vpn/getconfig.esp。

為什麼這個關鍵字現在重新升溫

Palo Alto Networks 在 5 月 13 日發布公告，Rapid7 從 5 月 17 日開始看到實際利用，CISA 在 5 月 29 日加入 KEV。到了 7 月 20 日，Arctic Wolf 公開多起 6 月事件的完整後續：攻擊者把 CVE-2026-0257 當作一致的初始入口，接著取得認證資料、橫向移動，並在不同受害環境部署 Qilin。

因此現在的搜尋意圖已經從「PAN-OS 要不要更新」變成：

• GlobalProtect Cookie 到底如何被偽造？
• 為什麼公開金鑰加密不能證明 Cookie 身分？
• 更新後是否要撤銷 Session 或更換憑證？
• 如何從 GlobalProtect Log 判斷只有探測，還是真的建立 VPN Tunnel？
• Qilin 進入後使用哪些橫向移動與勒索行為？

證據分級：已確認、研究者分析與未知部分

受影響範圍與最低安全版本

Panorama 與 Cloud NGFW 不受此漏洞影響；舊的、已停止支援的 PAN-OS 應升級到仍受支援的安全版本。不要只看主版本「11.2」或「10.2」就判定安全，Hotfix Take 也是漏洞邊界的一部分。正式變更前應以 Palo Alto 最新 Product Status 表為準，因為同一分支有多個可接受修補線。

暴露條件：不是所有 GlobalProtect 都可直接利用

1. 設備存在 GlobalProtect Portal 或 Gateway。
2. 設定中啟用 Generate Cookie for Authentication Override 或 Accept Cookie for Authentication Override。
3. 用來加解密 Cookie 的憑證曾與 Portal／Gateway HTTPS 或其他會向外提供 Certificate Chain 的功能共用。
4. 設備版本低於對應修補門檻，且沒有停用功能或更換為全新的專用憑證。

Authentication Override 並非預設啟用。它的目的，是讓已完成認證的使用者在 Cookie 有效期內不必再次輸入密碼或重跑 MFA。這種 Cookie 本質上接近 Bearer Token：誰能提交有效值，伺服器就把誰視為已認證。因此 Cookie 的「不可偽造性」與帳號密碼一樣重要。

漏洞資料流：從 TLS 公開憑證到未授權 VPN

Internet attacker
    │
    ├─ TLS handshake with GlobalProtect
    │      └─ receives public certificate chain
    │
    ├─ chooses a public key reused by Authentication Override
    │
    ├─ constructs cookie claims for a target identity
    │
    └─ encrypts the cookie to the server's public key
              │
              ▼
       GlobalProtect / gpsvc
              │
       decrypts with private key
              │
       insufficient independent authenticity check
              ▼
       accepts attacker-controlled identity
              │
              ▼
       portal access / gateway VPN tunnel

這條鏈不需要偷走私鑰。RSA 的正常設計就是：公開金鑰可以給任何人，用它加密的資料只有私鑰持有者能解密。問題出在應用程式的信任語意——如果「能成功解密」就是唯一可信條件，那任何人都能把自己選擇的內容加密後交給伺服器。

密碼學核心：Confidentiality 不等於 Authenticity

加密回答的是「其他人能不能看到內容」；簽章或 MAC 回答的是「內容是不是可信任簽發者產生、而且沒有被修改」。兩者可以同時存在，但不能互相替代。

概念性的易受攻擊模式如下。這不是 PAN-OS 原始碼，而是將 Rapid7 分析抽象成容易審查的資料流：

// 概念模型：只解密，然後信任明文中的身分
byte[] ciphertext = Base64Decode(request.AuthCookie);
byte[] plaintext  = RsaDecrypt(serverPrivateKey, ciphertext);

CookieClaims claims = ParseClaims(plaintext);

// 缺陷：沒有驗證 MAC、簽章、簽發者或 server-side session
return CreateVpnSession(claims.Username, claims.Domain);

即使伺服器使用安全的 RSA Padding，這個業務邏輯仍可能有問題。Padding 防止部分密碼學攻擊，卻不會把公開金鑰變成祕密，也不會自動證明發送者是合法 Portal。真正缺少的是與攻擊者無法取得的祕密綁定之完整性證明。

安全修補應如何改變信任模型

Palo Alto 表示，更新後設備會以更安全的方法重新產生 Authentication Override Cookie，使用者升級後須重新認證一次。供應商沒有公開完整程式 diff，因此下列是安全設計示意，不宣稱等同實際修補：

// 概念模型：Cookie 內容與伺服器端祕密綁定
CookieClaims claims = ParseStrictSchema(cookie.Payload);

bool valid = VerifyHmac(
    key: DedicatedCookieIntegrityKey,
    data: cookie.Payload,
    tag: cookie.AuthenticationTag);

if (!valid ||
    claims.ExpiresAt < Now ||
    claims.Audience != ThisGateway ||
    !SessionStore.Contains(claims.SessionId))
{
    RejectAuthentication();
}

return CreateVpnSession(claims.Subject);

這種設計把安全性建立在伺服器端 Secret／可信任簽發者與有效 Session，而不是公開憑證是否「剛好不容易取得」。另外還要驗證效期、Audience、Portal／Gateway 範圍、Session ID、使用者狀態與撤銷資訊，避免 Cookie 被跨設備或長時間重放。

Rapid7 POC 實際證明了什麼

1. 連線到 GlobalProtect HTTPS 服務，取得整條 Certificate Chain。
2. 迭代 Chain 中每張 RSA Certificate 的公開金鑰。
3. 使用每把公開金鑰建立測試 Authentication Override Cookie。
4. 將 Cookie 分別送往 Portal、Gateway 或兩者。
5. 根據回應判斷 Cookie 是否被接受，以及是否能建立身分／VPN Session。

這個 POC 的關鍵不是暴力破解私鑰，而是測試「HTTPS Certificate Chain 中是否有一把公開金鑰，同時被後端當成 Cookie 解密金鑰」。Rapid7 的 Lab 中，第一張憑證失敗，第二張 CA Certificate 成功；這也說明掃描器不能只比較 Leaf Certificate，必須理解完整 Chain 與設備設定。

本文不重貼可直接偽造管理員 Cookie 的程式碼或 payload。防守團隊若需要驗證，優先使用已認證的版本／設定檢查；任何主動 POC 都應只在隔離實驗室或取得明確授權的設備執行，因為成功測試會建立可用的認證狀態並污染事件記錄。

從漏洞到 Qilin：真實攻擊鏈

1. 外部探測：掃描可達的 GlobalProtect Portal／Gateway，取得 TLS Certificate Chain。
2. Cookie 認證：使用偽造 Cookie 冒用本機或其他高價值帳號。部分探測只停在 Cookie Accepted，部分繼續建立 VPN。
3. 建立 Tunnel：Rapid7 在成功案例看到 /ssl-vpn/hipreport.esp 與 /ssl-vpn/getconfig.esp，隨後取得 VPN IP。
4. 內部發現與認證存取：攻擊者從 VPN 網段盤點 AD、檔案伺服器與管理介面，取得可橫向移動的認證資料。
5. 橫向執行：Arctic Wolf 觀察使用 PsExec 與 Administrative Shares，在多台 Windows 主機執行工作。
6. Payload Staging：多起事件把密碼保護的勒索程式放在 C:\PerfLogs\。
7. 衝擊：依 affiliate 操作差異，可能直接進行大量加密，也可能先外洩資料再雙重勒索。
8. 清除痕跡：事件中出現大範圍 Log Clearing，因此不能只依端點仍存在的 Event Log 排除入侵。

「CVE-2026-0257 會直接執行 ransomware」是錯誤描述。漏洞原始 primitive 是 Authentication Bypass 與未授權 VPN；Qilin 是攻擊者取得網路層存取後的後續行動。把兩階段分開，才能在偵測上設置多個攔截點：Cookie Login、Gateway Connected、內部掃描、認證濫用、PsExec、Staging、加密。

如何檢查是否啟用易受影響功能

Portal：

1. 進入 Network → GlobalProtect → Portals。
2. 選擇 Portal，進入 Agent → Agent Configuration → Authentication。
3. 確認是否勾選 Generate cookie for authentication override 或 Accept cookie for authentication override。

Gateway：

1. 進入 Network → GlobalProtect → Gateways。
2. 選擇 Gateway，進入 Agent → Client Settings → Authentication Override。
3. 確認是否勾選 Accept cookie for authentication override。

接著追蹤所選 Certificate Profile／Certificate：是否曾用於 Portal HTTPS、Gateway HTTPS、其他服務、使用者或設備。官方 FAQ 明確指出，若該憑證曾經用於其他功能，即使現在已解除共用，也不能繼續當 Cookie 憑證；必須產生一張全新的專用憑證。

GlobalProtect Log：區分探測、認證與成功連線

Splunk 偵測範例

index=network sourcetype="pan:globalprotect"
("Cookie" AND "success")
| eval user_lower=lower(user)
| where user_lower="admin"
    OR host_name IN ("GP-CLIENT","DESKTOP-GP01","WINDOWS-LAPTOP-001")
    OR src_mac IN ("aa:bb:cc:dd:ee:ff","00:11:22:33:44:55")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(src_ip) values(host_name) values(src_mac)
        values(event_type) by user, device_name

index=network sourcetype="pan:globalprotect"
(event_type="gateway-auth" OR event_type="gateway-connected")
| transaction user src_ip maxspan=10m
| search "Cookie" "success"
| table _time device_name user src_ip assigned_ip
        host_name client_os src_mac duration

實際欄位名稱會依 Syslog Parser、Splunk Add-on 與 PAN-OS 版本不同，請先抽樣原始事件再對應。高價值規則不是單一 IP Blocklist，而是「Cookie 認證 + 不合理使用者／裝置 + Gateway Connected + VPN Pool 內部行為」的關聯。

已公開 IOC 與使用限制

Rapid7／Unit 42 公開的早期來源包含 104.207.144[.]154、146.19.216[.]119、146.19.216[.]120、146.19.216[.]125 等；裝置特徵包含 GP-CLIENT、DESKTOP-GP01、WINDOWS-LAPTOP-001、aa:bb:cc:dd:ee:ff 與 00:11:22:33:44:55。

這些 IOC 適合回溯，不適合當唯一偵測。IP 可被棄用、共享或轉移；裝置名稱與 MAC 也能輕易修改。命中 IOC 不是自動證明入侵，未命中也不是安全證明。應將 IOC 與 Cookie Login、VPN Session、使用者平常來源、內部網路行為、EDR 程序樹與 AD 認證事件關聯。

Qilin 後續 Threat Hunting

• VPN Pool IP 是否對大量主機執行 TCP 445／3389／5985／5986 掃描。
• 非管理工作站是否出現 PsExec.exe、PSEXESVC.exe 或遠端服務建立。
• ADMIN$、C$ 是否由新來源大量存取。
• C:\PerfLogs\ 是否新增密碼保護壓縮檔、未知 EXE／DLL 或批次檔。
• 網域管理員、備份帳號、Hypervisor 管理帳號是否由 VPN Pool 或新裝置登入。
• Event Log Service 停止、wevtutil cl、PowerShell Clear-EventLog 或 EDR Tampering。
• 短時間大量檔案改名、Entropy 上升、Shadow Copy 刪除、備份工作失敗。
• 外洩前的大量壓縮、Rclone／雲端儲存、異常 DNS／HTTPS Upload。

修補與降低風險的正確順序

1. 確認暴露：盤點所有外部與內部 Portal／Gateway、PAN-OS／Prisma Access 版本、Authentication Override 設定與 Certificate Usage。
2. 立即更新：升級到官方 Product Status 表列出的安全版本；所有會產生或接受 Cookie 的 GlobalProtect Component 都要更新。
3. 無法更新時：停用 Generate／Accept Authentication Override Cookie；或建立一張從未與其他功能共用的全新專用憑證。
4. 不要重用舊憑證：曾經透過 TLS 或其他功能公開的 Certificate 不能只靠「現在解除共用」恢復安全。
5. 讓使用者重新認證：官方修補會使用更安全方法重新產生 Cookie，更新後第一次登入需要重新認證。
6. 撤銷既有狀態：若設備曾暴露，終止現有 GlobalProtect Session，檢查並撤銷可疑 Cookie／Token，重設遭冒用或可能外洩的帳號。
7. 威脅獵捕：回溯至少至 2026 年 5 月 17 日；若 Log Retention 允許，再往前延伸。
8. 分段與最小權限：VPN 使用者不應因「通過 VPN」就能直接管理 AD、備份、Hypervisor 或安全設備。

若發現 Gateway Connected：事件應變

1. 封鎖並終止可疑 VPN Session，但保留 GlobalProtect、Traffic、Threat、System 與 Config Log。
2. 確認被冒用的 Username、Source IP、Host ID、MAC、Client OS、Assigned IP 與 Session 時間。
3. 用 Assigned VPN IP 搜尋 Firewall Traffic、DNS、Proxy、AD、SMB、EDR 與 Server Log。
4. 重設受影響帳號，撤銷 Session／Token；若使用者有高權限，擴大到其管理過的端點與 Secrets。
5. 檢查 PsExec、Remote Service、Admin Share、RDP、WinRM、Password Dumping 與新建管理員。
6. 若出現 Qilin Staging／加密前兆，立即隔離受影響網段、保護備份控制面並啟動勒索事件程序。
7. 完成更新與全新專用憑證後才恢復對外服務，並對後續 Cookie Login 建立加強監控。

常見錯誤

• 「有 MFA 所以安全」：Authentication Override 的目的就是避免重跑認證；偽造 Cookie 可能發生在 MFA 判斷之前。
• 「公開金鑰本來就公開，所以不可能是漏洞」：正因公開金鑰人人可用，系統不能把使用它加密的能力當成身分證明。
• 「Cookie Login 成功但沒 Malware，所以沒事」：成功 Gateway Connected 已代表內部網路邊界被突破。
• 「只封 IOC IP」：攻擊基礎設施與裝置指紋都能快速更換。
• 「把舊憑證從 HTTPS 拿掉就好」：公開金鑰已經可以被保存；官方要求產生全新的專用憑證。
• 「修補後不必查歷史」：Qilin 事件證明初始存取可能在加密前數日或數週發生。

FAQ

CVE-2026-0257 能直接控制防火牆嗎？

漏洞本身讓攻擊者繞過 GlobalProtect 認證並建立未授權 VPN，而不是直接取得 PAN-OS Root Shell。後續控制範圍取決於被冒用身分、VPN Policy、Network Segmentation 與內部服務權限。

功能沒有啟用，還需要升級嗎？

沒有啟用 Authentication Override 可消除這條特定利用路徑，但外網安全設備仍應升級到受支援的安全版本，避免日後設定變更重新暴露，也取得同一維護版的其他安全修補。

為什麼 NVD 是 9.1，供應商是 CVSS 4.0 7.8？

兩者使用不同 CVSS 版本與影響表達方式。Palo Alto 的 CVSS 4.0 強調產品本身與後續系統影響；NVD 顯示 CVSS 3.1 9.1。實務排序應加入「Internet-facing VPN、已實際利用、KEV、Qilin 後續」等情境，不應只比較單一數字。

更新後為什麼使用者必須重新登入？

官方說明修補後會用更安全的方法重新產生 Cookie。舊 Cookie 不應跨越新的信任機制繼續有效，因此第一次連線需要重新認證，這是預期安全行為。

延伸閱讀

• CVE-2026-50522：SharePoint 反序列化 RCE、POC、修補與鑑識
• LonelySec 漏洞預警與 CVE 專題

官方公告與技術來源

• Palo Alto Networks：CVE-2026-0257 Security Advisory
• Unit 42：Active Exploitation Threat Brief 與 IOC
• Rapid7：gpsvc、Cookie Forgery、POC 與實際 Log 分析
• Arctic Wolf：CVE-2026-0257 到 Qilin Ransomware 的事件調查
• NVD：CVE-2026-0257、CVSS 與 CISA KEV 狀態
• CISA Known Exploited Vulnerabilities Catalog

本文技術細節以 2026 年 7 月 25 日可取得的供應商公告、Rapid7 POC 分析與 Arctic Wolf 事件調查為準。概念程式碼用於解釋信任邊界，不冒充未公開的 PAN-OS 原始碼。