Connexion avec MFA : enquêter sur une session suspecte dans le SOC

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte signale une activité inhabituelle sur un compte. La connexion associée affiche une authentification multifacteur satisfaite. Avant de clore le dossier, le SOC doit vérifier ce que cette indication établit, puis examiner les actions réalisées dans les applications.

La démarche proposée ici s’applique à votre fournisseur d’identité et à votre stack de détection. Les exemples Microsoft Entra illustrent des comportements documentés ; les champs et les possibilités de réponse doivent être vérifiés dans votre environnement.

Séparer authentification, session et activité

Le NIST distingue l’authentification initiale de la session qui permet ensuite de continuer à utiliser un service. Cette continuité repose sur un secret de session, par exemple un cookie, sans imposer une nouvelle authentification à chaque interaction. Source : NIST SP 800-63B-4, gestion des sessions

MITRE ATT&CK décrit le vol de cookies de session comme une technique permettant d’accéder à un service sous une identité déjà authentifiée. Selon le mécanisme utilisé, leur réutilisation peut contourner certaines protections MFA. Cela justifie une hypothèse d’investigation, sans démontrer qu’un vol a eu lieu. Source : MITRE ATT&CK, T1539

Notre recommandation : organiser le dossier autour de trois questions. Quelle authentification est documentée ? Quelle session peut être reliée à l’activité ? Quelles opérations ont réellement été réalisées ? Une réponse solide à la première question laisse les deux suivantes à examiner.

Lire le détail de la MFA

Dans Microsoft Entra, les détails d’authentification indiquent les méthodes, leur résultat et les politiques appliquées. Une exigence MFA peut être satisfaite par une information déjà présente dans un token, sans nouvelle sollicitation de l’utilisateur à cet instant. Source : Microsoft, détails des logs de connexion

Microsoft précise aussi que ces détails peuvent être incomplets ou inexacts avant la fin de leur agrégation. Conservez l’heure de consultation et vérifiez à nouveau l’événement si un champ déterminant semble contradictoire. La même documentation décrit cette limite.

Pour chaque connexion retenue, relevez :

• l’identité stable du compte et l’environnement concerné ;
• l’application utilisée et la ressource demandée ;
• le résultat global et le détail des étapes d’authentification ;
• les horodatages avec leur fuseau ;
• les identifiants de requête et de corrélation disponibles.

Le Correlation ID d’Entra dépend de paramètres transmis par le client ; Microsoft n’en garantit pas l’exactitude. Utilisez-le avec les autres éléments du dossier. N’affirmez pas que l’utilisateur vient d’approuver une notification si les logs montrent seulement une exigence satisfaite.

Inclure les connexions non interactives

Une application peut obtenir ou renouveler un accès pour le compte d’un utilisateur en arrière-plan. Microsoft classe notamment l’utilisation d’un refresh token parmi les connexions non interactives. Limiter la recherche aux connexions interactives laisserait donc une partie de l’activité hors du périmètre. Source : Microsoft, connexions non interactives

Dans cette vue, plusieurs événements peuvent être regroupés sur une seule ligne. Ouvrez le détail pour retrouver les occurrences et leurs heures. Vérifiez aussi la signification de l’adresse IP : pour certains clients confidentiels, elle correspond à l’émission initiale du token plutôt qu’à l’origine de la demande de renouvellement.

Notre recommandation : construire une chronologie qui distingue authentification interactive, renouvellements et opérations applicatives. Notez les catégories effectivement collectées. Une période sans événement dans une catégorie ne décrit pas nécessairement toute l’activité du compte.

Examiner les opérations dans les applications

Cherchez ce que le compte a fait après l’accès : consultation de ressources sensibles, modification d’autorisations, export ou changement de configuration. Pour chaque opération, documentez la cible, le résultat et la source qui permet de l’établir.

Dans son guide consacré aux comptes de messagerie compromis, Microsoft recommande notamment d’examiner les règles de boîte aux lettres, les transferts, les méthodes MFA enregistrées, les consentements applicatifs et les rôles. Ces vérifications visent aussi les changements qui pourraient maintenir un accès. Source : Microsoft, réponse à un compte de messagerie compromis

Adaptez cette liste aux services réellement accessibles au compte. Une règle de transfert récemment créée demande une explication, mais peut correspondre à un besoin autorisé. Comparez son historique avec une demande vérifiable et confirmez le contexte par un canal approprié, distinct du compte potentiellement compromis.

Le lien doit rester explicite : même identité, même application, fenêtre temporelle cohérente et identifiants concordants lorsqu’ils existent. Sans lien de session fiable, écrivez « activité observée sur le même compte » et conservez l’incertitude sur son rattachement à la connexion.

Corréler sans recopier les secrets

OWASP recommande de tracer le cycle de vie des sessions et les opérations importantes, tout en excluant des logs les identifiants de session bruts utilisables comme secrets. La documentation propose un hachage salé pour permettre une corrélation sans exposer la valeur de session. Source : OWASP, journalisation des sessions

Notre recommandation : utiliser les identifiants de diagnostic non secrets fournis par les services. Évitez de copier cookies, tokens ou en-têtes d’autorisation dans un ticket ou un assistant IA. Si une collecte spécialisée doit préserver ces éléments, son stockage et ses accès exigent un cadre distinct et restreint.

Vérifier l’effet du confinement

La réponse doit préciser quels accès elle vise. Microsoft distingue les tokens d’accès, les refresh tokens et les sessions propres aux applications. Entra ne peut pas révoquer directement un cookie de session émis par une application ; celle-ci doit appliquer ses propres mécanismes. Source : Microsoft, révocation des accès

Cette documentation signale qu’un délai peut séparer la demande de révocation de la perte effective d’accès. Le comportement dépend notamment du type de token, de l’application et des mécanismes d’évaluation continue qu’elle prend en charge.

Notre recommandation : pour chaque mesure autorisée, consigner la cible, le responsable, l’heure, l’effet attendu et le contrôle de résultat. Coordonnez les actions côté identité et côté application avec leurs équipes responsables.

Une confirmation d’exécution dans la console ne suffit pas à démontrer que tous les accès concernés ont cessé.

Préservez les éléments utiles lorsque cela reste compatible avec l’urgence. Si le confinement doit passer en premier, notez les actions engagées et les preuves devenues indisponibles. Les perturbations possibles pour l’activité métier doivent faire partie de la décision.

Un exercice pour tester votre méthode

Exemple fictif : une connexion affiche une MFA satisfaite. Une règle de transfert inconnue apparaît ensuite sur la messagerie du même compte. L’utilisateur reconnaît sa connexion habituelle, mais conteste la création de la règle.

Le dossier doit alors distinguer ce qui est confirmé de ce qui reste à établir :

• la connexion et son détail d’authentification sont conservés ;
• la création de la règle est documentée avec sa destination et son auteur technique ;
• le rattachement à une session précise reste à confirmer ;
• l’hypothèse d’un accès non autorisé doit être examinée avec les autres explications ;
• les mesures décidées doivent être vérifiées dans les services concernés.

Dans un environnement de test autorisé, faites reconstruire ce parcours par un second analyste. Peut-il retrouver les preuves, comprendre les limites du rapprochement et vérifier le résultat du confinement ?

Le livrable attendu est une conclusion exploitable : activité expliquée, suspicion nécessitant une escalade ou compromission établie par les preuves disponibles. Ajoutez les éléments manquants et la prochaine décision attendue. La mention MFA garde ainsi sa place exacte dans l’enquête.