Get a client workstation, own the domain.
Results 1 to 10 of 10

Thread: Get a client workstation, own the domain.

  1. #1
    Junior Member
    Join Date
    Jun 2005
    Posts
    20

    Get a client workstation, own the domain.

    Like the title? I thought you might. So you might be wondering what I mean by owning a domain by getting only one workstation? Is it even possible? Well, before this year it was very difficult to do. Now, it's way too easy and I will share the reasons why.

    Let's talk about workstation security for a second. I would guess that most companies don't even worry about completely securing client workstations. In most companies that level of attention would take waaaaay too much time. Besides, compromising a workstation only gives a few key pieces of information. None of which are that useful for compromising a domain. Check it out:

    1. You can crack any local account passwords on the box. Chances are slim but the password for the local adminstrator account may be the same as the password for the local administrator account on all of the other workstations. The chances are even slimmer but the password may be the same as that on servers.

    2. You can dump the LSA secrets which reveals clear text passwords for accounts that are used to run local services on the machine. The chance that this will reveal anything on a client machine will be slim.

    Lets be realistic though...your testing a fairly secure network here. You've compromised one workstation due to a default install of msde with a blank sa password. However, this is the only workstation that you've gotten into and you've already checked all the other machines in the domain. Where do you go from here?

    Now, thanks to Arnaud Pilon, you have a chance using a new tool called CacheDump (http://http://www.cr0.net:8040/misc/cachedump.html). Let me give you a little background first.

    When you log into Windows, it is kind enough to cache your password in the registry. This caching process can be disabled but by default it is enabled and for a good reason. Consider this...you have a laptop that you use at work. You log on to it using the username and password for your work domain. When you take your laptop home, even though you are not connected to the work domain you can still log into that laptop with the same username, password and domain. This is made possible by the password cache that is stored in the registry for your username. Nice functionality huh? Without it you would have to have a local user account to log in with and you would have to maintain two different passwords...one for your domain account and one for the local account. What a pain. So here is the classic case of security vs. functionality.

    So a Windows machine will cache domain user account passwords, big deal right? This is a huge deal. Let's say that a domain admin logs into your workstation. He/She leaves behind a cached password for a very privileged account. Even worse, let's say you use Altiris or Microsoft SMS to remotely install and administer applications on client workstations. The whole purpose for using these products is to facilitate an application setup by giving it administrative privileges for a user who is not an administrator. So Altiris/SMS is logging into almost all of your machines using a very privileged account and the cached password hash is being left behind on every machine.

    Now where were we...you've compromised one workstation and your stuck. What do you do now? You bust out CacheDump and run it as follows:

    c:\cachedump (wow, complicated isn't it)

    domadmin1:0E9A658F6132E709ED673458387E6892:work:work.comp.corp
    entadmin1:19E8B953689EFBC3222ABC599F835856:comp:comp.corp

    The output shows you the cached password hash for a domain admin account in your domain and an enterprise admin account in the parent domain. So you copy this information into a text file called hashs.txt and run a custom version of John and crack all the passwords as follows:

    c:\john -format:mscash hashs.txt

    It's only a matter of time now.

    The game is changing. Now your workstations are just a important as your domain controllers and you member servers.

    Want the tools discussed in this article?

    CacheDump v1.1, diffs for John that include the mscash format, and how to build the custom version of John can all be found here:

    http://www.cr0.net:8040/misc/cachedump.html

    To dump LSA secrets I prefer Cain & Able which can be found here:

    http://www.oxid.it/cain.html

  2. #2
    Senior Member
    Join Date
    May 2003
    Posts
    1,199
    There is atleast one MAJOR flaw in this thing. You assume that the work stations are not locked down. Most companies WILL lock down work stations. You can puch out policies that will lock down the box after the first restart after being joined to the domain. Now if the computers were not on a domain but just a network it would be different. Some of your points are vaild, but are very well known flaws and the majority of these types of problems are taken care of by a halfway decent tech.
    Everyone is going to die, I am just as good of a reason as any.

    http://think-smarter.blogspot.com

  3. #3
    Junior Member
    Join Date
    Jun 2005
    Posts
    20
    Great point. I agree completely. However, a large network is much harder to secure than a small one. Even after group policies have been applied there is still a pretty good change that at least one machine exists with a missing patch that will lead to a SYSTEM level exploit or there will be an admin account with a blank password. One domain machine could lead to a complete domain compromise using this technique.

  4. #4
    Senior Member
    Join Date
    May 2003
    Posts
    1,199
    the number of computers on the domain has nothing to do with the likley hood tha one will fail to properly implement pushed out policies and updates. So the chance remains the same for exploitation. the difference would be a larger network may draw more attention for potential attacks, and also offer a wider variety of services that need to be pached. But still the failure will then be on the hands of the tech creating the policy, not on the singe computer.
    Everyone is going to die, I am just as good of a reason as any.

    http://think-smarter.blogspot.com

  5. #5
    Senior Member
    Join Date
    Oct 2001
    Posts
    748
    Originally posted here by reedarvin
    Great point. I agree completely. However, a large network is much harder to secure than a small one. Even after group policies have been applied there is still a pretty good change that at least one machine exists with a missing patch that will lead to a SYSTEM level exploit or there will be an admin account with a blank password. One domain machine could lead to a complete domain compromise using this technique.
    But then you are also assuming that a domain admin has logged into that system. Working in an extremely large enterprise environment I'll agree that it is hard to make sure that every machine is locked down. However, oru domain admins don't go around just logging into any given workstation with domain admin privileges. You are also assuming that they never age the passwords on the domain admin accounts, or that the domain admin has logged into that machine in the last xx number of days and the account hasn't been aged. Or even that you will be able to crack the password...

    Our domain admin or exchange admin passwords are a minimum of 14 characters, following a pretty complicated password scheme. You won' t be able to easily crack it without some serious processing power.. Is this an issue? I don't see it as being one. Atleast not one that isn't easily overcome with basic and simple security precautions.

  6. #6
    Lets not forget that if you have physical access to a machine, it is just a matter of time before you can exploit it.

    There are many ways to do this, either through a direct escalation of privledges exploit, or social engineering, etc.

    For example... I worked at a very large company... And the network was locked down tight... except... the night shift supervisor had an administrator account. When he left for lunch, he left his computer logged on. And BAM... I had an administrator account.

    If you're trusted to be around and on the machines, you can own them given time.

  7. #7
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    This has already been discussed in detail, here:

    http://www.antionline.com/showthread...r=1#post841118

    The bottom line is, if a domain admin ever logs on to a workstation, the domain security is automatically compromised. To retain NT domain security, domain admins must never log on to workstations.

    Slarty

  8. #8
    Member
    Join Date
    Dec 2003
    Posts
    97
    The other important question is that windows password caching, to my knowledge, only works when logged on through the console. That is to say, logins for the starting of services, or the use of Run As or a connection through SMS or Altiris...as none of these is doing a console log on, the credentials aren't cached.

    Please correct me if i'm wrong.

  9. #9
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    Just adding something to slarty' explanation, its pretty common nowadays a rule that states
    "if you log in on a workstation as an admin, after you log off you should have the user log on again immediatilly after you while you are looking".
    And, of course, use max cached profiles = 1.
    On my (big) clients, workstations cant cache profiles (zero); only portables devices can (laptops), but cached profiles are allways limited to 1.
    You can prevent using this kind of procedure.
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  10. #10
    King Tutorial-ankhamun
    Join Date
    Jul 2004
    Posts
    897
    If the password is good, it will take a long, long, long time to crack. By the way, you can also do domain password cache crack it from Cain:

    http://www.irongeek.com/i.php?page=v...sswordCracking

    it's just a small part of the video abovem but it will show you how to set up cachedump and do it, or just use Cain with a few clicks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •