Case Study: Attack Chaining from an External Web Application to an Internal Network Foothold

Theoretical vulnerability criticality does not matter. Here is one attack chain our AI agents ran that explains why.

A Fortune 1000 organization put one public-facing back-office application in scope, in the tier that handles payouts and ledgers. Tested on its own, that application returned a short list of medium-severity findings.

FireCompass agents also tested the wider external attack surface the application sat on. Two independent attack paths came out of it.

Neither path required a novel exploit or a cracked password, only internet-facing assets that were reachable and unauthenticated, plus analysis that followed each finding to its conclusion. Here is the full case.

The case study

Outcome: a single public-facing back-office application became the launch point for two independent lateral movements, first sideways from one application to another, then across the network perimeter into the internal environment itself, ending in a validated foothold inside the internal VPC.

A framing note for accuracy. The two lateral movements below were discovered through different mechanisms off the same estate and the same public entry point. They are presented in the sequence an attacker would run them, an application-layer pivot first, an infrastructure-layer pivot second, rather than as a single mechanically linked chain. Each step was observed and validated; the internal foothold was reached, not inferred.

What the agents found

The entry point was a public-facing back-office web application in a Fortune 1000 organization, the tier that handles payouts, ledgers, and related money-movement workflows. On its own, it presented an authenticated single-page application behind a corporate identity provider, and a finding-by-finding review would have stopped at a handful of medium-severity observations. The agents kept going, and the same application became the pivot point for two separate escalations.

First, lateral movement from one application to another (application layer)

The public application shipped its JavaScript with source maps left publicly readable, and those maps had their embedded source content populated, meaning the full original source, not merely minified code, was downloadable by anyone. That source exposed the internal structure the front end talked to: backend base URLs, route names, and the location of a separate, internet-facing development and test backend belonging to the same domain. Following those leaked URLs, the agents reached that second backend’s finance and ledger APIs and found them entirely unauthenticated. A bulk export endpoint returned live records of real payouts, identifiers, amounts, statuses, and dates, with no credential required. In one hop, the agents had moved from the customer-facing application to a separate backend and were exfiltrating genuine financial data.

Second lateral movement, from the external surface into the internal network (infrastructure layer)

Service scanning of the same estate turned up a second internet-exposed host running a database with authentication disabled. That database was not an application data store; it held the entire backend of the organization’s self-hosted VPN platform: the enrolled employees’ TOTP seeds, RSA private keys, X.509 client certificates, the admin password hash, and the VPN’s cookie-signing secrets. With the seed and certificate material in hand, the agents reconstructed a valid VPN client configuration and generated valid one-time codes on demand, defeating the VPN’s multi-factor requirement not by bypassing it, but by holding the secrets that produce it, and established a real tunnel into the internal VPC. From inside, they enumerated hosts that are invisible from the internet: a Windows machine with Remote Desktop exposed, a second unauthenticated database carrying another block of employee VPN credentials, an internal line-of-business application, and an internal service publishing its full API schema through an open, unauthenticated Swagger interface. Separately, the harvested VPN admin-API token and secret granted full control of the VPN management plane, which would let an attacker inject new internal routes toward the payment and ledger subnets, placing the internal payout and refund services, otherwise firewalled from the outside, one hop away.

Attack path

Key takeaway

A single public application was enough to launch two independent lateral movements, and the more severe one never touched the application at all. Source maps left in production turn a front end into a map of the internal backend; an unauthenticated database that happens to hold VPN material turns an exposed port into a working key to the internal network, because possessing the secrets that generate one-time codes defeats multi-factor authentication as completely as disabling it. Neither pivot required a novel exploit or a cracked password, only assets that were reachable and unauthenticated. Strip source maps from production builds, treat every internet-reachable data store as requiring authentication by default, hold VPN credential material, especially TOTP seeds and certificate keys, to the same standard as the private keys they effectively are, and segment the internal network so that a single tunnel does not place remote-access services, management planes, and additional credential stores all within one reach.