Mimikatz, déplacement latéral : comment se protéger ?

Protéger ses hôtes avec leurs pare-feu

Pour Benjamin Delpy, « il est décevant de voir encore, en 2020, beaucoup d’entreprises, de toutes tailles, qui autorisent les connexions poste-à-poste. Lorsque l’on installe un poste ou un serveur Windows, par défaut, aucune connexion entrante n’est possible. Cela signifie que la possibilité d’accéder à distance aux fichiers, au bureau, ou de lancer des appels de procédures à distance (RPC), a été volontairement activée ». Car pour lui, aujourd’hui, « on n’a plus besoin de ça pour administrer des machines ». Et le premier rapport, contre le déplacement latéral des assaillants dans son système d’information, « c’est le pare-feu de Windows, de base. Il est actif par défaut ! »

Alors si cette protection native est désactivée, c’est à la fois lié au mythe historique de la sécurité périmétrique, et « à de la facilité » : « énormément d’administrateurs se facilitent la vie en désactivant le pare-feu de Windows. C’est plus facile, comme ça, de télédistribuer avec des outils très basiques ».

Benjamin Delpy souligne toutefois que le déplacement latéral entre postes de travail survient de moins en moins… Ce sont les serveurs qui sont visés. Mais « que le serveur de la comptabilité puisse accéder au serveur dédié aux déploiements dans les usines, par exemple, ça ne viendrait à l’esprit de personne… mais c’est souvent ce que l’on voit, parce que le pare-feu a été désactivé ».

Ne pas laisser les protections sans surveillance

Mais les assaillants les plus avancés ont plus d’une carte dans leur manche : « ils prennent la main du domaine complet, avant de se télédistribuer par GPO. Il n’y a rien de mieux que de compter sur le fonctionnement normal d’un domaine pour se télédiffuser, parce que cela passe sous le radar ». Et là, tout tient à la manière dont le domaine a été conçu et maintenu pour empêcher cela.

Et cela vaut aussi pour les consoles d’administration des systèmes de protection des hôtes, ou d’EDR, voire d’administration de systèmes : « on a vu des attaquants prendre la main sur les outils de sécurité pour se déployer sur les hôtes ». En somme, « on a protégé son domaine, mais pas son antivirus. Cela peut avoir l’air bête, dit comme ça, mais ça arrive ».

Dans billet de blog, et un récent épisode du podcast No Limit Secu, Christophe Renard, aussi connu sous le pseudonyme FuraxFox, évoquait justement, en premier conseil pour les RSSI, la supervision des antivirus – et pas seulement par leur console propriétaire.

Gérer rigoureusement les droits

Mais il recommandait également de migrer les administrateurs Windows dans le groupe Protected Users d’Active Directory. Car relève Christophe Renard, avec cette disposition, « vous indiquez à Windows que ces comptes doivent exclusivement utiliser l’authentification par Kerberos et que la politique de gestion des identifiants doit privilégier la sécurité sur la simplicité d’utilisation ».

Pour Benjamin Delpy, cela mérite effectivement d’être fait, mais attention à ne pas développer un faux sentiment de sécurité totale : « rien n’empêche là de voler un ticket Kerberos en mémoire », ni, pour l’assaillant, « de se diffuser ».

Quant à retirer le debug privilege, comme le conseille également Christophe Renard, oui, au moins pour bloquer les assaillants les moins avancés : ce privilège « permet de lire la mémoire de n’importe quel processus, et de manipuler processus et taches indépendamment de leur propriétaire ».

Le désactiver constitue donc une avancée, mais pas suffisante, explique Benjamin Delpy : « lorsque l’on prend le contrôle d’un poste, on ne cherche pas uniquement à devenir administrateur, on cherche à devenir système. C’est encore au-dessus. Et le système n’a pas besoin du debug privilege ». Qui plus est, « une fois passé administrateur, en général, il est possible de se redonner le debug privilege ».

Des règles d’exécution strictes

Le premier principe, pas toujours évident à appliquer et à faire respecter, « mais on y arrive en 2020 », consiste à ne pas donner de droits d’administration aux utilisateurs sur leur poste. Le second : « si l’utilisateur peut écrire un exécutable quelque part, il ne peut pas le lancer ». Et réciproquement, « si un utilisateur peut lancer un programme quelque part, celui-ci ne peut pas écrire à cet endroit ». De telles règles d’exécution, explique Benjamin Delpy, « c’est tout bête, mais ça bloque énormément d’attaques et de diffusion ». Et d’illustrer : « avec de telles règles en place, un assaillant peut prendre le contrôle d’un poste ou d’un serveur, puis récupérer sa charge, mais il ne pourra pas la lancer ».

Là, il ne s’agit pas d’une protection absolue : « il y a les macros, l’exécution en mémoire, etc. Mais ces règles limitent déjà considérablement la menace ». Et aussi parce que bien souvent, « une macro sert d’amorce puis va télécharger un exécutable. Avec le principe ici décrit, il ne pourra pas se lancer ». Et pour cela, pas besoin d’éditeur tiers, souligne le créateur de Mimikatz, « AppLocker fait très bien son travail. Cela demande juste de la configuration ».

Au final, pour Benjamin Delpy, « les attaquants ne sont pas très sophistiqués. Ils n’en ont pas besoin. Pour l’essentiel, il y a un vrai problème d’hygiène de base ». Las, « le maintien en conditions opérationnelles de sécurité du patrimoine n’est pas assez sexy ».