Threat Actors Rapidly Adopt New ThinkPHP RCE Exploit to Spread IoT Malware and Deploy Remote Shells

Threat actors wasted no time jumping on this new exploit to launch new campaigns for reconnaissance, uploading back doors, and deploying variants of the Mirai botnet.
December 19, 2018
7 min. read

Key Points

  1. Only a few days after the ThinkPHP vulnerability was discovered, it is already being exploited on the Internet.
  2. Almost 46,000 servers, most of which are located in China, are potential targets for this exploit.
  3. Multiple campaigns have been launched simultaneously by different threat actors, which might suggest the infection potential.
  4. Campaigns vary from reconnaissance and uploading of back doors to deploying a variant of the Mirai IoT malware.

F5 researchers have observed multiple new campaigns leveraging a very recent exploit against ThinkPHP, a popular PHP framework in China. Within days of its discovery, the vulnerability had already been exploited in the wild by multiple threat actors. With this vulnerability, we see a pattern similar to those we have seen in other RCE vulnerabilities, such as Apache Struts 2 – CVE-2017-5638 mentioned last year, where attackers rushed to capitalize on the time it takes organizations to patch and profit from it. New ThinkPHP vulnerability campaigns with a variety of purposes are being launched every couple of days. In our experience, although rapidly deployed, these campaigns can last for more than a year.

Remote Code Execution Vulnerability

On December 9, ThinkPHP released a security update stating that a recent vulnerability had been patched.1 According to ThinkPHP (translated from Chinese), “Because the framework does not detect the controller name enough, it may lead to possible ‘getshell’ vulnerabilities without the forced routing enabled.” After looking into the vulnerable code, it is clear that this vulnerability stems from a non-validated input, which allows an attacker to trigger an app.invokefunction function to actually run any desired functions on the affected system. This vulnerability affects versions 5.0 and 5.1 and was fixed in versions 5.0.23 and 5.1.31.

Figure 1. The ThinkPHP security update released on December 9 (translated from Chinese)

On December 11, a proof of concept (PoC) exploiting this vulnerability was published on A day later, another PoC was published on, and another PoC popped up in the forum on ThinkPHP’s official website.

Figure 2. The vulnerability published on ThinkPHP’s official website (translated from Chinese)

Shortly after these published PoCs, we started seeing this exploit in new and active campaigns.

Infection Potential

Many might not have used or even heard about ThinkPHP, but this PHP-based open-source web-application framework is very popular in China. A quick Shodan search shows almost 46,000 servers running ThinkPHP are potentially vulnerable to this very recent vulnerability. Thousands of servers running ThinkPHP are also found in Hong Kong, the US, and other countries.

Figure 3. Shodan shows almost 46,000 servers in various locations worldwide running ThinkPHP

Reconnaissance Campaigns

Multiple campaigns are passively exploiting this vulnerability while executing code that, in most cases, just returns a string sent by the attacker in case a server is vulnerable. Usually these are the researchers or adversaries who later expand the campaign with more malicious intents.

Figure 4. Attacker sends malicious payload to determine if the targeted server is vulnerable

Installing a Back Door

Another campaign we spotted was trying to deploy a PHP shell on vulnerable servers.

This campaign uploads a PHP shell to the targeted server, to later be used as an arbitrary code injection endpoint. The first request tries to upload a base64-encoded PHP file named “images.php”.

Figure 5. A request delivering the php back door

Once the base64 file is decoded, the <?php tag is noticeable, but the file is still obfuscated.

Figure 6. The decoded base64 string, a php file, is still obfuscated

After de-obfuscating the PHP code, we get a much clearer version of the code. Its main function is to run arbitrary PHP code using the eval function.

Figure 7. The de-obfuscated php shell

Here we see a nice trick that allows the threat actor to restrict access to the PHP shell to only those who know a secret, without the secret appearing in the shell’s code. MD5 followed by a SHA1 calculation is done on the provided secret and the injected code will execute only if the substring of this calculation equals a specific value. This allows the threat actor to prevent possible takeover of this shell by other threat actors.

Once the PHP file is uploaded to the server, the attacker sends another request, verifying the back door is in place.

Figure 8. The attacker’s second malicious request, sending the secret and the injected code

Decoding the injected code using base64 results in the code: die("Hello, Peppa!"), which prints the message and exits the running PHP script.

This exact payload—“Hello, Peppa!”—was actually used in another campaign launched half a year ago. It targeted vulnerable PHP servers to deploy back doors. It was likely launched by the same threat actor.

Spreading IoT Malware

A very recent campaign exploits this vulnerability to spread Hikari IoT malware, a recent variant of the infamous Mirai malware.

Figure 9. Hikari botnet spreading using ThinkPHP exploit

The exploit downloads a spearhead bash script using the curl command. This bash script then downloads and executes the binaries of the Hikari botnet malware, while each executable targets a different processor architecture, focusing mostly on IoT (ARM, MIPS, SH4, etc.).

Figure 10. bash script downloads and executes Hikari executables targeting various architectures

Threat Actors Are Upgrading Their Arsenals

These campaigns are a good example of a pattern we have seen for several years now, where threat actors adapt newly published exploits in their existing campaigns. Recent evidence of this pattern includes the CroniX campaign, with its threat actor originally exploiting Jenkins servers via CVE-2017-1000353 and later moving to deliver malware using the Apache Struts 2 namespace vulnerability (CVE-2018-11776).

What to Do?

ThinkPHP has published an official security update patching this vulnerability and upgrading to version 5.0.23 or 5.1.31 will immediately solve the issue. That said, having an advanced web application firewall solution should be a priority for organizations who wish to protect their assets, regardless of whether they’ve already deployed a patch on their servers or not.

Implement a web application firewall
Patch vulnerable systems
Join the Discussion


What's trending?

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read