Credit card skimmer evades Virtual Machines

Click the icon to Follow me:- twitterTelegramRedditDiscord

This blog post was authored by Jérôme Segura

There are many techniques threat actors use to slow down analysis or, even better, evade detection. Perhaps the most popular method is to detect virtual machines commonly used by security researchers and sandboxing solutions.

Reverse engineers are accustomed to encountering code snippets that check certain registry keys, looking for specific values indicating the presence of VMware or Virtual Box, two of the most popular virtualization software. Many malware families incorporate these anti-vm features, usually as a first layer.

For web threats, it is more rare to see detection of virtual machines via the browser. Typically threat actors are content with filtering targets based on geolocation and user-agent strings. But that feature does exist in modern browsers and can be quite effective.

In this blog post we show how a Magecart threat actor distributing a digital skimmer is avoiding researchers and possibly sandboxes by ensuring users are running genuine computers and not virtual ones.

Virtual Machine detection

Our investigation started by looking at a newly reported domain that could possibly be related to Magecart. Suspicious JavaScript is being loaded alongside an image of payment methods. Note that browsing directly to the URL will return a decoy Angular library.

load

There is one interesting function within this skimmer script that uses the WebGL JavaScript API to gather information about the user’s machine. We can see that it identifies the graphics renderer and returns its name.

For many Virtual Machines, the graphics card driver will be a software renderer fallback from the hardware (GPU) renderer. Alternatively, it could be supported by the virtualization software but still leak its name.

detection

We notice that the skimmer is checking for the presence of the words swiftshader, llvmpipe and virtualbox. Google Chrome uses SwiftShader while Firefox relies on llvmpipe as its renderer fallback.

By performing this in-browser check, the threat actor can exclude researchers and sandboxes and only allow real victims to be targeted by the skimmer.

Data exfiltration

If the machine passes the check, the personal data exfiltration process can take place normally. The skimmer scrapes a number of fields including the customer’s name, address, email and phone number as well as their credit card data.

skimmer

It also collects any password (many only stores allow customers to register an account), the browser’s user-agent and a unique user ID. The data is then encoded and exfiltrated to the same host via a single POST request:

Evasion

This is not surprising to see such evasion techniques being adopted by criminals, however it shows that as we get better at detecting and reporting attacks, threat actors also evolve their code eventually. This is a natural trade-off that we must expect.

In addition to code obfuscation, anti-debugger tricks and now anti-vm checks, defenders will have to spend more time to identify and protect against those attacks or at least come up with effective countermeasures.

Malwarebytes users are protected against this campaign:

block

Indicators of Compromise (IOCs)

cdn.megalixe[.]org
89.108.127[.]254
  • Skimmer code
  • Skimmer code beautified

The post Credit card skimmer evades Virtual Machines appeared first on Malwarebytes Labs.

If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.

Discord

Original Source
Available for Amazon Prime