Are Attackers "Passing Through" Your Azure App Proxy?

TL;DR - Azure app proxy pre-authentication set to Passthrough may unintentionally expose private network resources.
Microsoft’s Azure app proxy allows for publishing on-premises applications to the public without opening ports on a firewall and can use Entra ID for authentication.
For a demonstration setup, a Windows Server 2022 evaluation license was used on a VM with a basic website served via HTTP on port 80 in our private network.

A private network connector is installed on a system in your private network and connects outbound to Azure. Once installed and connecting outbound successfully, it should show up in your Azure Portal:

Once the connector is present, you can add your on-premises application to the app proxy, and there will be an option for “Pre Authentication.” This setting “defines how Private Network pre-authenticates users before providing access to the application on your private network,” according to Microsoft Help. Pre-authentication is set to “Microsoft Entra ID” by default:

The other option is “Passthrough.”

Basically, it is asking if you want the traffic to your published application to be authenticated via Microsoft Entra ID prior to forwarding traffic to your application. In the demo environment, two (2) applications were configured using the available options:
- MSENTRAID-redactedoutlook.msappproxy.net
- PASSTHROUGH-redactedoutlook.msappproxy.net
Both of the application URLs are pointing at the root of the same website on our VM.
A simple request to the root of the MSENTRAID URL is redirected to HTTPS:

This is because Microsoft requires a secure connection for authentication, and the application is published via plain HTTP. A second request to the MSENTRAID via HTTPS redirects to Microsoft for authentication:

No matter what relative path is requested, all resources are protected by Microsoft Entra ID authentication:

A simple curl request to the Passthrough URL to the same nonexistent directory results in a 404 from the VM and is not protected by Microsoft Entra ID authentication:

Using a more real-world scenario, let’s suppose the application at the root of the site was designed to use Entra ID for authentication (a sales quoting application) and uses a simple redirect to the application’s User-access URL (basically, it’s the Office 365 application launcher link where users will be automatically signed into the application without having to go to My Apps first).

Let’s also suppose the application on the same server accessible at /portal/ is an application that uses its own authentication scheme and is intended to be publicly accessible for customers. Passthrough may have been used in this scenario to make that application accessible to the public.
With Passthrough pre-authentication, there are no protections restricting access from the Azure app proxy side. Microsoft’s own documentation warns about Passthrough not giving the benefit of blocking anonymous attacks:

Passthrough pre-authentication is basically the equivalent of opening a port on your firewall to the private system.
While the intent may have been to have the sales quoting application on the root use the Azure User-access URL (and Entra ID for authentication), clients can use the customer portal, and other resources may be unintentionally accessible.
Forced browsing for content discovery is a trivial activity to perform, and each request to the MSENTRAID URL is met with a redirect for authentication:

On the other hand, each request to the Passthrough URL displays results from the VM itself. Sorted by HTTP response status code, we can see the customer portal was identified, as well as a few other interesting paths.

The /secure/ path prompts for HTTP Basic authentication:

A quick list of default accounts is used in Burp Suite’s Intruder tool to brute-force potential credentials such as admin:admin, test:test, guest:guest, demo:demo, etc.

Successful credentials for a default/test account were identified:

Weak credentials could be present and allow unauthorized access to data and/or applications. This scenario has been encountered with legacy app servers on many occasions and could be an entry point into your organization.