Partager via

Investigation des applications compromises et malveillantes

  • Article

Cet article fournit des conseils sur l’identification et l’examen des attaques malveillantes sur une ou plusieurs applications d’un locataire client. Les instructions pas à pas vous aideront à prendre l’action corrective requise pour protéger les informations et minimiser les risques supplémentaires.

  • Conditions préalables requises : décrit les exigences spécifiques que vous devez respecter avant de commencer l’examen. Par exemple, la journalisation qui doit être activée, et vous devez disposer des rôles et des autorisations nécessaires, entre autres.
  • Workflow : affiche le flux logique que vous devez suivre pour effectuer cet examen.
  • Étapes d’examen : contient des instructions pas à pas détaillées pour cet examen spécifique.
  • Étapes d’autonomie : contient des étapes sur la façon de désactiver les applications compromises.
  • Étapes de récupération : contient des étapes de haut niveau sur la façon de récupérer ou d’atténuer une attaque malveillante sur des applications compromises.
  • Références : contient des documents de référence et de lecture supplémentaires.

Prérequis

Avant de commencer l’enquête, vérifiez que vous disposez des outils et des autorisations appropriés pour collecter des informations détaillées.

Outils requis

Pour un examen efficace, installez le module PowerShell suivant et le kit de ressources sur votre ordinateur d’enquête :

Workflow

Organigramme détaillé des étapes d’investigation.

Étapes d’investigation

Pour cette enquête, nous supposons que vous disposez d'une indication de compromission potentielle d'une application sous la forme d'un rapport d'utilisateur, par exemple les journaux de connexion de Microsoft Entra, ou d'une détection de protection de l'identité. Veillez à compléter et à activer toutes les étapes préalables requises.

Ce manuel a été créé en tenant compte du fait que tous les clients de Microsoft et leurs équipes d'enquêteurs ne disposent pas de l'ensemble des licences Microsoft 365 E5 ou Microsoft Entra ID P2 ou ne les ont pas configurées. Ce manuel met en évidence d’autres fonctionnalités d’automatisation si nécessaire.

Déterminer le type d’application

Il est important de déterminer le type d’application (multilocataire ou locataire unique) dès le début de la phase d’investigation pour obtenir les informations appropriées et nécessaires pour contacter le propriétaire de l’application. Pour plus d’informations, consultez Location dans Microsoft Entra ID.

Applications mutualisées

Pour les applications multi-locataires, l’application est hébergée et gérée par un tiers. Identifiez le processus nécessaire pour contacter le propriétaire et lui et signaler les problèmes de l’application.

Applications à locataire unique

Trouvez les coordonnées du propriétaire de l’application au sein de votre organisation. Vous le trouverez sous l’onglet Propriétaires dans la sectionApplications d’entreprise. Votre organisation peut également disposer d’une base de données contenant ces informations.

Vous pouvez également exécuter cette requête de Microsoft Graph :

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Vérifier Identity Protection - identités de charge de travail à risque

Au moment de l’écriture de ce guide, cette fonctionnalité est en préversion et des conditions de licence s’appliqueront à son utilisation. Les identités de charge de travail à risque peuvent être le déclencheur d’examen d’un Service Principal, mais elles peuvent également être utilisées pour approfondir d’autres déclencheurs que vous avez pu identifier. Vous pouvez vérifier l’état de risque d’un Service Principal à l’aide de l’onglet Identity Protection - identités de charge de travail à risque, ou utiliser l’API Microsoft Graph.

Capture d’écran de la page Détails de la détection des risques.

Capture d’écran de la page d’interface utilisateur de la détection des risques.

Exemple d’API Graph de détection des risques du principal de service.

Vérifier s'il y a un comportement inhabituel de connexion.

La première étape de l’enquête consiste à rechercher des preuves de schémas d’authentification inhabituels dans l’utilisation du Service Principal. Dans le Portail Azure, Azure Monitor, Microsoft Sentinel ou le système Gestion des informations et des événements de sécurité (SIEM) de votre organisation, recherchez les éléments suivants dans la section Infos d’identification du principal du service :

  • Emplacement : le Service Principal s’authentifie-t-il à partir d’adresses IP inattendues ?
  • Échecs : le nombre d'échecs d'authentification pour le Service Principal est-il élevé ?
  • Horodatages : existe-t-il des authentifications réussies à des moments inattendus ?
  • Fréquence : existe-t-il une augmentation de la fréquence des authentifications pour le Service Principal ?
  • Fuite d’informations d’identification : les informations d’identification d’application sont-elles codées en dur et publiées sur une source publique telle que GitHub ?

Si vous avez déployé Microsoft Entra ID Identity Protection - identités de charge de travail à risque, vérifiez les détections de connexions suspectes et d’informations d’identification de fuite. Pour plus d’informations, consultez Détentions pour risques liés à l’identité de la charge de travail.

Vérifier la ressource cible

Dans les connexions au Service Principal,vérifiez également la ressource à laquelle le Service Principal a accédé lors de l’authentification. Il est important d’obtenir une entrée du propriétaire de l’application, car elle connaît les ressources auxquelles le principal de service doit accéder.

Capture d’écran montrant comment vérifier la ressource pour le principal de service.

Rechercher les modifications anormales des informations d’identification

Utilisez les journaux d’audit pour obtenir des informations sur les modifications des informations d’identification sur les applications et les principaux de service. Filtrez la catégoriepar gestion des applications et l’activité par l’application de mise à jour : gestion des certificats et dessecrets.

  • Vérifiez si des informations d'identification nouvellement créées ou inattendues ont été attribuées au Service Principal.
  • Vérifier les informations d'identification sur le Service Principal à l'aide de l'API Microsoft Graph.
  • Vérifiez l'application et les objets principaux de service associés.
  • Vérifiez tout rôle personnalisé qui a pu être créé ou modifié. Notez les autorisations marquées ci-dessous :

Capture d’écran montrant comment vérifier les rôles personnalisés créés ou modifiés.

Si vous avez déployé la gouvernance des applications dans Microsoft Defender for Cloud Apps, vérifiez les alertes relatives à l'application sur le portail Azure. Pour plus d’informations, consultez Démarrer avec la détection des menaces.

Si vous avez déployé Identity Protection, vérifiez le rapport « Détections des risques » et dans l’identité de l’utilisateur ou de la charge de travail « historique des risques ».

Capture d’écran de l’interface utilisateur du portail détection des risques.

Si vous avez déployé Microsoft Defender for Cloud Apps, vérifiez que l’option « Ajout inhabituel d’informations d’identification à une application OAuth » est activée et vérifiez les alertes ouvertes.

Pour plus d'informations, voir Ajout inhabituel d’informations d’identification à une application OAuth

En outre, vous pouvez interroger les API servicePrincipalRiskDetections et user riskDetections pour récupérer ces détections de risque.

Rechercher des modifications anormales de configuration d’application

  • Vérifiez les autorisations API attribuées à l’application pour vous assurer que les autorisations sont cohérentes avec ce qui est attendu de l’application.
  • Vérifiez les journaux d’audit (filtrez l’activité par applicationde mise à jour ou par principal du service de mise à jour).
  • Vérifiez que les chaînes de connexion sont cohérentes et que l'URL de déconnexion n'a pas été modifiée.
  • Vérifiez si les domaines de l’URL sont conformes à ceux inscrits.
  • Déterminez si quelqu’un a ajouté une URL de redirection non autorisée.
  • Confirmez la propriété de l’URI de redirection que vous possédez pour vous assurer qu’elle n’a pas expiré et a été revendiquée par une personne mal intentionnée.

De plus, si vous avez déployé Microsoft Defender for Cloud Apps, vérifiez sur le portail Azure les alertes relatives à l'application que vous êtes en train d'examiner. Toutes les stratégies d’alerte ne sont pas activées par défaut pour les applications OAuth. Vérifiez donc qu’elles sont toutes activées. Pour plus d’informations, consultez Stratégies d’autorisation d’application. Vous pouvez également consulter des informations sur la prévalence et l'activité récente des applications sous l'onglet>InvestigationOAuth Apps.

Rechercher les rôles d’application suspects

  • Vous pouvez également utiliser les journaux d’audit. Filtrez l'activité par Ajouter une attribution de rôle d’application à un principal de service.
  • Vérifiez si les rôles attribués ont un privilège élevé.
  • Vérifiez si ces privilèges sont nécessaires.

Vérifier la présence d'applications commerciales non vérifiées

  • Vérifiez si des applications de la galerie commerciale (versions publiées et vérifiées) sont utilisées.

Vérifiez s'il y a des indications de divulgation d'informations sur la propriété de keyCredential

Examinez votre locataire en vue d'une éventuelle divulgation d'informations sur la propriété de keyCredential, comme indiqué dans le document CVE-2021-42306.

Pour identifier et corriger les applications Microsoft Entra affectées associées aux comptes d’identification Automation impactés, accédez au référentiel GitHub de conseils de correction.

Important

Si vous découvrez des preuves de compromission, il est important de prendre les mesures mises en évidence dans les sections contenant-contenu et récupération. Ces étapes permettent de résoudre le risque, mais d’effectuer une enquête plus approfondie pour comprendre la source de la compromission afin d’éviter un impact supplémentaire et de s’assurer que les acteurs malveillants sont supprimés.

Il existe deux méthodes principales d’accès aux systèmes via l’utilisation d’applications. La première consiste à obtenir le consentement d'un administrateur ou d'un utilisateur pour une application, généralement par le biais d'une attaque par hameçonnage. Cette méthode fait partie de l’accès initial à un système et est souvent appelée « hameçonnage de consentement ».

La seconde méthode consiste à créer une nouvelle application à partir d'un compte administrateur déjà compromis, à des fins de persistance, de collecte de données et pour passer inaperçu. Par exemple, un administrateur compromis peut créer une application OAuth avec un nom apparemment innocu, en évitant la détection et en autorisant l’accès à long terme aux données sans avoir besoin d’un compte. Cette méthode est souvent utilisée dans les attaques des États-nations.

Voici quelques mesures qui peuvent être prises pour examiner plus en détail.

Vérifier le journal d'audit unifié (UAL) de Microsoft 365 pour les indications de hameçonnage des 7 derniers jours.

Parfois, lorsque les attaquants utilisent des applications malveillantes ou compromises comme moyen de persistance ou pour exfiltrer des données, il s'agit d'une campagne d'hameçonnage. En fonction des résultats des étapes précédentes, vous devez revoir les identités des éléments suivants :

  • Propriétaires d'applications
  • Administrateurs du consentement

Examinez les identités pour y déceler des signes d'attaques par hameçonnage au cours des dernières 24 heures. Ce délai peut être porté à 7, 14 et 30 jours s'il n'y a pas d'indications immédiates. Pour obtenir un manuel d’investigation de hameçonnage détaillé, consultez le manuel d’investigation de hameçonnage.

Recherchez des autorisations de demandes malveillantes pour les sept derniers jours

Pour qu'une application soit ajoutée à un locataire, les attaquants usurpent l'identité des utilisateurs ou des administrateurs pour qu'ils donnent leur accord aux applications. Pour en savoir plus sur les signes d'une attaque, consultez le guide d’enquête sur le consentement à l'application et la subvention.

Vérifiez les journaux d’audit

Pour afficher toutes les subventions de consentement pour cette application, filtrez l’activité par consentement à l’application.

  • Accédez aux journaux d’audit à partir du Centre d’administration Microsoft Entra

  • Utiliser Microsoft Graph pour interroger les journaux d’audit

    a) Filtrez pour une période spécifique :

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Filtrez les journaux d’audit pour les entrées du journal d’audit « Consentement aux applications » :

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Utilisez Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Pour plus d’informations, consultez le manuel d’enquête sur l’octroi de consentement de l’application.

Un utilisateur peut autoriser une application à accéder à certaines données de la ressource protégée en agissant en son nom. Les autorisations permettant ce type d’accès sont appelées « autorisations déléguées » ou consentement de l’utilisateur.

Pour rechercher les applications qui sont consentées par les utilisateurs, utilisez LogAnalytics pour rechercher les journaux d’audit :

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

Vérifiez les journaux d’audit pour déterminer si les autorisations accordées sont trop larges (à l’échelle du locataire ou à l’échelle de l’administrateur)

L’examen des autorisations accordées à une application ou à un principal de service peut être une tâche fastidieuse. Commencez par comprendre lesautorisations potentiellement risquées dans l’ID Microsoft Entra.

Puis, suivez les instructions sur la façon d’énumérer et de passer en revue les autorisations dans l’examen de l’octroi de consentement de l’application.

Vérifiez si les autorisations ont été accordées par des identités d'utilisateurs qui ne devraient pas être habilitées à le faire, ou si les actions ont été effectuées à des dates et heures inhabituelles.

Vérifiez à l'aide des journaux d'audit :

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Vous pouvez également utiliser les journaux d’audit Microsoft Entra et les filtrer par consentement pour l’application. Dans la section Détails du journal d’audit, cliquez sur Propriétés modifiées, puis passez en revue consentAction.Permissions :

Capture d’écran montrant comment utiliser les journaux d’audit Microsoft Entra.

Étapes d’isolement

Après avoir identifié une ou plusieurs applications ou identités de charge de travail comme étant malveillantes ou compromises, vous ne souhaiterez peut-être pas immédiatement déployer les informations d’identification de cette application, ni supprimer immédiatement l’application.

Important

Avant de procéder à l'étape suivante, votre organisation doit évaluer l'impact de la désactivation d'une application sur la sécurité et sur l'activité de l'entreprise. Si l’impact métier de la désactivation d’une application est trop important, envisagez de préparer et de passer à l’étape de récupération de ce processus.

Désactiver l’application compromise

Une stratégie d’iolement classique implique la désactivation des connexions à l’application identifiée, pour donner à votre équipe de réponse aux incidents ou au temps de l’unité commerciale affectée pour évaluer l’impact de la suppression ou de la clé propagée. Si votre enquête vous conduit à croire que les informations d’identification du compte d’administrateur sont également compromises, ce type d’activité doit être coordonné avec un événement d’éviction pour vous assurer que tous les itinéraires d’accès au locataire sont coupés simultanément.

Capture d’écran montrant comment désactiver la connexion utilisateur.

Vous pouvez également utiliser le code PowerShell Microsoft Graph suivant pour désactiver la connexion à l’application :

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Étapes de récupération

Corriger Service Principals

  1. Dressez la liste de toutes les informations d'identification attribuées au Service Principal à risque. La meilleure façon de procéder consiste à effectuer un appel Microsoft Graph à l’aide de GET ~/application/{id} où l’ID passé est l’ID d’objet de l’application.

    • Analysez la sortie des informations d’identification. La sortie peut contenir passwordCredentials ou keyCredentials. Enregistrez les keyIds pour tous.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Ajoutez un nouveau certificat (x509) à l'objet de l'application à l'aide de l'API addKey de l'application.

    POST ~/applications/{id}/addKey

  3. Supprimez immédiatement toutes les anciennes informations d’identification. Pour chaque ancienne information d’identification de mot de passe, supprimez-la à l’aide de :

    POST ~/applications/{id}/removePassword

    Pour chaque ancienne clé, supprimez-la à l’aide de :

    POST ~/applications/{id}/removeKey

  4. Corrigez tous les Service Principals associés à l’application. Suivez cette étape si votre locataire héberge/inscrit une application mutualisée et/ou inscrit plusieurs principaux de service associés à l’application. Procédez de la même manière que pour la liste précédente :

  • GET ~/servicePrincipals/{id}

  • Trouvez les passwordCredentials et keyCredentials dans la réponse, enregistrez tous les anciens keyIds.

  • Supprimez tous les anciens mots de passe et informations d’identification de clé. Utilisez :

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Corrigez les ressources du Service Principal affecté

Corrigez les secrets Azure Key Vault auxquels le Service Principal a accès en effectuant leur rotation.

  • Secrets directement exposés avec les appelsGetSecret.
  • Le reste des secrets se trouvent dans les coffres de clés exposés.
  • Le reste des secrets se trouve dans les abonnements exposés.

Pour plus d’informations, consultez Supprimer et reconduire interactivement les certificats et les secrets d'un Service Principal ou d'une Application..

Pour obtenir des conseils sur microsoft Entra SecOps sur les applications, consultez le guide des opérations de sécurité Microsoft Entra pour les applications.

Dans l’ordre de priorité, ce scénario serait :

  • Mise à jour de la documentation sur les cmdlets Graph PowerShell (Add/Remove ApplicationKey + ApplicationPassword) afin d'y inclure des exemples de transfert d'informations d'identification.
  • Ajoutez des cmdlets personnalisés à Microsoft Graph PowerShell pour simplifier ce scénario.

Désactivez ou supprimez les applications malveillantes

Une application peut être désactivée ou supprimée. Pour désactiver l’application, sous Activé pour que les utilisateurs se connectent, placez le curseur sur Non.

Vous pouvez supprimer l’application, temporairement ou définitivement, dans le Portail Azure ou via l’API Microsoft Graph. Lorsque vous procédez à une suppression progressive, l'application peut être récupérée jusqu'à 30 jours après la suppression.

DELETE /applications/{id}

Pour supprimer définitivement l’application, utilisez cet appel d’API Microsoft Graph :

DELETE /directory/deletedItems/{id}

Si vous désactivez ou supprimez l'application, configurez un contrôle dans les journaux d'audit de Microsoft Entra pour savoir si l'état redevient activé ou récupéré.

La journalisation est activée :

  • Service : répertoire principal
  • Activité : Mise à jour du Service Principal
  • Catégorie : Gestion des applications
  • Initié par (acteur) : UPN d’acteur
  • Cibles : ID d’application et nom complet
  • Propriétés modifiées : Nom de propriété = compte activé, nouvelle valeur = true

Journalisation pour la récupération :

  • Service : répertoire principal
  • Type d’activité : Ajouter un Service Principal
  • Catégorie : Gestion des applications
  • Initié par (acteur) : UPN d’acteur
  • Cibles : ID d’application et nom complet
  • Propriétés modifiées : Nom de propriété = compte activé, nouvelle valeur = true

Remarque

Microsoft désactive globalement les applications qui ont été détectées en violation de ses conditions d’utilisation. Ces applications affichent DisabledDueToViolationOfServicesAgreement sur la propriété disabledByMicrosoftStatus sur les types de ressources application et principal de service associés dans Microsoft Graph. Pour empêcher leur instanciation ultérieure dans votre organisation, vous ne pouvez pas supprimer ces objets.

Mise en oeuvre d’Identity Protection pour les identités de charge de travail

Microsoft détecte les risques sur les identités de charge de travail à travers le comportement de connexion et les indicateurs de compromission hors ligne.

Pour plus d’informations, consultez Sécuriser les identités de la charge de travail avec Identity Protection..

Ces alertes s’affichent dans le portail Identity Protection et peuvent être exportées dans des outils SIEM via paramètres de diagnostic ou les API Identity Protection

Capture d’écran montrant comment passer en revue les risques et les alertes dans le portail Identity Protection.

Accès conditionnel pour les identités de charge de travail à risque

L’accès conditionnel vous permet de bloquer l’accès pour des comptes spécifiques que vous désignez lorsque Identity Protection les marque comme étant « à risque ». L’application par le biais de l’accès conditionnel est actuellement limitée aux applications monolocataires uniquement.

Capture d’écran montrant comment contrôler l’accès utilisateur en fonction de la stratégie d’accès conditionnel.

Pour plus d’informations, consultez l’article Accès conditionnel pour les identités de charge de travail.

Implémenter des stratégies de risque d’application

Vérifiez les paramètres de consentement de l'utilisateur dans Microsoft Entra ID>Applications d’entreprise>Consentement et autorisations>Paramètres de consentement de l’utilisateur.

Capture d’écran montrant comment autoriser le consentement de l’utilisateur pour les applications.

Pour passer en revue les options de configuration, consultez Configurer le consentement des utilisateurs aux applications.

Lorsqu’un développeur d’application dirige les utilisateurs vers le point de terminaison de consentement administrateur avec l’intention de donner le consentement pour l’ensemble du tenant, on parle de flux de consentement administrateur. Pour garantir le bon fonctionnement du flux de consentement de l’administrateur, les développeurs d’application doivent répertorier toutes les autorisations dans la propriété RequiredResourceAccess qui se trouve dans le manifeste de l’application.

La plupart des organisations désactivent la possibilité pour leurs utilisateurs de donner leur consentement aux applications. Pour permettre aux utilisateurs de demander toujours le consentement des applications et d’avoir une fonctionnalité de révision administrative, il est recommandé d’implémenter le flux de travail de consentement administrateur. Suivez les étapes du flux de travail de consentement de l’administrateur pour le configurer dans votre locataire.

Pour les opérations à privilèges élevés, telles que le consentement de l’administrateur, vous disposez d’une stratégie d’accès privilégié définie dans nos conseils.

Le consentement progressif basé sur le risque aide à réduire l'exposition des utilisateurs aux applications malveillantes. Par exemple, les demandes de consentement pour des applications multi-locataires nouvellement enregistrées qui ne sont pas vérifiées par l'éditeur et qui requièrent des autorisations non fondamentales sont considérées comme risquées. Si une demande de consentement d’utilisateur à risque est détectée, la demande nécessite une réaffectation à un consentement d’administrateur. Cette capacité de réaffectation est activée par défaut, mais n’entraîne de changement de comportement que quand le consentement d’utilisateur est activé.

Vérifiez qu’il est activé dans votre tenant et passez en revue les paramètres de configuration décrits ici.

Références

Playbooks sur les réponses aux incidents supplémentaires

Parcourez les conseils afin d’identifier et d’examiner ces types d’attaques supplémentaires :

Ressources pour répondre aux incidents