How a Bug Bounty Hunter Turned a Forgotten Subdomain Into a Critical Find
Everyone else was hammering the main app. One researcher used Expose to map the company's real attack surface instead - and found the abandoned corner of it that turned a quiet afternoon into a critical report.

On this page
The crowd was all in one room
When a well-known fintech opened its public bug bounty program, the rush was predictable. Within hours, hundreds of researchers were pounding on the same front door: the flagship web app, the mobile API, the login flow. It's where the bounties live, and it's where the crowd always goes. Harper, a part-time bounty hunter with a day job in infrastructure, watched the submissions tracker fill up and decided to do the opposite of what everyone else was doing.
Her reasoning was simple and a little contrarian. A company's real attack surface is almost never just the polished product everyone is staring at. It's the sprawl - the marketing microsites, the staging servers someone forgot, the acquired startup's old infrastructure that got bolted on during integration, the dashboard a contractor stood up for a campaign three years ago and never tore down. The crowd fights over the well-defended front door. The interesting bugs live in the doors nobody remembers building. To find those doors, she didn't start with a scanner. She started with Expose.
Mapping the surface nobody documented
Harper's first goal wasn't to find a vulnerability. It was to build a complete, honest map of everything that belonged to the target organization - the kind of map the company itself probably didn't have. This is the part of security work that has nothing to do with exploits and everything to do with knowing what exists. You cannot test, or defend, an asset you don't know is yours.
She fed the company's primary domain and corporate name into Expose and asked it to expand outward - to surface the domains, subdomains, and infrastructure connected to the organization across the open record. The platform pulled together what was scattered across certificate transparency logs, passive DNS history, domain registrations, and archived references: the footprint as it actually existed, including the parts that had quietly fallen out of anyone's memory.
The map that came back was much larger than the bounty program's neat scope diagram suggested. Among the expected production assets were the ghosts:
- a staging subdomain whose name followed an internal convention, still resolving, still serving a login page;
- an entire cluster of infrastructure inherited from a startup the fintech had acquired two years earlier, never fully decommissioned;
- a marketing-campaign microsite on a look-alike domain, last meaningfully updated years ago;
- an old developer portal subdomain that certificate logs showed had been quietly renewed but never linked from anywhere.
None of this was hidden, and none of it was obtained by breaking in. Certificate transparency logs are public by design. Passive DNS is a matter of record. Expose's contribution was correlation and speed - assembling, in minutes, the picture of an organization's sprawl that would have taken a careful analyst days of cross-referencing, and surfacing the forgotten corners the crowd never thought to look for.
Staying inside the lines
Before she touched anything, Harper did the thing that separates a researcher from a trespasser: she checked scope. A bug bounty program's rules are not bureaucratic friction; they are the line between authorized testing and a crime. Some of what Expose surfaced was explicitly in scope. Some was explicitly out. And some sat in the gray zone of "assets owned by the organization" that the program's wording arguably covered but didn't name.
This is exactly where good-faith researchers protect themselves, and Harper was careful. The acquired-startup infrastructure and the forgotten developer portal were the most interesting targets, but they weren't named in scope. Rather than poke at them and argue later, she did two things. For the assets clearly in scope, she began testing. For the gray-zone assets - the ones that looked owned by the company but weren't enumerated - she paused and asked the program through the proper channel whether they were in scope, providing the evidence that tied them to the organization. Authorization first; testing second.
"The fastest way to turn a great finding into a legal problem is to test something you weren't authorized to touch," Harper said. "OSINT tells me what exists. The program rules tell me what I'm allowed to test. Those are two different questions, and you answer the second one before you act on the first."The door nobody had locked
The program responded quickly and, to their credit, confirmed that the acquired company's infrastructure had indeed come along with the acquisition and was considered in scope - they simply hadn't realized it was still live. That confirmation was the green light. Harper turned her attention to the forgotten developer portal subdomain, the one certificate logs showed had been silently renewed for years.
What she found there was the kind of thing that happens when an asset outlives the team that built it. The portal was running a version of its software that had been end-of-life for years, with a known, publicly documented authentication weakness that had been patched in the wider world long ago - but never here, because nobody remembered this server existed to patch it. Through it, she could reach an internal-facing interface that should never have been on the public internet at all. From the company's perspective, this was a quiet, wide-open side door into a building whose front entrance had armed guards.
Harper did exactly enough to responsibly demonstrate the issue and not one step more - confirming the access existed, documenting it carefully, and stopping well short of touching real data. The goal of a bug bounty is to prove a risk so it can be fixed, not to exploit it. Restraint is part of the craft.
A report that gets fixed, not argued
A vulnerability is only as valuable as the report that conveys it. Harper knew that a critical finding on a forgotten asset can trigger a frustrating internal argument - "is that even ours?" - that delays the fix and muddies the bounty. So she wrote the report to head that argument off before it started.
She structured it as a story the security team could follow and verify: here is the asset, here is the public evidence that it belongs to your organization (the Expose-sourced map, with the certificate and DNS lineage), here is the acquisition that brought it in, here is the end-of-life software it runs, here is the precise, minimal proof of the access it grants, and here is exactly what an attacker could do with it. By doing the attribution work up front, she turned a potential dispute into a one-line confirmation. The triage team didn't have to ask whether it was theirs; she'd already shown them, with sources.
The finding was confirmed as critical. The forgotten server was taken offline within hours and properly decommissioned. The acquired company's lingering infrastructure was audited and cleaned up - which almost certainly closed other doors no one had reported yet. And the report earned one of the program's higher payouts, not because the exploit was exotic, but because the discovery was: she'd found a serious risk the company didn't know it carried, on an asset it had forgotten it owned.
The lesson cuts both ways
The case is a clean illustration of an uncomfortable truth that applies to every organization, not just this one. The same open-source visibility Harper used to find the forgotten subdomain is available to anyone - including people with far worse intentions than collecting a bounty. Attackers do reconnaissance exactly this way, mapping an organization's real sprawl through public records before they ever send a packet. The forgotten developer portal would have been just as visible to a criminal as it was to Harper. The only question was who found it first.
For the fintech, the takeaway wasn't only "patch that server." It was the recognition that they needed to see their own attack surface the way an outsider does - continuously, not once. They began periodically running their own domains and corporate identity through Expose to enumerate everything tied to them, including the assets that arrive silently through acquisitions and the ones contractors stand up and abandon. You cannot defend the asset you've forgotten you own, and the inventory in someone's head is always smaller than the inventory in the public record.
Could you see your own attack surface the way a researcher does?
Expose maps the domains, subdomains, and exposed assets tied to an organization into one picture - the same forgotten corners attackers and bug hunters find first.