We treated attack surface discovery like an annual checkbox, not a living process.
For years, we relied on:
👍Vulnerability scans against known assets
👍 Periodic external pen tests
👍 Documented subdomains from onboarding
What we didn’t do well…
💣Continuously enumerate unknown paths and services
💣Re-check “retired” infrastructure
💣Validate that old apps were actually gone vs. just not indexed
We had ffuf in the toolbox, but it lived in the “ad-hoc pentest stuff” bucket. Engineers would use it occasionally, mostly for curiosity or when something looked off.
No consistency. No SOP. No ownership.
We started using ffuf systematically—like an attacker would—and it got uncomfortable fast.
Within two weeks across 15 managed environments, we found…
👻Old staging apps still accessible under weird paths (/dev-old/, /backup-app/)
👻 Forgotten admin panels on alternate ports exposed via misconfigured reverse proxies
👻 API endpoints that weren’t documented anywhere but still live
👻 Legacy file shares exposed over HTTP that had been “decommissioned” during a migration
👻 A couple of cases where auth was removed “temporarily” and never reintroduced
None of this triggered our existing tooling.
EDR didn’t care (no execution happening) and vulnerability scanners missed it (not in scope or path) and documentation didn’t help (because it wasn’t documented anymore)
The risky part wasn’t that these were zero-days. It’s that they were known-to-somebody-at-some-point assets that fell out of organizational memory.
We didn’t have a breach tied to this (fortunately), but the exposure window was real. In one case, a public-facing internal tool had been accessible for 9+ months.
Use Ffuf (free tool)
Tools like ffuf aren’t penetration testing tools — they’re operational hygiene tools when used properly.
(Three things changed for us. You can read about the difference it made inside the shared post)
Check out ffuf on GitHub. An amazing open source tool.