Az - Conditional Access Policies / MFA Bypass
Basic Information
Azure Conditional Access policies are rules set up in Microsoft Azure to enforce access controls to Azure services and applications based on certain conditions. These policies help organizations secure their resources by applying the right access controls under the right circumstances. Conditional access policies basically defines Who can access What from Where and How.
Here are a couple of examples:
Sign-In Risk Policy: This policy could be set to require multi-factor authentication (MFA) when a sign-in risk is detected. For example, if a user's login behavior is unusual compared to their regular pattern, such as logging in from a different country, the system can prompt for additional authentication.
Device Compliance Policy: This policy can restrict access to Azure services only to devices that are compliant with the organization's security standards. For instance, access could be allowed only from devices that have up-to-date antivirus software or are running a certain operating system version.
Conditional Acces Policies Bypasses
It's possible that a conditional access policy is checking some information that can be easily tampered allowing a bypass of the policy. And if for example the policy was configuring MFA, the attacker will be able to bypass it.
Device Platforms - Device Condition
It's possible to set a condition based on the device platform (Android, iOS, Windows, macOS), however, this is based on the user-agent so it's pretty easy to bypass. Even making all the options enforce MFA, if you use a user-agent that it doesn't recognize you will be able to bypass the mFA.
Locations: Countries, IP ranges - Device Condition
Of course if this is set in the conditional policy, an attacker could just use a VPN in the allowed country or try to find a way to access from an allowed IP address to bypass these conditions.
Office365 Client Apps
You could indicate that if clients access Office 365 apps from the browser they need MFA:
To bypass this, it's possible to pretend you log-in into an app from a desktop application (like to Microsoft Teams in the following example) which will bypass the protection:
As Microsoft Teams app has a lot of permissions, you will be able to use that access.
You can find the ID of more public applications with predefined Office365 permissions in the database of roadtools:
This attack is specially interesting because by default public Office365 applications will have permissions to access some data.
Other apps
By default, other apps created by users won't have permissions and could be private. However, users could also create public apps granting them some permissions.
A potential scenario where a policy is set to require MFA to access an application when the user is using a browser (maybe because it's a web application and therefore it will be the only way), if there is a proxy application -an application allowed to interact to other apps on behalf of users-, the user could login in the proxy application and then through this proxy application login into the initially MFA protected app.
Check the Invoke-MFASweep and the donkeytoken techniques.
Other Az MFA Bypasses
Ring tone
One Azure MFA option is to receive a call in the configured phone number where it will be asked the user to send the char #
.
As chars are just tones, an attacker could compromise the voicemail message of the phone number, configure as the message the tone of #
and then, when requesting the MFA make sure that the victims phone is busy (calling it) so the Azure call gets redirected to the voice mail.
Compliant Devices
Policies often asks for a compliant device or MFA, so an attacker could register a compliant device, get a PRT token and bypass this way the MFA.
Start by registering a compliant device in Intune, then get the PRT with:
Find more information about this kind of attack in the following page:
Az - Pass the PRTTooling
Get all the policies
MFASweep is a PowerShell script that attempts to log in to various Microsoft services using a provided set of credentials and will attempt to identify if MFA is enabled. Depending on how conditional access policies and other multi-factor authentication settings are configured some protocols may end up being left single factor. It also has an additional check for ADFS configurations and can attempt to log in to the on-prem ADFS server if detected.
Donkey token is a set of functions which aim to help security consultants who need to validate Conditional Access Policies, tests for 2FA-enabled Microsoft portals, etc..
Test each portal if it's possible to login without MFA:
Because the Azure portal is not constrained it's possible to gather a token from the portal endpoint to access any service detected by the previous execution. In this case Sharepoint was identified, and a token to access it is requested:
Supposing the token has the permission Sites.Read.All (from Sharepoint), even if you cannot access Sharepoint from the web because of MFA, it's possible to use the token to access the files with the generated token:
References
Last updated