CronRAT targets Linux servers with e-commerce attacks

CronRAT targets Linux servers with e-commerce attacks

There’s an interesting find over at the Sansec blog, wrapping time and date manipulation up with a very smart RAT attack.

The file, named CronRAT, isn’t an e-commerce attack compromising payment terminals in physical stores. Rather, it looks to swipe payment details by going after vulnerable web stores and dropping payment skimmers on Linux servers. It’s your classic Magecart attack with a stealthy twist.

This method means it bypasses the protection people using the websites arm themselves with, rigging the game from the start. By the time you get onto the website, everything may be fine at your end but the stream further up river has already been polluted. It achieves this thanks to the Linux Cron Job system, which we’ll come back to a little later.

First of all, here’s a brief rundown on what Magecart is, and the difference between client-side and server-side attacks.

What is Magecart?

It’s the collective used for multiple groups who partake in web skimming. These attacks rely on outdated CMSes, or plugin zero days. They may go after small businesses running a particular e-commerce platform. It’s possible they use services like bulletproof hosting to frustrate researchers and law enforcement. Web shells are a popular tactic. There are even impersonators out there, just to make things even more confusing.

Client-side versus server-side attacks

Client-side is where the people who buy things from websites hang out. These are the places where operations such as Magecart may lurk. It could be bogus JavaScript loading in from untrusted domains, or perhaps some other form of rogue code. You can ward off threats such as these by using browser plugins like NoScript. There’s an element of control over these factors, in terms of how you try and secure your browser.

Server-side is an attack on the merchants. Your security processes and tools are great, but when someone is directly corrupting the site under the hood, you may be fighting a lost battle. While your typical web shopper’s first run-in with Magecart would be the previously mentioned rogue JavaScript or other code, this attack means browser-based fixes may not help.

With those out of the way, we’ll loop back to Cron and Cron Jobs.

What is Cron?

Cron is a way that people running a Linux system can schedule tasks. Those tasks will run at a specified time/date in the future, and are known as Cron Jobs. Where things get interesting is that you can enter any date you like, even ones which don’t exist. As long as the system accepts your input, it’ll take it on board and file away in the scheduling system.

CronRAT adds various tasks to the cron table, with a date specification that’ll generate run time errors when triggered. What the malware authors have done is take advantage of the “any date can be used” functionality, and assigned them to February 31st. Of course, this is a date which doesn’t actually exist. As a result, the errors will never happen.

As Sansec puts it:

…the actual malware code is hidden in the task names and is constructed using several layers of compression and base64 decoding.

The payload is a “sophisticated bash program that features self-destruction, timing modulation and a custom binary protocol to communicate with a foreign control server.”

This is definitely one way for Magecart to make waves over the Black Friday period and also further still into the Christmas season.

The problem of digital skimming

Here’s some thoughts from Jerome Segura, our Senior Director of Threat Intelligence:

We’ve known for a long time that there are two different ecosystems when it comes to website security: server-side and client-side. While most security companies focus on the latter, the former is probably the more interesting and perhaps less documented one as it requires access to backend systems. This is an example of a threat that is well crafted and meant to evade detection by default browser-side, but also in some aspects server-side due to its clever obfuscation techniques.

What that means from a digital skimming standpoint is that you are always accepting a level of risk by shopping online and placing trust in the merchant’s ability to keep their systems safe. You should be aware of any subtle changes in payment forms and other possible giveaways that a website is not up to par. Without getting too technical, certain things like outdated copyright information or broken HTML elements may be an indication that the store is not keeping their site up to date.

An attacker will first compromise online shops that are vulnerable to attacks, so it makes sense to stay clear of those that are not following best practices.

Safety first

There’s lots of things you can do out there in the real world to avoid ATM skimmers, and related threats. You can also be proactive in the realm of web-based skimmers targeting the sites you make payments on. Issues such as CronRAT may take a little while longer for various industries to figure out.

While there are varying levels of protection for web purchases, it may be dependent on payment method and/or location. It’s also not great to know that if payment data has been compromised, it’s possible the criminals have grabbed other data too. While this may not be the most reassuring message to take into the new year, forewarned is most definitely forearmed.