Utilisation offensive de GPO en environnement Active Directory20 minute(s) de lecture

Les GPOs, acronymes de Group Policy Object, sont des conteneurs mis à disposition des administrateurs pour faire appliquer à un ensemble d’objets, un ensemble de règles. Ces dernières permettent donc d’améliorer la flexibilité tout en offrant une grande modularité aux gérants d’infrastructures Active Directory. Nous verrons dans ce poste comment utiliser de manière offensive des droits trop conséquents sur des stratégies de groupes.

Les exemples qui suivront seront effectués sur un domaine m’appartenant “testlab.local” composé d’un contrôleur de domaine (DC01) Windows Server 2019, et deux 2 machines (WS01, WS02) Windows 10 Professionnel (en version d’essai). L’utilisateur Bobby est compromis, ainsi que son mot de passe (“metallica123!”). Les démonstrations des techniques seront opérées sur “Cobalt Strike” et “Empire”. Les antivirus sur les machines susmentionnées sont désactivés.

Composantes

Les GPOs sont constituées de 2 parties:

• Logique, ce sont des éléments gérés et stockés au sein de l’annuaire Active Directory en tant que propriété d’objet. Nous pouvons y retrouver les attributs spécifiques suivants:
  • “displayName”, qui correspond au nom donné lors de la création de la GPO.
  • “gPCFileSysPath”, qui correspond au chemin physique de la GPO.
  • “versionNumer” qui correspond à la version de la GPO, cette valeur doit être la même que celle présente dans le fichier “GPT.ini” située au niveau de “gPCFileSysPath”.
  • “gPCFunctionalityVersion”, qui indique la version du protocole “Group Policy” qui doit être utilisée.
  • “objectGUID”, abréviation de “Global Unique Identifier” correspond à une manière d’authentifier la GPO (c’est l’équivalent du SID).
  • “gPCMachineExtensionNames/gPCUserExtensionNames”, aussi appelé “CSE” (“client side extension”) correspond à une liste de GUID permettant de définir les actions de la GPO. Sans ces dernières les paramètres spécifiés ne seront pas appliqués. Vous pouvez trouver une liste à cet endroit. L’attribut est structuré de la manière suivante “[<CSE GUID 1><CSE TOOL GUID 1>][<CSE GUID 2><CSE TOOL 2>]” les “CSE GUID” sont triés par ordre alphabétique, et de même pour les “CSE TOOL”, indépendamment l’un de l’autre.
  • “name”, qui ressemble fortement au GUID.
  • “GpoStatus”, comme son nom l’indique définit l’état de la GPO, ces derniers sont “AllSettingsDisabled” (les paramètres définis pour les utilisateurs et pour les ordinateurs sont désactivés), “AllSettingsEnabled” (les paramètres définis pour les utilisateurs et pour les machines sont activés), “ComputerSettingsDisabled” (les paramètres définis pour les ordinateurs sont désactivés), “UserSettingsDisabled” (les paramètres définis pour les utilisateurs sont désactivés). Ces états seront définis dans l’attribut LDAP “Flags” qui prend les valeurs suivantes 0 (“AllSettingsEnabled”), 1 (“UserSettingsDisabled”), 2 (“ComputerSettingsDisabled”) et enfin 3 (“AllSettingsDisabled”).
  • “objectClass” dont la valeur doit être “{top, container, groupPolicyContainer}”.
  • “objectcategory” qui doit être égal à “CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=DOMAIN,DC=COM”
  • d’un point de vue plus structurel, les “GPOs” possèdent 2 enfants dans l’annuaire LDAP, ces derniers correspondent simplement aux 2 types de paramètre qu’une “GPO” est susceptible d’appliquer, “User” et “Machine” qui apparaîtront en tant que “Canonical Name” (“CN”) après le “DistinguishedName” de la GPO. Ces objets LDAP sont de classe “Container”.
• Physique, l’endroit où sont stockés les fichiers de ladite GPO sur le(s) contrôleur(s) de domaine. Il sera toujours le même et suivra la structure suivante: “\\domain.dns\SysVol\domain.dns\Policies\GPOName\”. Les GPO sont divisées en deux catégories, les GPOs “User” et “Machine”, ce qui correspondra à deux dossiers différents dans leur partie physique. Ainsi nous retrouverons un dossier “User” et un dossier “Machine”. Pour différents paramètres, il est possible d’associer certains répertoires et fichiers comme par exemple:
  • Les paramètres de sécurité, qui seront disponibles ici: “Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf”.
  • Les scripts de démarrage au niveau machine, sont présents à cet endroit: “Machine\Scripts\Startup\”.
  • Les tâches planifiées, sont situées au terme de ce chemin: “Machine\Preferences\ScheduledTasks” dans un fichier nommé “ScheduledTasks.xml”.
  • Bien d’autres que vous pouvez retrouvez ici.

Création d’une GPO

Il existe trois manières de définir une nouvelle stratégie de groupe, l’outil bien connu des administrateurs “GPMC.msc”, la console “Active Directory Users and Computers”, mais nous verrons surtout PowerShell. Pour cela Microsoft a implémenté un module pour pouvoir manipuler de tels objets, le module “GroupPolicy” qui est issu de la librairie .NET “Microsoft.GroupPolicy.Management.dll” (et “Microsoft.GroupPolicy.Management.Commands.dll” pour les cmdlet PowerShell).

# Nous commençons par importer le module
Import-Module GroupPolicy -Verbose
# Afin de créer une GPO la cmdlet New-GPO est tout indiqué. Nous pouvons donc la construire ainsi:
$GPO = New-GPO -Name SuperSecureGPO

Pour pouvoir continuer à la paramétrer il me faut faire un détour par l’explication d’un objet important dans un annuaire LDAP : les “Organizational unit”. Les “OUs” sont les conteneurs permettant de structurer les objets de l’Active Directory, elles jouent le rôle de boîtes qui rendent l’organisation d’autant plus pratique. Pour énumérer les “OUs” d’un Active Directory il existe globalement 3 méthodes; en utilisant PowerShell, avec le module ActiveDirectory en utilisant la cmdlet “Get-ADOrganizationalUnit” de la manière suivante:

Get-ADOrganizationalUnit -Filter "*" | Select-Object -ExpandProperty "DistinguishedName"

avec PowerView en utilisant la cmdlet “Get-DomainOU” de la façon ci-après:

Get-DomainOU | Select-Object -ExpandProperty distinguishedname

Si vous préférez faire les choses à la main, vous avez plusieurs choix, le mien se profilera vers PowerShell mais il est aussi tout à fait possible d’utiliser VBScript, C#, ou VB.Net, pour faire un programme utilisant les mêmes fonctionnalités.

$domainObj = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$PDC = ($domainObj.PdcRoleOwner).Name
$SearchString = -join @("LDAP://", $PDC, "/")
$DistinguishedName = "DC=$($domainObj.Name.Replace('.', ',DC='))"
$SearchString += $DistinguishedName
$Searcher = New-Object System.DirectoryServices.DirectorySearcher([ADSI] $SearchString)
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$Searcher.SearchRoot = $objDomain
$Searcher.Filter="(objectClass=organizationalUnit)"
$Searcher.FindAll()

Dans un premier temps nous obtenons les informations de l’actuel domaine, puis nous obtenons le contrôleur de domaine qui possède le rôle PdcEmulator (celui qui contrôle la modification des objets), et créons un chemin LDAP à partir de ce dernier. Puis nous utilisons la classe .NET “System.DirectoryServices.DirectorySearcher” qui permet, comme son nom l’indique, de chercher des objets dans le domaine, enfin nous appliquons le filtre LDAP “(objectClass=organizationalUnit)”, qui permet de filtrer les “OUs”.

• 

Revenons au sujet principal. Pour que les GPOs puissent être appliquées, il leur faut être lié avec une unité organisationnelle, cela aura pour effet de changer un attribut “LDAP”, “gplink”. Cette propriété est construite de la manière suivante “[ADSPATHGPO 1;GPLINK STATUT]” où le statut peut prendre 4 valeurs différentes: 0 (“LinkEnabled”), 1 (“LinkDisabled”), 2 (“LinkEnabled”, “Enforced”), 3 (“Enforced”). C’est pour cet objectif que la cmdlet “New-GPLink” doit être utilisé. Nous pouvons donc lier la GPO précédemment créée:

$GPO | New-GPLink -Target "OU=Computer,DC=testlab,DC=local"

La prochaine étape consiste à paramétrer l’action de la GPO, ici notre GPO active le mode de langage contraint de PowerShell. Pour cela nous utilisons la cmdlet “Set-GPPrefRegistryValue”

$GPO | Set-GPPrefRegistryValue -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\" -Action Create -ValueName "__PSLockdownPolicy" -Value "4" -Type String

Notre GPO est désormais appliquée et c’est à la prochaine mise à niveau des stratégies de groupes que ses fonctionnalités seront activées (toutes les, 90 minutes sommer à cela un temps aléatoire entre 0 et 30 minutes). Il est également possible de changer ou d’ajouter des droits sur une GPO avec la cmdlet “Set-GPPermission”. Les arguments disponibles pour celles-ci sont les suivants:

Set-GPPermission -Guid <guid> -PermissionLevel {None | GpoApply | GpoRead | GpoEdit | GpoEditDeleteModifySecurity | GpoCustom | WmiFilterEdit | WmiFilterFullControl |      WmiFilterCustom | StarterGpoRead | StarterGpoEdit | StarterGpoFullControl | StarterGpoCustom | SomCreateWmiFilter | SomWmiFilterFullControl | SomCreateGpo |                SomCreateStarterGpo | SomLogging | SomPlanning | SomLink} -TargetName <string> -TargetType {Computer | User | Group} [-DomainName <string>] [-Server <string>]              [-Replace] [-WhatIf] [-Confirm]  [<CommonParameters>]

Regardons plus en détail le paramètre “-PermissionLevel”, bien que les valeurs possibles sont pour le moins énigmatiques, elles correspondent en réalité à des accès précis (donc à des “ACLs” précises):

• “GpoRead” est “GenericRead”.
• “GpoEditDeleteModifySecurity”, est “GenericWrite, WriteDacl, WriteOwner”.
• “GpoEdit”, “GenericWrite”.
• “GpoApply”, “GenericExecute”.

Nous approfondirons cette notion un peu après.

Enumération

La découverte des GPOs peut se faire de différentes manières. L’une des premières, est l’utilisation de “gpresult”, qui permettra de lister les GPOs qui sont actuellement appliquées “gpresult /R”. Si vous êtes sur le contrôleur de domaine vous pouvez également utiliser PowerShell pour énumérer les GPOs: “Get-GPO -All”. Si vous n’êtes pas sur le contrôleur de domaine, rien ne vaudra alors PowerView pour gagner du temps. “Get-DomainGPO” vous fournira tout ce dont vous aurez besoin. Si vous voulez faire les choses à la main PowerShell sera comme toujours votre meilleur ami.

$domainObj = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$PDC = ($domainObj.PdcRoleOwner).Name
$SearchString = -join @("LDAP://", $PDC, "/")
$DistinguishedName = "DC=$($domainObj.Name.Replace('.', ',DC='))"
$SearchString += $DistinguishedName
$Searcher = New-Object System.DirectoryServices.DirectorySearcher([ADSI]$SearchString)
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$Searcher.SearchRoot = $objDomain
$Searcher.Filter="(objectClass=groupPolicyContainer)"
$Searcher.FindAll()

Le code est similaire à l’exemple précédent, cependant il suffit de changer le filtre pour obtenir les GPOs, ce dernier est “(objectClass=groupPolicyContainer)”.

• 

• 

Enfin quasiment. En effet les GPOs étant des “Securable objects”, elles possèdent donc un “SecurityDescriptor”, ce qui implique que des “ACL” lui sont attribuées, que d’autres objets la contrôlent. L’intérêt ici est que, les GPOs étant à la fois des objets “AD” et des objets “NTFS” (pour cause, la dimension physique). Quiconque possède des droits sur l’objet en obtiendra sur le répertoire de la GPO. En d’autres termes, qui possède des droits d’écriture sur l’objet de la GPO peut modifier les fichiers de son dossier. Parmi toutes les ACL qui existe nous chercherons donc: “AllExtendedWrite”, “GenericAll”, “GenericWrite”,”WriteOwner”, “WriteMember”, “WriteDacl”, “WriteProperty”. Si il s’agit de reconnaissance globale vous pouvez utiliser PowerView de la sorte:

Get-DomainObjectAcl -Identity "SuperSecureGPO" -ResolveGUIDs |  Where-Object {($_.ActiveDirectoryRights.ToString() -match "GenericWrite|AllExtendedWrite|WriteDacl|WriteProperty|WriteMember|GenericAll|WriteOwner")}

Si vous préférez obtenir des informations plus précises rien ne vous empêche de rajouter des conditions ou changer la condition. Par exemple, si nous souhaitons savoir si notre utilisateur possède n’importe quel droit, filtrer par SID est une bonne idée.

Vous pouvez aussi utiliser BloodHound qui marque chaque fois qu’un objet peut avoir ce genre d’ACL sur une GPO. Si beaucoup d’éléments se profile sur le graphe, les requêtes personnalisées vous aideront à filtrer les résultats. A titre personnel j’utilise https://github.com/hausec/Bloodhound-Custom-Queries. Si vous voulez encore une fois procéder à la main, PowerShell vous sera très utile. Il vous faudra le chemin “LDAP” de la “GPO” (“ADSPath”).

$ADEntry = New-Object System.DirectoryServices.DirectoryEntry "LDAP://CN={62009B2C-4CAB-4E96-82DD-6A56D055A977},CN=Policies,CN=System,DC=testlab,DC=local"
$aclObject = $ADEntry.PSBase.ObjectSecurity
$aclList = $aclObject.GetAccessRules($true,$true, [System.Security.Principal.SecurityIdentifier])

• 

• 

• 

• 

• 

Abus des droits

Nous avons vu précédemment que les GPO sont particulièrement puissantes. Elles nous permettent de faire appliquer à un ensemble d’objets, des règles arbitraires. Ainsi nous pouvons ajouter des scripts de démarrage, des tâches immédiates, des droits locaux (tel “SeDebugPrivilege”), ou même ajouter des utilisateurs à des groupes locaux. Vous conviendrez qu’il est alors possible d’en tirer profit pour différentes étapes de la Kill Chain, notamment le mouvement latéral, mais surtout l’élévation de privilège ainsi que la persistance (cependant une très mauvaise “OPSEC”, est garanti avec cette méthode). Pour exécuter ce genre d’attaque 2 outils existent “SharpGPOAbuse”, et “PyGPOAbuse”. Les deux ont des avantages mais aussi des inconvénients. “SharpGPOAbuse” est bien plus polyvalent que “PyGPOAbuse”, mais ce dernier a l’avantage de pouvoir opérer hors du domaine et en utilisant du “PTH”. En revanche les deux restes relativement peu flexibles, bien que rarement utiliser, le premier ne permet pas d’utiliser des identifiants alternatifs, et nécessite d’être déposé sur le disque si votre “C2” ne permet pas d’exécuter des “Assembly” .NET en mémoire, c’est d’ailleurs dans cet objectif que “SharpGPOAbuse” a été présenté, en étant usité au travers de la fonction “execute-assembly” de CobaltStrike. Ne trouvant pas mon compte dans ces deux outils, j’ai donc décidé d’écrire le mien, cette fois si en PowerShell. Il gardera comme défaut le fait de devoir être membre d’un domaine pour être utilisé, et pour l’instant un manque de polyvalence au niveau des différentes fonctions d’exploitation (d’autres sont prévus). Cependant il est un peu plus flexible que le premier. En effet il permet l’utilisation d’identifiants alternatifs, il n’a pas besoin d’être écrit sur le disque, propose plusieurs façons différentes de présenter la “GPO” à exploiter tout comme l’utilisateur, dans le cas où il doit être spécifié, tout en gardant les avantages du premier: plus polyvalent que “PyGPOAbuse”, peut utiliser d’autres domaines ainsi que d’autres contrôleurs de domaine, l’utilisation est aussi plus aisée que la version python. En tant qu’exemple nous utiliserons une attaque par ajout d’administrateur local. Cette dernière repose sur plusieurs principes. Les groupes d’administrations sont souvent restreints, c’est donc un paramètre “Machine” qu’il faudra appliquer. C’est derniers sont sauvegardés en “\Machine\Microsoft\Windows NT\SecEdit” dans un fichier “GptTmpl.inf”. Celui-ci sera structuré de la manière suivantes:

[Unicode]
Unicode=yes
signature="$CHICAGO$"
Revision=1
[Group Membership]
*S-1-5-32-544__Memberof =
*S-1-5-32-544__Members = *SID_UTILISATEUR/GROUP

Les GUIDS de la propriété “gPCMachineExtensionNames” devront comporté les suivants:

{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}

Les valeurs renseignées dans le fichier “GPT.ini” ainsi que la propriété “versionNumber” devront tous deux être augmentés de 1, sinon les paramètres de la “GPO” ne seront pas appliqués. le SID du groupe (dans l’exemple, “S-1-5-32-544” qui est celui des administrateurs par défaut) peut-être changer par n’importe quel SID d’un groupe du domaine.

Attaque avec CobaltStrike:

• Avec SharpGPOAbuse. L’assemby .NET est exécutée en mémoire avec “execute-assembly”, la commande ressemblera donc à celle ci-dessous. Une fois que les stratégies de groupe auront été actualisées, il ne restera plus qu’à utiliser “Jump” en “psexec” (le “psexec” nécessite d’être administrateur local, ce que nous sommes devenu, et des répertoires d’administration disponible en écriture, ce qui est le cas) pour avoir notre “beacon” (ici un “listener” “SMB”, a été utilisé dans le but de mettre en place une infrastructure paire à paire, nous y reviendrons dans un future article).
• Avec PowerGPOAbuse. Le programme PowerShell doit d’abord être importé avec “powershell-import” puis “powerpick” permet d’exécuter une commande PowerShell sans nécessairement avoir PowerShell. Enfin, nous finirons comme avec le premier cas, c’est à dire en pivotant avec “psexec”.

beacon> execute-assembly D:\tools\bin\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount bobby --GPOName SuperSecureGPO

• 

• 

• 

Attaque avec PowerShellEmpire:

• Avec SharpGPOAbuse. Ne pouvant pas exécuter de .NET en mémoire avec Empire, il faut donc le mettre sur la machine compromise. Ensuite, il faut l’exécuter avec “Start-Process” sans attendre de résultat malheureusement. Enfin comme dans l’exploitation avec CobaltStrike, “PsExec” nous permettra de pivoter sur le “DC” (il est fait avec “Invoke-SMBExec” the Invoke-TheHash).
• Avec PowerGPOAbuse. En premier lieu il faut importer le programme dans l’implant avec la commande “scriptimport”. Puis “scriptcmd” permettra d’utilisé un script PowerShell chargé. Il n’y aura pas d’output car les fonctions utilises “Write-Host” (équivalent de “print”) qui ne retourne aucune valeur, et c’est ce qu’attend “scriptcmd”, ce comportement sera corrigé.

• 

• 

• 

• 

Avec PyGPOAbuse l’attaque est un peu plus complexe, il faut convertir le mot de passe de l’utilisateur ayant les droits d’édition sur la “GPO” (ici Bobby) en son hash NT, ajouté le “fqdn” (“fully qualified domain name” dans notre cas “testlab.local”) du domaine, obtenir le nom de la “GPO” pour enfin pouvoir lancer le programme (je n’ai cependant jamais réussi à le faire marcher pour une raison qui m’échappe).

• 

Enumération Offensive

les exemples qui suivront seront fait avec PowerView.

Les “GPOs” étant des objets créés dans le but de configurer un grand nombre d’objet, il est de ce fait possible d’énumérer les paramètres qu’elles appliquent sur quelles/quels machines/utilisateurs, en effet si une “GPO” définit les comptes Administrateurs sur les machines susmentionnées alors il devient intéressant de viser ces utilisateurs en question. Cette tâche peut être effectuée grâce aux cmdlets “Get-DomainGPOLocalGroup” et “Get-DomainGPOComputerLocalGroupMapping” . Il est alors possible de faire une corrélation entre machines et utilisateurs qui peut être très avantageuse.

• 

• 

• 

• 

Pour obtenir la liste de machines concernées par une tel GPO, il est possible d’utiliser la commande en une ligne suivante:

Get-DomainGPO -Identity "SuperSecureGPO" | ForEach-Object {Get-DomainOU -GPLink $_.cn | ForEach-Object {Get-DomainComputer -SearchBase $_.distinguishedname -Properties dnshostname}}

D’une manière similaire il était possible pour les administrateurs de choisir des mots de passe pour des paramètres à appliquer (création de services en tant qu’un utilisateur précis, monter des partages SMB avec des identifiants précis, définir les mot de passe d’un utilisateur local précis, …) au travers de “Group Policy Preferences Password”. En revanche  Microsoft a malencontreusement publié la clef privée utilisée pour chiffrer le mot de passe (AES256), résultant d’une vulnérabilité toujours exploitable aujourd’hui. D’un point de vue extérieur, l’outil “CrackMapExec” possède plusieurs modules permettant de faire une reconnaissance au niveau des partages SMB, et ressortir une liste de potentiel de “GPO” vulnérable, l’outil “gpp-decrypt” permet lui de retrouver le claire des mots de passe.

• 

• 

Il est cependant beaucoup plus simple lorsque l’on possède un implant de tout faire depuis la machine compromise, “Get-GPPPassword.ps1” de PowerSploit permet de mener cette énumération directement avec PowerShell.

• 

• 

Le résultat peut être utilisé au travers d’une “pipe” afin de trouver les ordinateurs sur lesquels l’utilisateur serait administrateur, ou bien les ordinateurs affectés par la GPO. Cette tâche peut-être automatisée avec la commande en une ligne suivante:

Get-GPPPassword -Verbose | ForEach-Object {$b = ($_.Files).SubString(($_.Files).IndexOf('{')); Get-DomainGPO $b.SubString(0, $b.IndexOf('\')) | Where-Object { Get-DomainOU -GUID $_.cn | ForEach-Object {Get-DomainComputer -ADSPath $_} }; Write-Host ([System.Environment]::NewLine)}

Bien que complexe, elle fonctionne de similairement au premier exemple, à la différence qu’il faut filtrer le résultat pour obtenir la propriété “Name” incluse dans “gPCFileSysPath”. En utilisant un principe similaire, il est possible de faire une multitude de choses, savoir si ses utilisateurs ont des accès administrateurs

Get-GPPPassword -Verbose | ForEach-Object {$pass = ConvertTo-SecureString -AsPlainText -Force $_.Passwords; $cred = New-Object System.Management.Automation.PSCredential($_.UserName, $pass); Find-LocalAdminAccess -Credential $cred}

attention non discret, ou si ils sont membres du domaine etc.

Impacts Forensics

Il est important de noter que chaque action qui se déroule lors d’un abus de GPO (surtout lorsque des permissions sont exploitées) laisse un certains nombres de traces qu’il est important d’avoir en tête. Dans un premier temps s’il est choisi d’ajouter un privilège à un utilisateur, ce seront les “Event ID” 6144 ainsi que 4704 seront générés. Si c’est un utilisateur est ajouté à un groupe ce seront les “Event ID” 6144 et 4728 qui seront générés. Si une tâche immédiate est créée alors les “Event ID” 6144, 4698, 4700 qui seront retournés. Si c’est un script de démarrage qui est ajouté alors c’est l’ “Event ID” 6144 qui sera inscrit dans les logs du système. Il ne faut tout de fois pas oublié tous les logs qui seront créées à la modification de l’objet Active Directory qu’est une GPO, et le fait d’accéder à un partage SMB et de modifier ce dernier (“Event ID” 5136, 5169, 5143), en plus des différents fichiers qui seront éventuellement laissés derrière. Ces traces seront laissées uniquement si “audit policy” sont activées.

Conclusion

Dans cet article nous avons vu que les stratégies de groupes font parties des éléments essentiels d’un Active Directory, et qu’elles sont très puissantes. Comme toujours leur sécurité ne doit absolument pas être négligée, avec de mauvaises permissions un attaquant possède tous les outils nécessaires pour les utiliser de manière offensive, s’assurant gains de privilège, mouvement latéral ainsi que persistance. J’espère que cela vous aura plu.

Beaucoup d’exemples ont utilisé un scripting PowerShell relativement poussé, il est donc prévu des leçons de PowerShell sur le blog, ce qui a plusieurs objectifs:

• Mieux comprendre le fonctionnement de certains outils (PowerView vue dans cette exemple).
• Mieux utilisé ces derniers (dans le cas de commande en une ligne).
• Ainsi que faire découvrir ce merveilleux langage qu’est PowerShell.

PowerGPOAbuse est disponible sur github, à cette adresse https://github.com/rootSySdk/PowerGPOAbuse