L'escalade de privilèges est l'utilisation par un attaquant des droits du compte courant pour obtenir un niveau d'accès supplémentaire, généralement plus élevé au système. Malgré le fait que l'escalade de privilèges peut être le résultat de l'exploitation de vulnérabilités zero-day, ou du travail de pirates informatiques de premier ordre menant une attaque ciblée, ou d'un malware correctement déguisé, mais cela se produit le plus souvent en raison d'une configuration incorrecte de l'ordinateur ou du compte. En poursuivant le développement de l'attaque, les attaquants exploitent un certain nombre de vulnérabilités distinctes qui, ensemble, peuvent entraîner une fuite de données catastrophique.
Pourquoi les utilisateurs ne devraient-ils pas disposer de droits d'administrateur local?
Si vous êtes un spécialiste de la sécurité, il peut sembler évident que les utilisateurs ne devraient pas avoir de droits d'administrateur local, comme ceci:
- Rend leurs comptes plus vulnérables à diverses attaques.
- Rend ces attaques beaucoup plus graves.
Malheureusement, pour de nombreuses organisations, cela reste un sujet très controversé et s'accompagne parfois de discussions animées (voir, par exemple,
mon responsable dit que tous les utilisateurs doivent être des administrateurs locaux ). Sans entrer dans les détails de cette discussion, nous pensons que l'attaquant a obtenu les droits d'un administrateur local sur le système à l'étude: soit par un exploit, soit parce que les machines n'étaient pas correctement protégées.
Étape 1. Inversez la résolution des noms DNS via PowerShell
Par défaut, PowerShell est installé sur de nombreux postes de travail locaux et sur la plupart des serveurs Windows. Bien qu'il ne soit pas exagéré, il est considéré comme un outil d'automatisation et de contrôle incroyablement utile, il est également capable de se transformer en un
malware sans fil presque invisible (un programme de piratage qui ne laisse pas de traces d'une attaque).
Dans notre cas, l'attaquant commence à effectuer une reconnaissance du réseau à l'aide du script PowerShell, triant séquentiellement l'espace d'adressage IP du réseau, essayant de déterminer si cette IP est autorisée pour l'hôte, et si oui, quel est le nom de réseau de cet hôte.
Il existe plusieurs façons d'accomplir cette tâche, mais l'utilisation de l'applet de commande Get-ADComputer est une option fiable car elle renvoie un ensemble de données vraiment riche sur chaque nœud:
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq '10.10.10.10'}
Si la vitesse de travail dans les grands réseaux pose des problèmes, le rappel du système DNS peut être utilisé:
[System.Net.Dns]::GetHostEntry('10.10.10.10').HostName
Cette méthode de listage des nœuds sur un réseau est très populaire, car la plupart des réseaux n'utilisent pas de modèle de sécurité à confiance nulle et ne suivent pas les demandes DNS internes pour les pics d'activité suspects.
Étape 2: sélection des objectifs
Le résultat final de cette étape est d'obtenir une liste de noms d'hôte de serveur et de poste de travail pouvant être utilisés pour poursuivre l'attaque.
A en juger par le nom, le serveur 'HUB-FILER' semble être un objectif louable, car au fil du temps, les serveurs de fichiers ont tendance à accumuler un grand nombre de dossiers réseau et un accès excessif à eux par trop de personnes.
L'affichage à l'aide de l'Explorateur Windows nous permet de déterminer s'il existe un dossier partagé ouvert, mais notre compte actuel ne peut pas y accéder (nous n'avons probablement que les droits de listage).
Étape 3: Apprenez l'ACL
Maintenant sur notre hôte HUB-FILER et le dossier de partage cible, nous pouvons exécuter le script PowerShell pour obtenir l'ACL. Nous pouvons le faire à partir de la machine locale, car nous avons déjà des droits d'administrateur local:
(get-acl \\hub-filer\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto
Résultat d'exécution:
De là, nous voyons que le groupe Utilisateurs du domaine n'a accès qu'à la liste, mais le groupe Helpdesk a également le droit de changer.
Étape 4: identifier les comptes
En exécutant
Get-ADGroupMember , nous pouvons obtenir tous les membres de ce groupe:
Get-ADGroupMember -identity Helpdesk
Dans cette liste, nous voyons un compte d'ordinateur que nous avons déjà identifié et auquel nous avons déjà accédé:
Étape 5: utiliser PSExec pour travailler à partir d'un compte d'ordinateur
PsExec de Microsoft Sysinternals vous permet d'exécuter des commandes dans le contexte du compte système SYSTEM @ HUB-SHAREPOINT, qui, comme nous le savons, est membre du groupe de travail Helpdesk. Autrement dit, il nous suffit d'effectuer:
PsExec.exe -s -i cmd.exe
Eh bien, vous avez alors un accès complet au dossier cible \\ HUB-FILER \ share \ HR, car vous travaillez dans le contexte du compte d'ordinateur HUB-SHAREPOINT. Et avec cet accès, les données peuvent être copiées sur un périphérique de stockage portable ou autrement récupérées et transférées sur le réseau.
Étape 6: détecter cette attaque
Cette vulnérabilité particulière pour la définition des privilèges de compte (les comptes d'ordinateur accédant aux dossiers réseau partagés au lieu des comptes d'utilisateur ou des comptes de service) peut être détectée. Cependant, sans les bons outils, c'est très difficile.
Pour détecter et prévenir cette catégorie d'attaques, nous pouvons utiliser
DatAdvantage pour identifier les groupes contenant des comptes d'ordinateurs, puis fermer l'accès à ceux-ci.
DatAlert va plus loin et vous permet de créer une notification spécifiquement pour un tel scénario.
La capture d'écran ci-dessous montre une notification utilisateur qui sera déclenchée chaque fois qu'un compte d'ordinateur accède aux données sur un serveur surveillé.
Étapes suivantes à l'aide de PowerShell
Envie d'en savoir plus? Utilisez le code de déverrouillage «blog» pour accéder gratuitement au
cours vidéo complet
PowerShell et aux principes de base d'Active Directory .