Case Study: One Application in Scope, Two Attack Paths, and a Foothold Inside the Network

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.

Application-layer pivot. Publicly readable JavaScript source maps exposed internal backend URLs and pointed at a separate internet-facing development and test backend. Its finance and ledger APIs required no authentication, and a bulk export endpoint returned live payout records.

External to internal access. An internet-facing database with authentication disabled held the organization VPN credential store. FireCompass agents used that material to open a tunnel into the internal VPC and enumerate internal-only hosts.

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 estate. 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

About FireCompass

FireCompass is an agentic AI platform for automated penetration testing, red teaming, and attack surface management, spanning web applications, APIs, cloud, and infrastructure across external and internal environments. It discovers shadow assets and validates risk through safe exploitation and multi-stage attack-path analysis, delivering evidence-backed results with near-zero false positives and prioritizing what is actually exploitable. FireCompass can run fully autonomously or with expert-in-the-loop validation, holds a USPTO-awarded patent for its automated red teaming technology, and is trusted by Fortune 500 enterprises and recognized by industry analysts including Gartner, GigaOm, and IDC.

Hack Yourself Before AI Does