Analyzing an Attack (Part 3)

Analyzing an Attack (Part 1)
Analyzing an Attack (Part 2)

Don Parker

In part 2 of this series, we left all the necessary information required for an attack on the victim network. With that in mind, let's move on to an actual attack. This attack entails passing on some of the required programs to be able to go deeper into exploiting an attack.

It would be pointless to simply attack a computer and then retreat, so we’ll do a strong attack. Usually the goal of a malicious attacker is not just to increase their presence on a computer network, but to maintain it. That means they want to continue to hide their presence and perform some other actions. Interesting

stuff

Now we’ll use the Metasploit Framework to facilitate the actual attack. This is really interesting because it gives you many different types of exploits and many different options when it comes to choosing a payload. Maybe you don’t want a reverse utility, or a VNC inject. The payload usually depends on your upcoming target, your network architecture, and your final goal. In this case, we’ll go with a reverse utility. This is often the best approach, especially if our target is behind a router and not directly accessible. For example, you hit a webserver but it is load balanced. There is no guarantee that you will be able to connect to it with a forward utility, so you will want to have your computer generate a reverse utility. We will not cover how to use the Metasploit Framework as that may be covered in another article. So let’s just focus on things like the packet level.

This time, instead of going through the process of showing each step of the attack with quick screenshots and snippets, we will show a different attack. What we will do is recreate the attack with the help of Snort. We will take the binary log of the attack we performed and parse it through Snort. Ideally it will see everything as we did. In fact, what we will be executing is a demonstration packet. The goal here is to see how we can piece together exactly what happened. With that in mind, we will take the binary packet log that captured everything that happened and parse it through Snort using some of its default rules.

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 syntax causes Snort to parse a binary packet called article_binary, the output of which is shown below. We have truncated the Snort output so that we can examine each part in detail.

==============================================================
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

This part is interesting because there are 63 alerts that were triggered by an attack. We will look at the alert.ids file, which can give us a lot of details about what happened. Now, if you remember the first thing the attacker did was use Nmap to scan the network, that also created the first alert that was 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]

In this way, the attacker used netcat to list the webserver to find out what type of webserver it was. This action did not trigger any Snort alerts. We also want to find out what happened, so let's take a closer look at the packet log. After observing the usual TCP/IP handshake, we see the following packet.

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 about this packet other than the fact that it has a GET request followed by something like slslsl . So in reality, there is nothing for Snort to do. It would be very difficult to construct an effective IDS signature to trigger this type of enumeration attempt. That is why there are no such signatures. The next packet is where the victim network’s webserver enumerates itself.

After the enumeration is done, the attacker immediately sends a code to execute the exploit to the webserver. This code will then return some output with the Snort signatures enabled. Specifically for the exploit shown below we can see 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]

Once the attacker has gained access to the webserver, he will start using the TFTP client to transfer four files: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. After these files have been transferred, the attacker uses netcat to send a reverse utility back to his computer. From there, he can disconnect and another utility, the utility that resulted from the initial attack, and perform all the remaining work in the netcat utility. Interestingly, none of the actions performed by the attacker via the reverse utility were logged by Snort. However, regardless of that, the attacker used the rootkit that he transferred via TFTP to hide the process information for netcat.

Conclusion

In part three of this series, we saw the attack demonstrated using Snort. We can completely recreate one of the things that was done except for the use of the rootkit. While an IDS is a pretty useful piece of technology and part of your network defenses, it’s not always perfect. IDSs can only alert you to traffic that they can sense. With that in mind, we’ll look at building Snort signatures in the final part of this series. Along the way, we’ll also look at testing a signature to verify its effectiveness.