{"id":19145,"date":"2022-05-28T19:04:25","date_gmt":"2022-05-29T03:04:25","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2022\/05\/28\/news-12878\/"},"modified":"2022-05-28T19:04:25","modified_gmt":"2022-05-29T03:04:25","slug":"news-12878","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2022\/05\/28\/news-12878\/","title":{"rendered":"Beneath the surface: Uncovering the shift in web skimming"},"content":{"rendered":"

Credit to Author: Paul Oliveria| Date: Mon, 23 May 2022 16:00:00 +0000<\/strong><\/p>\n

Microsoft security researchers recently observed that web skimming campaigns now employ various obfuscation techniques to deliver and hide skimming scripts. It\u2019s a shift from earlier tactics where attackers conspicuously injected malicious scripts into e-commerce platforms and content management systems (CMSs) via vulnerability exploitation, making this threat highly evasive to traditional security solutions. As of this writing, some of the latest skimming HTML and JavaScript files uploaded in VirusTotal have very low detection rates.<\/p>\n

Web skimming typically targets platforms like Magento, PrestaShop, and WordPress, which are popular choices for online shops because of their ease of use and portability with third-party plugins. Unfortunately, these platforms and plugins come with vulnerabilities that the attackers have constantly attempted to leverage. One notable web skimming campaign\/group is Magecart<\/a>, which gained media coverage over the years for affecting thousands of websites, including several popular brands.<\/p>\n

In one of the campaigns we\u2019ve observed, attackers obfuscated the skimming script by encoding it in PHP, which, in turn, was embedded inside an image file\u2014a likely attempt to leverage PHP calls when a website\u2019s index page is loaded. Recently, we\u2019ve also seen compromised web applications injected with malicious JavaScript masquerading as Google Analytics and Meta Pixel (formerly Facebook Pixel) scripts. Some skimming scripts even had anti-debugging mechanisms, in that they first checked if the browser\u2019s developer tools were open.<\/p>\n

Given the scale of web skimming campaigns and the impact they have on organizations and their customers, a comprehensive security solution is needed to detect and block this threat. Microsoft 365 Defender<\/a> provides a coordinated defense that\u2019s enriched by our visibility into attacker infrastructure and continuous monitoring<\/a> of the threat landscape.<\/p>\n

In this blog, we provide the technical details of the recent skimming campaigns\u2019 obfuscation techniques. We also offer steps for defenders and users to protect themselves and their organizations from such attacks.<\/p>\n

How web skimming works<\/h2>\n

This primary goal of web skimming campaigns is to harvest and later exfiltrate users\u2019 payment information, such as credit card details, during checkout. To achieve this, attackers typically take advantage of vulnerabilities in e-commerce platforms and CMSs to gain access to pages they want to inject the skimming script into. Another common method is web-based supply chain attacks, where attackers use vulnerabilities in installed third-party plugins and themes or compromise ad networks that may inevitably serve malicious ads without the site owner\u2019s knowledge or consent.<\/p>\n

\"Attack
Figure 1. Overview of a web skimming attack<\/figcaption><\/figure>\n

As mentioned earlier, one notable skimming campaign is Magecart<\/a>. First observed in 2010, Magecart campaigns have increased in number and become stealthier through heavy obfuscation techniques, new injection points, and delivery methods. In the last five years, popular organizations or brands have been affected by Magecart\u2014from an airline company<\/a> and online ticketing services<\/a> to a sports brand<\/a> and personal transporter<\/a>. In 2019, tens of thousands of websites<\/a> got compromised because of a misconfiguration in the cloud service provider where these sites were hosted. Such an increase in these types of attacks prompted the Payment Card Industry Security Standards Council (PCI SSC) to release a bulletin<\/a> that warns users about the threat. In April 2022, PCI also released<\/a> a major revision in its Data Security Standard (DSS), which now includes additional requirements for e-commerce environments to help prevent skimming.<\/p>\n

Recent developments<\/h2>\n

In their earlier iterations, most web skimming campaigns directly targeted unpatched e-commerce platforms like Magento. Also, the malicious JavaScript they injected were very conspicuous. However, as the campaigns\u2019 attack vectors and routines evolved, attackers also started using different techniques to hide their skimming scripts.<\/p>\n

Malicious images with obfuscated script<\/h3>\n

During our research, we came across two instances of malicious image files being uploaded to a Magento-hosted server. Both images contained a PHP script with a Base64-encoded JavaScript, and while they had identical JavaScript code, they slightly differed in their PHP implementation. The first image, disguised as a favicon (also known as a shortcut or URL icon), was available on VirusTotal, while the other one was a typical web image file discovered by our team. Their hashes are included in the Indicators of compromise<\/a> section below.<\/p>\n

We first observed the malicious favicon in November 2021, when a few campaigns started dropping remote access trojans (RATs) on target web servers, in addition to injecting scripts into web pages. This delivery method moves away from the usual modus<\/em>; it appears that attackers are now targeting the server side to inject their scripts, enabling them to bypass conventional browser protections like Content Security Policy (CSP), which prevents the loading of any external scripts. Meanwhile, the more recent image file was uploaded on the \/media\/wysiwyg\/<\/em> directory, most likely by leveraging a vulnerability in the Magento CMS.<\/p>\n

The insertion of the PHP script in an image file is interesting because, by default, the web server wouldn\u2019t run the said code. Based on previous similar attacks, we believe that the attacker used a PHP include<\/em> expression to include the image (that contains the PHP code) in the website\u2019s index page, so that it automatically loads at every webpage visit.<\/p>\n

In both images\u2019 cases, once the embedded PHP script was run, it first retrieved the current page\u2019s URL and looked for the \u201ccheckout\u201d and \u201conepage” keywords, both of which are mapped to Magento\u2019s checkout page.<\/p>\n

\"Partial
Figure 2. Screenshot of a Magento shopping cart page with the \u201ccheckout\u201d keyword in the URL<\/figcaption><\/figure>\n

Before serving the skimming script, the PHP script also checked that administrator cookies weren\u2019t set to ensure that a web admin isn\u2019t currently signed in. Such a check ensured that the script only targeted the site visitors (online shoppers).<\/p>\n

\"Partial
Figure 3. Portion of the PHP script that checks for admin cookies<\/figcaption><\/figure>\n

The skimming script was encoded multiple times using hexadecimal (Base16) and then Base64. When decoded, it had an array of strings that were referenced and substituted further to construct a complete JavaScript code. Below are snippets of the decoded skimming script.<\/p>\n

The boms()<\/em> function (Figure 4) was responsible for creating and serving the fake checkout payment form (Figure 5) that collected target users\u2019 payment details.<\/p>\n

\"Partial
Figure 4. Portion of the skimming script that creates and serves the fake checkout payment form<\/figcaption><\/figure>\n
\"Partial
Figure 5. Sample screenshot of the fake checkout form that collects user payment details<\/figcaption><\/figure>\n

The said function is only triggered if the __ffse<\/em> cookie value wasn\u2019t set to \u201c236232342323626326\u201d\u2014most probably a check to ensure that the website isn\u2019t already infected.<\/p>\n

\"Partial
Figure 6. Portion of the skimming script that checks for a specific cookie value<\/figcaption><\/figure>\n

When the user submitted their details in the fake form, the glob_snsd() <\/em>function is triggered (Figure 7), which then collected the said details in the form elements (input, select), encoded them in hex and Base64, and finally added them to the cookies (Figure 8).<\/p>\n

\"Partial
Figure 7. Portion of the skimming script that launches the credential theft and exfiltration routines<\/figcaption><\/figure>\n
\"Partial
Figure 8. Portion of the skimming script that performs the credential theft routine<\/figcaption><\/figure>\n

The encoded stolen information was then exfiltrated to an attacker-controlled C2 via PHP curl requests.<\/p>\n

\"Partial
Figure 9. Portion of the skimming script that performs the exfiltration routine<\/figcaption><\/figure>\n

Concatenated and encoded skimming host URL<\/h3>\n

We also came across four lines of JavaScript injected into a compromised webpage. Like the malicious images we previously analyzed, the script in this scenario would run only when it finds the \u201ccheckout\u201d keyword in the target web page URL. It would then fetch the skimming script hosted on an attacker-controlled domain to load a fake checkout form.<\/p>\n

The attacker-controlled domain was encoded in Base64 and concatenated from several strings. As of this writing, the said domain is still active.<\/p>\n

\"Partial
Figure 10. Code snippet containing the concatenated and encoded URL that hosts the skimming script<\/figcaption><\/figure>\n

The skimming script itself wasn\u2019t obfuscated and had two main functions: getData()<\/em> and __send()<\/em>. getData()<\/em> was responsible for getting form data on the web page, converting them to JSON, and passing it onto __send()<\/em>. Interestingly, this function also checked for crawlers and other possible debugging attempts before skimming data. It specifically checked if the user had opened the browser developer tool, as seen in the snippet below:<\/p>\n

if (devtools.open) return;
 if (\/bot|googlebot|crawler|spider|robot|crawling\/i.test(navigator.userAgent)) return;<\/pre>\n
The __send() <\/em>function, in turn, created an image object and prepared the URL for exfiltration. Note that while it formed the image, this function loaded the URL with the captured data in the data<\/em>parameter. The parameter value was also encoded in Base64.<\/p>\n
\"Partial
Figure 11. Snippet of the hosted script that exfiltrates web page data<\/figcaption><\/figure>\n
Google Analytics and Meta Pixel script spoofing<\/h3>\n
Attackers have also started masquerading as Google Analytics and Meta Pixel (formerly Facebook Pixel) scripts to trick site administrators or developers into thinking they\u2019re looking at non-malicious codes, thus evading detection.<\/p>\n
The screenshot below illustrates how a Base64-encoded string was placed inside a spoofed Google Tag Manager code. This string decoded to trafficapps[.]business\/data[.]php?p=form<\/em>.<\/p>\n
\"Partial
Figure 12. Encoded skimming script in a spoofed Google Analytics code<\/figcaption><\/figure>\n
We also observed a similar technique where the skimming script mimicked Meta Pixel\u2019s function parameters and JavaScript file name to avoid detection. Like the example in the previous section, the URL in this technique was encoded in Base64 and split into several strings. The concatenated string decoded to \/\/sotech[.]fun\/identity[.]js<\/em>, and it contained obfuscated code. Interestingly, the decoded URL also had the query string d=GTM-34PX2SO<\/em>, which is specific to Google Tag Manager and not<\/em> Meta Pixel.<\/p>\n
\"Partial
Figure 13. Encoded skimming script in a spoofed Meta Pixel code<\/figcaption><\/figure>\n
The attackers behind the Meta Pixel spoofing used newly registered domains (NRDs) hosted on HTTPS to carry out their attacks. All the domains we saw associated with this skimming campaign were registered around the same time via a popular budget hosting provider, as seen in the list below. However, the actual hosting sites were hidden behind Cloudflare\u2019s infrastructure.<\/p>\n