Français - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Conditional Access Policies / MFA Bypass

Soutenir HackTricks

Informations de base

Les politiques d'accès conditionnel Azure sont des règles établies dans Microsoft Azure pour appliquer des contrôles d'accès aux services et applications Azure en fonction de certaines conditions. Ces politiques aident les organisations à sécuriser leurs ressources en appliquant les bons contrôles d'accès dans les bonnes circonstances. Les politiques d'accès conditionnel définissent essentiellement Qui peut accéder à Quoi depuis Où et Comment.

Voici quelques exemples :

  1. Politique de risque de connexion : Cette politique pourrait être configurée pour exiger une authentification multi-facteurs (MFA) lorsqu'un risque de connexion est détecté. Par exemple, si le comportement de connexion d'un utilisateur est inhabituel par rapport à son modèle régulier, comme se connecter depuis un pays différent, le système peut demander une authentification supplémentaire.

  2. Politique de conformité des appareils : Cette politique peut restreindre l'accès aux services Azure uniquement aux appareils qui sont conformes aux normes de sécurité de l'organisation. Par exemple, l'accès pourrait être autorisé uniquement depuis des appareils ayant un logiciel antivirus à jour ou exécutant une certaine version du système d'exploitation.

Contournements des politiques d'accès conditionnel

Il est possible qu'une politique d'accès conditionnel vérifie certaines informations qui peuvent être facilement falsifiées, permettant un contournement de la politique. Et si, par exemple, la politique était configurée pour MFA, l'attaquant pourra la contourner.

Plateformes d'appareils - Condition d'appareil

Il est possible de définir une condition basée sur la plateforme de l'appareil (Android, iOS, Windows, macOS), cependant, cela est basé sur le user-agent, donc c'est assez facile à contourner. Même en rendant toutes les options obligatoires pour MFA, si vous utilisez un user-agent qu'il ne reconnaît pas, vous pourrez contourner la MFA.

Emplacements : Pays, plages IP - Condition d'appareil

Bien sûr, si cela est défini dans la politique conditionnelle, un attaquant pourrait simplement utiliser un VPN dans le pays autorisé ou essayer de trouver un moyen d'accéder depuis une adresse IP autorisée pour contourner ces conditions.

Applications clientes Office365

Vous pourriez indiquer que si les clients accèdent aux applications Office 365 depuis le navigateur, ils ont besoin de MFA :

Pour contourner cela, il est possible de prétendre que vous vous connectez à une application depuis une application de bureau (comme Microsoft Teams dans l'exemple suivant), ce qui contournera la protection :

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokrns-stdout

<token>

En raison des nombreuses autorisations de l'application Microsoft Teams, vous pourrez utiliser cet accès.

Vous pouvez trouver l'ID de plus d'applications publiques avec des autorisations Office365 prédéfinies dans la base de données de roadtools :

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

Cette attaque est particulièrement intéressante car, par défaut, les applications publiques Office365 auront des autorisations pour accéder à certaines données.

Autres applications

Par défaut, d'autres applications créées par des utilisateurs n'auront pas d'autorisations et pourraient être privées. Cependant, les utilisateurs pourraient également créer des applications publiques leur accordant certaines autorisations.

Un scénario potentiel où une politique est définie pour exiger MFA pour accéder à une application lorsque l'utilisateur utilise un navigateur (peut-être parce qu'il s'agit d'une application web et donc ce sera le seul moyen), s'il existe une application proxy - une application autorisée à interagir avec d'autres applications au nom des utilisateurs -, l'utilisateur pourrait se connecter à l'application proxy puis, via cette application proxy, se connecter à l'application initialement protégée par MFA.

Vérifiez les techniques Invoke-MFASweep et donkeytoken.

Autres contournements MFA Az

Sonnerie

Une option Azure MFA est de recevoir un appel au numéro de téléphone configuré où il sera demandé à l'utilisateur de envoyer le caractère #.

Comme les caractères ne sont que des tons, un attaquant pourrait compromettre le message de messagerie vocale du numéro de téléphone, configurer comme message le ton de # et ensuite, lors de la demande de MFA, s'assurer que le téléphone de la victime est occupé (en l'appelant) afin que l'appel Azure soit redirigé vers la messagerie vocale.

Appareils conformes

Les politiques demandent souvent un appareil conforme ou MFA, donc un attaquant pourrait enregistrer un appareil conforme, obtenir un jeton PRT et contourner ainsi le MFA.

Commencez par enregistrer un appareil conforme dans Intune, puis obtenez le PRT avec :

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

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

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Trouvez plus d'informations sur ce type d'attaque dans la page suivante :

Az - Pass the PRT

Outils

roadrecon

Obtenez toutes les politiques

roadrecon plugin policies

Invoke-MFASweep

MFASweep est un script PowerShell qui tente de se connecter à divers services Microsoft en utilisant un ensemble de credentials fournis et essaiera d'identifier si MFA est activé. Selon la façon dont les politiques d'accès conditionnel et d'autres paramètres d'authentification multi-facteurs sont configurés, certains protocoles peuvent finir par être laissés en facteur unique. Il dispose également d'une vérification supplémentaire pour les configurations ADFS et peut tenter de se connecter au serveur ADFS sur site s'il est détecté.

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

donkeytoken

Donkey token est un ensemble de fonctions qui visent à aider les consultants en sécurité qui ont besoin de valider les politiques d'accès conditionnel, les tests pour les portails Microsoft activés 2FA, etc..

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

Testez chaque portail s'il est possible de se connecter sans MFA :

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

Parce que le portail Azure n'est pas contraint, il est possible de rassembler un jeton à partir de l'endpoint du portail pour accéder à tout service détecté par l'exécution précédente. Dans ce cas, Sharepoint a été identifié, et un jeton pour y accéder est demandé :

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

Supposons que le jeton ait la permission Sites.Read.All (de Sharepoint), même si vous ne pouvez pas accéder à Sharepoint depuis le web en raison de MFA, il est possible d'utiliser le jeton pour accéder aux fichiers avec le jeton généré :

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

Références

Soutenir HackTricks
PreviousAz - AzureAD (AAD)NextAz - Dynamic Groups Privesc

Last updated