Need cloud computing? Get started now

Dark background with blue code overlay
Blog
RSS

WordPress Malware Setting Up SEO Shops

Larry Cashdollar

Written by

Larry Cashdollar

November 20, 2020

Larry Cashdollar

Written by

Larry Cashdollar

Larry W. Cashdollar has been working in the security field as a vulnerability researcher for more than 20 years and is currently a Principal Security Researcher on the Security Intelligence Response Team at Akamai. He studied computer science at the University of Southern Maine. Larry has documented more than 300 CVEs and has presented his research at BotConf, BSidesBoston, OWASP Rhode Island, and DEF CON. He enjoys the outdoors and rebuilding small engines in his spare time.

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.

Larry Cashdollar

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. 

Larry Cashdollar

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.

Larry Cashdollar

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.

Larry Cashdollar

Traffic flow

Here is how the attack / traffic flows: 

Larry Cashdollar
  1. Request from web user browser to the infected WordPress site

  2. Malware forwards request to command and control server

  3. If request is valid return 'okhtmlgetcontent' with e-commerce site HTML

  4. 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 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.

Larry Cashdollar

SEO in Google

Larry Cashdollar

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. 

Larry Cashdollar

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.



Larry Cashdollar

Written by

Larry Cashdollar

November 20, 2020

Larry Cashdollar

Written by

Larry Cashdollar

Larry W. Cashdollar has been working in the security field as a vulnerability researcher for more than 20 years and is currently a Principal Security Researcher on the Security Intelligence Response Team at Akamai. He studied computer science at the University of Southern Maine. Larry has documented more than 300 CVEs and has presented his research at BotConf, BSidesBoston, OWASP Rhode Island, and DEF CON. He enjoys the outdoors and rebuilding small engines in his spare time.