Leaked Access Tokens

What Is Leaked Access Tokens?

A personal access token acts as the account that created it. Present it and the API treats you as that developer, with no password and no second factor. Scope and expiry limit the damage; a classic token with broad organization access and no expiry has neither. You'll pick a token from a public gist, list an organization's private repositories, then clone one and push a commit back as its owner. You'll revoke it, reissue a fine-grained replacement limited to one repository, and turn on secret scanning and push protection.

What You'll Learn in Leaked Access Tokens

• Recognize why an over-scoped, non-expiring personal access token is dangerous: a single leaked copy grants broad, long-lived access to clone private repositories and push, all as the developer
• Trace how an attacker turns a token scraped from a public gist into real access by presenting it in an Authorization header to list private repositories and then cloning and pushing
• Respond to a leak correctly by revoking and rotating the token rather than just deleting the public copy, since anyone who already copied it keeps access until the token is killed
• Reissue a fine-grained, least-privilege token scoped to a single repository with a short expiry, instead of a classic broad token that grants sweeping access with no expiry
• Reduce exposure by enabling secret scanning and push protection so tokens leaked to gists, CI logs, or commits are flagged and blocked early

Leaked Access Tokens — Training Steps

1. Bob's gist harvester

   Bob does not read gists by hand. He runs a small scraper that pages the platform's public gist feed and scans every file for anything shaped like a credential. The feed is open to anyone, no account needed, so the whole stream of public gists is his to search.

2. Run the harvester

   Bob runs the scraper. It pulls the public gist feed and matches each file against its credential patterns. Most hits are dead, expired or disabled keys, but one is live: a Loomwick personal access token sitting in a developer's deploy gist.

3. Open the flagged gist

   Bob opens the gist the scraper flagged. The deploy helper is a gift: it carries the token in full, names the repository it targets, and shows exactly how it is used.

4. What the token can do

   Before using it hard, Bob asks the platform what the token is. He calls Loomwick's API with the token in an Authorization header, and the response describes the credential itself. It belongs to an ordinary developer, not an admin, yet the scopes are sweeping and there is no expiry.

5. List the private repositories

   Now Bob puts the token to work. He asks the API to list the organization's repositories, and the private ones come back alongside the public one. He has never held a Loomwick account. The token alone is enough.

6. Clone a private repo

   With the token, Bob clones a private repository straight to his own machine. The gist handed him both the credential and the exact repository it targets. The clone pulls down billing-core in full: source, config, and history.

7. Open the webhook file

   Read access is bad enough, but the token can write too. Bob opens a webhook file in the cloned repository, looking for a quiet place to add a line of his own.

8. Plant the change

   Bob adds a single line. Every billing event the service forwards now goes to his own collector as well as the internal ledger. It is a small, quiet change, the kind that slips through a busy review.

9. Commit the change

   Bob commits the edit. The message reads like a harmless forwarder tweak, but the diff quietly carries his exfiltration line.

10. Push as the developer

    Then Bob pushes the commit back to Loomwick over the authenticated repository URL. The platform accepts it: the token is treated as Maya, so the write lands on the default branch. A leaked token is not just read access. It carries the developer's full identity, including the power to change what ships.