Secrets OAuth Entra ID : Détecter la Persistance T1098.003

Dans le paysage moderne des attaques cloud, la persistance silencieuse supplante les exfiltrations brutales. Lorsqu'un attaquant compromet un compte disposant de privilèges d'administration d'applications dans Microsoft Entra ID (rôle Application Administrator ou Cloud Application Administrator), il cherche immédiatement à pérenniser son accès sans éveiller les soupçons. La technique MITRE ATT&CK T1098.003 (Add OAuth App Credentials) constitue le vecteur de prédilection : elle consiste à injecter un nouveau secret client ou un certificat x509 au sein d'une application d'entreprise légitime ou d'un Service Principal existant.

Anatomie de l'attaque : La porte dérobée invisible

Contrairement à la création d'un nouveau compte administrateur immédiatement repérable dans les revues d'accès, la modification des informations d'identification d'une application tierce déjà approuvée hérite de l'ensemble des permissions Microsoft Graph de celle-ci (ex. Mail.ReadWrite, Directory.ReadWrite.All, Files.ReadWrite.All). L'attaquant n'a plus besoin d'interagir avec l'interface d'authentification interactive d'Entra ID : il utilise le flux OAuth 2.0 Client Credentials Grant directement depuis ses propres serveurs de commande et contrôle (C2), contournant intégralement les politiques de Conditional Access et le MFA utilisateur.

L'angle mort natif d'Entra ID

Par défaut, l'audit natif de Microsoft 365 enregistre les opérations d'ajout de clés dans le journal d'audit sous les événements Add service principal credentials ou Update application – Certificates and secrets management. Toutefois, ces événements sont noyés dans la masse des déploiements CI/CD automatisés et des renouvellements programmés de secrets. Sans corrélation contextuelle entre l'adresse IP d'origine, le compte exécutant (UPN interactif vs identité de charge de travail) et la durée de validité anormale de la clé (par exemple un secret configuré pour expirer dans 99 ans), cette porte dérobée reste indétectée pendant plusieurs mois.

Détection avancée par Advanced Hunting (KQL)

La requête KQL ci-dessous permet d'isoler en temps réel les ajouts de secrets applicatifs suspects en filtrant les déploiements légitimes de votre chaîne DevOps :

CloudAppEvents
| where ActionType in~ (
    "Add service principal credentials.",
    "Update application – Certificates and secrets management ")
| extend ActorUPN = tostring(RawEventData.InitiatedBy.user.userPrincipalName),
         ActorIP  = coalesce(IPAddress, tostring(RawEventData.InitiatedBy.user.ipAddress)),
         AppId    = tostring(RawEventData.TargetResources[0].id),
         AppName  = tostring(RawEventData.TargetResources[0].displayName)
| mv-expand Property = RawEventData.TargetResources[0].modifiedProperties
| where Property.displayName =~ "KeyDescription"
| extend KeyData = parse_json(tostring(Property.newValue))
| extend KeyType = tostring(KeyData[0].KeyType), EndUtc = todatetime(KeyData[0].EndDateTime)
| where not(ActorUPN endswith "svc-devops@akuity.eu" and ActorIP in ("51.144.0.0/14"))
| project Timestamp, ActorUPN, ActorIP, AppName, AppId, KeyType, EndUtc, ReportId

Remédiation automatisée avec Akuity SOC

Face à une détection positive, le temps de réponse est critique. La plateforme SOAR sans agent d'Akuity SOC neutralise la persistance en quelques secondes :

• Résolution de la friction : L'assistant IA in-app d'Akuity SOC analyse et décode les événements Graph API au sein du Ticket Panel unifié, éliminant tout risque d'exposition de données sensibles sur des parseurs web tiers.
• Riposte SOAR chirurgicale : Déclenchement en 1 clic de l'action revokeOAuthApp() depuis l'inventaire des éléments de preuve pour supprimer instantanément le secret injecté et révoquer les autorisations du Service Principal.
• Gouvernance & conformité : Validation préalable sous élévation MFA AAL2 obligatoire et consignation immuable de l'action dans le journal d'audit certifié conforme aux exigences NIS 2 et SOC 2 Type II.

Mini-FAQ technique

Pourquoi le Conditional Access ne bloque-t-il pas cette attaque ?

Le flux OAuth Client Credentials utilisé avec un secret d'application n'implique aucun utilisateur interactif. Les politiques d'accès conditionnel ciblant les identités humaines ne s'appliquent pas aux Service Principals, à moins d'activer spécifiquement les licences Workload Identities Premium et de configurer des politiques dédiées aux identités de machines.

Comment différencier une injection de secret malveillante d'un renouvellement Terraform ?

L'analyse repose sur le compte initiateur (compte nominatif vs Service Principal CI/CD), la plage IP source et les métadonnées de l'opération (validité atypique, absence d'association avec un ticket Jira/ServiceNow valide dans le pipeline SOAR).