CyberWire Daily - Magecart payment card theft analysis. [Research Saturday]

Episode Date: January 12, 2019

Researchers at RiskIQ have been tracking a series of web-based credit card skimmers known as Magecart. We take a closer look at attacks on Ticketmaster, British Airways, NewEgg and Shopper Approved payment card pages.  Yonathan Klijnsma is lead of threat research at RiskIQ, and he guides us through what they've learned. Links to RiskIQ research: https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-newegg/ https://www.riskiq.com/blog/labs/magecart-shopper-approved/ Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers

by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management

with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. So we originally started tracking Magecart back in 2015. That's Jonathan Kleinsma. He's the lead of threat research with Risk IQ.

Today we're discussing a series of Risk IQ blog posts covering Magecart. We saw some of this activity and we started digging into it. It turned out to be a lot bigger than we initially expected. And over the years we've been publishing about this and it's been growing. And it's where we're at the current day. It's currently eight groups that we're tracking. There's a lot more data and we're going through to see if there's more which we can define as groups. But there's at least eight criminal groups.

And take us through what exactly are we talking about when we're talking about Magecart? So Magecart for us is describing an MO. So Magecart specifically is web skimming for payment information or payment data. And we take this MO and we have different groups we label under this, but we don't give individual groups separate names. For us, an MO describes a type of attack. In this case, it's web skimming for payment information. And we just call it Magecart Group 1 to Group 8. Now, is there commonality between the code that the different groups are using? There is for some of them. So one of the original groups has been selling off their kit.

They started doing this in 2016. So you can actually see a bunch of different groups using the same code base. Some of them focus on the actual attack part, so to compromise and like the steps after this. And others you will see sort of modifying and playing around with the code base to see if they can improve it. So walk me through this. If I am someone who is out to do this type of skimming, how would I go about doing it? The thing is that current web pages and payment pages online for card not present transactions, they are just web pages with fields, with forms, and you put your

information in there. Now, the same type of scripts that can create these forms and can do your checking while you're putting in your information where it validates you, this same script can also pull out this information. So doing these types of attacks, there's one thing you need to do. You need to run some script in the browser of the victim that's currently trying to do a transaction. And the way to do this is you compromise a merchant, an online store, and you actually put your script in a page. And what your script does, it will search for a payment form and will just pull out the information that's in the form

once a user submits their payment. And this is how they all do it. They have different versions of how to do this. Sometimes they look at when the form is being filled in. So every time you're typing something in, they will check to see if you enter payment information. But there's other groups that just check, you know, is somebody submitting their payment? Others will be hooking on the fact that a form is submitted.

Some will be hooking on the button you're clicking to perform your actual transaction. There's just different ways of going at it. And do you have any sense for who these folks are? Anything attribution-wise? No, we try to sort of stray away from attribution, but we do know the original group that we were tracking in 2015, which goes back to 2014, at least one of their members is a native Russian, at least he speaks Russian natively. Now, we don't know if he's based out of Russia, At least he speaks Russian natively.

Now, we don't know if he's based out of Russia, but that's what we have for them. I see. Well, let's walk through a couple of the incidents that you all have highlighted in some of the blogs you've done about this. Why don't we start out with Ticketmaster? What was going on with this one? So Ticketmaster is a very, very large organization. They have a very big online presence, but they also have a big security policy and a big security team. They take security very seriously. Now, the thing is, if you want to go after one of these organizations, it's going to be very difficult if they have all the security

stuff in place. So the specific group that went after Ticketmaster is one we call Macecard Group 5. And all that these guys are doing is they are going after the supply chain. So Ticketmaster is one we call MaceCard Group 5. And all that these guys are doing is they are going after the supply chain. So Ticketmaster uses, or at that time used, a bunch of different analytics providers and sort of basically providers that give them functionality on their website. It wasn't even all about analytics. So what this group does is they go after the supply chain. They will compromise these smaller organizations because they are good at what they're doing, be it analytics or something else. But they're not always that good at security.

So these companies get breached. And the thing is, their script runs on the Ticketmaster website, runs on a whole bunch of websites. So the original breach started in December with a company called Socialplus. They compromised this company and they basically added their skimming code to the script that's normally loaded by Socialplus' customers. Now Ticketmaster was one of their customers and by that effect they were executing the skimmer code on their website. Now another third party which Ticketmaster was using, called Inbenta, was also compromised. They were compromised in February of this year, and they were compromised for a few months. And near the end of June, this is sort of when this all became public and when it started to be resolved. They were breached because one of the providers they're using was breached.

And for this group specifically, it's their tactic. It's their MO. They don't go after the big organizations directly. Their thing is, let's do one compromise for 1,000 or 10,000 sites instead of some of the other groups that do one compromise at a time. So they need to do 10,000 compromises to get 10,000 e-commerce websites. This group for Ticketmaster, they just have the supply chain approach, which sort of has a fan out if you look at it. Now, what's going on with this in terms of a command and control server?

The command and control servers, or we like to call it drop servers, they have one or two functions. Now, it kind of depends how they're doing their attack. Sometimes what they will do is they will add a script tag to the actual website, which loads an external piece of JavaScript. And they usually load the script from one of their servers. That's one approach, but in the case for

Ticketmaster, for example, they added their skimmer code to this third party. So they weren't hosting the skimmer themselves. So they still had a server, which we call the drop server, in place and all it was doing is receiving the cards. So they skimmed the form information

and they send off the data to this drop server and all this drop server does is it accepts the data and it puts it either on disk, depending how they've set it up, or it puts it in a nice database and these guys can log into their sort of administrative panels and see how much they actually have gotten. I'm struck by the notion that it seems to me that

if you're someone like Ticketmaster or some of these other companies that have been hit by this, if you've got a third-party company that you're relying on to run on your payment pages, shouldn't there be some sort of code verification process going on to make sure that it hasn't been altered by the time it gets to you? It should. It should. But it's not something that's currently in place. There's been this whole sort of ecosystem of analytics providers and different companies grabbing all these niches, and people like to use this because you don't have to reinvent it. But now we're at the point where these types of compromises have been put on the radar, and people are looking at this and saying, we should really do something about this.

And we're slowly seeing a move, and there's different approaches to this. So some of them will actually cut down on the amount of providers they're using. They're just saying, this has no use. Let's just drop them. It's an additional risk for us. Some of them are going to their providers and just asking them, and I think this is a really good approach. They are asking them like, hey, what is your security policy? What do you have in place to see if something happened on your side? And I think that's a really good thing to do because these companies have to sort of learn about this because it's not something they're used to. And what that means is they're slowly pushing the sort of idea of security to all these smaller companies. And then there's another approach for the companies that

are a little bit more ahead. There is sub-resource integrity. And all that means is if you load a resource from your web page, be it one of those scripts from one of those providers, you can, in your web page, add a checksum, which is a checksum of the file that you're expecting to load from this provider. Now, the way this works is that browsers will check the checksum and they verify it to the resource. If it doesn't match, the browser won't execute anything and won't do anything. So there's sort of different layers of approaches. But this whole concept, while it's not new for us, it is new for a lot of people in the e-commerce space. It's not something they had to deal with before.

It used to be breaches and, for example, point-of-sale malware, which would also basically do the same thing. They would skim, but then skim from memory. And this web skimming is just a new evolution. And it's been there since 2014. And we've been publishing about this for a while. And in the beginning, you would see people sort of going, well, you know, this happens, there are breaches,

information gets stolen. And we've been continuing to publish on this. And right now, everybody's like, oh, damn, we really need to do something about this. It's something we need to be more strict on. Now, personally, I don't see the approach of trying to go through all your providers. And it's all small controls. It's one of many you should have in place. And hopefully you tag it at one point in this entire set of controls. But I think we should also reconsider how we're doing online payments because that's

actually where the real problem is. When you're doing your online transaction, there's no additional control in place. Everything that you're putting in on the web page is payment information, and it is as accessible as the image on the page or any of the other content on the page. So I think we need to dig down more into how we're doing online payments and make sort of a different model around this. Because the bigger organizations, they can put all these controls in place. They can sort of align all of this. But what we see, the majority of victimized websites are from people that are doing their business

and are doing their thing, making their product, and they're using the e-commerce space online to sell their product, but it is not their main focus. So they also don't really have a clue a lot of times what's going on. And those are the majority of websites we're seeing compromised. Now, what about looking at their outbound traffic? Is it a situation where companies like Ticketmaster or some of the other ones that were breached here, would they have necessarily noticed that there was data going somewhere that it

shouldn't have? That's actually very, very hard if you look at it from how these attacks work. So all these online payments, all these providers that are on the pages, and all this analytics that's happening at providers, and then you have the session recording companies, which do analytics by recording everything that happens on the website. session recording companies, which do analytics by recording everything that happens on the website. Those guys actually, by accident, sort of also copy payment information while they're doing an analysis because they're looking at what's happening on a website, what's being typed in. So this information actually goes a lot further than what people are expecting. And if you look

at trying to see if there's controls in place to figure out where data is going, it's a lot harder than you would expect. That's interesting. Well, let's move on to the British Airways breach. That was another one that got hit. What was special about this one? So the British Airways one is one we attribute to a group we call Magecart Group 6. They are very different in the way they operate. So they are highly targeted.

They go for one organization. And once they breach this organization, they figure out how it works or how the payment basically works with these organizations. And they integrate their skimmer at basically the best spot they can go for with this. And if you look at the British Airways ones, what they did,

they modified this one JavaScript resource on the server that was loaded by both the mobile version of the payment page as well as the normal desktop one. And this way, they had both mobile and desktop payments that are being done online.

They had both of these covered for skimming. But this group, like I said, they integrated really well and they really take care of how they breach an organization and they take their time to figure out what's going on, how does this organization work, how does their website look like, how does the website function, and where should we go. And their idea is basically, if we're on this website for a day, so we're there skimming payment information for a day, that will be already

it will have a big, big return. If we're there skimming payment information for a day, that will be already, you know, it will have a big, big return. If we're there longer, that's only better. Now, for the time that they were active on the website, it's a long time. So a lot of cards were skimmed at that time. Yeah, it's interesting that in this case, they were able to infiltrate the mobile devices as well. Yeah. So a lot of these mobile apps, they are partially native to the operating system of the mobile devices as well. Yeah. So a lot of these mobile apps, they are partially native

to the operating system of the mobile device. But a lot of times when they want to sort of align a design of the app, as well as the whole experience of paying and then people switching from the desktop website

to the mobile one, you sort of want to have a similar or basically you want to have the same design all around. And in mobile apps, what they tend to do is you'll have these sort of dashboards in your airline related apps where you can see your flights, status of flights, all that information. Those are usually native displays. And all they're doing is they're hitting up these API endpoints for, for example, British Airways, where they're pulling down this information and they are just displaying it in a nice way. Now, the actual payment process or the booking process for a lot of these,

they actually just visit a mobile version of the website in the background. They load all the resources from the web server, just like a normal website visit. And the reason for this is you don't want to duplicate everything. You don't want to add online payment processing in a mobile app. If you've already done it properly for the website. You can just make sure that the website also works on mobile devices. And that's what we see a lot of times. The apps partially are native. They display data natively by using APIs on the services. But at the same time, certain processes, they will just map these over to a mobile website display and they will show this in the app. And that's how they got British Airways mobile payments as well. Well, let's move on to

another victim here. They were able to get in and compromise Newegg. Yeah. So Newegg is the same group as the British Airways group. And they sort of took the same approach. They breached an organization and they figured out how the payment worked. And you can see this by the way they added their skimmer. So the checkout process for Newegg is split in different steps. So in the first step, you're adding your shipping and sort of billing information. And then the second step of your checkout, you're adding payment information. Now, this payment information page was a separate page, and this is only where the skimmer was active. So they figured out how this payment process worked, and they went after this really specific file, and they added their skimmer code as a small JavaScript snippet on the web

page. It was very small. It was 15 lines of code if you space it out neatly and make it readable. So that's 15 lines of code, and we saw the data go for sale on one of the underground markets, and they had about half a million cards for sale. So that's a pretty big return for these guys. Yeah, it sure is. And are they making any attempt to obfuscate the code when they're injecting it? Not really. And the most interesting thing is when we were looking at this code and we tried to set out some detection rules, basically, we crawl the internet, we crawl the

websites online. And what we noticed is if we made our rule just a little bit too generic for the skimmers, we noticed that people were actually doing the same concept for actual payments. They would grab form data from the payment form and they would send it off to a remote server and wait for the remote server to validate the payment and say, it's good, you can continue.

Which is a really, really bad practice if you think about it. And it's really not how we should do online payments. You know, just sending it off to a remote server to do some validation.

So they are not doing obfuscation just because their skimmer is very simple. And basically the drop server, so the server where the cards go to, what they try to do is they try to blend this in. So the domain names, they will be similar or they'll be looking like a surface of one of the companies they breach. And then the URL where the payment data is sent to, now the URL doesn't really matter for them. They just have a process on the server side, which receives all the payment information. It doesn't really matter which URL you send it to, but the URL they put in, they try to match it with what normal URLs on a website look like as well.

And you could, for example, with Newegg, one of the steps in the checkout process for Newegg was a URL, and it contained the word global shopping, I believe. Now, global shopping was capitalized with a G and an S, but the actual drop server path where the cards were sent was global data with a capital G, capital D. But it was completely different from the way they did British Airways. it was completely different from the way they did British Airways. So they sort of make it really simple. They don't over-office-gate because that tends to stick out, at least for us. When we see office-gated skimmers in normal script, you can see a really big difference, even if you look at something like entropy. So they try to make it really plain, really simple, and just make it look like it's all part of normal processing on a website. Now, in the case of Newegg, was this going through a third party or had they actually gotten into Newegg itself?

They had gotten into Newegg itself. So they added their script directly on the Newegg website. They did not compromise a third party. We don't know what happened on the inside, how it was compromised, but we do know they had access to the Newegg servers. Well, let's move on to the last one we're going to talk about today. This is an organization called Shopper Approved. What happened here?

So Shopper Approved is one of the examples of one of those third parties being compromised. Now, Shopper Approved was compromised by Group 5, which is the one that does this supply chain attack. They added their skimmer code on a Saturday morning. And we saw this, I think, a little under an hour after it happened. Because Shopper Approved is used on a couple thousand websites. So we saw their scripts occur a bunch of times. Now, what was interesting about this attack, when those guys first had access and they put their skimmer in, they forgot to obfuscate it. So Group 5 is an example of a group that has bought a kit for this skimming, but they are heavily focused on the MO and basically the operation of gaining access and doing the supply chain attack.

They don't really change the skimmer from what they originally bought it as. from what they originally bought it as. So the first time they compromised shopper-approved, or actually the first time they put the skimmer on the shopper-approved surface, they put in an unobfuscated version so we could actually see what it looked like when it was clean, when there was no changes in variable names or anything.

And they came back about 15 minutes later to modify the script again to actually add a obfuscated version. And they forgot to do this. They were just possibly rushed in some way, and they just forgot to do it. So we were in contact with Shopper Proof over the weekend

and on Monday morning, when all their teams got in, they cleaned it up and they started their investigation. Now, what's the best way for folks to protect themselves against this? If I'm an organization that needs to take online payments, how can I look out for these things? ways. They will do anything from trying to use default credentials to credentials they pull out of breach data, so public information from breaches or private, so stuff that's not yet hit the public. And they will also go after outdated software. So if you have an old WordPress, they'll try it.

If you have an old Magento, they'll try it. But also servers that you haven't installed. So if you're running an old strut, still trying to use it to get in. So from a security perspective specifically, it's general security that needs to be in place. But talking about those sort of different controls you can put in place to detect the skimming part or the modification on the server, there's a couple of different things you can do. One thing we advise a lot of organizations is to isolate your payment form. A lot of times these pages, the payment pages just look very nice in design, but the problem with that is they have a lot of external scripts running on them

and when they run all these external scripts, you can have this supply chain issue. So we advise people to just keep their checkout page clean and empty and just simplify it as much as possible. Now, at the same time, there are other concepts you can use. So you can use CSP, which is a content security policy, and you can define where data can go through or can come from

and go to on your website. And at the same time, you can also add this sub-resource integrity I talked about, where you define what a resource should look like when it's loaded or a checksum of what it should look like. And then when the checksum doesn't match, the browsers won't actually load it. So there's sort of different controls. Now, this sub-resource integrity, we also advise people to do this on their own site. So sub-resource integrity is for the visitor and the browser of the visitor. But one thing we advise is people to also add a sort of a monitor on their server for files that are being modified.

You tend to do a deployment when you're updating your website so you can take into account the fact that it's being deployed. You still have to validate what's being deployed. But if any file changes appear outside of deployment,

something might be up. So there's sort of, basically you need to layer on controls and security policies to try and catch them at any step, basically. It's not one thing to protect you from Magecart as a whole or these Magecart type of attacks. It's about layering your security and just getting multiple things in place. Is there any sense that with these breaches being detected and being pushed back against that Magecart is slowing down at all?

Or are they still going at full speed? It's actually more than full speed. It's ramping up. If you look at sort of a timeline of all these events and all these different groups, the first group was 2014. Now they disappeared in 2016, but at that time, two new groups appeared, most likely because they bought the source code from this original group. Now 2017, we have another group joining. But this year, 2018, we have three new groups joining in. So it's only ramping up because these guys learn from each other. They are in the same ecosystem of crime.

They have competitors. ecosystem of crime, they have competitors. And when they see somebody else doing really well, selling off a lot of cards, obviously they are sort of interested in how these guys are doing this. And maybe some of the publications that are happening are also hinting towards them, saying like, this apparently is a good approach to do it. So more and more groups are joining in. It is a very lightweight and not a very impactful way to get payment information. Now, generally, I mean, the end game for these Magecart groups is, is it the selling of the cards themselves, the selling of those numbers, or are they using the cards to purchase things for themselves or to try to cash out that way? Do you have any

sense on that? We have a sense of that for some of the groups. So Group 6, the one from British Airways and Newegg, we know they sell off their cards through a broker, and that's how they get their profit. But Group 1 did a different thing. They would sell off their cards on one end, but they also had a reshipping company in place. So what they would do is they would recruit mules in the U.S., and they would buy expensive technology or technology that's not available in their own region. They would buy it from online merchants in the U.S. using stolen payment information, ship it to the mule in the U.S., and the mule would then send it to them. And that was also part of their income. So they sort of had two ways of doing this. Two ways of doing this.

Now, since this is basically vacuuming up data from forms that are being filled out, would any of the next generation payment systems, I'm thinking of things like Apple Pay or things like that, that have a more automated and tokenized exchange of information, would that be helpful in cutting down on these sorts of things? It would, because it's a token transaction. You are not actually giving your payment information at that time, which is what they're going after with all these skimming attacks.

So if you're doing a transaction, but you're not actually filling out your card information, the skimming won't work. For example, I only do payments right now via online retailers where I can store my own payment card in the account. Because that means during checkout, I just select my preferred payment method. I'm not entering my payment information, so it won't be available to web skimmers. So this type of token transaction is a really good one. But another approach, which I take myself, is use retailers where you can store your card information ahead of time. Now, that's really interesting because I could imagine that being counterintuitive,

where you think, well, I don't want to trust this organization to store my credit card information. But the point you make is a good one, that that may actually be the safer choice. It is the safer choice. Now, it might not be the safer choice when it comes to a breach of an organization. The example with British Airways, they recently made a publication that they found more payment information compromised because whoever was inside their infrastructure managed to get to the server that stored payment information from remote members' transactions. So in a way, it's sort of two-pronged. You're not vulnerable to skimmers this way,

but if an organization is compromised and that's sort of a general thing, they might actually still get to the payment information. But if we're just focusing on skimmers right now, that is my approach. The payment forms, in my opinion, I don't want the payment form to accept raw credit card information.

Our thanks to Jonathan Kleinsma from RiskIQ for joining us. RiskIQ has a series of blog posts covering the Magecart reports. We'll have links to them in the show notes for this episode. And now, a message from Black Cloak. Did you know the easiest way for cybercriminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk.

In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. Thanks for listening. Thank you.