Analyzing an Attack (Part 3)

Analyzing an attack (Part 1)
Analyzing an attack (Part 2)

Don Parker

In part 2 of this series, we have left out all the necessary information required for an attack on the victim network. With that in mind, let's move on to the actual attack. This attack entails traversal across several request programs to be able to go further in exploiting an attack.

It really makes no sense to simply attack a computer and then retreat, which is why we're going to do a strong attack. Usually the goal of a malicious code attacker is not only to increase their presence on the computer network but also to maintain it. That means the attacker wants to continue hiding his presence and perform some other actions.

Interesting problems

We will now use the Metasploit Framework to facilitate a real attack. This working mechanism is really interesting because it offers you many different types of exploits as well as many different options in the matter of choosing the payload. You probably don't want a reverse utility, or inject VNC. Payload often depends on your upcoming goals, network architecture, and end goal. In this case, we'll make do with a reverse widget. This is often an advantageous method, especially in cases where our target is located behind the router and is not directly accessible. For example, you “hit” a webserver but the load is still balanced. It is not guaranteed to be possible to connect to it with a forward utility, so you will want the computer to create a reverse utility. We will not mention how to use the Metasploit Framework because it may have been introduced in another article. So let's just focus on things like package levels, for example.

Now, instead of introducing each attack step with brief images and code excerpts, we will present a different attack. What will be done is to recreate the attack with the help of Snort. We will take advantage of the binary record in the attack we performed, then parse it through Snort. Ideally it would look like everything we've done. In effect, what will do is a demonstration package. The goal here is to see how exactly what happened can be pieced together. With that in mind, we'll use the binary package's log that logged everything it did and parsed it through Snort through some of its default rules.

Snort output

The syntax used to call 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 the binary packet called article_binary, the output of which is shown below. We've truncated Snort's output so we can look at 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 section is interesting because 63 alerts were triggered by an attack action. We will look at the alert.ids file, which can provide a lot of detailed information about what happened. Now, if you remember the first thing the attacker did was use Nmap to perform a network scan, that issue also generated 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 method, the attacker used netcat to enumerate the webserver to find out what type of webserver it is. 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 log for the package. After observing the usual TCP/IP handshake procedures, we see the packet below.

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..CP....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

Không có gì đáng chú ý trong gói này ngoài sự việc là nó có request GET với một số vấn đề bên trong theo sau như slslsl chẳng hạn. Vì vậy trong thực tế, không có bất cứ gì cho Snort hành động. Chính vì vậy sẽ rất khó khăn trong việc xây dựng một chữ ký (hay có thể gọi là dấu hiệu) IDS hiệu quả nhằm kích hoạt kiểu cố gắng liệt kê này. Chính điều đó là lý do tại sao không có các chữ ký như vậy. Gói tiếp theo sau chính là nơi mà webserver của mạng nạn nhân tự liệt kê nó.

Sau khi việc liệt kê được thực hiện, kẻ tấn công ngay lập tức gửi một mã nhằm thực hiện hành vi khai thác đến webserver. Mã này sau đó sẽ cho một số kết quả có các chữ ký Snort đã được kích hoạt. Đặc biệt cho sự khai thác được thể hiện bên dưới mà chúng ta có thể thấy được chữ ký Snort này.

[**] [1:1248:13]  WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]09/08-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 4 files: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. After these files have been transmitted, the attacker uses netcat to send a utility back to his computer. From there, he can destroy the connection and other utility that resulted from the initial attack and do all the remaining work in the netcat utility. Very intriguingly, none of the actions performed by the attacker via the reverse utility were logged by Snort. However, regardless of that problem, the attacker used the rootkit that he transmitted via TFTP to hide process information for netcat.

Conclude

In part three of this series, we saw the attack demonstrated using Snort. We can completely recreate one of the things that have been done except for the rootkit's usage. Even if an IDS is a pretty useful piece of technology and part of your cyber defense system, it's not always perfect. IDSs can only alert you to traffic that they can sense. With that in mind, we will learn how to build Snort signals in the final part of this series. Along with that, we will learn how to test a digital signature (sign) to evaluate its effectiveness.