Executing Stolen Session Token Replay Attacks Against Pomerium Zero Trust Access Proxy Through Continuous Identity and Session Validation

Modern organizations increasingly use Zero Trust Network Access (ZTNA) architectures to provide secure access to internal applications without automatically trusting users or network locations.

Zero Trust follows the principle of "never trust, always verify", meaning that authentication and authorization decisions should continuously enforce access policies rather than assuming that an already-authenticated session remains trustworthy indefinitely.

Pomerium is an open-source identity-aware access proxy that can be used to protect internal applications through identity-based access policies.

However, if a valid authenticated session token is stolen, an attacker may attempt to reuse the token from another client to access a protected application.

This creates a session-token replay risk because the attacker may possess a credential that was legitimately issued to another user or session.

In this use case, Pomerium is deployed as the controlled Zero Trust access proxy on an Ubuntu Linux virtual machine inside an isolated VirtualBox laboratory.

A controlled protected web application is placed behind Pomerium.

A legitimate test user authenticates through the Zero Trust access layer and establishes a valid session. A controlled session-token replay scenario is then performed using a laboratory test token.

The assessment evaluates whether the Zero Trust architecture can identify abnormal reuse of an authenticated session and whether additional identity, session, and access-policy controls can prevent continued unauthorized access.

Open Policy Agent (OPA) is used to support policy-based authorization decisions. osquery provides endpoint and device-state information. Wazuh provides security monitoring, while OpenSearch is used for centralized investigation and event correlation.

After identifying the session-replay weakness, the access policy is strengthened using session controls and continuous identity validation. The same controlled token-replay scenario is then repeated to verify that unauthorized session reuse is prevented while legitimate users continue to access protected applications.

The complete Zero Trust workflow is: Protected Application → Pomerium Zero Trust Access → Legitimate Authentication → Session Establishment → Controlled Session Token Replay → Continuous Verification → Anomalous Session Detection → Access Restriction → Policy Remediation → Retesting → Zero Trust Validation

Pomerium is the real open-source Zero Trust access-proxy platform used in this project. It provides identity-aware access control for protected applications.

A user who successfully authenticates to a protected application receives an authenticated session. If the corresponding session token is stolen, an attacker may attempt to reuse that token from another client. Traditional authentication may consider the token valid because it was originally issued legitimately. A Zero Trust architecture should instead evaluate whether the current request, identity, session, device, and access context continue to satisfy the security policy.

The security problem is therefore:

The controlled attack scenario evaluates whether a stolen authenticated session token can be reused by another laboratory client to access a protected application.

The primary Zero Trust security concept is Continuous Verification.

A successful authentication event should not create unlimited trust. Instead, access should continuously depend on: Identity + Session + Device + Request Context + Access Policy -> Authorization Decision. The objective is to ensure that a valid token alone does not provide indefinite trust to an unknown or unauthorized client.

The secure processing flow is: