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 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.
Initially we thought that only a specific user agent 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:
- Initiate our cleanup processes – nothing was detected.
- Initiate databases cleanup processes – nothing was detected.
- Manual inspections of key files and locations – nothing was detected.
At this point, we have to start thinking outside of the box; think like the end-user, attacker or administrator:
- Leverage search engines to get more information on the target site – this proved unfruitful, save a few redirections to it, but nothing else – no solution or insight.
- Dive a little deeper and start analyzing the requests and packets – finally a ray of light!
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 user ID?
A little research rendered some useful information on this USERID=shine-check. We started to notice that there were various forums talking about this specific issue. 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 from 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 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 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 returning anything.
- 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?
- 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 filled with clues. The function couldn’t write the output because the headers were already sent, and in those warnings was the prize! Two files were disclosed in the warning message, one benign and the other contained the infection. Bingo.
The payload was here:
Using our free online Decoder we extracted the following:
Removing the payload did the trick! Buh-bye redirects.
A Little Icing On the Cake
I do want to mention something about the redirect code as it was unusual, at least to me.
On the first visit, it checks if user is not Chinese (no zh in browser languages) and not coming from websites in Hong Kong. At the same time, the user should also 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 get 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:firstname.lastname@example.org email. 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 the conditions for the redirects. What really affects them is the referrer: non-Chinese origin plus some luck (or lack of it). So much for the scenario we first had in mind.
If you find yourself with 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. We find great joy in little scavenger hunts!