External Penetration Testing Case Study: Direct Server Access Bypassed the SSO Gateway

This black box external penetration test checked whether a B2B service provider’s support-management application could only be reached through its SSO and MFA access gateway after an infrastructure migration. It couldn’t: external reconnaissance found an additional public route to the server, requests sent there did not pass through the gateway, and some application functions did not independently require a verified user context.

Engagement	Details
Scope	External infrastructure, access gateway, and administrative web application
Approach	Black box, with no user accounts or architecture documentation
Effort	5 tester-days, plus 1 tester-day for retesting
Retest	Direct addresses, auxiliary ports, alternative hostnames, and the legitimate SSO workflow

Key takeaways

• The official application address behaved as expected, and the test did not identify a way to bypass MFA within that login flow.
• A direct public route to the server skipped the access gateway, and the application assumed traffic had already been authenticated upstream.
• The demonstration stopped at retrieving one owner-created test record and performing one agreed status change.
• The first fix missed an auxiliary port left over from the migration, so the finding stayed open until remediation covered all interfaces and the final retest confirmed closure of the assessed bypass routes.

What did the client need tested?

A B2B service provider made its support-management application available to employees through an access gateway.

The official application address required single sign-on and multi-factor authentication. Following an infrastructure migration, the organization commissioned an external penetration test to verify that the application could only be reached through this approved access path.

The testers received no user accounts or architecture documentation. The authorized scope consisted of agreed domains and address ranges, and active testing was restricted to organization-owned assets.

What did the external penetration test find?

The official application address behaved as expected. Unauthenticated users were redirected to the identity provider, and the assessment did not identify a way to bypass multi-factor authentication within that login flow.

External reconnaissance revealed an additional public route to the server hosting the application.

Requests sent directly to that endpoint did not pass through the access gateway.

The application assumed that incoming traffic had already been authenticated upstream. Some functions therefore did not independently require a verified user context.

The login mechanism worked, but it was not a mandatory route into the application.

After the finding was reported, the system owner created a test record. From an external connection without an SSO session, the testers retrieved that record and performed an agreed status change.

The demonstration stopped there. No customer-document review, bulk ticket export, or attempt to compromise the server’s operating system was performed.

Why didn’t previous scanning find the SSO bypass?

Previous scanning targeted the official application hostname. The scanner reached the login page, while the direct server endpoint was absent from the target inventory.

This was not an issue that inherently required manual detection. The underlying gap was incomplete coverage of the external attack surface and the assumption that protecting the public hostname protected every route to the application.

For where scanning ends and penetration testing starts, see penetration testing vs vulnerability scanning.

How was the gateway bypass fixed and retested?

The first change restricted access to the server’s main interface.

Retesting found that an auxiliary port left over from the migration still exposed the same application. The finding therefore remained open.

The complete remediation covered all interfaces. The origin server accepted traffic only from the approved intermediary, with authenticated communication between the two layers.

The application was also changed to reject requests lacking a correctly verified user identity, rather than relying solely on where the request appeared to originate.

Initial containment was applied on the day of notification. The full architectural change was completed within four business days.

The final retest covered direct addresses, auxiliary ports, alternative hostnames, and the legitimate SSO workflow. It confirmed closure of the assessed bypass routes without making a broader claim that the entire infrastructure was secure.

Each finding’s retest status is recorded in the report, as in section 7 of our sample penetration test report.

Key takeaway

An authentication gateway protects an application only when alternative access paths cannot bypass it. Both the network boundary and the application’s handling of identity must enforce that assumption.

Need the same test for your external perimeter?

This engagement was a black box test of external infrastructure, an access gateway, and an administrative web application: 5 tester-days, plus 1 tester-day for retesting. For what an attacker can reach once inside, our Active Directory penetration testing case study starts from a standard domain account, and our guide to internal vs external penetration testing compares the two.

External tests at Pentestica are quoted individually in tester-days; see how tester-days translate into a fixed price, or request a pentest quote with your domains, address ranges, and any recent migrations.