Online sIDHistory edit / SID injection

As probably most of you know way back Microsoft had to back track on their initial claim of the domain being the security boundary to state that the forest is the security boundary. This due to the way kerberos works. The SIDs in the access tokens are not verified by kerberized services, but to forge access token requires some serious privileges to start with. If you are domain admin then it has been possible to manipulate the AD dit database to add abitrary SIDs to the sIDHistory attribute.

There already are offline AD database editing tools like SHEdit (SID History Edit). This tool circumvents the DsAddSidHistory() limitations allowing an domain admin in any domain to access any domains in the forest as any user. With Samba4 it's possible to do an online sIDHistory attack by joining a Samba4 DC to an AD domain and then use the Samba4 ldb database edit tool ldbedit. The ldbedit tool can be used even while samba is being used. With a Samba4 DC in your domain sIDHistory editing becomes really easy.

So a quick walk through...

Here we can see three DCs DEV01 and DEV04 are both Windows 2008 R2 DCs LUX01 is a Ubuntu 10.04 Server. Follow this guide on samba.org to join a Samba 4 server as DC.

After we successfully added a Samba4 DC into the domain and have it synchronizing we create a new user.

A brand new test user.

Only member of Domain User.

The sIDHistory attribute is empty.

Now we need to go to the Samba4 box and edit the newly created user in the Samba4 ldb database.

Run ldbedit.

The ldbedit tool allows us to edit all the domain objects in vi in standard LDIF format. This tool is very powerful.

Add in the sIDHistory atribute with the Enterprise Admins SID (S-1-5-21-2343920589-472558339-514900765-519).

After a few seconds let's have another look at the sIDHistory attribute. Nicely populated with the Enterprise Admins SID.

Now we go and login to the DC (which a normal Domain User shouldn't be able to do unless we change the default policy, which we haven't done here) with the user which only was a member of the Domain Users group.

We run whoami.exe and tokensz.exe.  Whoami shows us who we are logged in as and tokensz shows us which SIDs we have in our access token. As we can see here we have the Enterprise Admins SID. To just make sure that it works in practice let's add our self to the Enterprise Admin group. We aren't a member of the group yet. We only have the Enterprise Admins SID in our access token.

Only administrator is in the group.

Now we added our self to the group without any problems.

Bottom line, Domain Admins are Equivalent to Enterprise Admins. The forest is the security boundary, but you knew that already. Anyway this is a very accessible and online version of the sIDHistory offline edit so nothing is really new here. Enjoy!

//Johan Akerstrom