Il n'est pas facile de repérer les tentatives de connexion malveillantes
Récemment, nous avons enquêté sur un comportement suspect dans un environnement où l'authentification sans mot de passe Azure a été mise en place. L'enquête a été motivée par le fait que plusieurs utilisateurs ont été confrontés à des invites inattendues de l'application Authenticator. A leur décharge, aucun des utilisateurs n'est tombé dans le piège ou n'a laissé entrer l'attaquant.
Ce type d'événement, connu sous le nom de MFA Fatigue, est routinier et attendu par les organisations, grandes et petites. Les attaquants tireront parti de cette technique d'ingénierie sociale pour inciter les utilisateurs à accepter les invites d'authentification push (cette technique a été utilisée avec succès lors d'attaques récentes, notamment par Uber).
Ce scénario s'est avéré particulièrement difficile à étudier en raison des enregistrements associés aux invites sans mot de passe qui ont échoué.
Les limites des capacités d'enregistrement compliquent les enquêtes
Le suivi des tentatives de connexion malveillantes est crucial pour la protection des environnements cloud et n'est possible qu'en surveillant les journaux cloud disponibles. Bien que Microsoft et d'autres fournisseurs de cloud publient des schémas de journaux et proposent des accords de niveau de service (SLA) pour la livraison des enregistrements, il existe encore plusieurs problèmes qui affectent les journaux cloud :
- Les types d'événements d'enregistrement sont souvent mal documentés, voire pas documentés du tout.
- Certaines des valeurs et des identifiants enregistrés sont internes au fournisseur cloud et leur signification n'est pas claire.
- De nouveaux types d'enregistrement sont ajoutés, des types d'enregistrement sont retirés et les formats d'enregistrement sont modifiés sans que les consommateurs en soient informés.
Tout cela complique la surveillance et la réponse aux incidents, et laisse les consommateurs de cloud dans l'incertitude quant à l'exhaustivité des enregistrements et au rattrapage des changements inopinés - il devient donc difficile d'enquêter sur les invites sans mot de passe qui ont échoué à partir des données enregistrées.
Un examen plus approfondi de la découverte et de l'atténuation des échecs de connexion sans mot de passe dans Azure
Authentification sans mot de passe
Pour ceux qui ne connaissent pas, l'authentification sans mot de passe est une option solide pour atténuer le risque que les utilisateurs créent des mots de passe non sécurisés. Il existe plusieurs façons d'activer l'authentification sans mot de passe dans Azure. Dans l'environnement étudié, l'application Microsoft Authenticator a été utilisée.
Pour s'inscrire à l'authentification sans mot de passe, les utilisateurs finaux doivent suivre les étapes de configuration détaillées suivantes. Une fois que l'utilisateur est inscrit à cette méthode, il peut saisir son nom d'utilisateur dans l'invite de connexion Azure, puis sélectionner l'option "Utiliser une application à la place" :
L'utilisateur reçoit alors un numéro à saisir dans l'application mobile pour terminer la procédure :
Si le nombre correspond, l'utilisateur est authentifié. Tout en étant raisonnablement sûre, cette méthode n'oblige plus les utilisateurs à créer et à mémoriser de bons mots de passe, ce qui améliore considérablement la convivialité.
Enquête
Dans le passé, nous avons surveillé différentes façons de configurer le MFA dans Azure, y compris l'utilisation de l'authentification sans mot de passe avec Microsoft Authenticator comme deuxième facteur (c'est-à-dire lorsque l'utilisateur est invité dans l'application après avoir saisi le mot de passe correct). Microsoft Authenticator comme second facteur nous observons l'une des deux erreurs suivantes dans les logs si les invites Authenticator sont abandonnées, ou si le code est incorrect :
- 50074 Une authentification forte est requise.
- 500121 Échec de l'authentification lors d'une demande d'authentification forte.
Par conséquent, nos requêtes de détection et de chasse ont été conçues pour rechercher ces codes d'erreur.
Cependant, lorsque l'application Microsoft Authenticator est configurée comme facteur unique, comme dans le cas de l'authentification sans mot de passe, nous avons vu l'erreur suivante lorsque l'invite a été abandonnée
- {"errorCode":1003033,"failureReason":"The remote NGC session was denied."}
Ce code d'erreur était nouveau, quelque chose que nous n'avions jamais vu auparavant et les recherches sur l'internet ne donnent pratiquement aucune information sur son origine. Le message d'erreur était également énigmatique, sans explication sur ce qu'est "NGC". Après quelques recherches, nous avons établi qu'il correspond au GUID D6886603-9D2F-4EB2-B667-1971041FA96B, qui est documenté comme "PIN Credential Provider".
En examinant le journal, nous avons constaté d'autres incohérences (voir la capture d'écran ci-dessous) :
- Les informations relatives à l'emplacement et à l'appareil (en rouge) ne sont pas renseignées.
- L'application et les informations sur les ressources (en bleu) sont manquantes.
- Les informations sur l'utilisateur (en violet) sont limitées. Les champs UserPrincipalName et UserDisplayName ne contiennent pas les valeurs attendues (l'adresse électronique et le nom complet de l'utilisateur). Au lieu de cela, la valeur UserId est présente dans les trois champs.
Le code d'erreur inhabituel et les données manquantes dans les enregistrements rendent difficile l'alerte sur ces événements et l'investigation appropriée.
Atténuation
Compte tenu de la difficulté que nous avons eue à enquêter sur cet incident, nous avons voulu partager les détails que nous avons recueillis avec la communauté de la sécurité afin que les praticiens de la sécurité puissent ajuster leurs requêtes de recherche pour détecter cette situation. À l'adresse Vectra , nous avons déjà mis à jour nos produits pour couvrir ce scénario.
La requête de chasse peut être aussi simple que l'extrait Kusto suivant, qui trouvera toutes les tentatives de connexion sans mot de passe qui ont échoué au cours des 30 derniers jours :
SigninLogs | where TimeGenerated > ago(30d) | where ResultType == 1003033
D'autres codes d'erreur liés à NGC peuvent également être intéressants :
À retenir :
- Lorsque vous introduisez de nouvelles méthodes d'authentification dans votre environnement, évaluez les journaux résultant des interactions avec ces nouveaux mécanismes. Recherchez les nouveaux codes d'erreur et les nouveaux types d'enregistrements qui pourraient devoir être pris en considération pour la surveillance et l'alerte.
- Les organisations qui surveillent les échecs de connexion sans mot de passe devraient envisager d'ajouter le code 1003033 à leurs requêtes de recherche. Prenez note des informations limitées qui sont disponibles avec cet enregistrement - vous ne pourrez pas utiliser le UserPrincipalName ou d'autres informations qui sont normalement disponibles dans les enregistrements du journal d'ouverture de session.
- Un appel aux fournisseurs de cloud (y compris Microsoft) : commencez à considérer les journaux comme une fonction de sécurité cruciale dont dépendent de nombreux acteurs. Documentez soigneusement les enregistrements, complétez les informations manquantes et annoncez les changements que vous apportez. Cela aidera vos clients et les fournisseurs de sécurité dans leur lutte pour assurer la sécurité de tous.
L'auteur tient à remercier Peter Schaub et Rey Valero pour leur aide dans la recherche de cet incident.