Microsoft Advanced Threat Analytics (ATA) : Simulation des attaques
Dans le précédent billet, Introduction à Microsoft Advanced Threat Analytics (ATA) https://blogs.technet.com/b/byod-fr/archive/2016/01/02/introduction-a-microsoft-advanced-threat-analytics-ata.aspx, j’ai expliqué les mécanismes utilisés par ATA pour contrer les attaques sur le réseau interne de l’entreprise en cumulant deux fonctionnalités que sont la détection des menaces et la détection des comportements anormaux par l’utilisation du Machine Learning. Et qui dit Machine Learning, dit qu’il est nécessaire d’avoir une phase d’apprentissagependant laquelle ATA va découvrir son environnement conceptualisé par des entités représentant les utilisateurs, ordinateurs, serveurs, mobiles visibles sur le réseau et leur comportement : c’est à travers l’analyse des variations qu’ATA pourra détecter des comportements douteux mettant en évidence qu’un attaquant est dans la place, et que l’on pourra mettre en place des mesures pour contrecarrer sa progression.
Pour une meilleure compréhension, je vous conseille d’ailleurs vivement de commencer par lire le précédent billet avant de vous intéresser à la reproduction des scénarios d’attaque.
Pourquoi ce billet ?
Le premier réflexe de toute personne technique intéressée sera de mettre en place la solution ATA sur une plateforme de test et de vérifier si les attaques données comme étant détectées le sont effectivement (Voir https://technet.microsoft.com/en-us/library/dn707706.aspx).
Bien sûr, on ne peut pas voir la « soupe magique » utilisée par ATA pour corréler et analyser les événements mais on est directement intéressé pour vérifier son efficacité ; et c’est là que les choses se corsent, car il n’est pas facile de simuler sur un environnement de maquette une vraie infrastructure de production pour s’assurer que la détection comportementale permet réellement de détecter les prémices d’une attaque.
On trouve sur le blog ATA des « y a rien qui marche » https://social.technet.microsoft.com/Forums/security/en-US/home?forum=mata; l’objectif est donc de vous fournir quelques éléments vous permettant de comprendre les mécanismes d’attaque désormais bien connus tels que Pass-The-Hash (PtH) et Pass-The-Ticket (PtT) mais également de les tester sur une maquette ATA.
ATA vs bonnes pratiques ?
L’utilisation d’un outil de détection comme ATA n’est pas la solution magique et ne doit pas vous exonérer de mettre en place les mesures de protection décrites dans les 2 documents “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft”, Version 1 and 2 https://www.microsoft.com/en-gb/download/details.aspx?id=36036 datés, rappelons-le, de 2012.
La mise en place de ces bonnes pratiques permet de limiter la surface d’attaque de votre SI et de contenir les attaques : plus on réduit la surface d’attaque en implémentant les bonnes pratiques, plus on limite le risque d’infection et de propagation. Investir dans des mesures de protection n’est certes pas quelque chose de très visible et donc de facilement justifiable d’un point de vue financier sauf, malheureusement, après coup.
On a pu cependant remarquer que des budgets impossibles à débloquer en temps normal pour renforcer des mesures de sécurité, devenaient soudainement disponibles pour remettre un SI en ordre de marche après découverte d’une compromission généralisée.
ATA apporte une solution complémentaire dans votre arsenal de défense : il est difficile de contrer une attaque, lorsque l’on n’est pas en mesure de détecter des signaux faibles. Même si l’ignorance peut passer pour une situation agréable (« cela n’arrive qu’aux autres ») jusqu’à la découverte, souvent fortuite, de l’infection, le réveil s’avère en général difficile.
Attaques et Activités suspectes
Parmi les attaques « déterministes », nous allons nous intéresser aux deux familles que sont, les attaques de type reconnaissance (reconnaissance DNS et énumération de comptes), et les attaques par mouvement latéral, les plus critiques étant PtH, PtT et exécution à distance.
Concernant les autres types d’attaques, elles sont plus difficiles à reproduire puisque mettant en œuvre la détection des comportements anormaux associés à une phase d’apprentissage.
Sans minimiser sa criticité, l’attaque Golden Ticket nécessite que l’attaquant ait déjà compromis un contrôleur de domaine, ce qui correspond à la phase finale de l’attaque ; on devrait pouvoir limiter la casse mais les jeux sont quasiment déjà faits. (Cf https://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf).
L’attaque Forge PAC (MS14-068) utilise une vulnérabilité corrigée depuis plus d’un an (voir « Une vulnérabilité dans Kerberos pourrait permettre une élévation de privilèges » https://technet.microsoft.com/library/security/MS14-068. Si vos contrôleurs de domaine sont correctement patchés, ils ne sont plus vulnérables mais la détection est toujours intéressante car elle signifie que vous êtes sous attaque !
L’attaque Skeleton Key est plus récente. Mais ceci pourra faire le sujet d’un prochain billet.
Passons maintenant à la description des attaques.
1- Reconnaissance DNS
Après avoir compromis un poste ou un serveur, l’attaquant va classiquement tenter de découvrir l’environnement dans lequel il va pouvoir évoluer et va donc mener une action de reconnaissance. Un référentiel intéressant est évidemment l’annuaire DNS qui fournit la liste des noms des ordinateurs du domaine avec leur adresse IP.
Une simple ligne de commande nslookup permet d’essayer de lister la zone correspondante au domaine consoto.com.
On remarquera que, bien que la tentative soit infructueuse, elle déclenche une alerte dans la console ATA. L’ordinateur depuis lequel est effectuée la tentative est indiqué (PC-JHACKER) ainsi que le serveur DNS cible (ici DC01).
2- Reconnaissance avec énumération de comptes
Cette reconnaissance consiste à utiliser un outil (un script java, krbguess) qui initie une tentative d’authentification Kerberos avec un nom d’utilisateur et analyse ensuite la réponse. Le script prend en entrée un dictionnaire de noms d’utilisateurs pour tenter de deviner ceux qui sont présents dans l’annuaire Active Directory.
Pour l’attaquant, l’intérêt de ce script est qu’il ne provoque pas d’événements dans le journal Windows car c'est uniquement la première étape d'une authentification qui ne correspond pas à une authentification infructueuse. Mais bien sûr, ce type d’attaque n’échappe pas à ATA ;-)
La console ATA indique l’ordinateur depuis lequel la reconnaissance a été lancée, le nombre de tentatives avec les noms d’utilisateur associés, et les éventuels essais réussis avec les noms de comptes existants ayant été détectés.
Note: Pour cette attaque, il faut attendre un certain délai (des fois plusieurs minutes) avant que la reconnaissance soit détectée et l’alerte levée.
3- Attaque Pass-The-Hash
Une attaque Pass-The-Hash (PtH) utilise une technique par laquelle un attaquant capture les informations d’authentification d’un compte utilisateur sur un ordinateur, puis les utilise pour s’authentifier à d'autres ordinateurs sur le réseau. Une attaque PtH est très similaire dans le concept à une attaque de vol de mot de passe, mais il repose sur le vol et la réutilisation de hash de mot de passe plutôt que le mot de passe en clair. En effet, le hash du mot de passe (ou NT Hash) peut être utilisé directement comme un authentificateur pour accéder à des services pour le compte de l'utilisateur comme, par exemple, une connexion SMB sur un partage réseau (le hash est de fait le secret partagé entre le poste de l’utilisateur et le contrôleur de domaine).
Contrairement à une attaque profitant d’une faille comme MS14-068 et qui peut résulter d’une erreur dans l’implémentation (erreur de programmation), d’une faiblesse dans un protocole, etc., l’attaque PtH est basée sur le fait que,
- pour des besoins de SSO, les credentials de l’utilisateur sont présents en mémoire dans le processus de sécurité de Windows (Local Security Authority Subsystem Service ou LSASS)
- lorsque l’on est administrateur local d’un poste, on peut appeler des fonctions privilégiées du système qui permettent d’accéder à ces informations (par définition l’administrateur est omnipotent).
- si un compte avec plus de privilèges qu’un utilisateur standard se connecte sur le PC – par exemple pour des besoins de HelpDesk –, que ce soit en ouvrant une session locale ou à distance en RDP, il sera possible d’accéder à ses informations et pouvoir dès lors profiter de ses privilèges plus élevés (attaque par élévation de privilèges).
Il est donc inutile, vous l’aurez compris, de demander à Microsoft un correctif de sécurité pour corriger ce problème.
Une autre caractéristique de ce type d’attaque est le mouvement latéral : l’attaquant va passer de poste en poste pour « moissonner » des informations d’authentification au gré de ses déplacements ; son objectif est de pouvoir arriver à capturer les credentials de comptes privilégiés pour accéder à des informations sensibles ou prendre possession de l’infrastructure s’il a la « chance » de tomber sur un compte administrateur du domaine.
Pour une meilleure compréhension, je vous conseille vivement la lecture des 2 documents Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques https://www.microsoft.com/en-gb/download/details.aspx?id=36036
Pour simuler une attaque PtH, on utilise l’outil Windows Credential Editor (WCE) développé par la société Amplia Security. Il suffit de lancer WCE sur le poste compromis depuis le compte administrateur local de la machine pour lister le NTHash de l’utilisateur ayant une session ouverte sur le poste. Ici l’attaquant est chanceux car l’utilisateur jtrevages est administrateur du domaine (dans un cas réel, le moissonnage aurait sans doute nécessité de nombreux sauts).
L’attaquant se déplace sur un autre poste compromis (déplacement latéral) pour réinjecter le NT Hash dans une session administrateur local.
Pour vérifier que l’on a bien acquis les droits d’administrateur du domaine, il suffit d’ouvrir une connexion réseau sur le répertoire C$ du contrôleur de domaine.
C’est bon ! On a accès au contrôleur de domaine. Mais ATA veille et cette dernière action provoque l’apparition d’une alerte dans la console ATA.
L’alerte est identifiée comme critique et renseigne sur le compte utilisateur dont l’identité a été usurpée (jtrevages), le poste depuis lequel l’action a été effectuée (PC-JHACKER) et fournit des recommandations.
4- Attaque Pass-The-Ticket
Une attaque Pass-The-Ticket (PtT) est très similaire à l’attaque précédente. Depuis un poste compromis sur lequel l’attaquant dispose de privilèges élevés, par exemple administrateur local, il va utiliser un outil lui permettant d’extraire les informations d’authentification depuis la mémoire du processus privilégié LSASS. Dans le cas de PtT c’est le jeton Kerberos de l’utilisateur (le TGT ou Ticket Granting Ticket) qui est intéressant.
L’attaquant va ensuite injecter ce ticket Kerberos sur un autre poste (n’oubliez pas le mouvement latéral) pour accéder aux ressources réseau sous le compte de l’utilisateur dont l’identité a été usurpée.
Là encore, tout repose sur le fait qu’un utilisateur avec privilèges est ou s’est connecté sur le poste compromis et ce risque peut être largement minimisé avec l’adoption de bonnes pratiques. Désolé si j’ai l’air de me répéter ;-)
Pour simuler une attaque PtT, on va utiliser l’outil mimikatz sur le poste compromis avec la commande Sekurlsa ::tickets /export pour exporter dans les fichiers d’extension .kirbi le contenu des différents tickets.
Les fichiers qui nous intéressent sont ceux correspondant aux TGT des utilisateurs ici, associés à l’identité jtrevages.
On doit maintenant mener l’attaque à partir d’un autre poste. Il suffit recopier le fichier en XXX-jtrevages@krbtgt-CONTOSO.COM.kirbi dans le répertoire de mimikatz du poste de l’attaquant.
Pour vérifier que l’injection se passe correctement, lancer d’abord en ligne de commande klist pour lister les tickets Kerberos déjà existants sur la machine. Faites une tentative de connexion sur le partage avec la commande dir \\dc01\c$: la connexion est refusée.
On lance ensuite mimikatz et on injecte le TGT de jtrevages avec la commande Kerberos :: ptt XXX-jtrevages@krbtgt-CONTOSO.COM.kirbi
On vérifie par un klist que les jetons Kerberos de jtrevages sont injectés : c’est bien le cas.
On fait une nouvelle tentative de connexion au DC en faisant dir \\dc01\c$: connexion OK ! Bonne nouvelle pour l’attaquant, mais ceci déclenche une alerte ATA.
L’alerte jugée critique (rouge) nous fournit des informations intéressantes comme le poste depuis lequel l’attaque a été menée, la cible (DC01) et l’identité usurpée (jtrevages), ce qui permet d’envisager des actions correctives immédiates : la dévalidation du compte compromis et la déconnexion du poste utilisé pour l’attaque. Ce pourra être le point de départ d’une investigation en analysant le poste de l’attaquant et en tentant de remonter la piste à partir de l’identité compromise.
5- Remote Execution
PSExec est un outil développé par Mark Russinovich qui fait partie de la panoplie des utilitaires de la suite Sysinternals, bien connue des administrateurs Windows, et que vous trouverez sur technet https://technet.microsoft.com/en-us/sysinternals/bb842062. L’intérêt de PsExec est de pouvoir exécuter un processus sur une machine distante sans avoir à installer de client – ce qui permet de passer sous le radar des anti-virus –. De plus, les outils en ligne de commande qui n’offrent pas la possibilité d’être exécutés sur une machine distante deviennent utilisables avec PsExec. C’est pour cela que cet outil fait souvent partie de l’arsenal des attaquants.
Dans la suite logique d’une attaque de type Pass-The-Ticket, l’attaquant cherchera à exécuter des commandes sur le serveur cible.
On peut vérifier par la commande hostname que l’on est bien sur le DC, mais l’alerte est levée dans la console ATA.
Là encore, l’alerte nous fournit des informations intéressantes sur la cible et sur le poste depuis lequel est menée l’attaque.
Conclusion
Depuis plusieurs années, les entreprises font face à des attaques ciblées dont le scénario est connu et qui profite du fait que certaines bonnes pratiques de sécurité ne sont pas mises en œuvre ; celles principalement consistant à limiter au strict minimum le nombre et l’utilisation de comptes à privilèges. Ce billet décrit comment simuler certaines attaques “déterministes” comme Pass-The-Hash et Pass-The-Ticket qui sont détectées par ATA.
La détection de ce type d’attaques n’est qu’un des aspects de la solution ATA, puisque la fonctionnalité de détection des comportements anormaux basée sur le Machine Learning doit permettre de détecter des attaques plus complexes (comme Over-Pass-The-Hash ou Golden Ticket) ou de mettre en évidence des signaux faibles caractéristiques d’une APT.