Anti-Phishing, DMARC , Breach Notification , Card Not Present Fraud

E-Commerce Skimming Attacks Evolve Into iFrame Injection

Finding Shows Risk To Sites That Use External Payment Processors
E-Commerce Skimming Attacks Evolve Into iFrame Injection
Illustration: Mohamed Hassan/CC

Criminal gangs have been hitting e-commerce sites hard lately by injecting their malicious code to "skim" customers' payment card details.

See Also: 2018 Banking Threat Landscape: An Inside Look at How Cybercriminals Target Financial Services

Security firm RiskIQ says it's tracking more than a half-dozen groups that employ "digital skimmer" attack techniques that it classifies as being "Magecart." Such groups typically target Magento e-commerce software and plant malicious code inside victims' websites (see New Skimmer Attack Steals Data From Over 100 E-Commerce Sites).

Magecart groups' code can be stealthy: Consumers may never be aware that their payment card details have been compromised via a legitimate site. Oftentimes, breached e-commerce sites don't discover that they've been hacked, but rather get notified by security firms such as RiskIQ, which continually conduct internet-wide scans, looking for sites that display known signs of Magecart attacks.

Recently, Malwarebytes has spotted a new twist in attackers' skimming tactics. In one case, attackers infected an e-commerce site with code that causes it to pop up a malicious iFrame at payment time.

The use of injected overlays is nothing new in either skimming or phishing attacks, says Jérôme Segura, a Malwarebytes security researcher. But it poses a special risk for any e-commerce site that may think it's better isolated against Magecart attacks thanks to using an external payment service provider, or PSP.

"To me the main takeaway was that even sites that do not take payment themselves can still be abused with those tricks," Segura tells ISMG. "It really shows that any e-commerce site is fair game."

Data Goes to Russia

Malwarebytes didn't name which Magento-powered e-commerce site got hit by the iFrame attack, although Segura says it is a clothing portal that serves the Asia-Pacific region.

He says that when users of the site come to the payment screen, the iFrame suddenly gets injected into the page. Normally, however, a person would be redirected to the PSP.

On the right, the iFrame skimmer. (Source: Malwarebytes)

"What we notice are new fields to enter credit card data that did not exist on the left (untampered form)," Segura writes in a blog post. By itself, this may not be out of the ordinary since online merchants do use such forms - including iFrame - as part of their checkout pages."

Essentially, the iFrame jumps ahead in line. Although all PHP pages within the e-commerce site were infected, Segura says that the iFrame would only be triggered "if the current URL in the address bar is the shopping cart checkout page (onestepcheckout)." Apparently to help the malicious code avoid detection, "some extra checks (screen dimensions and presence of a web debugger) are also performed before continuing."

The JavaScript that draws the iFrame comes from a domain, thatispersonal[.]com, which is hosted in Russia, Segura writes. Another script is used to process and validate the data. Once the victim enters their card details, the "data is sent via a POST request to the same malicious domain in a custom-encoded format."

Finally, after that occurs, the user does get directed to the proper PSP, where they can pay.

Hiding in Plain Sight

Yonathan Klijnsma, a threat researcher at RiskIQ, says that the attack found by Segura resembles the style of a group his company refers to as Magecart 4.

Last November, RiskIQ published a joint report with Flashpoint that covered a variety of Magecart actors, including group 4, which had developed an extensive infrastructure for skimming payment cards.

Before injecting the iFrame, the malicious code performs some checks. (Source: Malwarebytes)

Magecart 4 is also notable for its ability to "[blend] in with its victims' sites to hide in plain sight and employs methods to avoid detection," RiskIQ says.

Now, by using an iFrame, the attackers can capture payment card data before the customer is directed to the PSP.

But Klijnsma says the attack was a bit clunky. "The skimmer here puts its own payment form in so the user inserts it," he says. "The funny thing is that this method breaks the checkout process because if you iFrame instead of redirect, the user has to enter payment data twice, which might tip them off."

While this user interface anomaly might raise customers' suspicions, however, by the time they see the second payment screen, their data would already have been compromised.

About the Author

Jeremy Kirk

Jeremy Kirk

Executive Editor, Security and Technology, ISMG

Kirk was executive editor for security and technology for Information Security Media Group. Reporting from Sydney, Australia, he created "The Ransomware Files" podcast, which tells the harrowing stories of IT pros who have fought back against ransomware.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing, you agree to our use of cookies.