L'élévation des privilèges consiste à utiliser les droits actuels d'un compte par un attaquant pour obtenir un accès supplémentaire, généralement à un niveau supérieur dans le système. Bien que l'élévation des privilèges puisse résulter de l'exploitation de vulnérabilités zero-day, ou du travail de hackers de premier plan menant une attaque ciblée, ou d'un logiciel malveillant habilement dissimulé, elle se produit le plus souvent en raison d'une mauvaise configuration de l'ordinateur ou du compte. En poursuivant l'attaque, les attaquants exploitent une série de vulnérabilités distinctes, ce qui peut finalement conduire à une fuite de données catastrophique.
Pourquoi les utilisateurs ne devraient-ils pas avoir de droits d'administrateur local ?
Si vous êtes un spécialiste en sécurité, cela peut sembler évident, que les utilisateurs ne devraient pas avoir de droits d'administrateur local, car cela :
- Rend leurs comptes plus vulnérables à diverses attaques
- Rend ces attaques beaucoup plus graves
Malheureusement, pour de nombreuses organisations, c'est encore une question très controversée et parfois accompagnée de vives discussions (voir par exemple, ). Sans entrer dans les détails de cette discussion, nous considérons qu'un attaquant a obtenu des droits d'administrateur local sur le système examiné : soit par le biais d'un exploit, soit parce que les machines n'étaient pas correctement sécurisées.
Étape 1. Résolution inverse 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 soit souvent considéré comme un outil d'automatisation et de gestion incroyablement utile, il peut également se transformer en presque invisible (programme de piratage ne laissant pas de traces d'attaque).
Dans notre cas, l'attaquant commence à effectuer une reconnaissance réseau à l'aide d'un script PowerShell, en itérant séquentiellement à travers l'espace des adresses IP du réseau, essayant de déterminer si l'IP donnée résout à un hôte, et si oui, quel est le nom de réseau de cet hôte.
Il existe de nombreuses façons d'accomplir cette tâche, mais l'utilisation de la cmdlet ADComputer est une option fiable, car il 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 fonctionnement dans de grands réseaux pose des problèmes, un appel système DNS inverse peut être utilisé :
[System.Net.Dns]::GetHostEntry('10.10.10.10').HostName
Cette méthode d'énumération des nœuds dans le réseau est très populaire, car la plupart des réseaux n'utilisent pas de modèle de sécurité à confiance zéro et ne surveillent pas les requêtes DNS internes pour des pics d'activité suspects.
Étape 2 : Choix de la cible
Le résultat de cette étape est l'obtention d'une liste de noms d'hôtes de serveurs et de stations de travail, qui peut être utilisée pour poursuivre l'attaque.
À en juger par le nom, le serveur 'HUB-FILER' semble être une cible digne, car avec le temps, les serveurs de fichiers ont tendance à accumuler un grand nombre de dossiers réseau et un accès excessif à ceux-ci de la part d'un trop grand nombre de personnes.
L'exploration via l'Explorateur Windows nous permet de déterminer la présence d'un dossier partagé ouvert, mais notre compte actuel ne peut pas y accéder (il est probable que nous disposions uniquement des droits de listing).
Étape 3 : Étudier les ACL
Maintenant, sur notre hôte HUB-FILER et le dossier partagé cible share, nous pouvons exécuter un script PowerShell pour obtenir la liste des ACL. Nous pouvons le faire depuis notre machine locale, car nous avons déjà des droits d'administrateur local :
(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoRésultat de l'exécution :
Nous voyons que le groupe Utilisateurs du domaine a uniquement accès au listing, mais que le groupe Helpdesk a également des droits de modification.
Étape 4 : Identification des comptes
En exécutant , nous pourrons obtenir tous les membres de ce groupe :
Get-ADGroupMember -identity Helpdesk
Dans cette liste, nous voyons le compte d'ordinateur que nous avons déjà identifié et auquel nous avons déjà accès :
Étape 5 : Utilisation de PSExec pour travailler au nom du compte d'ordinateur
de Microsoft Sysinternals 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 cible Helpdesk. Il suffit donc d'exécuter :
PsExec.exe -s -i cmd.exeVous avez désormais un accès complet au dossier cible HUB-FILERshareHR, car vous travaillez dans le cadre du compte d'ordinateur HUB-SHAREPOINT. Avec cet accès, les données peuvent être copiées sur un périphérique de stockage portable ou extraites et transférées par le réseau.
Étape 6 : Détection de cette attaque
Cette vulnérabilité spécifique dans la configuration des droits des comptes (comptes d'ordinateur accédant à des dossiers réseau partagés au lieu de comptes utilisateurs ou de comptes de service) peut être détectée. Cependant, cela peut s'avérer très difficile sans les bons outils.
Pour détecter et prévenir cette catégorie d'attaques, nous pouvons utiliser pour identifier les groupes comportant des comptes d'ordinateur, puis restreindre leur accès. va plus loin en permettant de créer une notification spécifiquement pour ce type de scénario.
La capture d'écran ci-dessous montre la notification utilisateur qui se déclenchera à chaque fois qu'un compte d'ordinateur accède aux données sur le serveur surveillé.
Les étapes suivantes avec PowerShell
Vous souhaitez en savoir plus ? Utilisez le code de déverrouillage « blog » pour un accès gratuit au cours complet .
Source : habr.com
