Brute force attempts on Global Protect Portal are not redirected to configured IDP

• Observing multiple log in attempts on the GlobalProtect portal
• Log in attempts are not seen in IDP logs, but are directly appearing on the firewall
• GlobalProtect logs show random users who do not belong to the domain.



**ERROR_LOGS**
• HTTP POST requests can be verified in sslvpn-access.log
1.1.1.1  [2025-07-09 21:47:56.12421469 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 134 512 11443, taskid 1094695, user mredd
1.1.1.1  [2025-07-09 21:47:57.191908086 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 142 512 11443, taskid 1094696, user tklingensmith
1.1.1.1  [2025-07-09 21:47:57.36645413 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 137 512 11443, taskid 1094697, user erankins
1.1.1.1  [2025-07-09 21:47:58.541788549 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 135 512 11443, taskid 1094698, user kandes
1.1.1.1  [2025-07-09 21:47:59.014454329 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 134 512 11443, taskid 1094699, user fedge
1.1.1.1  [2025-07-09 21:47:59.711393962 +0200 CEST] POST /global-protect/login.esp HTTP/1.1 135 512 11443, taskid 1094700, user lelson
• Authentication will be failing on firewall directly, instead of IDP. This can be seen in authd.log
2025-07-10 08:47:04.458 +0200 debug: pan_auth_cache_user_is_allowed(pan_auth_cache_allowlist_n_grp.c:789): user "XXX" is NOT in allow list of auth prof/vsys "GP_Auth_Profile/vsys1" 
2025-07-10 08:47:04.459 +0200 failed authentication for user 'XXX'. Reason: User is not in allowlist. auth profile 'GP_Auth_Profile', vsys 'vsys1', From: 1.1.1.1.
2025-07-10 08:47:04.459 +0200 debug: _log_auth_respone(pan_auth_server.c:311): Sent PAN_AUTH_FAILURE auth response for user 'XXX' (exp_in_days=-1 (-1 never; 0 within a day))(authd_id: 7382216541716955129)

**LOG_SIGNATURES**
• HTTP POST to /global-protect/login.esp resulting HTTP 512 errors

PAN-OS 9.1+
GlobalProtect

Attackers are crafting HTTP POST requests directly to /global-protect/login.esp, bypassing the expected HTTP GET request and SAML redirect to the IDP. This causes the authentication daemon (authd) to handle the request, which fails because the users are not in the allowlist.

This is expected behavior for scenarios where HTTP POST is used first, instead of HTTP GET

**PREVENTIVE_MEASURES**
1. Implementing threat signatures to prevent/block GP Portal/Gateway brute force attacks (e.g., TID 40017).
2. Utilizing resources to detect and prevent brute force attacks, such as those described in Palo Alto Networks Knowledge Base articles.
3. Consider disabling the GlobalProtect Portal login page.

Detecting Brute Force Attack on GlobalProtect Portal Page:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJ2CAK

How to Protect GlobalProtect Portal on NGFW from Brute Force Attack:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000010zEJCAY

Brute Force Signature and Related Trigger Conditions:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClmpCAC

How to disable the GlobalProtect Portal login page:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClbpCAC