Analyzing a Hack from A to Z (Part 1)

If you would like to read the following parts in this article series please go to:

• Analyzing a Hack from A to Z (Part 2)
• Analyzing a Hack from A to Z (Part 3)
• Analyzing a Hack from A to Z (Part 4)

This article series will be based upon a network system breach. What we shall cover is the actual hack itself, from the reconnaissance stage, through to enumeration, network service exploitation, and ending with post-exploitation strategies. All of these steps will then be viewed at the packet level, and then explained. Being able to view, and understand an attack at the packet level is critically important for both system administrators (sys admin) and network security personnel. The output of firewalls, Intrusion Detection Systems (IDS) and other security devices will always in turn lead you to look at the actual network traffic. If you don’t understand what you are looking at, at the packet level, then all of the network security technology you have is utterly useless. This will then be followed by how to write a Snort signature based off of the attack traffic.

Tools used for this simulated network attack:

• Nmap
• IPEye
• Tcpdump
• Metasploit Framework
• Netcat
• SolarWinds TFTP Server
• Tftp client
• FU Rootkit

Setting the stage

There is no shortage of hostile scanning on the Internet today, not to mention worm activity, and other forms of malware, such as viruses. All of this amounts to a lot of white noise for the well protected computer network. What we shall look at is a person deliberately targeting a computer network. For the purposes of this article we shall assume that the hacker has already decided upon his victim and done earlier research such as finding out the IP address or addresses of the victim network. He may have also tried to find out other such nuggets of information, such as email addresses associated with that network. This type of information is critical in case the hacker were to find there was no way into the network after having scanned, profiled, and enumerated it. The email addresses that he may have harvested would be useful in setting up a client side attack by which he would try and lure a user to a malicious website via a link in an email. More on that type of attack in a later article series.

On with the show

We shall now view the actions of the potential hacker as he goes about the business of scanning, profiling, and enumerating the victim network. The first tool that the hacker uses is Nmap. Though Nmap has quite a few IDS signatures for it, it is still quite a useful tool, and is heavily used.

Figure 1

We can see via the syntax used by the hacker in the screenshot that he deliberately picks port 21 and 80, as he has several exploits he can use via the the Metasploit Framework. Not only that but those are two system services and protocols that he understands fairly well. Shown as well is that he is using a SYN scan which is also the most common port scan type. This is due to the fact if a service which uses TCP is listening on a port which is scanned with a SYN packet, then it will send back a SYN/ACK packet. That SYN/ACK packet indicates that a service is indeed listening there, and awaiting connections. The same cannot be said for UDP based services such as DNS (DNS also uses TCP though it mostly uses UDP for the bulk of its transactions).

Listed below the syntax is the output that Nmap gleans from the packets it sent, but to be more accurate, from the packets it receives as a result of the SYN scan it just did. We can see that there are seemingly both FTP and HTTP services offered. We are not really interested in the MAC address so we will ignore that. Though tools such as Nmap are not often wrong it is always good to verify your information at the packet level to ensure its accuracy. Not only that, but it is also in looking at the return packets, from the victim network, that we shall gather the host, service, and architectural information from.

Let us consult the packets

There are several programs out there today which will take packets off the wire and pull out information such as the operating system type, architectural info ie: x86 or SPARC and so on, for you. That really isn’t all that much fun, nor more importantly are we learning anything by letting a program do the work for us. On that note let’s take a look at the Nmap packet trace, and pull out some information about the victim network.

10:52:59.062500 IP (tos 0x0, ttl  43, id 8853, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.17 > 192.168.111.23: ICMP echo request seq 38214, length 8
0x0000:  4500 001c 2295 0000 2b01 0dd3 c0a8 6f11  E…”…+…..o.
0x0010:  c0a8 6f17 0800 315a 315f 9546            ..o…1Z1_.F
10:52:59.078125 IP (tos 0x0, ttl 128, id 396, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.23 > 192.168.111.17: ICMP echo reply seq 38214, length 8
0x0000:  4500 001c 018c 0000 8001 d9db c0a8 6f17  E………….o.
0x0010:  c0a8 6f11 0000 395a 315f 9546 0000 0000  ..o…9Z1_.F….
0x0020:  0000 0000 0000 0000 0000 0000 0000       …………..

Shown in the two packets above is the opening salvo from Nmap. What it does is send an ICMP echo request to the victim network. You will note that it is not aimed at a specific port, seeing as ICMP does not use ports, but rather is handled by the ICMP error message handler which is built into the TCP/IP protocol stack. This ICMP packet is also stamped with a unique number, 38214 in this case, in order to help the TCP/IP stack keep track of the returning traffic, and associate it with an earlier ICMP packet it sent. The packet directly above us is the response from the victim network, in the form of an ICMP echo reply. Also note it bears the sequence number of 38214. So the hacker knows that there is indeed a computer, or computer network behind that IP address.

This opening ICMP packet sequence is why Nmap has an IDS signature for it. This ICMP host discovery option can be disabled in Nmap if so desired. What kind of information can be gleaned via the resulting ICMP echo reply packet from the victim network? In reality not a ton of information is there to help us profile the network. Though we can take a preliminary stab at what the operating system family is. The time to live field and value next to it is highlighted in the packet above. A value of 128 points to the likelihood that this computer is probably a Microsoft Windows one. While this ttl value is not a definitive answer as to what the operating system is, it will hopefully be corroborated by the ensuing packets that we will look at.

Wrap up

So far in this part we have seen a malicious hacker scan a network for two specific ports using Nmap. He so far has ascertained that a computer or computer network resides at that IP address. In part two we shall go on to finish the study of our packet trace, and pull out the remaining pieces of profiling information. See you then.