Az - Conditional Access Policies / MFA Bypass

Support HackTricks

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:

  1. 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.

  2. 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:

roadrecon auth -u -r -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokrns-stdout


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:

SELECT appId, displayName FROM ApplicationRefs WHERE publicCLient = 1 ORDER BY displayName ASC

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:

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Find more information about this kind of attack in the following page:

Az - Pass the PRT


Get all the policies

roadrecon plugin 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.

Invoke-MFASweep -Username <username> -Password <pass>

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..

Import-Module 'C:\Users\Administrador\Desktop\Azure\Modulos ps1\donkeytoken' -Force

Test each portal if it's possible to login without MFA:

Test-MFA -credential $cred -Verbose -Debug -InformationAction Continue

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:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

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:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl


Support HackTricks

Last updated