Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
This chapter is from the book

Network Footprinting

The first step in attacking any network is to figure out what to attack—to develop a "footprint" of the target network. There are many techniques for this. For a full discussion, see one of the excellent books in the "Hacking Exposed" series. The basic goal is to learn more about the network. There is a lot to discover, including, but not limited to, the following:

  • Network address ranges
  • Host names
  • Exposed hosts
  • Applications exposed on those hosts
  • OS and application version information
  • Patch state of the host and the applications
  • Structure of the applications and back-end severs
  • Implementation details the sys admin posted to newsgroups or told a reporter about

Network Address Ranges

The first step is to find the logical locations for the networks of interest. We are performing a penetration test of victimsrus.com, so we start by looking up what networks are registered to victimsrus.com. Doing so is really simple, since address ranges are public records. You can just go to http://www.samspade.org and type in "victimsrus.com" and press Enter. Out will come all kinds of useful information about the address ranges of victimsrus.com, including contact personnel and so on.

However, perhaps even more interesting than the publicly registered address ranges for victimsrus.com is any information on networks possibly connected to the target network. For example, there may be an extranet located at extranet.victimsrus.com. This extranet is not publicized as well as the core victimsrus.com, so it is a good bet it is not secured as well as the main public network. In addition, you may know that some other company is a business partner of victimsrus.com. They may very well have direct links into victimsrus.com. If so, it may be easier to attack them and jump from there to victimsrus.com. Keep in mind the first principle of successful attacks: Sometimes the shortest path to your goal is not through the front door.

Attackers are as lazy as everyone else. Why make things more difficult and attack a well-defended network or host when you can take the simple approach and attack a poorly defended one and then take over the well-defended one from the back (see Figure 2-2)?


Figure 2-2 Why attack a well-protected front door?

Far too often, we forget this concept.

Because an attacker will always endeavor to find the simple way to attack something, it is important to realize that no network can be any more secure than its weakest link—the most insecure network or computer that is connected to the target. Next time you get requests to link a partner network into your organization's network, ask what kinds of security practices and policies are in place. If they are not at least as good as yours, you probably should take steps to mitigate any spillover effects of their poor security. Be sure you know what the security policy is for any partner networks that connect to your network. Although a service level agreement (SLA) is poor consolation when you get attacked, it would be useful to look to see how they plan to keep their network (and by extension, yours) protected.

Host Names

The next thing the attacker needs is host names. In some cases, it is possible to perform Domain Name Server (DNS) lookup requests on large swaths of the network. In some cases, it is even possible to perform something called a zone transfer. A zone transfer is simply a request to a DNS server to send a copy of an entire DNS zone—a listing of all the registered names in the network. Although host names are not critically important to most attacks, they can make certain attacks much simpler. For example, if you have the host name of a Web server running IIS, you can deduce the anonymous IIS account for that host because it is usually called IUSR_<hostname>. Now let's assume that the administrator has done something really useless and configured account lockout on that system. All an attacker has to do to take down that Web server is to send a large number of requests to the server asking it to authenticate you as IUSR_<hostname>. In short order, he can send enough bad passwords to lock out the anonymous user account. After that account is locked out, he can just keep sending enough bad requests to keep it that way and this Web server will no longer serve anything to anyone. In Chapter 11, "Passwords and Other Authentication Mechanisms—The Last Line of Defense," we discuss passwords, but for now, remember not to enable account lockout on public-facing servers (or anywhere else for that matter).

Exposed Hosts

More interesting than host names are the hosts that are actually exposed. In this phase of the attack, we are trying to locate easy targets. Doing so may be absolutely trivial. You may not even need any tools, as long as 3Internet Control Message Protocol (ICMP) traffic is not blocked at the border. In that case, this command is perfectly sufficient:

c:\DiscoverHosts 192.168.2

Obviously, the IP address at the end would need to be adjusted to the appropriate target range. DiscoverHosts is just a thin wrapper around ICMP echo (ping) to check who responds on a particular network. If ICMP echo is not blocked, we just sit back while your network generates a list of valid addresses.

In the vast majority of cases, ICMP traffic should be sent to /dev/null at the border, but it is surprising how often administrators forget to ensure that it is. While this does not really stop enumeration, it makes it marginally more difficult because the attacker needs to rely on custom tools, called port scanners.

A port scanner is simply a tool that attempts to ascertain which ports a host is listening to. This can be done, for instance, by attempting to make a connection. A successful connection means the host is listening. An unsuccessful connection usually means it is not. Going into depth on port scanners is far beyond the scope of this chapter. However, a few basics are important. First, the most common type of port scan is known as a SYN scan. A SYN scan is where the attacker sends a SYNchronize packet to a target. If a host has an application listening on the port the SYN packet went to, it will respond with an ACKnowledge packet, and the port scanner will report an open port. You can port scan an entire network in short order. Doing so on a range of well-chosen ports can give you a tremendous amount of information on what is available on the network. We personally also like scanning for ports that should never be listening outside the firewall, such as the SQL Server port and Server Message Block (SMB, a.k.a, Common Internet File System or CIFS, a.k.a. Windows Networking). A host responding on these ports may be accidentally exposed to the Internet, indicating a misconfigured firewall. Be careful with that assumption, however. Some firewalls, such as Microsoft ISA Server, support server publishing, where the firewall publishes the port and inspects all traffic to it before forwarding it on to the host. In this case, although you can still get to the host, some of the possible attacks may be blocked by the firewall. Other attacks may succeed, depending on the type of service published and the types of inspection performed by the firewall.

If the host is there but has no process listening on a port, an attempt to connect results in a refused connection; most port scanners will not report those. They are important, however, because they enable us to actually determine how a firewall is configured. For example, a host may return the following results:

Port refused
Port open

This tells us that this is a Web server since it has port 80 open. We also find out that the firewall has published port 443 (HTTP/S) for this server. However, the server is not listening on that port. In other words, there is an unnecessary hole in the firewall. We will get back to that later.

Applications Exposed on Those Hosts

Port scanning is a way to determine what applications are exposed on a host. This allows us to get information on possible vectors for attack. Some of the commonly looked-for applications include the ones on the ports listed in Table 2-1.

Table 2-1. Some Commonly Scanned-For Applications

TCP Port



FTP data channel


FTP control channel






Connection-oriented DNS (resolution is on UDP 53)




Internet Key Exchange (IKE)


POP3 (Mail)


Windows RPC Endpoint Mapper


NetBIOS Name Service


NetBIOS session






Common Internet File System / native SMB on Windows 2000 and higher




SQL Server (1434 if your port scanner can do UDP)




LDAP to a Windows Global Catalog Server


Remote Desktop Protocol (Windows Terminal Services)

Naturally, many other ports can be open, particularly if the target system is not a Windows system. However, these are the ones we look for in this chapter.

OS and Application Version Information

If we can, it is very useful to get information on the version of the applications that we found. For example, many applications have some kind of banner that is sent as soon as someone connects. Most SMTP and POP servers as well as many Web servers are configured to do this, for instance In our case, the target network is running IIS 6.0 on Windows Server 2003, and IIS 6.0 does not send a very useful banner. (Note that IIS 6.0 may leak the IP address of the server in the banner. If this is important to you, you need the hotfix in KB 834141.)

Patch State of the Host and the Applications

It is also very interesting to an attacker to find out what patch state the exposed servers are in. This information can be had in different ways. In some cases, the banners presented by the applications will tell us all we need to know. For example, sendmail banners usually tell you the version number of the daemon. If you know which version of sendmail contains unpatched vulnerabilities, you have all the information you need to begin an attack to that system. In other cases, you can interpret from the responses the system is giving you whether it has a particular patch or not. This is essentially the technique used in good vulnerability scanners and in OS fingerprinting tools. As a last resort, an attacker may fire off an exploit against a system and see what happens. This is often the technique used by vulnerability scanners to look for denial-of-service attacks. If the system still responds after the attack, it was obviously not vulnerable!

This last point leads us to one of the important things to realize about unpatched vulnerabilities. Generally speaking, in penetration tests we prefer not to use methods that depend on unpatched vulnerabilities to break into systems. Proving that they are there is interesting, but because vulnerabilities are almost always unintended functionality, using them runs the risk of destabilizing the host and, consequently, the network. If you are doing a penetration test, bringing the network down in the process is highly unlikely to be met with a lot of cheers, and could cut the exercise a lot shorter than it should be. For a real attacker, using unpatched vulnerabilities as an entrance to the network is also a last resort. In general, it is rather noticeable when a server crashes. If the attacker can get in without using potentially destabilizing techniques, he will surely choose to do so. However, if using unpatched vulnerabilities is the only way in, the attacker will absolutely use them.

In Chapter 3, "Rule Number 1: Patch Your Systems," we look into patch management in more details and discuss what happens if you have unpatched vulnerabilities. However, for now, let's just note that the target network in our example is completely patched. All the systems have all the latest patches.

Structure of the Applications and Back-End Servers

If you can, it is usually very helpful to get information on the structure of the application and the back-end server(s), if any. In many cases, this is very difficult to do, but in some cases you get lucky. For example, assume you have a target network that uses a particular third-party Web application with very distinct filenames and page designs. In this case, it is often obvious to the attacker which application you are using. If the attacker is familiar with the application, he may know how to exploit it. For instance, the application may use a configuration file called %webroot%\system.config. If files with the .config extension are not parsed by the Web server, the attacker can simply request this file in a Web browser. In a best-case scenario, that file will only give him information such as the names of the back-end servers and databases. In the worst-case scenario, that file will contain the username and password used to actually establish the connection between the Web server and a database server.

Do not make the mistake of dismissing this as a contrived example. It is not. This exact situation was encountered a few months ago as we were evaluating a customer's network to see whether there was anything they could do to improve security. A very large number of commercial Web applications are extremely poorly written, essentially turning them into a wide-open back door into the network. To learn how to spot the obvious flaws, turn to Chapter 16, "Evaluating Application Security."

Implementation Details the Sys Admin Posted to Newsgroups or Told a Reporter About

It is amazing how much information you can glean about a company's network implementation by trolling newsgroups and magazine articles. Far too often, the system administrator posts questions that reveal sensitive details about their network, the types of systems used, firewall configuration, and other things. In a few cases, there have been magazine articles that intend to highlight how good a company was at building their network. Unfortunately, they also provide the attacker with a blueprint for what they missed. Be extremely careful what you say in newsgroup postings and to reporters. We find that not speaking to journalists at all is a preferred approach. Also be careful with the information in those "out-of-office" messages you set when you go on vacation:

At this point, we have just about all the information we need to start the attack. The first step is to establish an initial foothold into the network—pierce the eggshell if you will.

  • + 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