1. Introduction
Most professional intruders utilize stepping stones [
1] to launch their attacks. One significant benefit that intruders can obtain by doing so is that they can protect themselves behind a long connection chain. As we know, a computer network communication using TCP protocol can expose the source IP address to the destination. However, a network communication connection chain containing multiple connections with each utilizing TCP protocol cannot expose the source IP of the first host of the connection chain to the last destination host. This indicates that, at the end of a TCP connection chain, it is infeasible to know where the network packets come from originally. Therefore, by utilizing a long interactive TCP connection chain, intruders can be well protected.
Capturing stepping-stone intruders is non-trivial due to some inherent design defects of TCP protocol. However, detecting such kind of intrusion is possible. Since the 1990s, many approaches have been proposed and developed to detect stepping-stone intrusion (SSI). The SSI detection techniques can be divided into two different categories: host-based and network-based detection. The host-based SSI detection technique is to check if there exists a relayed incoming and outgoing connection pair. The network-based SSI detection technique determines an intrusion using the length of a connection chain. The longer a connection is employed, the higher the probability there exists a stepping-stone intrusion. Estimating the length of a connection chain becomes key for network-based SSI detection.
Some well-known host-based SSI detection approaches include Packet Content Thumbprint (C-Thumbprint), Packet Time Thumbprint (T-Thumbprint), packet counts, Random-Walk, TCP Session Watermark, and cross-over packets. C-Thumbprint was proposed to detect stepping-stone intrusion by S.S. Chen and L. T. Heberlein [
2] in 1995. It is the first approach developed for SSI detection. Its basic idea is to compare the packet content of the incoming connection of a host with its outgoing connection to see if there exists a relayed pair. For efficiency reasons, instead of comparing the contents of packets directly, C-Thumbprint uses a hash function to compute a fixed-size thumbprint from the packets captured in a session. That is why this approach is normally called content thumbprint. The biggest disadvantage of C-Thumbprint is that it cannot apply to an encrypted TCP session. Since 2000, more and more hackers used encrypted tools, such as OpenSSH, to make a long connection chain to launch their attacks.
In 2000, some computing scientists, such as Y. Zhang, V. Paxson, K. Yoda, and H. Etoh, proposed packet-content-independent approaches to detect stepping-stone intrusion and made significant progress. Y. Zhang et al. [
1] developed an algorithm to use the time period for which a session has packets captured, called ON-time, and one for which a session has no packets captured, called OFF-time, to detect SSI. After monitoring a TCP session for a certain period of time, we would obtain two ON-OFF time period data sequences. One is from the incoming connection of a host, and another one is from its outgoing connection. The ON-OFF time sequence is called time thumbprint, denoted as T-Thumbprint. Simply comparing the two T-Thumbprints can help us determine if a host is used as a stepping stone or not. T-Thumbprint is independent of packet contents. Therefore, this method can apply to encrypted TCP sessions. In the same year, K. Yoda and H. Etoh proposed to employ session deviation to detect stepping-stone intrusion [
3]. Session deviation can be computed based on the header information of the packets captured from a TCP session other than packet contents. This approach can also apply to an encrypted TCP session.
Between 2002 and 2007, the approaches of comparing the amount of packets from the incoming and outgoing connections of a host were proposed to detect stepping-stone intrusion. They are called packet count methods. Two typical ones in this category are the algorithm proposed by A. Blum et al. in 2004 [
4], and another one developed by T. He and L. Tong in 2007 [
5]. X. Wang proposed watermark approaches to detect stepping-stone intrusion from 2001 to 2004 [
6,
7,
8]. The basic idea of the watermark approaches is to inject a small piece of a watermark into the incoming connection of a host and check its outgoing connections to see if the injected watermark can be detected or not.
If a host is used as a stepping stone, the amount of packets monitored from one incoming connection of the host is supposed to be close to the amount of packets from its relayed outgoing connection. In an ideal scenario, the two numbers should be equal. In a non-ideal case, the difference between the two numbers should be bounded. This is the basic idea employed in Random-Walk approach to detect stepping-stone intrusion. Using cross-over packets to detect stepping-stone intrusion was proposed in 2016 by S. H. Huang et al. [
9]. A cross-over packet is defined as an Echo packet that meets the second Send packet before the Echo packet of the first Send packet comes back to the sender. The amounts of the cross-over packet from the two relayed sessions are close. In other words, we can monitor the amount of cross-over packets from the incoming connection of a host, as well as its outgoing connection, to detect stepping-stone intrusion.
All of the above host-based SSI detection approaches suffer from two serious issues. One is that they may bring high false-positive errors since a stepping-stone host may not be used for intrusion. Another one is that they could not resist intruders’ evasion, such as chaff-perturbation and/or time-jittering manipulation. Network-based SSI detection approaches have been proposed since 2002 to mitigate the above two issues coming with the host-based SSI detection approaches. In the following section, we will briefly summarize some typical network-based SSI detection algorithms.
The representatives of the network-based SSI detection technique involve Yung’s approach, Step-function, the cross-over packet approach, and the clustering–partitioning algorithm. The significant benefit of employing the length of a connection chain to detect SSI is that it can reduce false-positive errors. The reason behind this is that some legal applications may use one or two hosts as a stepping stone, but there are few applications using three or more than three hosts as stepping stones. If we can estimate the length of a connection chain, we can, most likely, determine if a host is used for intrusion. The longer a connection chain, the higher the probability the chain is used for stepping-stone intrusion.
To the best of our knowledge, K. H. Yung [
10] is the first researcher proposing an algorithm to detect stepping-stone intrusion by estimating the downstream length of a connection chain. If a host is used as a stepping stone, every Send packet along the connection chain would be first acknowledged by its adjacent host and then echoed by the end host of the connection chain. The time difference between a Send packet and its acknowledgment packet would reflect the length between the sender host and its downstream adjacent host along the connection chain. This can be used to measure the length of one connection. We denote it as Ts-a. The time difference between a Send packet and its echoed packet from the end of the connection chain can represent the length of the whole connection chain including multiple connections. We denote this as Ts-e. The ratio of Ts-a and Ts-e can reflect the length of the downstream part of the whole connection chain. The closer the ratio is to zero, the longer the connection chain, and the higher the probability the chain is used as a stepping-stone intrusion. However, K. H. Yung’s method failed to match Send with Echo as well as the acknowledgment packet. This makes the method come with high false-negative errors.
Step-function [
11] and clustering–partitioning [
12] approaches were proposed by J. Yang et al. in 2004 and 2007 [
11,
12], respectively. Both methods can estimate the length of a connection chain precisely and bring down the false-negative detection error rate. The step-function approach can only apply to a local area network. The clustering–partitioning algorithm can apply to the Internet to detect stepping-stone intrusion, but it needs to collect the network packets from the beginning to the end of establishing a connection chain. A cross-over packet is used to detect stepping-stone intrusion [
13]. This is based on an observation that the more the amount of cross-over packets, the longer the downstream connection chain. Unfortunately, cross-over packets can be easily manipulated by intruders’ chaff-perturbation and time-jittering evasion.
In this paper, we explore a novel approach to detect stepping-stone intrusion via the distribution of computer network traffic. The advantages of this approach are that (1) it can bring down false-positive detection errors since it belongs to a network-based detection method; (2) it does not need to collect packets from the beginning to the end of establishing a connection chain; (3) it can resist intruders’ chaff-perturbation manipulation; and (4) it receives a high detection rate.
As we mentioned before, a Send packet from a sender host can be acknowledged (we call it an Ack packet) by its adjacent host and be echoed (we call it an Echo packet) by the end host of a connection chain. If we can match Send packets with its Ack packets, as well as Echo packets correctly, we would obtain a bunch of round-trip times (RTTs) between Send and Ack (we denote this as RTTs-a), as well as Send and Echo (denoted as RTTs-e). The distribution of RTTs-a and RTTs-e can help us estimate the length of a downstream connection chain. This is the basic idea of using the distribution of RTTs of computer network traffic to detect stepping-stone intrusion.
We arranged the rest of the paper as the following.
Section 2 describes the preliminaries needed in this paper.
Section 3 presents a significant result on network traffic distribution.
Section 4 introduces the stepping-stone detection algorithm using network traffic distribution.
Section 5 shows our experimental justification and its analysis. We conclude the whole paper and discuss future work in
Section 6.
3. Significant Results on Network Traffic Distribution
The RTT from a matched Send and Echo packet pair is composed of the delay introduced by each connection in a connection chain. Obviously, the more connections a connection chain contains, the larger the RTT value. In each connection, the network delay comes from the following delays from each router along the connection plus propagation delay: queue delay, processing delay, and transmission delay. Among the four delays from a TCP connection, transmission delay dominates the whole connection chain delay. It is trivial to know that a longer connection chain would bring a larger RTT. From our experimental tests, we found that the longer the connection chain, the more inconsistent the values of RTTs. Since the variation in RTTs from a connection chain follows the Poisson distribution, we use the standard deviation of RTTs to represent its inconsistency. Our experimental results show that the longer the connection chain, the higher the standard deviation of the RTTs from the connection chain. In the following, we introduce the experimental setup and the results.
In order to justify the relation between the standard deviation of the RTTs of network traffic and the length of a connection chain, we designed the following network connection in the JEMES Lab of the TSYS School of Computer Science, Columbus State University, GA. We selected five computer hosts, named CCT30, CCT29, CCT28, CCT27, and CCT26. All five hosts were connected locally to be part of a LAN. They all ran Linux systems and had SSH servers installed. We established an SSH connection from CCT30 to CCT26 via CCT29, CCT28, and CCT27. We operated CCT26 from CCT30. This SSH connection chain has four connections: CCT30→CCT29, CCT29→CCT28, CCT28→CCT27, and CCT27→CCT26. While operating CCT 26 from CCT30, we collected the outgoing network traffic, including Send and Echo packets from CCT30, CCT29, CCT28, and CCT27 using the following tcpdump command. We assumed to collect the outgoing network traffic at the host CCT30 from the connection CCT30→CCT29.
sudo tcpdump -nn -tt ‘tcp port 22 && (host IP-CCT30 && host IP-CCT29) and (tcp[flags] & tcp-psh == tcp-psh)’ > CCT30_TestX.txt, where X represents the number of the test.
The above command can collect Send and Echo packets from the outgoing connection of the host CCT30 and store the collected packets in the file CCT30_Test1.txt if this is the first test. A Send packet takes port 22 as the destination port and uses the IP address of CCT30 as its source IP address and CCT29 as its destination address. An Echo packet takes port 22 as its source port and uses CCT30 as its destination host and CCT29 as its source host. Both Send and Echo packets contain Push flags as Flags [P.]. We repeated the test 10 times. We obtained ten collected packet files, CCT30_TestX.txt, where X = 1, 2, 3, …, 10. Similarly we obtained packet files from CCT29, CCT28, and CCT27 as CCT29_TextX.txt, CCT28_TestX.txt, and CCT27_TestX.txt, respectively. The following shows the format of one collected packet.
1643041500.815242 IP 168.27.2.106.40946 > 168.27.2.103.22: Flags [P.], seq 2409120754:2409120790, ack 3129783136, win 501, options [nop,nop,TS val 1613436092 ecr 2848772024], length 36.
In this collected sample packet, the first field is the timestamp to collect this packet, the second field tells us this is an IP packet, and the following fields tell us the source IP address (168.27.2.106), the destination IP address (168.27.2.103), the source port (40496), the destination port (22), and much other packet header information. Obviously, based on the Send and Echo definition discussed in
Section 2, this is a Send packet. The packet flag field contains the flag information showing that the packet carries data and also acts as an acknowledgment. The following fields show its sequence and acknowledgment number. The last field displays the length of the packet. We apply the method discussed in
Section 5 to process the collected packets in the files CCTY_TestX.txt, where Y = 30, 29, 28, and 27, X = 1 to 10. We obtained the standard deviation of RTTs from the hosts CCT30, CCT29, CCT28, and CCT27. The results can be found in
Table 1.
In
Table 1, each column shows the RTT standard deviation for different hosts, and each row represents the number of tests. From the column of CCT30, we obtain the RTT standard deviation of the outgoing connection chain of CCT30 including four connections: CCT30→CCT29, CCT29→CCT28, CCT28→CCT27, and CCT27→CCT26. The column CCT29 represents the RTT standard deviation of the outgoing connection chain of CCT29. This connection chain contains three connections, including CCT29→CCT28, CCT28→CCT27, and CCT27→CCT26. Similarly, the CCT28 column and CCT27 column represent the RTT standard deviation for the outgoing connection chain of CCT28 and CCT27, respectively. The length of the CCT28 outgoing connection chain is 2, but for CCT27, the length is 1.
From
Table 1, it is trivial to observe that, along with the decrease in the length of the connection chain, the standard deviation of the RTTs obtained in different hosts also becomes smaller. If we examine the row of Test 1, we see that in CCT30, where the length of the connection chain is 4, the standard deviation of the RTTs is 338.77, but for CCT29, CCT28, and CCT27, the standard deviations of the RTTs are 256.48, 66.43, and 31.64, respectively, with corresponding 3, 2, and 1 connections. A similar conclusion can be drawn from each test from Test 2 to Test 10. Only one exception happened in CCT28 from Test 10 as shown in the table.
The experimental result shows that a longer connection chain can introduce a larger standard deviation of the RTTs of the network traffic. A longer connection chain has more routers and hosts involved. Each router or host can introduce network delays, including queue delay, transmission delay, and processing delay. The three delays are indeterministic. They introduce inconsistency of RTTs. The more routers and hosts in a connection chain, the greater the inconsistency of the RTTs of the network traffic. Therefore, the standard deviation of the RTTs of network traffic can be used to reflect the length of a connection chain. It is hard to infer the number of connections in a connection chain. It is impossible to tell if a connection chain is long or short just depending on the standard deviation of the RTTs of network traffic. A measuring unit is needed to determine if a connection chain is long or short. Here is a good metaphor for this: if we have two ropes, one’s length is 180, and the other one’s is 10; it is hard to tell which rope is longer because this depends on the length measuring unit. This will be discussed in
Section 4.
5. Experimental Results and Analysis
An experiment was designed to assess the performance of the detection algorithm. We made a long connection chain using OpenSSH spanning eight hosts, including an attacker host, compromised hosts, and a victim host. Network traffic was collected from each compromised host. We followed the algorithm to compute α for each host. Then, we examined if α becomes larger as the sensor is closer to the victim. This is because a larger α represents a shorter connection chain. The closer a sensor is to a victim, the shorter the connection chain between the sensor and the victim.
5.1. Experimental Setup
In this experiment, we made a connection from one computer CCT30 in the CCT lab to seven AWS servers, AWS1, AWS2, AWS3, AWS4, AWS5, AWS6, and AWS7, and connected back to CCT31 in the same lab. We built an eight-connection chain containing nine hosts with CCT30 as an attacker and CCT31 as a victim. Each host ran Linux OS with SSH client and server installed. The tcpdump tool was also available in each host.
Table 2 shows the AWS server’s public and private IP addresses and their corresponding geographic locations.
5.2. Data Collection
In order to assess the detecting and adaptive performance of the proposed detection algorithm, we simulated three different attackers using different scripts to launch attacks via the host CCT30 to the victim CCT31. The scripts used by the three attackers are shown in the following.
The attacker 1 script was as follows:
pwd
whoami
sudo su
ls
cd/etc
ls −a
scp −p shadow attacker username@attacker IP:/home/seed/Documents exit
The attacker 2 script was as follows:
whoami
pwd
cd/home/seed/Documents
ls
nano text_file.txt
//paste a large text and save it
ls
cat hello.txt
exit
The attacker 3 script was as follows:
whoami
pwd
cd/home/seed/Documents
ls
nano hello.txt
//enter a few sentences and save the text file
ls
cat hello.txt
exit
Attacker 1 first checks the name of its current folder; then checks who they are; changes to admin privilege; checks the details of the current folder; changes its folder to etc, which contains some sensitive files; lists the details in the etc folder; and finally copies a file to the etc folder. What Attacker 2 does includes (1) checking who they are; (2) checking where they are; (3) changing its current folder to home/seed/Documents; (4) listing the files and directories in the current folder; (5) creating a file, text_file.txt, which is a large file; (6) checking if the file is created; (7) displaying the content of hello.txt; and (8) exiting. Attacker 3 does similar things as Attacker 2 does except for creating hello.txt, which is a small file.
Each attacker repeated their corresponding script ten times to make network traffic all the way down from CCT30 to CCT31 via the AWS servers: AWS1, AWS2, …, AWS7. We ran the following tcpdump command on each host except CCT31 to collect Send, Echo, and Ack packets from its outgoing connection.
sudo tcpdump -nn -tt “( dst port 22 && src xxx.xxx.xxx.xxx) || (dst xxx.xxx.xxx.xx && src port 22)” >HostName_Out_AttackX_TestY.txt
We use the server AWS1 as an example to demonstrate how to sniff network packets from a host’s outgoing connection. As we discussed above, the outgoing connection of AWS1 is the connection from AWS1 to AWS2. Therefore, in the above tcpdump command, in order to collect Send and Echo packets, we apply the following rule: the source IP is the IP address of AWS1 with destination port 22, or the destination IP is the IP address of AWS2 with source port 22. The filter “dst port 22 && src xxx.xxx.xxx.xxx” is to capture the Send packets from AWS1 to AWS2, but the filter “dst xxx.xxx.xxx.xx && src port 22” is to capture the Echo and Ack packets from AWS2. In the packet stored file name, the field “AttackX” represents Attacker1, Attacker2, or Attacker3, and the field “TestY” represents the number of tests; here, Y is an integer between 1 and 10 included because each attacking script code was repeated 10 times. For example, if Attacker1 runs its script at AWS1 a third time to launch attacks on the victim CCT31 via the compromised servers, the captured packets are stored in the file “AWS1_Out_Attack1_Test3.txt”. In each host, after completing all three attacks by repeating each attack 10 times, we obtained 30 files, which contain all of the sniffed Send, Echo, and Ack packets. In each file, every sniffed packet is stored in one row. The following shows the format of one captured packet.
1643041500.815242 IP 168.27.2.106.40946 > 168.27.2.103.22: Flags [P.], seq 2409120754:2409120790, ack 3129783136, win 501, options [nop,nop,TS val 1613436092 ecr 2848772024], length 36.
From the above captured packet, we can obtain its timestamp (field 1), source IP and source port number (field 2), destination IP and destination port number (field 3), TCP flags (field 4), sequence number (field 5), acknowledgment number (field 6), and some other trivial fields. The last field is the length of the packet, which is 36 bytes in this example. From the captured packet information, we know this is a Send packet sent from IP 168.27.2.106 and port 40946 to IP 168.27.2.103 with port 22. Obviously, from the port number, IP address, and TCP flags, it is trivial to determine the type of a captured packet: Send, Echo, or Ack.
5.3. Data Processing
In order to compute the RTTs of the captured network traffic and calculate their standard deviations, we need to go through several steps to process the collected data in each host as the following.
Step 1: Obtain Send, Echo, and Ack packets.
Step 2: Match Send packets with Echo packets to obtain RTT-E.
Step 3: Match Send packets with Ack packets to obtain RTT-A.
Step 4: Filter out the outliers of RTT-E and RTT-A.
Step 5: Calculate the stand deviation StdE from RTT-E, as well as StdA from RTT-A.
Step 6: Compute the ratio α between StdA and StdE.
In Step 1, a Python code was made to obtain Send, Echo, and Ack packets from a collected packet data file and store them in Send.txt, Echo.txt, and Ack.txt, respectively. In Step 2, we matched Send packets with Echo packets and computed the RTTs for each matched Send and Echo pair using the data mining approach proposed in 2021 [
14]. The matched RTTs are stored in RTT-E.txt, and similarly, from Send and Ack packets, we could obtain RTT-A as shown in Step 3. In Step 4, a Python code was made to filter out the outliers in RTT-E.txt, as well as in RTT-A.txt. The algorithm used to filter out the outliers is the “Z-score of two” outlier elimination method as we mentioned in
Section 4. In Step 5, we calculated the standard deviation of the matched Send and Echo packets. The longer a connection chain, the more inconsistent the RTTs between the matched Send and Echo pair, and the higher the standard deviation of the RTTs. In order to know how high the StdE is, we calculated StdA. We used StdA as a measure bar to gauge StdE. This is what was carried out in Step 6.
5.4. Data Analysis
The three tables,
Table 3,
Table 4 and
Table 5, show the StdE in 10 tests for Attacker 1, Attacker 2, and Attacker 3, respectively.
Table 6,
Table 7 and
Table 8 show the StdA in 10 tests for Attacker 1, Attacker 2, and Attacker 3, respectively.
Table 9,
Table 10 and
Table 11 show the ratio α between StdA and StdE in 10 tests for Attacker 1, Attacker 2, and Attacker 3, respectively.
The ratio α between RTT-E and RTT-A is supposed to reflect the length of the connection chain from the host where we collect network traffic to the host that is located at the end of the connection chain. Let us examine the ratios we obtained from three attackers, each with 10 tries. The connection chain we made was from CCT30 to CCT31 via AWS servers AWS1, AWS2, …, and AWS7. The chain has eight connections. If we collect network traffic at CCT30, the value of α should be close to 0. Similarly, if we collect data at AWS1, AWS2, … or AWS7, the value of α should be increased from close to 0 to far away from 0 but still bounded within 1. By checking the ratios in
Table 9 for Attacker 1, we found three exceptions with its ratio exceeding 1 (refer to the ratios of Test1-AWS6, Test1-AWS7, and Test4-AWS5). We also found that the ratio decreased when the chain became shorter, which is opposite to our algorithm (refer to the ratios of Test5-AWS3, Test8-AWS6, and Test10-AWS5). In
Table 10 and
Table 11, we did not find any exceptions.
Even though some ratios in
Table 9 are not consistent with the number of corresponding connections, we are confident about one point we observed from the ratios in the three tables. The point is, in general, in each row of
Table 9,
Table 10 and
Table 11, the value of α is increased from CCT30 to AWS7. This indicates that as the length decreases in a connection chain, the corresponding α increases. If we count two neighbor hosts as one pair, such as in
Table 9, the ratio pair (0.15→0.19) maps to two neighbor hosts (CCT30→AWS1), and in
Table 8, we obtain 60 ratio pairs. The ones in Test5-AWS3, Test8-AWS6, and Test10-AWS5 represent abnormal pairs. From the three tables,
Table 8,
Table 9 and
Table 10, we altogether obtain 180 ratio pairs with 3 abnormal pairs. It is trivial to know that among the tests from three Attackers, the abnormal rate is 3/180 = 1.67%.
From the above experimental result, we definitely know that the ratio between StdA and StdE represents the length of a connection chain from the sensor to the end host. The closer to 0 the ratio, the longer the connection chain. This ratio is not affected by intruders’ manipulation because the RTTs of network traffic are from the MMD packet-matching algorithm [
14], which resists intruders’ chaff-perturbation and time-jittering evasion.
5.5. Comparison with the State-of-the-Art Detection Algorithm
To the best of our knowledge, the method of the state-of-the-art detection algorithm is to mine network traffic to detect stepping-stone intrusion [
12]. The strength of the method [
12] is that it can accurately estimate the number of connections in a chain. The weaknesses of the method include (1) it having to capture the session packets from the beginning to the end of establishing a connection chain; (2) it being limited to resisting intruders’ session manipulation; and (3) poor detection efficiency (O(n
2)), where n is the number of packets captured.
For this proposed approach, its strength includes the fact that (1) it is not necessary to monitor a TCP session from the beginning to the end. Therefore, the approach can reduce the number of packets captured and thus improve its detection efficiency. (2) It can resist intruders’ chaff-perturbation to a high capacity. Its obvious weakness is that it cannot accurately estimate the number of connections in a chain. It can only tell if a connection chain is longer or shorter based on the ratio between StdA and StdE.