Tunnel Through GCP via JWT Forgery

What this lab covers

You examine how an application handles its tokens, escalate from an ordinary user to an administrator by exploiting the weakness in that handling, and use the resulting access to reach the cloud environment behind the application.

The chain then follows the familiar cloud path: metadata tokens from the instance, enumeration with the service account identity, and privilege escalation to reach data in managed services.

It is rated intermediate because it spans application and cloud layers. It suits testers and developers who issue tokens in their own products.

How JWT validation fails

A JSON Web Token carries claims and a signature. The security property depends entirely on the recipient verifying that signature with the correct key and rejecting anything that does not verify, because the claims themselves are readable and editable by whoever holds the token.

Failures cluster into recognizable categories. Accepting the algorithm declared in the token header allows an attacker to change it, including to none where the implementation permits it. Confusing symmetric and asymmetric algorithms allows a public key to be used as a signing secret. Weak signing secrets can simply be recovered offline, since verification is cheap to attempt.

Once claims can be forged, whatever the application trusts becomes attacker-controlled. If a role or administrator claim in the token drives authorisation decisions, escalation is a matter of editing a field and re-signing.

How to detect this in your own environment

Log token validation failures and alert on volume. An attacker probing algorithm handling or brute forcing a secret generates a distinctive burst of rejections before anything succeeds.

Watch for privilege changes that did not come through your own administrative flow. A session acting with administrative rights where no grant was recorded is a strong signal that authorisation is being asserted rather than checked.

On the cloud side the usual signal applies. Metadata access from an unexpected process and service account tokens used from outside the instance are where application compromise becomes visible as cloud compromise.

How to prevent it

Pin the expected algorithm at the verifier rather than reading it from the token, and reject anything else. This single change eliminates the largest family of JWT attacks.

Use strong random signing keys, rotate them, and verify issuer and audience claims as well as the signature. A token valid for a different service should not be accepted by yours.

Do not use claims as the source of truth for authorisation where the decision matters. Look up the user's current entitlements server-side, so a forged or stale claim does not decide access.

Real-world context

JWT implementation flaws have appeared repeatedly in libraries and applications, and the algorithm confusion and none-algorithm issues in particular have affected multiple widely used libraries over the years.

The cloud consequence is what raises severity. In a traditional application an authorisation bypass yields application access, and in a cloud-hosted one it can lead to the workload identity and from there to managed services holding the actual data.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API and T1548 Abuse Elevation Control Mechanism.

Applying this at work

• Check that your token verification pins the algorithm rather than accepting the one declared in the header.
• Confirm issuer and audience claims are validated, not just the signature.
• Review whether any authorisation decision in your applications is made from a claim rather than from a server-side lookup.
• Audit signing key strength and rotation for tokens your services issue.
• Add alerting on token validation failure volume, which is the earliest signal of probing.

Frequently asked questions

What is JWT algorithm confusion?

An attack where the verifier trusts the algorithm named in the token header. An attacker changes it, for example to none, or to a symmetric algorithm using a known public key as the secret, so a token they signed themselves verifies successfully.

Should authorisation decisions be based on JWT claims?

Not for decisions that matter. Claims can be stale even when the token is valid, and forged if validation is weak. Look up current entitlements server-side rather than trusting a field in the token.

How does an application flaw become a cloud compromise here?

Escalating within the application leads to code execution or access on the underlying instance, at which point the metadata service issues tokens for the attached service account and the attacker inherits that cloud identity.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.