TA0004 Élévation de privilèges : passer d’un compte ordinaire à l’administration

Sixième tactique de la matrice ATT&CK Enterprise. L’objectif, selon le MITRE : l’adversaire cherche à obtenir des permissions de plus haut niveau. La définition ajoute une observation d’expérience : les attaquants entrent et explorent souvent un réseau avec un accès non privilégié, mais ont besoin de permissions élevées pour poursuivre leurs objectifs.

→ Lire l’explication complète de la marmotte

L’objectif de l’attaquant

Monter en droits. C’est une étape rarement optionnelle : voler les identifiants d’un annuaire, installer un service, lire la mémoire d’un autre processus ou désactiver une protection exigent presque toujours des privilèges que le compte d’entrée ne possède pas.

La tactique a une particularité structurelle qu’il faut comprendre pour lire une couverture de détection : la moitié de ses techniques sont partagées avec la persistance. Tâche planifiée, processus système, exécution automatique au démarrage, exécution déclenchée par un événement, comptes valides, manipulation de compte : le même geste sert à rester et à monter, selon le contexte où il est posé. Ce n’est pas une imprécision du catalogue, c’est une propriété du terrain : un mécanisme qui exécute du code au nom du système offre les deux à la fois.

Les techniques, et ce qu’elles couvrent

Treize techniques, dont six partagées avec la persistance. Les sept propres à cette tactique sont les plus instructives.

L’exploitation. T1068 (exploitation pour élévation de privilèges) est la voie directe : une vulnérabilité dans le noyau, un pilote ou un service privilégié. Le site en documente un cas devenu classique avec Dirty COW, où une course dans le mécanisme de copie à l’écriture du noyau Linux donnait l’écriture sur des fichiers en lecture seule.

L’abus des mécanismes d’élévation légitimes. T1548 couvre les mécanismes prévus pour élever les droits de façon contrôlée, et détournés : contrôle de compte d’utilisateur sous Windows, exécution déléguée sous Unix, et surtout les binaires qui s’exécutent avec les droits de leur propriétaire, cas que le site traite dans l’élévation de privilège via un binaire SUID root mal configuré.

Le vol de contexte d’exécution. T1055 (injection de processus) consiste à faire exécuter son code dans l’espace d’un processus plus privilégié : ce qui fournit à la fois les droits et la discrétion, puisque l’activité apparaît sous le nom d’un programme légitime. T1134 (manipulation de jeton d’accès) en est la version Windows par les jetons d’identité : emprunter le contexte d’un autre utilisateur sans connaître son mot de passe.

La modification de la politique. T1484 (modification de la politique de domaine ou de locataire) est la technique la plus rentable en environnement d’entreprise : plutôt que d’élever ses droits sur une machine, on modifie la règle qui distribue les droits à toutes les machines. Les stratégies de groupe en sont le véhicule classique (GPO Active Directory : durcissement, abus et contrôle décrit les deux faces), et l’équivalent en nuage consiste à modifier une politique d’identité, comme le montre détecter la persistance IAM dans AWS.

La sortie d’isolation. T1611 (évasion vers l’hôte) décrit le passage d’un conteneur à la machine qui l’héberge, par un montage trop permissif, une capacité excessive ou un socket d’orchestration exposé. Le site traite la question sous l’isolation des conteneurs Docker : namespaces, cgroups et évasions, et son équivalent au niveau machine virtuelle dans l’évasion de VM et l’isolation matérielle des hyperviseurs. Dans un cluster, le chemin le plus court reste souvent le jeton de compte de service monté par défaut.

Ce qu’on peut détecter, et par quoi

L’élévation elle-même, par les journaux d’authentification et de processus. Un processus qui change de contexte de sécurité, une session qui obtient un jeton d’administration, un compte ordinaire qui exécute soudain une opération privilégiée : ces événements existent dans les journaux du système, à condition d’avoir activé la journalisation détaillée, ce que décrit centraliser les journaux Sysmon des postes Windows.

L’injection de processus, par l’EDR. C’est l’un des rares comportements que les outils de détection sur terminaux voient bien, parce qu’il suppose des appels système caractéristiques. La page sur l’EDR précise aussi ses limites : les techniques d’injection évoluent plus vite que les règles.

Les modifications de politique, par les journaux d’annuaire et de plateforme. Une stratégie de groupe modifiée, un rôle d’administration attribué, une politique d’identité éditée : ces événements sont rares, décisifs, et constituent les meilleures alertes de toute la tactique. Leur surveillance suppose de savoir qui a le droit de les produire, ce qui ramène à l’audit de l’héritage des permissions et du droit effectif.

Les chemins d’attaque, par analyse préalable. Plutôt que d’attendre l’élévation, on cartographie à froid les chemins qui mènent d’un compte ordinaire à l’administration du domaine. C’est un exercice de configuration, pas de détection, et il trouve ce qu’aucune alerte ne signalera : un groupe imbriqué, une délégation oubliée, un compte de service administrateur local sur tous les postes.

Ce que le défenseur peut faire

Séparer les plans. Un compte d’administration qui ne sert jamais à lire ses courriels, et un poste d’administration distinct, suppriment la majorité des chemins d’élévation : séparer plan de contrôle et plan de données en décrit le principe.

Donner les privilèges à la demande, pas en permanence. C’est l’objet de l’accès juste-à-temps et des privilèges temporaires : un droit qui n’existe que pendant l’intervention ne peut pas être volé entre deux interventions.

Corriger en priorité ce qui élève. Les vulnérabilités d’élévation locale sont souvent reléguées derrière les vulnérabilités distantes, au motif qu’elles « supposent déjà un accès ». C’est précisément l’hypothèse de l’attaquant. La priorisation décrite dans CVSS, EPSS et KEV aide à ne pas les oublier.

Durcir l’isolation des conteneurs : pas de privilèges étendus, pas de montage du socket de l’orchestrateur, jetons de compte de service non montés par défaut, et contrôle d’admission qui refuse les configurations dangereuses.

Auditer les chemins, pas les comptes. La question n’est pas « combien avons-nous d’administrateurs ? » mais « combien de chemins mènent à l’administration ? ». La réponse, dans un annuaire ancien, dépasse régulièrement la centaine.

Sources

TA0004, Privilege Escalation, MITRE ATT&CK Enterprise v20 : objectif et treize techniques.
Jeu de données STIX Enterprise ATT&CK 19.2 : identifiants et périmètre des techniques citées.

🐝 Ce qui arrive si on s’en passe

Une organisation qui n’examine pas cette tactique administre ses systèmes comme si les droits étaient un sujet de confort. Les administrateurs utilisent leur compte privilégié pour lire leurs courriels, les comptes de service sont administrateurs locaux sur tous les postes « pour éviter les problèmes », et les vulnérabilités d’élévation locale restent au bas de la pile de correctifs. Le résultat est qu’un accès initial banal (un poste d’utilisateur ordinaire) devient un accès au domaine en quelques heures, par des chemins que personne n’a cartographiés et qui n’exigent aucune compétence rare. Le coût se révèle à la remédiation : lorsque l’administration du domaine est compromise, il ne s’agit plus de nettoyer des machines mais de reconstruire une confiance, c’est-à-dire de renouveler l’ensemble des secrets de l’annuaire, opération lourde, risquée, et qui doit être conduite pendant que l’attaquant y a encore accès.

🦫 Explication de la marmotte 🍫

Dans un système informatique, tous les comptes n’ont pas les mêmes droits. Un compte d’utilisateur ordinaire peut lire ses propres documents ; un compte d’administrateur peut installer des logiciels, lire les fichiers de tout le monde et modifier la configuration des machines.

Un attaquant entre rarement avec un compte d’administrateur. Il entre par le compte d’un employé : celui qui a ouvert la pièce jointe, ou dont le mot de passe avait fuité ailleurs. Son étape suivante consiste donc à obtenir davantage de droits : c’est l’élévation de privilèges.

Trois moyens principaux. Le premier consiste à exploiter un défaut dans un programme qui tourne déjà avec des droits élevés, comme le cœur du système d’exploitation. Le deuxième consiste à détourner les mécanismes prévus pour élever les droits de manière légitime : ceux qui permettent à un utilisateur d’exécuter une tâche d’administration précise, et qui sont souvent mal réglés. Le troisième, le plus efficace en entreprise, ne touche pas la machine : il modifie la règle qui distribue les droits à toutes les machines du réseau.

Une observation utile : la moitié des techniques de cette étape sont les mêmes que celles de l’étape précédente, la persistance. Un mécanisme qui exécute un programme au nom du système permet en effet à la fois de rester et de monter en droits.

La protection la plus efficace ne consiste pas à détecter l’élévation, mais à réduire le nombre de chemins qui y mènent : des comptes d’administration qui ne servent qu’à administrer, des droits accordés pour la durée d’une intervention plutôt que pour toujours, et un examen régulier (à froid, hors incident) de la question « à partir d’un poste ordinaire, par combien de chemins peut-on devenir administrateur ? ». Dans un réseau installé depuis dix ans, la réponse surprend toujours.

Pages voisines

La citent

TA0004 Élévation de privilèges : passer d'un compte ordinaire à l'administration

Elle cite

: les deux pages se citent l’une l’autre.