Le simulateur d'attaques EntraGUARD : 35 attaques connues, rejouées en lecture seule
Un score de conformité indique combien de contrôles passent. Il ne dit pas si un attaquant entre réellement. Le simulateur d'attaques EntraGUARD répond à cette seconde question : il rejoue 35 attaques connues Entra ID & Microsoft 365 contre le tenant réel, en lecture seule stricte, et indique quels chemins sont viables.
Pourquoi un simulateur en plus de l'audit
Un audit mesure la posture contrôle par contrôle. C'est précis, défendable, et c'est exactement ce qu'attend un référentiel. Mais un décideur demande rarement « combien de contrôles passent » ; il demande « est-ce qu'on peut entrer ». Ce ne sont pas les mêmes questions. Un tenant peut bien scorer sur le papier et exposer malgré tout un chemin d'attaque complet, de bout en bout — et un seul chemin viable suffit à un attaquant.
Le simulateur relit les constats comme le ferait un attaquant. Au lieu d'une liste de réglages, il déroule une kill-chain : accès initial, puis persistance et escalade, puis les faiblesses de configuration qui élargissent la surface. Chaque scénario répond à une question brute — « ce chemin fonctionne-t-il contre ce tenant, aujourd'hui ? »
Lecture seule par construction
C'est le point le plus important : le simulateur ne mène aucune action sur le tenant. Il n'envoie jamais de hameçonnage, ne déclenche jamais de push MFA, ne crée jamais d'objet, ne modifie jamais un réglage. Chaque scénario est évalué uniquement à partir de la configuration et de l'état lus via la même application Graph en lecture seule que l'audit utilise déjà. Ce qu'il rejoue, c'est le raisonnement d'une attaque contre la configuration réelle du tenant — pas l'attaque elle-même.
Cette contrainte rend le simulateur sûr à exécuter sur un tenant de production en pleine journée, et c'est aussi sa limite assumée : lorsqu'un signal n'est réellement pas observable en lecture seule, l'étape est marquée indéterminée plutôt que devinée.
35 scénarios sur trois phases
Le catalogue est regroupé par phase de kill-chain, et chaque attaque peut être activée ou désactivée avant une exécution :
| Phase | Exemples |
|---|---|
| Accès initial | AiTM / vol de session, hameçonnage par device code, password spray, authentification héritée, MFA fatigue, fournisseur d'identité externe malveillant, comptes sans MFA, utilisateurs à risque non traités. |
| Persistance & escalade | Consent phishing, shadow admin, abus de compte break-glass, credentials de service principal, rôles privilégiés permanents, groupes assignables aux rôles, invités privilégiés, Golden SAML / fédération, secrets d'application à risque, permissions Graph de prise de contrôle. |
| Configuration & exposition | Contournement d'accès conditionnel, abus cross-tenant, applications sans propriétaire, redirect URI dangereuses, consentement utilisateur permissif, création d'apps par les utilisateurs, aucune protection de base, invitations d'invités ouvertes, pas de workflow de consentement admin, aucun accès conditionnel, groupes dynamiques exploitables, partage anonyme SharePoint / OneDrive. |
Ce que produit une exécution
On sélectionne les attaques, on lance : chaque scénario est rejoué à tour de rôle — l'écran les fait défiler un à un, exactement comme l'audit, sans figer la page. Rien d'autre n'est affiché pendant l'exécution ; à la fin, le résultat apparaît : un score d'exposition global sur 100 et le nombre de chemins d'attaque viables parmi les scénarios exécutés.
Chaque scénario porte son propre verdict — chemin d'attaque viable, attaque interrompue ou indéterminé — un sous-score d'exposition, et, lorsque le chemin est rompu, le point de rupture exact : le contrôle qui l'a stoppé. Ce détail fait toute la différence entre « vous avez échoué ce scénario » et « c'est votre MFA résistant au hameçonnage qui l'a stoppé, conservez-le ».
Historique et restitution
Chaque exécution est conservée dans un historique dédié, filtrable par période, chaque entrée affichant son score, son nombre de chemins viables et son nombre de scénarios. Ouvrir une exécution montre la kill-chain complète de chaque scénario, et l'exécution s'exporte en PDF de marque — le même traitement en marque blanche que les rapports d'audit. Le tableau de bord fait aussi remonter la dernière simulation sous forme de carte, pour que le score d'exposition côtoie le score de conformité.
Comment le lire à côté de l'audit
Les deux sont complémentaires. L'audit est la mesure exhaustive, alignée sur les référentiels ; le simulateur est le résumé, vu de l'attaquant, qui fait atterrir l'audit en réunion. Une bonne habitude : présenter d'abord le score d'exposition et le nombre de chemins viables, puis utiliser l'audit pour expliquer pourquoi chaque chemin est ouvert et quoi corriger. Les points de rupture indiquent quels contrôles déjà en place font leur travail — à nommer, car une défense qui fonctionne est rarement mise en avant.
Un seul chemin viable, c'est le titre. Un score de 62/100 est abstrait ; « 18 chemins d'attaque viables, et voici le premier étape par étape » ne l'est pas. Ouvrez sur le chemin, gardez le score comme courbe de tendance.