Breaking into a Major Bank

A bank's web application this time, and the brief points straight at debugging and monitoring endpoints developers forget to actually lock down before shipping to production. Same Nagli-hosted Bug Bounty Masterclass series, and this one's confirmed too, Wiz's own published benchmark data lists it as Bank Actuator, a Spring Boot actuator heapdump leak, based on a real critical finding at an actual financial institution where exposed debugging endpoints leaked credentials and internal secrets. Confirmed bounty on that one, $4,800.

So this is just a mimic of that real hunt so lets jump in.

Nothing sitting on the main page itself. Figured there had to be something more revealing hiding somewhere, so ran dir enum and turned up two more endpoints, /error and /health.

Two completely different error messages, one that said error outright, the other reading like a legitimate health-check API response rather than a generic failure page. Worth actually sitting with that for a second rather than just noting it and moving on, the status code on that request came back as 500, but the message it was showing didn't match what a 500 normally looks like, which on its own is the kind of mismatch worth remembering, a framework formatting its own errors in a very particular, recognizable shape rather than a generic server failure.

Nothing I could actually do with that by hand though, so rather than guessing blind at endpoint names one at a time, this called for an actual scanner built for exactly this kind of exposure. Ran nuclei against it.

Came back with a long list of Spring Boot actuator endpoint exposures, which also confirmed what that mismatched error page had been quietly hinting at the whole time, this was a Spring Boot app, and Spring Boot's actuator module is infamous for exactly this, a set of operational endpoints meant for internal monitoring that get left wide open to the entire internet more often than anyone building production systems would like to admit. /env caught my eye first, same as it always does, but reading through it this time didn't actually hand over anything usable.

What did matter was sitting right next to it in that same scan output, /actuator/heapdump. If you haven't run into one of these before, a heapdump is a complete snapshot of a running Java application's memory at one exact moment in time, not just what's written in a config file, but what the application is actually holding in memory while it runs.

That distinction matters more than it sounds like it should. Your source code can mask a password with asterisks, your config file can keep secrets encrypted at rest, but the JVM still has to decrypt every one of those values at some point to actually use them, and whatever's been decrypted recently is sitting in plaintext somewhere in memory. Database passwords and full connection strings, API keys and tokens for whatever third-party services the app talks to, encryption keys and certificates used to sign JWTs or secure traffic, none of it protected once you're looking at a raw memory snapshot instead of the source. Pulled the heapdump down and ran it through a couple of different analysis tools, though honestly a plain strings pass against the file was enough on its own to surface what mattered, and the flag was sitting right there in it.

Worth being honest about what actually made this one solvable, because it wasn't some clever exploitation technique, it was recon, specifically knowing that a weird-looking error page is worth fingerprinting rather than dismissing, and that Spring Boot actuators are a known, well-documented exposure class worth scanning for by name. Wiz actually ran AI agents against this exact challenge afterward as part of that same benchmark, and one of them solved it in just six steps, purely by recognizing the timestamp format and structure of that generic error page, pattern-matching it to Spring Boot instantly and going straight for /actuator/heapdump without wasting a single step anywhere else. Worth sitting with that for a second rather than brushing it off, the part of this bug that actually took real skill wasn't exploiting the heapdump once you had it, it was recognizing the stack fast enough from almost nothing to know exactly where to look.

Which is really the whole takeaway here, actuator endpoints, debug consoles, and monitoring routes left exposed in production aren't rare, they're one of the most common misconfigurations a modern framework ships with a sharp edge on, and finding them has almost nothing to do with writing exploit code and everything to do with fingerprinting a stack correctly and then actually knowing, by name, what that stack is famous for leaving open.

Happy hunting, see you in the next scope :)