About a week ago we got an interesting Zencart case. Being that we don’t often write about Zencart we figured it’d be good time to share the case and details on what we found.

The Scenario

The site was redirecting to “www .promgirl .de”. I know, not very unique.

Additionally, it was only affecting “www” instances, all “non-www” instances were working correctly with no redirects. We also noticed that it would only trigger with specific User Agents and Referrers. This shouldn’t be new as we’ve talked at length about conditional malware.

The Analysis

Initially we thought that only a specific UA could trigger it and only on “www” version of the site. Then our theory was blown out of the water when another researcher was able to get it to trigger on “non-www” versions too. I would be lying if I said this was all relevant, but at least you get an idea of our thought process.

Here is a step by step to better understand our processes:

1. Initiate our cleanup processes – nothing was detected

2. Initiate databases cleanup processes – nothing was detected

3. Manual inspections of key files and locations – nothing was detected

At this point, we have to start thinking outside of the box and start thinking like the end-user, attacker and administrator:

4. Leverage search engines to get more information on the target site – prove unfruitful, show redirections to it but nothing else – no solution or insight

5. Dive a little deeper and start analyzing the requests and packets – finally a ray of light

I noticed this line:

It looked very suspicious: shine-check? How is it that after I make my first anonymous request it assigns you such a strange USERID?

A little research rendered some useful information on this: USERID=shine-check. We started to notice that there were various forums talking to this specific issue, and the one common denominator in the equation was Zencart. While this doesn’t address the issue, it definitely gets us intrigued and as a researcher it starts to paint a better picture.

Digging a little deeper and leveraging the insights brought about in the various posts we were able to decipher the following:

Yes, it’s a Zencart infection and has been around for a while, shame on us. It turns out that it doesn’t leverage the database or .htaccess files, instead can be inserted across in any one PHP file. The two very important indicators, signatures, for this infection can be found in the shine-check and twotime cookies in the HTTP header information.

One very specific post shared with us the exact payload, and it’s dated back to the summer of 2012. They payload was outlined here: http://pastebin.com/jFY5LF1h. While it gave us a tremendous amount of insight into what we were working with, it was apparent something had changed as none of the existing patterns it outlined were not returning anything.

6. Even with that information in hand, it wasn’t enough to tell us where it was, just that it was legitimate and would require some digging. We set about additional reviews.

Apparently, something has changed in the malware since summer of 2012. But what?

7. After several hours I began to get a little frantic and that led me to line by line reviews, never a pleasant experience. Sparing you all the details, I finally got it. By it, I mean a very benign piece of code that would never set off any alarms, it was just setting some variables. Interestingly enough, disabling it made the cookies disappear. That’s strange, right? I just had to know, so I went about setting some of my own variables that would echo out the results.

Like magic, my new variables spit out warnings it couldn’t write the output because the headers were already sent, and in those warnings we were products with the prize!!! Two files were disclosed, one benign and the other contained the gold!!!

The payload was here:


includes/modules/extra_functions.php


It contained:

Using our free online Decoder we extracted the following:

Removing the payload did the trick! Buh-bye redirects..

That’s it.

A little Icing On the Cake

I do want to mention something about the redirect code as it wasn’t usual, at least not to me.

On the first visit, it checks if user is not Chinese (no zh in browser languages) and not coming form Hong Kong sites. At the same time user should be coming from Bing, Google, Facebook or Yahoo. For such “eligible” visitors they set the USERID=shine-check cookie and redirect them to “hxxp://www .promgirl .de/” For “non-eligible” users they only set the USERID=twotime cookie.

After that every returning user who has the USERID=shine-check cookie gets redirected without further checks, and users with the USERID=twotime cookie never gets redirected.

There is one more interesting “eligibility” condition and it’s based on chance. The code creates an array with 40 items that contain the hxxp://www .promgirl .de/ URL and 60 items that contain the mailto:[email protected] email. Then, for eligible visitors they randomly choose one of the items, and if the item is the URL then that visitor gets the shine-check cookie and gets redirected, and if the item is the email, then the visitor gets the twotime cookie and never gets redirected.

As you can see, User-Agent and “www” don’t affect redirects. What really affects them is the Referrer, non-Chinese origin plus some luck (or lack of it). So much for the scenario above uh.. hehehe..

Good luck!

If you find yourself in a similar issue an need help please let us know. Via our services we’ll do everything necessary to ensure that infections like this are addressed in a timely manner and we found great joy in little scavenger hunts!!

Via Sucuri.net