Leaked Credential, End to End thumbnail

Leaked Credential, End to End

By Richard Augenti

A developer committed AWS credentials to the `payments-api` repository four commits ago, and the file is still tracked on the team's Git server. Detect the exposure with gitleaks, revoke the credential, purge it from every commit with `git filter-repo`, and discover that the remote is still dirty the moment that separates fixing your copy from fixing the exposure. You will finish by adding a pre-commit hook and a CI gate, then proving they work by trying to reintroduce a credential.

Browse
Skill Level: Intermediate Duration: 60 min Secrets ManagementDevSecOps
Sign in to start

Free to browse. Takes about 60 minutes once you start.

Lab Overview

A developer on the payments-api team committed a staging deployment file containing AWS credentials. The commit is several commits deep in main, the file is still tracked, and the pipeline has no secret scanning.

In this lab you detect the exposure with gitleaks, remove the credential from both the working tree and the repository history with git filter-repo, and add the local and pipeline controls that stop it happening again. Along the way you hit the distinction that matters most in a real leak: rotating the credential comes first, because rewriting history does not un-leak anything that has already been cloned.

The credentials in this lab are fabricated. They match the AWS key format so scanners detect them, but they are not real and grant no access to anything.

What to Expect

  • Environment: a single Ubuntu machine you connect to over SSH, with git, gitleaks and the payments-api repository already installed. No cluster required.
  • Access: SSH credentials are generated for your session and shown in the workspace. They are destroyed when the lab ends.
  • Safe by design: the leaked AWS keys are fabricated. They are shaped like real keys so tooling behaves realistically, and they authenticate to nothing.
  • Progress: your work is not saved. If the lab expires or you quit, the machine and everything on it is destroyed.

What are hands-on labs?

A lab is a real environment, not a simulation. You get a live machine with the tooling already installed, a task taken from production work, and root access to take it apart. Nothing is mocked, nothing is multiple choice. It either works or it doesn't.

Real tooling

The same commands you would run at work, on a machine that is already set up for them. No screenshots, no sandboxed toy version.

Break it freely

Everything is disposable. When the clock runs out the environment is destroyed with everything in it, so there is no reason to be careful.

Useful on Monday

Built by engineers who run these systems in production. Skills you can apply to your own stack the same week, not exam preparation.

Browse labs