Comment se défendre contre les attaques Identity-First : vol de session, hameçonnage AiTM et attaques par « connexion »

Les attaques identity-first sont désormais un problème de sécurité pratique parce que les attaquants n’ont plus toujours besoin de « s’introduire ». Les rapports de menaces de l’industrie décrivent systématiquement un glissement plus large des techniques d’intrusion coûteuses et ponctuelles vers l’abus à plus haut rendement d’accès de confiance, avec les tokens de session volés émergeant comme une option plus rentable que de nombreux chemins d’exploitation traditionnels. Les recommandations de Microsoft sur le vol de tokens décrivent le même pattern du côté défenseur : une fois qu’un token est volé et rejoué, l’attaquant peut obtenir l’accès même si l’utilisateur a déjà satisfait la MFA.

Ce tutoriel couvre les attaques identity-first que la plupart des équipes voient maintenant dans des environnements réels : le phishing adversary-in-the-middle, le vol de cookies de session, le rejeu de tokens, l’usurpation via les chemins de support et le style d’intrusion par « connexion » où l’attaquant abuse de l’identité de confiance et de l’accès SaaS plutôt que de malwares bruyants ou de force brute évidente. Les campagnes AiTM modernes sont particulièrement dangereuses parce qu’elles peuvent voler les identifiants et cookies de session en temps réel, rejouer la session, puis établir la persistance en modifiant les méthodes MFA ou les règles de boîte de réception.

À la fin, vous aurez un plan de durcissement pratique : identifier les comptes les plus susceptibles d’être ciblés, exiger une authentification plus forte, réduire les opportunités de rejeu de session, resserrer les workflows de support, ajouter une surveillance utile et répéter la réponse à un incident de session volée. Si vous planifiez aussi un déploiement plus large d’authentification plus forte pour le personnel, ce tutoriel se combine bien avec Comment déployer des passkeys d’entreprise et une MFA résistante au phishing.

Étape 1 : Identifier vos identités à plus haut risque

La façon la plus rapide d’améliorer la sécurité des identités n’est pas de durcir chaque compte également. C’est de commencer par les comptes que les attaquants sont les plus susceptibles d’exploiter en premier. Les recherches récentes sur les menaces cadrent le paysage actuel comme de « l’exploitation à haute confiance », ce qui est exactement pourquoi les identités admin, développeur, finance, helpdesk et tierces méritent un traitement spécial.

Construire un inventaire de risques

Créez un petit fichier qui mappe les types d’identité aux risques, privilèges et chemins d’abus probables.

admins:
  examples:
    - cloud-admins
    - idp-admins
    - email-admins
  risks:
    - tenant-wide compromise
    - privilege escalation
    - policy tampering
  priority: critical

developers:
  examples:
    - ci-cd-maintainers
    - repo-admins
    - secrets-managers
  risks:
    - source tampering
    - secret exposure
    - supply-chain abuse
  priority: high

finance_hr:
  examples:
    - payroll
    - accounts-payable
    - hr-ops
  risks:
    - bec-fraud
    - payroll diversion
    - pii exposure
  priority: high

help_desk:
  examples:
    - password-reset-agents
    - identity-support
  risks:
    - social-engineering pivot
    - mfa reset abuse
    - account recovery hijack
  priority: critical

third_party_access:
  examples:
    - contractors
    - vendors
    - managed-service-accounts
  risks:
    - weak endpoint hygiene
    - unmanaged-device access
    - supply-chain identity exposure
  priority: high

Mapper les permissions réelles, pas seulement les intitulés de poste

Ne supposez pas que « finance » est à haut risque et « chef de projet » ne l’est pas. Regardez les permissions réelles :

• qui peut réinitialiser la MFA
• qui peut approuver des paiements
• qui peut gérer le flux de messagerie
• qui peut créer des enregistrements d’applications
• qui peut accéder aux exports de données clients
• qui peut publier du code ou des artefacts

Un tableur ou fichier YAML suffit tant qu’il reflète la réalité.

Inclure les accès partagés et dormants

Inventoriez aussi :

• les comptes break-glass
• les appareils admin partagés
• les comptes de service avec connexion interactive
• les utilisateurs privilégiés dormants
• les comptes de support tiers encore activés

Vous devriez maintenant avoir une liste des identités qui méritent des contrôles plus forts avant le reste du personnel.

Étape 2 : Durcir l’authentification

L’objectif ici n’est pas « plus de prompts MFA ». C’est de rendre le phishing et l’abus de tokens matériellement plus difficiles. Les recommandations actuelles de Microsoft sur l’identité disent explicitement que les passkeys fournissent une authentification résistante au phishing que les attaquants ne peuvent pas hameçonner, intercepter ou rejouer, et recommandent des méthodes résistantes au phishing pour les comptes privilégiés et des politiques d’accès conditionnel qui imposent une authentification forte pour les applications sensibles.

Exiger la MFA résistante au phishing pour les bons utilisateurs d’abord

Commencez par les admins IdP, les admins cloud, les approbateurs finance, le personnel helpdesk, les développeurs avec des privilèges de production ou CI/CD, et les dirigeants fréquemment ciblés. Bloquez le SMS, l’appel vocal et la MFA push-only pour ces utilisateurs. Exigez des passkeys ou des clés de sécurité et fixez un objectif de migration de 90 jours pour les utilisateurs standard à haut risque.

Appliquer la confiance du dispositif pour les accès sensibles

Combinez une authentification plus forte avec des exigences de dispositif conforme et un accès conditionnel basé sur le risque, plutôt que de vous reposer uniquement sur l’authentification. Les applications à haute valeur devraient exiger des dispositifs gérés ou conformes, des vérifications de risque de connexion et une authentification renforcée pour les actions sensibles.

Traiter les passkeys et clés de sécurité comme la destination par défaut

Faites des passkeys la méthode préférée et des clés de sécurité le fallback fort pour les scénarios privilégiés ou de dispositifs partagés. Pour le plan d’inscription complet, les modèles de déploiement, la conception de récupération et les métriques d’adoption, consultez Comment déployer des passkeys d’entreprise et une MFA résistante au phishing.

Vous devriez maintenant avoir une base d’authentification priorisée qui augmente le coût du phishing et du rejeu d’identifiants pour les comptes qui comptent le plus.

Étape 3 : Réduire l’exposition au vol de session

Même une authentification forte ne suffit pas si l’attaquant peut voler ou rejouer la session résultante. Le playbook de vol de tokens de Microsoft est explicite : une attaque de vol de tokens fonctionne parce que l’attaquant réutilise un token émis pour un utilisateur qui a déjà complété la MFA. Les recommandations de Microsoft sur la protection des tokens disent aussi que la protection des tokens réduit le rejeu en exigeant des tokens de session liés au dispositif, bien que le support de plateforme actuel soit encore limité et que les applications basées sur navigateur ne soient pas supportées par ce contrôle aujourd’hui.

Raccourcir la durée de vie des sessions risquées quand c’est approprié

Ne raccourcissez pas chaque session aveuglément, mais vérifiez d’abord ces cas :

• consoles d’admin
• applications finance et paie
• outils de helpdesk et de récupération
• dépôts de documents sensibles
• administration email et gestion de boîtes aux lettres
• applications admin internes personnalisées

Une base simple de politique de session :

admin_apps:
  max_session_hours: 4
  sign_in_frequency_hours: 4
  require_reauth_for_sensitive_actions: true

finance_apps:
  max_session_hours: 8
  sign_in_frequency_hours: 8
  require_reauth_for_wire_or_payroll_changes: true

standard_apps:
  max_session_hours: 12
  sign_in_frequency_hours: 12
  require_reauth_for_profile_security_changes: true

Exiger la ré-authentification pour les actions sensibles

Ne vous reposez pas sur la session originale pour :

• les changements de méthode MFA
• la réinitialisation de mot de passe pour un autre utilisateur
• l’export de grands ensembles de données
• les changements de détails de paiement
• les changements de règles de boîte de réception
• l’attribution de rôles admin

Cela compte parce que les campagnes AiTM et de vol de tokens modernes pivotent souvent vers la persistance en changeant les méthodes MFA ou en ajoutant des chemins de récupération de compte après la compromission initiale. L’étude de cas AiTM de Microsoft a explicitement documenté des attaquants ajoutant une nouvelle méthode MFA après avoir rejoué une session volée et a recommandé d’exiger un re-challenge MFA pour les mises à jour MFA.

Utiliser la protection de token ou le binding quand disponible

Si votre plateforme d’identité supporte les tokens liés au dispositif ou la protection de tokens, activez-le d’abord pour les applications et dispositifs qu’il supporte réellement. Microsoft documente la protection de tokens comme un contrôle de session d’accès conditionnel qui réduit le rejeu en s’assurant que seuls les tokens de session liés au dispositif sont acceptés, et recommande de le déployer d’abord avec un groupe pilote et une validation en mode rapport uniquement.

Nettoyer le risque des navigateurs et extensions

La défense AiTM et contre le vol de session est plus faible si les utilisateurs naviguent depuis des endpoints non gérés pleins d’extensions risquées. Au minimum :

• restreignez les installations d’extensions pour les utilisateurs privilégiés
• bloquez les navigateurs non gérés des applications admin
• exigez des navigateurs sécurisés et supportés pour les accès sensibles
• vérifiez les paramètres de persistance de session des navigateurs

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": [
    "aapocclcgogkmnckokdopfmhonfmgoek",
    "ghbmnnjooekpmoecnnnilnnbdlolhkhi"
  ],
  "PasswordManagerEnabled": false,
  "BrowserSignin": 0
}

Vous devriez maintenant avoir des sessions de moindre valeur pour les attaquants, une protection plus serrée contre le rejeu de session et moins d’exposition basée sur le navigateur sur les comptes sensibles.

Étape 4 : Bloquer les workflows AiTM et de phishing

Les attaques AiTM réussissent parce qu’elles s’inscrivent dans des workflows d’apparence normale : lien email, message de fournisseur de confiance, page de connexion clonée, prompt MFA, session volée, puis rejeu silencieux. Le rapport de campagne 2023 de Microsoft a montré exactement ce pattern, incluant l’utilisation de fournisseurs de confiance, de services légitimes comme leurres, de fausses pages de connexion et MFA Microsoft, le rejeu de cookies de session et l’activité BEC subséquente.

Renforcer les contrôles email pour l’abus d’identité, pas seulement les malwares

Ajustez la stack email pour se concentrer sur :

• l’usurpation de fournisseurs et partenaires
• les leurres suspects à thème de connexion
• l’abus de plateformes de confiance comme les partages de fichiers cloud
• les domaines nouvellement vus et les chaînes de redirection bizarres
• la corrélation de campagne à travers plusieurs utilisateurs

Protéger les parcours de connexion

Pour les applications sensibles et les chemins SSO :

• n’utilisez que vos domaines IdP officiels
• réduisez les surfaces de connexion alternatives
• bloquez l’auth legacy directe quand c’est possible
• assurez-vous que les utilisateurs sont formés sur la vraie expérience de connexion
• favorisez les méthodes résistantes au phishing liées à l’origine pour que les fausses pages de connexion ne puissent pas compléter le flux avec succès

Mettre à jour l’éducation des utilisateurs pour correspondre aux attaques actuelles

Enseignez aux utilisateurs les patterns actuels, pas seulement « cherchez les fautes de frappe » :

• fausses étapes MFA sur une page de connexion clonée
• liens « ouvrir ce document » de vrais fournisseurs
• capture de mot de passe + MFA menant à une prise de contrôle de compte silencieuse plus tard
• usurpation de helpdesk ou support après le phishing
• abus de règles de boîte aux lettres et phishing interne de second stade

Détecter les comportements MFA et de session inhabituels

Ne vous reposez pas uniquement sur le « voyage impossible ». Les recommandations AiTM de Microsoft listent des détections plus riches comme la manipulation suspecte de boîte de réception, les propriétés de connexion inhabituelles, l’utilisation anormale de tokens, les tentatives possibles de phishing AiTM et les connexions risquées suivies de changements MFA.

Vous devriez maintenant avoir des contrôles plus forts autour des workflows de phishing qui précèdent typiquement le vol de session et le rejeu de tokens.

Étape 5 : Verrouiller les chemins admin et de support

Les attaquants adorent les workflows de helpdesk et d’admin parce qu’ils sont de confiance, urgents et souvent sous-documentés. Si le helpdesk peut réinitialiser la MFA après une vérification d’identité faible, votre politique de connexion sophistiquée est facile à contourner.

Créer un vrai standard de vérification du helpdesk

password_or_mfa_reset:
  allowed_identity_checks:
    - manager_callback_using_directory_number
    - verified_hr_attribute_plus_ticket_context
    - approved_video_or_in_person_check
  disallowed_identity_checks:
    - caller_knows_email_address
    - caller_knows_employee_id_only
    - incoming_phone_number_match_only
  extra_requirements:
    - second-analyst-approval_for_privileged_accounts
    - mandatory_case_notes
    - alert_to_user_after_reset

Isoler les sessions privilégiées

Pour l’accès privilégié, utilisez :

• des comptes admin dédiés
• des postes de travail à accès privilégié ou des navigateurs isolés
• pas d’email quotidien ou de navigation web depuis les sessions admin
• une fréquence de connexion plus courte
• des exigences de méthode plus fortes que les comptes du personnel normal

Ajouter des exigences de step-up pour les changements admin

Exigez toujours une authentification fraîche pour :

• les changements de rôle
• les changements d’enregistrement d’applications
• les modifications d’accès conditionnel
• les changements de transport de messagerie et d’accès aux boîtes aux lettres
• les paramètres de fédération et de fournisseur d’identité

Protéger les comptes break-glass

Les comptes break-glass devraient être :

• peu nombreux
• documentés hors ligne
• exclus uniquement là où c’est absolument requis
• surveillés en continu
• non utilisés pour les opérations quotidiennes

Vous devriez maintenant avoir moins de contournements faciles à travers les workflows de support et d’admin.

Étape 6 : Ajouter la surveillance et la réponse

Le but de la surveillance n’est pas de collecter plus de logs de connexion. C’est de repérer la compromission d’identité assez vite pour arrêter la persistance. Les recommandations de Microsoft sur la protection et le vol de tokens mettent l’accent sur la surveillance active, l’accès conditionnel basé sur le risque, l’analyse des connexions suspectes et la réponse rapide parce que le rejeu de tokens et l’activité AiTM nécessitent souvent plus qu’une réinitialisation de mot de passe pour être contenus.

Utiliser des détections meilleures que le voyage impossible seul

Le voyage impossible peut encore être utile, mais il est bruyant par lui-même. De meilleures détections incluent :

• propriétés de connexion inhabituelle
• connexion depuis un nouveau dispositif plus un nouveau réseau plus une application sensible
• même utilisateur depuis une combinaison IP et user agent inhabituelles
• méthode MFA ajoutée après une connexion risquée
• nouvelles règles de boîte de réception après une activité de session suspecte
• patterns de réutilisation de tokens suspects
• accès au courrier et aux fichiers immédiatement après une connexion avec des propriétés inhabituelles

Exemple KQL : méthode MFA ajoutée après une connexion risquée

let RiskyWindow = 4h;
let RiskySignins =
SigninLogs
| where TimeGenerated > ago(1d)
| where RiskLevelDuringSignIn in ("medium", "high")
| project UserPrincipalName, RiskySignInTime = TimeGenerated, IPAddress, UserAgent;
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add authentication method", "Update user", "Register security info")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| join kind=inner RiskySignins on $left.TargetUser == $right.UserPrincipalName
| where TimeGenerated between (RiskySignInTime .. RiskySignInTime + RiskyWindow)
| project TimeGenerated, TargetUser, OperationName, IPAddress, UserAgent

Exemple KQL : pattern suspect de réutilisation de session

SigninLogs
| where TimeGenerated > ago(1d)
| summarize
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated),
    IPs=make_set(IPAddress, 10),
    UserAgents=make_set(UserAgent, 10),
    Apps=make_set(AppDisplayName, 10)
  by UserPrincipalName
| where array_length(IPs) > 2 and array_length(UserAgents) > 1
| project UserPrincipalName, FirstSeen, LastSeen, IPs, UserAgents, Apps

Construire un playbook de réponse à la compromission d’identité

initial_actions:
  - revoke_active_sessions
  - block_sign_in_temporarily
  - require_password_reset_if_password_was_captured
  - investigate_mfa_method_changes
  - review_inbox_rules_and_forwarding
  - review_app_consent_and_tokens
  - review_recent_admin_actions

containment:
  - require_reauthentication_for_sensitive_apps
  - restrict_access_to_managed_devices_only
  - increase_sign_in_risk_enforcement

post_incident:
  - confirm_user_device_health
  - remove_attacker_added_mfa_methods
  - review_affected_contacts_for_follow_on_phishing
  - document_root_cause_and_detection_gaps

Les recommandations AiTM de Microsoft sont claires : la réinitialisation de mot de passe seule ne suffit pas quand l’attaquant vole une session et change les paramètres MFA ; la révocation de session et le retour en arrière des changements MFA faits par l’attaquant font partie d’une remédiation appropriée.

Vous devriez maintenant avoir une base de surveillance et un flux de réponse initial pour la compromission d’identité qui va au-delà des réinitialisations de mot de passe.

Étape 7 : Exécuter un exercice de simulation

Un exercice de simulation est l’endroit où vous découvrez si vos contrôles fonctionnent ensemble ou ne font que belle figure sur des slides. Utilisez des scénarios qui correspondent aux chaînes d’attaque identity-first actuelles.

Scénario 1 : du phishing au vol de session

# Scenario: Phishing to Session Theft

1. A finance user receives an email from a known vendor with a cloud-document link.
2. The link leads to a fake SSO login page and a fake MFA prompt.
3. The attacker captures the password, MFA challenge result, and session token.
4. Two hours later, the attacker replays the session from a new network.
5. The attacker creates inbox rules and tries to change payment details.

Questions:
- Which control should have blocked the initial sign-in?
- Which detections should fire after replay?
- Who revokes sessions?
- Who reviews inbox rules and outbound payment changes?

Scénario 2 : usurpation du support

# Scenario: Support Impersonation

1. An attacker calls the help desk posing as an executive traveling internationally.
2. They claim they lost their phone and cannot complete MFA.
3. They pressure support for a fast reset before a payroll deadline.
4. They ask to add a temporary recovery method.

Questions:
- What verification steps are mandatory?
- Can one analyst approve this alone?
- Is the user notified out-of-band?
- What extra control applies because the target is high risk?

Scénario 3 : token volé avec tentative de persistance

# Scenario: Stolen Token with Persistence Attempt

1. A developer's session is replayed successfully.
2. The attacker creates a new OAuth app consent and tries to add an MFA method.
3. They access source repositories and CI/CD settings.

Questions:
- Which detections should fire first?
- What gets revoked?
- Which secrets and tokens must be reviewed?
- How do you determine whether code or pipeline changes occurred?

Scorer l’exercice

Suivez :

• le temps de détection
• le temps de confinement
• si les sessions ont été révoquées
• si les changements MFA ont été trouvés
• si la politique du helpdesk a tenu
• si les communications étaient claires

Problèmes courants de configuration

Exiger la MFA mais pas la MFA résistante au phishing

Cela laisse les utilisateurs à haut risque exposés à la capture AiTM et au rejeu de tokens même si l’organisation croit que « la MFA est activée ».

Se concentrer sur les mots de passe mais pas les sessions

Les équipes réinitialisent souvent les mots de passe et s’arrêtent là, même si l’attaquant peut déjà avoir une session valide, un chemin de rafraîchissement ou une méthode MFA ajoutée par l’attaquant.

Traiter tous les utilisateurs de la même façon

Le durcissement identity-first fonctionne mieux quand vous priorisez d’abord les admins, le helpdesk, la finance, les développeurs et les accès tiers.

Utiliser le voyage impossible comme détection principale

Le voyage impossible aide, mais il manque trop de choses et génère trop de bruit pour être le seul signal de compromission d’identité.

Laisser les workflows de support et de récupération faibles

Une politique de connexion forte à la porte d’entrée peut quand même être contournée par une réinitialisation MFA faible, une récupération de compte ou une gestion break-glass faible.

Conclusion

Les attaques identity-first fonctionnent parce qu’elles abusent de la confiance qui existe déjà : utilisateurs de confiance, dispositifs de confiance, sessions de confiance, fournisseurs de confiance et processus de support de confiance. Les rapports de menaces de l’industrie décrivent ce glissement plus large comme des attaquants optimisant pour « se connecter » et un accès de confiance à plus haut rendement, tandis que les recommandations de Microsoft sur le vol de tokens montrent pourquoi un token rejoué peut vaincre des défenses qui s’arrêtent à la MFA initiale.

Si les ressources sont limitées, améliorez d’abord ceux-ci : exigez des méthodes résistantes au phishing pour les utilisateurs privilégiés, forcez des contrôles plus forts sur les applications sensibles, exigez la ré-authentification pour les changements de sécurité de compte, durcissez la vérification du helpdesk et déployez un playbook de réponse qui révoque les sessions et vérifie la persistance ajoutée par l’attaquant. Au fil du temps, l’objectif de maturité est simple : moins de méthodes hameçonnables, moins de sessions puissantes de longue durée, moins de chemins non gérés vers les applications sensibles et une réponse plus rapide quand une identité est abusée.

Pour un guide détaillé du déploiement d’une authentification résistante au phishing dans votre personnel, consultez Comment déployer des passkeys d’entreprise et une MFA résistante au phishing. Pour en savoir plus sur les tendances de ransomware basées sur l’identité qui motivent ces défenses, consultez Identity-Based Ransomware.