Thursday, August 12, 2010

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 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


  1. Really nice work! Good tutorial!

  2. That surprises me, but I don't know enough about Linux/AD integration to understand why this is possible. I would have thought AD must validate the data that comes from the Linux server sync and impose the same security rules for attribute editing that it does when you edit attributes from a Windows OS, otherwise what is stopping you just using this method to join any standard user to the domain admins group (by setting the primary group ID of that account to the domain admins RID for example). Anyway, interesting article :) thanks

  3. cjwdev,

    It's not as bead as you seem to think. The linux box is still added to a child domain as a DC. This needs domain admin privileges. So you only escalate domain admins to enterprise admins, which has been known for ages. Just haven't seen the "attack" done online or with samba 4 before. :)

  4. Hi Johan

    Its me Akmil
    I need to add a sid history to a user (single user) any other way of putting it in - its a protected field in ADSI edit

  5. Using mimikatz you can now do this without having to join a samba server to the domain or needing Domain Admin privilages. Check out mimikatz misc:addsid

  6. I know this is old, but couldn't you also overwrite the SID directly, bypassing SID filtering entirely?