1
IDIC - SANS GIAC LevelTwo
©2000, 2001
1
Network Mapping /
Information Gathering
• This is the reconnaissance section.
We will examine a number of
traces where the would-be attacker
is trying to gather information to
target a specific exploit.
– Host by host scanning
– Broadcast scanning
– Infrastructure scanning
Hello, and welcome to the Network Mapping and Information Gathering section of the course. The
purpose of this section is to show you many different methods that attackers will use in order to
perform reconnaissance on your network and systems.
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
Host Scanning
TCP Port 110 – POP3
20:35:25.068533 srn.org.4010 > 192.168.10.227.110: S
20:35:25.260798 srn.org.4086 > 192.168.14.101.110: S
20:35:25.279802 srn.org.4129 > 192.168.14.119.110: S
20:35:25.281073 srn.org.4141 > 192.168.14.126.110: S
20:35:25.287761 srn.org.4166 > 192.168.14.128.110: S
20:35:25.290293 srn.org.4209 > 192.168.14.136.110: S
20:35:25.295865 srn.org.4234 > 192.168.14.141.110: S
20:35:25.303651 srn.org.4277 > 192.168.14.146.110: S

20:35:25.317924 srn.org.4302 > 192.168.14.173.110: S
20:35:25.319275 srn.org.4378 > 192.168.14.171.110: S
This scan looks for a single service, but on many hosts.
Let us start off by talking about host-by-host scanning, where an attacker issues packets to a number
of hosts on the targeted network to probe for presence of potential victims.
Many of the traces we have looked at have been port scans. A port scan is when an attacker checks
for various services on one host. Another common tactic is the host scan; this is when an attacker
scans many hosts for one service.
Please note that the attacker whose scan is shown on this slide appears to have knowledge of the 14
subnet, and the attacker is scanning only active hosts. This would serve as an indicator that the
attacker has already done reconnaissance. In this case, the attacker is doing a host scan for TCP port
110, usually associated with POP3.
3
IDIC - SANS GIAC LevelTwo
©2000, 2001
3
Sequential Countup
Using ICMP Echo Requests
[Using ICMP Echo Requests]
01:00:38 pingmapper > 192.168.6.1: icmp: echo request
01:00:51 pingmapper > 192.168.6.2: icmp: echo request
01:01:04 pingmapper > 192.168.6.3: icmp: echo request
01:01:18 pingmapper > 192.168.6.4: icmp: echo request
01:01:31 pingmapper > 192.168.6.5: icmp: echo request
01:01:44 pingmapper > 192.168.6.6: icmp: echo request
01:01:57 pingmapper > 192.168.6.7: icmp: echo request
This may appear very trivial, but when a ping gets more
than one reply, attackers know they have found
a subnetwork.
We have already introduced the concept of network mapping. This example shows an attacker

pinging each address in a subnet in order. ICMP echo requests should be blocked at the firewall or
filtering router in most environments, which would protect against this type of scan.
An ICMP echo request scan is a great way for an attacker to identify broadcast addresses on your
subnet, if you permit ICMP echo requests into your network and ICMP echo replies out of your
network. Any address that returns multiple echo replies from one ping is probably a broadcast
address. So if your network is using variable length subnet masks, this technique can identify those
subnets.
4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4
ICMP Echo Request
23:14:11 normalping > normal: icmp: echo request
4500 0054 5336 0000 ff01 6a70 7f00 0001
7f00 0001 0800 1e15 2263 0000 13ca 0339
b181 0400 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
This is a typical ICMP echo request packet. Most ping packets contain in their 8-byte header an
identifier and a sequence number. Following the header is usually a 56-byte payload, consisting of
an 8-byte timestamp and a fill pattern. The FreeBSD ping packet on this slide follows the
convention. (Detect and analysis by Andrew Korty, GCIA)
The 20 octet IP header is grayed out; immediately after it is the 8-byte ICMP header, shown in bold.
The first two bytes of the ICMP header, 0800, are the type and code for an echo request (type 8, code
0). After that is 1e15, the checksum. Next is 2263, the identifier, which is normally the process ID
of the sending process on Unix. The last part of the ICMP header is 0000, which is a sequence
number that normally starts at 0. The next 8 octets, italicized above, is the timestamp. You will
notice that the rest of the packet consists of increasing hex values from 08 through 37, which is the
fill pattern.

5
IDIC - SANS GIAC LevelTwo
©2000, 2001
5
ICMP Echo Request (2)
195.61.132.6 > 128.210.67.55: icmp: echo request (DF)
4500 0028 7873 4000 f101 0614 c33d 8406
80d2 4337 0800 656a beef dead 3901 885d
0008 6f87 80d2 4337 0000 0000 0000
195.61.132.6 > 128.210.67.74: icmp: echo request (DF)
4500 0028 7873 4000 f101 0601 c33d 8406
80d2 434a 0800 5928 beef dead 3901 885d
0008 7bb6 80d2 434a 0000 0000 0000
The detect on this slide looks like a conventional ping scan, and it probably is. However, dumping
the packets reveals something quite out of the ordinary.
Of course, different ping programs are likely to build different packets, but the ones in this detect do
seem odd. The payload is only 10 bytes in length, and the first 4 bytes of the payload are the same as
the destination address. The identifier is always 0xbeef, which would make it difficult for the
sending computer to know which process the replies are intended for, and the sequence number is
always 0xdead, so there is no way to tell how many pings have succeeded without being dropped or
duplicated. It is interesting to note that 0xdeadbeef is often used by programmers as a fill pattern.
Detect and analysis by Andrew Korty, GCIA
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
6
ICMP Payload Change
in Large Scan
63.98.234.3 > good.guys.net.163: icmp: echo request
4500 001c 70ac 0000 1e01 ca65 3f62 ea03

**** 66a3 0800 8d3f 3bbd 2f03 23f8 6673
5010 0c00 b3ce 0000 0000 0000 0000
63.98.234.3 > good.guys.net.164: icmp: echo request
4500 001c a01c 0000 1e01 9af4 3f62 ea03
**** 66a4 0800 883f 3bbd 3403 c37a 0000
0001 0000 0000 0000 0133 0332 3334
63.98.234.3.62287 > good.guys.net.163.80: . ack
1956327536 win 3072
4500 0028 59ff 0000 2306 dc01 3f62 ea03
**** 66a3 f34f 0050 5d00 197b 749b 3070
5010 0c00 32de 0000 0133 0332 3334
The changing pattern helped make the detect, but the scan actually consists of a TCP ACK and an
ICMP echo request for each system. ACKs are pretty successful at penetrating perimeters. Most of
the packets have the frame padded to 46 bytes with zeros.
Detect by George Bakos
7
IDIC - SANS GIAC LevelTwo
©2000, 2001
7
Version Bind
05/24-14:56:52.557482 213.1.248.131:3574 ->
z.y.w.66:53 UDP TTL:49 TOS:0x0 ID:63645 Len: 38
65 18 01 80 00 01 00 00 00 00 00 00 07 76 65 72
73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03
The packet shown in this slide is asking the target system to answer with the version of BIND that it
is running. If an attacker sends a packet like this one to a DNS name server, and that server responds
with its BIND version, then the attacker can use the appropriate exploit to compromise the server.
Notice that two octets have been highlighted: byte 12 (value 07) and byte 20 (value 04).
In the detect below, we have a slight variation of this packet from the same attacking host. You will
notice that the second packet still has the 07 value in the 13th octet into the packet (byte 12) and the

04 value another 8 octets later (byte 20). This will be detected by the standard Snort ruleset. There
is still one more variation of this attack that you see sometimes, which is almost the same as these
and is yet another version query, but it has the byte pattern “00 0010 0008”.
05/24-14:56:53.166333 213.1.248.131:3575 -> z.y.w.98:53 UDP TTL:49 TOS:0x0
ID:63647 Len: 38
4B 2B 01 80 00 01 00 00 00 00 00 00 07 76 65 72 K+ ver
73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 sion.bind
If your host responds to this query, this is not a good sign. There is a good chance it will be
compromised shortly thereafter.
Detects by Laurie Zirkle
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
8
RPC Info Query
05/20-08:28:20.109310 202.152.12.170:948 -> z.y.w.98:111
TCP TTL:47 TOS:0x0 ID:49185 DF
*****PA* Seq: 0x7A679FD2 Ack: 0xD8600F48 Win: 0x7D78
TCP Options => NOP NOP TS: 30003373 579257539
80 00 00 28 3A D7 D6 BF 00 00 00 00 00 00 00 02
00 01 86 A0 00 00 00 02 00 00 00 04 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
RPC packets will generally have the 00 01 86 prefix shown
in the signature for this detect.
SUNRPC is the building block for a number of services, the most well known and frequently used
being NFS. RPCs and even NFS can be implemented over TCP as well as over UDP. Remote
Procedure Calls are not programmed to sockets, but to functions. The log file entries from systems
tend to reflect this, including the ever popular dump() call.
There are common attacks for many well known RPC services such as tooltalk and statd. Here is one
more that is slightly different, but you still have the same signature:

01 86 A0 00 00 00 02 00 00 00 04
[**] RPC Info Query [**]
05/18-18:35:50.788732 203.231.10.220:872 -> z.y.w.98:111
TCP TTL:47 TOS:0x0 ID:22796 DF
*****PA* Seq: 0x356EBD5D Ack: 0x51D3CF02 Win: 0x7D78
TCP Options => NOP NOP TS: 187385869 565623365
80 00 00 28 5E 76 20 50 00 00 00 00 00 00 00 02 (^v P
00 01 86 A0 00 00 00 02 00 00 00 04 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Snort detect by Laurie Zirkle
9
IDIC - SANS GIAC LevelTwo
©2000, 2001
9
Printer Hunting
08:27:36.603367 192.168.1.1.63766 > 192.168.12.3.9100:S
2784969512:2784969512(0) win 65535 <nop,wscale 1,mss 1460>
08:27:40.102674 192.168.1.1.63766 > 192.168.12.3.9100:S
2784969512:2784969512(0) win 65535 <nop,wscale 1,mss 1460>
08:27:46.502821 192.168.1.1.63766 > 192.168.12.3.9100:S
2784969512:2784969512(0) win 65535 <nop,wscale 1,mss 1460>
About every 5 - 10 seconds, myhost (192.168.1.1) sends a TCP connection attempt from a varying
high-numbered port to the remotehost (192.168.12.3) port 9100. The number of connection attempts
using the same source port varies from one to a handful; then the source port changes. The remote
host does not respond to these attempts.
By looking up port numbers on the internet, we found that port 9100 is the standard port used by
networked Hewlett Packard LaserJet printers. Searching the network traces shows other connections
to destination port 9100 to machines that are definitely networked HP LaserJet printers.
A check of myhost's print queue showed that a print job has been trying to print to a remote LaserJet
printer for about a month. The IP address of this printer in the hosts file is correct and does not

match the IP for remotehost. However, looking back in the system change log, we find that the
current IP of remotehost is the same as the original IP of the printer that the print queue is going to.
This IP was updated in /etc/hosts when the network was subnetted and new IP's were assigned.
Printing on myhost is done via HP's JetDirect software. When the print job was cancelled, the TCP
connection attempts to remotehost stopped. When the printer was removed and re-added with the
correct IP address via JetDirect, printing went to the printer and not to remotehost.
Detect and analysis by Mike Harvey, GCIA.
10
IDIC - SANS GIAC LevelTwo
©2000, 2001
10
Port 7306 Scan
09:54:40 prober.374 > ludmi.arpa.net.7306: S
4984444:4984444(0) win 8192 (DF)
09:54:40 prober.375 > 192.168.21.20.7306: S
4984454:4984454(0) win 8192 (DF)
09:54:41 prober.376 > 192.168.21.21.7306: S
4984945:4984945(0) win 8192 (DF)
09:54:41 prober.377 > 192.168.21.22.7306: S
4984955:4984955(0) win 8192 (DF)
09:54:41 prober.378 > 192.168.21.23.7306: S
4984965:4984965(0) win 8192 (DF)
During December 1998 and January 1999, there were a large number of reports of puzzling scans,
often to high numbered TCP and UDP ports. This is one more reason to configure your firewall to
deny all and then add back what you need to do business.
By mid 1999, it was clear that many of these scans had a purpose; they were looking for malicious
code, or trojans. In this case, port 7306 is commonly associated with the NetMonitor trojan.
11
IDIC - SANS GIAC LevelTwo
©2000, 2001

11
Network Mapping
• Network mapping refers to an
attacker probing your systems in
order to determine what their IP
addresses are
Another technique that attackers use to gain information about your systems is network mapping.
There are many ways to do network mapping, but they all have the same goal: determining what the
IP addresses of your systems are.
In many cases, network mapping is done with the most commonly used port numbers, such as 53
(DNS) and 80 (HTTP). This is done for two main reasons: because firewalls are very likely to
permit this traffic to pass through, and because attackers can “hide” their mapping attempts among
all the other traffic going to these ports.
12
IDIC - SANS GIAC LevelTwo
©2000, 2001
12
Data in a SYN
0000: 00 e0 1e 94 5f 00 00 10 0b 49 d9 00 08 00 45 00 |
0010:006883240000f206f42bc8d3bbc2xxxx|
0020:06080898003505d8b25b000000005002 |
0030:08009562000000000000000000000000|
0040:00000000000000000000000000000000|
0050:00000000000000000000000000000000|
0060:00000000000000000000000000000000|
0070:000000000000 |
This is a pattern used for load balancing;
the DNS server responds with a SYN/ACK.
Detect by Dave Eberlien:
“The attacker starts out by sending three crafted Syn packets with 64 octets of null data added. By

itself this is unusual behavior because an initial SYN is normally sent without a payload. The reason
for the payload could be to give a truer representation of response time with a larger packet size. At
the IP level all of the packets that I captured had IP source ports from 2000 to 4000 in increments of
100. The source port would increment by one for the three Syn packets. The initial packets are
received at the trace tool with less then one millisecond separating them. On the trace the summery
[sic] information calls these packets DNS query requests with an ID=0. The reason for this is the tool
will try to interpret the data as a DNS query because of the destination port 53. In fact this is not a
DNS query but simply a TCP Syn packet with 64 octets of null data (all zeros).”
NOTE: In this case the targeted DNS server responds with a SYN/ACK as if nothing is wrong.
The “global load balancing” concept is described by Howard Kash in his “Analysis of the Type0
(Class 0) DNS that has been detected, version 1.0” located at:
/>13
IDIC - SANS GIAC LevelTwo
©2000, 2001
13
02:08:48 mapper.com.3066 > 192.168.134.117.echo:udp6
02:15:04 mapper.com.3066 > 172.31.73.1.echo:udp6
02:15:13 mapper.com.3066 > 172.31.16.152.echo:udp6
02:22:38 mapper.com.3066 > 192.168.91.18.echo:udp6
02:27:07 mapper.com.3066 > 172.31.2.176.echo:udp6
02:30:38 mapper.com.3066 > 192.168.5.103.echo:udp6
02:49:31 mapper.com.3066 > 172.31.152.254.echo:udp6
02:49:55 mapper.com.3066 > 192.168.219.32.echo:udp6
03:00:19 mapper.com.3066 > 172.31.158.86.echo:udp6
udp 6 = UDP packet, 6 bytes payload
Stealthy scan: slow scan rate and address interleaving
Network Mapping
with UDP Echo Requests
In this slide, we see an attacker performing network mapping through UDP echo requests. Don’t
confuse these with ICMP echo requests; there is a service called echo that Unix systems may have on

UDP port 7. This service is unrelated to ICMP echo requests and replies. The echo service will
“echo” whatever characters it receives back to their sender.
If an attacker finds systems that are running the echo service, he or she can use them for a variety of
denial of service attacks. Since it is trivial to spoof a UDP packet (since UDP is connectionless), an
attacker could spoof packets with a forged source address; the system with echo would then send all
of its responses to the spoofed system.
Although many attackers know about the echo service, this particular scan is using an uncommon
technique; we have to give these folks extra points for interleaving the Internet address families and
keeping the scan rate down to stealthy levels.
14
IDIC - SANS GIAC LevelTwo
©2000, 2001
14
Nov 3 1997 6:02:26PM 148.204.89.26 2014 147.168.16.7 143 tcp
Nov 3 1997 6:02:26PM 148.204.89.26 2014 147.168.16.7 143 tcp
Nov 3 1997 6:02:26PM 148.204.89.26 2014 147.168.16.7 143 tcp
Nov 3 1997 6:16:05PM 148.204.89.26 1436 204.34.256.18 143 tcp
Nov 3 1997 6:16:08PM 148.204.89.26 1436 204.34.256.18 143 tcp
Nov 3 1997 9:50:09PM 148.204.89.26 1156 128.256.1.41 1080 tcp
Nov 3 1997 9:50:09PM 148.204.89.26 1157 128.256.10.114 1080 tcp
Nov 3 1997 9:56:17PM 148.204.89.26 1412 147.168.16.7 1080 tcp
Nov 3 1997 9:56:17PM 148.204.89.26 1412 147.168.16.7 1080 tcp
Nov 3 1997 9:56:17PM 148.204.89.26 1412 147.168.16.7 1080 tcp
Nov 3 1997 9:56:17PM 148.204.89.26 1412 147.168.16.7 1080 tcp
Three address families, two loops – “in your face” scan
IMAP + SOCKS Variation
This scan shows an attacker first scanning various addresses for TCP port 143, IMAP. Hours later,
the same address scans some of the same addresses for TCP port 1080, SOCKS.
Another thing we like to look for is the order of a probe. We realized long ago that we weren’t the
sole focus of these attacks. As we continue to deploy sensors in interesting locations, we get a better

and better picture of the list of internet addresses that is being fed to various attack scripts. As the
months go by, it is possible to categorize the input files.
15
IDIC - SANS GIAC LevelTwo
©2000, 2001
15
[**] SNMP access, public [**]
02/22-06:36:32.633503 158.36.37.2:1289 -> x.x.x.z:161
UDP TTL:118 TOS:0x0 ID:51169
Len: 246
30 81 EB 02 01 00 04 06 70 75 62 6C 69 63 A1 81 0 public
DD 02 02 3B E7 02 01 00 02 01 00 30 81 D0 30 0B ; 0 0.
06 07 2B 06 01 02 01 01 01 05 00 30 0B 06 07 2B + 0 +
06 01 02 01 01 03 05 00 30 0B 06 07 2B 06 01 02 0 +
…
01 01 07 05 00 30 10 06 0C 2B 06 01 04 01 0B 02 0 +
03 09 05 01 03 05 00 30 10 06 0C 2B 06 01 04 01 0 +
06 01 04 01 0B 02 04 03 0A 07 05 00 30 0F 06 0B 0
2B 06 01 04 01 0B 02 04 03 0A 0D 05 00 30 0F 06 + 0
0B 2B 06 01 04 01 0B 02 04 03 0D 01 05 00 .+
Password guessing example in the notes pages
SNMP Probe
Default Community String
This is a Snort style detect of an SNMP probe. Only one packet is shown above, but this is part of a
large scan. Note that this is using the public community string and they haven’t yet begun walking
the tree. Another packet, shown below, is guessing the SNMP password:
08/08-11:16:12.737426 216.217.80.201:8314 -> xx.xx.xx.23:161
UDP TTL:116 TOS:0x0 ID:6285
Len: 48
30 26 02 01 00 04 04 64 65 76 61 A0 1B 02 03 2C 0& deva ,

90 B7 02 01 00 02 01 00 30 0E 30 0C 06 08 2B 06 0.0 +.
01 02 01 01 02 00 05 00
There are a handful of other SNMP packets, with the following names: private, gene and fred.
This scan was generated with the “SolarWinds Network Management Toolset”, probably the demo
version. This was certainly not a quiet scan for this particular kiddie.
Reported by Jeremy Hansen in August 13, 2000 GIAC.
16
IDIC - SANS GIAC LevelTwo
©2000, 2001
16
17:31:33.49 prober.1030 > 192.168.2.255.161:
GetNextRequest(11)[|snmp]
17:31:33.73 prober.1030 > 255.255.255.255.161:
GetNextRequest(11)[|snmp]
17:31:33.73 prober > 255.255.255.255: icmp: echo request

17:43:17.32 prober > 192.168.1.255: icmp: echo request
17:43:17.32 prober.1030 > 192.168.1.255.161:
GetNextRequest(11)[|snmp]
GetNextRequest is used to walk an SNMP MIB Tree
Information Gathering
Using Broadcast SNMP and Ping Mapping
In this example, we see a scan that is using SNMP requests and ICMP echo requests in order to
gather information. This is similar to a pattern used by printer software to scan for printers. It is still
troubling.
17
IDIC - SANS GIAC LevelTwo
©2000, 2001
17
[**] SNMP-write-write [**]

02/16-22:45:56.399686 0:0:0:55:B6:43 -> 0:0:0:C4:25:8C type:0x800
len:0x67
0.17.3.44:54064 -> 192.168.1.1:161 UDP TTL:10 TOS:0x0 ID:26882
Len: 17664
30 3B 02 01 00 04 05 77 72 69 74 65 A3 2F 02 04 0; write./
1D 65 1B 75 02 01 00 02 01 00 30 21 30 1F 06 0B .e.u 0!0
2B 06 01 04 01 84 11 09 05 04 00 04 10 31 39 32 + 192
2E 31 36 38 2E 31 2E 31 2E 63 66 67 .168.1.1.cfg
In addition to using SNMP for intelligence gathering,
some MIB variables are writeable.
SNMP Write Attempt
This is a fairly rare pattern, an attack that is often postulated and rarely detected.
This is definitely someone hostile trying to rewrite some SNMP information on our machines. The
destination port is UDP 161, and the payload is clearly an SNMP write command.
There are many more attempts than just the one shown in this slide. They all follow the same
technique. The source port is being reused, the packets arrive in a very fast succession, and the IDs
are incremented by one for each packet. All of this indicates that an automated method is being used.
Also notice the low TTL: these packets have most likely not been traveling that far, so the sender is
probably intentionally setting a low TTL when constructing the packets.
Snort detect and analysis by Tomas Halvarsson, GCIA.
18
IDIC - SANS GIAC LevelTwo
©2000, 2001
18
Network Mapping
Using ICMP Broadcast Echo Requests
00:43:58 pingmapper > 192.168.64.255: icmp: echo request
00:43:58 pingmapper > 192.168.64.0: icmp: echo request
00:50:02 pingmapper > 192.168.65.255: icmp: echo request
00:50:02 pingmapper > 192.168.65.0: icmp: echo request

00:54:56 pingmapper > 192.168.66.255: icmp: echo request
00:54:57 pingmapper > 192.168.66.0: icmp: echo request
In contrast to the Smurf attacks, here we see that the
broadcast echo requests are spaced reasonably far apart in
time. The source IP address is not spoofed. The time delay
between broadcasts gives the attacker time to process the
echo replies without getting overloaded.
A word about social engineering. It was actually on a different scan than this, but when the analyst
finally located the attacker, here was their reply ( [ ]s) indicate sanitized material:
Howdy there! Yeah, we ought to update our contact info. Sigh. Well, it's not a spoof, this is
coming from our network. One of the people who we host here (who runs the [ATTACKER].com
host) has been doing a scan of the internet for places that still are vulnerable to directed broadcasts,
and thus may be used in smurf attacks. He's a security consultant, and hopes to help contact these
sites and tell them how to fix their stuff. We've forwarded this on to him, and I'm sure he'll be
responding shortly with a longer explanation.
So the upshot is: don't worry. All is aboveboard. If you'd like to get in touch with me in particular,
you can give me a call at work at (510)555-1212, or on my cellular at (415)555-1212. But I think
that the best person to talk to about this is Max, who will be contacting you shortly I'm sure. Have
fun!
-[Prober DNS Point of Contact]
19
IDIC - SANS GIAC LevelTwo
©2000, 2001
19
Net Map for Subnet Mask
02:21:06 echo.net > 172.20.64.0: icmp: echo request
02:21:06 echo.net > 172.20.64.64: icmp: echo request
02:21:06 echo.net > 172.20.64.63: icmp: echo request
02:21:01 echo.net > 172.20.64.127: icmp: echo request
02:21:06 echo.net > 172.20.64.128: icmp: echo request

02:21:06 echo.net > 172.20.64.191: icmp: echo request
02:21:06 echo.net > 172.20.64.192: icmp: echo request
02:21:06 echo.net > 172.20.64.255: icmp: echo request
ICMP address mask request would be a lot easier!
In this detect, we see an attacker sending ICMP echo requests to potential broadcast addresses. You may
be saying to yourself, 172.20.64.0 isn’t a broadcast address. That is true of most systems; however, some
older Unix implementations used .0 as a broadcast address instead of .255. So this attacker is searching
for the old style and new style broadcast addresses that would be used by various subnets.
A much simpler way of collecting the same information would be to send ICMP address mask requests.
If your border routers and firewalls do not block address mask requests, then an attacker can just issue an
address mask request, and your network will send an address mask reply with your subnet mask.
02:21:06.700002 echo.net > 172.20.64.0: icmp: echo request
02:21:06.701270 205.67.232.33 > echo.net: icmp: host 172.20.64.0 unreachable - admin prohibited filter
02:21:06.714882 echo.net > 172.20.64.64: icmp: echo request
02:21:06.715229 echo.net > 172.20.64.63: icmp: echo request
02:21:06.715561 echo.net > 172.20.64.127: icmp: echo request
02:21:06.716021 echo.net > 172.20.64.128: icmp: echo request
02:21:06.746119 echo.net > 172.20.64.191: icmp: echo request
02:21:06.746487 echo.net > 172.20.64.192: icmp: echo request
02:21:06.746845 echo.net > 172.20.64.255: icmp: echo request
02:21:06.825170 echo.net > 172.20.65.63: icmp: echo request
02:21:06.826434 echo.net > 172.20.65.0: icmp: echo request
02:21:06.827738 echo.net > 172.20.65.64: icmp: echo request
02:21:06.829132 echo.net > 172.20.65.127: icmp: echo request
02:21:06.830529 echo.net > 172.20.65.128: icmp: echo request
02:21:06.832055 echo.net > 172.20.65.192: icmp: echo request
02:21:06.833415 echo.net > 172.20.65.191: icmp: echo request
02:21:06.835410 echo.net > 172.20.65.255: icmp: echo request
02:21:06.837534 echo.net > 172.20.66.0: icmp: echo request
02:21:06.838839 echo.net > 172.20.66.64: icmp: echo request

02:21:06.840242 echo.net > 172.20.66.63: icmp: echo request
20
IDIC - SANS GIAC LevelTwo
©2000, 2001
20
02:30:01.535559 P 208.147.210.149.1079 >
192.111.43.252.snmp:
GetRequest(29).1.3.6.1.4.1.11.2.4.3.10.6.0
02:30:01.536259 P 208.147.210.149.1079 >
192.111.43.255.snmp:
GetRequest(29).1.3.6.1.4.1.11.2.4.3.10.6.0
Navy printserver to Russia story
Printer Hunting
Using SNMP to Broadcast Addresses
This is another example of an SNMP scan. Note that the second detect is a scan to a broadcast
address. It should be noted that network designers often place core systems at host address “1”.
SNMP should always be blocked at the firewall or filtering router. Many devices such as X-
terminals and print servers come with SNMP agents built in.
Additional analysis was done by Marc Panet-Raymond, GCIA:
The object the attacker appears to be interested in is specific to the HP SNMP tree-based IANA
assignments; .1.3.6.1.4.1.11 is assigned to hp. The particular MIB the attacker is trying to access is
listed below. From the description below, I am not aware of the value of that piece of information,
but if the attacker is successful in retrieving this information, he may also retrieve other information
that can be of use. Also, if the attacker has the read/write community string, he may change the
configuration of the targeted system.
MIB:
.iso.org.dod.internet.private.enterprises.hp.nm.interface.npCard.npIpx.npIpxSapInfo
MIB Description:
This is a 50 byte array that contains the following information.
2 bytes: bindery object type (always 030c in hi-lo order)

12 bytes: Mac address of card (ASCII)
2 bytes: frame type also high bit (8000) is set if card is not configured
2 bytes : unit type (hex 81 for NetJet card)
32 bytes: node name (ASCII) which is:
print server name for Queue Server mode
printer name for RPTR mode
IANA Asssignment: />21
IDIC - SANS GIAC LevelTwo
©2000, 2001
21
scanr.1323 > 172.20.83.3.161: |30|81|ea|02|01|04|06|a1|81|
dcGetNextRequest(9)|02|01|02|01|02|01[|snmp] (ttl 118, id 65130)
scanr.1323 > 172.20.83.3.161: |30|81|ea|02|01|04|06|a1|81|
dcGetNextRequest(9)|02|01|02|01|02|01[|snmp] (ttl 117, id 65130)
scanr.1323 > 172.20.83.3.161: |30|81|ea|02|01|04|06|a1|81|
dcGetNextRequest(9)|02|01|02|01|02|01[|snmp] (ttl 116, id 65130)
scanr.1323 > 172.20.83.3.161: |30|81|ea|02|01|04|06|a1|81|
dcGetNextRequest(9)|02|01|02|01|02|01[|snmp] (ttl 115, id 65130)
This is either a very broken application or a poorly crafted
packet;probably not dangerous, certainly an anomaly.
SNMP Crafted Header
These packets were printed with the -vv option to get more information. The first clue that
something was wrong was that misspelling in GetNextRequest. Also, note that the ID field has not
changed, nor has the source port. I would ignore the TTL differences normally, but the countdown is
just too weird. After checking more data, we see that each host is scanned four times and each time
we have the same TTL pattern.
Now what is the analysis? Do we just have an inept coder trying to write an SNMP application, or is
an inept coder trying to write an exploit? We may never know.
22
IDIC - SANS GIAC LevelTwo

©2000, 2001
22
Scan Using Source Port 0
With Both SYN and FIN Flags Set
13:10:33 srn.org.0 > 192.168.26.203.143: SF
374079488:374079488(0) win 512
13:10:33 srn.org.0 > 192.168.24.209.143: SF
374079488:374079488(0) win 512
13:10:33 srn.org.0 > 192.168.17.197.143: SF
374079488:374079488(0) win 512
13:10:33 srn.org.0 > 192.168.16.181.143: SF
374079488:374079488(0) win 512
13:10:33 srn.org.0 > 192.168.24.194.143: SF
374079488:374079488(0) win 512
Source port 0 or 65535 and SF set are a good signature.
So why are these packets being crafted? Part of the
reason is that some security devices filter on SYN only.
There are several interesting aspects to this scan pattern. First, the source port in each attempt is set
to 0, which you should not normally see. Second, both the SYN and FIN flags have been set. This is
a classic sign of crafted packets, since SYN and FIN should never both be set in the same packet.
Historically, SYN/FIN packets have been used to evade filtering and intrusion detection systems.
FINs may be allowed through even if SYNs are not. This improves the probability of a response.
Since the FIN signals connection teardown, some logging systems will potentially fail to report the
connect.
Several security folks in the trade have commented that Windows systems will answer a packet with
SYN and another flag set as if it were a SYN only packet. That may be, but Windows systems do not
tend to host IMAP and NFS; this scan is more likely to be targeted at Unix systems. Therefore, the
purpose(s) of the SYN/FIN must be to avoid getting logged and evade filtering devices.
Currently, SYN/FIN scans occur against many different ports.
Final note: the attack tool here may be linuxportz.

23
IDIC - SANS GIAC LevelTwo
©2000, 2001
23
DNS Scan with SF, 0
Jan 30 05:02:31.562286 207.153.9.234,0 -> 10.0.0.1,53
PR tcp len 20 40 -SF
Jan 30 05:02:31.572273 207.153.9.234,0 -> 10.0.0.2,53
PR tcp len 20 40 -SF
Jan 30 05:02:31.582643 207.153.9.234,0 -> 10.0.0.3,53
PR tcp len 20 40 -SF
Over two years after the first 0 SF pattern was detected, this
DNS probe was located.
Here is another example of a scan where the SYN and FIN flags are set and the source port is always
set to zero. In this case, it appears to be targeting DNS. We have seen a number of reports of detects
from systems that had source port zero and SF set, which is anomalous. The combination is used for
both penetration and stealth.
Detect by Erik Fichtner, obfuscation.org, first reported on GIAC on February 2, 2000.
24
IDIC - SANS GIAC LevelTwo
©2000, 2001
24
DNS Update
Apr 8 18:07:53 dns1 named[11759]: unapproved update
from [208.243.251.37].65532 for .edu
Apr 8 18:07:54 dns1 named[11759]: unapproved update
from [208.243.251.37].65531 for .edu
This system log file shows activity that occurs on UDP port
53. This is a potential problem for sites with Windows 2000
systems that are not hardened. Detailed explanation of

update is included in your notes pages.
Detect and analysis below by Suzanne Hernandez, GCIA:
Apr 03 02:05:33 ns1 named[1337]: unapproved update from [13.1.1.1].1025 for
our.domain
This message came from our syslog running on our DNS server. I had never seen this message before
and investigated it in DNS and BIND. It turns out this is a feature in the 8.x version of BIND that allows
you to remotely add to or delete records from a domain. We run a second level domain on our network,
so further investigation was necessary, even though the update was unsuccessful. This feature is
necessary to allow a DHCP server to add records to a DNS server whenever a machine registers itself
with the DHCP server. The nsupdate works on UDP port 53 just like a regular DNS query. To recreate
this, I created a bogus domain with an mx record and added the following to the options section in the
DNS configuration file:
allow-update { any; };This option is off by default.
I then typed the following from another server:
root@server] # nsupdate
> update delete bogus.domain. in mx
> update add bogus.domain. 99999999 in mx 0
hacker.exchange.server.
When this was completed, I did an mx lookup and got the following result:
Nslookup q=mx bogus.domain
Bogus.domain preference = 0, mail exchanger = hacker.exchange.server
Now I have effectively hijacked bogus.domain’s mail and redirected it to my exchange server.
25
IDIC - SANS GIAC LevelTwo
©2000, 2001
25
11:16:44.611343 ns1.uta.edu > myhost.woe.is.me.com: icmp:
ns1.uta.edu udp port 1075 unreachable (DF)
11:16:44.611345 dns.Princeton.EDU.1075 >
myhost.woe.is.me.com.53: 65196 (41) (DF)

11:16:44.611499 myhost.woe.is.me.com.53 >
dns.Princeton.EDU.1075: 65196* q: woe.is.me.com 0/0/0 (41)
11:16:44.624771 as4100c.javanet.com.1075 >
myhost.woe.is.me.com.53: 10825 (41)
11:16:44.624942 myhost.woe.is.me.com.53 >
as4100c.javanet.com.1075: 10825* q: woe.is.me.com 0/0/0 (41)
11:16:44.655498 dns.Princeton.EDU > myhost.woe.is.me.com:
icmp: dns.Princeton.EDU udp port 1075 unreachable (DF)
11:16:44.661939 as4100c.javanet.com > myhost.woe.is.me.com:
icmp: as4100c.javanet.com udp port 1075 unreachable
DNS Denial of Service
The query host is spoofed
These queries come from a very diverse set of source addresses. The query (q: field) contains the
domain name (woe.is.me.com) rather than a host. The query is successful, as myhost returns one
answer (1/1/1).
The random source ports seem normal enough, but the intensity of the timing of the requests is
highly unusual for this very lightly-used DNS server. Each host sends two seemingly identical
requests back-to-back, but each has a separate DNS ID, which increments a small amount for each
connection, which would seem normal for two requests close together if ID's are assigned
sequentially.
I found a tool on rootshell.com called doomdns whose purpose is to send DNS requests to a server
with spoofed source addresses in a sort-of smurf style flooding DoS attempt. The comments in the
source claimed a very large amplification factor can be achieved with DNS. There's also a tool
called abusedns mentioned at the sans web site. This tool is a follow-on to doomdns.
Detect and analysis by Mike Harvey, GCIA.