effective mapping technique because the attacker doesn't have to send many packets to

potentially collect a lot of information.

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]

FTP Bounce

We have another trace courtesy of the correlation database engine. In this case, the analyst is searching for FTP-DATA (TCP port 20) without an initiating FTP (TCP port 21). This can be the result of FTP bounce. The advantage to the attacker of using FTP bounce is that his identity is hidden. This is just like using an open proxy server, except that the source port will always show as TCP 20 for FTP-DATA. To do this, they just log on to a vulnerable FTP server as anonymous and open up arbitrary ports to probe the intended victim. This is not usually a very serious threat, unless the FTP server is a trusted host by its organization. Then, an attacker may be able to use the FTP server to probe the organization. FTP bounce is the subject of a

CERT advisory, which you can find at www.cert.org/ftp/cert_advisories/CA-97.27.FTP_bounce.

In some implementations of FTP daemons, the PORT command can be misused to open a connection to a port of the attacker's choosing on a machine that the attacker could not have accessed directly. There have been ongoing discussions about this problem (called "FTP bounce") for several years, and some vendors have developed solutions for this problem. When we uncovered the traffic in the following trace, we went back to prober and it was an FTP

server, it supported anonymous FTP, and we were able to use the port command as advertised. The interesting thing is this trace was detected long before going to unknown ports became a fad. The following trace represents all the connections from prober to the protected network

(172.20.152):		source IP	src port dest IP		dest port
date	time
04/27/98	10:17:31	prober	20	172.20.152.2	3062	t
04/27/98	10:27:32	prober	20	172.20.152.2	4466	t
05/06/98	06:34:22	prober	20	172.20.152.2	1363	t
05/06/98	09:12:15	prober	20	172.20.152.2	4814	t
05/06/98	09:15:07	prober	20	172.20.152.2	1183	t
05/06/98	10:11:30	prober	20	172.20.152.2	1544	t

NetBIOS-Specific Traces

This section examines some traces that appear to be targeted at Windows systems. NetBIOS uses 135–139 TCP and UDP. It is certainly true that other systems than Windows use NetBIOS (SAMBA, for example), but as a general rule NetBIOS traffic can be expected to be generated

by and targeted against Windows systems.

A Visit from a Web Server

One of the characteristics of NetBIOS is that traffic to destination port UDP 137 is often caused by something a site initiates. If you send email to a site running Microsoft Exchange, for example, the site will often send a port 137 attempt back. The following trace turned up because we saw 137s and then we started searching for the cause factor. To find the answer, we pulled all traffic for jellypc and found the web access. Then, we did the same for jampc and it was the same pattern. Being able to pull all the traffic for a host is very valuable when doing

analysis. If your IDS does not support this, beat on your vendor!

Public Safety Announcement

Although this section focuses mostly on NetBIOS, let me take a minute to mention that there are hostile web servers on the Internet. When a system from your site visits a web server, that server can collect a lot of information about you, including your operating system and browser version. If your site doesn't use Network Address Translation (NAT), the web server will have your IP address. It is often possible to extract the web client's email address. Some sites open a connection back to the client and perform what we believe is TCP stack analysis. (And we haven't even discussed cookies.)

The web server in the jellypc trace wasn't satisfied with just the information it could collect from the HTTP headers; the server wanted more, so another system from the same subnet comes back to the hosts that visited the web server to collect the information available from the

NetBIOS Name Service.
Here is the pattern:	jellypc.arpa.net 1112 -> www.com		http
12/02/97 08:27:18				137
12/02/97 08:27:19	0 bill.com	137 -> jellypc.arpa.net
12/02/97 17:06:03	jampc.arpa.net 2360 -> www.com		http	137
12/02/97 17:08:10	0 bill.com	137 -> jampc.arpa.net

I got on the phone and had a great chat with a technical type who runs the network there. It turns out that they are using a piece of commercial software for marketing purposes that creates a comprehensive database of your likes and dislikes.

If you want to see what kind of information is available about a particular Microsoft Windows host, the command is called nbtstat and it runs on Windows NT systems. A Windows host that

runs NetBIOS cannot refuse to answer an nbtstat. A sample trace is shown here:

C:\>nbtstat -a goo

NetBIOS Remote Machine Name Table

Name Type Status

---------------------------------------------

Registered Registered Registered

MAC Address = 00-60-97-C9-35-53

GOO	<20>	UNIQUE
GOO	<00>	UNIQUE
KD2	<00>	GROUP
KD2	<1C>	GROUP
KD2	<1B>	UNIQUE
GOO	<03>	UNIQUE
SRN0RTH	<03>	UNIQUE
INet~Services	<1C>	GROUP
IS~GOO	<00>	UNIQUE
KD2	<1E>	GROUP
KD2	<1D>	UNIQUE
..__MSBROWSE__.<01>		GROUP

The NetBIOS name of my machine, Goo, can be picked up as well as my workgroup, KD2. The logon name I use on that machine is srnorth. It is also possible to determine that I have a master browser cookie.

Perhaps this application of the wildcard request doesn't concern you, but I have been able to use nbtstat queries to determine an entire organizational structure as well as most of the logon names.