Analyzing a Malicious iFrame – Following the Eval Trail

Over the last week, we’ve been working with some interesting malware injections. Developers and malware prevention professionals usually think of hidden iframes that deliver spam-seo or other malware as “easy to spot”. Take this injection, for example (thanks to Sucuri team member, Rafael C., for the sample):

Sucuri - JS Infection II

This is not your traditional iframe src=’http://… code, but you can see where the bad code lives in the example above. This is a problem for the malware creators, because if an infection is easily detectable then it’s a relatively straightforward process to write a script to detect and clean it up. That’s why the next step for the malware creator is to hide or obfuscate the injection.

Spotting Obfuscated Code

Using JavaScript, there are several tools to obfuscate malicious code (like CharCode or URLEncode). In general, obfuscated malware looks like the example below, but of course, the techniques can be more or less advanced. Our team tends to like writing about the more complicated events:

Sucuri - JS Injection Sample

At first glance, this code looks like a CSS related script that is part of your site’s visual architecture. Usually, you don’t want to touch these files because it could break your website’s look and feel. This, of course, is exactly what the malware creator wants you to think.

Is it Malware?

The tricky thing here is that this function is actually creating a CSS rule. Were we wrong to think that it’s malicious?

last_style_node.addRule(selector, declaration);

What we need to do to find out is look at the content of the rule. To do that, we look for the function call.

createCSS('#va', 'background:url(data:,String.fromCharCode)');

The code is defining the background image for the #va selector. When you look closely you can see that String.fromCharCode is not a valid URL. Remember, malware creators need to figure out how to hide their code injections. In this scenario, storing the functions it needs inside a CSS style is ingenious.

Now that we know where the malware lives, we can find out how it is recovering those strings:

Sucuri - JS Infection III

Putting It All Together

In the code above, we see that the vkk variable is used as the fromCharCode function and uu variable contains a va string. At this moment, this doesn’t make sense, but it starts to come together as we keep moving through some lines of code.

Sucuri - JS Infection IV

It’s important to the hacker that nothing is stored in plain sight (if it was, it’d be much easier to clean). In this instance, take the t variable as an example; it contains the number 2. In this case, this value is attributed by subtracting 2 from the number of seconds of a date stored in the knr variable. That’s pretty complex, right?

This t variable is used to multiply all entries of the xt array*

*Some of the content of this variable has been removed to shorten the post. It doesn’t affect the code’s logic.

Next, there is an empty function called g, which is attributed to hhhu variable, and within these parameters the uu is being used to create the function. By concatenating the e, va(the content of uu) and l we end up with, eval! Now we’re finding some malware.

Then, another chain of variables, hhhu, is now attributed to ac with a different function–the one inside the variable ry, which, previously, we saw contains String.fromCharCode. Now it’s eval’ing String.fromCharCode for CharCodes that are stored in the xt variable.

Finally, after all this, it calls the eval again–the hhhu–but now to execute the code inside dwms variable, which was decoded using the for loop from before.

Dissecting Malware is A Full Time Job

That was an illustration of one payload. It’s just one data point that articulates the sort of complex obfuscation we deal with on a daily basis and, we can say without reservation, as we continue to find new ways to detect it more easily, malware creators will find ways to make their obfuscation more and more complex. If you’re having trouble with malware or blacklisting, take a look at the symptoms of malware and ask us to help.

Do you have samples you’d like us to analyze? Feel free to engage us on Twitter at SucuriLabs or feel free to send us an email at labs@sucuri.net.

5 comments
  1. Great post and very interesting to read.
    Obfuscated and encrypted code can be a nightmare. You simply do not know what is inside unless you decode it which takes a lot of time and effort. We manage to avoid this issue by quarantining any code that is encrypted or obfuscated. Our admins can then inspect it and see if it is a genuine release by a reputable company.
    However, for the general user, it is impossible for them to be able to tell what code is genuine and what is not. With our named brand clients, we simply can not take the risk of having any security issues present within any code without adequate protection being in place.

    1. You’re absolutely right, it’s why we built the Website Firewall, because of your last point. Everyday website owners just are not prepared to handle issues like this, and as you can see complexity continues to increase.

      1. Would your firewall have detected this type of malicious iframe? I assume it would be more on the end of the injection of the malware, preventing it from happening in the first place.
        This is a great example of why flagging obfuscated code is a good practice, so that it can be quarantined and checked by one of our admins.

        1. You’re thinking about it incorrectly. The firewall is designed to stop the attacker from getting in, which in turn would prevent them from injecting your site with this payload. What would have detected it though is our detection / cleanup products, which is what looks for this type of stuff – focused on the infections themselves.

Comments are closed.

You May Also Like