Guide d’activité suspecte d’Advanced Threat Analytics

S’applique à : Advanced Threat Analytics version 1.9

Après une investigation appropriée, toute activité suspecte peut être classée comme suit :

• Vrai positif : action malveillante détectée par ATA.

• Vrai positif sans gravité : action détectée par ATA qui est réelle mais non malveillante, telle qu’un test d’intrusion.

• Faux positif : fausse alarme, ce qui signifie que l’activité ne s’est pas produite.

Pour plus d’informations sur l’utilisation des alertes ATA, consultez Utilisation d’activités suspectes.

Si vous avez des questions ou des commentaires, contactez l’équipe ATA à l’adresse ATAEval@microsoft.com.

Modification anormale des groupes sensibles

Description

Les attaquants ajoutent des utilisateurs à des groupes à privilèges élevés. Ils le font pour accéder à davantage de ressources et gagner en persistance. Les détections s’appuient sur le profilage des activités de modification de groupe d’utilisateurs et sur les alertes en cas d’ajout anormal à un groupe sensible. Le profilage est effectué en continu par ATA. La période minimale avant qu’une alerte puisse être déclenchée est d’un mois par contrôleur de domaine.

Pour obtenir une définition des groupes sensibles dans ATA, consultez Utilisation de la console ATA.

La détection s’appuie sur les événements audités sur les contrôleurs de domaine. Pour vous assurer que vos contrôleurs de domaine auditent les événements nécessaires, utilisez cet outil.

Enquête

1. La modification du groupe est-elle légitime ?
   Des modifications de groupe légitimes qui se produisent rarement et qui n’ont pas été apprises comme « normales », peuvent provoquer une alerte, qui serait considérée comme un vrai positif sans gravité.

2. Si l’objet ajouté était un compte d’utilisateur, case activée les actions effectuées par le compte d’utilisateur après avoir été ajouté au groupe d’administration. Accédez à la page de l’utilisateur dans ATA pour obtenir plus de contexte. Y a-t-il eu d’autres activités suspectes associées au compte avant ou après l’ajout ? Téléchargez le rapport de modification des groupes sensibles pour voir quelles autres modifications ont été apportées et par qui au cours de la même période.

Remédiation

Réduisez le nombre d’utilisateurs autorisés à modifier des groupes sensibles.

Configurez Privileged Access Management pour Active Directory , le cas échéant.

Confiance rompue entre les ordinateurs et le domaine

Remarque

L’alerte Confiance rompue entre les ordinateurs et le domaine était déconseillée et n’apparaît que dans les versions d’ATA antérieures à la version 1.9.

Description

Une confiance rompue signifie que les exigences de sécurité Active Directory peuvent ne pas être appliquées pour ces ordinateurs. Il s’agit d’un échec de sécurité et de conformité de base et d’une cible logicielle pour les attaquants. Dans cette détection, une alerte est déclenchée si plus de cinq échecs d’authentification Kerberos sont détectés à partir d’un compte d’ordinateur dans les 24 heures.

Enquête

L’ordinateur en cours d’examen permet-il aux utilisateurs du domaine de se connecter ?

• Si c’est le cas, vous pouvez ignorer cet ordinateur dans les étapes de correction.

Remédiation

Reconnectez la machine au domaine si nécessaire ou réinitialisez le mot de passe de l’ordinateur.

Attaque par force brute à l’aide d’une liaison simple LDAP

Description

Remarque

La différence main entre échecs d’authentification suspects et cette détection est que dans cette détection, ATA peut déterminer si différents mots de passe ont été utilisés.

Dans une attaque par force brute, un attaquant tente de s’authentifier avec de nombreux mots de passe différents pour différents comptes jusqu’à ce qu’un mot de passe correct soit trouvé pour au moins un compte. Une fois trouvé, un attaquant peut se connecter à l’aide de ce compte.

Dans cette détection, une alerte est déclenchée lorsqu’ATA détecte un grand nombre d’authentifications de liaison simples. Cela peut être soit horizontalement avec un petit ensemble de mots de passe sur de nombreux utilisateurs ; ou verticalement » avec un grand ensemble de mots de passe sur quelques utilisateurs seulement ; ou toute combinaison de ces deux options.

Enquête

1. Si de nombreux comptes sont impliqués, sélectionnez Télécharger les détails pour afficher la liste dans une feuille de calcul Excel.

2. Sélectionnez l’alerte pour accéder à sa page dédiée. Vérifiez si des tentatives de connexion se sont terminées par une authentification réussie. Les tentatives apparaissent sous la forme de comptes devinés sur le côté droit de l’infographie. Si oui, l’un des comptes devinés est-il normalement utilisé à partir de l’ordinateur source ? Si oui, supprimez l’activité suspecte.

3. S’il n’y a pas de comptes devinés, les comptes attaqués sont-ils normalement utilisés à partir de l’ordinateur source ? Si oui, supprimez l’activité suspecte.

Remédiation

Les mots de passe complexes et longs fournissent le premier niveau de sécurité nécessaire contre les attaques par force brute.

Activité de passage à une version antérieure du chiffrement

Description

Le passage à une version antérieure du chiffrement est une méthode permettant d’affaiblir Kerberos en rétrogradant le niveau de chiffrement de différents champs du protocole qui sont normalement chiffrés à l’aide du niveau de chiffrement le plus élevé. Un champ chiffré affaibli peut être une cible plus facile pour les tentatives de force brute hors connexion. Différentes méthodes d’attaque utilisent des chiffrements Kerberos faibles. Dans cette détection, ATA apprend les types de chiffrement Kerberos utilisés par les ordinateurs et les utilisateurs, et vous avertit lorsqu’un chiffrement plus faible est utilisé : (1) est inhabituel pour l’ordinateur source et/ou l’utilisateur ; et (2) correspond aux techniques d’attaque connues.

Il existe trois types de détection :

1. Skeleton Key : programme malveillant qui s’exécute sur les contrôleurs de domaine et autorise l’authentification auprès du domaine avec n’importe quel compte sans connaître son mot de passe. Ce programme malveillant utilise souvent des algorithmes de chiffrement plus faibles pour hacher les mots de passe de l’utilisateur sur le contrôleur de domaine. Dans cette détection, la méthode de chiffrement du KRB_ERR message du contrôleur de domaine au compte demandant un ticket a été rétrogradée par rapport au comportement précédemment appris.

2. Golden Ticket : dans une alerte Golden Ticket , la méthode de chiffrement du champ TGT du message TGS_REQ (demande de service) de l’ordinateur source a été rétrogradée par rapport au comportement précédemment appris. Cela n’est pas basé sur une anomalie de temps (comme dans l’autre détection golden ticket). En outre, aucune demande d’authentification Kerberos n’était associée à la demande de service précédente détectée par ATA.

3. Overpass-the-Hash : un attaquant peut utiliser un hachage volé faible afin de créer un ticket fort, avec une requête Kerberos AS. Dans cette détection, le type de chiffrement de message AS_REQ de l’ordinateur source a été rétrogradé par rapport au comportement précédemment appris (autrement dit, l’ordinateur utilisait AES).

Enquête

Tout d’abord, case activée la description de l’alerte pour voir lequel des trois types de détection ci-dessus vous traitez. Pour plus d’informations, téléchargez la feuille de calcul Excel.

1. Skeleton Key : vérifiez si Skeleton Key a affecté vos contrôleurs de domaine.
2. Golden Ticket : dans la feuille de calcul Excel, accédez à l’onglet Activité réseau . Vous verrez que le champ déclassé approprié est Type de chiffrement de ticket de demande, et que les types de chiffrement pris en charge par l’ordinateur source répertorient des méthodes de chiffrement plus fortes. 1.Vérifiez l’ordinateur source et le compte, ou s’il existe plusieurs ordinateurs sources et comptes case activée s’ils ont quelque chose en commun (par exemple, tout le personnel marketing utilise une application spécifique qui peut provoquer le déclenchement de l’alerte). Dans certains cas, une application personnalisée rarement utilisée s’authentifie à l’aide d’un chiffrement de chiffrement inférieur. Vérifiez s’il existe des applications personnalisées de ce type sur l’ordinateur source. Si c’est le cas, il s’agit probablement d’un vrai positif bénin et vous pouvez le supprimer . 1.Vérifiez la ressource accessible par ces tickets. S’il existe une ressource à laquelle ils accèdent tous, validez-la et assurez-vous qu’il s’agit d’une ressource valide à laquelle ils sont censés accéder. Vérifiez également si la ressource cible prend en charge les méthodes de chiffrement fortes. Vous pouvez case activée cela dans Active Directory en vérifiant l’attribut msDS-SupportedEncryptionTypes, du compte de service de ressources.
3. Overpass-the-Hash : dans la feuille de calcul Excel, accédez à l’onglet Activité réseau . Vous verrez que le champ déclassé approprié est Type de chiffrement d’horodatage chiffré et types de chiffrement pris en charge par l’ordinateur source contient des méthodes de chiffrement plus fortes. 1.Dans certains cas, cette alerte peut être déclenchée lorsque des utilisateurs se connectent à l’aide de cartes à puce si la configuration de la carte à puce a été modifiée récemment. Vérifiez s’il y a eu des modifications de ce type pour le ou les comptes impliqués. Si c’est le cas, il s’agit probablement d’un vrai positif bénin et vous pouvez le supprimer . 1.Vérifiez la ressource accessible par ces tickets. S’il existe une ressource à laquelle ils accèdent tous, validez-la et assurez-vous qu’il s’agit d’une ressource valide à laquelle ils sont censés accéder. Vérifiez également si la ressource cible prend en charge les méthodes de chiffrement fortes. Vous pouvez case activée cela dans Active Directory en vérifiant l’attribut msDS-SupportedEncryptionTypes, du compte de service de ressources.

Remédiation

1. Skeleton Key : supprimez le programme malveillant. Pour plus d’informations, consultez Skeleton Key Malware Analysis.

2. Golden Ticket : suivez les instructions des activités suspectes golden ticket . En outre, étant donné que la création d’un Golden Ticket nécessite des droits d’administrateur de domaine, implémentez pass les recommandations de hachage.

3. Overpass-the-Hash : si le compte concerné n’est pas sensible, réinitialisez le mot de passe de ce compte. Cela empêche l’attaquant de créer des tickets Kerberos à partir du hachage de mot de passe, bien que les tickets existants puissent toujours être utilisés jusqu’à leur expiration. S’il s’agit d’un compte sensible, vous devez envisager de réinitialiser le compte KRBTGT deux fois comme dans l’activité suspecte Golden Ticket. La réinitialisation de KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine. Planifiez donc avant de le faire. Consultez les conseils de l’article sur le compte KRBTGT. Étant donné qu’il s’agit d’une technique de mouvement latéral, suivez les meilleures pratiques de Passer les recommandations de hachage.

Activité Honeytoken

Description

Les comptes Honeytoken sont des comptes leurins configurés pour identifier et suivre les activités malveillantes qui impliquent ces comptes. Les comptes Honeytoken doivent être inutilisés, tout en ayant un nom attrayant pour attirer les attaquants (par exemple, SQL-Administration). Toute activité de leur part peut indiquer un comportement malveillant.

Pour plus d’informations sur les comptes de jeton honey, consultez Installer ATA - Étape 7.

Enquête

1. Vérifiez si le propriétaire de l’ordinateur source a utilisé le compte Honeytoken pour s’authentifier, à l’aide de la méthode décrite dans la page d’activité suspecte (par exemple, Kerberos, LDAP, NTLM).

2. Accédez aux pages de profil des ordinateurs sources et case activée quels autres comptes ont été authentifiés à partir de ceux-ci. Vérifiez auprès des propriétaires de ces comptes s’ils ont utilisé le compte Honeytoken.

3. Il peut s’agir d’une connexion non interactive. Veillez donc à case activée pour les applications ou les scripts qui s’exécutent sur l’ordinateur source.

Si, après avoir effectué les étapes 1 à 3, s’il n’y a aucune preuve d’utilisation sans gravité, supposons qu’il s’agit d’une utilisation malveillante.

Remédiation

Assurez-vous que les comptes Honeytoken sont utilisés uniquement dans le but prévu, sinon ils peuvent générer de nombreuses alertes.

Usurpation d’identité à l’aide d’une attaque Pass-the-Hash

Description

Pass-the-Hash est une technique de mouvement latéral dans laquelle les attaquants volent le hachage NTLM d’un utilisateur à partir d’un ordinateur et l’utilisent pour accéder à un autre ordinateur.

Enquête

Le hachage a-t-il été utilisé à partir d’un ordinateur détenu ou utilisé régulièrement par l’utilisateur ciblé ? Si oui, l’alerte est un faux positif, si ce n’est pas le cas, il s’agit probablement d’un vrai positif.

Remédiation

1. Si le compte impliqué n’est pas sensible, réinitialisez le mot de passe de ce compte. La réinitialisation du mot de passe empêche l’attaquant de créer des tickets Kerberos à partir du hachage de mot de passe. Les tickets existants sont toujours utilisables jusqu’à leur expiration.

2. Si le compte concerné est sensible, envisagez de réinitialiser le compte KRBTGT deux fois, comme dans l’activité suspecte Golden Ticket. La réinitialisation de KRBTGT deux fois invalide tous les tickets Kerberos de domaine. Par conséquent, planifiez l’impact avant de le faire. Consultez les conseils de l’article sur le compte KRBTGT. Comme il s’agit généralement d’une technique de mouvement latéral, suivez les meilleures pratiques de Passer les recommandations de hachage.

Usurpation d’identité à l’aide d’une attaque Pass-the-Ticket

Description

Pass-the-Ticket est une technique de mouvement latéral dans laquelle les attaquants volent un ticket Kerberos d’un ordinateur et l’utilisent pour accéder à un autre ordinateur en réutilisant le ticket volé. Dans cette détection, un ticket Kerberos est vu utilisé sur deux ordinateurs différents (ou plus).

Enquête

1. Sélectionnez le bouton Télécharger les détails pour afficher la liste complète des adresses IP impliquées. L’adresse IP d’un ou des deux ordinateurs fait-elle partie d’un sous-réseau alloué à partir d’un pool DHCP sous-dimensionné, par exemple, VPN ou Wi-Fi ? L’adresse IP est-elle partagée ? Par exemple, par un appareil NAT ? Si la réponse à l’une de ces questions est oui, l’alerte est un faux positif.

2. Existe-t-il une application personnalisée qui transfère les tickets au nom des utilisateurs ? Si c’est le cas, c’est un vrai positif bénin.

Remédiation

1. Si le compte concerné n’est pas sensible, réinitialisez le mot de passe de ce compte. La réinitialisation de mot de passe empêche l’attaquant de créer des tickets Kerberos à partir du hachage de mot de passe. Tous les tickets existants restent utilisables jusqu’à leur expiration.

2. S’il s’agit d’un compte sensible, vous devez envisager de réinitialiser le compte KRBTGT deux fois comme dans l’activité suspecte Golden Ticket. La réinitialisation de KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine. Planifiez donc avant de le faire. Consultez les conseils de l’article sur le compte KRBTGT. Étant donné qu’il s’agit d’une technique de mouvement latéral, suivez les meilleures pratiques décrites dans Passer les recommandations de hachage.

Activité Kerberos Golden Ticket

Description

Les attaquants disposant de droits d’administrateur de domaine peuvent compromettre votre compte KRBTGT. Les attaquants peuvent utiliser le compte KRBTGT pour créer un ticket d’octroi de ticket Kerberos (TGT) fournissant l’autorisation à n’importe quelle ressource. L’expiration du ticket peut être définie sur n’importe quelle heure arbitraire. Ce faux TGT est appelé « Golden Ticket » et permet aux attaquants d’atteindre et de maintenir la persistance dans votre réseau.

Dans cette détection, une alerte est déclenchée lorsqu’un ticket d’octroi de ticket Kerberos (TGT) est utilisé pour une durée supérieure à la durée autorisée spécifiée dans la stratégie de sécurité Durée de vie maximale pour les tickets utilisateur .

Enquête

1. Des modifications récentes (au cours des dernières heures) ont-elles été apportées au paramètre Durée de vie maximale du ticket utilisateur dans la stratégie de groupe ? Si oui, fermez l’alerte (il s’agissait d’un faux positif).

2. La passerelle ATA impliquée dans cette alerte est-elle une machine virtuelle ? Si oui, a-t-il récemment repris à partir d’un état enregistré ? Si oui, fermez cette alerte.

3. Si la réponse aux questions ci-dessus est non, supposons qu’il s’agit d’une erreur malveillante.

Remédiation

Modifiez le mot de passe KRBTGT (Ticket Granting Ticket Ticket) Kerberos deux fois conformément aux instructions de l’article sur le compte KRBTGT. La réinitialisation de KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine. Planifiez donc avant de le faire. En outre, étant donné que la création d’un Golden Ticket nécessite des droits d’administrateur de domaine, implémentez pass les recommandations de hachage.

Demande d’informations privées de protection des données malveillantes

Description

L’API de protection des données (DPAPI) est utilisée par Windows pour protéger en toute sécurité les mots de passe enregistrés par les navigateurs, les fichiers chiffrés et d’autres données sensibles. Les contrôleurs de domaine contiennent une clé de master de sauvegarde qui peut être utilisée pour déchiffrer tous les secrets chiffrés avec DPAPI sur des machines Windows jointes à un domaine. Les attaquants peuvent utiliser cette clé master pour déchiffrer les secrets protégés par DPAPI sur toutes les machines jointes à un domaine. Dans cette détection, une alerte est déclenchée lorsque l’API DPAPI est utilisée pour récupérer la clé de master de sauvegarde.

Enquête

1. L’ordinateur source exécute-t-il un analyseur de sécurité avancé approuvé organization sur Active Directory ?

2. Si oui et qu’il doit toujours le faire, fermez et excluez l’activité suspecte.

3. Si oui et qu’il ne doit pas le faire, fermez l’activité suspecte.

Remédiation

Pour utiliser DPAPI, un attaquant a besoin de droits d’administrateur de domaine. Implémentez Transmettre les recommandations de hachage.

Réplication malveillante des services d’annuaire

Description

La réplication Active Directory est le processus par lequel les modifications apportées à un contrôleur de domaine sont synchronisées avec tous les autres contrôleurs de domaine. Avec les autorisations nécessaires, les attaquants peuvent lancer une demande de réplication, ce qui leur permet de récupérer les données stockées dans Active Directory, y compris les hachages de mot de passe.

Dans cette détection, une alerte est déclenchée lorsqu’une demande de réplication est lancée à partir d’un ordinateur qui n’est pas un contrôleur de domaine.

Enquête

1. L’ordinateur en question est-il un contrôleur de domaine ? Par exemple, un contrôleur de domaine nouvellement promu qui a rencontré des problèmes de réplication. Si oui, fermez l’activité suspecte.
2. L’ordinateur en question est-il censé répliquer des données à partir d’Active Directory ? Par exemple, Microsoft Entra Connect. Si oui, fermez et excluez l’activité suspecte.
3. Sélectionnez l’ordinateur ou le compte source pour accéder à sa page de profil. Vérifiez ce qui s’est passé au moment de la réplication, en recherchant des activités inhabituelles, telles que : qui a été connecté, quelles ressources ont été consultées.

Remédiation

Validez les autorisations suivantes :

• Répliquer les modifications de répertoire

• Répliquer toutes les modifications du répertoire

Pour plus d’informations, voir Accorder des autorisations services de domaine Active Directory pour la synchronisation de profils dans SharePoint Server 2013. Vous pouvez tirer parti du scanneur ad ACL ou créer un script Windows PowerShell pour déterminer qui, dans le domaine, dispose de ces autorisations.

Suppression massive d’objets

Description

Dans certains scénarios, les attaquants effectuent des attaques par déni de service (DoS) plutôt que de voler uniquement des informations. La suppression d’un grand nombre de comptes est une méthode de tentative d’attaque DoS.

Dans cette détection, une alerte est déclenchée chaque fois que plus de 5 % de tous les comptes sont supprimés. La détection nécessite un accès en lecture au conteneur d’objets supprimés. Pour plus d’informations sur la configuration des autorisations en lecture seule sur le conteneur d’objets supprimés, consultez Modification des autorisations sur un conteneur d’objets supprimés dans Afficher ou Définir des autorisations sur un objet Directory.

Enquête

Passez en revue la liste des comptes supprimés et déterminez s’il existe un modèle ou une raison professionnelle qui justifie une suppression à grande échelle.

Remédiation

Supprimez les autorisations pour les utilisateurs qui peuvent supprimer des comptes dans Active Directory. Pour plus d’informations, consultez Afficher ou définir des autorisations sur un objet Directory.

Escalade de privilèges à l’aide de données d’autorisation falsifiées

Description

Les vulnérabilités connues dans les versions antérieures de Windows Server permettent aux attaquants de manipuler le certificat d’attribut privilégié (PAC). PAC est un champ du ticket Kerberos qui contient des données d’autorisation utilisateur (dans Active Directory, il s’agit de l’appartenance au groupe) et accorde aux attaquants des privilèges supplémentaires.

Enquête

1. Sélectionnez l’alerte pour accéder à la page de détails.

2. L’ordinateur de destination (sous la colonne ACCESSED ) est-il corrigé avec MS14-068 (contrôleur de domaine) ou MS11-013 (serveur) ? Si oui, fermez l’activité suspecte (il s’agit d’un faux positif).

3. Si l’ordinateur de destination n’est pas corrigé, l’ordinateur source exécute-t-il (sous la colonne FROM ) un système d’exploitation/une application connue pour modifier le pac ? Si oui, supprimez l’activité suspecte (il s’agit d’un vrai positif bénin).

4. Si la réponse aux deux questions précédentes était non, supposons que cette activité est malveillante.

Remédiation

Assurez-vous que tous les contrôleurs de domaine avec des systèmes d’exploitation jusqu’à Windows Server 2012 R2 sont installés avec KB3011780 et que tous les serveurs membres et contrôleurs de domaine jusqu’à 2012 R2 sont à jour avec KB2496930. Pour plus d’informations, consultez Pac Argent et Pac forgé.

Reconnaissance à l’aide de l’énumération de compte

Description

Dans la reconnaissance d’énumération de compte, un attaquant utilise un dictionnaire contenant des milliers de noms d’utilisateur ou des outils tels que KrbGuess pour tenter de deviner des noms d’utilisateur dans votre domaine. L’attaquant effectue des requêtes Kerberos à l’aide de ces noms pour essayer de trouver un nom d’utilisateur valide dans votre domaine. Si une estimation détermine correctement un nom d’utilisateur, l’attaquant obtient l’erreur Kerberos Pré-authentification requise au lieu du principal de sécurité inconnu.

Dans cette détection, ATA peut détecter l’origine de l’attaque, le nombre total de tentatives de détection et le nombre de correspondances. S’il y a trop d’utilisateurs inconnus, ATA le détecte comme une activité suspecte.

Enquête

1. Sélectionnez l’alerte pour accéder à sa page de détails.

   1. Cet ordinateur hôte doit-il interroger le contrôleur de domaine pour savoir s’il existe ou non des comptes (par exemple, des serveurs Exchange) ?

2. Existe-t-il un script ou une application en cours d’exécution sur l’hôte qui pourrait générer ce comportement ?

   Si la réponse à l’une de ces questions est oui, fermez l’activité suspecte (il s’agit d’un vrai positif bénin) et excluez cet hôte de l’activité suspecte.

3. Téléchargez les détails de l’alerte dans une feuille de calcul Excel pour afficher facilement la liste des tentatives de compte, divisée en comptes existants et non existants. Si vous examinez la feuille de compte non existante dans la feuille de calcul et que les comptes semblent familiers, il peut s’agir de comptes désactivés ou d’employés qui ont quitté l’entreprise. Dans ce cas, il est peu probable que la tentative provait d’un dictionnaire. Il s’agit probablement d’une application ou d’un script qui vérifie quels comptes existent encore dans Active Directory, ce qui signifie qu’il s’agit d’un vrai positif sans gravité.

4. Si les noms ne sont généralement pas familiers, l’une des tentatives d’estimation correspond-elle aux noms de comptes existants dans Active Directory ? S’il n’y a pas de correspondance, la tentative a été futile, mais vous devez prêter attention à l’alerte pour voir si elle est mise à jour au fil du temps.

5. Si l’une des tentatives d’estimation correspond à des noms de compte existants, l’attaquant sait l’existence de comptes dans votre environnement et peut tenter d’utiliser la force brute pour accéder à votre domaine à l’aide des noms d’utilisateur découverts. Vérifiez les noms de compte devinés pour rechercher d’autres activités suspectes. Vérifiez si l’un des comptes correspondants est un compte sensible.

Remédiation

Les mots de passe complexes et longs fournissent le premier niveau de sécurité nécessaire contre les attaques par force brute.

Reconnaissance à l’aide de requêtes des services d’annuaire

Description

La reconnaissance des services d’annuaire est utilisée par les attaquants pour mapper la structure d’annuaires et cibler les comptes privilégiés en vue des étapes ultérieures d’une attaque. Le protocole SAM-R (Security Account Manager Remote) est l’une des méthodes utilisées pour interroger le répertoire afin d’effectuer ce mappage.

Dans cette détection, aucune alerte n’est déclenchée le premier mois suivant le déploiement d’ATA. Pendant la période d’apprentissage, ATA profile les requêtes SAM-R effectuées à partir de quels ordinateurs, à la fois l’énumération et les requêtes individuelles des comptes sensibles.

Enquête

1. Sélectionnez l’alerte pour accéder à sa page de détails. Vérifiez quelles requêtes ont été effectuées (par exemple, administrateurs d’entreprise ou administrateur) et si elles ont réussi ou non.

2. Ces requêtes sont-elles censées être effectuées à partir de l’ordinateur source en question ?

3. Si oui et que l’alerte est mise à jour, supprimez l’activité suspecte.

4. Si oui et qu’il ne devrait plus le faire, fermez l’activité suspecte.

5. S’il existe des informations sur le compte impliqué : ces requêtes sont-elles censées être effectuées par ce compte ou ce compte se connecte-t-il normalement à l’ordinateur source ?

   • Si oui et que l’alerte est mise à jour, supprimez l’activité suspecte.

   • Si oui et qu’il ne devrait plus le faire, fermez l’activité suspecte.

   • Si la réponse était non à tous les cas ci-dessus, supposons qu’il s’agit d’une erreur malveillante.

6. S’il n’existe aucune information sur le compte impliqué, vous pouvez accéder au point de terminaison et case activée quel compte a été connecté au moment de l’alerte.

Remédiation

1. L’ordinateur exécute-t-il un outil d’analyse des vulnérabilités ?
2. Déterminez si les utilisateurs et groupes interrogés spécifiques dans l’attaque sont des comptes privilégiés ou à valeur élevée (c’est-à-dire, pdg, directeur financier, gestion informatique, etc.). Si c’est le cas, examinez également d’autres activités sur le point de terminaison et surveillez les ordinateurs auxquels les comptes interrogés sont connectés, car ils sont probablement des cibles de mouvement latéral.

Reconnaissance à l’aide de DNS

Description

Votre serveur DNS contient une carte de tous les ordinateurs, adresses IP et services de votre réseau. Ces informations sont utilisées par les attaquants pour mapper votre structure réseau et cibler des ordinateurs intéressants pour les étapes ultérieures de leur attaque.

Il existe plusieurs types de requête dans le protocole DNS. ATA détecte la requête AXFR (Transfer) provenant de serveurs non DNS.

Enquête

1. L’ordinateur source (provenant de...) est-il un serveur DNS ? Si oui, il s’agit probablement d’un faux positif. Pour valider, sélectionnez l’alerte pour accéder à sa page de détails. Dans la table, sous Requête, case activée quels domaines ont été interrogés. S’agit-il de domaines existants ? Si oui, fermez l’activité suspecte (il s’agit d’un faux positif). Vérifiez également que le port UDP 53 est ouvert entre la passerelle ATA et l’ordinateur source pour empêcher les faux positifs futurs.
2. La machine source exécute-t-elle un scanneur de sécurité ? Si c’est le cas, excluez les entités dans ATA, soit directement avec Fermer et exclure , soit via la page Exclusion (sous Configuration – disponible pour les administrateurs ATA).
3. Si la réponse à toutes les questions précédentes est non, continuez à examiner en vous concentrant sur l’ordinateur source. Sélectionnez l’ordinateur source pour accéder à sa page de profil. Vérifiez ce qui s’est passé au moment de la demande, en recherchant des activités inhabituelles, telles que : qui a été connecté, quelles ressources ont été consultées.

Remédiation

La sécurisation d’un serveur DNS interne pour empêcher la reconnaissance à l’aide de DNS peut être effectuée en désactivant ou en limitant les transferts de zone uniquement aux adresses IP spécifiées. Pour plus d’informations sur la restriction des transferts de zone, consultez Restreindre les transferts de zone. La modification des transferts de zone est une tâche parmi une liste de contrôle qui doit être traitée pour sécuriser vos serveurs DNS contre les attaques internes et externes.

Reconnaissance à l’aide de l’énumération de session SMB

Description

L’énumération SMB (Server Message Block) permet aux attaquants d’obtenir des informations sur l’emplacement où les utilisateurs se sont récemment connectés. Une fois que les attaquants disposent de ces informations, ils peuvent se déplacer latéralement dans le réseau pour accéder à un compte sensible spécifique.

Dans cette détection, une alerte est déclenchée lorsqu’une énumération de session SMB est effectuée sur un contrôleur de domaine.

Enquête

1. Sélectionnez l’alerte pour accéder à sa page de détails. Vérifiez le ou les comptes qui ont effectué l’opération et quels comptes ont été exposés, le cas échéant.

   • Existe-t-il un type de scanneur de sécurité en cours d’exécution sur l’ordinateur source ? Si oui, fermez et excluez l’activité suspecte.

2. Vérifiez quel(s) utilisateur(s) impliqué(s) a effectué l’opération. Se connectent-ils normalement à l’ordinateur source ou sont-ils des administrateurs qui doivent effectuer de telles actions ?

3. Si oui et que l’alerte est mise à jour, supprimez l’activité suspecte.

4. Si oui et qu’il ne doit pas être mis à jour, fermez l’activité suspecte.

5. Si la réponse à tout ce qui précède est non, supposons que l’activité est malveillante.

Remédiation

1. Contiennent l’ordinateur source.
2. Recherchez et supprimez l’outil qui a effectué l’attaque.

Tentative d’exécution à distance détectée

Description

Les attaquants qui compromettent les informations d’identification d’administration ou utilisent une attaque zero-day peuvent exécuter des commandes à distance sur votre contrôleur de domaine. Cela peut être utilisé pour obtenir la persistance, la collecte d’informations, les attaques par déni de service (DOS) ou toute autre raison. ATA détecte les connexions PSexec et WMI distantes.

Enquête

1. Cela est courant pour les stations de travail d’administration, ainsi que pour les membres de l’équipe informatique et les comptes de service qui effectuent des tâches d’administration sur les contrôleurs de domaine. Si c’est le cas et que l’alerte est mise à jour parce que le même administrateur ou ordinateur effectue la tâche, supprimez l’alerte.
2. L’ordinateur en question est-il autorisé à effectuer cette exécution à distance sur votre contrôleur de domaine ?
   • Le compte en question est-il autorisé à effectuer cette exécution à distance sur votre contrôleur de domaine ?
   • Si la réponse aux deux questions est oui, fermez l’alerte.
3. Si la réponse à l’une ou l’autre des questions est non, cette activité doit être considérée comme un vrai positif. Essayez de trouver la source de la tentative en vérifiant les profils d’ordinateur et de compte. Sélectionnez l’ordinateur ou le compte source pour accéder à sa page de profil. Vérifiez ce qui s’est passé au moment de ces tentatives, en recherchant des activités inhabituelles, telles que : qui a été connecté, quelles ressources ont été consultées.

Remédiation

1. Restreindre l’accès à distance aux contrôleurs de domaine à partir de machines non de niveau 0.

2. Implémentez l’accès privilégié pour autoriser uniquement les machines renforcées à se connecter aux contrôleurs de domaine pour les administrateurs.

Informations d’identification de compte sensibles exposées & Services exposant les informations d’identification du compte

Remarque

Cette activité suspecte était déconseillée et n’apparaît que dans les versions d’ATA antérieures à la version 1.9. Pour ATA 1.9 et versions ultérieures, consultez Rapports.

Description

Certains services envoient les informations d’identification du compte en texte brut. Cela peut même se produire pour les comptes sensibles. Les attaquants qui surveillent le trafic réseau peuvent intercepter et réutiliser ces informations d’identification à des fins malveillantes. Tout mot de passe en texte clair pour un compte sensible déclenche l’alerte, tandis que pour les comptes non sensibles, l’alerte est déclenchée si au moins cinq comptes différents envoient des mots de passe en texte clair à partir du même ordinateur source.

Enquête

Sélectionnez l’alerte pour accéder à sa page de détails. Découvrez quels comptes ont été exposés. S’il existe de nombreux comptes de ce type, sélectionnez Télécharger les détails pour afficher la liste dans une feuille de calcul Excel.

En règle générale, il existe un script ou une application héritée sur les ordinateurs sources qui utilise une liaison simple LDAP.

Remédiation

Vérifiez la configuration sur les ordinateurs sources et veillez à ne pas utiliser de liaison simple LDAP. Au lieu d’utiliser des liaisons simples LDAP, vous pouvez utiliser LDAP SALS ou LDAPS.

Échecs d’authentification suspects

Description

Dans une attaque par force brute, un attaquant tente de s’authentifier avec de nombreux mots de passe différents pour différents comptes jusqu’à ce qu’un mot de passe correct soit trouvé pour au moins un compte. Une fois trouvé, un attaquant peut se connecter à l’aide de ce compte.

Dans cette détection, une alerte est déclenchée lorsque de nombreux échecs d’authentification à l’aide de Kerberos ou NTLM se sont produits, ce qui peut être soit horizontalement avec un petit ensemble de mots de passe sur de nombreux utilisateurs ; ou verticalement avec un grand ensemble de mots de passe sur quelques utilisateurs seulement ; ou toute combinaison de ces deux options. La période minimale avant qu’une alerte puisse être déclenchée est d’une semaine.

Enquête

1. Sélectionnez Télécharger les détails pour afficher les informations complètes dans une feuille de calcul Excel. Vous pouvez obtenir les informations suivantes :
   • Liste des comptes attaqués
   • Liste des comptes devinés dans lesquels les tentatives de connexion se sont terminées avec une authentification réussie
   • Si les tentatives d’authentification ont été effectuées à l’aide de NTLM, vous verrez des activités d’événement pertinentes
   • Si les tentatives d’authentification ont été effectuées à l’aide de Kerberos, vous verrez les activités réseau pertinentes
2. Sélectionnez l’ordinateur source pour accéder à sa page de profil. Vérifiez ce qui s’est passé au moment de ces tentatives, en recherchant des activités inhabituelles, telles que : qui a été connecté, quelles ressources ont été consultées.
3. Si l’authentification a été effectuée à l’aide de NTLM et que vous voyez que l’alerte se produit plusieurs fois et qu’il n’y a pas suffisamment d’informations disponibles sur le serveur auquel la machine source a tenté d’accéder, vous devez activer l’audit NTLM sur les contrôleurs de domaine impliqués. Pour ce faire, activez l’événement 8004. Il s’agit de l’événement d’authentification NTLM qui inclut des informations sur l’ordinateur source, le compte d’utilisateur et le serveur auxquels l’ordinateur source a tenté d’accéder. Une fois que vous savez quel serveur a envoyé la validation d’authentification, vous devez examiner le serveur en vérifiant ses événements tels que 4624 pour mieux comprendre le processus d’authentification.

Remédiation

Les mots de passe complexes et longs fournissent le premier niveau de sécurité nécessaire contre les attaques par force brute.

Création d’un service suspect

Description

Les attaquants tentent d’exécuter des services suspects sur votre réseau. ATA déclenche une alerte lorsqu’un nouveau service qui semble suspect a été créé sur un contrôleur de domaine. Cette alerte s’appuie sur l’événement 7045 et elle est détectée à partir de chaque contrôleur de domaine couvert par une passerelle ATA ou une passerelle légère.

Enquête

1. Si l’ordinateur en question est une station de travail administrative ou un ordinateur sur lequel les membres de l’équipe informatique et les comptes de service effectuent des tâches administratives, il peut s’agir d’un faux positif et vous devrez peut-être supprimer l’alerte et l’ajouter à la liste Exclusions si nécessaire.

2. Le service est-il quelque chose que vous reconnaissez sur cet ordinateur ?

   • Le compte en question est-il autorisé à installer ce service ?

   • Si la réponse aux deux questions est oui, fermez l’alerte ou ajoutez-la à la liste Exclusions.

3. Si la réponse à l’une ou l’autre des questions est non, cela doit être considéré comme un vrai positif.

Remédiation

• Implémentez un accès moins privilégié sur les machines de domaine pour autoriser uniquement des utilisateurs spécifiques à créer des services.

Suspicion d’usurpation d’identité basée sur un comportement anormal

Description

ATA apprend le comportement de l’entité pour les utilisateurs, les ordinateurs et les ressources sur une période glissante de trois semaines. Le modèle de comportement est basé sur les activités suivantes : les machines auxquelles les entités se sont connectées, les ressources auxquelles l’entité a demandé l’accès et l’heure à laquelle ces opérations ont eu lieu. ATA envoie une alerte en cas d’écart par rapport au comportement de l’entité basé sur les algorithmes d’apprentissage automatique.

Enquête

1. L’utilisateur en question est-il censé effectuer ces opérations ?

2. Considérez les cas suivants comme des faux positifs potentiels : un utilisateur qui est revenu de vacances, le personnel informatique qui effectue un accès excessif dans le cadre de son travail (par exemple, un pic de support technique dans un jour ou une semaine donné), des applications bureau à distance.+ Si vous fermez et excluez l’alerte, l’utilisateur ne fera plus partie de la détection

Remédiation

Différentes actions doivent être effectuées en fonction de la cause de ce comportement anormal. Par exemple, si le réseau a été analysé, l’ordinateur source doit être bloqué sur le réseau (sauf s’il est approuvé).

Implémentation de protocole inhabituelle

Description

Les attaquants utilisent des outils qui implémentent différents protocoles (SMB, Kerberos, NTLM) de manière non standard. Bien que ce type de trafic réseau soit accepté par Windows sans avertissements, ATA est en mesure de reconnaître les intentions malveillantes potentielles. Le comportement indique des techniques telles que Over-Pass-the-Hash, ainsi que des exploits utilisés par des rançongiciels avancés, tels que WannaCry.

Enquête

Identifiez le protocole inhabituel : à partir de la ligne de temps de l’activité suspecte, sélectionnez l’activité suspecte pour accéder à la page de détails ; le protocole apparaît au-dessus de la flèche : Kerberos ou NTLM.

• Kerberos : souvent déclenché si un outil de piratage tel que Mimikatz a été potentiellement utilisé une attaque Overpass-the-Hash. Vérifiez si l’ordinateur source exécute une application qui implémente sa propre pile Kerberos, qui n’est pas conforme à la RFC Kerberos. Dans ce cas, il s’agit d’un vrai positif bénin et l’alerte peut être Fermée. Si l’alerte continue d’être déclenchée et que c’est toujours le cas, vous pouvez supprimer l’alerte.

• NTLM : Peut être WannaCry ou des outils tels que Metasploit, Medusa et Hydra.

Pour déterminer si l’activité est une attaque WannaCry, procédez comme suit :

1. Vérifiez si l’ordinateur source exécute un outil d’attaque tel que Metasploit, Medusa ou Hydra.

2. Si aucun outil d’attaque n’est trouvé, case activée si l’ordinateur source exécute une application qui implémente sa propre pile NTLM ou SMB.

3. Si ce n’est pas le cas, case activée si elle est provoquée par WannaCry en exécutant un script de scanneur WannaCry, par exemple ce scanneur sur l’ordinateur source impliqué dans l’activité suspecte. Si le scanneur détecte que la machine est infectée ou vulnérable, travaillez sur la mise à jour corrective de la machine, la suppression du programme malveillant et son blocage du réseau.

4. Si le script n’a pas trouvé que l’ordinateur est infecté ou vulnérable, il peut toujours l’être, mais SMBv1 a peut-être été désactivé ou la machine a été corrigée, ce qui affecterait l’outil d’analyse.

Remédiation

Appliquez les derniers correctifs à toutes vos machines et case activée toutes les mises à jour de sécurité sont appliquées.

1. Désactiver SMBv1

2. Supprimer WannaCry

3. Les données sous le contrôle de certains logiciels de rançon peuvent parfois être déchiffrées. Le déchiffrement n’est possible que si l’utilisateur n’a pas redémarré ou éteint l’ordinateur. Pour plus d’informations, consultez Want to Cry Ransomware

Remarque

Pour désactiver une alerte d’activité suspecte, contactez le support technique.

Voir aussi

• Playbook ata sur les activités suspectes
• Consultez le forum ATA !
• Utilisation d’activités suspectes