50 lines
3.4 KiB
Markdown
50 lines
3.4 KiB
Markdown
|
|
|||
|
|
==**This technique is incredibly invasive and hard to remove. Even if you have signoff on your red team exercise to perform these techniques, you must take the utmost caution when performing these techniques. In real-world scenarios, the exploitation of most of these techniques would result in a full domain rebuild.
|
|||
|
|
|
|||
|
|
## General
|
|||
|
|
|
|||
|
|
SID history is a feature in Microsoft Windows that allows the security identifier (SID) of a user or group to be preserved when the user or group is moved or renamed within a domain. "Persistence through SID history" refers to a technique used by attackers in which they add the SID history of a privileged account (such as an administrator account) to a normal account, allowing them to gain the same permissions as the privileged account. This allows the attacker to maintain access to a compromised system even after the privileged account's password is changed or the account is disabled.
|
|||
|
|
|
|||
|
|
- Notes
|
|||
|
|
- We normally require Domain Admin privileges or the equivalent thereof to perform this attack.
|
|||
|
|
- When the account creates a logon event, the SIDs associated with the account are added to the user's token, which then determines the privileges associated with the account. This includes group SIDs.
|
|||
|
|
- We can take this attack a step further if we inject the Enterprise Admin SID since this would elevate the account's privileges to effective be Domain Admin in all domains in the forest.
|
|||
|
|
- Since the SIDs are added to the user's token, privileges would be respected even if the account is not a member of the actual group. Making this a very sneaky method of persistence. We have all the permissions we need to compromise the entire domain (perhaps the entire forest), but our account can simply be a normal user account with membership only to the Domain Users group. We can up the sneakiness to another level by always using this account to alter the SID history of another account, so the initial persistence vector is not as easily discovered and remedied.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## Commands
|
|||
|
|
|
|||
|
|
Forging History
|
|||
|
|
|
|||
|
|
- Login has an Administrator (Or user that has the right)
|
|||
|
|
|
|||
|
|
We could use something like Mimikatz to add SID history. However, the latest version of Mimikatz has a flaw that does not allow it to patch LSASS to update SID history. Hence we need to use something else. In this case, we will use the [DSInternals](https://github.com/MichaelGrafnetter/DSInternals) tools to directly patch the ntds.dit file, the AD database where all information is stored
|
|||
|
|
|
|||
|
|
Powershell (Get SID of a group)
|
|||
|
|
```
|
|||
|
|
Get-ADGroup "Domain Admins"
|
|||
|
|
```
|
|||
|
|
- Copy the SID (Will become the SID History)
|
|||
|
|
|
|||
|
|
Powershell (NTDS relanch database -> Patch and Add SID History)
|
|||
|
|
```
|
|||
|
|
PS C:\Users\Administrator.ZA>Stop-Service -Name ntds -force
|
|||
|
|
|
|||
|
|
PS C:\Users\Administrator.ZA> Add-ADDBSidHistory -SamAccountName 'username of our low-priveleged AD account' -SidHistory 'SID to add to SID History' -DatabasePath C:\Windows\NTDS\ntds.dit
|
|||
|
|
|
|||
|
|
PS C:\Users\Administrator.ZA>Start-Service -Name ntds
|
|||
|
|
```
|
|||
|
|
The NTDS database is locked when the NTDS service is running. In order to patch our SID history, we must first stop the service. **You must restart the NTDS service after the patch, otherwise, authentication for the entire network will not work anymore.**
|
|||
|
|
|
|||
|
|
Powershell (Verify the SID has been added to the user)
|
|||
|
|
```
|
|||
|
|
Get-ADUser Low_Prev_Account -Properties sidhistory
|
|||
|
|
|
|||
|
|
-> SID HISOTRY
|
|||
|
|
|
|||
|
|
|
|||
|
|
# Try to enumerate :C/ of the DC
|
|||
|
|
|
|||
|
|
dir \\thmdc.za.tryhackme.loc\c$
|
|||
|
|
```
|