윈도우 도메인(AD) 기반 취약성 점검 방법

<출처 : http://www.defenceindepth.net/2012/05/exploiting-windows-domain.html>

A common recommendation I often come across is that Internet-facing systems should not be a part of an active Windows domain. As an exercise of interest, I have decided to look at this topic a little deeper and explore what advantage (if any) access to a domain member really provides.

In this scenario I will demonstrate how to gain privilege within a Windows domain using only the tools available on a default Windows install. I will be working under the assumption that:

1. I have access to a public terminal (or something similar) with up-to-date anti-virus.
2. I do not have administrative access on the host.
3. I do not have access to any third-party tools.

Once connected to a Windows workstation, the first piece of information I want to find is the domain namespace. This can be done a couple of different ways:

nbtstat –A <IP-Address>

net config workstation

Next, because I am working from a domain member, I can query the domain controller and check whether it’s aware of any additional domains:

net view /domain

*Note: It is often advantageous to target other domains such as those used for testing and development. These environments will often contain hosts where less emphasis is placed on security.

Next I am interested in knowing what hosts exist on the domain. For this, I can query the domain controller:

net view /domain:<DOM> > hosts.txt

Depending on the size of the network this listing can get quite large. I have redirected the output into a text file to prevent continually query the domain controller.

*Note: This command will not typically respond with every Windows host on the network. Only hosts available via NETBIOS are known to the domain controller.

Because I’m on a Windows domain, I can be fairly certain some machines will have file sharing turned on.  Large networks are often host to a myriad of file shares with “interesting” data on them. It’s not uncommon to find personally identifiable information or even login credentials sitting on workstation or server shares.

To obtain a list of systems with active shares I can query each domain member by using:

for /f %i in (hosts.txt) do @(net view \\%i >> shares.txt 2>nul)

This command will loop over the file containing the domain members (obtained from the previous command) and query each host for open shares. Any errors (i.e. inaccessible systems) are discarded.

As previously mentioned, in some cases you may get lucky and find exactly what you’re looking for within these shares. For the sake of this exercise, however, let’s assume there was nothing interesting found.

Next I am interested in what users and groups exist on the domain. The goal here is to elevate my privileges on the domain (remember, I only have ‘User’ rights on one system thus far). To obtain a list of domain users and groups I can query the domain controller as follows:

net user /domain > users.txt 

net group /domain > groups.txt

Once this information is gathered I want to look for “interesting” user accounts. Usernames containing the words “temp”, “test”, “tst”, “tmp”, "helpdesk", "ftp" are all of interest here as testing and temporary accounts often have simple passwords.

type users.txt | find “test”

If there are no stand-out usernames in the list above I can direct my efforts on querying the groups:

 type groups.txt | find “helpdesk”

The domain controller can then be queried to dump the users belonging to that group:

net group “helpdesk” /domain

*NOTE: I have chosen to target non-administrative accounts here as they typically have weaker passwords. However, it is certainly not unheard of to have weak passwords on account belonging to “Domain Admins”. Always worth checking :)

Having chosen a number of domain users to target I can now attempt to compromise these accounts through password guessing. I can accomplish this through SMB connection attempts against a host on the domain. Which host I choose here doesn’t matter as authentication occurs against the domain controller and not the host itself.

for /f %i in (users.txt) do @(for /f %j in (passwords.txt) do @(echo Trying %i:%j... >> success.txt && net use \\wombat /u:%i %j 1>>success.txt && net use \\wombat /del))

This script will loop over a list of targeted usernames (in users.txt) and try simple password attempts against each account from the passwords.txt file. Success.txtwill keep a log of successful password guesses. Keep in mind here I am only targeting the low hanging fruit. Only a few passwords are being attempted for each account as to not lock out any accounts.

With a small adaptation this script I can choose to target every account in the entire domain:

for /f %i in (users.txt) do @( echo Trying %i:%j... >> success.txt && net use \\wombat /u:%i %i 1>>success.txt && net use \\wombat /del)

Here I am scanning the entire domain for accounts that use their username as their password. This is sometimes known as a horizontal password scan.

The benefits of horizontal scanning become apparent in environments with a large user base. An increase in the number of accounts often improves the chances of discovering an account with a weak password. The chance of locking out an account is also significantly decreased as only a small number of password guesses are attempted against each account.

The above script could also be tweaked to guess the password of the default local administrative account (RID 500) on the current machine. Providing this account is active, it cannot be locked out (meaning infinite password guesses).

Once credentials have been acquired for a domain account the next step is to find out what access the account has. Indeed, it may be the case that only a particular service on a particular host is accessible from the captured account.

The next step in this process is to find out what services are available on the domain. This would be quite simple with nmap... but remember, we don’t have access to any third-party tools! To get around this I have adapted Ed Skoudis’ FTP command line port scanner:

for /f %i in (hosts.txt) do @(for /f %j in (ports.txt) do @(echo Checking %i:%j... & echo %i:%j >> success.txt & echo open %i %j > commands.txt & echo quit >> commands.txt & ftp -n -s:commands.txt 1>>success.txt))

This script attempts to make a connection to each port in ports.txt (I've chose 21\ftp) for every domain member in hosts.txt (found at the beginning of this exercise). It uses the built-in Windows FTP client to read in commands (-s flag) from commands.txt to make each connection. Logging information is stored in success.txt.

Once the available network services have been mapped I can then attempt to exploit / gain access to these services:

In this post I have demonstrated several examples of how domain membership can be abused to gain privilege on a Windows' domain. Due to the inherent verbose nature of Windows’ domains, attackers have the advantage of gaining valuable information about a target network in a relatively short period of time. That said, however, a skilled attacker always has (and always will) be able to penetrate a network’s defences regardless of having domain membership or not.