This blog post focuses on bypassing Microsoft Defender for Cloud Apps (MDA) App Control. This bypassing method is one scenario of four that allows you to bypass session proxy. There are a few ways to restrict and prevent agent impersonation and this post does not describe the ways.

Microsoft Defender for Cloud Apps and Azure AD, including the Conditional Access App Control provides a platform to detect, defend, and mitigate cloud risks, security issues, and much more.

First, it’s important to mention that the following scenario checked on a few environments using Microsoft Defender for Cloud Apps Conditional Access App Control. Second, the scenario is one of four bypass scenarios for MDC. Third, there are ways to mitigate the issues in all of the scenarios.

Note: The next post will be focused on detection and mitigation with MDA and Microsoft Sentinel.

Session Proxy in a nutshell

By integrating MDA into your Conditional Access policies, you can redirect user sessions to Cloud apps through MDA. The MDA acts as a reverse proxy and gives the option to govern that session and all the traffic that comes through this session.

It’s important to note that in order to do the “Cloud Application Reverse Proxy”  through MDA, the App must be accessed via Azure AD if a cloud application is available by other means, such as a user account and password coming from another identity provider then Azure AD.

When integrating with Azure AD Conditional Access, you can configure apps to work with Conditional Access App Control. It allows you to quickly and selectively enforce access and session controls on your organization’s apps based on any condition in Conditional Access.

The conditions define to who a Conditional Access policy is applied. After you’ve determined the conditions, you can route users to Defender for Cloud Apps, where you can protect data with Conditional Access App Control by applying access and session controls. Conditional Access App Control enables user app access and sessions to be monitored and controlled in real-time based on access and session policies. The Defender for Cloud Apps portal uses access and session policies to refine filters further and set actions on a user.

Conditional Access App Control Use Cases

MDA and App Control can be implemented in many scenarios, from the discovery method to the DLP scenario. Microsoft has made available a whitepaper detailing 20 use cases for using a cloud app security broker through Microsoft Defender for Cloud Apps.

The following use cases its part of the use cases mentioned in the whitepaper:

1. Discover all cloud apps and services used in your organization
2. Assess the risk and compliance of your cloud apps
3. Govern discovered cloud apps and explore enterprise-ready alternatives
4. Enforce DLP and compliance policies for sensitive data stored in your cloud apps
5. Ensure safe collaboration and data sharing practices in the cloud
6. Enforce adaptive session controls to manage user actions in real-time
7. Record an audit trail for all user activities across hybrid environments
8. Detect threats from privileged accounts
9. Identify and revoke access to risky OAuth apps
10. Capture user activities within custom cloud on-premise apps

Note: the whitepaper link is available at the reference

Session Control in Action

Creating a session policy with Conditional Access App Control enables you to handle and manage user sessions by redirecting the user through a reverse proxy instead of directly to the specific App. All user requests and responses go through Defender for Cloud Apps (MDA) rather than directly to the App.

When a session is protected by proxy, all the relevant URLs and cookies are replaced by Microsoft Defender for Cloud Apps (MDA). For example, if the App returns a page with links whose domains end with myapp.com, the link’s domain is suffixed with something like *.mcas.ms, as follows:

You may also see the following domains in the transparency logs:

• *.ms
• mcasproxy.*
• *.-rs-mcas.ms
• *.rs-mcas.ms
• *.-rs2-mcas.ms
• *.rs2-mcas.ms
• *.admin-mcas.ms
• *.mcas.ms

Access Controls – Many organizations that use session controls for cloud apps to control in-session activities also apply access controls to block the same native mobile and desktop client apps, thereby providing comprehensive security for the apps.

You can block access to native mobile and desktop client apps with access policies by setting the Client app filter to Mobile and desktop. Some native client apps can be individually recognized, while others that are part of a suite of apps can only be identified as their top-level App. For example, apps like SharePoint Online can only be recognized by creating an access policy applied to Office 365 apps.

Session Controls – While session controls are built to work with any browser on any significant platform operating system, we support Microsoft Edge, Google Chrome, Mozilla Firefox, or Apple Safari. Access to mobile and desktop apps can also be blocked or allowed.

App Connectors – By using API Connectors, the information gathered by MCAS can be extended to the application services supporting this kind of API connection. It’s almost apparent that most of Microsoft’s SaaS-based apps are supported in this scenario. On the website, the following applications supporting API connections are mentioned:

• Office 365
• GCP
• ServiceNow
• Salesforce
• AWS
• Workday
• and more

What can be discovered depends on the functionality being provided by the manufacturer of the App.

Use Conditional Access App Control

Conditional Access App Control acts as a reverse proxy redirecting the end-user session to Microsoft Defender for Cloud Apps (MDA) to monitor activities in real0time. This allows for more granular control over the session and the conditions laid out within the conditional access policy assignments.

There are three choices for this control that uses signals from MCAS to perform actions:

• Monitor Only that can log and audit activities within the session. This takes no action against the session. Monitoring data can be reviewed within MDA for compliance or other security reasons and then converted to an appropriate custom session policy.
• Block downloads that can block download, cut, copy, and print documents. This can be used to prevent data exfiltration from unmanaged devices.
• A custom policy uses policies created within MDA to enforce actions. This can include almost any access or session policies MDA  is capable of configuring, such as enforcing usage of sensitivity labels or DLP or blocking access entirely.

Known limitations

• A proxy can be bypassed using an embedded session token – It’s possible to bypass the proxy in cases where the application embeds the token within the links. An end-user can copy the link and access the resource directly in that case.
• A parameter change can bypass a proxy – It’s possible to bypass the defined session policy by modifying parameters. For example, it’s possible to alter the URL parameters and mislead the service to bypass the proxy and enable a download of a sensitive file.

Behavior

If a user to whom the CA policy is applicable goes to https://sharepoint.microsoft.com on an unmanaged device (or not compliant device), the session is redirected to MCAS. This can be seen by the URL being referenced, in my case: https://domain.access-control.cas.ms/aad_login

The first page a user sees is a custom page with a company brand that tells the user that access to SharePoint Online is monitored. The user has the option to suppress this page for one week but is reminded again after that.

Bypass

Reverse proxies work by refereeing interactions between users and the applications they access. When users open managed applications and authenticate, the reverse proxy is inserted into the traffic path so that it can monitor data in transit and apply protections in real-time. In essence, the proxy is a code middleman that acts as the user for the App and virtualizes the session to act as the App for the user. Unlike MAM, a reverse proxy preserves apps’ native user experiences.

In multiple authentication methods, a request header User-Agent value can be used to determine if user authentication will be performed. This is useful when you want to authenticate users using a known set of applications, usually browsers, and allow other applications through a reverse proxy.

Essentially, when you request a Web Page, a GET request for that page is sent to the server. This GET request contains several parameters such as the Host, Cookies, Security Headers, and many others. One of these parameters is the User-Agent, and it tells the server what type of client you are requesting the page from. This could allow the server to decide what to send based on the value in the User-Agent.

Generally, the reverse proxy allows devices to go through the SAML authentication process. As a result, authorized applications from all managed or unmanaged devices are redirected to the CASB proxy. But if you use Office 365 and authenticate via Azure Active Directory, this method is unsuccessful because the authentication is not redirected through SAML authentication.

When the User-Agent field is used, the critical element is the regular expression (regex) that performs the match.

• The “^” regex operator is not supported.
• Predefined regexes are provided for the most common browsers.
• When the field is empty, all User-Agent values match
• You can create a custom regex by directly editing the field
• Multiple regexes are allowed

The User-Agent request header is a character string that lets servers and network peers identify the application, operating system, vendor, and version of the requesting user agent.

A browser’s User-Agent string (UA) helps identify which browser is being used, what version, and which operating system. Like all other browsers, a Chrome-based browser sends this information in the User-Agent header every time it makes a request to any site or any app. When feature detection APIs are unavailable, use the UA to customize behavior or content to specific browser versions.

A user agent is a string of data, including browser name, version, operating system, and device type, that your browser sends to every website you connect with to help it customize the content display to your device. Because the user-agent offers a range of information on every website visitor, marketers often use the user-agent data to cross-verify their ad traffic against their targeting criterion. For example, checking whether the device type is mobile to pass the traffic as valid for a mobile ad campaign. However, the user-agent can be manipulated through a tactic called user-agent spoofing.

In user-agent spoofing, bad actors modify elements of the user agent string to obfuscate their traffic details. For example, making high traffic volumes from a single device look like lots of individual advertising engagements from multiple devices.

How to Bypass

By setting a user agent string in your browser, you can bypass the protections offered by the Microsoft Defender for Cloud Apps Proxy. The actions that can be bypassed are copy, paste, download, etc.

The user agent string can be used via User-Agent Switcher Plugin or User-Agent Switching in Browser. To bypass, run the following actions.

Open your web browser and use the Chrome user agent switcher as part of the developer tools. Open them by clicking the Menu button and choosing More Tools → Developer Tools. You can also use the F12 key on your keyboard.

Then, you can choose a specific User-Agent browser and string. The most important is the string, and you can use the strings already checked for this scenario on the strings below.

Note: Because this setting is temporary. It only works when the Developer Tools panel is open and only for the current tab. So the best way is to change the user agent on the browser config or flag option or use a user agent switcher. 

TIP: You can create a specific user agent or download and install the extension ‘User-Agent Switcher for Chrome’

Notes:

• Create a user agent string using user agent strings from the User-Agent strings.

• Set the new user agent as active within the extension.

• Navigate to any protected services by Microsoft Defender for Cloud Apps.

• Observe that you are now accessing the regular site and are not going through the Microsoft Defender for Cloud Apps Proxy.

User Agent Strings

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Powerpoint/1.4.00.35564 Chrome/85.0.4183
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.4.00.35564 Chrome/85.0.4183.121
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.4.00.35564 Chrome/85.0.4183.121 Electron/10.4.7 Safari/537.36
• Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.3.00.5153 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)
• Mozilla/5.0 (iPhone; CPU iPhone OS 15_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148

TIP: You can replace the App that the Proxy Session doesn’t use, and then the bypassing will occur. You can make it even easier and go to the page of one of the many services that show your User-Agent: https://suip.biz/?act=my-user-agent

Spoof MDA App Proxy with Burp Suite

In addition, you can do the same test we burp suite through the following actions:

• In Burp Suite, go to the Proxy → Options tab, and find the Match and Replace section. There are already several rules for replacing User-Agent to emulate requests from various devices.
• You can include existing rules or create a new one. To create a new one, click the “Add” button.
• For “Type,” select “Request header”.
• For the “Match” field, specify 1 ^User-Agent.*$
• In the “Replace” field, enter the value that will replace the HTTP header of the user agent – use the same strings as before
• In the “Comment” field, enter any comment to remember what this title is for quickly
• Check the “Regex match” checkbox

References

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3nibJ

https://docs.microsoft.com/en-us/defender-cloud-apps/troubleshooting-proxy-url

https://docs.microsoft.com/en-us/cloud-app-security/enable-instant-visibility-protection-and-governance-actions-for-your-apps#how-it-works

https://user-agents.net/

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html