# An Exploit Traffic Detection Method Based on Reverse Shell
## 4 Evaluation
### Experimental Design Scheme
#### 4.2.3 Comparison of Detection Results of Exploit Traffic  
Experiment 3 compares the detection ability of ETDetector and Blatta, the most popular method to date.  
The experimental results show that only 5 exploits of code execution were detected in Reference [11], while ETDetector detected 9 exploits, and rate-total increased by 40%. For the four exploits under the condition that the traffic is not encrypted, the corresponding traffic can be detected in Reference [11] and ETDetector  and there is no significant difference in the rate-encrypted index. However, for the six times of code execution vulnerability exploitation under traffic encryption conditions, only one time was detected in Reference [11], while ETDetector was detected five times, and rate-encrypted increased by about 66.7%. This is because the method in Reference [11] detects based on traffic load. In the case of unencrypted traffic, plaintext features of shellcode in the load can be extracted; however, in the case of encrypted traffic, the content of the payload is invisible, and effective information cannot be extracted effectively, so encrypted traffic cannot be detected. However, ETDetector extracts traffic behavior characteristics independent of load content. Even under the condition of traffic encryption, as long as the TCP protocol is used, the traffic communication behavior characteristics conform to the law, and it can be effectively detected.  
According to Table 4, the ninth reverse shell attack avoids both methods. Through analysis, the related module is Windows/Meterpreter/reverse_http, which communicates by HTTP sessions initiated by the target machine, intrinsically different from TCP-based reverse shells, so the fusion information feature in Section 3.1.2 cannot detect it. Since the ultimate purpose of detecting reverse shell traffic in this paper is to locate the target machine, there is no restriction on the specific methods to achieve reverse shell traffic detection. Therefore, for the reverse shell traffic implemented by HTTP/HTTPS protocol, supplementary experiments were carried out by combining some existing vulnerabilities and using tool traffic detection methods. The results show that as long as the reverse shell traffic can be detected and the target machine can detect the whole process of vulnerability exploitation traffic according to the session relationship, there is no significant impact on the detection results. Therefore, in practical applications, accurate positioning of the target machine can be realized in combination with the detection methods of the reverse shell against other protocols, to realize the detection of vulnerability exploitation traffic.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Feature Vector Type** & \multicolumn{3}{c}{**Mean Time Required/s**} \\ \hline  & **1:50** & **1:100** & **1:300** \\ Packet delay sequence & 3.614 & 4.384 & 7.868 \\ Packet direction sequence & 3.392 & 4.120 & 7.105 \\ Packet length sequence & 3.505 & 4.292 & 7.335 \\ Packet delay + packet direction sequence & 3.587 & 4.364 & 7.901 \\ Packet length + packet direction sequence & 3.601 & 4.185 & 7.368 \\ Packet delay + packet length sequence & 6.522 & 7.716 & 14.36 \\ Packet delay + packet length + packet direction sequence & 6.424 & 7.943 & 13.992 \\ Fusion information feature vector & **0.863** & **0.949** & **1.379** \\ \hline \hline \end{tabular}
\end{table}
Table 3: Comparison of detection results before and after feature fusion.