10 - 1

Intrusion Detection in-Depth SANS 2003

1
Network Mapping/Information
Gathering
This page intentionally left blank.
10 - 2
Intrusion Detection in-Depth - SANS 2003 2
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
Stealthy scanning
Outbound activity may signal compromise
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.
Specifically, some of the topics that will be examined in the section are host-by-host scanning in an
attempt to find live hosts or ones that are listening for a certain service. Well also look at stealthy
scanning that may be something as simple as slowly performing the scanning to avoid detection. Or
it may be something as clever as indirectly using another host to assist you in scanning as well see
with the tool hping. And, finally, while it may not be considered information gathering, per se, it is
important to understand that outbound activity from a server in your network may be an indication
that the host has been compromised.
10 - 3
Intrusion Detection in-Depth - SANS 2003 3
Hping Pattern
Silent Host Replies:
17:14:18.726864 quiethost.0 >attacker.1356: R 0:0(0) Ack 192486 win 8192 <mss
1380> (DF) (ttl 17, id 15697)
17:14:21.781140 quiethost.0 >attacker.1357: R 0:0 (0) Ack 187498 win 8192 <mss
1380> (DF) (ttl 17, id 15699)
Attacker Quiet
Target
1
Stimulate Quiet Host
2
Note IP ID on response 3
Step 3, stimulate the
target. Spoof address
of the quiet host. If the
port is active, Quiet
host receives Syn/Ack, if
closed, Rst/Act.
4
5
Step 5, the Quiet host
will only reply to a
Syn/Ack and will reply
with an RST
incrementing his IPID.
Before hping2 became a packet factory generator, it was a reconnaissance tool that took advantage of a neat
trick. It allowed you to scan a target without directly revealing your IP address.
First, it required the attacker to find a quiet host one which was not being used, but was a live host which
was not behind a restrictive firewall. The attacker would stimulate the quiet host by sending many packets
of TCP traffic to a non-listening port of the quiet host. The attacker would examine the IP identification
numbers returned by the quiet host in the RESETS of the traffic. If this were truly a quiet host, the
attacker expected to see incrementing IP ID numbers. Historically, IP ID numbers were incrementally
generated most often each new packet had an IP ID value one greater than the previous one. Today, some
TCP/IP stacks have a randomized IP ID and scanning via hping2 would no longer work.
Next, as the background scanning of the silent host is happening, the attacker now tries to examine whether a
target host listens on a particular port. This is where the scan becomes very clever. The attacker sends a SYN
to the target host and port that is of interest, but the source IP used is the quiet hosts. Therefore, the target
host will respond to the quiet host. Although the attacker can not see the actual response of the target host,
what he can see is the change in IP ID numbers because of the background scan he has going between his host
and the quiet host. What good is this? If the target host does not listen on the port that was scanned, it
will respond with a RESET to the original source IP what it believe to be the quiet host. The quiet host
will silently drop the RESET. However, if the target host listens on the port scanned, it will respond with a
SYN/ACK to the original source IP of the quiet host. When the quiet host receives a SYN/ACK and
realizes it never sent a SYN in the first place (remember the port scan traffic was all spoofed to have the
source IP of the quiet host) , it will respond with a RESET. What the attacker will be able to see is an
increment of the IP identification number by 2 instead of the normal 1 from the background scan. When he
sees this, he knows that the target host listens on the scanned port.
The target host never receives traffic from the attacker. The quiet host acts as an unknowing middleman to
reflect traffic.
10 - 4
Intrusion Detection in-Depth - SANS 2003 4
Normal ICMP Review
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 ICMP 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.
10 - 5
Intrusion Detection in-Depth - SANS 2003 5
ICMP Echo Request
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
10 - 6
Intrusion Detection in-Depth - SANS 2003 6
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
11:01:33.468943 xx.xx.xx.xx > 192.168.6.4: icmp: echo request
0x0000 4500 0023 00be 0000 8001 fbe5 xxxx xxxx E..#............
0x0010 c0a8 0604 0800 cf13 0200 1000 444d 4250 ............DMBP
0x0020 494e 4700 0000 0000 0000 0000 0000 ING...........
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. Just for fun, we dump the hex and in this case find that the payload of the
packet contains the string DMBPING so this is not being done from the keyboard, we have a case
of a tool crafted to send this.
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.
10 - 7
Intrusion Detection in-Depth - SANS 2003 7
Echo Requests and Unsolicited
ACKs
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
This scan uses a combination of echo requests and unsolicited ACKs in an attempt to discover live
hosts. ICMP echo requests may be blocked inbound precluding any response and live host
identification. However, if the perimeter defense is accomplished by a packet-filtering device that is
not stateful, such as a Cisco router, it may be possible to penetrate it with the unsolicited ACK.
A router that is not stateful will assume that the ACK flag on the packet means some kind of
established connection and will allow the traffic inbound. If the target host exists, it will respond to
the unsolicited ACK with a RESET informing that scanner that the host is alive.
Detect by George Bakos
10 - 8
Intrusion Detection in-Depth - SANS 2003 8
Recon for DNS TSIG
Domain Name System (query)
Transaction ID: 0xbeef
Flags: 0x0980 (Inverse query)
0... .... .... .... = Query
.000 1... .... .... = Inverse query
.... ..0. .... .... = Message is not
truncated
.... ...1 .... .... = Do query recursively
Questions: 0
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
CERT advisory CA-2001-02 describes a buffer overflow attack for DNS transaction signature (TSIG)
traffic. Before this vulnerability could be exploited it was necessary to do some reconnaissance on
the target DNS server. This was done using a DNS inverse query and returned valuable information
required for the actual exploit.
One version of the exploit code used a very identifiable DNS identification number 0xbeef for the
inverse query. The Ethereal output shown above displays this identification number and indicates
that this is an inverse query. Inverse queries are a legacy of older versions of BIND and are typically
not seen or supported in newer versions of BIND. Signatures to identify TSIG reconnaissance would
look for the DNS identification number of 0xBEEF and an inverse query. It should be noted that this
DNS identification number could be easily changed in the source code to elude detection. Another
version of the exploit uses a DNS inverse query with an identification number of 0xABCD.
10 - 9
Intrusion Detection in-Depth - SANS 2003 9
DOA TSIG
10.0.0.1.1045 > 10.0.0.2.53: 57005+ [b2&3=0x180] [7q] [1au]
Type0 (Class 250)? ^@^A^B^C^D^E^F^G^H^I^J^K^L^M^N^O^P^Q^R^S^T^
U^V^W^X^Y^Z^[^\^]^^^_ !"#$%&'()*+,-./0123456789:;<M-k^J.^@^@.
[|domain]
4500 021a 0f5d 0000 4011 6b74 0a00 0001 E....]..@.kt....
0a00 0002 0415 0035 0206 3b11 dead 0180 .......5..;.....
0007 0000 0000 0001 3f00 0102 0304 0506 ........?.......
0708 090a 0b0c 0d0e 0f10 1112 1314 1516 ................
1718 191a 1b1c 1d1e 1f20 2122 2324 2526 ..........!"#$%&
2728 292a 2b2c 2d2e 2f30 3132 3334 3536 '()*+,-./0123456
3738 393a 3b3c eb0a 0200 00c0 0000 0000 789:;<..........
003f 0001 eb44 5e29 c089 4610 4089 c389 .?...D^)..F.@...
460c 4089 4608 8d4e 08b0 66cd 8043 c646 F.@.F..N..f..C.F
..
72ff ffff 2f62 696e 2f73 6800 0e0f 1011 r.../bin/sh.....
If a DNS server responds to the inverse query contained in the code to perform the TSIG exploit, the
next step is the actual buffer overflow attempt. The DNS request can be seen in the slide above. It is
a strange query, but has a couple of familiar items. First that attacker has to give this DNS query an
identification number. The decimal value printed by tcpdump is 57005, but the hex equivalent is our
old friend 0xdead. This matches the inverse query DNS identification number. This isnt required,
but it looks like the coder wanted some kind of consistent telltale identification.
The DNS type is 0 and the class is 250 that signals a TSIG transaction. The query itself is just a
count up of hex values. Since this was a very long query, many of the lines have been omitted. But,
you can see a familiar ASCII translation on the right side of the output the /bin/sh. This is the
attempt to get a shell at the privilege level at which BIND is running if the buffer overflow has been
successful.
For a comprehensive discussion of tsig, see: http://www.sans.org/rr//DNS/BIND.php
10 - 10
Intrusion Detection in-Depth - SANS 2003 10
Recon for BIND Version 9
dig +short @ns.sample.com authors.bind chaos txt
host.myplace.com.32813 > ns1.myplace.com.domain:
21261+ TXT CHAOS)? authors.bind. (30) (DF)
"Andreas Gustafsson"
"Bob Halley"
"Damien Neil"
"Matt Nelson"
"Ben Cottrell"
etc.
The authors of BIND version 9 wanted to make sure that they got some credit. So they included they
created a new DNS query that could ask for the authors names. Remember the version of BIND
query was able to determine the exact version of BIND running using the a DNS type of TXT and a
class of CHAOS? The authors.bind query doesnt tell the exact version of BIND, however it is a new
feature of version BIND 9.
Attackers quickly learned that this feature might help them locate BIND version 9 DNS servers.
While version.bind comes disabled by default in BIND version 9, authors.bind comes enabled and
ready to spew out the authors names upon request. All an attacker has to do is use any of the tools
such as dig, host, or nslookup to execute the authors.bind query. Specifically, they must point to the
DNS server to be queried, make sure that the DNS type is set to TXT, the DNS class is set to CHAOS
and query for authors.bind. If they are successful, you will see the names on the above slide
displayed.
10 - 11
Intrusion Detection in-Depth - SANS 2003 11
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
Remote Procedure Calls (RPC) are the building block for a number of services, the most well-known
and frequently used being Network File System (NFS). RPCs and even NFS can be implemented
over TCP as well as over UDP. RPCs are not programmed to sockets, but to functions. The log file
entries from systems tend to reflect this, including the ever popular dump() call that can be executed
from a Unix command line with rpcinfo p z.y.w.98.
If you were to examine the bolded values (00 01 86 A0 00 00 00 02 00 00 00 04) in
Ethereal, you would find the following:
00 01 86 A0 is the universal program number for Portmap (100000 in decimal)
00 00 00 02 is the version of Portmap program (version 2)
00 00 00 04 is the procedure to be called by portmap in this case dump
[**] 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
10 - 12
Intrusion Detection in-Depth - SANS 2003 12
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 - 13
Intrusion Detection in-Depth - SANS 2003 13
Backdoors WU-FTPD 9704
&T0rn 9876
Jan 28 03:51:37 165.230.162.206:39343 ->
MY.SUB.NET.1:9704 SYN **S*****
Jan 28 03:51:37 165.230.162.206:3290 ->
MY.SUB.NET.3:9704 SYN **S*****
16:50:05.773307 193.231.96.73.4331 > honey.net.9876:
S [tcp sum ok] 1365694445:1365694445(0) win 16384
<mss 1460,nop,nop,sackOK> (DF) (ttl 103, id 34873,
len 48)
16:50:05.773590 honey.net.9876 > 193.231.96.73.4331:
S [tcp sum ok] 391308637:391308637(0) ack 1365694446
win 32120 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id
49072, len 48)
Obviously an attacker could use any port as a back door. For the purpose of this course, we are
asking you to be sensitive to three: 1524 ingreslock taught later, 9704, and the one from the T0rn
rootkit, 9876 of course these could be changed, but they are also fairly common.
Detect and Analysis by Paul Asadoorian, GCIA HONORS.
It turns out the port 9704 is a common backdoor port that is put into place when an attacker uses
specific RPC and WU-FTPD buffer overflow exploits. Once the attacker gains access to the
machine, via a buffer overflow, a line is put in the inetd.conf telling it to listen on port 9704. The
attacker was looking for machines that had already been compromised. If the attacker were able to
find this port open they would have instant access to a root shell. The scan contains characteristics,
such as the SYN flag being set, random source ports, and the ability to specify an ip range or subnet
as well as destination port number.
The following links contain all of the supporting information for scans of port 9704:

http://lists.insecure.org/incidents/2000/Sep/0054.html
http://www.cert.org/advisories/CA-2000-17.html
For information about T0rn, I would look at Byron thatchers GCIA practical:
http://www.sans.org/y2k/practical/Byron_Thatcher_GCIA.doc which is where the trace on the slide
was taken from and also Toby Millers paper at: http://www.sans.org/y2k/t0rn.htm
10 - 14
Intrusion Detection in-Depth - SANS 2003 14
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.
10 - 15
Intrusion Detection in-Depth - SANS 2003 15
02:08:48 mapper.com.3066 > 192.168.134.117.echo: udp 6
02:15:04 mapper.com.3066 > 172.31.73.1.echo: udp 6
02:15:13 mapper.com.3066 > 172.31.16.152.echo: udp 6
02:22:38 mapper.com.3066 > 192.168.91.18.echo: udp 6
02:27:07 mapper.com.3066 > 172.31.2.176.echo: udp 6
02:30:38 mapper.com.3066 > 192.168.5.103.echo: udp 6
02:49:31 mapper.com.3066 > 172.31.152.254.echo: udp 6
02:49:55 mapper.com.3066 > 192.168.219.32.echo: udp 6
03:00:19 mapper.com.3066 > 172.31.158.86.echo: udp 6
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. Dont
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.
10 - 16
Intrusion Detection in-Depth - SANS 2003 16
[**] 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 havent 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 on August 13, 2000 GIAC.
10 - 17
Intrusion Detection in-Depth - SANS 2003 17
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.
10 - 18
Intrusion Detection in-Depth - SANS 2003 18
[**] 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.
10 - 19
Intrusion Detection in-Depth - SANS 2003 19
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 Assignment: http://www.iana.org/assignments/enterprise-numbers
10 - 20
Intrusion Detection in-Depth - SANS 2003 20
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.
10 - 21
Intrusion Detection in-Depth - SANS 2003 21
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.
10 - 22
Intrusion Detection in-Depth - SANS 2003 22
date time source IP src port dest IP dest port
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.38 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.2 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.40 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.42 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.4 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.44 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.6 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.8 80 t
04/26/98 20:27:37 202.256.20.6 31337 256.34.229.46 80 t
31337, 666 are gimmes
Scanning for Web Servers
31337 Signature Port
Its easy to see that this is a host scan. At the same time, many different IP addresses on the same
subnet are receiving a packet from one source address destined for their TCP port 80. We can get
further confirmation that this is an automated scan because of the use of source port 31337 (eleet).
This could be a coincidence, but it is far more likely that the attack script or program uses the eleet
port. Other noteworthy source ports such as 666 are also used.
10 - 23
Intrusion Detection in-Depth - SANS 2003 23
Information Gathering
Using NetBIOS
One of the characteristics of NetBIOS is that UDP 137 is often caused by
something a site initiates. For example, if you send e-mail to a site running
Microsoft Exchange, they will often send a port 137 attempt. So we look
for the causing factor:
Here is the pattern:
12/02/97 08:27:18 jellypc.net 1112 -> www.srnaccess.com http
12/02/97 08:27:19 207.256.242.26 137 -> jellypc.nnnn.arpa.net 137
or:
12/02/97 17:06:03 jampc.net 2360 -> www.srnaccess.com http
12/02/97 17:08:10 207.256.242.26 137 -> jampc.nnnn.arpa.net 137
NOTE: 207.256.242.26 is on the same Class C net as www.srnaccess.com
We love NetBIOS! We could keep an analyst employed full time evaluating the various patterns.
The slide above shows a common case, where a web server is accessed by a PC and then sometime
later the PC is accessed with a name lookup. Think of this in terms of stimulus and response; when
you see activity from port 137 to port 137, you need to determine if it is stimulus from an attacker or
a response to an action from your own site.
10 - 24
Intrusion Detection in-Depth - SANS 2003 24
16:34:59 srn.org 137 > 192.168.130.55 137: udp
16:34:59 srn.org 137 > 192.168.108.171 137: udp
16:34:59 srn.org 137 > 192.168.162.231 137: udp
16:34:59 srn.org 137 > 192.168.14.209 137: udp
16:34:59 srn.org 137 > 192.168.145.45 137: udp
16:34:59 srn.org 137 > 192.168.160.181 137: udp
16:34:59 srn.org 137 > 192.168.15.116 137: udp
16:34:59 srn.org 137 > 192.168.148.137 137: udp
16:35:00 srn.org 137 > 192.168.146.20 137: udp
16:35:00 srn.org 137 > 192.168.164.186 137: udp
A connection from any source port other than
137 to 137 may indicate a Samba system.
Information Gathering
Scanning for NetBIOS Name Service
This slide shows more examples of port 137 scans. Although there are many reasons why an attacker
might try to access NetBIOS ports, one of the primary reasons is reconnaissance. Port 137 provides a
lot of information to an attacker; if at all possible, this port should be blocked at your network
perimeter.
Although we typically think of NetBIOS connections occurring from UDP port 137 to port 137, this
is not always the case. For example, connections involving a Samba system may only have port 137
as a source or destination, not both.
10 - 25
Intrusion Detection in-Depth - SANS 2003 25
Null Sessioning
What is it? - finger for Windows
Provides information about user
names and shares
Demonstration exploit
Defending against null sessioning
Null sessioning is a way of gathering information about a Windows system. Some people compare it
to the finger command on Unix systems, but null sessioning can reveal much more information.
When you establish a null session, you are effectively logging into a Windows system as user
nobody. This gives you very limited rights, so you cant change anything on the Windows system,
but you can access a lot of information about the system.
10 - 26
Intrusion Detection in-Depth - SANS 2003 26
Null Session
net use \\172.20.244.164\IPC$ /USER:
Or
NET USE \\172.20.244.164\IPC$ /u:
Then
NET VIEW \\172.20.244.164
If null session or anonymous login is allowed, it is possible
to collect a tremendous amount of information about the
system including the users names. With that information,
a variety of passwords can be tried against the names.
This slide shows a command that could be used to create a null session. As you can see, the user
name is set to null. Also, the share that we are accessing on the Windows machine is called IPC$. If
your system allows such connections to your IPC$ share, then attackers can gather information on
your system. The next slide shows some of the information that can be collected through a null
session.
A practical from Andrew Windsor shows the share decoded on the net and then, he shows a much
easier way.
http://www.sans.org/y2k/practical/Andrew_Windsor_GCIA.doc
00180: 00 00 09 00 00 00 50 00 72 00 6F 00 66 00 69 00 ......P.r.o.f.i.
00190: 6C 00 65 00 73 00 00 00 0D C1 01 00 00 00 00 00 l.e.s..........
001A0: 00 00 01 00 00 00 00 00 70 9D 05 00 00 00 00 00 ........p_......
001B0: 00 00 05 00 00 00 49 00 50 00 43 00 24 00 00 00 ......I.P.C.$...
001C0: 12 A6 0B 00 00 00 00 00 00 00 0B 00 00 00 52 00 ._............R.
001D0: 65 00 6D 00 6F 00 74 00 65 00 20 00 49 00 50 00 e.m.o.t.e. .I.P.
001E0: 43 00 00 00 42 84 03 00 00 00 00 00 00 00 03 00 C...B..........
001F0: 00 00 44 00 24 00 00 00 7C 37 0E 00 00 00 00 00 ..D.$...|7......
00200: 00 00 0E 00 00 00 44 00 65 00 66 00 61 00 75 00 ......D.e.f.a.u.
00210: 6C 00 74 00 20 00 73 00 68 00 61 00 72 00 65 00 l.t. .s.h.a.r.e.
00220: 00 00 03 00 00 00 00 00 00 00 03 00 00 00 49 00 ..............I.
00230: 24 00 00 00 2D 2A 0E 00 00 00 00 00 00 00 0E 00 $...-*..........
Other tools can be used to enumerate shares, ACLs, usernames and so forth. By far and away the
most useful tool that exploits this feature is Razors enum which is available on
http://razor.bindview.com.
10 - 27
Intrusion Detection in-Depth - SANS 2003 27
A Real Example
2/18/98 1:39 AM - Diablo - \\192.168.4.22
UserName,Administrator
Groups,Administrators (Local,
Members can fully administer the computer/domain)
AccountType,User
HomeDrive
HomeDir
PswdCanBeChanged,Yes
PswdLastSetTime,Never
PswdRequired,Yes
PswdExpires,No
AcctDisabled,No
AcctLockedOut,No
AcctExpiresTime,Never
LastLogonTime,11/20/98 3:24 PM
LastLogonServer,192.168.4.22
Sid,S-1-5-21-706837240-361788889-398547282-500
This slide shows some of the information that can be collected once you are logged on as the user
nobody. Attackers can use null sessioning to collect system names, user names, group names, and
system policy settings.
In order to protect your systems against activities like null sessioning, you should use a security
auditing program for Windows hosts. One such program is SomarSofts DumpSec
(http://www.somarsoft.com), which can be used to identify problems with the security of an NT
systems Registry, file system and shares.
To disable null session on Windows 2000, edit the appropriate registry setting:
Run the command regedt32
Go to HKLM\SYSTEM\CurrentControlSet\Control\LSA
Edit the key RestrictAnonymous to have a value of 2
Understand that if you are in a Windows domain this may break things. There are legitimate
purposes for null sessions such as:
Trusted domains can enumerate resources
Computers outside the domain can authenticate and enumerate users
T he SYSTEM account can authenticate and enumerate resources
The above information was obtained from:
http://www.brown.edu/Facilities/CIS/CIRT/help/netbiosnull.html
10 - 28
Intrusion Detection in-Depth - SANS 2003 28
Clearcase UDP 371
Time Source Destination Protocol
Info
23:03:19.9379 206.251.4.210 cablemodem.net UDP
Source port: 1070 Destination port: 371
09:53:45.7975 206.251.4.210 cablemodem.net UDP
Source port: 1045 Destination port: 371
09:53:51.5325 206.251.4.210 cablemodem.net UDP
Source port: 1031 Destination port: 371
09:54:01.8435 206.251.4.210 cablemodem.net UDP
Source port: 1077 Destination port: 371
Note that the source address is Compaq
Detect and analysis by Shane Boothe:
Note: Detects are from either systems outside our corporate firewall or from systems connected to a
cable modem (cable-modem-land is kinda scary!!!). In all cases a host-based firewall was used. Most
addresses have been changed to protect the guilty/innocent. Packet dumps were read via Ethereal
(http://ethereal.com), an open source network protocol analyzer.
After seeing the above activity I did an nslookup on 206.251.4.210, which returned Compaq as the
owner. Being curious why Compaq would scan their customers computers, I did a little research.
UDP 371 is associated with either Clearcase, which is source control product from Rational Software
(http://www.rational.com/products/clearcase/index.jtmpl) or Backweb (http://www.backweb.com/),
which is a push based software distribution solution. A quick search of Backwebs site verified the
Compaq relationship. On the client computer an application named Compaq Service Connection is
automatically started upon boot up. The software allows Compaq to deliver software updates and
patches automatically. Im not sure I like that idea! In any case we configured the firewall to trust this
address so the updates could be delivered.
10 - 29
Intrusion Detection in-Depth - SANS 2003 29
Subtle and Stealthy Attacks
These attacks typically fall below the
noise threshold on a network and are
consequently difficult to detect. The
hostile connections are embedded
within a large volume of identical traffic
that is too massive to realistically
process.
There are two real approaches to stealth scanning: low and slow, and covert channels.
Coverting involves hiding information in packet headers, or what should be null padding, and can be
a handy way to synchronize with Trojans. With Trojan applications, the attacker has to find and
acquire the Trojan before they can make use of it.
Low and slow is just what it sounds like; there comes a point somewhere between 3 and 7 packets per
hour that it is no longer practical to search for scans unless you have a data mining capability.
10 - 30
Intrusion Detection in-Depth - SANS 2003 30
APR 21 ->
18:41:03.642390 srn.org > 256.168.12.255: icmp: echo request
18:41:05.120927 srn.org > 256.168.12.255: icmp: echo request
19:32:51.522600 srn.org > 256.38.13.255: icmp: echo request
19:32:53.119613 srn.org > 256.38.13.255: icmp: echo request
21:29:59.235065 srn.org > 256.168.13.255: icmp: echo request
21:30:00.238629 srn.org > 256.168.13.255: icmp: echo request
22:23:03.099737 srn.org > 256.38.14.255: icmp: echo request
22:23:03.853866 srn.org > 256.38.14.255: icmp: echo request
APR 22 ->
01:11:07.718531 srn.org > 256.38.15.255: icmp: echo request
01:11:09.370796 srn.org > 256.38.15.255: icmp: echo request
02:11:40.517847 srn.org > 256.168.15.255: icmp: echo request
02:11:42.760540 srn.org > 256.168.15.255: icmp: echo request
NOTE: They are mapping 2 sites
Stealthy Ping Mapping
Slow Scan to Evade Detection
This slide is an example of a slow scan of multiple subnets. The scans are occurring one or two hours
apart from each other. This technique will work to evade most intrusion detection systems because
they dont hold connections for evaluation anywhere near an hour. Being acquainted with multiple
traces of low and slow is well worth your time; it is a powerful technique.
If an intrusion detection system found this noteworthy traffic because of the broadcast address, it may
record a tally count for the most active source IPs. It is possible that if the threshold of scans
becomes large enough over time, it may show up as an active hostile source IP.
10 - 31
Intrusion Detection in-Depth - SANS 2003 31
16:32:30 www.org.80 > 172.16.97.217.1775: SA
16:32:40 www.org.80 > 172.16.129.64.1630: SA
16:32:54 www.org.80 > 172.16.176.79.1630: SA
16:32:58 www.org.80 > 172.16.191.57.1775: SA
16:33:09 www.org.80 > 172.16.223.94.1630: SA
16:33:13 www.org.80 > 172.16.238.72.1775: SA
Trace with complete header shown on notes pages
SYN/ACK Hiding in HTTP
Recall that if a system connects to a web server on port 80, the web server will answer back with 80 as the
source port. The source port of the clients request becomes the destination port, as shown below:
16:32:30 172.16.97.27.1775 > www.org.80 : S
16:32:30 www.org.80 > 172.16.97.27.1775: SA
In the case below there were no initiating SYNs, so this is either a SYN/ACK scan or someone is spoofing
your address space and hitting the web server.
16:32:30 www.org.80 > 172.16.97.27.1775: S 2784994:2784994(0) ack 674711610 win
32736
16:32:40 www.org.80 > 172.16.129.64.1630: S 266690:266690(0) ack 674711610 win
32736
16:32:54 www.org.80 > 172.16.176.79.1630: S 6827234:6827234(0) ack 674711610 win
32736
16:32:58 www.org.80 > 172.16.191.57.1775: S 7509906:7509906(0) ack 674711610 win
32736
16:33:09 www.org.80 > 172.16.223.94.1630: S 8636714:8636714(0) ack 674711610 win
32736
16:33:13 www.org.80 > 172.16.238.72.1775: S 6505114:6505114(0) ack 674711610 win
32736
This would be considered reconnaissance if www.org is a host that is sending SYN/ACKs in order to elicit a
RESET or host unreachable message to scan for live hosts. If www.org is an actual web server, chances are
better that someone is spoofing your IPs and you are seeing backscatter. Although, a clever attacker may
have a host posing as a web server or may be using a compromised web server to scan for live hosts.
10 - 32
Intrusion Detection in-Depth - SANS 2003 32
06:41:24 srn.com.113 > 172.21.32.83.1004: S
405:405(0) ack 674 win 8192
06:42:08 srn.com.113 > 192.168.83.15.2039: S
233:233(0) ack 674 win 8192
06:44:09 srn.com.113 > 192.168.162.67.2226: S
76:761(0) ack 674 win 8192
Result:
06:44:09 192.168.162.67.2226 > srn.com.113: R
674:674(0) win 0
The initiating SYN connections were never sent, but SYN-
ACKs are received.
Network Mapping
Using TCP SYN/ACK Packets
This slide demonstrates the pattern that is the so called stealth scan; stealth was coined by Chris
Klaus in his signature paper on stealth scanning that is available on fine hacker information sites
everywhere. As for the time frame, before mid 1997, this was a stealthy approach. Today, a more
accurate and descriptive term for this pattern is TCP half scans. Before we talk about how this
works, lets do a quick refresher on the TCP three way handshake.
A wants to talk to B, so A sends a packet with the SYN flag set. B says OK, I will talk with you and
acknowledges As SYN with a SYN/ACK. A says great and acknowledges Bs SYN/ACK with an
ACK, and the conversation begins.
A SYN B
A SYN/ACK B
A ACK B
The top section of your slide shows the signature of a TCP half open scan. The destination site sees
packets with SYN/ACKs, but there are not initiating SYNs to match them to. While this is certainly
the signature of a TCP half scan, there are other possible causes for this traffic. Your address space
might be used in a spoofing attack on someone else, or your site might possibly be involved in an
hping style scan, which we will discuss shortly.
The lower section of the slide, shown below the result box, illustrates how this scan can work. When
srn.coms packet arrives at 192.168.162.67 with the SYN/ACK set, 192.168.162.67 knows something
is wrong. TCP is stateful, and so 192.168.162.67 knows he never sent a SYN or active open packet.
Recall this is the first step in the three way TCP handshake. He figures this packet must be a mistake
and sends a RESET (the R in the fourth line) to say break off communications, something is wrong
here. This gives away his existence to srn.
10 - 33
Intrusion Detection in-Depth - SANS 2003 33
06:41:24 srn.com.1045 > 172.21.32.83.113: S
405:405(0) win 8192
06:42:08 srn.com.1167 > 192.168.83.15.113: S
233:233(0) win 8192
06:44:09 srn.com.1280 > 192.168.162.67.13: S
76:761(0) win 8192
Network Mapping
Using Reverse IDENT
If you know a specific process is running on a system
you can find out the username that owns the process.
Nmap has an option to scan for identd, authd port 113 TCP defined by RFC 1413. This is sometimes referred to as a
reverse ident scan. The word reverse is based on the fact that the normal and expected behavior of ident is:
Client computer A wants to talk to a service on server B, so A sends a packet with the SYN flag set. This is normal
for all communications, but the wrinkle is before B says OK, I will talk with you and acknowledges As SYN with a
SYN/ACK, B may want to find out if A is legitimate. So B, the server, sends a packet to port 113 on A. After the 3
way handshake is complete in reverse, the Server interrogates the Client for its process ID. Only after getting this
information, does the Server B allow the original connection to continue. The primary services that are likely to
require identd are IRC port 6667 and sendmail port 25.
A SYN B Port 25
Identd Process
Port 113 A SYN B
A SYN/ACK B
A ACK B
Resume Original Connection
A SYN/ACK B
A ACK B
Nmap and other tools can take advantage of listening systems on port 113 and collect a small amount of
reconnaissance information including the process ID. This is called a reverse identd scan because there was no
initiating activity by the client.
10 - 34
Intrusion Detection in-Depth - SANS 2003 34
Network Mapping
Using TCP Reset Packets
02:58:05 srn.com.25984 > 172.30.69.23.2271: R 0:0(0) ack
674719802 win 0
02:59:11 srn.com.50620 > 172.16.7.158.1050: R 0:0(0) ack
674719802 win 0
02:59:20 srn.com.19801 > 192.168.184.174.1478: R 0:0(0) ack
674719802 win 0
02:59:31 srn.com.7960 > 192.168.242.139.1728: R 0:0(0) ack
674719802 win 0
03:00:58 srn.com.35124 > 192.168.182.171.1626: R 0:0(0) ack
674719802 win 0
Result:
03:00:58 router.net > srn.com: icmp: host 192.168.182.171
unreachable
The attacker is sending Reset packets to close connections
that were never established.
This slide shows a reset scan. They make a wonderful scan, because so many resets occur naturally
on the Internet, that if an attacker is patient enough, the scan is nearly undetectable.
How does the reset scan work? The reset scan and many other scans rely on ICMP to help them with
their mapping. In this case, a packet is sent by srn.com and we see the RESET flag is set. Under
many circumstances there will be no reply. However, if the host or network does not exist and the
packet is not blocked before it reaches a helpful router, the router will send back information via
ICMP that the target is unreachable. To help you remember this technique, just think about A
Streetcar Named Desire and Blanches famous line, Ive always relied on the kindness of routers.
To summarize, this technique works when you have a helpful router and the target does not exist.
There are a class of these techniques. For instance, another fun one is to send replies to DNS queries
that were never asked. This only works when the host doesnt exist. Since the attacker is mapping
the holes in the network, this is called inverse mapping. After you find as many hosts that dont exist
as possible, you take the converse of the map and, voila!
One last important point: these techniques, the half opens, and a whole slew of other broken TCP
state techniques, utterly and totally fail when applied against sites with private internal addresses, an
application or proxy firewall with network address translation and split DNS. There is a big push
these days for less filtering so we can go faster and watch streaming DVD at our desktops. Keep in
mind there is a cost to having your site more open to the Internet. Call me conservative, but I still
find great comfort in the proxy firewalls.
10 - 35
Intrusion Detection in-Depth - SANS 2003 35
Stealthy Network Mapping
Faking a DNS Response
07:36:32.713298 stealth.com.domain > 172.29.185.48.54358: udp
07:57:01.634613 stealth.com.domain > 254.242.221.165.13043: udp
09:55:28.728984 stealth.com.domain > 192.168.203.163.15253: udp
10:38:53.862779 stealth.com.domain > 192.168.126.131.39915: udp
10:40:37.513176 stealth.com.domain > 192.168.151.126.19038: udp
10:44:28.462431 stealth.com.domain > 172.29.96.220.8479: udp
11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp
Stimulus-Response Pair
11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp
11:35:40.489523 router.mynet.net > stealth.com:
icmp: host 192.168.7.246 unreachable
The attacker is sending responses to questions that were never posed.
client server
Port X
Port 53
query
response
Normal DNS Query
There are a variety of techniques that rely on the kindness of ICMP to inverse map a site. In this
example, the replies to DNS questions that were never asked are used to probe the network. The final
two entries show a stimulus-response pair; the attacker sends a DNS reply to 192.168.7.246.
router.mynet.net responds to the attacker with an ICMP host unreachable message.
This technique can be use for inversely mapping UDP ports as well. Some sites will allow DNS
responses through a packet-filtering device that is not stateful. A non-listening port on a live host
will generate an ICMP port unreachable message.
10 - 36
Intrusion Detection in-Depth - SANS 2003 36
18:32:21.050033 A > B.71: (frag 9019:480@552)
18:32:21.109287 A > B.72: (frag 9275:480@552)
18:32:21.178342 A > B.73: (frag 9531:480@552)
18:32:21.295332 A > B.74: (frag 9787:480@552)
18:32:21.344322 A > B.75: (frag 10299:480@552)
18:32:21.384284 A > B.76: (frag 10555:480@552)
18:32:21.431136 A > B.77: (frag 11067:480@552)
18:32:21.478246 A > B.78: (frag 11579:480@552)
18:32:21.522631 A > B.79: (frag 11835:480@552)
When an IP fragment is sent to a host that doesnt exist,
the router will reply with an ICMP host unreachable.
Stealthy Network Mapping
Using Fragmented IP Datagrams Without Zero Offset
In this trace, we see that fragmented IP datagrams are being sent very quickly to many different hosts.
What makes this scan interesting is that the only fragments being recorded are starting at offset 552;
none of the fragments start at offset 0.
This is an example of the expected behavior of a fragment:
01:25:42.074775 A > B: icmp: echo request (frag 21552:552@0+)
01:25:42.154898 A > B: (frag 21552:156@552)
Note the 552@0+ in the first line, which indicates that:
The fragment starts at offset 0
There should be more chunks of data following
The fragment has 552 bytes of data
So the next fragment should start at offset 552 (offset 0 + 552 bytes of data). We then see 156@552
in the second line, which indicates that:
The fragment starts at offset 552
There should be no more fragments after this one
The fragment has 156 bytes of data
Please also note that both fragments have the same fragment ID, in this case 21552.
Now compare this example of proper fragmentation with the examples in the slide. The fragments in
the slide all start at offset 552, but there are no other fragments. The motivation for doing a scan with
fragments is that the receiving system may not log individual fragments, only whole packets after all
fragments have been received.
10 - 37
Intrusion Detection in-Depth - SANS 2003 37
00:59:17 m4trix> 172.20.179.41: icmp: echo reply
00:59:17 router> m4trix: icmp: host unreachable
02:11:50 m4trix> 172.20.54.94: icmp: echo reply
02:11:50 router> m4trix: icmp: host unreachable
02:55:14 m4trix> 172.20.135.88: icmp: echo reply
03:45:36 m4trix> 172.20.54.116: icmp: echo reply
03:45:36 router> m4trix: icmp: host unreachable
03:51:00 m4trix> 172.20.191.0: icmp: echo reply
03:51:00 router> m4trix: icmp: host unreachable
04:05:27 m4trix> 172.20.9.57: icmp: echo reply
06:52:49 m4trix> 172.20.205.83: icmp: echo reply
07:38:45 m4trix> 172.20.134.25: icmp: echo reply
This scan is penetrating the proxy firewall since it allows
echo replies in.
Echo Reply Inverse Scan
The scan depicted on this slide is one of the best stealth scans we have seen yet. Consider the slow
scan rate; it will probably evade scan detection software. Also note that most sites do not block
incoming echo replies. To do so would cause outgoing pings to fail, which would be unpopular.
This scan will work in a wide variety of environments.
This is yet another example of inverse mapping, of course.
10 - 38
Intrusion Detection in-Depth - SANS 2003 38
00:16:44.700238 srn.org.137 > 256.38.161.3.137: udp 50
00:16:44.700660 rt1-4.nnnn.arpa.net > srn.org: icmp: host
256.38.161.3 unreachable
00:16:46.204074 srn.org.137 > 256.38.161.3.137: udp 50
00:16:46.204393 rt1-4.nnnn.arpa.net > srn.org: icmp: host
256.38.161.3 unreachable
00:16:47.707683 srn.org.1141 > 256.38.161.3.snmp:
GetNextRequest(37)E:326.2.2.2.2.5[|snmp]
00:16:47.708131 rt1-4.nnnn.arpa.net > srn.org: icmp: host
256.38.161.3 unreachable
00:16:48.507295 srn.org.1141 > 256.38.161.3.snmp:
GetNextRequest(37)E:326.2.2.2.2.5[|snmp]
00:16:48.507694 rt1-4.nnnn.arpa.net > srn.org: icmp: host
256.38.161.3 unreachable
Wrong Number?
In this example, we have no idea what is going on. Shadow recommends that sites block SNMP
(161). So it is certainly true that we shouldnt be seeing this detect. However, not all strange things
are the result of malevolent intent. Shadow analysts have to make a call using their instincts and
training as to which detects to report. In this case, we decided this was just a wrong number.
10 - 39
Intrusion Detection in-Depth - SANS 2003 39
These were grouped together because they are the same
type of probe. These are very rare.
date time source IP src port dest IP dest port
05/25/98 16:17:28 198.147.103.2 68 256.168.103.2 67 udp
05/27/98 09:34:35 168.51.216.35 57864 256.38.0.0 67 udp
BOOTP: 67 UDP Server, 68 UDP for Client (not an
ephemeral port)
Bootp (Bootstrap Protocol) Probe
We go months without a bootp probe, and then we get a couple of them fairly close together in time.
As we accumulate more data, one of the analysis tasks we want to undertake is trying to figure out
who works with whom certain pairs or groups of IP addresses that show the same pattern of
activity.
Note that if a bootp attempt is successful, the attacker gets the information that is often found in
local/var/bootfiles/some_name.
10 - 40
Intrusion Detection in-Depth - SANS 2003 40
TCP Discard
08:02:35 dscrd.net.268 > 192.168.160.122.9: S
1797573506:1797573506(0) win 16384 (DF)
08:02:38 dscrd.net.268 > 192.168.160.122.9: S
1797573506:1797573506(0) win 16384 (DF)
Discard is not likely to be logged or protected, but it can certainly be used for mapping. The attacker
is testing for reset packets, which would indicate an inactive port, or ICMP unreachable messages.
This particular scan would try four SYN packets to TCP port 9 on each host; then it would move on
to the next host.
10 - 41
Intrusion Detection in-Depth - SANS 2003 41
UDP Discard
10:35:13 10.7.8.130.1755 > 10.9.8.38.9: udp 1025
(frag 24735:552@0+)
10:35:13 10.7.8.130 > 10.9.8.38:
(frag 24735:481@552)
10:35:29 10.7.8.130.1760 > 10.9.8.38.9: udp 1025
(frag 50079:552@0+)
10:35:29 10.7.8.130 > 10.9.8.38:
(frag 50079:481@552)
Probable mapping; goal is to elicit ICMP port unreachable
Detect and analysis by Stephen Pohler, GCIA:
* Similar fragment patterns:
- Legal' fragments - in that they will reassemble
- Fragment ids match and offsets align properly
- A first fragment with the more fragments bit set and then a final fragment
- According to TCP/IP Illustrated v1, all fragments except the final fragment must
be on an 8-byte boundary (552 / 8 = 69; so it is on an 8-byte boundary)
* Odd number of packets from each server:
- First packet from each server is always the 481@552 offset of the fragment
* udp size of the packets are all the same:
- Also, in the first packet, the 552 bytes of IP data minus the 8-byte UDP header is 544 bytes of udp
data, and the final fragment is 481 bytes of data481 + 544 = 1025; which is the correct udp data
size
10 - 42
Intrusion Detection in-Depth - SANS 2003 42
Customized Web Content
07:36:55.73 ad.pref.14363 > firewall.22: S
14974:14974(12) win 65535 (DF)
07:37:21.80 media.pref.58521 > firewall.22: S
14022:14022(536) win 65535 (DF)
07:37:53.63 media.pref.24463 > firewall.22: S
18985:18985(536) win 65535 (DF)
07:38:00.61 media.pref.28349 > firewall.119: S
9899:9899(536) win 65535 (DF)
Two days later:
10:48:00.61 media.pref.26649 > firewall.80: S
9679:9678(536) win 65535 (DF)
In the noise of supplying web content, the provider is
testing for open ports on the firewall
Normally, we should see clients from our side (firewall) initiating connections to external web
servers such as ad.pref and media.pref. However, in this case, we not only see the web servers
initiating traffic to our site, but they are attempting to establish connections on ports such as 22 (SSH)
and 119 (NNTP). Its very interesting to see traffic attempting active opens against the firewall.
A day or two after the first scan occurred, malformed packets from multiple locations hit the target
firewall. They originated first from the scanning service provider and then from other locations.
Such malformed packets are rare, but they do occur. To have so many on a single day is way outside
of coincidence.
10 - 43
Intrusion Detection in-Depth - SANS 2003 43
Confirming Snort Detection
Mar 18 03:57:54 tempest snort: [1:0:0] IDS296/web-misc_http-
whisker-splicing-attack-space [Classification: suspicious
miscellaneous traffic] [Priority: 1]: {TCP} 218.62.92.153:4767 -
> 195.82.120.100:80
Mar 18 03:57:54 tempest snort: [1:0:0] IDS243/web-cgi_http-cgi-
pipe [Classification: system integrity attempt] [Priority: 11]:
{TCP} 218.62.92.153:4767 -> 195.82.120.100:80
210.52.79.148 - - [16/Jan/2003:15:34:24 +0000] "GET
/data/snort_daily.html HTTP/1.0" 200 41567 "-" "libwww-
perl/5.21"
Detect and analysis by Arrigo Triulzi
For quite some time (since June 2001), I've been placing my logs on the web for IDS researchers and SANS
students to use. In particular as an extra bonus I process my daily logs with a small Perl script which produces
HTML for me to post. The data which is produced by the script is a good representation, relatively easy to
browse and search. I am personally fond of the section with the distribution of attack methods which I always
read first as it gives me a good handle on the overall picture.
One of the ideas which has always been drilled into me, in particular by Stephen Northcutt has been that of "log
fusion". There is a lot of value in looking at logs in context and attempting to combine information from, say,
Apache, Squid, Sendmail and your IDS (not to mention syslog, of course). In particular this technique is perfect
for rooting out false positives concerning web traffic, the best example being the good ol' 3DNS "attacks" which
compared against Squid logs become load-balancing attempts after a web request.
Now, who says that you cannot apply "log fusion" in the opposite direction? I've recently been comparing the
web accesses to the daily Snort data with attacks and suddenly my heart jumped: in the list of attacks I had sites
with source addresses which matched exactly the source address of hosts checking the daily log the following
day!
What happened? Well, very simple really: if you had developed a new attack and wanted to test it against a set of
Snort rules to see if it was detected you would probably run it on a small private segment. But what about
modified Snort rulesets? So you search the web with Google and you fall upon my site which not only publishes
daily Snort logs but also the rules being used. What follows is that you try your attack against my web site on the
assumption that the Snort sensor is there. Then you check the following day to see how much of it was detected.
Not bad at all: free remote verification!
10 - 44
Intrusion Detection in-Depth - SANS 2003 44
Intrusion Detection Systems (and
their operators) tend to be focused
on incoming traffic. It pays to
consider outgoing traffic as well.
Outgoing Packets
In many organizations, the purpose of perimeter security primarily routers, firewalls and intrusion
detection systems is to filter and scan incoming traffic. However, no attention is given to outgoing
traffic. Some of the reasons why you should at least consider monitoring your outgoing traffic are:
- Someone on your internal network may be launching attacks against other organizations. This
could be a member of your organization, a visitor, or an unauthorized person who has gained physical
access to your systems. Or it could be
- An attacker who has entered your network without passing through your Internet routers and
firewalls (for example, through unsecured modems). You may not know that the system has been
compromised, but if you are monitoring outgoing traffic, you may see the system launching attacks
against other systems or initiating contact with the external attacker.
- An internal machine could have a Trojan, which may be initiating contact with its external master.
- It is not possible to examine traffic from a stimulus-response standpoint if you are only examining
half of the conversation. If you see some strange incoming packets, but you havent been paying
attention to the outgoing packets, how can you determine if these packets are a response to a request
from your systems, or if they are unsolicited?
10 - 45
Intrusion Detection in-Depth - SANS 2003 45
11:56:45.894653 borg.2049 > 207.46.130.165.http:
S 637662720:637662720(0) win 16616 <mss 1460,wscale 0,eol> (DF)
4500 0030 bdae 4000 ff06 cd09 **** ****
cf2e 82a5 0801 0050 2601 f600 0000 0000
7002 40e8 2ed5 0000 0204 05b4 0303 0000
This is a Macintosh (borg) calling to Microsoft. No data
(other than borgs IP address) gets passed to Microsoft.
Microsoft Word
This is a final example of reconnaissance, but its quite different from the others that we have
reviewed. This packet was captured as it was going from a users Macintosh to Microsoft. The
Macintosh had Microsoft Word on it, and some research determined that this packet was triggered by
Microsoft Word.
So why is this considered reconnaissance? Well, the packet is transmitting the IP address of the
Macintosh to Microsoft. Folks who have spent a lot of money developing a Network Address
Translation scheme arent going to be very pleased about the hosts IP address being passed as data.
10 - 46
Intrusion Detection in-Depth - SANS 2003 46
Inferring Outbound Traffic
From Inbound ICMP Errors
12:58:47.697873 216.191.229.53 > 172.16.248.252: icmp:
time exceeded in-transit
12:58:47.828249 205.235.142.158 > 172.16.248.252:
icmp: time exceeded in-transit
12:58:47.858500 206.248.221.49 > 172.16.248.252: icmp:
host 129.97.175.143 unreachable - admin prohibited
filter
12:58:47.918470 200.220.72.126 > 172.16.248.252: icmp:
host 129.222.48.106 unreachable - admin prohibited
filter
Unreachables reflect failed outbound attempts.
The above slide has a small excerpt of traffic sent to an internal host 172.16.248.252. As you can tell
from the timestamps of the records above, many ICMP unreachable error messages were sent in a
very small amount of time. These ICMP messages are coming from many different IPs presumably
representing routers that sent the messages.
There are two possible conclusions here. The first is that someone may be spoofing your host IP
172.16.248.252 and sending traffic to many different destinations. The second possibility is that if
172.16.248.252 is an actual live host, it may be infected and searching for other victims. This is the
type of activity that may be seen from any malware that uses a pseudo-random number generator to
search for other victims. This is how Nimda that would look for other hosts to infect.
Detect and guidance from George Bakos.
10 - 47
Intrusion Detection in-Depth - SANS 2003 47
Compromised Telnet Server
10.10.102.182.2828 > 206.132.179.136.21: S 809165349:809165349(0) win
512
206.132.179.136.21 > 10.10.102.182.2828: S 3182517100:3182517100(0) ack
809165350 win 17520 (DF)
10.10.102.182.2828 > 206.132.179.136.21: . ack 1 win 512
206.132.179.136.21 > 10.10.102.182.2828: P 1:101(100) ack 1 win 17520

USER dadropsit
PASS amdhax0r

RETR warez.tar
QUIT
The excerpt of traffic and annotations above represent a compromised telnet server, 10.10.102.182.
This particular host offered up telnet, yet was not known to see outbound traffic. That is until it
was compromised one day and outbound traffic was captured going to an FTP server,
206.132.179.136.
Interesting enough, the tcpdump captured enough of the payload to see what is going on. It looks
like the attacker logs on to the FTP server. The password amdhax0r seems to indicate that he/she
may be affiliated with the hacking group AMD who have produced a number of exploits such as an
infamous one known as ADMROCKS that took advantage of a buffer overflow in BIND. The
hacker is retrieving a tarball named warez presumably all the code he or she will need to totally
customize the hacked telnet server.
Credit to George Bakos for the detect.
10 - 48
Intrusion Detection in-Depth - SANS 2003 48
Compromised Telnet Server (2)
10.10.102.182.2647 > 199.3.235.130.6667: S
2335338658:2335338658(0) win 512
199.3.235.130.6667 > 10.10.102.182.2647: S
4291582374:4291582374(0) ack 2335338659 win 17520 (DF)
10.10.102.182.2647 > 199.3.235.130.6667: P 1:11(10) ack
1 win 32120 (DF)
199.3.235.130.6667 > 10.10.102.182.2647: P 1:46(45) ack
1 win 17520 (DF)
199.3.235.130.4092 > 10.10.102.182.113: S
4291746152:4291746152(0) win 16384 (DF)
10.10.102.182.113 > 199.3.235.130.4092: S
2816500854:2816500854(0) ack 4291746153 win 32736
The FTP downloads from the compromised telnet server was not the only outbound activity captured.
Later on, the hacker decided to visit a known IRC server on host 199.3.235.130. Here is a
description of the activity by the system administrator:
Here, the lamer tried to connect to an IRC server with nick root. Then, after fixing that, he failed to
shut down the identd, or use a non-privileged account, so we had a few more boot-offs.
You can see the identd traffic as the IRC server 199.3.235.130 attempts to contact the compromised
telnet host on port 113.
If you know that you have a server that initiates no outbound sessions, you could have some kind of
sniffer or rule that looks for outbound initial SYN traffic from that server. That should alert you that
something wrong or unusual is occurring.
Detect and explanation by George Bakos.
10 - 49
Intrusion Detection in-Depth - SANS 2003 49
Summary
Reconnaissance techniques
Host scanning
Network mapping
Subtle and stealthy
To summarize this section, we have studied three types of reconnaissance techniques. Host scanning
involves searching for one or a few services on a number of hosts. Network mapping uses probes to
determine the IP addresses that are in use. Finally, subtle and stealthy scans are usually low and
slow, designed to blend in with legitimate traffic. Attackers will use any and all of these techniques
to gather reconnaissance information on your network and systems. And dont forget the value of
scrutinizing servers that do not initiate outbound traffic. This can help you discover compromised
servers in your network.
10 - 50
Intrusion Detection in-Depth - SANS 2003 50
Course Revision History
v4.0 S. Northcutt February 2001
v4.1 S. Northcutt June 2001, added tsig and 9704
v4.2 S. Northcutt August 2001 added 9876, expanded null session
v4.3 S. Northcutt January 2002 added reverse ident scan, Feb 19, 2002 removed duplicate trace
v4.4 S. Northcutt July 2002, removed archaic traces to make room earlier in course
v.4.4a edited/formatted by C. Tuttle July 9, 2002
v.4.5 J. Novak April 2003 per Stephens request, section reviewed and update. Most slides
have changed.