TCP Connect Scan

The first scan that we will analyze is the Nmap TCP Connect (-sT) scan. This type of scanning is the most basic because it completes the TCP three-way handshake with open ports and immediately closes them. Nmap first sends a SYN packet to each target port. A response packet with the Reset (RST) and Acknowledgment (ACK) flags set indicates that the port is closed. If a SYN/ACK is received, it indicates that the port is open and listening. Nmap will then respond with an ACK to complete the connection followed by an RST/ACK to immediately close the connection. This aspect of the scan makes it easily detectable at the system level because the error messages made during attempts to connect to a port will be logged.

Figure 8.1 shows the Nmap scanner system, 192.168.100.2, sending SYN packets to the target, 192.168.100.5. Most ports respond with an RST/ACK packet; however, packet 2904 shows the SYN/ACK response from port 139.

You can right click on the packet in the Wireshark output and choose Follow TCP Stream. This Wireshark feature shows only the packets affiliated with any particular connection. In our example, as shown in Figure 8.2, the extracted session shows the initial SYN packet, response SYN/ACK, and the subsequent ACK followed by the RST/ACK exchange on port 139.

Figure 8.3 shows the active ports on the target device. You can find these by using a filter such as tcp.flags==18 to view packets with both the SYN and ACK flags set.

You are going to see a lot of TCP connect activity on your network as a result of normal network communications. However, the fact that the source IP address is connecting to so many ports and/or systems potentially indicates a scan. Also, unless stealth techniques are used, it is also another indicator of scanning activity to see a high number of connections within such a short time frame. IDS and IPS systems will oftentimes maintain a signature to detect scanning that looks for a certain number of sessions within a limited amount of time. If this limit is exceeded, the intrusion system will alert or respond accordingly. One example is to look for X number of SYN requests from a single host within a set number of seconds. This type of signature can generate false positives, but with customization to your specific infrastructure, it can also be a great alert for scanning activity.

The Snort sf Portscan preprocessor will detect Nmap TCP connect scanning activity. The previous scan generated the following entry in the Snort alert file:

[**] [122:1:0] (portscan) TCP Portscan [**]

01/13-20:30:31.107599 192.168.100.2 -> 192.168.100.5

PROTO255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:161 DF

You may also use the Basic Analysis and Security Engine (BASE), which is a Web-based front-end for Snort. Figure 8.4 shows BASE with the portscan alerts generated from an Nmap TCP Connect scan.

Now you know the IP address of the system that was performing the scanning, and the open ports on the systems that responded. Since this was a TCP connect scan, the source IP address is not likely spoofed since it received and replied to packets. What else can we do with this information? If the scanner is an internal system, you should physically track it down to determine why it is sending this scan-like traffic. Notice we say “scan-like”. The reason is that there could be a legitimate purpose for the traffic being generated by the internal system and it is wise to approach your search calmly, without starting a fire-drill. Many an administrator has been embarrassed by going off half-cocked in pursuit of an alleged attacker or hacked box, only to later find that the suspected malicious traffic was in fact, benign.

If this is a system external to your network, review your firewall policy to see how and why the scans are making it into the internal network in the first place. You should also look for other events and traffic targeting the host or indicating further reconnaissance. Depending on what you find, it might be a good idea to also evaluate the host for signs of compromise. If the system has been compromised, you should rebuild it. If this appears to be initial reconnaissance against the target, make sure that all patches are up to date on the system. If you are still seeing traffic from this source IP address, you may need to add a temporary rule to block packets from and to this source system. You should also investigate the open ports that responded to the scan. The attacker may have been looking for a particular open service (possibly because it has a new discovered vulnerability) or a Trojan port of some type.

SYN Scan

The next scan that we will analyze is a TCP SYN scan, also known as a half-open scan because a full TCP connection is never completed. Nmap first sends a SYN packet to each target port. If a RST/ACK is received, it indicates that the port is closed. If a SYN/ACK is received, it indicates that the port is open and listening. The part that makes this scan a half-open scan is that Nmap will then follow with an RST to close the connection (instead of the final ACK in the complete 3-way handshake). SYN scans were originally known as stealth scans because few systems would notice or log them because they never created a full connection. However, many current operating systems, firewalls and intrusion detection systems (IDSes) will notice and even log this type of activity.

In Figure 8.5, the attacker, 192.168.100.2, is sending SYN packets to the target, 192.168.100.5. Most ports respond with an RST/ACK packet; however, the highlighted packets 511 and 516 show the SYN/ACK response and the subsequent RST exchange on port 135.

As with the TCP Connect scan, the Snort sfPortscan preprocessor will detect Nmap SYN scanning activity and generate an entry in the Snort alert file. You should follow the same response and mitigation recommendations as stated with the TCP Connect scan.

XMAS Scan

The XMAS scan determines which ports are open by sending packets with invalid flag settings to a target device. It is considered a stealth scan because it may be able to bypass some firewalls and IDSes more easily than the SYN scans. The Nmap XMAS scan sends packets with the Finish (FIN), Push (PSH), and Urgent (URG) flags set. Because this flag combination is invalid and should never occur in normal traffic, there is no established convention for dealing with these types of packets. Different TCP stacks will respond in different ways. Typically, closed ports will respond with a RST/ACK, and open ports will drop the packet and not respond. However, some TCP stacks will respond with RST packets from all ports, even open ports, and some systems will not respond to any packets. Personal firewalls and packet filters will also alter responses to this scan.

Notice that in Figure 8.6 the attacker, 192.168.100.5, is sending packets to the target, 192.168.2.1, with the FIN, PSH, and URG flags set. This scan is not receiving any responses to the XMAS packets.

As previously mentioned, you should not see packets in normal traffic with the FIN, PSH, and URG flags set. The Snort SCAN nmap XMAS rule will detect Nmap XMAS scanning activity. The previous scan generated the following entry in the Snort alert file:

[**] [1:1228:7] SCAN nmap XMAS [**]

[Classification: Attempted Information Leak] [Priority: 2]

01/13-20:49:13.408003 0:11:F5:92:26:F4 -> 0:17:F2:4D:B4:4A type:0x800 len:0x36

192.168.100.5:55661 -> 192.168.100.2:23 TCP TTL:55 TOS:0x0 ID:12511 IpLen:20 DgmLen:40

**U*P**F Seq: 0x68134FB6 Ack: 0x0 Win: 0x1000 TcpLen: 20 UrgPtr: 0x0

[Xref => http://www.whitehats.com/info/IDS30]

You should follow the same response and mitigation recommendations as stated with the TCP Connect scan.

Null Scan

The Null scan determines which ports are open by sending packets with invalid flag settings to a target device. Actually, the invalid flag settings are packets with all flags turned off (hence the name for the scan). Null scans were also originally considered very stealthy because of their ability to easily bypass operating system logging, fire-walls and IDSes. However, much like the SYN scan, the prevalence of scan-specific signatures on network-based appliances and host intrusion prevention and detection applications have contributed to administrators’ awareness with regards to this scan. Closed ports will respond with a RST/ACK, and open ports will drop the packet and not respond. However, some systems will respond with RST packets from all ports, even open ports, and some systems will not respond to any packets. Personal firewalls and filters will also alter responses to this scan.

In Figure 8.7, the attacker, 192.168.100.5, is sending packets to the target, 192.168.100.2, with all flags turned off, as indicated by the empty brackets []. This scan is not receiving any responses to the NULL packets. Notice that the intruder is using a static source port of 80. Specifying a popular source port that is often allowed through firewalls (such as Web port 80 or DNS port 53) is a common way for the Nmap scan to evade firewall restrictions.

You should not see packets in normal traffic without any flags set. The good news is that Snort has a rule to detect null scans; be sure it is integrated into your rule set and test its responsiveness. You should follow the same response and mitigation recommendations as stated with the TCP Connect scan.

Nmap Fragment Scan

Let’s test a personal firewall running on a fully-patched Windows 2000 Pro server that is sitting in our DMZ. This particular system should only have port 80 accessible as it is serving up a small, static Website. We’ll try a fragmentation scan against the server and since we’ll be testing from the same subnet, we’ll also incorporate some decoy IP addresses and see what the MAC addresses look like in our Wireshark results.

The intended victim, our personal firewall-protected W2K server, has several typical Windows services listening. However, the firewall is configured to only allow DNS queries, ping traffic and inbound HTTP requests, as shown in Figure 8.8.

We want to see how this personal firewall handles an Nmap fragmentation scan. Here is the Nmap command for performing our test:

C:downloads>nmap -f -D 10.0.0.10,10.0.0.15,10.0.0.33,ME,10.0.0.67,10.0.0.99 10.0.0.2

Notice in the Nmap command above, we used the word ME to place the scanning system after the decoy 10.0.0.33 in the list. We inserted several non-existent IP addresses into the decoy list. The IP address that we are scanning is the last item shown in the command, 10.0.0.2. The scan is being performed from a host with the IP address of 10.0.0.7. Wireshark was also set up to capture the details of this scan. Here are the results from Nmap:

Starting Nmap 4.53(http://insecure.org) at 2008-02-01 16:39 Central Standard Time

All 1714 scanned ports on 10.0.0.2 are filtered

MAC Address: 00:02:E3:13:36:4B (Lite-on Communications)

Nmap done: 1 IP address (1 host up) scanned in 72.672 seconds

It looks like our personal firewall is doing a pretty good job against this type of scan! Nmap was able to determine that all of the ports scanned (we used Nmap’s default port scanning list) are in the filtered state. If you recall from our previous chapters, this state implies the fact that Nmap can determine some type of filtering is occurring based on the results received from the scan. Now, let’s check out our Wireshark output and see what those decoy IP addresses look like.

Nmap Decoys

In the first Wireshark screenshot, we can see the details from one of the decoy IP addresses. If you look at the packet details in the lower half of the screenshot, you can see the MAC address information captured by Wireshark, as shown in Figure 8.9.

Now we’ll compare this MAC address information (00:14:a5:13:17:75) to the IP address that we know is the real source of the Nmap scan, as shown in Figure 8.10.

It’s a match! Just remember that this test will only work for scans originating from the same subnet. Otherwise, you would find the MAC address of the upstream router for the source MAC. Now, hopefully you also noticed the fact that our packets were indeed fragmented. For example in packets number 31 and 32 you will notice the offset is equal to 8 and 16 respectively, indicating 8 byte increments. Wireshark shows that the –f Nmap option performed as expected and split our outbound packets into 8 byte fragments.

Scanning to Test Alert Procedures

It is critical to test your internal network alerting facilities and/or your outsourced managed services alerting. Both can be tricky to test. This is due in part to technical issues, but also from a political standpoint. You want to make sure you have your management’s approval to conduct such a test in case the end result does not meet expectations or even worse, you cause a system crash or network instability. You must also conform to any existing contractual agreements with your managed service providers that specify the rules of engagement before you test their monitoring and alerting measures for your infrastructure.

Nmap has many types of scans and scan options that have been well-documented by IDS and IPS vendors over the years. Many signatures and heuristics have been devised to detect scanning and even to detect scanning from specific tools, like Nmap. As a result, there are most likely several ways to kick off an Nmap scan that will cause alerts to trigger on the monitoring stations of your managed service provider. The issue is finding a scan pattern that should attract enough attention because of its difference to the normal ebb and flow of traffic. Any intrusion analyst can testify that after a few million packets or so, you start to tune out common scans, service version queries and many other forms of general broad-range reconnaissance that happen on a daily basis and are commonly accepted as part of being “connected to the Web”. Therefore, your job in performing this alert testing is to pinpoint an appropriate target in your network infrastructure in conjunction with the right attention-getting scan. When performed by a legitimate attacker, this process would be considered targeted reconnaissance. The attacker most likely has a preferred exploit in their arsenal or is looking for a certain type of target based on the latest vulnerability information. Your managed service provider should be tasked with staying on top of cutting edge vulnerability information and exploit signatures. You should also have in your contract some information about risk priorities specific to your protected oranization assets, in addition to guidelines for response timeliness. With our Nmap testing, we’ll zero in on a specific target and utilize what should be some eye-catching scan techniques in order to test gaining the attention and response of our monitoring and managed services analysts. Keep in mind that we are talking about external-facing hosts. Unless otherwise instructed, your provider should immediately alert you to any internally-protected assets that come under Nmap scan-related fire.

Targeted Reconnaissance with Nmap

Targeted reconnaissance refers to the ever-tightening circle of information-gathering that occurs in the primary phase of an attack. To demonstrate how an attacker might perform this targeting using Nmap, we’ll start off with a broad-based scan, looking for servers with Web ports. We’re going after Web ports because that is one of the most published entry-points for the attacker into your infrastructure. Other externalfacing servers of interest typically include DNS servers, mail servers, routers and unprotected desktops. With a Web server, if an attacker can exploit their way onto the system, odds are they will have access to further pathways into your infrastructure. This ties into the need for segregated server networks, server hardening, separation of duties, and the principle of least privilege – but that is a different book!

Working out of our demo lab, we’ll only be scanning the 10.0.0.0/24 network, but in the real world an attacker would either be scanning multiple, miscellaneous subnets looking for certain ports or if they were targeting your organization specifically, then they might already have your subnet/s in their sites. As a reminder, here’s what a basic Nmap port 80 scan would look like:

nmap -p80 10.0.0.0/24

There are certainly ways we could make this port 80 scan less obvious, the biggest one being the timing switch. Remember Nmap has the capability to slow down the speed with which it scans utilizing the –t, timing, option. Keep in mind though we are mimicking an attacker who is scanning from the Internet and servers that have an internet-exposed address receive numerous scans of this type on a daily, if not hourly, basis. At this stage in the reconnaissance game, these scans are typically ignored by managed services providers.

Why didn’t the attacker incorporate the version detection option into this port 80 scan? The primary reason is for scan speed. They can come up with an extensive list of servers with an available HTTP port in a very short amount of time by using a pared down scan such as this one. If the attacker is already focused on a certain company or subnet, it is also likely that they want to minimize the number of probes being sent to the targets.

Now we have a listing of IP addresses that have an Internet-accessible port 80 listening. The attacker will feed this list of IP address back into a tool like Nmap and perform the next phase of targeted reconnaissance; determining what service versions are running on the open ports. The reason for this step is that most likely the attacker has exploit code ready to use against the matching, vulnerable service version. Hence the reason for staying on top of your patching and security hardening efforts.

Our scan discovered five active hosts, three of which have listening HTTP ports:

C:Downloads>nmap -p80 10.0.0.0/24

Starting Nmap 4.53 (http://insecure.org) at 2008-02-03 16:01 Central Standard Time

Interesting ports on 10.0.0.1:

PORT STATE SERVICE

80/tcp open http

MAC Address: 00:0F:B5:6D:EF:F1 (Netgear)

Interesting ports on 10.0.0.2:

PORT STATE SERVICE

80/tcp open http

MAC Address: 00:02:E3:14:47:5C (Lite-on Communications)

Interesting ports on 10.0.0.3:

PORT STATE SERVICE

80/tcp closed http

MAC Address: 00:12:3F:FD:18:67 (Dell)

Interesting ports on 10.0.0.4:

PORT STATE SERVICE

80/tcp closed http

MAC Address: 00:0D:0B:BE:2C:67 (Buffalo)

Interesting ports on 10.0.0.5:

PORT STATE SERVICE

80/tcp open http

MAC Address: 00:0C:29:E0:54:1B (VMware)

Nmap done: 256 IP addresses (6 hosts up) scanned in 6.797 seconds

Now we’ll run the –sV version scan against IP addresses 10.0.0.1, 10.0.0.2, and 10.0.0.5 to see what information Nmap can collect about the HTTP services found on the systems with the open HTTP ports:

C:Downloads>nmap -sV -p80 10.0.0.1-2,5

Starting Nmap 4.53 (http://insecure.org) at 2008-02-03 16:10 Central Standard Time

Interesting ports on 10.0.0.1:

PORT STATE SERVICE VERSION

80/tcp open tcpwrapped

MAC Address: 00:0F:B5:6D:EF:F1 (Netgear)

Interesting ports on 10.0.0.2:

PORT STATE SERVICE VERSION

80/tcp open http?

MAC Address: 00:02:E3:14:47:5C (Lite-on Communications)

Interesting ports on 10.0.0.5:

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 1.3.23 ((Unix))

MAC Address: 00:0C:29:E0:54:1B (VMware)

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/.

Nmap done: 3 IP addresses (3 hosts up) scanned in 11.266 seconds

Now we’re getting somewhere. From an attacker’s perspective, we have one system, 10.0.0.1, that doesn’t appear to be a viable target because the HTTP port is potentially protected. Our next option, 10.0.0.2, looks promising except for the fact that Nmap doesn’t have any feedback on the HTTP version that is running. For the attacker, this could indicate a non-HTTP service masquerading on port 80. We actually ran a netcat listener on this system and collected the Nmap queries. The –l command tells netcat to listen on a port and we used the –p option to specify port 80. Here is a copy of the Nmap query data that was received on the console of the netcat listener:

F:Netcat_for_Windows>nc -l -p80

GET /HTTP/1.0

OPTIONS /HTTP/1.0

OPTIONS /RTSP/1.0

l ? GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0

Ç (r¦?? ? ?åá ?ù| ? ?? ? version?bind ? ? ? ? HELP

?? S? O? ?G+~¦,eO¦′˜= ²é{¦+û+w¢μ-¦<=¦on?n (? ?

f ? ? e d c b a ′ § ? ¶ ? ?? ñ SMBr ?@ @? ? ü ?PC NETWORK PROGRAM 1.0 ?MICROSOFT

NETWORKS 1.03 ?MICROSOFT NETWORKS 3.0 ?LANMAN1.0 ?LM1.2X002 ?Samba ?NT LANMAN 1.0

?NT LM 0.12 ?default

0????′???? Ç OPTIONS sip:nm SIP/2.0

Via: SIP/2.0/TCP nm;branch=foo

From: <sip:nm@nm>;tag=root

To: <sip:nm2@nm2>

Call-ID: 50000

CSeq: 42 OPTIONS

Max-Forwards: 70

Content-Length: 0

Contact: < sip:nm@nm >

Accept: application/sdp

TNMP? TNME ? ? ??a DmdT ? ? ?? ? ?: / ? @?¤ ? =? / @? <NTP/1.0>

? ²+.?¦á MMS¶ ? ? ? ====? ? ? ? N S P l a y e r / 9 . 0 . 0 . 2 9 8 0 ; {0 0 0

0 A A 0 0 - 0 A 0 0 - 0 0 a 0 - A A 0 A - 0 0 0 0 A 0 A A 0 A A 0} am–_ Z ?

?6?, ¦ ? : 4 μ ? (CONNECT_DATA=(COMMAND=version))

As you can see, Nmap runs several different types of tests in its attempt to determine the service version of what it thinks should be a Web-enabled port. We can easily spot queries for headers, version.bind type, Server Message Block (SMB) and even Session Initiation Protocol (SIP) checks. Keep in mind that from the attacker’s point of view, they would never see this output. It is included here only for the purpose of demonstrating Nmap’s service version scan against this host.

The last host scanned, 10.0.0.5, is going to be the most interesting to the attacker at this point. Not only is it reporting a live host with an open port 80, but Nmap was also able to determine the version of Web server running on the port! In this case, it appears to be a rather outdated version of Apache, 1.3.23. If we do some basic searches online for vulnerability information pertaining to this version, we find that not only does it have vulnerability issues; one of those issues is incorporated into a Metasploit exploit, shown in Figure 8.11.

Luckily for us, this particular exploit appears to only work against vulnerable Apache versions installed on Windows machines. Nmap reported that this particular version is running on a UNIX-based platform:

Interesting ports on 10.0.0.5:

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 1.3.23 ((Unix))

MAC Address: 00:0C:29:E0:54:1B (VMware)

At this point, you might expect to see further Nmap queries from the attacker while they attempt to determine whether or not the operating system really is UNIX-based (although in the author’s experience, they should save themselves the time and just trust Nmap’s assessment). However, this doesn’t necessarily mean that the attacker won’t still attempt to run the exploit against your UNIX-based Apache server. Their mileage may even vary in terms of whether or not they cause any service disruption. Regardless, it is definitely time to update the Apache server. This also proves how easily an attacker could use Nmap to narrow down on a particular system. Back at your managed service provider, the analyst’s alerting workstation should have generated several Events of Interest (EOI) pertaining to these scans. Hopefully you have received a notification by now of a potential intrusion attempt! If your targeted reconnaissance scanning efforts do not generate notifications of any type, it is definitely time to investigate the monitoring performance agreement with your vendor.