RSS Feed
« Fuzzing FIX | Main | AlienVault OSSIM 4.2 - Enabling Custom Install »

When Domain Admin Is Not Enough

When conducting a network pentest we often find the goal of the tester, at least on a Windows domain network test, is to get Domain Admin. That is well and good, but for impact nothing beats capturing the CIOs desktop, documents or e-mail. So how do we get there?

When we are testing networks we often talk about network mapping and recon.  Its almost described as a matter of course in most books on network hacking. Sadly, often a tester will run Nmap and not even wait for the results before kicking off a scanner or running an exploit.

In actual fact, network reconnaissance can be the most important part of an assessment, and Nmap isn’t always the best or most appropriate tool for this particular job. Never underestimate the use and value of tools such as Wireshark, traceroute, ping and tcptraceroute in mapping a network.

When pentesting a Windows network, we’re probably going to be running Nmap near the start of the engagement, however at this point we are unlikely to be authenticated to the domain. We need to remember to come back to this as soon as we have managed to gain access to our first domain account - the first toehold.

The Kung Fu Toehold

Getting that first toehold can be tricky, but there are a number of ways:

  1. Sniffing (ARP poisoning or even just listening to broadcasts)
  2. SMB traffic redirection
  3. Exploit a single unpatched host

With SMB redirection we can capture hashes and crack them, but that is CPU intensive and often there are easier ways.  However sometimes the simple ways are still the best - printers can be very helpful. With only read access to printer queues, we have a goldmine of usernames. 

Dont Lock Out The Domain

Next we can kick-off a brute force attack - but lets be smart about this. Most Windows networks have account lockout policies in place. This could result in a tester doing a Denial of Service on the network if they’re not careful. Try explaining to a systems admin why you’ve locked out all of the users in the middle of the day - not something you ever want to have to do. So we need to think around the problem and proceed carefully.

On a recent test we managed to gather 20 usernames, and the lockout policy would have locked us out after 5 failed logins. So we carefully chose 3 passwords and tried them on all the accounts.  This resulted in 4 compromised accounts.  In this situation the password policy strength was set to complex passwords,  but human nature being what it is “Password1” worked for more than 1 account - make sure you think like a normal person, not a security tester. If we know a company has a strong password policy (for example, 6 characters, 1 special, upper and lower), try and come up with the easiest options that match this. “Pa55word!” would work, or even better use permute.exe and give it the company name. 

From Humble Beginnings

Now that we have one or two user accounts we can get all the usernames from the domain, we can fully identify what the password policy is, and we can find out who the domain administrators are.  Tools such as and Nmap are fantastic when we want to enumerate users from domain controllers.   We could then just repeat this process and brute force out passwords hoping to get lucky - perhaps  a domain administrator has got the password of “Passw0rd1”  but its unlikely.  If we use the information we have gathered to identify interesting targets this would more likely result in access to the real goal - data.  Also remember with domain access you can potentially view corporate Intranet pages, or sometimes we can see this without a username and password.  If we don’t already have it from external recon, we are likely to find data on the CIO (their name at very least), and perhaps members of the Board. Remember that organisational charts are often a boon in this case.  At this point, hopefully, we now know who we are targeting and can make a decent guess at the  format of the username.

Stay On Target

So now we have our target accounts, what next?  We could use the company Intranet site again;  perhaps finding XSS and using tools like “Shell of the Future” or “BeEF”  to poison requests from the users that we particularly want when we see them come in.  We could even redirect those requests to Metasploit http-ntlmrelay and target specific boxes. This may succeed, however, it could be less surgical than we require. Enter Nmap again.

With Nmap’s SMB scripts and an authenticated user acount we can get the name of a user that is logged in and the IP address of their host machine when scanning the domain controller.  This gives us our target host - the CIOs laptop/desktop.  Once again we may get lucky - this box may not have  been patched. However it is likely that it will be, CIOs are important  and tech support like to make sure that they’re safe.  What next? We could send a malicious document via email. This may hit antivirus, or they may not open it. What we need is hosts that the CIO has sent their password to.

Say we breach a mail server, Citrix server, or even an Intranet web server - we are likely to get something very useful, user passwords. Lost of users will login to these hosts.  We can start off by pulling out the hashes from these machines and passing them across the network.  It is likely that more systems can be compromised this way, however there is a cleaner way. If we want the CIOs desktop we really also want the password in our hand,  so we can turn to WCE.exe, mimikatz or procdump

Windows Credentials Editor, mimikatz and procdump are awesome pieces of software.  They will pull decrypted passwords out of memory (in the case of procdump just the memory). No nasty cracking,  rainbow tables or hash passing.  We just need admin access on the host that our target is logged into, and to disable the antivirus (we’ve found pulling passwords out of memory can trigger some modern antivirus solutions).  This could be a mail server,  Citrix server or perhaps even a desktop.  We dump the passwords and were done.  So we now have the CIOs credentials, but there’s one more thing to think of.

One Desktop To Rule Them All

The next activity is so simple it took me a while to realise how powerful it was.  Presuming we have admin access to a machine on the domain (the CIOs desktop), we can RDP into that host as a privileged user, use “Run As”  with the password or token (via incognito) of the CIO to get a shell, and kill that user’s instance of Explorer.  Then run Explorer from the shell that you have just started.  Your desktop will restart as the CIO  user. We can now easily startup tools like Outlook and have Windows do all the hard work for us.  We can also use this technique when targeting developers.  Using Windows authentication tokens extracted by Metasploit to do the same thing and start up SQL Server Management Studio and (if the SQL Servers are using domain authentication) connect directly to development SQL Servers.  Often the passwords used on those machines can potentially give you access to production hosts.  So just remember Domain Administrator is good, but it isn’t always the most interesting user on the network.


Nmap (smb scripts)
Nmap (ldap scripts)
Metasploit (smb_relay)
Metasploit (http_ntlmrelay)

Reader Comments (1)

You can take the forest hostage
September 19, 2013 | Unregistered CommenterAndre Gironda

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.