A long old way to Domain Admin: Propagating Infections

On a recent penetration test I made heavy use of Sec-1 Ltd’s tool sharecheck in a way to gain Domain Administrator privileges that had previously been missed. Effectively there was a lot of ground work in horizontal propagation which I automated through Meterpreter and Sharecheck.

I’ve mentioned Sharecheck before on my Internal Penetration Testing post, but I don’t believe I’ve ever ran through the features of this tool which I make use of on almost every test. Effectively this tool allows you to do four main things:

  1. Determine if a Domain User account to which you have access is also a Local Administrator of a machine somewhere on the network
  2. Determine who else has Local Administrator privileges on each machine
  3. Determine the Local Account Lockout policy of each machine on the network
  4. Determine who is currently logged in and therefore potential targets for account takeover

The tool is simple to use you just supply a network range to scan and a username/password combination. The tool can be downloaded here and can be executed like this:

sharecheck.exe -r -u corp.local\holly -p password

The output is a HTML report, which looks like:

There are a couple of things to point out here – this tool will not only show you machines on the network which have no local account lockout (seen here on the second column) .It will also highlight machines out there which don’t follow the standard policies for your network, which can indicate issues with deployed Group Policy. Generally it’s worth scanning a range and playing spot the difference.

If the user you scan the range with is a local administrator of any machines that machine will be highlighted as having the shares C$/Admin$ under the read/write column. This is a really simple way of taking credentials you’ve gained through phishing, spoofing LLMNR, or good old fashioned bruteforce attacks to see  if those accounts have increased credentials. It’s certainly not uncommon to see users who are admins of their own machine and this is a simple way to find them (this is often true of executives! Since you know, they get what they want). You can see this on the first row, the “holly” account which I used to scan the range is an Administrator of the Laptop1 machine.

The right hand column shows which users are currently logged in to that machine  – this is useful as it gives an indication of accounts which may be targeted with Incognito or Mimikatz.

Now the above screenshot is a cleaned-up, simplified set up to highlight a recent way that I used Sharecheck to gain a domain administrator level compromise on a client network – which could have been a touch awkward without this tool. In the above network the account “Admin.Service” is a domain administrator. There are two ways that I could confirm this during the Penetration Test, the first was to hit the domain controller with enum4linux (which I described in my Internal PenTesting post), alternatively I could log in to any domain joined workstation and execute the command:

net groups "Domain Administrators"

The above screenshot informs me that that Domain User account, corp.local\holly, which I compromised using a bruteforce attack is a local administrator of the machine Laptop1. Now the lesson of this post is shown in the above screenshot – there’s a path to compromising the domain admin account and it’s shown in the furthest right two columns: Local Administrator Group and Local Authenticated Users.

Quick FYI, the group with *** next to its name is highlighted because it has more than 10 members in it; it’s good that it does that as sometimes you’ll see large groups such as “Domain Users” who have been given Local Administrative access and it’s good that it’s highlighted for you as a potential target. Also the user account with !!! next to its name is highlighted because it has been disabled, and in this case replace with the “admin” account. This is a good thing to know about since this account is non-standard for this network, in this case the Administrator account came under the protection of LAPS however this “admin” account did not!

Now the machine that I can access with my administrative permissions has the account corp.local\paul logged in to it, which I could compromise with a tool such as Mimikatz; the paul account is highlighted on the second row sixth column’ as being an administrator of Laptop 2. Therefore by compromising Laptop1, gaining access to paul’s account I in term gain access to Laptop 2. Continue that pattern on and you’ll see that by compromising Laptop2 I can gain access to the account Corp.local\emily, who is an administrator of Laptop3. On and on, eventually this leads to compromising Laptop5 through rick’s account which gives us access to the Admin.Service account – which is a domain administrator and therefore a full network compromise.

On the real world engagement, this wasn’t as clean as this simple and neat ordered list. In actual fact I managed to gain access to a handful of accounts through various attacks which gave me access to a small number of machines that I compromised through PSExec. I propagated through the network in exactly the way described above but the machines were a little more organically laid out throughout the network but eventually after around five propagation movements I found myself logged-in domain administrator!

So the vulnerability is effectively Domain Users being given Local Administrative permissions to machines on the network, be it their own machines to install software or the odd server or two for users such as web developers. You can use these small increases in permissions to widen the search for potential domain administrator account which can be compromised by extracting passwords, hashes, tokens or even just key logging. The fix for this in part is reducing user permissions to the absolute minimum and deploying protection mechanisms such as Microsoft Local Administrator Password Solution!