This case study provides an overview of the operations carried out by our penetration testing red berets for one of our customers.

Our client, a Fortune 500 financial services company, needed to conduct a rigorous penetration test of its network before launching a slew of new services.

Our penetration team members have these advantages:

The initial steps in penetration testing involve numerous scans and a careful study of the network. This reveals important information about the network and allows the team to obtain relevant details of objects in the path, including router, firewall and switch.

The Internet provided an unlimited pool of resources that we used to narrow the range of activities and provide some insight as to the type and amount of information publicly available about the organization.

Network enumeration is a technique that identifies the domain names and associated networks related to a particular organization. We queried the 'whois' databases to assist us in finding a wealth of information about the network. There are many different tools to query various whois databases.

The following query types provided the majority of the information that was used:

Our information collection phase becomes easy if a system administrator configures the DNS server incorrectly, by allowing a distrusted Internet user to perform a DNS zone transfer. A zone transfer allows a second master server to update its zone database from the primary master server.

Many DNS servers, however, are mis-configured, and provide a copy of the zone to anyone who asks. This isn't necessarily bad if the information provided relates only to the systems that are connected to the Internet, and have valid hostnames, although it makes it that much easier for attackers to find potential targets. This DNS server of our target network did not have the zone transfers enabled.

We now attempted to determine their network topology, as well as potential access path into the network. To accomplish this, we used the 'traceroute' program that comes with most Unix systems and is provided in Windows NT.

Traceroute is a diagnostic tool that lets you view the routes that an IP packet follows from one host to the next. It uses the time-to-live (TTL) option in the IP packet to obtain an 'ICMP time exceeded' message from each router. Each router that handles the packet is required to decrement the TTL field. The TTL field is known as a hop count. When the TTL field decrements to zero, the packet is discarded.

The following is a sanitized representation of some of the critical information gleaned at this stage.

Here we see the output of traceroute to the system:
1 10.200.232.193 (10.200.232.193) 1.210 ms 0.988 ms 0.852 ms
2 10.200.232.18 (10.200.232.18) 5.525 ms 7.263 ms 5.686 ms
3 20.34.2.34 (20.34.2.34) 7.677 ms 7.174 ms 6.809 ms
4 20.34.115.152(20.34.115.152) 6.703 ms 30.130 ms 6.885 ms
5 vsb-lvsb-stm1.Bbone.vsnl.net.in (20.34.2.161) 7.553 ms 8.752 ms 7.484 ms
6 10.19.33.137 (10.197.33.137) 8.663 ms 8.210 ms 8.590 ms
7 * * *
8 * * *

After the sixth device, all imp and up has been blocked through it shows there is a router with strict filtering.

The following shows firewall output from a TCP traceroute to find the devices in the path:
hop=1 TTL 0 during transit from ip=10.20.23.193 get hostname…name=UNKNOWN
hop=1 hoprtt=1.1 ms
hop=2 TTL 0 during transit from ip=10.20.23.18 get hostname... name=UNKNOWN
hop=2 hoprtt=5.9 ms
hop=3 TTL 0 during transit from ip=20.34.2.34 get hostname...name=UNKNOWN
hop=3 hoprtt=7.2 ms
…
…
…
hop=7 TTL 0 during transit from ip=10.16.99.113 get hostname... name=UNKNOWN
hop=7 hoprtt=11.9 ms
hop=8 TTL 0 during transit from ip=10.168.101.54 get hostname... name=UNKNOWN
hop=8 hoprtt=14.1 ms
len=46 ip=10.168.10.54 ttl=56 DF id=60364 tos=0 iplen=44
sport=80 flags=SA seq=8 win=8576 rtt=12.5 ms
seq=1540990198 ack=1146067775 sum=f9a5 urp=0

From the above firewalking we found that there is another filtering device placed between the router 10.19.33.137 and the server 10.168.10.54. We knew by now that access to the inside network is limited. With numerous other detection methods, by end of day one, it was found that the intermediate device was indeed a firewall.

But later on, as the attacks progressed, we would come to know that even a security device like a firewall is unable to stop an attacker from gaining access to the internal network if the services running were not strong.

With accurate information about the network, the focus was now on getting access at the operating system level on the target machines. Port scanning is the act of systematically scanning a computer's ports. Since a port is a place where information goes into and out of a computer, port scanning identifies open doors to a computer.

With accurate information about the network, the focus was now on getting access at the operating system level on the target machines. Port scanning is the act of systematically scanning a computer's ports. Since a port is a place where information goes into and out of a computer, port scanning identifies open doors to a computer.

The following shows the output of a port scan on the two identified target systems, called here as system A and the mail server called here as B.

Port scan on A
(The 65,526 ports scanned but not shown below are in state: filtered.)
Port State Service
80/tcp open http
The telnet on to port 80 to this server revealed that it was running a version of Apache. The server running was Solaris 2.7.

Port scan on B
(The 65,526 ports scanned but not shown below are in state: filtered.)
Port State Service
25/tcp open smtp
79/tcp open finger
110/tcp open pop-3

A telnet on to port 25 sent back a default banner, which revealed that it was a vulnerable version of sendmail server running on Linux.

At this point we had a fair idea about the two machines on the network and the operating systems running on them. The findings about the operating systems were further confirmed by doing extensive manual tests on the packets received from the target system (using passive OS fingerprinting techniques).

Next came a complete vulnerability scan of the two systems, and a listing down of all the known vulnerabilities that were associated with the services running on the two systems. We found more than one vulnerability associated with the sendmail and also on the version of Apache running on the web server.

The team now brainstormed on strategies to exploit one or more of the vulnerabilities, and doing so without creating an alarm. It was critical at this stage to get full control of the system, but covertly. Often, if care is not taken at this stage, you run the risk of crashing the operating system and bringing the target administrator's attention to the covert operation.

After analyzing the above information, these were the attack approaches decided on by the penetration testing team.