Long gone is the time when if your website was compromised you’d be eaisly able to spot a file out of place by its date modified and then easily identify the malicious line of code forwarding unsuspecting visitors to your site off to a simple domain or IP address which was out of place. On top of this they would make it even simplier to fix by only making thier changes in a single file.
Then around 5 years ago actors compromising your website would try to make it hard to find what they did by obfuscating their malicious domain or IP address by encoding it with a simple method such as base64 encoding. They also started increasing the number of files they would drop on the compromised host.
However nowadays the efforts they go to has crept up another level. A recent website compromised I was engaged to assit on turned up new index.php files scattered through various directories. These index.php files were heavily encoded as you can see from the images below. Not only were they using base64 encoding but also uuencoding and with each on top of the other. A step further they are also attempting to obfuscate the commands
| command | encoded version |
| base64_decode | ‘b’.’as’.’e’.’6′.’4_d’.’e’.’c’.’o’.’d’.’e’ |
| base64_encode | ‘b’.’a’.’se’.’6′.’4_’.’e’.”.’nc’.’od’.’e’ |
| convert_uuencode | ‘c’.’on’.’ve’.’rt_uue’.’nco’.’de’ |
| error_reporting | ‘er’.’ro’.’r_’.’r’.’epo’.’rt’.’in’.’g’ |
Looking at the code you can find an IP reference shown with a long2IP command long2ip(_e5inno::$_nut8hlqh – 519)
which references a long variable $_nut8hlqh = 2420912559
So take 519 off 2420912559 and convert to an IP returns 144.76.47.168 which while according to https://abuseipdb.com it only has one sighting, that sighting is also a hacking event
You will also see commands referring to search engines such as (strpos($_SERVER[‘HTTP_REFERER’], “google”) and trying to ascertain device types and IP addresses of PCs browsing the site such as @$_SERVER[‘HTTP_X_FORWARDED_FOR’] which is another method they employed to confuse their victim as if you went direct to the website webpages you would be greeted by your standard page though if you went their via a search engine you would be redirected to a malicious 3rd party website.
So basically depending on your client device, IP address and how you reached the site would determine if you were redirected or saw the standard website content.
It also looked for the existance of a robots.txt file and it would attempt to modify the permissions of the file as per $_zpgrv3f5 = $_SERVER[“DOCUMENT_ROOT”] . “/robots.txt”;if (@file_exists($_zpgrv3f5)) {@chmod($_zpgrv3f5, 0777) and add entries to your robot.txt file such as User-agent: Googlebot\nUser-agent: Slurp\nDisallow
The actor also added an include in the /.well-known/index.php file which inlcuded a link to a .inc file which was created in this subdirectory /wp-includes/blocks/categories/.e4d07f78.inc
This .inc file was one of the largest pieces of forensic data left behind.
On top of all the above they also left other files with various naming conventions.
The above goes to show the lengths threat actors go to to obfuscate their code as well as attempts to establish persistence by hiding as many web shells in a compromised server as they can.
The initial compromise was due to plugins which had not been updated and had vulnerabilities. Luckily the website had offsite backups and was able to be recovered
Keywords
$_sqlgr hex2bin array_merge sys_get_temp_dir
