Decrypting Behinder Webshell: Challenges and Solutions for Financial Institutions

Introduction

In 2019, I was stationed at a financial institution. I participated in two offensive and defensive exercises in September and November 2019, responsible for organizing, providing technical support, and reviewing the exercises. During this period, multiple attack teams used the Behinder webshell. While the defense side’s IDS did report webshell connections, they couldn’t see the request and response details. Currently, there are IDSs on the market that can decrypt Behinder ciphertext. However, in my department, the security equipment from three vendors couldn’t identify or decrypt Behinder webshells, so the client requested a method to decrypt the ciphertext. The screenshot of the downloaded pcap package is as follows:

>

Note: This article discusses the PHP version of Behinder v2.0.1.

1. Behinder – Dynamic Encryption Algorithm

(1) Introduction to Behinder

Behinder is a new type of webshell client developed in Java that features dynamic encryption of communication traffic. The old webshell management tool, China Chopper, has obvious attack traffic characteristics, making it easy to detect by various security devices, and is used less frequently in real scenarios. Encrypted webshells are becoming increasingly popular.

Because the communication traffic is encrypted, traditional WAF and IDS devices find it difficult to detect, posing a significant challenge to threat hunting. The main feature of Behinder is symmetric encryption of interactive traffic, with the encryption key dynamically generated by a random number function, making the client’s traffic almost undetectable.

The latest version of Behinder is v2.0.1, with increasingly improved compatibility, including powerful features such as virtual terminal, Socks proxy, file management, reverse shell, and database management, making it easy to deploy and use.

>

Figure 1-1 Behinder webshell

(2) Communication Principle of Behinder Tool

The communication process of Behinder can be divided into two stages:

1. Key negotiation
2. Encrypted transmission

1. First Stage – Key Negotiation

1) The attacker requests the server key through a GET or POST method, such as http://127.0.0.1/shell.aspx?pass=645;

2) The server uses the high 16 bits of the MD5 of a random number as the key, stores it in the session’s $_SESSION variable, and returns the key to the attacker.

2. Second Stage – Encrypted Transmission

1) The client encrypts the command to be executed using the AES algorithm or XOR operation and sends it to the server;

2) The server decrypts the ciphertext using AES or XOR operation and executes the corresponding command;

3) The execution result is encrypted with AES and returned to the attacker.

Figure 1-2 Behinder Execution Flowchart

Details of Behinder (v2.0.1) data packets captured in Wireshark are shown in Figures 1-3 and 1-4:

2. Behinder Feature Detection

Summarizing the characteristics of Behinder in traffic interaction, these features can be divided into two categories. One category is bypassable features, which attackers can bypass by constructing packets, making it impossible for devices to detect Behinder webshell features. The other category is non-bypassable features, where attackers cannot change certain HTTP fields in some scenarios, resulting in fixed packet fields that devices can detect. Using a single feature has a high false positive rate, but using multiple features together can reduce false positives. It is recommended to use multiple features in combination to further improve the accuracy of feature detection.

(1) Bypassable Features

1. Accept Field

The Accept field is commonly used in the HTTP protocol, but the default value of the Accept field in Behinder is very special, and this feature exists in any communication stage of Behinder. As follows:

Accept: text/html,image/gif, image/jpeg, *; q=.2, */*; q=.2

Figure 2-1 Request Body Accept Field

2. UserAgent Field

Behinder has more than ten built-in UserAgents, and each time it connects to a shell, it randomly selects one to use. If multiple UserAgents from the following list are found in historical traffic from the same source IP accessing a certain URL, it can be basically confirmed as a Behinder feature. The following UserAgent list is extracted from Behinder’s jar package.

Request Body UserAgent as shown in Figure 2-2

3. Long Connection

Behinder communication uses long connections by default to avoid resource overhead caused by frequent handshakes. By default, the request and response headers will contain Connection.

Connection: Keep-Alive

Request Body Connection as shown in Figure 2-3

(2) Non-bypassable Features

1. URL Parameter During Key Transmission

During key transmission, the URI has only one parameter, a key-value type parameter, with only one parameter. The key is the password set by the hacker for the shell, usually less than 10 letters and numbers, and few people set special characters as a one-sentence password (we do not consider rare cases). The value is generally a 2 to 3-digit random pure number. Additionally, the webshell’s extension is generally an executable script, as follows:

\.(php|jsp|asp|aspx)\?(\w){1,10}=\d{2,3}  HTTP/1.1

Request Key URL Figure 2-4:

2. URL Parameter During Encryption

During encrypted communication, there are no URL parameters. As follows:

\.(php|jsp|asp|jspx|asa)    HTTP/1.1

3. Transmitted Key

The key used for encryption is a 16-character random string composed of lowercase letters and numbers. During the key transmission phase, the key exists in the Response Body. The regex is as follows:

^[a-fA-F0-9]{16}$

Return Random Key as shown in Figure 2-5:

4. Encrypted Data Upload

During encrypted communication, the php/jsp shell will submit base64 encoded request data. The following regex can match it well. The number 20 specifies that the character must appear at least 20 times to match. The regex is as follows:

\r\r[a-zA-Z\d\+\/]{20,}

5. Encrypted Data Download

This feature also exists during encrypted communication, where the data in the return packet is encrypted binary data. Here, the regex uses “non” to match uncommon binary characters. The regex is as follows:

” [^\w\s><=\-‘”\:\;\,\!\(\)\{\}][\w]{2}[^\w\s><=\-‘”\.\:\;\,\!\(\)\{\}][a-zA-Z\d]{2}”

3. Behinder Packet Decryption

(1) Decryption Idea

When the PHP OpenSSL extension script is enabled on the server, Behinder ciphertext uses the symmetric encryption algorithm AES for encryption, and it is also base64 encoded after encryption. After the client initiates key negotiation, a 16-character plaintext random key will be returned. If the security monitoring device collects traffic comprehensively, the ciphertext traffic and key can be intercepted, and the Behinder ciphertext details can be obtained through a decryption and decoding platform.

(2) Preparation Tools

AES Online Decoder (http://tools.bugscaner.com/cryptoaes/)

BASE64 Online Decoder (https://tool.oschina.net/encrypt?type=3)

(3) Implementation Method

1. Obtain Key

Obtain the key from the request key data packet: 29ab481053a0ebeb

2. Obtain Request Ciphertext and Return Ciphertext

>

3. Use Online Decryption and Decoding Platform

(1) Enter the key and request ciphertext, decrypt it to base64 encoding; base64 decode

whoami decryption

whoami decoding

(2) Enter the key and return ciphertext, decrypt it to base64 encoding; base64 decode

This article studies the PHP language. When the PHP OpenSSL extension script is enabled on the server, Behinder ciphertext uses the symmetric encryption algorithm AES for encryption, and it is also base64 encoded after encryption. After the client initiates key negotiation, a 16-character plaintext random key will be returned. If the security monitoring device collects traffic comprehensively, the ciphertext traffic and key can be intercepted, and the Behinder ciphertext details can be obtained through a decryption and decoding platform.