SecurityInsider
Le blog des experts sécurité Wavestone

« Microsoft Advanced Threat Analytics », quelles conclusions tirer de la version d’évaluation ?


Une volonté de découvrir Microsoft ATA par la pratique

Dès la sortie de sa version d’évaluation en mai dernier, Microsoft Advance Threat Analytics (ATA) a suscité une grande curiosité chez les communautés sécurité, et pour cause, Microsoft nous promet un outil facile d’utilisation et très efficace dans la détection d’intrusions. Pour rappel, il propose trois fonctionnalités principales :
  • Détecter l’exécution des schémas d’attaques connus : Brute-force[1], Pass-the-Hash[2], Pass-the-Ticket[3], etc.
  • Détecter les comportements suspicieux en analysant l’activité des utilisateurs légitimes.
  • Détecter les failles de sécurité : politique de mots de passe faible, utilisation de protocoles obsolètes, droits trop permissifs, etc.
Solucom s’étant intéressé à Microsoft ATA dès son lancement, notamment en publiant un article[4] sur la présentation et les promesses de l’outil, nous avons souhaité concrétiser notre analyse en testant sa version d’évaluation et en vous exposant ainsi nos résultats.

Le périmètre des tests

Nous avons effectué les tests dans un environnement virtuel composé de cinq machines. Toutes font partie du domaine contoso05.com :
  • Un contrôleur de domaine : serveur Active Directory sous Windows Server 2012 dont le nom est « ad.contoso05.com » et l’adresse IP est « 10.100.203.11 ».
  • Un ATA Center : serveur de supervision de Microsoft ATA sous Windows Server 2012 dont le nom est « ata-center.contoso05.com ».
  • Un ATA Gateway : serveur sonde Microsoft ATA sous Windows Server 2012 dont le nom est « ata-gateway.contoso05.com ».
  • Un serveur de domaine : serveur sous Windows Server 2012 dont le nom est « user01.contoso05.com ».
  • Un poste utilisateur de domaine : poste de travail sous Windows 8 dont le nom est « user02.contoso05.com ».
Toutes les attaques menées pour tester la détection ont ciblé le contrôleur de domaine. Les autres serveurs ne sont pas inclus dans le périmètre de supervision géré par l’outil en version d’évaluation.

Vu que l’environnement fictif que nous avons utilisé pour réaliser nos tests ne comporte que peu de machines et peu d’activités d’exploitation, la fonction de détection des comportements suspects et celle de la détection des risques n’ont pas été testées et évaluées. Un test complet de ces deux fonctionnalités aurait nécessité une infrastructure plus complète et réaliste ainsi qu’une activité quotidienne des utilisateurs sur plusieurs jours. Un tel environnement « en conditions réelles » est relativement complexe à mettre en place.

La courte période de validité de la version d’évaluation nous a aussi poussé à nous focaliser sur les tests de détection des schémas d’attaques connus.
 Figure 1 : Architecture de test utilisée

Les tests réalisés

Reconnaissance DNS

La reconnaissance DNS consiste à envoyer des requêtes au serveur DNS afin de mieux comprendre le fonctionnement du système d’information cible. Le transfert de zone[5] en est un exemple ; il consiste à demander au contrôleur de domaine de transférer toutes les informations stockées sur les zones qu’il connait. 

Il est important de noter que ce type de transfert devrait être contrôlé et ne devrait se faire qu’entre des contrôleurs de domaines.

Le test qui suit consiste à essayer d’initier un transfert de zone du contrôleur de domaine vers un poste de travail quelconque. Une simple invite de commande suffit :
 Figure 2 : Envoi d’une demande de transfert de zone au contrôleur de domaine 

La réponse de Microsoft ATA est presque immédiate ; une alerte est levée et plusieurs recommandations sont proposées pour se protéger de ce type attaques :
 Figure 3 : Réponse de Microsoft ATA à la demande de transfert de zone

Le résultat de ce premier test correspond à nos attentes, et les recommandations proposées par ATA sont pertinentes.

Brute-force

Cette attaque consiste à essayer d’accéder à la session d’un utilisateur en testant plusieurs combinaisons possibles de mots de passe. Il est possible de réaliser cette attaque en se basant sur un dictionnaire (une liste contenant un grand nombre de mots de passe), plus la liste est longue et plus il y a de chance que le mot de passe s’y trouve.

Dans le test qui suit, nous avons mené une attaque par brute-force sur le compte « administrator » en utilisant le module SMB Login de Metasploit[6] et une liste de trois millions de mots de passe :
Figure 4 : Déroulement d’une attaque par brute-force qui cible le contrôleur de domaine 

Malgré la présence des logs de sécurité qui attestent des tentatives infructueuses de connexion, aucune alerte n’a été levée par Microsoft ATA.
Figure 5 : Logs de sécurité du contrôleur de domaine

Après quelques heures, l’attaque a bien abouti et le mot de passe du compte « administrator » a été révélé.

En définitive, nous n’avons pas pu détecter l’attaque par brute-force par le biais de Microsoft ATA. 

Pass-the-Hash

L’attaque Pass-the-Hash consiste à utiliser des hash de mots de passe volés pour s’authentifier auprès de machines distantes. Elle permet ainsi de contourner l’authentification classique qui requiert la connaissance du mot de passe de l’utilisateur.  
Ce schéma, extrait du document « Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques », proposé par Microsoft, explique le déroulement de cette attaque :
  1. L’attaquant commence par compromettre un premier poste de travail en utilisant une quelconque méthode.
  2. Après qu’il ait obtenu des droits d’administrateur local, il exporte les hash de mots de passe présents sur le poste compromis.
  3. Ensuite, il utilise ces hash afin de se propager sur d’autres machines du domaine.

Figure 6 : Déroulement d’une attaque Pass-the-Hash

Pour tester cette attaque, nous avons supposé qu’un attaquant ait eu accès à l’une des machines du domaine et qu’il y ait trouvé le hash du mot de passe de l’administrateur.

Nous avons donc commencé par exporter le hash du mot de passe de l’administrateur du contrôleur de domaine afin de l’utiliser dans notre attaque (en utilisant l’outil Mimikatz[7]).
Figure 7 : Exportation des hash de mots de passe

Ensuite, nous avons utilisé le module PSExec de Metasploit pour essayer de se connecter depuis un poste de travail distant (user02.contoso05.com) au contrôleur de domaine en utilisant le hash volé :
Figure 8 : Déroulement de l’attaque Pass-the-Hash

L’attaque aboutit mais une alerte est levée dans la console d’administration de Microsoft ATA :
Figure 9 : Réponse de Microsoft ATA à l’attaque Pass-the-Hash

Si nous essayons de nous connecter à distance avec le programme PSExec[8], le même résultat est obtenu à la différence près que Microsoft ATA spécifie cette fois-ci le service qui a été créé (PSEXESVC) :

Figure 10 : Réponse de Microsoft ATA à une tentative de connexion à distance en utilisant PSExec

Dans les deux cas précédents, c’est la création d’un service sur le système attaqué qui déclenche l’alerte. Pour vérifier si toutes les utilisations du Pass-the-hash sont détectées, nous avons combiné cette attaque avec le module SMB_login qui ne crée pas de service : 
 Figure 11 : Déroulement de l’attaque Pass-the-Hash en utilisant le module SMB_login

Après le déroulement de cette attaque, aucune alerte n’a été levée par Microsoft ATA.

Ainsi, seules les méthodes d’attaque Pass-the-Hash nécessitant la création d’un service sur la machine cible sont détectables par Microsoft ATA

Pass-the-Ticket

L’attaque Pass-the-Ticket est semblable à l’attaque Pass-the-Hash, à la différence qu’elle utilise un ticket Kerberos volé pour usurper la session d’un utilisateur (au lieu du hash de mot de passe).

Afin de tester cette attaque, nous avons supposé qu’un attaquant ait eu accès à l’une des machines du domaine et qu’il y ait trouvé un ticket permettant d’usurper l’identité de l’administrateur.

Nous avons donc commencé par exporter les tickets Kerberos présents sur le contrôleur de domaine pour les utiliser lors de l’attaque. Pour cela nous avons utilisé l’outil Mimikatz :
 Figure 12 : Exportation des tickets Kerberos

Les tickets sont exportés vers un dossier prédéfini :
 Figure 13 :Tickets Kerberos présents sur le contrôleur de domaine

Le ticket qui nous intéresse est : [0;334fa]-2-0-40e10000-Administrator@krbtgt-CONTOSO05.COM.kirbi. Ce dernier nous permettra en effet d’accéder à la session de l’administrateur.

Il faut noter qu’avant d’avoir utilisé ce ticket sur la machine user02.contoso05.com, l’utilisateur local n’avait pas les droits d’accès au contrôleur de domaine
Figure 14 : Réponse à une tentative de connexion de l’utilisateur local au contrôleur de domaine

Toujours sur la même machine (user02.contoso05.com), nous avons alors importé le ticket Kerberos précédemment prélevé du contrôleur de domaine en utilisant Mimikatz. 
Figure 15 : Importation du ticket Kerberos de l’administrateur sur la machine user02.contoso05.com

En réessayant à nouveau d’accéder au contrôleur de domaine, l’accès est autorisé et aucun mot de passe n’est demandé. En effet, l’utilisateur local utilise le ticket de l’administrateur au lieu de son propre ticket.
Figure 16 : Réponse à une tentative de connexion de l’utilisateur local au contrôleur de domaine après importation du ticket Kerberos de l’administrateur

Suite à ce test, nous avons remarqué qu’aucune alerte n’a été levée dans le tableau de bord de Microsoft ATA.

Conclusion

Les tests réalisés se sont concentrés autour de l’évaluation de la fonctionnalité de détection des attaques connues de Microsoft ATA. Pour ce faire, les attaques par reconnaissance DNS, brute-force, Pass-the-Hash et Pass-the-Ticket ont été initiées.

En considérant l’infrastructure de tests choisie, ces quatre attaques, pourtant relativement classiques, n’ont pas pu toutes être détectées par l’outil. L’exécution de certaines méthodes de Pass-the-Hash, les attaques Pass-the-Ticket et les attaques par brute-force n’ont par exemple soulevé aucune alerte dans la console Microsoft.

Pour autant, nous prévoyons d’autres séries de tests sur la version officielle de Microsoft ATA qui, nous l’espérons, aura évolué permettant ainsi de respecter toutes ses promesses !


Baptistin BUCHET
Adam KETTANI

Aucun commentaire:

Enregistrer un commentaire