TCP connect() Scan (-sT)
Requires Privileged Access: NO
Identifies TCP Ports: YES
Identifies UDP Ports: NO

The TCP connect() scan is named after the connect() call that's used by the operating system to initiate a TCP connection to a remote device. Unlike the TCP SYN scan (-sS), the TCP connect() scan uses a normal TCP connection to determine if a port is available. This scan method uses the same TCP handshake connection that every other TCP-based application uses on the network.


TCP connect() Scan Operation
The TCP connect() scan to a closed port looks exactly like the TCP SYN scan:

sT_scan_closed
Source          Destination    Summary 
-------------------------------------------------------------------------------------
[192.168.0.8]   [192.168.0.10] TCP: D=21 S=41441 SYN SEQ=3365539736 LEN=0 WIN=5840
[192.168.0.10]  [192.168.0.8]  TCP: D=41441 S=21 RST ACK=3365539737 WIN=0
A scan to an open port results in a different traffic pattern than the TCP SYN scan:

sT_scan_open
Source          Destination    Summary 
-------------------------------------------------------------------------------------
[192.168.0.8]  [192.168.0.10]  TCP: D=80 S=49389 SYN SEQ=3362197786 LEN=0 WIN=5840
[192.168.0.10] [192.168.0.8]   TCP: D=49389 S=80 SYN ACK=3362197787 SEQ=58695210 LEN=0 WIN=65535
[192.168.0.8]  [192.168.0.10]  TCP: D=80 S=49389 ACK=58695211 WIN<<2=5840
[192.168.0.8]  [192.168.0.10]  TCP: D=80 S=49389 RST ACK=58695211 WIN<<2=5840
As the trace file excerpt shows, the TCP connect() scan completed the TCP three-way handshake and then immediately sent a reset (RST) packet to close the connection.

Unlike the TCP SYN scan, the nmap output shows that very few raw packets were required for the TCP connect() process to complete:
# nmap -sT -v 192.168.0.10

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 12:30 EDT
Initiating Connect() Scan against 192.168.0.10 [1663 ports] at 12:30
Discovered open port 3389/tcp on 192.168.0.10
Discovered open port 80/tcp on 192.168.0.10
Discovered open port 3306/tcp on 192.168.0.10
Discovered open port 445/tcp on 192.168.0.10
Discovered open port 139/tcp on 192.168.0.10
Discovered open port 520/tcp on 192.168.0.10
Discovered open port 135/tcp on 192.168.0.10
The Connect() Scan took 1.45s to scan 1663 total ports.
Host 192.168.0.10 appears to be up ... good.
Interesting ports on 192.168.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
80/tcp   open  http
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
520/tcp  open  efs
3306/tcp open  mysql
3389/tcp open  ms-term-serv
MAC Address: 00:30:48:11:AB:5A (Supermicro Computer)

Nmap finished: 1 IP address (1 host up) scanned in 2.242 seconds
               Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
#   
Advantages of the TCP connect() Scan
No special privileges are required to run the TCP connect() scan. Nmap uses the operating system's normal method of connecting to remote devices via TCP before it tears down the connection with the RST packet. Because these are TCP-based methods that any user can employ, no additional rights or privileges are required.


Disadvantages of the TCP connect() Scan
The disadvantage of this scan is apparent when application connection logs are examined. Since the TCP connect() scan is completing a TCP connection, normal application processes immediately follow. These applications are immediately met with a RST packet, but the application has already provided the appropriate login screen or introductory page. By the time the RST is received, the application initiation process is already well underway and additional system resources are used.


When to use the TCP connect() Scan
Because this scan is so obvious when browsing through the application event logs, it might be considered the TCP scan of last resort. If privileged access isn't available and determination of open TCP ports is absolutely necessary, however, this scan may be the only method available.

The only option to the TCP connect() scan that does not require privileged access but still scans TCP ports is the FTP bounce attack (-b). Given the small number of susceptible FTP servers that will participate in a bounce attack, this option is becoming less viable.


clock I try not to use the connect() scan unless it's absolutely necessary. It's very obvious (in both network traces and in application log files), and it uses many more system and application resources than the SYN scan!