Guide d'activité suspecte d'Advanced Threat Analytics

S’applique à : Advanced Threat Analytics version 1.9

Après une enquête appropriée, toute activité suspecte peut être classifiée comme suit :

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

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

• Faux positif : une fausse alarme, ce qui signifie que l’activité n’a pas eu lieu.

Pour plus d’informations sur la gestion des alertes ATA, consultez Travail avec les activités suspectes.

Pour 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 l’alerte lorsqu’un ajout anormal à un groupe sensible est vu. 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 de 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 l’outil this.

Enquête

1. La modification du groupe est-elle légitime ?
   Les 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 bénin.

2. Si l'objet ajouté était un compte d'utilisateur, vérifiez quelles actions le compte d'utilisateur a entrepris 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 d’autres activités suspectes associées au compte avant ou après l’ajout ? Téléchargez le rapport de modification de groupe sensible pour voir quelles autres modifications ont été apportées et par qui au cours de la même période.

Correction

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

Configurez Gestion des accès privilégiés pour Active Directory le cas échéant.

Confiance brisée entre les ordinateurs et le domaine

Description

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

Enquête

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

• Si oui, vous pouvez ignorer cet ordinateur dans les étapes de correction.

Correction

Rejoindre à nouveau la machine au domaine si nécessaire ou réinitialiser le mot de passe de la machine.

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

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 quand ATA détecte un nombre massif d’authentifications de liaison simples. Cela peut être horizontalement avec un petit ensemble de mots de passe pour de nombreux utilisateurs ; ou verticalement » avec un grand ensemble de mots de passe sur seulement quelques utilisateurs ; ou toute combinaison de ces deux options.

Enquête

1. Si de nombreux comptes sont impliqués, sélectionnez Download details 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 avec une authentification réussie. Les tentatives apparaitraient comme Comptes devinés sur le côté droit de l'infographie. Si oui, les comptes supposés sont-ils habituellement utilisés à partir de l’ordinateur source ? Si c’est le cas, 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 c’est le cas, supprimez l’activité suspecte.

Correction

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

Activité de rétrogradation du chiffrement

Description

La rétrogradation du chiffrement est une méthode d’affaiblissement de 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 cypher 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 des contrôleurs de domaine et permet l’authentification au 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 message KRB_ERR 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 de TGS_REQ (demande de service) de l’ordinateur source a été rétrogradée par rapport au comportement précédemment appris. Ce n’est pas basé sur une anomalie temporelle (comme dans l’autre détection Golden Ticket). En outre, aucune demande d’authentification Kerberos n’a été 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 pour créer un ticket fort à l'aide d'une requête AS Kerberos. 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 utilise AES).

Enquête

Vérifiez d'abord la description de l'alerte pour voir avec quel type de détection parmi ceux-ci vous êtes confronté. 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 Network. Vous verrez que le champ rétrogradé approprié est Request Ticket Encryption Type et Source Computer Supported Encryption Types répertorie les méthodes de chiffrement plus fortes. 1.Vérifiez l’ordinateur source et le compte, ou s’il existe plusieurs ordinateurs sources et comptes, vérifiez s’ils ont quelque chose en commun (par exemple, tous les membres du personnel marketing utilisent une application spécifique susceptible d’entraîner le déclenchement de l’alerte). Il existe des cas dans lesquels une application personnalisée rarement utilisée s'authentifie à l'aide d'un chiffrement plus faible. Vérifiez s’il existe de telles applications personnalisées sur l’ordinateur source. Si c’est le cas, il s'agit probablement d'un vrai positif bénin et vous pouvez le neutraliser. 2. Vérifiez la ressource utilisée par ces tickets. S'il y a une ressource à laquelle ils accèdent tous, validez-la et assurez-vous qu'il s'agit bien d'une ressource qu'ils sont censés accéder. Vérifiez également si la ressource cible prend en charge des méthodes de chiffrement fortes. Vous pouvez le vérifier 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 rétrogradé approprié est Type de chiffrement de l'horodatage chiffré et Types de chiffrement pris en charge par l'ordinateur source contient des méthodes de chiffrement plus fortes. 1.Il existe des cas dans lesquels cette alerte peut être déclenchée lorsque les utilisateurs se connectent à l’aide de cartes à puce si la configuration de carte à puce a été modifiée récemment. Vérifiez s’il y a eu des modifications comme celles-ci 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, validez cette ressource et assurez-vous qu'ils sont censés y accéder. Vérifiez également si la ressource cible prend en charge des méthodes de chiffrement fortes. Vous pouvez le vérifier dans Active Directory en vérifiant l’attribut msDS-SupportedEncryptionTypes, du compte de service de ressources.

Correction

1. Skeleton Key : supprimez les programmes malveillants. Pour plus d’informations, consultez Skeleton Key Malware Analysis.

2. suivez les instructions relatives aux activités suspectes du Golden Ticket. En outre, étant donné que la création d’un Golden Ticket nécessite des droits d’administrateur de domaine, implémentez les recommandations « Pass the hash ».

3. Overpass-the-Hash : si le compte impliqué n’est pas sensible, réinitialisez le mot de passe de ce compte. Cela empêche l’attaquant de créer de nouveaux 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 du KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine, il est donc important de planifier avant de procéder. Voir les directives dans l’article sur le compte KRBTGT. Étant donné qu’il s’agit d’une technique de mouvement latéral, suivez les meilleures pratiques des recommandations de « Pass the hash ».

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 laissés inutilisés, tout en ayant un nom attrayant pour attirer les attaquants (par exemple, SQL-Admin). Toute activité à partir d’eux peut indiquer un comportement malveillant.

Pour plus d’informations sur les comptes de jetons 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 à la ou les pages de profil de l’ordinateur source et vérifiez les autres comptes authentifiés à partir d’eux. Contactez les propriétaires de ces comptes s’ils utilisaient le compte Honeytoken.

3. Il peut s’agir d’une connexion non interactive. Veillez donc à rechercher 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 bénigne, supposons que cela est malveillant.

Correction

Assurez-vous que les comptes Honeytoken sont utilisés uniquement à des fins prévues, sinon ils peuvent générer de nombreuses alertes.

Vol d’identité par 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 appartenant ou utilisé régulièrement par l’utilisateur ciblé ? Si oui, l’alerte est un faux positif, sinon, c’est probablement un vrai positif.

Correction

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 de nouveaux tickets Kerberos à partir du hachage de mot de passe. Les tickets existants sont toujours utilisables jusqu’à leur expiration.

2. Si le compte impliqué est sensible, envisagez de réinitialiser le compte KRBTGT deux fois, comme dans l’activité suspecte Golden Ticket. La réinitialisation de KRBTGT invalide deux fois tous les tickets Kerberos de domaine. Planifiez donc l’impact avant de le faire. Voir les directives dans l’article sur le compte KRBTGT. Comme il s’agit généralement d’une technique de mouvement latéral, suivez les meilleures pratiques des recommandations de Pass the Hash.

Vol 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-traité, 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 des tickets pour le compte des utilisateurs ? Si c’est le cas, c’est un véritable positif bénin.

Correction

1. Si le compte impliqué 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 de nouveaux tickets Kerberos à partir du hachage de mot de passe. Tous les tickets existants restent utilisables jusqu’à 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 du KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine, il est donc important de planifier avant de procéder. Voir les directives dans l’article sur le compte KRBTGT. Étant donné qu’il s’agit d’une technique de mouvement latéral, suivez les meilleures pratiques dans Pass the hash recommendations.

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 TGT faux 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 plus que le temps autorisé autorisé, tel que spécifié dans la durée de vie maximale de la stratégie de sécurité des tickets utilisateur.

Enquête

1. Une modification récente (au cours des dernières heures) a-t-elle été apportée à la durée de vie maximale du paramètre de ticket utilisateur dans la stratégie de groupe ? Si oui, fermez l’alerte (c’était un faux positif).

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

3. Si la réponse aux questions ci-dessus n’est pas, supposons que cela est malveillant.

Correction

Modifiez deux fois le mot de passe du ticket d’octroi de ticket Kerberos (KRBTGT) en fonction des instructions de l’article du compte KRBTGT. La réinitialisation du KRBTGT deux fois invalide tous les tickets Kerberos dans ce domaine, il est donc important de planifier avant de procéder. En outre, étant donné que la création d’un Golden Ticket nécessite des droits d’administrateur de domaine, implémentez les recommandations « Pass the hash ».

Demande malveillante de renseignements sur la protection des données personnelles

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é principale pour déchiffrer les secrets protégés par DPAPI sur tous les ordinateurs joints à 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é principale de sauvegarde.

Enquête

1. L’ordinateur source exécute-t-il un scanneur de sécurité avancé approuvé par l’organisation 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.

Correction

Pour utiliser DPAPI, un attaquant a besoin de droits d’administrateur de domaine. Implémentez les recommandations pour 'Pass the hash'.

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 rencontre 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 de 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 sont accessibles.

Correction

Validez les autorisations suivantes :

• Répliquer les modifications du répertoire

• Répliquer toutes les modifications du répertoire

Pour plus d’informations, voir Accorder une autorisation des Services de domaine Active Directory pour la synchronisation des profils dans SharePoint Server 2013. Vous pouvez tirer parti de AD ACL Scanner ou créer un script PowerShell Windows 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é. 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 View 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 métier qui justifie une suppression à grande échelle.

Correction

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 a des données d’autorisation utilisateur (dans Active Directory il s’agit de l’appartenance au groupe) et accorde des privilèges supplémentaires aux attaquants.

Enquête

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

2. L’ordinateur de destination (sous la colonne ACCÈS ) 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 s’exécute-t-il (sous la colonne FROM ) un système d’exploitation/application connu pour modifier le PAC ? Si oui, supprimez l’activité suspecte (c’est un vrai positif bénin).

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

Correction

Vérifiez que tous les contrôleurs de domaine dotés de systèmes d’exploitation jusqu’à Windows Server 2012 R2 sont installés avec KB3011780 et tous les serveurs membres et contrôleurs de domaine jusqu’à 2012 R2 sont à jour avec KB2496930. Pour plus d’informations, consultez Silver PAC et Forge PAC.

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

Description

Dans la reconnaissance de l’énumération de compte, un attaquant utilise un dictionnaire avec des milliers de noms d’utilisateurs ou des outils tels que KrbGuess pour tenter de deviner les 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 de nom principal de sécurité inconnu.

Dans cette détection, ATA peut détecter l’emplacement de l’attaque, le nombre total de tentatives de estimation 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 déterminer si des comptes existent (par exemple, Exchange serveurs) ?

2. Existe-t-il un script ou une application s’exécutant sur l’hôte qui peut générer ce comportement ?

   Si la réponse à l’une de ces questions est oui, fermez l’activité suspecte (c’est 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ées en comptes existants et non existants. Si vous examinez la feuille des comptes non existants dans la feuille de calcul et que les comptes vous semblent familiers, ils peuvent être des comptes désactivés ou des employés qui ont quitté l'entreprise. Dans ce cas, il est peu probable que la tentative provique d’un dictionnaire. Il s'agit probablement d'une application ou d'un script qui vérifie les comptes qui existent toujours dans Active Directory, ce qui signifie qu'il s'agit d'un vrai positif bénin.

4. Si les noms sont largement inconnus, l’une des tentatives devinage correspond-elle aux noms de compte existants dans Active Directory ? S’il n’y a aucune correspondance, la tentative a été futile, mais vous devez prêter attention à l’alerte pour voir si elle est mise à jour au fur et à mesure.

5. Si l’une des tentatives devinage correspond aux noms de compte existants, l’attaquant connaît 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 détecter des activités suspectes supplémentaires. Vérifiez si l’un des comptes correspondants est sensible.

Correction

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’annuaire et cibler des comptes privilégiés pour les étapes ultérieures d’une attaque. Le protocole Remote (SAM-R) du Gestionnaire de compte de sécurité est l’une des méthodes utilisées pour interroger le répertoire pour effectuer ce mappage.

Dans cette détection, aucune alerte n’est déclenchée au cours du premier mois après le déploiement d’ATA. Pendant la période d’apprentissage, les profils ATA enregistrent depuis quels ordinateurs les requêtes SAM-R sont effectuées, tant pour l’énumération que pour les requêtes individuelles de 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, par les administrateurs d'entreprise ou l'administrateur) et si elles ont été réussies 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 n’était pas à toutes les questions ci-dessus, supposons qu’elle est malveillante.

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

Correction

1. L’ordinateur exécute-t-il un outil d’analyse des vulnérabilités ?
2. Examinez si les utilisateurs et les 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 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 pour le mouvement latéral.

Reconnaissance à l’aide du 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 demande AXFR (Transfer) provenant de serveurs non DNS.

Enquête

1. La machine source (provenant de...) est-elle 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, vérifiez quels domaines ont été interrogés. Est-ce que ces domaines existent ? Si oui, fermez l’activité suspecte (c’est 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 à enquêter 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 sont accessibles.

Correction

La sécurisation d’un serveur DNS interne pour empêcher la reconnaissance à l’aide du 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 à partir des attaques internes et externes.

Reconnaissance par énumération de sessions 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/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é s’exécutant sur l’ordinateur source ? Si oui, fermez et excluez l’activité suspecte.

2. Vérifiez quel utilisateur/s impliqué a effectué l’opération. Ils se connectent normalement à l’ordinateur source ou sont-ils administrateurs qui doivent effectuer ces 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 à toutes les questions ci-dessus n’est pas, supposons que l’activité est malveillante.

Correction

1. Isolez 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 compromissent les informations d’identification d’administration ou qui utilisent un exploit de zéro jour peuvent exécuter des commandes distantes sur votre contrôleur de domaine. Cela peut être utilisé pour obtenir la persistance, collecter des informations, des 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 administratives, ainsi que pour les membres de l’équipe informatique et les comptes de service qui effectuent des tâches administratives sur des contrôleurs de domaine. Si c’est le cas, et que l’alerte est mise à jour, car le même administrateur ou l’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 des deux questions est non, cette activité doit être considérée comme un véritable 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 sont accessibles.

Correction

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 ordinateurs renforcés à 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

Description

Certains services envoient des informations d’identification de 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 de texte clair pour un compte sensible déclenche l’alerte, tandis que pour les comptes non sensibles, l’alerte est déclenchée si cinq comptes ou plus différents envoient des mots de passe de 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 Download details 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 utilisent une liaison simple LDAP.

Correction

Vérifiez la configuration sur les ordinateurs sources et veillez à ne pas utiliser la 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 utilisant Kerberos ou NTLM se sont produits, cela peut être horizontalement avec un petit ensemble de mots de passe pour 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 Download details 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 les 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 sont accessibles.
3. Si l’authentification a été effectuée à l’aide de NTLM et que l’alerte se produit plusieurs fois et qu’il n’y a pas suffisamment d’informations disponibles sur le serveur auquel l’ordinateur source a essayé 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 essayé 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.

Correction

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

Création suspecte de service

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 d’administration, 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 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 n’est pas, cela doit être considéré comme un vrai positif.

Correction

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

Suspicion de vol d’identité en fonction d’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 connectent, les ressources auxquelles l’entité a demandé l’accès et l’heure à laquelle ces opérations ont eu lieu. ATA envoie une alerte lorsqu’il existe un écart par rapport au comportement de l’entité en fonction des algorithmes de Machine Learning.

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 retourné par des vacances, le personnel informatique qui effectue un accès excédentaire dans le cadre de son devoir (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.

Correction

Différentes actions doivent être effectuées en fonction de ce qui a provoqué ce comportement anormal. Par exemple, si le réseau a été analysé, la machine source doit être bloquée du réseau (sauf si elle est approuvée).

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 avertissement, ATA est en mesure de reconnaître l’intention malveillante potentielle. Le comportement indique des techniques telles que Over-Pass-the-Hash, ainsi que des exploits utilisés par des ransomwares avancés, tels que WannaCry.

Enquête

Identifiez le protocole inhabituel : à partir de la ligne de temps d’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é pour mener 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 au 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 qu’elle 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é, vérifiez 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, vérifiez s’il est dû à 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 l’ordinateur est infecté ou vulnérable, travaillez sur la mise à jour corrective de l’ordinateur et supprimez le programme malveillant et bloquez-le du réseau.

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

Correction

Appliquez les derniers correctifs à toutes vos machines et vérifiez que toutes les mises à jour de sécurité sont appliquées.

1. Désactiver SMBv1

2. Supprimer WannaCry

3. Les données dans 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 désactivé l’ordinateur. Pour plus d’informations, voir Le rançongiciel WannaCrypt cible les systèmes obsolètes

Voir aussi

• Manuel sur l'analytique des menaces avancées pour les activités suspectes
• Consultez le forum ATA !
• Gestion des activités suspectes