Some weeks the most useful work isn't the kind you get to show off. Before jumping back into offensive labs, I spent a long stretch putting my personal knowledge base back in order — an internal wiki where I archive every audit methodology, every test protocol, every technical sheet piled up since the start of my training. Only once that housekeeping was done could I get back to two much more concrete exercises: an exploitation chain against a vulnerable application, and a CTF centered on continuous integration.
Tidy up before you attack
Documenting as you go is easy to say and harder to keep up. After enough labs back to back, drafts pile up, sheets stay half-sorted, some case studies aren't even linked into the site's index yet. So I took the time to sort it all out: publish the pending sheets, clean up duplicate drafts, verify that every category (Pentest, Active Directory, Forensics, Network, GRC) points to the right pages, and rebuild the site to make sure no link pointed into a void.
It's a thankless exercise, but it pays off: a knowledge base you can no longer navigate is worthless, no matter how good the methodology it holds. And it's precisely with that base back on solid footing that I moved on to two new cases.
AWSGoat M2 — when a small flaw hides a bigger one
The first case involved AWSGoat's Payroll module, a deliberately vulnerable application. The starting point was classic: a login form letting a SQL injection slip through, enough to impersonate an account at an intermediate privilege level. Nothing extraordinary on its own — except that first foothold opened the door to a second, far more interesting problem: an identifier parameter, in a profile-update request, that was never checked against the logged-in user's session.
The result: from an intermediate account, it became possible to modify the information of a higher-privilege account — up to overwriting its password. Two flaws taken separately would have been annoying; chained together, they granted full takeover of the super-admin account, without ever knowing a single legitimate password. This kind of chaining is exactly why a "minor" flaw always deserves to be dug into fully rather than checked off as a side note.
CTF Wonderland — poisoning a pipeline
The second playground was a CTF built around Jenkins, Gitea and GitLab, where the goal was no longer to attack an application but the chain that builds and deploys it. Every challenge hid a secret in Jenkins' credential store, reachable only by managing to run code inside a pipeline you don't directly control.
The basic technique — injecting a stage into a Jenkinsfile and triggering a build via a pull request — was enough for two of the four challenges. The third called for a different approach: no trace in the repository's current state, but a secret forgotten somewhere in the Git history, found by sorting hundreds of commits chronologically to spot the intruder. The fourth resisted me: the mechanism linking a test pipeline to a production pipeline was still unclear by the end of the session, and I set it aside rather than force a shaky lead.
The most transferable lesson from these four challenges fits in one sentence: Jenkins' automatic secret masking in logs (****) only recognizes the exact raw value. Transform the data before displaying it — a simple encoding step — and it slips right through the filter unnoticed. A silly little trick, but one that says a lot about the difference between protection that checks a box and protection that actually holds up.
What I'm taking away
Tidying a knowledge base and poisoning a pipeline don't look like they have anything in common. Yet both exercises demand the same discipline: follow a thread all the way through, don't stop at the first explanation that seems good enough, and accept that a quarter of the work sometimes stays unfinished from one session to the next. The CTF continues, the knowledge base keeps growing — and that's exactly as it should be.