Au-delà du coffre : le privilège permanent zéro neutralise plus que les attaques sur les mots de passe

Partie 2 sur 3 de notre série Rethinking Privileged Access. Commencez par la Partie 1 : Le mot de passe n'a jamais été le seul problème.

Dans la Partie 1, nous avons tracé la ligne entre le modèle coffre-et-check-out du PAM traditionnel et le modèle session-et-Activities du PAM moderne avec Netwrix Privilege Secure (NPS). L'un protège le mot de passe ; l'autre élimine le privilège permanent qui se cache derrière. Ce cadrage est un bon point de départ, mais il sous-estime le problème. Dans Windows et Active Directory, le mot de passe n'est que la graine. Tout ce qu'un attaquant utilise pour se déplacer latéralement en est dérivé ou est émis à cause de lui : un hachage NTLM, un ticket Kerberos, une session en cache, un certificat, un blob DPAPI. Un outil PAM qui protège uniquement le mot de passe protège un maillon d'une chaîne bien plus longue.

C'est là que la vraie différence entre le PAM traditionnel et le PAM moderne apparaît. Le coffre masque le mot de passe, mais ne touche à rien de ce qui en découle. NPS supprime le privilège permanent en effectuant la rotation, la désactivation ou la suppression des comptes dès la fin d'une session. Cela interrompt plusieurs de ces chemins d'attaque en aval, car la plupart d'entre eux dépendent de l'existence d'un compte privilégié, dans un état utilisable, plus longtemps que nécessaire. NPS n'empêche toutefois pas totalement les menaces AD comme le Kerberoasting. D'autres produits Netwrix, tels que Netwrix Threat Prevention, peuvent aider en détectant les activités d'authentification suspectes.

La surface d'identifiants que personne ne place dans un coffre

Voici ce qui est attaquable dans un environnement Windows/AD au-delà du mot de passe en clair :

• Hachages NTLM : utilisables directement via Pass-the-Hash, sans qu'il soit nécessaire de les casser.
• Tickets Kerberos (TGT/TGS) : volables et rejouables via Pass-the-Ticket, et falsifiables via des Golden et Silver Tickets si la clé krbtgt ou celle d'un compte de service est compromise.
• Éléments exploitables par Kerberoasting/AS-REP roasting : tout utilisateur du domaine peut demander un ticket de service pour un compte porteur d'un SPN, ou un AS-REP pour un compte dont la préauthentification est désactivée, puis le casser hors ligne.
• Identifiants de domaine en cache (MSCACHEv2) : stockés dans la ruche SECURITY locale de toute machine sur laquelle un utilisateur s'est connecté.
• Certificats et entrées msDS-KeyCredentialLinkExpand : exploitables via une mauvaise configuration des modèles AD CS ou des attaques Shadow Credentials, pour s'authentifier en tant qu'utilisateur sans jamais toucher à son mot de passe.
• Mots de passe gérés par LAPS/gMSA : protégés uniquement par l'ACL de l'attribut qui les stocke.
• Secrets protégés par DPAPI : déchiffrables si un attaquant dérive la clé maître de l'utilisateur ou vole la clé de sauvegarde DPAPI du domaine.

Aucun de ces éléments ne nécessite le mot de passe en clair, et tous donnent accès à quelque chose de très proche.

Pourquoi le privilège permanent est le fil conducteur

Presque tous les éléments de cette liste ne sont puissants que parce que le compte qui se trouve derrière détient de vrais privilèges en ce moment même et les conserve indéfiniment. Une configuration de PAM traditionnel, avec un mot de passe placé dans un coffre, renouvelé et injecté au-dessus d'une appartenance permanente à Domain Admins, laisse tout de même un hachage NTLM à voler, un TGS à attaquer par roasting et une session en cache à casser entre deux check-out.

Les modèles de comptes de NPS (demandeur, géré et éphémère, détaillés dans la Partie 1) s'attaquent directement à cette cause racine commune. Les comptes gérés sont désactivés et renouvelés dès la fin d'une session, les comptes éphémères sont purement et simplement supprimés, et même les comptes demandeurs ne bénéficient d'une appartenance à des groupes élevés que pendant la durée de la session.

Parce que le privilège a un début et une fin au lieu d'exister indéfiniment, la plupart des attaques ci-dessus perdent leur cible à l'instant où la session se ferme. NPS n'a pas besoin de détecter l'attaque, car il ne reste plus rien qui vaille la peine d'être attaqué.

Ce que NPS change, attaque par attaque

Avec NPS, un compte compromis dispose de privilèges limités, ce qui plafonne les dégâts qu'il peut causer.

Deux fonctionnalités qui élargissent encore l'effet

Deux des Activities de NPS non liées aux comptes, toutes deux présentées dans la Partie 1, méritent d'être rappelées ici, car elles étendent cette même logique au-delà des identifiants :

• Activation/désactivation de RDP. La plupart des serveurs laissent RDP en écoute en permanence. NPS peut l'activer uniquement pendant la durée d'une session et le désactiver immédiatement après. Cela supprime une surface d'attaque importante et constamment disponible, qui n'a rien à voir avec les identifiants que détient l'attaquant.
• Mode de protection. L'analyse des ressources Windows et Linux à la recherche de comptes locaux non approuvés détecte un autre mode de défaillance : un insider (ou un attaquant déjà entré) qui crée discrètement un compte permanent pour un usage ultérieur. Elle applique la même philosophie du « ne pas laisser s'accumuler de privilèges non gérés » aux comptes que NPS n'a pas créés à l'origine.

Ce que cela ne remplace pas

Il est important d'être précis sur les limites, car surestimer ne rend service à personne. NPS est efficace contre les attaques qui dépendent d'un compte privilégié persistant dans un état utilisable, ce qui couvre une part étonnamment large du catalogue d'attaques sur les identifiants Windows. Il n'agit pas sur les attaques qui fonctionnent indépendamment de l'état en temps réel d'un compte donné : un Golden Ticket forgé à partir d'une clé krbtgt volée, l'abus de modèles AD CS, une Shadow Credential écrite dans un attribut ou le vol de la clé de sauvegarde DPAPI de tout le domaine. Ces cas exigent leur propre hygiène (discipline de rotation de krbtgt, revue des modèles de certificats, surveillance des écritures d'attributs, protection de la clé de sauvegarde), quelle que soit la rigueur du modèle de session et d'Activities.

À retenir

Le PAM traditionnel place un mot de passe dans un coffre et protège un seul artefact. Éliminer le privilège permanent réduit la valeur de presque tout ce qui découle de ce mot de passe : hachages, tickets, sessions en cache et attributs des comptes gérés. Ces artefacts ne valent la peine d'être volés que si le privilège qui se trouve derrière est encore là quand l'attaquant tente de s'en servir. NPS n'arrêtera pas toutes les attaques sur les identifiants dans Active Directory, mais il ferme bien plus de surface d'attaque que « protéger le mot de passe » ne le pourrait jamais.

À suivre dans cette série

Tout ce qui précède suppose que les comptes fonctionnent entièrement selon les modèles de comptes de NPS. La Partie 3 présente Bring Your Own Vault (BYOV) : comment NPS ajoute cette même protection basée sur les sessions au-dessus d'un coffre que vous utilisez déjà (un coffre PAM traditionnel, CyberArk, BeyondTrust, HashiCorp Vault ou LAPS), afin que vous puissiez commencer à réduire cette exposition sans tout migrer d'un seul coup.