No announcement yet.

enterprise admin

  • Filter
  • Time
  • Show
Clear All
new posts

  • enterprise admin

    I've been on the activedir mailling list and i've heard that it is possible for a domain admin to gain enterprise admin access. I know you can do this pyhsically from one of the root dc's and i know that MS considers the forest the security boundary NOT the domain but i was wondering how this can be done(is it through sidHistory- i think that was taken care of with sidFiltering).
    I ask because i'm an enterprise admin and the IT managers gave each local IT dept. a domain and made them all domain admins but NOT enterprise admins(management doesn't trust them enough for that).
    so i was wondering, how easy it would be for a domain admin to inject him/her self into the enterprise admin group in a win2k sp4 forest, root domain in native mode?

  • #2
    Activedir, ah ? (hi joe ! P)
    (well, I'm lurker too)

    It's quite easy to elevate privileges from DA to EA if your DA ID is in the forest root domain.

    The task of elevating privileges from child domain DA to EA is more tricky as you do not have access to the root domain DCs and have no write permissions over Config and Schema partitions.

    One line of the attack I can think of is exploiting the SidHistory feature. More on this here:

    Another way could be trying to run your own code in the EA context - something like adding your prog to HKLM\Software\Microsoft\Windows\CurrentVersion\Run and wait till user with EA ID logs to the DC. When he logs to the DC, the code will run in EA admin context (and the code can add child domain DA ID to EA group).

    I bet that there are many other ways to tackle this, but the bottom line is obvious: any DA in the forest can elevate himself to EA.
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"


    • #3
      Yeah, i use alot of joeware tools

      As to my question- You can write to the config NC on any DC in the forest-think installing a new DC or Exchange server. Those are written to the config NC on your local dc and then rep'ed.
      You don't need access to the root. you only need access to the schema master for schema changes and the domain namming master if you want to add/delete a domain.

      as to sidHistory, i always thought sidFiltering took care of that exploit...

      The EA is a universal group so its membership is only on GC's. To inject yourself into that group, i assume you need access to a GC in the root domain somehow.

      Speaking of joe, I'm only concerned with how this could be done because he's always ranting about not giving any one DA access and how they can easily becaome EA's but he never says how except thru hints(usually involving localsystem on a DC).
      I still don't know how it can be done and i'd like to know if its as trivial as joe imples.
      i'm really curious to know how(for my own education as well as making the argument to upper management to get rid of allot of our child DA's. If i could show a "proof of concept" of a DA becoming an EA, that would really do it).

      Thanks for your reply!


      • #4
        When you install a new DC, you are creating a server object in Default child domain NC. The creation of NTDS objects in Config NC is implemented not via explicit ACL, but rather Extended Rights which allow a child DA to create objects there.

        SidHistory - I am not sure SID Filtering is on by default on intra-forest trusts, but in any case this is a very non-trivilal vector of attack.

        As for EA group, though is served via GC, but remember that GC is read-only - if you want to write to EA group, you want to be writing to forest rood Default NC.

        I am about in the same position as you are: at least once I want to see one of joe's trick in real life

        But as proof of concept, give this one a shot:

        In child domain, on one of the DC's add to HKLM\Software\Microsoft\Windows\CurrentVersion\Run a new entry which will call a VBS script. Something like:
        strGroupDN = "cn=Enterprise Admins,cn=Users,dc=forestroot,dc=com"
        strMemberDN = "cn=evilDA,ou=accounts,dc=child1,dc=forestroot,dc=com" 
        set objGroup = GetObject("LDAP://" & strGroupDN)
        objGroup.Add("LDAP://" & strMemberDN)
        And logon to this DC via RDP with your EA ID. The script will run and will add the child domain DA to EA group as it will run in the security context of your account (which is member of EA group and has write perms over the EA group).

        Looks like some day we will declare an open hunting season on joe and will torture him till he spits his tricks
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"


        • #5
          Thanx for the script. That can preety much do the trick but it implies you run it in the context of EA.
          I was more thinking of a "hack" run as a child DA with simillar results to get my managers off their duffs

          Also, wheter thru extended rights or direct ACE's, you are writing to the config NC on a child DC. I also think the same think happens when you install an Exchange server or modify the ntds settings of a DC or make it a GC, alter the display specifiers,yada yada..

          Finally, I was digging around the archives of some of my posts to the list and i pulled this one from Roger. This is the one that got me thinking and paranoid-

          Global Catalogs are global catalogs. Period. There is no real distinction
          between domains when it comes to Global Catalogs. Here's why...

          GC's are read only, but only through "normal" (i.e. user) interaction.
          Something has to be able to write to the GC on every DC in a forest, and
          that something is the System account. By launching a process as System
          (which anyone with admin privs to ANY DC in ANY domain could do), you can
          modify the contents of a Universal Group (which exists in the GC). So,
          you're not elevating privs in the root. You're using existing privileges to
          inject an account into a Uni Group, to own the world.

          He implies that the localsystem on a dc can write to any domain NC on any GC in the forest.
          If you want to read the whole conversation, search for "A root dc question" in the topic on the activedir archives.

          Thanks again for the script and ideas and replying.


          • #6
            So I scratched my head a bit and did some googling...

            Group membership is part of useraccount's Kerb ticket (the SIDs are part of PAC in the Kerb ticket). After you aquire the ticket from KDC, you can forge your ticket and add EA group's SID to it. Sounds simple ? Not really... The problem is that the Kerb ticket is encrypted using the server's password.
            Now there is no problem for a user to determine which KDC issued the ticket (it would be one of child domain's DCs) and as you are already a DA and own that DC, you can crack the SYSTEM account's password and use it later to forge your client ticket. Kerb ticket lifetime is 10 hours by default, so the evil DA would probably have enought time...

            Now if you look over here:
            you will notice that you can get away even without cracking the server's password:
            But there's a flaw in the Windows 2000 implementation of LogonUser. This function is implemented in terms of a lower-level (and much more powerful) function called LsaLogonUser, which takes about a hundred thousand parameters (I exaggerate, but only just a little). Anyway, this lower-level function is so powerful that only users with SeTcbPrivilege are allowed to use it, which basically means you need to run as SYSTEM to call it. Why? Because you’re allowed to inject arbitrary SIDs into the resulting token. Want to pretend that a user is really an administrator of the machine? This function allows you to inject the BUILTIN\Administrators SID into the resulting token, so clearly we don't want nonprivileged users calling it! But here's the thing: Because the very useful LogonUser function calls LsaLogonUser, it also requires this same privilege, even though it doesn't allow you to pass in those extra SIDs. Programs that need to call this function on Windows 2000 often end up being configured to run as SYSTEM, even though they might not normally need any special level of privilege. This is bad!
            This is where the part where joe mentions GINA DLL comes to my mind. As the interactive logons are managed by MSGINA.DLL and you can replace the GINA DLL with your own one, it looks like you can inject the EA SID into your ticket...

            And yes, writing to GC directly is indeed a scary thought, but I have no idea how to attack it...
            Guy Teverovsky
            "Smith & Wesson - the original point and click interface"