L'élévation de privilèges est l'utilisation par un attaquant des droits actuels d'un compte pour obtenir un niveau d'accès supplémentaire, généralement plus élevé, au système. Même si l’élévation des 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 encore de logiciels malveillants bien déguisés, elle est le plus souvent due à une mauvaise configuration de l’ordinateur ou du compte. En développant davantage l'attaque, les attaquants exploitent un certain nombre de vulnérabilités individuelles, qui, ensemble, peuvent conduire à une fuite de données catastrophique.
Pourquoi les utilisateurs ne devraient-ils pas avoir de droits d'administrateur local ?
Si vous êtes un professionnel de la sécurité, il peut sembler évident que les utilisateurs ne doivent pas disposer de droits d'administrateur local, comme ceci :
- Rend leurs comptes plus vulnérables à diverses attaques
- Rend ces mêmes attaques beaucoup plus graves
Malheureusement, pour de nombreuses organisations, il s'agit encore d'une question très controversée et qui s'accompagne parfois de discussions animées (voir, par exemple, ). Sans entrer dans les détails de cette discussion, nous pensons que l'attaquant a obtenu les droits d'administrateur local sur le système étudié, soit via un exploit, soit parce que les machines n'étaient pas correctement protégées.
Étape 1: Inverser la résolution DNS avec PowerShell
Par défaut, PowerShell est installé sur de nombreux postes de travail locaux et sur la plupart des serveurs Windows. Et même s'il n'est pas sans exagération qu'il soit considéré comme un outil d'automatisation et de contrôle incroyablement utile, il est également capable de se transformer en un outil quasi invisible. (un programme de piratage qui ne laisse aucune trace de l'attaque).
Dans notre cas, l'attaquant commence à effectuer une reconnaissance du réseau à l'aide d'un script PowerShell, parcourant séquentiellement l'espace d'adressage IP du réseau, essayant de déterminer si une adresse IP donnée correspond à un hôte et, si oui, quel est le nom réseau de cet hôte.
Il existe de nombreuses façons d'accomplir cette tâche, mais en utilisant l'applet de commande ADComputer est une option solide car il renvoie un ensemble de données très riches sur chaque nœud :
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}Si la vitesse sur les grands réseaux pose problème, un rappel DNS peut être utilisé :
[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName
Cette méthode de liste des hôtes sur un réseau est très populaire, car la plupart des réseaux n'utilisent pas de modèle de sécurité zéro confiance et ne surveillent pas les requêtes DNS internes pour déceler des pics d'activité suspects.
Étape 2 : Sélectionnez une cible
Le résultat final de cette étape est d’obtenir une liste de noms d’hôtes de serveurs et de postes de travail pouvant être utilisés pour poursuivre l’attaque.
D'après son nom, le serveur 'HUB-FILER' semble être une cible intéressante, puisque au fil du temps, les serveurs de fichiers accumulent généralement un grand nombre de dossiers réseau et un accès excessif à ceux-ci par un trop grand nombre de personnes.
La navigation avec l'Explorateur Windows nous permet de détecter la présence d'un dossier partagé ouvert, mais notre compte actuel ne peut pas y accéder (nous n'avons probablement que les droits de référencement).
Étape 3 : Apprentissage de l'ACL
Désormais, sur notre hôte et notre partage cible HUB-FILER, nous pouvons exécuter un script PowerShell pour obtenir l'ACL. Nous pouvons le faire depuis la machine locale, puisque nous disposons déjà des droits d’administrateur local :
(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoRésultat de l'exécution :
De là, nous voyons que le groupe Utilisateurs du domaine a accès uniquement à la liste, mais que le groupe Helpdesk a également le droit de modifier.
Étape 4 : Identification du compte
Fonctionnement , nous pouvons obtenir tous les membres de ce groupe :
Get-ADGroupMember -identity Helpdesk
Dans cette liste, nous voyons un compte informatique que nous avons déjà identifié et auquel nous avons déjà accédé :
Étape 5 : Utilisez PSExec pour exécuter en tant que compte d'ordinateur
de Microsoft Sysinternals vous permet d'exécuter des commandes dans le contexte du compte système SYSTEM@HUB-SHAREPOINT, dont nous savons qu'il est membre du groupe cible Helpdesk. Autrement dit, il nous suffit de faire :
PsExec.exe -s -i cmd.exeEh bien, vous avez un accès complet au dossier cible HUB-FILERshareHR, puisque vous travaillez dans le contexte du compte informatique HUB-SHAREPOINT. Et grâce à 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 transmises sur le réseau.
Étape 6 : Détecter cette attaque
Cette vulnérabilité particulière de réglage des privilèges de compte (comptes d'ordinateur accédant aux partages réseau au lieu de comptes d'utilisateurs ou de comptes de service) peut être découverte. Cependant, sans les bons outils, cela est très difficile à réaliser.
Pour détecter et prévenir cette catégorie d'attaques, nous pouvons utiliser pour identifier les groupes contenant des comptes d'ordinateur, puis leur refuser l'accès. va plus loin et permet de créer une notification spécifiquement pour ce genre de scénario.
La capture d'écran ci-dessous montre une notification personnalisée qui se déclenchera chaque fois qu'un compte d'ordinateur accède aux données sur un serveur surveillé.
Prochaines étapes avec PowerShell
Veulent en savoir plus? Utilisez le code de déverrouillage "blog" pour accéder gratuitement à l'intégralité .
Source: habr.com