Deux connexions trop éloignées : détecter l'impossible travel
Le défi
Toutes les connexions au tableau de bord de Brightmoor ont réussi ce matin, chacune avec le bon mot de passe et sans aucun échec pour attirer l'attention. C'est bien là le problème : un mot de passe volé produit un succès parfaitement propre. La seule chose qu'une connexion valide ne peut pas falsifier, c'est d'être à deux endroits à la fois. Un compte s'est connecté depuis sa ville habituelle puis, quelques minutes plus tard, depuis l'autre bout du monde, avant de revenir. Lisez le journal de connexion et nommez le compte compromis.
Ce que tu vas apprendre
- Expliquer pourquoi un mot de passe volé ne produit que des succès propres
- Utiliser la géolocalisation dans le temps, et non le succès ou l'échec, comme signal
- Repérer un compte dont la ville change d'une distance infranchissable en quelques minutes
- Séparer les sessions de l'utilisateur légitime de celles de l'attaquant, entremêlées
- Lister les défenses : MFA, alertes d'impossible travel, liaison de session
Compétences testées
Prérequis
- Lecture d'événements de logs tabulaires
- Notions de géographie mondiale
Comment ça marche
Dès qu'un attaquant possède un mot de passe valide, ses connexions réussissent exactement comme celles du propriétaire. Compter les échecs ou les verrouillages ne donne rien, car il n'y en a aucun.
Ce qu'un identifiant valide ne peut pas falsifier, c'est la localisation. Un même compte ne peut pas se connecter depuis deux villes distantes de plusieurs milliers de kilomètres à quelques minutes d'intervalle. Corréler les lieux de connexion successifs de chaque compte avec le temps écoulé entre eux fait ressortir une distance qu'aucun trajet réel ne pourrait couvrir.
Ici, un compte alterne entre sa ville d'origine et une ville située à l'autre bout du monde, à quelques minutes d'intervalle. Ces sessions lointaines sont celles de l'attaquant, entremêlées avec celles de l'utilisateur légitime qui n'a jamais quitté son domicile.
Erreurs fréquentes
- Chercher les connexions échouées. Chaque ligne a réussi : l'attaque se cache dans des succès propres.
- Signaler un compte qui a simplement une autre ville d'origine. Être à Accra ou à Lisbonne est normal : sauter d'une ville à l'autre à quelques minutes d'intervalle ne l'est pas.
- Répondre avec la ville ou l'IP de l'attaquant. La question demande quel compte a été compromis.
- Passer à côté de l'entremêlement. L'utilisateur légitime continue de travailler depuis chez lui entre les sessions de l'attaquant, c'est pourquoi les deux villes apparaissent pour un même compte.
Comment s'en protéger
Faites en sorte qu'un mot de passe seul ne suffise pas et surveillez les sessions qui se téléportent.
- Exigez l'authentification multifacteur, pour qu'un mot de passe volé ne donne pas l'accès.
- Mettez en place la détection d'impossible travel : signalez ou exigez une vérification renforcée lorsque les connexions successives d'un compte dépassent une vitesse de déplacement réaliste.
- Liez les sessions à des signaux d'appareil et de réseau pour qu'une session existante ne puisse pas être reprise depuis un nouveau pays, et déclenchez une alerte à la première connexion depuis un nouveau pays.