Magento Infection Sends Stolen Credit Card Data To Black Market

While investigating suspicious files on a customer’s eCommerce site, the SiteLock Research Team found malicious payment processing code injected into Magento application files that skimmed credit card data and administrative login credentials. The Magento hack, or malicious code, sent stolen credit card data directly to a publicly accessible carding market where victim’s card details were listed for sale. In this article we analyze the infection, take a deeper look at the carding market, and discuss ways you can keep your site and your credit card data secure.

<strong><em>WHAT IS MAGENTO?</em></strong>

<em>Magento is an extensible eCommerce platform, primarily used by small and medium sized businesses.</em>

The infection “patches” the Magento code, downloading modified copies of legitimate Magento files from the attacker’s Pastebin account. The victim site’s existing versions of these files are replaced with the infected copies, and the file modification times are altered to alleviate suspicion. The replaced files, which we’ll review in greater detail, hook malicious blocks of code into existing Magento functions that execute during actions like user and administrator logins, payment information updates, and at checkout.

The Patcher

The first element of this attack is the use of a patcher, which targets four core Magento files, downloads infected versions of these files, and overwrites the existing files with malicious replacements. The file itself includes standard Magento header comments and is not entirely obfuscated, unlike the majority of web-based malware infections. This means that, at a glance, the file may be perceived to be a standard Magento file.

Here is the functional portion of the patcher script with Pastebin IDs removed.

This file defines a function named patch(), which is then used to download, via cURL, a file from Pastebin and overwrite the clean files. Note the $link variable (notation 1 in the above image), which is the base64 encoding of the partial address http://pastebin.com/raw/. Each individual ‘patch’ is passed five variables (notation 2 in the image) which declare, in order:

1. The directory path of the target file, relative to the preset $path, /app/code/core/Mage
2. The name of the file to be infected
3. The name of a file in the same directory, whose file modification time will be applied to the infected file
4. The predicted size of the new file
5. The Pastebin ID of the infected version of the file

The following files are replaced in this manner:

• /app/code/core/Mage/Payment/Model/Method/Cc.php
• /app/code/core/Mage/Customer/controllers/AccountController.php
• /app/code/core/Mage/Admin/Model/Session.php
• /app/code/core/Mage/Checkout/Model/Type/Onepage.php

The Skimmers

Each of the infected files inject malicious behavior into built-in Magento functions. With this in place, all attempted payment method updates, store checkouts, and site logins are logged and delivered to the attacker instantly as POST data via cURL. The injected code follows the same basic workflow in each of the infected files: Gather data, format the data, then send the data. While two of the files, Onepage.php and AccountController.php, send the data directly to the attacker’s domain, the other files, Cc.php and Session.php, route their data to a file on a seemingly unrelated site. It is possible that this site is associated with the attacker, though it’s more likely it’s a file the attacker uploaded to an otherwise legitimate site they’ve breached.

Cc.php

The payment method update function in Cc.php is modified to include the sendCcNumber() function.

The code is broken into three distinct blocks. The first block, starting with $info and ending after $data17, gathers victims’ names, billing addresses, and credit card details using legitimate Magento functions. The second block, starting with $message and ending after $subject, formats the gathered data and prepares it to be delivered. The final block, starting with $update and ending after curl_close, builds and eventually submits a cURL call that delivers the scraped data through the attacker’s API.

The code in this file is executed when a customer adds a payment method to their account or updates an existing account.

AccountController.php

The malicious version of AccountController.php intercepts customer login information.

Similar in structure to a phishing site, this script routes a copy of the site’s customer login information to the adversary’s server.

<em><strong>If the attacker already has the customer’s credit card data, why do they still want to steal their usernames and passwords?</strong></em>

<em>Infections like these tend to cast a wide net regarding stolen data. While credit card details are a very attractive target for cyber criminals, they also use these infections as an opportunity to build databases of usernames and passwords to leverage at a later date, either to sell in bulk or to further compromise high-value individuals.</em>

Note that this particular Magento file only handles user login data. These accounts store order history, payment information, and delivery details for returning customers, but do not have administrative capabilities over the Magento site itself.

Session.php

Where the previous file handled customer login data, Session.php is responsible for maintaining login sessions for administrators of the infected Magento site.

Having stolen administrative credentials to the site, this affords the attacker the ability to create new administrative accounts to utilize if the infected files are cleaned and the compromised accounts secured, allowing for persistent access.

Onepage.php

The final infected file, Onepage.php, is responsible for handling the processing of payment information when a product is purchased from the site.

Similar to the code in Cc.php, this malicious function scrapes billing and credit card data processed at the time of purchase and delivers it to the attacker.

Same Data, Two Files

While it’s true that the code in Cc.php and Onepage.php may deliver duplicate copies of the same information, they don’t execute under the same conditions. If a customer creates an account and adds a payment method, Cc.php will deliver their data regardless of if a purchase was made. Conversely, if a customer makes a one-time purchase without creating an account, Onepage.php will process the same data. Additionally, since they each route to different locations – Onepage.php sends the data directly to the attacker’s site, while Cc.php routes it to a third party – this creates redundancy to keep the system running even if one endpoint is taken down.

The Black Market

Again, all pertinent card data was collected – card number, expiration date, security code, and country of origin – and sent to the adversary. We decided to investigate the attacker’s primary domain, and were able to gain legitimate, public access to the service.

The carding site allows anyone with the domain name to create an account to browse for and purchase stolen card numbers. We registered for the service by responding to a single confirmation email, again publicly available on the net.

<em><strong>What is “Carding”?</strong></em>

<em>Carding is the term associated with harvesting, purchasing, selling, and using stolen credit card details. This is the case regardless of where the cards were sourced from (phishing sites, infected legitimate sites, hardware skimmers, etc.)</em>

Often attackers use stolen credit cards to make fraudulent purchases, and then resell the purchases for cash. Interestingly, the only transactions the market made with the cards were of small amounts, from $1 to $3, to determine if the cards were valid. If the transaction was successful, the bad actors would put the card on the eCommerce store, selling it to other bad actors for fraudulent use. In other words, a black market of card scammers.

After signing up, a user is provided full access to the card inventory – listing BIN, last two digits, card type, country of origin, and price – to purchase stolen cards. The site accepts two forms of payments, both anonymous: Bitcoin and Perfect Money. After adding credit to an account, one can purchase and use the ill-gotten cards. The carding market claims to guarantee the cards, though does not seem to offer refunds for deactivated or fake cards. Purchases seem simple and quick, giving illicit users access to private data with little to no effort.

The bad actors also sell hacking tools to assist card market users with compromising websites to collect their own card information.

Conclusion

Given the simple yet insidious path that compromised credit card data takes, what can you do to protect your site or card data from falling into the wrong hands?

• Only purchase goods online from reputable sites that use SSL/TLS. Look for a green lock and “https://” in the URL bar of your browser. While these secure connections unfortunately can’t prevent the type of attack we’ve discussed today, it’s still a critical step to take to ensure your information is secure online.
• Perform a search on companies and websites you’ve never purchased goods from before. Look for negative reviews, or messages of the site being hacked or blacklisted.
• Keep a close eye on your bank and credit card statements. Nothing replaces a little proactive diligence.
• Update your passwords regularly and avoid using the same password in multiple locations. If you use the same password everywhere and one of the sites you use is breached, the attacker could reuse that password and access your accounts elsewhere.
• If you own an eCommerce business, run regularly scheduled security scans to find and remove malicious code. SiteLock INFINITY continuously scans and removes malicious code, like the skimmer above, preventing compromise of your customers’ sensitive data.

If you’d like to learn more about how SiteLock can help secure your website code, give our security experts a call at 855.378.6200.