Leaked Asana PAT: revoke the token, not the user

An Asana Personal Access Token does not need a password prompt or an MFA challenge. It is a standalone credential that carries one user’s access into the API, and it keeps working wherever it ends up, including a public repository or a CI log.

How the attack works

The token leaks, then an attacker uses it from a host that has never been the owner’s device, calling the API rather than the web app. The token rapidly lists workspaces, teams, and every project the owner can read, a programmatic sweep unlike interactive browsing. It then bulk-exports tasks, custom fields, and comments across dozens of projects, including a confidential roadmap, and finally fetches attachment download URLs and stages the files off-platform. In ATT&CK terms this is T1552, Unsecured Credentials, paired with T1213, Data from Information Repositories, and T1567 for the exfiltration.

Why it works

The token inherits everything its owner can see, so every read is technically authorized. The deviation is behavioral: a fast programmatic sweep across many projects from a never-seen source, against an owner who normally works interactively on a managed device. A PAT with no expiry and broad project visibility, sitting in a leak-prone location, turns one mistake into a full export.

How to fix it

Revoke that specific token in Asana, which kills its API access immediately without disrupting the legitimate user. Do not chase a password reset or an IP block, which a standalone token shrugs off. Then scope the export from the audit log filtered to that token and window, because membership shows what was readable, not what was read. For the class, inventory all PATs, enforce expiry and least-visibility, add secret scanning to repos and CI, and move automation to scoped OAuth or service apps.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse the surgical revoke, scope the export from the audit log, and harden the PAT fleet.