2014-01-03 by Ante Kresic
We found another interesting piece of PHP-based malware on a client site a few days ago:
Can you decode and see what it is doing? ..
This piece of code tries to obfuscate all the functions that could be
flagged by a scanner using a benign php function called str_replace. This function replaces all instances of a string with a replacement in the subject. So, for example, the next line:
$ts = str_replace("b","","bsbtr_brbepblabcbe");
Replaces all instances of character 'b' with nothing. So from bsbtr_brbepblabcbe we get str_replace. Using the same technique, we have some more functions:
$dzy = $ts("er", "", "erberaersereer6er4er_dereercerodere"); //base64_decode
$mc = $ts("y","","ycyryeyaytye_yfyuynctyiyoyn"); //create_function
All this for creating a function and running it in this line:
$tha = $mc('', $dzy($ts("nd", "", $exg.$sjb.$iyo.$fy))); $tha();
Function code is contained in the next expression:
$dzy($ts("nd", "", $exg.$sjb.$iyo.$fy));
And the final code is:
What it does? It uses some simple tricks to edit the contents of the cookie, decode it from base64 and eval (execute) that malicious code.
According to our daily malware analysis experience, we've noticed that the bad guys are using obfuscation more and more
to hide what they are doing. Take for example this piece of code we found injected on a website:
No sign of any "eval()" and no sign of "preg_replace()" with the eval switch like in the majority of malware files.
When I looked at it for the first time, I thought that that’s just some corrupted/incomplete malware which can’t work. But one of the prerequisites for my job is "being curious" - And I am, so I checked it more deeply and... the result was interesting!
First, I decided to beautify the code to see it more clearly…
Those commented lines at the bottom are my own – they helped me to understand what’s under each variable and how it works.. As you can see, it has a getenv, preg_replace, base64_decode and when you put it all together, you get the readable code:
And that’s it – yes, there actually ARE eval() and even base64_decode() functions, but hidden behind variables. Otherwise, it's really just malicious backdoor component which reads some custom environment variable where the actual payload should be stored.
Curious about other ways of running the code in PHP without using eval() at all?
Most common is preg_replace with that “/e” switch (directly evaluates the expression after replacing), one of less common, but very interesting is the PHP assert() function. As mentioned in the PHP official documentation: If the assertion is given as a string it will be evaluated as PHP code by assert(). And there are others surprises in PHP...
recent post on the Joomla password stealer, here's another beautiful example of password stealer. This time from WordPress environment.
It's easy to understand, but what's interesting - it looks like legitimate code so you can easily overlook it. It stores its data in "png" files within ./wp-includes/images/
path and sends them to a non-obfuscated email address.
This is the bad part that was injected on the file user.php on wp-admin:
Anyway, keep your eyes open, guys :)
As we know, one of the main payloads of a successful attack is to maintain access to the compromised server for as long as possible. Today we found this simple but effective password stealer for Joomla.
It was injected in /administrator/components/com_login/models/login.php, and the code just captures the $credentials array, username and password to be more specific, and writes to a login.txt file, which was accessible through the internet.
To make things even easier for the attacker, it writes the date and time of the capture on Chicago Timezone (so is the attacker in Chicago?).
Just came across this backdoor (decoded):
It looks like a normal backdoor, but the interesting part and the one I didn't understand completely was this one:
What is it doing?
Why is it reading from php://input? From the PHP manual it explains:
2013-10-24 by Daniel B. Cid
We woke up this morning to many reports and people asking why the PHP.net site is being blacklisted.
We did not get a chance to analyze it while it was compromised, but it seems that one of their
That's the supposed bad code: http://pastebin.com/raw.php?i=nAess4xL
It seems the PHP team fixed it already and requested Google to clear it. If anyone has more info, we would love to hear it.
2013-10-09 by Daniel B. Cid
A common keyword that people use to find hidden injections on web sites is "base64_decode". You
often see injections that look like "eval ( base64_decode" or eval ( gzinflate ( base64_decode" being
used by the attackers.
So most web security tools have some signatures to look for it (specially on WordPress).
Well, the attackers do know about it as well and we are starting to see some interesting variations for it. For
example, instead of injecting base64_decode, they are injecting as a variable:
And instead of calling out base64_decode directly, they are using base + 32*2 + decode. A simple trick that allows
then to bypass many security filters.
2013-07-14 by Daniel B. Cid
Piwik is an open source web analytics software that is used by many web masters. And
the bad guys are using their popularity to try to make their malware injection harder to
It is not an uncommon tactic (we see if often with jquery), but as a web master if you see anything
from pwiki-stat or similar variations, it is likely fake. The official (and trusted one)
Today we found a malicious iframe that was being loaded from juquery.com (another fake jquery site). It
consisted of the following code hidden inside one of the plugins:
It forces the site to contact juquery.com/jquery-1.6.3.min.js on every page load and display whatever content is provides. It
is currently displaying the following malicious payload (triggered by sitecheck
Which creates another iframe based on the payload hosted at: httx://www.juquery.com/compability.php?0.09432658250443637:
Which also decodes to the iframe loading script:
It seems that fake jquery sites are becoming more and more popular and only jquery.com and jquery.org should
2013-07-03 by Daniel B. Cid
I don't think we have logged about it lately, but an old infection (that started early this year)
is still going strong. The result is this code being injected to the site when visited by
And the hidden code that generates it is tricky to find and generlly hidden inside one of the theme
files or wp-includes (on WordPress sites). It looks like this:
All that to the end goal: Inject an iframe from *no-ip.biz (and other free domains) that will redirect the browser of the victim to Fake AV.