Our internal penetration testing usually consists of three scenarios: the evil consultant, the disgruntled employee, and the dishonest cleaning staff. These persons all have access and opportunity for unauthorized activity. Hackers have been known to dress up as cleaning staff or to actually obtain a job as a janitorial person to gain internal access and to open back doors for access later from the outside. Each scenario entails nearly the same procedures with a little variation. For the evil consultant scenario, we ask the system administrator to give us an account normally given to a consultant or vendor. Many times consultant accounts have been restricted in some way or placed into a group with fewer access rights than a normal employee user account. However, even with these restricted accounts consultants have access to many resources and information that could enable them to gain unauthorized access to critical data. For the disgruntled employee scenario, we just obtain a normal user ID and see what assets we can access or abuse. For the cleaning staff scenario, we plug a laptop into the network and see where it will take us.

All internal testing requires coordination with company personnel to make sure access to the facilities and proper user IDs (for each scenario) are established. Also, close coordination helps limit your liability. When you conduct testing internally, you have more opportunity to unintentionally damage the network. Internal coordinators should be consulted before performing any testing that could harm the network or critical resources. Also, the internal coordinators can act as witnesses to defend you against unwarranted accusations. Sometimes system administrators blame a system problem that arises during the time of the testing on the test, even if it is totally unrelated. By having a member of the company or department observing your activities, you can provide a reasonable alibi against these accusations.

For the evil consultant scenario, we set up in a conference room or separate workspace. Depending on company policy, we use either a company-owned workstation or our own laptops. (Some organizations do not allow outside laptops on the network or even onto the premises.) We sign on with the consultant account and move onto the next stages of the test. Then we load our tools, if possible, and start the discovery phase.

For the disgruntled employee, the situation is nearly the same. We usually use a corporate workstation and sign on as a normal employee. From there, we attempt to gain administrator access over the system. We then load our tools and move on from there. If we cannot gain administrator access over the local system, we continue with applicable test procedures.

The cleaning staff scenario usually requires us to be creative. We normally either use our laptops or take over a workstation during off hours when fewer company employees are on site. Hopefully we are able to find a live network jack outside of normal view. If the client uses DHCP we plug in to the network, obtain a DHCP address, and move on. If the client does not use DHCP, we have to find a valid IP address if we want to do anything more than sniff the network. First, we try to walk around and look for clues. Many times companies list IP addresses on computers, workstations, or other devices for troubleshooting purposes. If you find one of these addresses, you can do one of two things: either use an address one or two numbers higher or lower than the address and hope it works, or disconnect the device and use its address until you can find another. Once you have obtained the IP address you can perform a ping sweep to find an open, unused address and use that for the remainder of the testing.

You need to be careful when using static IP addresses. If you select one already in use, you may cause IP address conflicts and be discovered. Select your IP addresses wisely. As a system administrator, take note of the ways a casual observer could determine your internal IP addressing scheme and guard against it. Disable unused network jacks, look for IP conflicts, and do not openly display machine IP addresses.

Once we have gained physical access to the network and obtained a valid IP address we can begin the discovery phase. During discovery we try to map the network, identify critical resources, and look for holes to exploit. We use a number of tools during the discovery phase. Our first step is to perform a ping sweep of the address ranges to identify hosts that are alive. We use tools such as Pinger, NetScanTools, or WS_Ping ProPack to perform the ping sweep. The tool attempts to ping a range of network addresses; any address that is active will respond, indicating that a system is alive and using that IP address. If ping has been restricted on the internal network or the system is not active, we receive a “host unreachable” or “timeout” message. We can begin by pinging addresses in the network block of the IP address we obtained. In addition, we can find other potential IP ranges from sniffer data, client systems' ARP tables, SNMP data, and routing information.

Once we have identified active hosts, we can start to map the network. By performing traceroutes to each host, we start to locate routers, firewalls, and other gateways that may segment the network. Using traceroutes we can begin to build a relatively accurate network map. VisualRoute is an excellent tool for performing traceroutes. It is easy to use and provides a nice GUI interface. (For more detail about how to use VisualRoute, see Chapter 12.)

Next we attempt to learn internal addresses and computer names by performing a zone transfer on the internal DNS server. Often zone transfers are not restricted on internal DNS servers. The zone transfers on internal DNS servers often help identify excellent target opportunities. As we have mentioned previously, it is fortunate for the tester and unfortunate for the organization that many system administrators provide a description of the type of server within the host name. For instance, with host names such as “XYZ_IIS1,” “XYZ_PDC,” and “XYZ_SQL” it does not take long to identify critical servers that may serve as excellent targets for hackers. If you know the company's server naming convention, you are in an even better position. To perform a zone transfer internally you can use either nslookup or a tool such as Sam Spade. If the network uses DHCP, you will already know the IP addresses for the DNS server since it will be contained in your network configuration information. You can locate this information by typing ipconfig /all for Windows NT and ifconfig for UNIX. If the network uses static IP addresses, you may have to work to find the DNS server. Looking for a target with port 53 open may lead you to the DNS server. Also, if you are using an internal company workstation for the testing, the DNS server should be included in the IP configuration information. Finally, we could use a sniffer to examine DNS traffic to identify the IP address of the DNS server.

From the ping sweeps, traceroutes, and internal DNS information we can start to develop our target list. The next step is to identify services that may be exploitable and may give us more information about the device. Nmap is a superior port scanner, and in addition to performing port scans it can also perform OS identification. Use Nmap with the “-O” option on the systems identified in the ping sweeps to determine the OS of the target (for more information on Nmap see Chapter 13). Knowing the type of OS will help determine which ports we will scan for during the port scan. For instance, if we find all the systems are UNIX based, there is no reason to scan for ports 135–139 (NT, NetBIOS). Port scanning can set off intrusion detection systems and generate alerts in system logs. Therefore, we generally start with “surgical” port scans to minimize the risk of detection. During the surgical port scans we scan for 10–20 ports that are likely to be on the host and that we know are normally easy to exploit. (Chapter 13 provides more detail on actual ports to scan depending on the OS.) Upon completion of the port-scanning phase, we have a list of hosts that are active and a traceroute to each system. In addition, the list contains information on the OS and open ports for each host. The results of this list greatly affect the next steps we take. The ports that are open necessarily influence the testing procedures that we use to further explore the systems. Below we touch on some of the more common ports we find open and how to test whether they are exploitable.

We have to keep in mind that normally the goal of testing is to find and plug the holes, not necessarily exploit them. The open port data gives us information to act on to fix the systems. Each open port represents a potential entry point into that system. Unfortunately for the system administrator, many applications and operating systems install with many of the ports open by default. NT, UNIX, IIS, Apache, and other software that is installed right out of the box without any additional action to secure the system leave many holes open. At times, the system administrator does not even realize the service or port is installed on the system because he or she never actually opened it. Also, many times when systems are preloaded with software several ports are opened by default but not needed. For instance, preloaded Compaq servers often come with the Compaq Web Management Interface installed and running on port 2301. Attackers can exploit this Web interface to gain administrator access to the system. Therefore, the list of open ports should be compared with the ports that are required to be open for business. Upon completion of the test, you or the administrator should conduct a full port scan against critical servers to identify any ports that may have been missed. Any ports that are not needed should be closed. Any ports that administrators are not aware of should be further investigated to determine whether they are needed.

Usually you will be able to figure out what service is running on most of the ports identified during the port scans. However, there will be ports that you do not recognize or that are not defined. Banner-grabbing programs can be used to help determine what is running on the port. (You can find more information concerning banner-grabbing tools in Chapter 12.) In addition, the banner-grabbing program can help identify the type and version of the service running on each port. The banner-grabbing program attempts to connect to the service running on that particular port and capture the output provided from the service. Normally, the output helps identify information about the service that is running. You can then use the information about the service to search vulnerability databases, such as www.securityfocus.com, for any published exploits affecting the service.

At this point in the testing, it is a good idea to review and organize the information you have collected. By consolidating and analyzing the information you can begin to see where holes might lie and design a plan to test for them. Build a quick table that lists the IP address, host name, operating system, open ports, applications, and any comments that may be useful as you move forward. Table 7-1 provides an example of how we normally organize this information. You can add or delete columns as you see fit. The important point here is to have the information organized into an easy-to-use format to aid in the testing.

What to do next largely depends on the operating systems, applications, open ports, and vulnerability information discovered. We normally have a set of exploits we try on NT, UNIX, and Novell systems. In addition, each application (IIS, SQL, Oracle, and so on) usually has vulnerabilities associated with it that we can attempt to exploit. In the following text, we start by describing techniques to try for common ports, then examine some testing methods for each operating system, and finally describe how you can look for additional exploits on your own.

After you have connected to the ports using banner-grabbing software, you can begin trying to log into each open service to gain access or to learn information that will help to gain access. First, try to log in to FTP (port 21) using “anonymous” as the user name. Many times FTP grants the user “anonymous” read access to files in the FTP directory. Sometimes anonymous FTP has been incorrectly configured to allow write access. With write access, you can copy over a Trojan horse program or a root kit containing Netcat and other tools. You can then attempt to create a batch script that uses Netcat to open a command prompt on a particular port. These are just two techniques you can use to gain access to the system with FTP write access. Once you have write access, there are a number of techniques you can use to gain command line access to the system.

If you cannot gain write access with anonymous FTP, you can try educated guessing against an account. If educated guessing does not work, try brute force password guessing to gain access. Be careful using brute force guessing during penetration testing since it can lock out accounts. Normally, we use brute force techniques only as a last resort since they increase the chance of detection and can inconvenience the client due to lockouts.

In addition, the version of the FTP software may be vulnerable to exploit. If you are able to identify a vulnerability for the specific version of FTP during your research, attempt to exploit it. For instance, WFTP is vulnerable to buffer overflows that enable the attacker to execute commands on the system or view files and directories. Wu-ftpd is open to a format string vulnerability that could allow an attacker to gain root access on the system. These are just a few examples; there are many vulnerabilities that affect different versions of FTP on many platforms.

Next, attempt to login to telnet using educated guessing for the user ID and password. If educated guessing is not successful, you could use brute force techniques. However, as mentioned, avoid using brute force until you have exhausted all other options. If you are able to successfully login to telnet, you will have command line access and be able to start attempting to escalate your privileges.

SMTP is often another vulnerable service. During the banner-grabbing phase, you would have obtained the name and version of the SMTP software running on port 25. During your vulnerability search you should determine whether the specific version of the software is vulnerable to any published exploits. For example, older versions of sendmail are susceptible to many vulnerabilities, many of which yield root or administrator access. Also, you can attempt to gather information using SMTP commands. You can also use SMTP commands to attempt to relay mail through the server, forge e-mail, or mail commands to programs. In Chapter 9 we demonstrate actual commands that can be used for these purposes.

Finger (port 79) can be used to gather system and user information. Most organizations have discontinued using Finger, but if you find Finger open, it can yield useful information about the users on the system. You can attempt to connect to it manually or use one of the tools covered in Chapter 12. Finger gathers information about the users on the system. You can use this information to help build your attack.

Another step during the discovery phase includes attempting to extract SNMP information from the network. SNMP is used to manage network devices. SNMP-enabled devices, if not configured correctly, can reveal a plethora of information about the network. SNMP information includes routing tables, protocols, error logs, and other system and network data. This information can be used to help build your attack. SNMP devices should be configured to use private community names that act much like passwords to control access to the service. The problem is that many organizations leave these community strings set to the default of “public” or “private.” If an attacker guesses this community name, he or she will have access to all the SNMP information and may have write ability if SNMP has been configured with write access. Several tools can be used to obtain the SNMP information. NetScanTools and WS_Ping ProPack are two of these tools. SNMP exploitation is described in greater detail in Chapter 12. To guard against SNMP exploitation, be sure to select hard-to-guess community strings and use access lists on routers and network devices to limit the range of addresses that can obtain SNMP information.

Even if you identified NT systems during the discovery phase, you should use NET commands and NT tools to identify the additional NT domains and systems. There are a number of tools native to Windows NT and within the NT resource kit that can be used to test Windows NT systems. Chapter 16 provides detail on each individual tool. Here we discuss the general methodology we use for testing Windows NT resources. First, we attempt to discover Windows NT domains, domain controllers, servers, and other NT resources. We then enumerate system and user information to be used during the test. We use this information to exploit accounts and gain access to NT resources.

Net view and net view/domain can be used to identify accessible domains and systems within those domains. If you are able to identify NT domains, you will want to locate the domain controllers for each domain. During testing, we commonly target the domain controllers because they contain the NT password file (SAM) for the entire domain. If the domain controller is vulnerable, almost every domain resource is vulnerable as well since domain administrator accounts have domain-wide access. Nltest can be used to identify the domain controllers for each domain. Additionally, Nltest can be used to identify trusted domains. Domain administrator accounts from the exploited domain may be able to access domain resources in the trusted domain. Even if a trust relationship does not exist between the domains, an account from the exploited domain may also be a valid account in another domain. Using this duplicate account, you can begin to test the new domain. Information on how to use these tools can be found in Chapter 16.

Once the critical NT servers have been identified, we can attempt to enumerate as much of the NT server information as possible. If the NT server has not been properly patched or secured, it can yield a great deal of information about the domain that will aid in building an attack. The information gathering can be done manually or with tools. The NT resource kit and DumpSec are two excellent tools for enumerating NT information. Most of these tools require a null connection to the NT system. A null connection is a connection made to the IPC$ share with no user name and password. If the RestrictAnonymous registry key has not been set on the system, you can enumerate user, group, and share information. A null connection enables you to collect information on:

Once you have obtained the information from DumpSec and the other NET commands, you can try to obtain administrator-level access on the system. Administrator access enables you to capture the system's password file (SAM file), perform additional exploits, and use the system as a launching point for additional testing. You can attempt to guess the administrator password through educated guessing. Be careful with this technique since you can lock out the account if passprop.exe is installed to allow for administrator lockout. Normally we attempt password guessing on one account and then use DumpSec to gather the account information to see whether the account has been locked out. If it has not, we continue password guessing. If we are still unsuccessful in guessing, we again check the account status using DumpSec. If the account is still not locked out, account lockout is probably not enabled. Now the door is open for brute force guessing. Tools such as NetBIOS Auditing Tool (NAT) can be used to brute force the accounts. (For information on NAT see Chapter 16.) Any dictionary file will work with the tool. Usually we add customized words to the beginning of the dictionary file such as local sports teams, attractions, movie stars, and so on. Often, at least one administrator account unintentionally has a weak password and once it falls, they all fall.

Once administrator access has been gained on the system, we can then extract the password file. L0phtCrack easily extracts the password file and can then be used to crack the passwords. (For more detail on using L0phtCrack see Chapter 15.)

Also, using the administrator account you should go through the file system looking for tools and hints that may help you gain access to additional systems. You may find notes the administrator left to him- or herself, applications that have hardcoded passwords, or trust relationships between the exploited system and other targets. Take time reviewing the information you find on the system and record anything that you may be able to use later. In addition, you may find sensitive information that the company would not want compromised.

Finally, you can now use the exploited system as a launching point for testing against additional systems. By loading your tool kit onto the exploited system and obtaining command line access, you can use your tools from this new platform against other systems on the network. You may be able to find new domains or systems from this new vantage point. Remote and Netcat are two tools you can use to obtain command line access to the exploited system. (Information on Remote and Netcat can be found in Chapter 16.) Additionally, you could use GUI remote control tools to control the exploited system. (See Chapter 18.)

There are several measures that should be taken to defend against NT attacks. First, setting the RestrictAnonymous key limits the information an attacker can glean from a null connection. Account lockouts should be enabled on all accounts. Auditing should be enabled on all systems, and the logs should be reviewed regularly for unauthorized activity. The passflt.dll should be used to enforce strong password controls. Syskey encryption should be used to encrypt the password hashes, making password cracking much more difficult. Information on configuring the passflt.dll and Syskey can be found in Windows NT service pack three and higher. The passprop.exe utility should be used to enforce account lockout on the administrator account. Passprop will lock out the administrator account remotely, but the account will still be accessible from the console. Finally, security patches and service packs should be applied shortly after being published and tested in the company's environment.

In this section we provide a quick overview of some of the services and applications to look for when trying to test UNIX systems. Chapter 9 provides additional depth and information that is useful in UNIX penetration testing. Testing UNIX systems is similar to NT but uses different services and techniques. Again we look for services that can be exploited. Remote services, NFS, telnet, FTP, and other services provide opportunities for exploitation. There are many different types of UNIX systems, including Solaris, SunOS, Linux, AIX, and HP-UX. If you can determine the type or “flavor” of UNIX you have discovered, you can use this information to search for vulnerabilities specific to the flavor and version.

There are certain clues that help you determine whether a host is running a UNIX operating system (rservices, X-Windows, and so on). UNIX systems need to have open ports to communicate and share files. Some specific UNIX ports to look for can be found in Chapters 9 and 13. Also, Nmap can be run with the operating system identification option to help determine the type and version of the UNIX operating system running on the host.

Once you know the target system is running UNIX, you can start to plan your test. First, search for specific vulnerabilities that apply to the type and version of UNIX you have identified and any services that may be running on the host. You can then check to see whether the host is susceptible to these exploits through testing.

Services such as FTP, SSH, telnet, SMTP, TFTP, POP, rservices, and NFS can be exploited if they are not properly configured or if weak passwords are used. If you find these services open (ports 21, 22, 23, 25, 69, 110, 512–515, and 2049, respectively) you should attempt to connect to them using password guessing or brute force.

Another potential way to gain access to a UNIX host as well as other systems is through buffer overflows. Buffer overflow attacks involve sending data to a program that exceeds the size of its buffer, causing the stack space to overflow. When this happens the attacker can attempt to overwrite the program's stack space to trick it into executing the hacker's own commands. In this way, buffer overflow attacks can enable the attacker to execute commands on the target as root or gain root access to the system. A number of buffer overflow attacks have been developed over the years for services such as sendmail, DNS BIND, Rstatd, RPC services, and IMAP. A search of vulnerability databases for these services should yield buffer overflows that will be successful on unpatched systems.

Web-server applications such as Apache, Netscape, and others have vulnerabilities associated with them that can enable root access. While patches have been released to protect these applications from the vulnerabilities, many system administrators fail to patch their systems in a timely manner. If you find Web services installed, check the specific version of the software against a vulnerability database to determine whether the software is vulnerable to attack.

Once you have gained access to a UNIX system, you should obtain and crack the password file. If shadow passwords are used, you will need root access to capture the shadow password file and crack it. Once you have obtained the password file you should use a password cracker such as John the Ripper to crack the file. Although you may have root access on the system, it is still useful to crack the remaining passwords on the system. Often you will find accounts reused on other servers. The more passwords you crack, the more user IDs and passwords you can try on other systems.

After you have obtained and cracked the password file, you can attempt to use the compromised host as a launching point for additional exploits and hopefully bypass filtering rules implemented on routers and other devices. To perform this exploitation, create a hacker tool kit and hide it on the target system. You can use this kit to launch the new exploits. (We cover the hacker tool kit in more detail below.) In addition, by using Netcat or datapipe you can route your tests through the compromised hosts, bypassing filtering rules and/or leveraging existing trust relationships. Additionally, since you have access to the file system, you should go through the files and settings looking for information that could be helpful to exploit other hosts.

To defend against these attacks, make sure all unnecessary services are closed. Use password crackers to proactively verify password strength. Review file permissions and close all unnecessary access. Finally, monitor for new vulnerabilities and patch your system constantly.

Chapter 9 provides more information on UNIX-specific testing procedures.

During your testing you will gather information that will enable you to start identifying applications and software versions that are running on the targets. For instance, you may be able to gain hints from the host name, ports that are specific to applications, or other clues. Build a list of these applications and software versions and add them to your table. These applications often have programming weaknesses associated with them that could be exploited if they're not patched. Commercial vulnerability scanners will identify some of these issues, but vulnerability databases are another way to find them. As part of your testing, log onto these database services (a list of these sites can be found in Chapter 22) and search for the operating systems, applications, and software versions you have identified in your table. If you find exploits you have not tried, either make sure the system is patched against them or test the system to see if it is vulnerable. One word of warning: Be careful running unfamiliar exploits that you download from the Internet! Think about where and from whom you are getting this code. Hackers at times include back doors or other nasty surprises in exploit code, hoping someone will be foolish enough to run it without properly testing it first. Therefore, always know what you are running, and test it in a lab environment before running it against production systems.

Sniffing is another technique to use internally. A sniffer or packet capture utility is able to capture any traffic traveling along the network segment to which it is connected. While performing all of the other techniques described in this chapter, we normally set up sniffers throughout the organization to capture network traffic, hoping to identify valuable information such as user IDs and passwords. We use sniffing to passively capture data being sent across the internal network. Laptops are usually the ideal platform since they are portable and easy to conceal. The system does not even need an IP address since it passively captures the traffic. The sniffing machine copies the data without modifying its contents and is difficult to detect even with sophisticated intrusion detection software. There are programs, such as AntiSniff, that have some success in detecting sniffers. (Detailed information on AntiSniff and sniffers can be found in Chapter 14.)

Switched Ethernet environments reduce the risk of packet capture. Since the sniffer is able to capture traffic only on its same network segment, a sniffer in a switched environment can see only traffic destined for it. However, in a shared environment or mixed environment, sniffers can be very useful for capturing valuable traffic. In addition, dsniff, written by Dug Song, is able to sniff across switches. The techniques dsniff uses to sniff on switched segments can cause denial-of-service conditions and therefore should be used cautiously during penetration testing.

Any network traffic that is transmitted in clear text is susceptible to sniffing. Telnet, FTP, and other clear-text sessions provide valuable information. The sniffer can capture a complete telnet and FTP session, including the user name and password. In addition, sniffed e-mail and HTTP traffic may yield actual passwords or clues that enable passwords to be guessed. Sniffed e-mail may also yield confidential material, legal matters, or other information that should normally be encrypted.

If the thought that this information can be captured from your network concerns you, L0phtCrack's SMB Capture sniffer will surely concern you. The NT password sniffer, SMB Capture, within L0phtCrack can sniff NT passwords directly from the network. If the passwords are weak (for example, dictionary word, short, one number at the end), L0phtCrack will be able to crack the passwords within minutes. If the passwords are strong (mixture of uppercase and lowercase letters, special characters) it could take months for them to be cracked. The fact that most NT networks use LANMAN passwords makes matters even worse. LANMAN passwords are required to be sent when non-NT clients (Windows 9x) need to authenticate to NT servers. The LANMAN passwords are not case sensitive and are therefore easier to crack. At the start of the internal testing scenario, start SMB Capture to begin capturing and cracking the NT passwords.

Normally we set up a sniffer in the test room where we are located during the testing. In addition, we try to find another network segment with critical data or high-volume network traffic on which to place a sniffer. Often, network segments that are connected to the data center, system administrators' work areas, legal departments, human relations departments, or senior management make excellent targets for sniffers. The key is to find a location in which to place the sniffer where it will not be noticed. If network closets can be accessed, you could plug the sniffer directly into a switch or hub port and attempt to conceal the sniffer somehow. Since most network closets are locked, we usually end up hiding the sniffer in an empty office, cubicle, or conference room. On occasion, we have hidden sniffers under podiums in conference rooms. Often there are so many wires coming out of the podium, no one notices one extra.

Once the sniffer is set up in the remote location, you need to find a way to retrieve the data from it. You can either go back and pick up the sniffer later and read the data, use a script to FTP it at regular intervals, or use a remote control program to go back and retrieve the data and configure the system as needed. The use of remote control programs on these hidden sniffers is quite effective. These programs allow you to periodically check the data you're receiving from the sniffer and make changes to the configuration as you learn more about the network. For instance, if you see login sessions that use the syntax “passwd,” you can filter the sniffed traffic using ngrep or another filtering command to capture this traffic in a file. The more filters you can place on the sniffer, the easier it will be to analyze the data. However, be careful not to make your filters too restrictive or you may miss critical data.

Internal testing is much like a series of linked vulnerabilities. Once you gain administrator access on one system, additional systems start to fall. Fortunately for the tester and unfortunately for the organization, administrator passwords on many systems tend to be the same within the organization. Additionally, there is usually at least one account from each compromised system that will work on another system. So as you begin to crack systems, build a list of information that may be useful in attacking other systems: account names, passwords, files that may offer password hints, vulnerable services, and so on. In addition, look for trust relationships between systems. Often a system we previously scanned from a laptop that showed no ports open will suddenly have many ports open when scanned from a compromised system. This is due to the fact that the system may have trust relationships or may use filtering to allow only certain hosts to connect to these services. Therefore, be sure to load your hacker kit onto the compromised host and begin the discovery phase on the remaining systems.

A hacker tool kit is essentially a set of tools placed on a compromised system to help escalate privileges or to attack other systems. The hacker tool kit usually consists of a port scanner (Nmap), Netcat (for creating listeners and back doors), and any other tools you used during your discovery and exploitation phase. Create a directory on the host system disguised by a name that will not alert a general user or system administrator. The file could also be hidden or streamed to further avoid detection. Just remember that when the test is over you will need to remove the tool kit, so remember where it is located.

Now that you have administrator access on the compromised host, you can run the tools from the host remotely or just use it as a stepping stone using port redirection. Port redirection involves taking network traffic coming into a host on one port and directing out from the host on another. For example, if we were able to compromise an NT Web server inside of a packet-filtering firewall, we would use a port redirection tool such as Fpipe to accept connections on a specified port and resend them to a specified port on a specified machine. On the compromised Web server we could set up a Netcat listener on port 80. On the compromised system we would execute:

C:>nc –l 80 –e cmd.exe

On the testing system outside the firewall, we could use Fpipe to make the connection to the Web server using a different source port that is not filtered by the firewall. The following command would establish a listener on port 25 on the test machine and then redirect the connection to port 80 on the target system using the source port of 25.

C:>fpipe –l 25 –s 25 –r 80 webipaddress

By using telnet to connect to the test system on port 25 we obtain a command prompt on the Web server inside the firewall. The traffic travels to port 80 from port 25 and thereby is able to bypass the filtering on the firewall. Using port redirection such as this, you can bypass filtering rules on packet-filtering firewalls or routers. Also, by remotely using a compromised host as a testing platform you may be able to take advantage of trust relationships.

It is also a good idea to run vulnerability scanners, commercial or freeware, internally to try to identify holes you may have missed. While the high-end commercial scanners are very good at detecting particular vulnerabilities, they are not able to link vulnerabilities. For instance, if one vulnerability can lead to the exploitation of another hole, the scanner will not be able to detect this. In addition, the scanners are not normally able to exploit trust relationships or bypass filtering rules. You need to complement the abilities of the commercial scanners with your testing skills and logic. Whichever vulnerability scanner you use, make sure it is updated. Without the updates for the latest vulnerabilities you will miss all vulnerabilities that were discovered since the last update. In addition to using an updated scanner, keeping current on all system patches will help defend against these exploits.

Once on an internal penetration engagement, our team was given a conference room with a live network jack. The goal of the engagement was to assess the security of the client's back-end database servers from unauthorized access by company employees. We did not know much about the layout of the network, except that the target servers were behind a firewall and on a separate segment. We did know that the segment onto which we were allowed was populated by employee machines.

The company was running DHCP, so when we plugged in, we received a valid network address. The first thing to do was to discover the network. We ran the net view command (as shown below) to obtain a list of domains and user workstations within each identified domain that we could see from our current location.

C:>net view /domain

And based on the results, we ran:

C:>net view /domain: domain_name

Next, we tried a null connection to each machine.

C:>net use \machine_nameipc$ "" /user:""

Once we had a connection, we attempted to determine whether there were any shares on these machines with the following command:

C:>net view \machine_name

Some shares on a few machines were identified. We then attempted to connect to those shares with the net use command and by trying some default user names and passwords. We successfully connected to several shares with the user name/password pair, administrator/<blank password>.

C:>net use \machine_namec$ ""/user:administrator

Unfortunately for the company the local administrator account had a blank password.

Once connected, we were able to copy over, install, and run the remote control program VNC, allowing us to control that machine from our laptop.

One note: We had cracked the local administrator account on a desktop machine. This is not the same as the domain administrator account that has admin access to all machines. This local administrator had admin access only to this machine and its SAM file; it did not offer user IDs and passwords that could be used on other hosts.

At this point, we were ready to go forward and attempt to access the back-end servers with the information we had gathered thus far. Before doing so, however, we took a moment to look around this machine's file system and found a local copy of a Microsoft Access database. Since databases often contain interesting information, we copied this back to our laptop to examine. Once we did, we found that it contained sensitive client information. This was at least a partial copy of a database stored behind that second firewall layer.

While there were additional vulnerabilities that allowed us to get at this information (for example, allowed null connections, blank admin password), the Achilles' heel here is that an employee had kept a local copy of a sensitive database.