3.4.10 - network mapping and information gathering

8/12/2019 3.4.10 - Network Mapping and Information Gathering

1/50

10 - 1

Intrusion Detection in-Depth SANS 2003 1

Network Mapping/InformationGathering

This page intentionally left blank.


2/50

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 wherethe would-be attacker is trying togather information to target a specificexploit 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 anattempt to find live hosts or ones that are listening for a certain service. Well also look at stealthyscanning 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 seewith the tool hping. And, finally, while it may not be considered information gathering, per se, it isimportant to understand that outbound activity from a server in your network may be an indicationthat the host has been compromised.


3/50

10 - 3


Hping Pattern

Silent Host Replies:17:14:18.726864 quiethost.0 >attacker.1356: R 0:0(0) Ack 192486 win 8192 (DF) (ttl 17, id 15697 )17:14:21.781140 quiethost.0 >attacker.1357: R 0:0 (0) Ack 187498 win 8192 (DF) (ttl 17, id 15699 )

Attacker Quiet

Target

1Stimulate Quiet Host

2Note IP ID on response3

Step 3, stimulate thetarget. Spoof addressof the quiet host. If theport is active, Quiethost receives Syn/Ack, if closed, Rst/Act.

4

5Step 5, the Quiet hostwill only reply to aSyn/Ack and will replywith an RSTincrementing his IPID.

Before hping2 became a packet factor y generator , it was a reconnaissance tool that took advantage of a neattrick. 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 whichwas not behind a restrictive firewall. The attacker would stimulate the quiet host by sending many packetsof TCP traffic to a non-listening port of the quiet host. The attacker would examine the IP identificationnumbers returned by the quiet host in the RESETS of the traffic. If this were truly a quiet host, theattacker expected to see incrementing IP ID numbers. Historically, IP ID numbers were incrementallygenerated most often each new packet had an IP ID value one greater than the previous one. Today, someTCP/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 atarget host listens on a particular port. This is where the scan becomes very clever. The attacker sends a SYNto the target host and port that is of interest, but the source IP used is the quiet hosts. Therefore, the targethost 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 hostand the quiet host. What good is this? If the target host does not listen on the port that was scanned, itwill respond with a RESET to the original source IP what it believe to be the quiet host. The quiet hostwill silently drop the RESET. However, if the target host listens on the port scanned, it will respond with aSYN/ACK to the original source IP of the quiet host. When the quiet host receives a SYN/ACK andrealizes it never sent a SYN in the first place (remember the port scan traffic was all spoofed to have thesource IP of the quiet host) , it will respond with a RESET. What the attacker will be able to see is anincrement of the IP identification number by 2 instead of the normal 1 from the background scan. When hesees 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 toreflect traffic.


4/50

10 - 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 anidentifier 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 theconvention. (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, code0). 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 asequence number that normally starts at 0. The next 8 octets, italicized above, is the timestamp. Youwill notice that the rest of the packet consists of increasing hex values from 08 through 37, which isthe fill pattern.


5/50

10 - 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, dumpingthe 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 doseem odd. The payload is only 10 bytes in length, and the first 4 bytes of the payload are the same asthe destination address. The identifier is always 0xbeef, which would make it difficult for thesending computer to know which process the replies are intended for, and the sequence number isalways 0xdead, so there is no way to tell how many pings have succeeded without being dropped or duplicated. It is interesting to note that 0xdeadbeef is often used by programmers as a fill pattern.

Detect and analysis by Andrew Korty, GCIA


6/50

10 - 6


Sequential CountupUsing ICMP Echo Requests

[Using ICMP Echo Requests ]01:00:38 pingmapper > 192.168.6. 1 : icmp: echo request01:00:51 pingmapper > 192.168.6. 2 : icmp: echo request01:01:04 pingmapper > 192.168.6. 3 : icmp: echo request

11:01:33.468943 xx.xx.xx.xx > 192.168.6.4: icmp: echo request0x0000 4500 0023 00be 0000 8001 fbe5 xxxx xxxx E..#............0x0010 c0a8 0604 0800 cf13 0200 1000 444d 4250 ............DMBP0x0020 494e 4700 0000 0000 0000 0000 0000 ING...........

This example shows an attacker pinging each address in a subnet in order. ICMP echo requestsshould be blocked at the firewall or filtering router in most environments, which would protectagainst 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 caseof 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 broadcastaddress. So if your network is using variable length subnet masks, this technique can identify thosesubnets.


7/50

10 - 7


Echo Requests and Unsolicited

ACKs63.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 000063.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 333463.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 livehosts. ICMP echo requests may be blocked inbound precluding any response and live hostidentification. However, if the perimeter defense is accomplished by a packet-filtering device that isnot 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 tothe unsolicited ACK with a RESET informing that scanner that the host is alive.

Detect by George Bakos


8/50

10 - 8


Recon for DNS TSIG

Domain Name System (query) Transaction ID: 0x beef

Flags: 0x 0980 (Inverse query) 0... .... .... .... = Query .000 1... .... .... = Inverse query .... ..0. .... .... = Message is nottruncated .... ...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 onthe target DNS server. This was done using a DNS inverse query and returned valuable informationrequired for the actual exploit.

One version of the exploit code used a very identifiable DNS identification number 0xbeef for theinverse query. The Ethereal output shown above displays this identification number and indicatesthat this is an inverse query. Inverse queries are a legacy of older versions of BIND and are typicallynot seen or supported in newer versions of BIND. Signatures to identify TSIG reconnaissance wouldlook for the DNS identification number of 0xBEEF and an inverse query. It should be noted that thisDNS 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.


9/50

10 - 9


DOA TSIG

10.0.0.1.1045 > 10.0.0.2.53: 57005+ [b2&3=0x180] [7q] [1au]Type0 (Class 250)? ^@Â^B^C^DÊ^F^G^HÎ^J^K^L^M^NÔ^P^Q^R^S^TÛ^V^W^X^Y^Z^[^\^]^^^_ !"#$%&'()*+,-./0123456789:;


10/50

10 - 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 theycreated a new DNS query that could ask for the authors names. Remember the version of BINDquery was able to determine the exact version of BIND running using the a DNS type of TXT and aclass of CHAOS? The authors.bind query doesnt tell the exact version of BIND, however it is a newfeature 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 andready to spew out the authors names upon request. All an attacker has to do is use any of the toolssuch as dig, host, or nslookup to execute the authors.bind query. Specifically, they must point to theDNS server to be queried, make sure that the DNS type is set to TXT, the DNS class is set to CHAOSand query for authors.bind. If they are successful, you will see the names on the above slidedisplayed.


11/50

10 - 11


RPC Info Query

05/20-08:28:20.109310 202.152.12.170:948 -> z.y.w.98: 111TCP TTL:47 TOS:0x0 ID:49185 DF*****PA* Seq: 0x7A679FD2 Ack: 0xD8600F48 Win: 0x7D78TCP Options => NOP NOP TS: 30003373 57925753980 00 00 28 3A D7 D6 BF 00 00 00 00 00 00 00 0200 01 86 A0 00 00 00 02 00 00 00 04 00 00 00 0000 00 00 00 00 00 00 00 00 00 00

RPC packets will generally have the 00 01 86 prefix shownin the signature for this detect

Remote Procedure Calls (RPC) are the building block for a number of services, the most well-knownand frequently used being Network File System (NFS). RPCs and even NFS can be implementedover TCP as well as over UDP. RPCs are not programmed to sockets, but to functions. The log fileentries from systems tend to reflect this, including the ever popular dump() call that can be executedfrom 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) inEthereal, 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: 0x7D78TCP 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


12/50

10 - 12


Printer Hunting08:27:36.603367 192.168.1.1.63766 > 192.168.12.3. 9100 : S2784969512:2784969512(0) win 65535

08:27:40.102674 192.168.1.1.63766 > 192.168.12.3. 9100 : S2784969512:2784969512(0) win 65535

08:27:46.502821 192.168.1.1.63766 > 192.168.12.3. 9100 : S2784969512:2784969512(0) win 65535

About every 5 - 10 seconds, myhost (192.168.1.1) sends a TCP connection attempt from a varyinghigh-numbered port to the remotehost (192.168.12.3) port 9100. The number of connection attemptsusing the same source port varies from one to a handful; then the source port changes. The remotehost does not respond to these attempts.

By looking up port numbers on the Internet, we found that port 9100 is the standard port used bynetworked Hewlett Packard LaserJet printers. Searching the network traces shows other connectionsto 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 matchthe 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 wasupdated 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 TCPconnection attempts to remotehost stopped. When the printer was removed and re-added with thecorrect IP address via JetDirect, printing went to the printer and not to remotehost.

Detect and analysis by Mike Harvey, GCIA.


13/50

10 - 13


Backdoors WU-FTPD 9704

&T0rn 9876Jan 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 (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 1365694446win 32120 (DF) (ttl 64, id49072, len 48)

Obviously an attacker could use any port as a back door. For the purpose of this course, we areasking you to be sensitive to three: 1524 ingreslock taught later, 9704, and the one from the T0rnrootkit, 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 usesspecific RPC and WU-FTPD buffer overflow exploits. Once the attacker gains access to themachine, via a buffer overflow, a line is put in the inetd.conf telling it to listen on port 9704. Theattacker was looking for machines that had already been compromised. If the attacker were able tofind 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 subnetas 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 slidewas taken from and also Toby Millers paper at: http://www.sans.org/y2k/t0rn.htm


14/50

10 - 14


Network Mapping

Network mapping refers to anattacker probing your systems inorder to determine what their IPaddresses 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 theIP 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 permitthis traffic to pass through, and because attackers can hide their mapping attempts among all theother traffic going to these ports.


15/50

10 - 15


02:08:48 mapper.com.3066 > 192.168.134.117. echo : udp 602:15:04 mapper.com.3066 > 172.31.73.1. echo : udp 602:15:13 mapper.com.3066 > 172.31.16.152. echo : udp 602:22:38 mapper.com.3066 > 192.168.91.18. echo : udp 602:27:07 mapper.com.3066 > 172.31.2.176. echo : udp 602:30:38 mapper.com.3066 > 192.168.5.103. echo : udp 602:49:31 mapper.com.3066 > 172.31.152.254. echo : udp 602:49:55 mapper.com.3066 > 192.168.219.32. echo : udp 603:00:19 mapper.com.3066 > 172.31.158.86. echo : udp 6

udp 6 = UDP packet, 6 bytes payloadStealthy scan: slow scan rate and address interleaving

Network Mappingwith UDP Echo Requests

In this slide, we see an attacker performing network mapping through UDP echo requests. Dontconfuse these with ICMP echo requests; there is a service called echo that Unix systems may have onUDP port 7. This service is unrelated to ICMP echo requests and replies. The echo service willecho 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), anattacker could spoof packets with a forged source address; the system with echo would then send allof its responses to the spoofed system.

Although many attackers know about the echo service, this particular scan is using an uncommontechnique; we have to give these folks extra points for interleaving the Internet address families andkeeping the scan rate down to stealthy levels.


16/50

10 - 16


[**] SNMP access, public [**]02/22-06:36:32.633503 158.36.37.2:1289 -> x.x.x.z:161UDP TTL:118 TOS:0x0 ID:51169Len: 24630 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 ProbeDefault Community String

This is a Snort style detect of an SNMP probe. Only one packet is shown above, but this is part of alarge scan. Note that this is using the public community string and they havent yet begun walkingthe 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 demoversion. This was certainly not a quiet scan for this particular kiddie.

Reported by Jeremy Hansen on August 13, 2000 GIAC.


17/50

10 - 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 request17:43:17.32 prober.1030 > 192.168.1.255.161:GetNextRequest(11)[|snmp]

GetNextRequest is used to walk an SNMP MIB Tree

Information GatheringUsing Broadcast SNMP and Ping Mapping

In this example, we see a scan that is using SNMP requests and ICMP echo requests in order togather information. This is similar to a pattern used by printer software to scan for printers. It is stilltroubling.


18/50

10 - 18


[**] SNMP-write-write [**]02/16-22:45:56.399686 0:0:0:55:B6:43 -> 0:0:0:C4:25:8C type:0x800len:0x670.17.3.44:54064 -> 192.168.1.1:161 UDP TTL: 10 TOS:0x0 ID:26882Len: 1766430 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 +............ 1922E 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. Thedestination 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 sametechnique. The source port is being reused, the packets arrive in a very fast succession, and the IDsare 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 .


19/50

10 - 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 HuntingUsing SNMP to Broadcast Addresses

This is another example of an SNMP scan. Note that the second detect is a scan to a broadcastaddress. 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-terminalsand 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 IANAassignments; .1.3.6.1.4.1.11 is assigned to hp. The particular MIB the attacker is trying to access islisted 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 informationthat can be of use. Also, if the attacker has the read/write community string, he may change theconfiguration 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 configured2 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


20/50

10 - 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)




This is either a very broken application or a poorly craftedpacket; probably not dangerous, certainly an anomaly.

SNMP Crafted Header

These packets were printed with the -vv option to get more information. The first clue thatsomething was wrong was that misspelling in GetNextRequest. Also, note that the ID field has notchanged, 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 timewe have the same TTL pattern.

Now what is the analysis? Do we just have an inept coder trying to write an SNMP application, or isan inept coder trying to write an exploit? We may never know.


21/50

10 - 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 thedomain name (woe.is.me.com) rather than a host. The query is successful, as myhost returns oneanswer (1/1/1).

The random source ports seem normal enough, but the intensity of the timing of the requests is highlyunusual 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 thesource claimed a very large amplification factor can be achieved with DNS. There's also a tool calledabusedns mentioned at the SANS web site. This tool is a follow-on to doomdns.

Detect and analysis by Mike Harvey, GCIA.


22/50

10 - 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 Servers31337 Signature Port

Its easy to see that this is a host scan. At the same time, many different IP addresses on the samesubnet are receiving a packet from one source address destined for their TCP port 80. We can getfurther 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.


23/50

10 - 23


Information GatheringUsing NetBIOS

One of the characteristics of NetBIOS is that UDP 137 is often caused bysomething a site initiates. For example, if you send e-mail to a site runningMicrosoft 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 http12/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 http12/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 sometimelater the PC is accessed with a name lookup. Think of this in terms of stimulus and response; whenyou 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.


24/50

10 - 24


16:34:59 srn.org 137 > 192.168.130.55 137: udp16:34:59 srn.org 137 > 192.168.108.171 137: udp16:34:59 srn.org 137 > 192.168.162.231 137: udp16:34:59 srn.org 137 > 192.168.14.209 137: udp16:34:59 srn.org 137 > 192.168.145.45 137: udp16:34:59 srn.org 137 > 192.168.160.181 137: udp16:34:59 srn.org 137 > 192.168.15.116 137: udp16:34:59 srn.org 137 > 192.168.148.137 137: udp16:35:00 srn.org 137 > 192.168.146.20 137: udp16:35:00 srn.org 137 > 192.168.164.186 137: udp

A connection from any source port other than137 to 137 may indicate a Samba system.

Information GatheringScanning 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 alot 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, thisis not always the case. For example, connections involving a Samba system may only have port 137as a source or destination, not both.


25/50

10 - 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 itto 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.


26/50

10 - 26


Null Session

net use \\172.20.244.164\IPC$ /USER:OrNET USE \\172.20.244.164\IPC$ /u: ThenNET VIEW \\172.20.244.164

If null session or anonymous login is allowed, it is possibleto collect a tremendous amount of information about thesystem 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, thname is set to null. Also, the share that we are accessing on the Windows machine is calleyour system allows such connections to your IPC$ share, then attackers can gather informyour system. The next slide shows some of the information that can be collected through asession.A practical from Andrew Windsor shows the share decoded on the net and then, he shows easier way.http://www.sans.org/y2k/practical/Andrew_Windsor_GCIA.doc00180: 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 awmost useful tool that exploits this feature is Razorsenum which is available onhttp://razor.bindview.com.


27/50

10 - 27


A Real Example2/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,NoAcctLockedOut,NoAcctExpiresTime,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, andsystem policy settings.

In order to protect your systems against activities like null sessioning, you should use a securityauditing 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 NTsystems 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


28/50

10 - 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




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 acable modem (cable-modem-land is kinda scary!!!). In all cases a host-based firewall was used. Mostaddresses 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 theowner. 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 theCompaq relationship. On the client computer an application named Compaq Service Connection isautomatically 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 thisaddress so the updates could be delivered.


29/50

10 - 29


Subtle and Stealthy Attacks

These attacks typically fall below thenoise threshold on a network and areconsequently difficult to detect. Thehostile connections are embeddedwithin a large volume of identical trafficthat 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 bea handy way to synchronize with Trojans. With Trojan applications, the attacker has to find andacquire 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.


30/50

10 - 30


APR 21 ->18:41:03.642390 srn.org > 256.168.12.255: icmp: echo request18:41:05.120927 srn.org > 256.168.12.255: icmp: echo request19:32:51.522600 srn.org > 256.38.13.255: icmp: echo request19:32:53.119613 srn.org > 256.38.13.255: icmp: echo request21:29:59.235065 srn.org > 256.168.13.255: icmp: echo request21:30:00.238629 srn.org > 256.168.13.255: icmp: echo request22:23:03.099737 srn.org > 256.38.14.255: icmp: echo request22:23:03.853866 srn.org > 256.38.14.255: icmp: echo requestAPR 22 ->01:11:07.718531 srn.org > 256.38.15.255: icmp: echo request01:11:09.370796 srn.org > 256.38.15.255: icmp: echo request

02:11:40.517847 srn.org > 256.168.15.255: icmp: echo request02:11:42.760540 srn.org > 256.168.15.255: icmp: echo request

NOTE: They are mapping 2 sites

Stealthy Ping MappingSlow Scan to Evade Detection

This slide is an example of a slow scan of multiple subnets. The scans are occurring one or two hoursapart from each other. This technique will work to evade most intrusion detection systems becausethey dont hold connections for evaluation anywhere near an hour. Being acquainted with multipletraces 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 mayrecord 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.


31/50

10 - 31


16:32:30 www.org.80 > 172.16.97.217.1775: SA16:32:40 www.org.80 > 172.16.129.64.1630: SA16:32:54 www.org.80 > 172.16.176.79.1630: SA16:32:58 www.org.80 > 172.16.191.57.1775: SA16:33:09 www.org.80 > 172.16.223.94.1630: SA16: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 thesource 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 spoofingyour address space and hitting the web server.

16:32:30 www.org.80 > 172.16.97.27.1775: S 2784994:2784994(0) ack 674711610 win32736

16:32:40 www.org.80 > 172.16.129.64.1630: S 266690:266690(0) ack 674711610 win32736

16:32:54 www.org.80 > 172.16.176.79.1630: S 6827234:6827234(0) ack 674711610 win32736

16:32:58 www.org.80 > 172.16.191.57.1775: S 7509906:7509906(0) ack 674711610 win32736

16:33:09 www.org.80 > 172.16.223.94.1630: S 8636714:8636714(0) ack 674711610 win

3273616:33:13 www.org.80 > 172.16.238.72.1775: S 6505114:6505114(0) ack 674711610 win32736

This would be considered reconnaissance if www.org is a host that is sending SYN/ACKs in order to elicit aRESET 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 mayhave a host posing as a web server or may be using a compromised web server to scan for live hosts.


32/50

10 - 32


06:41:24 srn.com.113 > 172.21.32.83.1004: S 405:405(0) ack 674 win 819206:42:08 srn.com.113 > 192.168.83.15.2039: S 233:233(0) ack 674 win 819206: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 MappingUsing TCP SYN/ACK Packets

This slide demonstrates the pattern that is the so called stealth scan; stealth was coined by ChrisKlaus in his signature paper on stealth scanning that is available on fine hacker information siteseverywhere. As for the time frame, before mid 1997, this was a stealthy approach. Today, a moreaccurate and descriptive term for this pattern is TCP half scans. Before we talk about how thisworks, 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 andacknowledges As SYN with a SYN/ACK. A says great and acknowledges Bs SYN/ACK with anACK, and the conversation begins.

A SYN BA SYN/ACK BA 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 certainlythe signature of a TCP half scan, there are other possible causes for this traffic. Your address spacemight 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. Whensrn.coms packet arrives at 192.168.162.67 with the SYN/ACK set, 192.168.162.67 knows somethingis 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 mistakeand sends a RESET (the R in the fourth line) to say break off communications, something is wronghere. This gives away his existence to srn.


33/50

10 - 33


06:41:24 srn.com.1045 > 172.21.32.83.113: S 405:405(0) win 819206:42:08 srn.com.1167 > 192.168.83.15.113: S 233:233(0) win 819206:44:09 srn.com.1280 > 192.168.162.67.13: S 76:761(0) win 8192

Network MappingUsing Reverse IDENT

If you know a specific process is running on a systemyou 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 areverse 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 normalfor all communications, but the wrinkle is before B says OK, I will talk with you and acknowledges As SYN with aSYN/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 3way handshake is complete in reverse, the Server interrogates the Client for its process ID. Only after getting thisinformation, does the Server B allow the original connection to continue. The primary services that are likely torequire identd are IRC port 6667 and sendmail port 25.

A SYN B Port 25

Identd Process

Port 113 A SYN B

A SYN/ACK BA ACK B

Resume Original Connection

A SYN/ACK BA 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 noinitiating activity by the client.


34/50

10 - 34


Network MappingUsing TCP Reset Packets

02:58:05 srn.com.25984 > 172.30.69.23.2271: R 0:0(0) ack 674719802 win 002:59:11 srn.com.50620 > 172.16.7.158.1050: R 0:0(0) ack 674719802 win 002:59:20 srn.com.19801 > 192.168.184.174.1478: R 0:0(0) ack 674719802 win 002:59:31 srn.com.7960 > 192.168.242.139.1728: R 0:0(0) ack 674719802 win 003: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 connectionsthat were never established.

This slide shows a reset scan. They make a wonderful scan, because so many resets occur naturallyon 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 withtheir 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 viaICMP that the target is unreachable. To help you remember this technique, just think about AStreetcar 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 queriesthat were never asked. This only works when the host doesnt exist. Since the attacker is mappingthe holes in the network, this is called inverse mapping. After you find as many hosts that dont existas 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 TCPstate 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 pushthese days for less filtering so we can go faster and watch streaming DVD at our desktops. Keep inmind there is a cost to having your site more open to the Internet. Call me conservative, but I stillfind great comfort in the proxy firewalls.


35/50

10 - 35


Stealthy Network MappingFaking a DNS Response

07:36:32.713298 stealth.com.domain > 172.29.185.48.54358: udp07:57:01.634613 stealth.com.domain > 254.242.221.165.13043: udp09:55:28.728984 stealth.com.domain > 192.168.203.163.15253: udp10:38:53.862779 stealth.com.domain > 192.168.126.131.39915: udp10:40:37.513176 stealth.com.domain > 192.168.151.126.19038: udp10:44:28.462431 stealth.com.domain > 172.29.96.220.8479: udp11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp

Stimulus-Response Pair11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp11: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 XPort 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 thisexample, the replies to DNS questions that were never asked are used to probe the network. The finaltwo 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 DNSresponses through a packet-filtering device that is not stateful. A non-listening port on a live hostwill generate an ICMP port unreachable message.


36/50

10 - 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 MappingUsing 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@552in 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 inthe slide all start at offset 552, but there are no other fragments. The motivation for doing a scan withfragments is that the receiving system may not log individual fragments, only whole packets after allfragments have been received.


37/50

10 - 37


00:59:17 m4trix> 172.20.179.41: icmp: echo reply00:59:17 router> m4trix: icmp: host unreachable02:11:50 m4trix> 172.20.54.94: icmp: echo reply02:11:50 router> m4trix: icmp: host unreachable02:55:14 m4trix> 172.20.135.88: icmp: echo reply03:45:36 m4trix> 172.20.54.116: icmp: echo reply03:45:36 router> m4trix: icmp: host unreachable03:51:00 m4trix> 172.20.191.0: icmp: echo reply03:51:00 router> m4trix: icmp: host unreachable04:05:27 m4trix> 172.20.9.57: icmp: echo reply06:52:49 m4trix> 172.20.205.83: icmp: echo reply07:38:45 m4trix> 172.20.134.25: icmp: echo reply

This scan is penetrating the proxy firewall since it allowsecho 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 slowscan 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.


38/50

10 - 38


00:16:44.700238 srn.org.137 > 256.38.161.3.137: udp 5000: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 5000: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 thingsare the result of malevolent intent. Shadow analysts have to make a call using their instincts andtraining as to which detects to report. In this case, we decided this was just a wrong number.


39/50

10 - 39


These were grouped together because they are the sametype 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 anephemeral 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 outwho 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 inlocal/var/bootfiles/some_name.


40/50

10 - 40


TCP Discard

08:02:35 dscrd.net.268 > 192.168.160.122.9: S1797573506:1797573506(0) win 16384 (DF)

08:02:38 dscrd.net.268 > 192.168.160.122.9: S1797573506: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 onto the next host.


41/50

10 - 41


UDP Discard10: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 udpdata, and the final fragment is 481 bytes of data481 + 544 = 1025; which is the correct udp datasize


42/50

10 - 42


Customized Web Content07: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 istesting for open ports on the firewall

Normally, we should see clients from our side (firewall) initiating connections to external webservers such as ad.pref and media.pref. However, in this case, we not only see the web serversinitiating 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 targetfirewall. 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 outsideof coincidence.


43/50

10 - 43


Confirming Snort DetectionMar 18 03:57:54 tempest snort: [1:0:0] IDS296/web-misc_http-

whisker-splicing-attack-space [Classification: suspiciousmiscellaneous 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 SANSstudents to use. In particular as an extra bonus I process my daily logs with a small Perl script which producesHTML 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 alwaysread 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 "logfusion". 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 perfectfor rooting out false positives concerning web traffic, the best example being the good ol' 3DNS "attacks" whichcompared 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 theweb accesses to the daily Snort data with attacks and suddenly my heart jumped: in the list of attacks I had siteswith source addresses which matched exactly the source address of hosts checking the daily log the followingday!

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 aboutmodified Snort rulesets? So you search the web with Google and you fall upon my site which not only publishesdaily Snort logs but also the rules being used. What follows is that you try your attack against my web site on theassumption 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!


44/50

10 - 44


Intrusion Detection Systems (andtheir operators) tend to be focusedon incoming traffic. It pays toconsider outgoing traffic as well.

Outgoing Packets

In many organizations, the purpose of perimeter security primarily routers, firewalls and intrusiondetection systems is to filter and scan incoming traffic. However, no attention is given to outgoingtraffic. 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. Thiscould be a member of your organization, a visitor, or an unauthorized person who has gained physicalaccess to your systems. Or it could be

- An attacker who has entered your network without passing through your Internet routers andfirewalls (for example, through unsecured modems). You may not know that the system has beencompromised, but if you are monitoring outgoing traffic, you may see the system launching attacksagainst 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 examininghalf 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 requestfrom your systems, or if they are unsolicited?


45/50

10 - 45


11:56:45.894653 borg.2049 > 207.46.130.165.http:S 637662720:637662720(0) win 16616 (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 havereviewed. This packet was captured as it was going from a users Macintosh to Microsoft. TheMacintosh had Microsoft Word on it, and some research determined that this packet was triggered byMicrosoft Word.

So why is this considered reconnaissance? Well, the packet is transmitting the IP address of theMacintosh to Microsoft. Folks who have spent a lot of money developing a Network AddressTranslation scheme arent going to be very pleased about the hosts IP address being passed as data.


46/50

10 - 46


Inferring Outbound Traffic

From Inbound ICMP Errors12: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 prohibitedfilter

12:58:47.918470 200.220.72.126 > 172.16.248.252 : icmp:host 129.222.48.106 unreachable - admin prohibitedfilter

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 tellfrom the timestamps of the records above, many ICMP unreachable error messages were sent in avery small amount of time. These ICMP messages are coming from many different IPs presumablyrepresenting routers that sent the messages.

There are two possible conclusions here. The first is that someone may be spoofing your host IP172.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 thetype of activity that may be seen from any malware that uses a pseudo-random number generator tosearch for other victims. This is how Nimda that would look for other hosts to infect.

Detect and guidance from George Bakos.


47/50

10 - 47


Compromised Telnet Server10.10.102.182.2828 > 206.132.179.136. 21 : S 809165349:809165349(0) win

512206.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 512206.132.179.136.21 > 10.10.102.182.2828: P 1:101(100) ack 1 win 17520

USER dadropsitPASS 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 itwas 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 lookslike the attacker logs on to the FTP server. The password amdhax0r seems to indicate that he/shemay be affiliated with the hacking group AMD who have produced a number of exploits such as aninfamous one known as ADMROCKS that took advantage of a buffer overflow in BIND. Thehacker is retrieving a tarball named warez presumably all the code he or she will need to totallycustomize the hacked telnet server.

Credit to George Bakos for the detect.


48/50

10 - 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 adescription 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 toshut 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 compromisedtelnet 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 thatsomething wrong or unusual is occurring.

Detect and explanation by George Bakos.


49/50

10 - 49


Summary

Reconnaissance techniques Host scanning Network mapping Subtle and stealthy

To summarize this section, we have studied three types of reconnaissance techniques. Host scanninginvolves searching for one or a few services on a number of hosts. Network mapping uses probes todetermine the IP addresses that are in use. Finally, subtle and stealthy scans are usually low andslow, designed to blend in with legitimate traffic. Attackers will use any and all of these techniquesto 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.


50/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 slideshave changed.

3.4.10 - network mapping and information gathering

Documents