A few weeks ago, I wrote about why so much of the external attack surface goes untested. Deep pentesting is expensive, so security teams concentrate on the assets they consider most critical, leaving much of the rest outside their pentest plans.
Research from Synack and Omdia found that organizations pentest about 32% of their attack surface on average, leaving roughly two thirds of it untested.
But what exposures might be hiding in the assets that never get tested?
In this piece, I want to make the problem concrete, using real findings from our AI pentesting runs. For each finding, I’ll start with the asset where the test began.
Would any of these have made your pentest shortlist?
A random external IP led to a transportation management system
The first exposure started on an operations reporting server at a large transportation company. It had no public hostname and was reachable only by its IP address, probably unintentionally. Yet from that serve, an attacker could reach an application used to direct and reroute live transportation activity.
The operations team had needs specific enough that no off-the-shelf product fit, so they built their own tools on this server. The system dated back to the late 1990s, with its main application running on Adobe ColdFusion.Homegrown tools like these rarely get the same security attention as commercial products, and these ones were more exposed than anyone realized.
The tools sat behind a login gateway that was supposed to redirect anyone without a session to the login page. But a specially crafted web address bypassed it. The gateway interpreted the request as a harmless stylesheet and let it through. The server behind it interpreted the same address as a request for the actual application.
Because the applications relied entirely on the gateway for authentication, a request without a login was treated as though it came from an authenticated employee.
That gave us access to live operational data, including details of what individual vehicles were carrying, as well as controls that could reroute them while in operation.
Of course, we did not execute those controls, since each action would write to live operations with no undo. Instead, we checked the protections that should have stopped such a request: anti-forgery tokens, authorization checks within the application, and origin checks. None was in place.
When the company blocked our initial route partway after the first AI pentest cycle, a variation of the same technique got through again.
A legacy reporting server opened the door to a PCI-scoped environment
For years, an analytics server at a global IT services company had been producing internal business reports. Teams depended on it, so it stayed in service while patch cycle after patch cycle passed it by. Its software was past end of life, and it sat in the backlog as a patch ticket with no owner.
From that one server, an attacker could take full control of a machine in PCI scope and potentially use it as a foothold into the internal network.
Getting there took five steps, starting with a single request and no credentials.
The server’s web service accepted XML messages that could be manipulated to make it read files from its own disk and return their contents. One of those files held the password for the server’s admin console.
The pentesting agent used that password to log in, deploy a web shell and gain system user privileges. It also provided access to two internal networks that were not properly protected by firewall or other security controls.
The same weakness was found on a sister server, raising the possibility that other systems were affected too. It also appeared on an unrelated system in another country, where it exposed a working service password.
A subsidiary’s registration server exposed a production database
The third asset belonged to a subsidiary of another large IT services group. The subsidiary operated its own platform, under its own brand and domain, separate from the parent company’s main environment.
The server had one job: register the software agents its customers install. Hardly an obvious pentest priority. Yet a single anonymous request exposed the superuser password for the subsidiary’s production database, potentially putting customer records and information about their systems at risk.
Acquired companies often retain their own infrastructure for years after the deal. Their systems work, customers depend on them, and folding everything into the parent’s environment is a project that keeps slipping. In the meantime, these assets can remain outside the inventory and security processes used by the parent company.
The flaw was similar to the previous case. The registration endpoint accepted XML, and an unauthenticated request could make the server read local files and return their contents in error messages.
The pentesting agents achieved access to files on that server. One was the application’s configuration file, containing the production database superuser password in plain text. The same password was also configured for a second database described as holding customer and customer-system tables.
With that level of database privilege, an attacker could potentially access or modify sensitive customer information, including details about the systems customers had connected to the platform.
The requests also reached the cloud provider’s internal metadata service, revealing account, cluster and network details behind the server.
The parent company told us its previous manual pentest had missed this attack path.
A supplier’s application opened a path to 14 other companies’ databases
At a global pharmaceutical company, a regional clinical-data application had been built by a third-party developer and published on the company’s regional web domain. From that one app, a single unauthenticated request reached a shared database server holding the data of 14 other companies, several of them pharmaceutical competitors.
The app was never brought in-house or held to the company’s development standards. Instead, it ran on shared hosting alongside other tenants, with security weaknesses that extended beyond the application itself.
From this one app, an unauthenticated SQL injection opened a path to a shared database environment containing 59 databases, including 14 belonging to other companies, several of them pharmaceutical competitors.
The entry point was an API parameter that the application decoded from base64 and passed directly into a SQL query without proper parameterization.
The database account had db_owner privileges, providing full read and write permissions. A linked server extended that access into the shared hosting environment. The SQL Server instance also had an enabled system administrator login.
The developer’s other applications on the same domain exhibited similar weaknesses.
Our customer had included this application in previous pentesting and red teaming exercises, which had uncovered other security issues. Yet those efforts had missed the attack path into the shared database environment.
None of the other companies’ data belonged to our customer. A flaw in a supplier’s application had become a potential route into its competitors’ records.
A demo with synthetic data exposed patient-record
A healthcare technology company kept a public demo of its patient platform on the internet. It held only synthetic patient data, but ran the same application code as production.
A demo without real patient data rarely makes the pentest shortlist, and it rarely gets the same monitoring as production. Yet for an attacker, a publicly accessible copy of production code offers an opportunity to look for weaknesses with relatively little scrutiny.
Testing revealed that a specially crafted unauthenticated request could list patient records across four institutions. With a low-privilege clinician account, the pentesting agents could also modify arbitrary patient records and generate patient-portal access tokens that never expired.
The first problem was a debug endpoint left in the shipped code. It exposed patient lists for one institution. By changing a sequential institution identifier, the agents could retrieve records associated with three more.
The second was missing object-level authorization. The API allowed a clinician account to read and overwrite patient records by their IDs, without checking whether that clinician was authorized to access them.
Finally, QA endpoints included in the application were protected only by checks in the browser. The same low-privilege account could use them to generate signed patient-portal tokens for any patient, with no expiry.
The company’s previous manual pentests had not uncovered these nine findings.
Covering the whole surface
These five assets were overlooked for different reasons. One was a homegrown tool without a hostname. Another was legacy infrastructure waiting for a patch. A third belonged to a subsidiary, a fourth to a supplier, and the fifth was a demo environment considered low-risk.
Each showed how an asset considered low priority could provide a path to critical systems and sensitive data.
When AI pentesting costs $5,000 to $15,000 per application, organizations still have to make difficult choices about what to test and how often. And if those choices keep bringing you back to the same familiar applications, you’re likely to miss the kinds of exposures we found here.
The goal is to make better use of your testing budget, so you can investigate more of your attack surface and revisit assets when the risk changes.
Getting there requires two things.
First, you need a deep understanding of the entire external attack surface, including asset relationships, technologies, and potential attack paths. That helps determine what deserves deeper investigation and how to approach it.
Second, AI pentesting needs to be efficient enough to scale. Organizations should be able to investigate more of their exposed assets within their existing budgets and revisit them as they change or when new threats emerge.
That’s the approach behind CyCognito. Full external discovery and continuous deterministic validation establish a baseline across the attack surface. Our Target Graph™ uses that context to direct AI pentesting where deeper investigation is needed, while keeping testing efficient enough to extend coverage and respond to changes.
The question for your organization is simple: how much of your attack surface are you actually testing, how often, and what happens to the assets that never make the list?
If you want to see what might be hiding in your untested attack surface, book a demo.
