Intelligence Gathering Techniques
By Stephen Northcutt
Chapter 8 from Network Intrusion Detection: An Analyst's Handbook, published by New Riders Publishing
In Chapter 3,"Architectural Issues," we raised the issue that CIRTs have to focus primarily on compromised systems. And they do! How would you feel if you were on the phone with your CIRT trying to get information you need to deal with the latest nasty Trojan horse code, and they said, "Sorry, we are devoting all our resources to a new intelligence gathering technique"?
The wise intrusion analyst will devote a lot of attention to the prevention, detection, and reporting of mapping techniques. They know that recon is just part of the game. As attackers amass high-quality information about the layout of networks and distribution of operating systems, they allow themselves to specifically target their attacks. You do not want to allow your organization to get in a one exploit, one kill situation!
The line between exploit/denial of service and recon probe couldn't be thinner. Any exploit that fails (or succeeds) also provides intelligence about the target.
This chapter contains many traces showing information gathering techniques. We will consider some of the ways an attacker might map the network and its hosts. We will take a short look at NetBIOS-specific issues since there are so many deployed Windows systems, and finally examine some of the so-called "stealth" mapping techniques.
On This Page
Network and Host Mapping
NetBIOS Specific Traces
Stealth Attacks
Summary
Network and Host Mapping
The goal of host mapping is simply to determine what hosts or services are available in a facility. In some sense, the odds are in the analyst's favor; we are defending sparse matrices. Suppose you have a class B network, 172.20.0.0—that is 65,536 possible addresses. There are also 65,536 TCP ports and 65,536 UDP ports. That means that the attacker has in excess of 23 trillion possible targets. Scanning at a rate of 18 packets per second, it would take a shade under five million years to completely scan the network. Because computers have a life span of between three and five years, the rate of change confounds the usefulness of the scan.
Now to be sure, attackers are coming up with smarter and faster scanning techniques. There is no need for an attacker to consider all possible port numbers. Fifty TCP and UDP ports will account for all the probable services, so the target space is something in the range of 163 million, which could be scanned in less than four months at 18 packets per second. Hmmmm, that is achievable! And if the site doesn't have intrusion detection, the site owners will probably never know if the attacker's scan randomizes the addresses and ports a bit.
But if the attackers can get an accurate host map, they can turn the tables on those of us who defend networks. Many address spaces are lightly populated. If the attacker is able to determine where the hosts are, they have a serious advantage. Say our class B network was populated with only about six thousand computers and the attacker can find them. Now, the attacker can scan the populated hosts on the net, at 18 packets per second, in less than ten days—and there still are much more efficient ways to do the scan. In fact, if we allow ICMP echo request broadcasts, they can ping map our network with only 255 packets.
The point of the story is obvious. If attackers are not able to get intelligence information about our site, they are forced to guess about a very sparse matrix. If we do let their intelligence-gathering probes succeed, then they don't have to do much guessing at all different.
So how could an attacker get such an accurate host map? Many sites still make a "host table" available for FTP download. Other sites allow DNS Zone transfers. Or perhaps the attacker will have to work to discover this information with host scans.
Crude ICMP Host Scan
If a site does not block ICMP echo requests, then the attacker can simply ping each address. This tends to be an older approach to mapping. This scan is fairly slow, and the scanner could be scanning multiple addresses, but it is still fast enough that a scan detector ought to catch it.
01:00:38.861865 pinger.mappem.com > 192.168.6.1: icmp: echo request 01:00:51.903375 pinger.mappem.com > 192.168.6.2: icmp: echo request 01:01:04.925395 pinger.mappem.com > 192.168.6.3: icmp: echo request 01:01:18.014343 pinger.mappem.com > 192.168.6.4: icmp: echo request 01:01:31.035095 pinger.mappem.com > 192.168.6.5: icmp: echo request 01:01:44.078728 pinger.mappem.com > 192.168.6.6: icmp: echo request 01:01:57.098411 pinger.mappem.com > 192.168.6.7: icmp: echo request
Host Scan Using UDP echo Requests
In the trace below, the attacker is targeting multiple network addresses. Two were detected by this sensor constellation, but it is probable that there were many more. By interleaving the scan, the attacker has managed to space the UDP echo requests far enough apart that the probe will not be detected by most scan detect codes. The scrambled addresses are also a nice touch. The "udp 6" refers to UDP payload with six bytes of data. As we will see in the last section in this chapter, stealth in intrusion detection has a fairly specific meaning, but I consider the low and slow approach the best stealth technique.
02:08:48.088681 slowpoke.mappem.com.3066 > 192.168.134.117.echo: udp 6 02:15:04.539055 slowpoke.mappem.com.3066 > 172.31.73.1.echo: udp 6 02:15:13.155988 slowpoke.mappem.com.3066 > 172.31.16.152.echo: udp 6 02:22:38.573703 slowpoke.mappem.com.3066 > 192.168.91.18.echo: udp 6 02:27:07.867063 slowpoke.mappem.com.3066 > 172.31.2.176.echo: udp 6 02:30:38.220795 slowpoke.mappem.com.3066 > 192.168.5.103.echo: udp 6 02:49:31.024008 slowpoke.mappem.com.3066 > 172.31.152.254.echo: udp 6 02:49:55.547694 slowpoke.mappem.com.3066 > 192.168.219.32.echo: udp 6 03:00:19.447808 slowpoke.mappem.com.3066 > 172.31.158.86.echo: udp 6
Broadcast ICMP
Broadcast ICMP is the single most common mapping technique in use. It is also very effective. If nothing else in this book has convinced you to campaign vigorously for your site to block incoming ICMP echo requests, this ought to do it! I can't remember going a week without at least one detect of this pattern.
00:43:58.094644 pinger.mappem.com > 192.168.64.255: icmp: echo request 00:43:58.604889 pinger.mappem.com > 192.168.64.0: icmp: echo request 00:50:02.297035 pinger.mappem.com > 192.168.65.255: icmp: echo request 00:50:02.689911 pinger.mappem.com > 192.168.65.0: icmp: echo request 00:54:56.911891 pinger.mappem.com > 192.168.66.255: icmp: echo request 00:54:57.265833 pinger.mappem.com > 192.168.66.0: icmp: echo request 00:59:52.822243 pinger.mappem.com > 192.168.67.255: icmp: echo request 00:59:53.415182 pinger.mappem.com > 192.168.67.0: icmp: echo request
A Word About Detecting Scans
Until some brilliant researcher comes up with a better technique, scan detection will boil down to testing for X events of interest across a Y-sized time window. An intrusion detection system can and should have more than one scan detect window. For instance, we have seen several scans that exceed five events per second. By using a short time window in the range of one to three seconds, the system can detect a high-speed scan and alert in near real time, three to five seconds after the scan begins. Nipping such scans in the bud is one of the best uses of automated reaction. The next reasonable time window is on the order of one to five minutes. This will detect slower but still obvious scans. The Shadow intrusion detection system has had some success with a scan detect of five to seven connections to different hosts over a one hour window. At a later date, they employed scan detect code for a 24-hour time window in order to investigate the TCP half-open scans that are plaguing the Internet. These half-open scans are detailed in the stealth section of this chapter. Scans have also been detected using database queries with rates as low as five packets over 60 days. A scan rate that low would make sense only if it was interleaved (executed in parallel from multiple source addresses) to the extreme. More on that later!
This example may appear to be similar at first glance to smurf. In contrast to the smurf attacks, the broadcast echo requests here 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.
As we discussed in Chapter 6, "Detection of Exploits," the zero is an archaic broadcast; UNIX and other systems will often still answer it. Windows systems will not; they will answer the 255 broadcast. This allows the attacker to distinguish between types of systems.
Netmask-Based Broadcasts
Which of the echo requests in the trace below are broadcasts? All of them! We all recognize the 0 and the 255, but they are all broadcast packets under the right conditions, and the point of this trace is to test for these conditions. What are these "right conditions?" They are networks that have a different subnet mask than the usual one.
02:21:06.700002 pinger> 172.20.64.0: icmp: echo request 02:21:06.714882 pinger> 172.20.64.64: icmp: echo request 02:21:06.715229 pinger> 172.20.64.63: icmp: echo request 02:21:06.715561 pinger> 172.20.64.127: icmp: echo request 02:21:06.716021 pinger> 172.20.64.128: icmp: echo request 02:21:06.746119 pinger> 172.20.64.191: icmp: echo request 02:21:06.746487 pinger> 172.20.64.192: icmp: echo request 02:21:06.746845 pinger> 172.20.64.255: icmp: echo request
Network Classes
There are network classes A—E. We will primarily be concerned with A, B, and C. In the sidebar on broadcasts based on RFC 919 from Chapter 7, "Denial of Service," we read: For example, 36.0.0.0 means "network number 36" while 36.255.255.255 means "all hosts on network number 36."
36.0.0.0 is a class A network. Only the first byte of the four bytes that are used to define an Internet address is required to denote the network (NETID). The remaining three bytes (or 24 bits) define the host address (HOSTID). This means a class A address can have 224 or 16,777,216 different host addresses.
172.20.0.0 is a class B network. The first two bytes define the NETID and the second two bytes (16 bits) define the HOSTID. A class B address can have 216 or 65,536 different addresses.
192.168.1.0 is a class C network. In this case, the first three bytes define the NETID and only one byte (8 bits) is available for the HOSTID. A class C address can have 28, or 256 different addresses.
It is possible to manage the address space differently by changing the netmask. The netmask for 172.20.0.0 might be described as 255.255.0.0 This simply says 16 bits for NETID and 16 bits for HOSTID. However, the owner of a class B address space might wish to break it up into subnets. In this case, they may use a netmask of 255.255.255.0. Instead of 65,536 possible hosts, this would give them 256 possible subnetworks each with 256 possible hosts.
I once worked in a facility that charged for network addresses. A single host address was $50.00 per month, and a subnet with a netmask of 255.255.255.0, or 256 possible addresses, was $1000.00 per month. The facility had a class B address space assigned to it, 172.20.0.0, which they broke up into subnets. It turns out that if we bought a router and leased a subnet from them, we could bring our address space tax way down. Here is how:
Rent one subnet 172.29.15.0 for $1000.00 per month. The expected subnet mask would be 255.255.255.0. That gives us 256 possible addresses, but 0 and 255 are not usable for hosts, so that left 254 usable addresses. At $50.00 per month, that would be $12,700.00 per month, so getting the subnet for $1000.00 per month is already a big win. However, with our own router, we could make the subnet mask anything we wanted on "our" side of the router.
Suppose we could find three more small groups as cheap…er…frugal and ruggedly individual as we. We could use two bits of our address space for internal subnets to create four subnets with six bits of address space each. 26 is 64. The netmask for this is 255.255.255.192 or in hex, 0xffffffc0. We could each have our own subnet to do with as we please and split the $1000.00 per month for just a little more than the price of five individual addresses. Great, but what is the broadcast value for a subnet mask of 255.255.255.192?
255–192 = 63, which is the broadcast value for an "all ones" broadcast which means 0 or 64 is the value for an "all zeros." But if that is too easy:
c 0 in hex is 1100 0000 in binary. ^^ the two high order bits were lost to the NETID ^^ ^^^^ so we have 6 bits of host ID to play with
Six bits all set to ones = 32 + 16 + 8 + 4 + 2 + 1 = 63
Now the pattern we see in the trace below is an ICMP echo request to 0, 64, 63, 127, 128, 191, 192 and 255.
Could 127, 128 also be broadcasts? Sure, if we have a situation where we need lots of subnets; but each one can have a lower number of hosts if we can steal one bit from the HOSTID space and use it for subnets. If we use 25 bits for the NETID (33,554,432 possible subnets) each with seven bits of HOSTID space (128 possible addresses), then this would be a subnet mask of 255.255.255.128. What is the broadcast address?
255–128 = 127. 127 is the "all ones" broadcast.
Could 191, 192 also be broadcasts? If we have a situation where we need lots and lots of subnets but each one can have a low number of hosts, we can use 27 bits for the NETID (134,217,728 possible subnets) each with five bits of HOSTID space (32 possible addresses). This is a subnet mask of 255.255.255.64.255–64 = 191.
Of course, if we allow ICMP in, they could just send one packet with an ICMP netmask request and be done with it! If the site answers a netmask request, it will return the network mask that it is using, eliminating the guesswork.
Port Scan
Time for an easier trace. Below we have a basic port scan. Once our attacker has found a host, he might want to scan it to see what services are active. This trace is TCP, and the scan counts down on the destination port. The skips in the source ports are interesting. This may be a very busy machine, or there may be more than one scan going on. This is a good example of a bursty trace; compare the arrival times at the beginning of the trace to the end.
In the beginning of the trace, there is a lower number of packets arriving per second than at the end. Any number of factors can influence this, but if we can correlate this trace to other traces from other sensor systems, and they are also bursty, then we can make some assumptions about the source machine. The skipped source ports indicate that the source of the burstiness may be the source computer and not the network in between. If we can match up the source ports of our detect with a detect from another sensor, we might be able to make assumptions as to whether there are multiple scans going on or whether this scan is being initiated from a busy multiple-user computer.
09:52:25.349706 bad.guy.org.1797 > target.mynetwork.com.12: S 09:52:25.375756 bad.guy.org.1798 > target.mynetwork.com.11: S 09:52:26.573678 bad.guy.org.1800 > target.mynetwork.com.10: S 09:52:26.603163 bad.guy.org.1802 > target.mynetwork.com.9: S 09:52:28.639922 bad.guy.org.1804 > target.mynetwork.com.8: S 09:52:28.668172 bad.guy.org.1806 > target.mynetwork.com.7: S 09:52:32.749958 bad.guy.org.1808 > target.mynetwork.com.6: S 09:52:32.772739 bad.guy.org.1809 > target.mynetwork.com.5: S 09:52:32.802331 bad.guy.org.1810 > target.mynetwork.com.4: S 09:52:32.824582 bad.guy.org.1812 > target.mynetwork.com.3: S 09:52:32.850126 bad.guy.org.1814 > target.mynetwork.com.2: S 09:52:32.871856 bad.guy.org.1816 > target.mynetwork.com.1: S
Scanning for a Particular Port
So what service runs on TCP 7306? Durned if I know. This trace was collected in late December 1998, which was the beginning of a number of interesting scans that all seemed to be targeting strange ports. This scan is well crafted; there is no obvious signature.
The first and last packet in the following trace resolve to a hostname; the middle four don't. This can be an indication that the attacker is "shooting in the dark"— that they do not have an accurate network map. Often, a reason some names resolve is that they don't exist.
09:54:40.930504 prober.3794 > lula.arpa.net.7306: S 49684444:49684444(0) win 8192 (DF) 09:54:40.940663 prober.3795 > 192.168.21.20.7306: S 49684454:49684454(0) win 8192 (DF) 09:54:41.434196 prober.3796 > 192.168.21.21.7306: S 49684945:49684945(0) win 8192 (DF) 09:54:41.442674 prober.3797 > 192.168.21.22.7306: S 49684955:49684955(0) win 8192 (DF) 09:54:41.451029 prober.3798 > 192.168.21.23.7306: S 49684965:49684965(0) win 8192 (DF) 09:54:41.451049 prober.3776 > host.arpa.net.7306: S 49684211:49684211(0) win 8192 (DF)
Complex Script; Possible Compromise
The next trace we will examine is comprised of multiple individual probes and attacks. We show it in five parts. The accesses to portmap (sunrpc) imply that this attacker is attempting a compromise instead of simply gathering intelligence. Furthermore, the system answers back—and this is a bad thing. portmap should be blocked by the filtering router or firewall, and secure portmap code should be on any system that runs sunrpc. Note that these attacks are directed against two systems, host 16 and host 17. Based on the ports accessed, I make the assumption these are UNIX systems. It is quite possible that these two systems have a trust relationship so that if one falls, they both fall.
Then we see the access to TCP port 906, which is unassigned, and the target system answers back. This could be an indication that malicious code has been installed on the system. Yet instead of sending or receiving data, the attacker closes the connection. Two hours later, the attacker pings to see if the systems are still there.
00:35:33.944789 prober.839 > 172.20.167.16.sunrpc: udp 56 00:35:33.953524 172.20.167.16.sunrpc > prober.839: udp 28 00:35:33.984029 prober.840 > 172.20.167.17.sunrpc: udp 56 00:35:33.991220 172.20.167.17.sunrpc > prober.840: udp 28 00:35:34.046598 prober.840 > 172.20.167.16.906: S 2450350587:2450350587(0) win 512 00:35:34.051510 172.20.167.16.906 > prober.840: S 1996992000:1996992000(0) ack 2450350588 win 32768 (DF) 00:35:34.083949 prober.843 > 172.20.167.17.sunrpc: udp 56 00:35:34.089272 172.20.167.17.sunrpc > prober.843: udp 28 00:35:34.279472 prober.840 > 172.20.167.16.906: F 117:117(0) ack 69 win 32120 00:35:34.284670 172.20.167.16.906 > prober.840: F 69:69(0) ack 118 win 32768 (DF) 02:40:43.977118 prober > 172.20.167.16: icmp: echo request 02:40:43.985138 172.20.167.16 > prober: icmp: echo reply
Let's talk about response for a moment. We want to back up, investigate, contain, and clean. If these were my systems, I would direct you to do the following:
Take your hands off the keyboard and keep them off.
Pull the network cable immediately; we will be right there.
Once on the scene, one of your top priorities is to back up the system(s).
Treat the backup tape as evidence.
The port 906 bears further investigation. The easiest thing to do is bring a laptop and a small hub to the system you suspect might be compromised. Plug the laptop and one of the possibly compromised systems into the hub. Then load your own copies of system utilities (such as ls, ps, netstat) into a directory on the suspect system and set your path to that directory. From the laptop, telnet to the possibly compromised system on port 906. Run your versions of netstat and ps and such on the suspect system to see what is active. Also, examine the /.rhosts and /etc/hosts.equiv on the suspect system to see what other systems are trusted by our dynamic duo.
When you are finally satisfied you understand what is going on with port 906, the following is the best course of action unless you are totally certain the system was not compromised.
Turn to the system owners and ask when the last full backup was made. Make sympathetic clucking noises as they say never or two years ago and nod your head sadly. Look them in the eye and ask if there is any data that it is absolutely critical to save. Back up data files only, format the hard drive, and tell them to be sure to install all the appropriate security patches before putting the system back in business. Hook up your laptop to the local area net. Scan the local net for sunrpc and also for systems that answer on port 906, whatever else you have learned. Continue nuking from high orbit until the infection is sanitized.
Does this sound draconian? The death of a thousand cuts is far worse.
"Random" Port Scan
This scan was well on its way to setting a speed record. This is another early 1999 example of scanning ports that don't make any sense. There is no detectable signature; the purpose of the scan is unknown.
11:48:42.413036 prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) win 512 11:48:42.415953 prober.18987 > host.arpa.net.248: S 909993377:909993377(0) win 512 11:48:42.416116 prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) win 512 11:48:42.416279 prober.19032 > host.arpa.net.828: S 323265067:323265067(0) win 512 11:48:42.416443 prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0) win 512 11:48:42.556849 prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) win 512 11:48:42.560124 prober.19150 > host.arpa.net.228: S 1832011492:1832011492(0) win 512 11:48:42.560824 prober.19151 > host.arpa.net.840: S 3231869397:3231869397(0) win 512 11:48:42.561313 prober.19152 > host.arpa.net.1003: S 2435718521:2435718521(0) win 512 11:48:42.561437 prober.19153 > host.arpa.net.6: S 2632531476:2632531476(0) win 512 11:48:42.561599 prober.19165 > host.arpa.net.280: S 2799050175:2799050175(0) win 512 11:48:42.563074 prober.19166 > host.arpa.net.845: S 2065507088:2065507088(0) win 512 11:48:42.563115 prober.19226 > host.arpa.net.653: S 1198658558:1198658558(0) win 512 11:48:42.563238 prober.19227 > host.arpa.net.444: S 1090444266:1090444266(0) win 512 11:48:42.565041 prober.19274 > host.arpa.net.907: S 2414364472:2414364472(0) win 512
Okay, we don't know the purpose of the scan and that is frustrating. So as 'analysts' what do we know about this? We know it is fast and we know the source port behavior is unpredictable; sometimes it skips, sometimes it doesn't.
Why doesn't the trace make sense, and why in the world is someone scanning so many unknown ports? I am not sure that we will ever know the answer to this; in early 1999, there were a lot of odd scan patterns. The best guess I have is that someone was using nmap or a similar tool to craft scans that had no possible purpose, probably from spoofed source addresses.
That answers how, but not why! Here is a guess: To drive intrusion detection analysts crazy—to see what they would report and what they wouldn't. To see if the scanners could cause a CNN news report that the world was under some horrible new cyber attack. Granted, it is far-fetched, but it is the best I can come up with. How should the analyst react to this trace and other unknown, seemingly random scans? I do recommend reporting stuff like this because you never know what piece of information will help your CIRT. However, if your firewall is set to deny everything that is not specifically allowed and none of your hosts answer back, don't get stressed. The best idea is to create a directory named "ScansFromMars" and file these detects there.
Database Correlation Report
I am a strong fan of allowing the analyst to "fire and forget." That is, when they see a detect, to simply report it and move on. When we first started doing fairly large-scale intrusion detection (five sites, 12,000 computers or so), the analyst had to manually check all the sensors for correlations of source port, source IP, destination port, destination IP, and so on. Back then, if you were looking for something like correlation of a TTL field or some behavior of the sequence number, it might take days to sort it out.
Life is too short for that kind of madness. Once a pattern has been detected and reported, the database looks to see if there are any correlations. This is what such a report might look like. This report was generated by a military correlation system known as Dark Shadow. It is based on an Oracle database. When an analyst detects and reports an intrusion attempt, Dark Shadow checks for that pattern across its data window of x sensor locations for y months. If it finds a match, it creates a correlation report. This is why the analyst can operate in a fire-and-forget mode.
An Alternative Approach
One of this book's reviewers suggested the following response to a possible system compromise.
Alternatively, you could boot from a CD and mount the hard drive readonly noexecute. Perhaps removing the hard drive and mounting it readonly noexecute on another box (preferably a different platform), and doing the backup from there is a safer alternative. Also, the hard drive should be kept for evidence; if you need the data, get it from the backup.
Incident Handling
Please note that there is no way I can do justice to incident handling in a few paragraphs. Incident Handling Step-by-Step is a collaboration of over 90 incident handlers. It is available from https://www.sans.org.
Note that from the source ports, it appears that two processes are running (port 111 goes from 617-1023 and 25 goes from 2294-29419) on a scanner, one to check email and the other to check portmapper. The probability that this scan is interleaved across many more addresses is very high.
06/04/98 03:20:25 scanner 622 172.20.1.41 111 t 06/04/98 04:02:35 scanner 21091 172.20.1.1 25 t 06/04/98 04:02:36 scanner 890 172.20.1.1 111 t 06/04/98 04:06:04 scanner 21242 172.20.10.114 25 t 06/04/98 04:09:15 scanner 617 172.20.10.114 111 t 06/04/98 07:24:47 scanner 2295 192.168.229.18 25 t 06/04/98 07:28:06 scanner 1017 192.168.229.18 111 t 06/04/98 07:28:21 scanner 2333 172.20.1.41 25 t 06/04/98 07:31:40 scanner 729 172.20.1.41 111 t 06/04/98 12:46:21 scanner 20553 172.20.48.157 25 t 06/04/98 12:49:40 scanner 1023 172.20.48.157 111 t 06/04/98 16:05:22 scanner 29276 172.20.1.1 25 t 06/04/98 16:08:33 scanner 803 172.20.1.1 111 t 06/04/98 16:08:52 scanner 29419 172.20.10.114 25 t 06/04/98 16:08:53 scanner 900 172.20.10.114 111 t
SNMP/ICMP
The Simple Network Management Protocol (SNMP) can provide an attacker a lot of information about your hosts and network configuration. Port 161 TCP and UDP should be blocked from the Internet.
It is amazing how many devices, such as micro hubs, x-terminals, and printers, have SNMP agents. By default, these devices are protected by a password (community string) called "public." Many security-conscious organizations change this password, usually to one of:
Private
Internal
The name of the organization
Please forgive me if you thought I was serious—the choices of private, internal, or the name of the organization for SNMP community strings are not advised. Pick something hard to guess.
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]
In the trace above, notice the use of broadcast for both SNMP and ICMP. This is an effective mapping technique because the attacker doesn't have to send many packets to potentially collect a lot of information.
FTP bounce
We have another trace courtesy of the correlation database engine shown below. 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 the subject of a CERT advisory taken from https://www.cert.org/advisories/CA-1997-27.html.
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 trace below, 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 that this trace was detected long before going to unknown ports became a fad. The trace below represents all the connections from prober to the protected network (172.20.152).
date time source IP src port dest IP dest port 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
In the next section, we will examine some traces that appear to be targeted at Windows systems. NetBIOS uses 135–139 TCP and UDP. It is certainly true that systems other than Windows use NetBIOS; we have already mentioned samba, 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; for example, if you send email to a site running Microsoft Exchange, they will often send a port 137 attempt back. The following trace turned up because we saw 137s and then we started searching for the causing 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 of the traffic for a host is valuable when doing analysis. If your IDS does not support this, beat on your vendor!
The Web server in the jellypc trace below wasn't satisfied with just the information they could collect from the HTTP headers. They 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:
12/02/97 08:27:18 jellypc.nnnn.arpa.net 1112 -> www.com http 12/02/97 08:27:19 0 bill.com 137 -> jellypc.nnnn.arpa.net 137 12/02/97 17:06:03 jampc.nnnn.arpa.net 2360 -> www.com http 12/02/97 17:08:10 0 bill.com 137 -> jampc.nnnn.arpa.net 137
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 NT systems. A Windows host that runs NetBIOS cannot refuse to answer an NBTSTAT.
A sample trace is shown below:
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 login name I use on that machine is srnorth. It is also possible to determine that I have a master browser cookie.
Perhaps this 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 login names.
Null Session
A savvy attacker can collect a lot of information about the Windows systems in our organization if we allow port 137 queries through the firewall. But wait, there's more. Null sessioning has been described as analogous to the UNIX command finger. In essence, it is logging into a system as a nobody user. You can't do anything except learn about the system. A sample command prompt string is shown below:
net use \\172.20.244.164\IPC$ "" /USER:""
If the target host, 172.20.244.164, is vulnerable to null sessioning, this will generate literally pages of information, a section of which is shown below.
2/18/98 1:39 AM - Jsmith - \\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
Null sessioning can be prevented. My favorite source of information for NTs tends to be xforce; they tell me the problem and how to fix it, usually on a single screen. Because this is a dynamic subject, the best thing to do is go to the xforce Web page at https://www.iss.net/xforce/ and use the keyword search.
Public Safety Announcement
While this section is mostly about NetBIOS, let me take a moment to mention that there are hostile Web servers on the Internet. When a system from your site visits a Web server, they 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), they 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.
Stealth Attacks
The first time I heard the term "stealth" was in a paper by Chris Klaus titled Stealth Scanning—Bypassing Firewalls/SATAN Detectors. He was describing what people now usually refer to as "half open"; that is, intentionally violating the TCP three-way handshake. There are a number of variations of half-open scans, and we are going to examine all of the common ones. These are not all that hard to detect in and of themselves, but as we will learn in our discussion on coordinated attacks, they are getting some help. Nowadays, some folks use "stealth" to mean null flags (no flags or code bits set). The only approaches I find actually stealthy are those based on either low and slow, or highly distributed, packet delivery.
This is a season of advanced scans, attackers with the skill to type make are using tools that give them the look and feel of eleetness. A year ago it was jackal, now it is hping and nmap.
Nothing I have seen (despite the comment we will look at in a moment) penetrates a well-configured proxy-based firewall. None of the deception tools will elude a well-trained analyst with an IDS that collects all the traffic and has a supporting database. If your site has chosen a lesser path, you may be in for a wild ride as we learn about so-called "stealth attacks" (and coordinated and decoy attacks as well, in a later chapter).
As we get ready to launch into some traces of stealth techniques, please take a moment to read the opening comment from the jackal.c source code.
/* Jackal - Stealth/FireWall scanner. With the use of halfopen ports and sending SYNC (sometimes additional flags like FIN) one can scan behind a firewall. And it shouldn't let the site feel we're scanning by not doing a 3-way-handshake we hope to avoid any tcp- logging. Credits: Halflife, Jeff (Phiji) Fay, Abdullah Marafie. Alpha Tester: Walter Kopecky. Results: Some firewalls did allow SYN | FIN to pass through. No Site has been able to log the connections though.. during alpha testing. ShadowS shadows@kuwait.net Copyleft (hack it i really don’t care). */
It was a brilliant idea! If the filtering router tested for SYN, feed it a SYN/FIN. However, the statement in the comment above that jackal had never been logged by any site misses the mark. You have seen the IMAP traces with the SYN/FIN set from Chapter 6, "Detection of Exploits," that were detected by the Shadow system. There was never anything that jackal (or hping or nmap) could send that couldn't be logged and analyzed by competent intrusion detection systems.
Explicit Stealth Mapping Techniques
The two well-known explicit mapping techniques are the SYN/ACK and the FIN scan. Both of these will generate a RESET if they hit an active host. They will also get an ICMP error message back if the host is unreachable. Explicit stealth mapping is more efficient than inverse mapping, but possibly more obvious.
SYN/ACK
This is the first example we will look at of a scan that intentionally disregards the TCP three-way handshake. In the case below, we see SYN/ACKs (step two of the handshake) when there is no step one (SYN). In early 1999, there were a large number of these scans in play.
06:41:24.067330 stealth.mappem.com.113 > 172.21.32.83.1004: S 4052190291:4052190291(0) ack 674711610 win 8192 06:42:08.063341 stealth.mappem.com.113 > 192.168.83.15.2039: S 2335925210:2335925210(0) ack 674711610 win 8192 06:42:14.582943 stealth.mappem.com.113 > 172.21.64.120.2307: S 2718446928:2718446928(0) ack 674711610 win 8192
The segment of the trace shown below shows how this scan can work. When stealth mappem's 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 there was never a SYN or active open packet (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 second line) to say "break off communications, something is wrong here." This gives away his existence to stealth.mappem. In turn, stealth.mappem is able to create a map of the site of active hosts that can be used to support further probes or attacks.
06:44:09.602803 stealth.mappem.com.113 > 192.168.162.67.2226: S 761493655:761493655(0) ack 674711610 win 8192 06:44:09.607462 192.168.162.67.2226 > stealth.mappem.com.113: R 674711610:674711610(0) win 0
FIN Scan
I have never detected a FIN scan in the wild and chose not to simulate one. In the case of a FIN scan, one would detect a large number of packets with the FIN flag set where there was no three-way handshake ever established. We have already discussed using a database to find ftp-bounce. A good intrusion analysis system should provide the capability to look for spurious traffic, such as FINs, to connections that were never established. HD Moore, the author of nlog, has been developing perl scripts to accomplish these sorts of tasks based on a 24-hour data window.
Inverse Mapping
Inverse mapping techniques can compile a list of networks or hosts that are not reachable and then use the converse of that map to determine where things probably are. These techniques are a bit harder to detect; I had to write a quick hack for the Shadow system to track RESET scans. Bill Ralph rewrote and improved the module look4scans.pl. Likewise, the following DNS example eludes all intrusion detection systems that I have worked with.
RESET Scan
Everybody knows BlaNCh3's signature line from the play Hacker on a Hot Tin Roof: "I've always relied on the kindness of routers." BlaNCh3 is referring to the way routers will happily spill their guts about the internal architecture of a network, even if the question doesn't make any sense. The router just looks at the IP address and makes decisions based on that. If the address doesn't exist, the router doesn't care that the RESET is out of place, it simply reports that the address doesn't exist. In the trace below, we see a RESET scan. At the bottom of the trace we see the router replying host unreachable. The unreachables are the cases where things are not, so by implication every other host exists. This is an extremely popular technique and, due to the amount of decoy traffic being sent, is a very safe technique for the attacker.
02:58:05.490 stealth.mappem.com.25984 > 172.30.69.23.2271: R 0:0(0) ack 674719802 win 0 02:59:11.208 stealth.mappem.com.50620 > 172.16.7.158.1050: R 0:0(0) ack 674719802 win 0 02:59:20.670 stealth.mappem.com.19801 > 192.168.184.174.1478: R 0:0(0) ack 674719802 win 0 02:59:31.056 stealth.mappem.com.7960 > 192.168.242.139.1728: R 0:0(0) ack 674719802 win 0 02:59:42.792 stealth.mappem.com.16106 > 172.16.102.105.1008: R 0:0(0) ack 674719802 win 0 03:00:50.308 stealth.mappem.com.8986 > 172.16.98.61.1456: R 0:0(0) ack 674719802 win 0 03:00:58.939 stealth.mappem.com.35124 > 192.168.182.171.1626: R 0:0(0) ack 674719802 win 0 03:00:58.940 router.mynet.net > stealth.mappem.com: icmp: host 192.168.182.171 unreachable
Answers to Domain Queries
Another variation of inverse mapping is shown below. The probing computer sends answers to domain questions that were never asked. The goal is simply to stumble across a subnet or host that doesn't exist, which will generate an ICMP unreach message. As we stated earlier, this pattern tends to evade detection. It can be found with scan detect code if the attacker gets greedy and probes too many hosts too quickly. It can also be detected by retrospective analysis scripts or database searches for application state violations.
05:55:36.515566 stealth.com.domain > 172.29.63.63.20479: udp 06:46:18.542999 stealth.com.domain > 192.168.160.240.12793: udp 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 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
Fragments, Just Fragments
One final example of an inverse mapping technique. As we have already learned, only the first fragment chunk comes with protocol information. Attackers using this technique, along with some interesting variations, were able to penetrate older firewalls and filtering routers. The firewalls would assume that this was just another segment of traffic that had already passed their access lists. Needless to say, this has been fixed in most vendors' products.
However, in this case the prober isn't particularly interested in firewall penetration. Once again, if one of the target hosts does not exist, the router will send back an unreachable message. The attacker is then able to compile a list of all the hosts that do not exist and by taking the inverse of that list, has a list of the hosts that do exist. This is why this class of techniques is called inverse mapping.
18:32:21.050033 prober > 192.168.5.71: (frag 9019:480@552) 18:32:21.109287 prober > 192.168.5.72: (frag 9275:480@552) 18:32:21.178342 prober > 192.168.5.73: (frag 9531:480@552) 18:32:21.295332 prober > 192.168.5.74: (frag 9787:480@552) 18:32:21.344322 prober > 192.168.5.75: (frag 10299:480@552) 18:32:21.384284 prober > 192.168.5.76: (frag 10555:480@552) 18:32:21.431136 prober > 192.168.5.77: (frag 11067:480@552) 18:32:21.478246 prober > 192.168.5.78: (frag 11579:480@552) 18:32:21.522631 prober > 192.168.5.79: (frag 11835:480@552)
Summary
The attacker community is investing an incredible amount of effort to scan the Internet. The single most important service for your site to block is ICMP echo requests. Recon probes should be taken seriously; if attackers can learn where your hosts are, they can make fairly short work of determining what services these hosts run. If they can't determine which of the hosts in your network address space are active, they have a very sparse matrix to deal with.
About the Author
Stephen Northcutt is currently the Chief Information Warfare Officer for the U.S. Ballistic Missile Defense Organization, original developer of the Shadow intrusion detection system, and former head of the Department of Defense's Shadow Intrusion Detection team. He is the author of Incident Handling: Step-by-Step and Intrusion Detection: Shadow Style, both published by the SANS Institute. Stephen is a featured lecturer and co-chair of the SANS Conference and is the program chair of the first Intrusion Detection Conference.
Copyright © 1999 by New Riders Publishing
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.
International rights = English only.
.gif "Link")