Cross-account exfiltration path in a mid-market SaaS environment.
A representative engagement, with customer details anonymized. The customer is a B2B SaaS company in financial services; scope covered their public perimeter, web and API surfaces, and production AWS tenancy. The agent ran in review-before-exploitation mode — meaning every exploit attempt was paused for customer approval before it executed. The narrative below tracks the engagement from kickoff to validated remediation, in the form your team would see in the portal.
What was in, what wasn’t.
Engagement scope covered three surfaces: the customer’s internet-facing perimeter (47 hosts across two cloud tenancies and a co-located edge), their primary web application and authenticated API (one production domain plus a staging subdomain), and their AWS production account (265 cloud resources across IAM, S3, RDS, ECS, and Lambda).
Explicitly out of scope: third-party SaaS integrations, the customer’s development AWS account, employee endpoints, and the corporate network. Out-of-scope assets were configured as hard guardrails in the engagement agreement and enforced by the agent throughout the engagement window.
External entry to demonstrated impact.
The agent reached customer-data exfiltration in five transitions over three active testing days. The trace below shows the route taken; dashed edges are alternate paths the agent surfaced but the customer declined to execute.
The techniques below are MITRE ATT&CK references — the industry standard catalog of attacker behaviors.
The two criticals.
Each finding in the portal carries the technique, the evidence the agent collected, and the exact command or request that produced it. Two are summarized below; the rest are detailed in the engagement report.
Cross-account role-chain to customer-data S3
A deploy role used by the production CI runner held s3:GetObject against the customer-data bucket through an over-broad Resource: "*" policy clause inherited from a template. Combined with a stale Jenkins service-account credential reachable from a staging admin panel, an external attacker could traverse from public web to customer PII without ever entering the internal network.
Staging admin reachable from public internet, accepting reused credentials
The staging admin panel at auth.staging.<customer>.dev was reachable without VPN and authenticated against the same SSO realm as the production environment. Two service accounts authenticated successfully using credentials present in a public credential dump; one of those accounts granted the role escalation path described in F-019-001.
Closed in nine days, validated on the platform.
- D+1 Findings assigned in the portal
The customer’s security lead assigned F-019-001 to their platform team and F-019-002 to their IT/identity team, both directly in the portal. Internal tickets were created via the Jira integration with full evidence attached.
- D+4 F-019-002 remediated
Staging admin placed behind the corporate VPN; SSO realms separated for staging and production; the two exposed service accounts rotated and added to the credential-rotation policy. Targeted retest triggered from the portal confirmed the panel was no longer reachable from the public internet.
- D+9 F-019-001 remediated
The deploy role’s S3 grants were scoped to the specific deployment-artifact buckets it needed; the wildcard clause was removed from the policy template. The CI runner’s cached credentials were rotated and the runner was configured to refuse stale tokens. Retest run from the customer’s deploy pipeline via the API; the validation result was returned to their CI workflow as a structured response.
- D+11 Engagement closed; report issued
Executive summary and technical report issued to the customer’s security and engineering leads. Customer used the report as evidence in their SOC 2 Type II audit later the same quarter. Two follow-on retests were run against the same scope in the months that followed.
What the customer took away.
A complete penetration test delivered in 11 calendar days from kickoff, with the executive summary and detailed technical report their auditor required. Both critical findings were closed inside the engagement window, and remediation was validated by on-demand retest rather than by a return engagement three months later.
Beyond the deliverables, the customer retained portal access to the engagement for the duration of their audit window, giving their assurance team a live workspace rather than a static PDF. Identical findings did not reappear in their next two quarterly engagements.