Mysterious Zencart Redirects Leverage HTTP Headers

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.

Sucuri-Zencart-Analysis

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

Sucuri-Zencart-infection-HTTP-header

I noticed this line:


Set-Cookie: USERID=shine-check; path=/

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:

Sucuri-Zencart-Payload

Using our free online Decoder we extracted the following:

Sucuri-Zencart-infection

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 from 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:hackseo@post.com 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 and 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!!

Scan your website for free:
About Denis Sinegubko

Denis is the founder of Unmask Parasites and a Senior Malware Researcher at Sucuri.

  • Rubicant3

    It can’t be stressed enough how important it is to keep an eye on HTTP headers. I learned this very quickly after reading The Tangled Web, by Michal Zalewski. Good digging again, Denis. Interesting to note that noscript wouldn’t save you from this since it’s based in the php and headers. Another reason to be vigilant in the tools you use — unconventional/unpredictable browsers and unconventional search engines (e.g., using DuckDuckGo probably wouldn’t have triggered this apparently).

    I’m guessing that files were infected because of insufficient file permissions or something similar? Something like Tripwire should have picked up that change to includes/modules/extra_functions.php when it happened, I would think.

    • Denis Sinegubko

      Yep, NoScript wouldn’t prevent the redirect but it would save you when you are already redirected to that third-party site. In this case, the goal of the redirect seems to be promotion of that site (not typical malware), but in other cases that third-party site could be malicious and you would definitely want to have NoScript working when you unexpectedly end up on such a site.

      Unconventional search engines and browsers can also help. Malicious code regularly check such things. If you are on Windows, you might even want to change your browser User Agent to something like “Chrome on Linux” – this will save you from quite a few attacks. I also saw a browser extension that deliberately removed Google from the “Referrer” header to prevent attacks that only work for visitors from Google and other major search engines.

      While this may decrease the attack surface, it can’t completely protect you. And be aware that changing the User-Agent and the Referrer header may result in a worse browsing experience as sites will serve you pages optimized for a different browser that may be not fully compatible with yours.