The attacker's accessed a URL ending in /wp-content/plugins/apikey/class-wc-action-queue.php.
My WordPress honey pot treated that as an access of a WSO web shell without a password,
and sent back a WSO login page.
The next access of class-wc-action-queue.php sent HTTP parameters with names and values
consistent with WSO shell access,
this time the "Php" action.
Some attackers use the "Php" action instead of the "RC" action.
Both will evaluate PHP code sent to them in an HTTP parameter named "p1",
but the "RC" action is more for "API" style access,
while the "Php" action is used by JavaScript in the WSO web shell allowing for
humans to enter PHP code in their brower,
and have WSO execute it on the server.
| Parameter | Value |
|---|---|
| pass | asdf |
| charset | Windows-1251 |
| a | Php |
| p1 | $fdsju = base64_decode("JGZ... |
A cold access, no password guesses, then an access with a password of "asdf" in quick succession. This indicates programmatic access. At a guess, the attackers had a list of WSO web shells by URL and password, and a program that ran the last and tried to run the dropper code on each WSO.
Invocation of URLs containing ``/plugins/apikey/, and ending in other than apikey.php`
didn't happen against my web server until 2019-05-30.
I added "test" mode for `apikey.php` to my honey pot 2019-04-05,
and download support 2019-05-27.
My honey pot has tricked attackers into downloadng a lot of malware since 2019-05-27.
I know that one or more WSO web shells have appear in those downloads.
187.94.220.193 has a DNS name of 187-094-220-193.acessecomunicacao.com.br
87-094-220-193.acessecomunicacao.com.br has no A record
whois has the IP address owned by acessecomunicacao.com.br,
so that checks out.
inetnum: 187.94.208.0/20
aut-num: AS53078
owner: Acesse Comunicação Ltda
ownerid: 10.462.644/0001-55
country: BR
owner-c: FERSA4
tech-c: FERSA4
inetrev: 187.94.216.0/21
nsstat: 20190530 AA
nslastaa: 20190530
nserver: ns2.acesseradio.com.br
nsstat: 20190530 AA
nslastaa: 20190530
created: 20091001
changed: 20130307
The code contains a Base64-encoded .htaccess file.
It apparently puts the .htaccess file in Apache's DocumentRoot.
It makes an attempt at working on both Windows and Linux installations:
The .htaccess file itself has a mess of leading tab characters,
possibly to convince a human with a text editor that the file is empty.
Is there any evidence that this sort of thing works,
or is it just superstition on bottomfeeder's part?
The .htaccess file would contain a single directive:
ErrorDocument 404 http://excellentrxgroup.su/
excellentrxgroup.su has a DNS A record of 95.110.232.65
95.110.232.65 has a DNS PTR record of host65-232-110-95.serverdedicati.aruba.it
Not much to excellentrxgroup.su in whois:
domain: EXCELLENTRXGROUP.SU
nserver: ns1.excellentrxgroup.su. 103.117.212.108
nserver: ns2.excellentrxgroup.su. 112.78.10.214
state: REGISTERED, DELEGATED
person: Private Person
e-mail: [email protected]
registrar: R01-SU
created: 2019-05-14T17:16:03Z
paid-till: 2020-05-14T17:16:03Z
free-date: 2020-06-16
source: TCI
Last updated on 2019-06-01T17:26:31Z
Based on it's name, one would guess "excellentrxgroup.su" is just another boner pill scam site.
geoiplookup does agree that 95.110.232.65 has an Italy location,
which agress with whois info about 95.110.232.65,
and it's PTR record.
traceroute even agrees: 95.110.232.65 lives in Aruba, Italy.
Wow!
After dropping .htaccess the code used to do a blacklist check
for the hostname the dropper runs on, PHP's $_SERVER['HTTP_HOST'].
This part is essentially commented out:
the code's author(s) put in a PHP exit; after the code
creates a .htaccess file.
This is puzzling: why not do this after you got some code to run on a compromised WordPress installation? You've already researched, designed, written and tested the code. You've probably used the results in the past. Commenting it out just seems sloppy.
In any case, if executed, the code checks with 23 blacklists to see if the compromised WordPress install is regarded as a spam site.