Attack surface discovery case study: what a fintech could not see
You cannot protect a system you do not know you own. This fintech group kept its list of internet-facing systems in a spreadsheet, updated every quarter, and the list had fallen far behind reality. An investor review and a regulator’s security check were both coming up.
Automated sweep: DNS → certificate logs → cloud accounts → open ports → application fingerprint
A spreadsheet that could not keep up
The group ran an e-wallet, a peer-to-peer lending platform and a payment gateway. Its teams released new code often, it used four cloud accounts, and outside marketing agencies launched promotional websites for campaigns. Nobody owned the full picture of what was exposed to the internet.
The worry was specific. A forgotten test site or campaign page could give an attacker a way in, and from there a route towards the payment systems. The investors doing due diligence ahead of a funding round would ask for an inventory. So would the reviewers from OJK, Indonesia’s financial services regulator.
Looking from the outside
We looked at the group the way an attacker would: from the internet, with no inside knowledge. Our tools collected domains and subdomains from public DNS records and from certificate transparency logs (public records of every web security certificate issued). They swept IP addresses and open ports, identified web applications and APIs, and listed storage and services in the group’s AWS and Google Cloud accounts.
We then removed duplicates, worked out which team owned each asset and graded how exposed it was. The method follows the information-gathering stages of the OWASP Web Security Testing Guide and the Penetration Testing Execution Standard (PTES). The difference is that it keeps running every week, instead of once at the start of a test.
What turned up
The spreadsheet listed 180 assets. We found 612.
Of the 432 unknown assets, 41 were forgotten staging and development servers and 18 were agency campaign sites. Nine were cloud storage buckets open to the internet. Six were debugging interfaces serving live production data.
Some were serious on their own. A staging admin panel still accepted its default password, and logging in gave a valid session on the company’s shared single sign-on. Two internal tools for building software and searching logs (Jenkins and Kibana) were reachable without any login from an old block of IP addresses. Three forgotten subdomains ran outdated website software with known flaws that let an attacker run their own code on the server.
Closing the gap
Each unknown asset went to an owner, who decided whether to take it down, put it behind a login or add it to the regular testing scope. The client answered the investor’s security questionnaire with an export from the live inventory, and it had the same inventory ready for the OJK review.
Discovery now runs continuously. New subdomains and assets appear on the dashboard and are queued for vulnerability scanning automatically. A weekly report shows what appeared, changed or disappeared, so the security team no longer depends on the spreadsheet.
A company that grows through fast releases, several cloud accounts and outside agencies probably has a gap like this one, and it is worth closing before commissioning a penetration test.