Covert Channels - Communicating over TCP without the initial 3-way handshake

Today we did a lab with a tool called covert_tcp.

While this is an old tool and the lab was quite basic, the thing that caught my attention was the tool sends data serially - one character at a time.
As a result, I decided to perform a capture of the traffic to verify this. Interestingly, I found things even more interesting.

First let's create a file with some simple text.
root@security-nik:/tools# echo "securitynik" > file.txt && cat file.txt
securitynik

Now let's setup the server with the file to receive the data
root@security-nik:/# covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1020 -dest_port 1021 -server -file received_file.txt
Covert TCP 1.0 (c)1996 Craig H. Rowland (crowland@psionic.com)
Not for commercial use without permission.
Listening for data from IP: 127.0.0.1
Listening for data bound for local port: 1020
Decoded Filename: received_file.txt
Decoding Type Is: IP packet ID

Server Mode: Listening for data.

Let's set tcpdump to capture this traffic
root@security-nik:/tools# tcpdump -tnnvi any -w covert-tcp.pcap 'port 1020 and port 1021'


Now that the server is "Listening for data" and tcpdump is sniffing for traffic on 'port 1020 and port 1021', let's send the file containing data

root@security-nik:/tools# covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1021 -dest_port 1020 -file file.txt
Covert TCP 1.0 (c)1996 Craig H. Rowland (crowland@psionic.com)
Not for commercial use without permission.
Destination Host: 127.0.0.1
Source Host     : 127.0.0.1
Originating Port: 1021
Destination Port: 1020
Encoded Filename: file.txt
Encoding Type   : IP ID

Client Mode: Sending data.

Sending Data: s
Sending Data: e
Sending Data: c
Sending Data: u
Sending Data: r
Sending Data: i
Sending Data: t
Sending Data: y
Sending Data: n
Sending Data: i
Sending Data: k
Sending Data:

As can be seen above, each character in 'securitynik' is being sent serially, one character at a time.

Taking a sample of the first 3 pairs (6 packets) of communication we see the following

root@security-nik:/tools# tcpdump -tnnX -r covert-tcp.pcap -c 6
reading from file covert-tcp.pcap, link-type LINUX_SLL (Linux cooked)
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 2047148032, win 512, length 0
    0x0000:  4500 0028 7300 0000 4006 09ce 7f00 0001  E..(s...@.......
    0x0010:  7f00 0001 03fd 03fc 7a05 0000 0000 0000  ........z.......
    0x0020:  50c2 0200 2d22 0000                      P...-"..
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 2047148033, win 0, length 0
    0x0000:  4500 0028 0000 4000 4006 3cce 7f00 0001  E..(..@.@.<.....
    0x0010:  7f00 0001 03fc 03fd 0000 0000 7a05 0001  ............z...
    0x0020:  5014 0000 2fcf 0000                      P.../...
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 2081947648, win 512, length 0
    0x0000:  4500 0028 6500 0000 4006 17ce 7f00 0001  E..(e...@.......
    0x0010:  7f00 0001 03fd 03fc 7c18 0000 0000 0000  ........|.......
    0x0020:  50c2 0200 2b0f 0000                      P...+...
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 34799617, win 0, length 0
    0x0000:  4500 0028 0000 4000 4006 3cce 7f00 0001  E..(..@.@.<.....
    0x0010:  7f00 0001 03fc 03fd 0000 0000 7c18 0001  ............|...
    0x0020:  5014 0000 2dbc 0000                      P...-...
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 1058078720, win 512, length 0
    0x0000:  4500 0028 6300 0000 4006 19ce 7f00 0001  E..(c...@.......
    0x0010:  7f00 0001 03fd 03fc 3f11 0000 0000 0000  ........?.......
    0x0020:  50c2 0200 6816 0000                      P...h...
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 3305897985, win 0, length 0
    0x0000:  4500 0028 0000 4000 4006 3cce 7f00 0001  E..(..@.@.<.....
    0x0010:  7f00 0001 03fc 03fd 0000 0000 3f11 0001  ............?...
    0x0020:  5014 0000 6ac3 0000                      P...j...

If we look above, the following can be extracted immediately.
There is no TCP 3-way handshake
The client (port 1021) has the SYN, ECN and CWR flags set in all the packets. This is not normal, as the SYN flag is usually either
found by itselt in the first step of beginning a communication or in the SYN-ACK which is the second step of establishing a new TCP
connection. More importantly, seeing the SYN, ECN, CWR flags all set in the same packet is atypical.

Another point to note is when we look at the packet, they all report "length 0". This implies no data is being sent in these packets.

Looking at the sequence number of the first packet sent by the client, we see  "2047148032"
Taking a look at the server's (port 1020) response, we see the Reset and Acknowledgement flags set.
This is typical for where the system is not listening on a port which is being requested. As can be seen below, there is no service listening on port 1020. Do remember above we show the server was "Listening for data"
root@security-nik:~# netstat -nltp | grep 1020

Checking for open files with port 1020 shows nothing also
root@security-nik:~# lsof -Pi | grep 1020

However, when we look for processes relating to covert_tcp we see the following
 
root@security-nik:~# ps aux | grep -iE '(1020|covert_tcp)'
root      4073  0.0  0.0   1848   244 pts/0    S+   22:49   0:00 covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1020 -dest_port 1021 -server -file received_file.txt


The moral of this post?!
Being able to detect what is normal and what is abnormal is critical in doing packets analysis.
With the right tools, normal channels can be bypassed and data exfiltration can occur.

While my attention was caught because of the serial nature of the communication, there is a lot more to be learnt by reading link below.
In the example above, the data is found in the IPID field.

Reference:
http://ojphi.org/ojs/index.php/fm/article/view/528/449


covert-tcp.pcap