While recently looking over my honeypots, I discovered an infection where a malicious actor added a storefront on top of my existing WordPress installation. For background, this particular honeypot is a full instance of WordPress running on a Docker image. The administrator credentials are intentionally weak, in order to give those with malicious intent easy access. This way I can examine what attacks the vulnerable site will undergo and what the login access will be used for. It didn't take long for the attacker to guess my credentials, and once obtained, they used their access to upload a malware-infected plug-in.
The malware overwrote the index.php file and added a function that checks the query parameter for a certain string. If this string is found, then a different site is served up. The code itself is obfuscated with gzip, base64 encoding, and some rot13 thrown in the mix in some cases.
The malware also adds an .htaccess file to redirect specially crafted requests to their parasitic code:
# BEGIN WordPress RewriteEngine On RewriteRule ^[a-zA-Z0-9_-]+/([0-9]{1,7})([a-zA-Z0-9]{4})[a-zA-Z0-9_-]+\.htm$ index.php?smsite=$2&smid=$1 [L] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]
So a GET request like 10001dguaara555 will be rewritten to /index.php?smsite=dgua&smid=10001&smtemp=test
Infector IP: 198.204.226.130
C2: host twenty-three2.aucsaitoimport.xyz -> twenty-three2.aucsaitoimport.xyz has address 69.197.158.94
"GET /test/10001dguaara555 HTTP/1.1" 200 3626 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "GET /index.php?smsite=dgua&smid=10001&smtemp=test HTTP/1.1" 500 211 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Request Headers
In the screenshot below, we see the request headers are out of order, and the User-Agent string is attempting to look like a Google bot. The reason the attackers are attempting to mimic a known bot is to hide within the logs. This is a common, albeit poor, obfuscation attempt. Also, the Accept-Language header is set to Japanese. There is also the presence of the Do Not Track (DNT) Request Header. DNT is a HTTP-header field designed to allow users to opt-out of activity tracking on a given website (if DNT is supported), and is being used here as a moot layer of obfuscation. This implies that the connecting client can handle cookies.
Malware IOCs
I've found multiple WordPress source files where malware has been prepended to the code.
1b66033e4e6e1941245fdf48b4a1adee43cd8cadd1d9177ce7464fa04827585a xmlrpc.php 40d1342db0f4e5116fd8844e010097f5c6a99ea3933f780fbd6305f6898d03c1 wp-config.php 2e28c01f8f99c27a115f2a67244770d4a79f93df3a2f745207a8e13b984ae1a7 index.php
The C2 traffic occurs between host twenty-three2.aucsaitoimport.xyz current IP 69.197.158.94.
Clear and Obfuscated Malware
As you can see in the image below, it is likely that the malware has been obfuscated through an obfuscation app. These apps turn the code into a hot mess of variables, which lead to other variables, in order to decode the source. Such tricks make it hard for novice researchers to access the source code being used, and are leveraged in order to extend the life of the attack.
After a lengthy deobfuscation mission, I managed to find an unobfuscated copy of the source code. I'll be using this code in my analysis and testing in this blog.
Malware Interaction with C2
The first arrow points to where the code checks if 'nobotuseragent' has been received from the C2. This is a check to see if the connecting request is from the bot or not, and is important as the criminals want to avoid bots and target actual humans in their scam.
The second arrow points to a check for 'okhtmlgetcontent', which then is followed by the site HTML to print back to the requesting browser at the second arrow.
The malware also uses password authentication to verify that the C2 it is speaking to is legitimate, the password is 'smedit' and they use the md5 hash of the md5 hash to verify it.
Traffic Flow
Here is how the attack / traffic flows:
-
Request from web user browser to the infected WordPress site
-
Malware forwards request to command and control server
-
If request is valid return 'okhtmlgetcontent' with e-commerce site HTML
-
Pass on HTML received from C2 to web user's browser
Below are the GET requests and Response headers from the web client and webserver.
GET /index.php?url=&id=&temp=&dt=0&web=INFECTEDIP&zz=&clock=CLIENTIP&uri=L2Z1aml4LzE2MzA3c3lkemRzLTEzMTE0NDY=&urlshang=&http=http HTTP/1.0
L2Z1aml4LzE2MzA3c3lkemRzLTEzMTE0NDY is the base64 encoded store URL /fujix/16307sydzds-1311446
The C2 responds with 'okhtmlgetcontent' and the HTML for the ecommerce site:
HTTP/1.1 200
OK Date: Wed, 11 Nov 2020
13:51:06 GMT
Server: Apache/2.4.6
X-Powered-By: PHP/7.0.10
Connection: close
Content-Type: text/html; charset=UTF-8
okhtmlgetcontent<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="ja" id="masterChannel-ait">
<head>
A screen shot from a tcpdump of the HTTP traffic
Sitemaps Generation
The malware creates sitemaps for Google to index on the fly, so the sitemap file isn't actually written to disk. My honeypot infection, as far as I could tell, was hosting more than 7,000 e-Commerce websites. There were six different sitemaps, all stored in robots.txt that was generated by the malware after infection.
SEO In Google
The screenshot below is one of the products being distributed through the malware infection on the honeypot. They are common, everyday items designed to just take up space on the web and game search rankings.
C2 Commands
The following table documents the three commands that the C2 expects from an infected site. These are all used to manage the handling of store content on the infected site, in order to keep the storefronts and sitemaps updated.
Command Action
ping Submit site to google for reindexing
put Add store content to sitemap file
del Delete store content from sitemap file
SEO Ransom Attacks
We've gotten reports of criminals poisoning Search Engine Optimization (SEO) results for companies, and then demanding a ransom to cease their interference with the target's online profile.
The actor claims they have the ability to poison the SEO results for the target by injecting negative reviews and messages into forums, and then linking those with the target sites search results. They demand payment in BTC and also offer their services in targeting the competition.
While inconclusive, malware like what hit my honeypot could be used for these types of attacks. This makes them a low-barrier attack for criminals to pull off, as they only need a few compromised hosts to get started. Given that there are hundreds of thousands of abandoned WordPress installations online, and millions more with outdated plug-ins or weak credentials, the potential victim pool is massive.
Bottom line, this attack proves that if you can modify something without authentication, it will be abused.
Article Link: https://blogs.akamai.com/sitr/2020/11/wordpress-malware-setting-up-seo-shops.html