A few days ago, i was called to investigate a security breach on a webserver. The company server was apparently serving drive-by-download exploits to visitors. So, i opened their website to see what was going on – and indeed, Firefox offers me to run a Java Applet (oh Java…):
Firefoxing offering a malicious JRE exploit
I friendly declined to run the applet and refreshed the page. However, when i refreshed i didn’t get served the applet again. So i took a look at the HTML source. Surprisingly, there was no sign of applet code, iFrames or anything else that looked suspicious. I deleted cache and cookies, refreshed the page once more, but still no exploit. So i opened the site in Chrome, same thing, nothing served. Time to look into the actual files on the server.
The code – part #1
So i connect to the machine, and right away, looking at the timestamp, i noticed the index.php file was recently modified. I download the index.php and this is what i find at the very end of the code:
Note i did not add the comments to the code, they left them in there. This code was placed at the end of all .php files. Let’s take this thing apart. The thing that should grab you attention right away is the base64 encoded string:
This base64 string decodes into:
When opening mbr*wserstats.c*m or mbr*wserstats.c*m/statH/, you will be redirected to http://botsvsbrowsers.com/ (a legit site that collects different User-agent strings). So at first this looks like some vistitor statistics thingy. But it’s not. Only when calling the full path to the stat.php file, you will get to the real server at mbr*wserstats.c*m.
Next let’s look at this piece of the code:
This part will check if the current visitor is a search engine crawler. If it is, it will not be served the exploit. This is to prevent the infected site being blacklisted by Google, Mozilla or AV software. Back to the code:
This is where the exploit is placed. The code forms a request for the attackers server. The request includes your IP and the site you are comming from. It will perform this request using curl and include the answer from the malicious server in the site being served.
Alose note the $sRetry at the very beginning of the code, this is so the request will not be serverd twice to the same user, when he refreshes the page. However, they must be doing some sort of further server-side checking because doing a fresh request without the POST data will also not serve the applet again (using a new IP will trigger the exploit again).
The code – part #2
The code analyized above was placed in all .php files. But the attackers also added a line of HTML to all files with an .html extension. The line, placed before the closing body-Tag is an iFrame linking to an local .php file, counter.php, that was created by the attacker.
Analysis on the counter.php will be published in a few days.
Who is behind this?
Take a look at image at the top of this post. Although the curl request is going to the mbr*wserstats.c*m server, the malicious applet is coming from the server at nearre*lt*megobs.b*z,
Both domains resolve to servers located in St.Petersburg, Russia. nearre*lt*megobs.b*z was registered just a few days ago using a domain registration service that hides the Whois entry. The other domain, mbr*wserstats.c*m, seems to be registered with fake info (adress and phone number do not exist) in February this year and is using Clowdflare DNS (hey, you got to load-balance your malware network!).
How did the attacker get access to the server?
I can’t tell for sure. The site they have is not running any scripts or CMS with known vulnerabilities and i could not find any security flaws in their code. So my best guess is that someone with FTP access had malware on their computer that stole the FTP credentials. Needless to say, they should not be running FTP anyway since the passwords are transfered in clear-text (use SFTP).