If you would like to read the other parts in this article series please go to:
- Analyzing a Hack from A to Z (Part 1)
- Analyzing a Hack from A to Z (Part 2)
- Analyzing a Hack from A to Z (Part 4)
In part two of this article series we left off having gathered all of the necessary information required for an attack on our victim network. On that note let’s carry on with the actual hack itself. This will be followed by the transferring over of some programs required in order to further the post-exploitation strategies of the hacker. It would be rather pointless to simply hack a computer and then withdraw. Normally the goal of any malicious hacker is to not only gain a presence on a computer network, but also to maintain it. That normally means trying to hide their ongoing presence.
Time for the fun stuff
Now I will be using the Metasploit Framework in order to facilitate the actual hack itself. This framework is really a thing of beauty in that it offers you a large variety of exploits, and just as importantly many different options for your choice of payload. You may not always want to have a reverse shell, or inject VNC. The payload will often depend on the target at hand, the network architecture, and your ultimate goal. In our case, we will go with the reverse shell. This is always beneficial, and especially so in case your target is behind a router and not directly accessible. For example you hit a webserver, but it is one of several which are load balanced. No guarantee that you will be able to connect to it with a forward shell, hence you’re wanting the computer to shovel a shell back to you. Lastly, I will not cover the actual usage of the Metasploit Framework for this is something that I have covered several times in other articles. We shall concentrate on what things look like at the packet level.
Now instead of taking the approach of covering each step of the hack with screenshots and code snippets we will take a different tack. What we shall do is recreate the hack with the help of Snort. We shall take the binary log of the hack I did, and then parse it through Snort to see what it saw. Ideally, it will have seen everything I did. In reality what we are going to do is packet forensics. The goal will be to see how accurately we can come to reassembling exactly what has happened. On that note, I shall take the binary packet log which recorded everything I did and parse it through Snort with its default ruleset in place.
Snort output
The syntax used to invoke snort is as follows:
C:\snort\bin\snort.exe -r c:\article_binary -dv -c snort.conf -A full
This in turn caused Snort to parse the binary packet called article_binary which resulted in the below output. I have truncated the output of Snort to the germane parts for brevity.
==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0
The part that is of interest to us is the fact that 63 alerts were triggered by the hacking activity. We will now take a look at the alert.ids file which will give us more detailed information as to what happened. Now if you remember the first thing the hacker did was use Nmap to scan the network. That also happens to be the first alert triggered by Snort.
[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]
Following this the hacker used netcat to enumerate the webserver in an effort to find out what type it was. This enumeration attempt did not trigger any Snort alerts. I would be curious to know why, so let’s take a look at the packet log. Well after seeing the normal TCP/IP three way handshake, the following packet was seen.
15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%t@…u…o.
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P…..[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P…[…GET.slsl
0x0030: 736c 0a sl.
There is nothing remarkable in this packet beyond the fact that there is a GET request with some garbage after it as evidenced by the slslsl. So in reality there was nothing for Snort to trigger on. It would be rather difficult to build an effective IDS signature to trigger on this type of enumeration attempt. That is likely why there are no such signatures. The next packet after this is where the victim networks webserver enumerates itself.
After the enumeration was done the hacker immediately sent exploit code to the webserver. This exploit code then resulted in quite a few Snort signatures being triggered. Specifically for the exploit shown below I saw this Snort signature.
[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]
Following this series of alerts Snort next fired off on a series of TFTP alerts. Once the hacker gained access to the webserver he then began to use the built-in TFTP client to transfer over four files: nc.exe ipeye.exe fu.exe msdirectx.exe After these files had been transferred over the hacker used netcat to send a shell back to his computer. From there he disconnected his other shell which resulted from the initial attack and did all remaining work in the netcat shell. Interestingly enough, none of the follow activity performed by the hacker via the reverse shell was logged by Snort. This in spite of the fact that the hacker used the rootkit he had transferred over via TFTP to hide the process information for netcat. Not good at all, one would ideally have wanted the usage of the fu.exe rootkit to have fired an IDS signature.
Wrap up
In part three of this series we saw the hack that was pulled off by the hacker as it was seen by Snort. We were able to recreate pretty much everything that was done with the exception of the usage of the rootkit. While an IDS is quite a useful piece of technology, and should be a part of your networks defenses, it isn’t perfect. It will only alert you to traffic that it has signatures for. With this in mind we shall learn how to build Snort signatures in the last part of this article series. Furthermore, we shall also see how to test these signatures to verify their effectiveness. See you then.
If you would like to read the other parts in this article series please go to:
