Magecart payment card skimming analysis.

Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday presented by Juniper Networks. 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.

Dave Bittner: [00:00:26] And now a quick word about our sponsor, Juniper Networks. They're empowering you to automate your security, see your networks, and protect your clouds. Juniper Networks has you covered, so your security teams can finally get back to fortifying your security posture. Learn more at juniper.net/security, or connect with Juniper on Twitter or Facebook. That's juniper.net/security. And we thank Juniper for making it possible to bring you Research Saturday.

Dave Bittner: [00:00:59] And thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data - all without ever decrypting anything. All without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at enveil.com.

Yonathan Klijnsma: [00:01:39] So, we originally started tracking Magecart back in 2015.

Dave Bittner: [00:01:43] That's Yonathan Klijnsma. He's the lead of threat research with RiskIQ. Today we're discussing a series of RiskIQ blog posts covering Magecart.

Yonathan Klijnsma: [00:01:52] 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 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.

Dave Bittner: [00:02:14] And take us through - what exactly are we talking about, when we're talking about Magecart?

Yonathan Klijnsma: [00:02:19] 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.

Dave Bittner: [00:02:46] Now, is there commonality between the code that the different groups are using?

Yonathan Klijnsma: [00:02:50] 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 parts - so, the 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.

Dave Bittner: [00:03:16] Hmm. 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?

Yonathan Klijnsma: [00:03:22] 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 is 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.

Yonathan Klijnsma: [00:03:53] 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 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 are 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.

Dave Bittner: [00:04:36] And do you have any sense for who these folks are? Anything attribution wise?

Yonathan Klijnsma: [00:04:41] Now, 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, or at least he has - he speaks Russian natively. Now, we don't know if he's based out of Russia, but it's - that's what we have for them.

Dave Bittner: [00:05:01] 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?

Yonathan Klijnsma: [00:05:11] 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 gonna be very difficult if they have all this security stuff in place. So, the specific group that went after Ticketmaster is one we call Magecart Group 5, and all that these guys are doing is they are going after the supply chain.

Yonathan Klijnsma: [00:05:42] 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 - you know, they are good at what they're doing. They get 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.

Yonathan Klijnsma: [00:06:15] 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.

Yonathan Klijnsma: [00:06:34] 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.

Yonathan Klijnsma: [00:06:50] But Ticketmaster wasn't compromised themselves. They were breached because one of the providers they were using was breached, and this is - 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, you know, a thousand or ten thousand sites, instead of some of the other groups that do one compromise at a time. So they need to do ten thousand compromises to get ten thousand 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.

Dave Bittner: [00:07:24] Now, what's going on with this, in terms of a command-and-control server?

Yonathan Klijnsma: [00:07:28] 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 this script from one of their servers. That's one approach. But in the case for - with Ticketmaster, for example, they added their skimmer code to this third party. So they weren't hosting the skimmer themselves.

Yonathan Klijnsma: [00:07:56] 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 skim the form information and they send off the data to the drop server. And all this drop server does is accept the data and it puts it either on disk, depending how they set it up, or it puts it in a nice database. And these guys can log into their sort of administrative panels and see, you know, how much they actually have gotten.

Dave Bittner: [00:08:23] 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?

Yonathan Klijnsma: [00:08:44] 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, like, 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.

Yonathan Klijnsma: [00:09:07] 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, you know, this has no use, let's just drop them, it's an additional risk for us.

Yonathan Klijnsma: [00:09:20] Some of them are going to the 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.

Yonathan Klijnsma: [00:09:46] And then there is another approach for the companies that are a little bit more ahead. There is Subresource 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 it 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.

Yonathan Klijnsma: [00:10:13] 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.

Yonathan Klijnsma: [00:10:33] 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. 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.

Yonathan Klijnsma: [00:10:56] Now, personally, I don't see the approach of trying to go through all your providers and, you know, 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.

Yonathan Klijnsma: [00:11:10] 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.

Yonathan Klijnsma: [00:11:37] 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 they're doing their thing, making their products, 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.

Dave Bittner: [00:12:06] Now, what about, you know, 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?

Yonathan Klijnsma: [00:12:20] 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, like, all this analytics that's happening, ad providers - and then you have, like, the session recording companies, which do analytics by recording everything that happens on a website. Those guys, actually, by accident, sort of also copy payment information while they're doing an analysis, because they're looking at what is 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's going, it's a lot harder than you would expect.

Dave Bittner: [00:13:03] Hmm. Yeah, 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?

Yonathan Klijnsma: [00:13:10] So, the British Airways one is one we attribute to a group we call a 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.

Yonathan Klijnsma: [00:13:36] 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 integrate it really well, and they really take care, like, how - they breach an organization, and they take their time to figure out, what's going on? How does this organization work? How does, you know, their website look like? How does the website function, and where should we go?

Yonathan Klijnsma: [00:14:10] 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, 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.

Dave Bittner: [00:14:29] Yeah, it's interesting that in this case they were able to infiltrate the mobile devices as well.

Yonathan Klijnsma: [00:14:36] 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.

Yonathan Klijnsma: [00:14:58] 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.

Yonathan Klijnsma: [00:15:19] 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.

Yonathan Klijnsma: [00:15:44] 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.

Dave Bittner: [00:16:03] Hmm. Well, let's move on to another victim here. They were able to get in and compromise Newegg.

Yonathan Klijnsma: [00:16:10] 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.

Yonathan Klijnsma: [00:16:35] 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 fifteen lines of code, if you space it out neatly and make it readable. So that's fifteen 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.

Dave Bittner: [00:17:08] Yeah, it sure is. And is there - are they making any attempt to obfuscate the code when they're injecting it?

Yonathan Klijnsma: [00:17:15] 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 all 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.

Yonathan Klijnsma: [00:17:56] So, they are not doing obfuscation, just because their skimmer is very simple, and they - basically, the drop server - so, the server where the cards go to - what they try to do is they tried to blend this in. So the domain names - they will be similar, or they will be looking like a surface of one of the companies they breach.

Yonathan Klijnsma: [00:18:17] 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 in a website look like as well.

Yonathan Klijnsma: [00:18:34] And you could - for example, with Newegg, one of the steps in the checkout process for Newegg was a URL, and it contained the words "Global Shopping," I believe. Now, "Global Shopping" was capitalized with a G and an S. But the actual drop server part, 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.

Yonathan Klijnsma: [00:18:56] So they sort of make it really simple. They don't over-obfuscate, because that tends to stick out, at least for us. When we see obfuscated skimmers in normal script, you can see a really big difference, even if you look at something like entropy. So, they just - 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.

Dave Bittner: [00:19:17] Now, in the case of Newegg, was this going through a third party, or had they actually gotten into Newegg itself?

Yonathan Klijnsma: [00:19:23] They had gotten into a 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.

Dave Bittner: [00:19:41] Hmm. 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?

Yonathan Klijnsma: [00:19:48] 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.

Yonathan Klijnsma: [00:20:14] 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 the 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.

Yonathan Klijnsma: [00:20:35] 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 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 fifteen minutes later to modify the script again, to actually add an obfuscated version. And they - you could sort of, you know, they forgot to do this. They were jut, possibly rushed, in some way, and they just forgot to do it. So, we were in contact with Shopper Approved over the weekend. And on Monday morning, when all their teams got in, they cleaned it up and they started their investigation.

Dave Bittner: [00:21:15] 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?

Yonathan Klijnsma: [00:21:24] So, the problem is, is that there's not really specific things for Magecart itself. If you look at the perspective of how these guys got in, there's a variety of ways. They will do anything from using - 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 have installed. So, if you're running an old Struts, they'll try to use it to get in.

Yonathan Klijnsma: [00:21:58] 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.

Yonathan Klijnsma: [00:22:14] One thing we advise a lot of organizations, is to isolate your payment form. So, a lot of times these pages - the payment pages 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.

Yonathan Klijnsma: [00:22:39] Now, at the same time there are other concepts you can use. So you can use CSP, which is the Content Security Policy, and you can define where data can go through, where it can come from and go to on your website. And at the same time, you can also add the Subresource 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 are sort of different controls.

Yonathan Klijnsma: [00:23:05] Now, this Subresource Integrity - we also advise people to do this on their own side. So, Subresource Integrity is for the visitor, and the browser of the visitor. But one thing we advise people is 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.

Yonathan Klijnsma: [00:23:33] So there are 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 sort of protect you from Magecart as a whole, or, you know, these Magecart type of attacks. It's about layering your security and just getting multiple things in place.

Dave Bittner: [00:23:54] Now, 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?

Yonathan Klijnsma: [00:24:05] It's actually more than full-speed. It's ramping up. If you look at it 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, 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.

Yonathan Klijnsma: [00:24:46] 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 very impactful way to get payment information.

Dave Bittner: [00:25:01] Now, is - generally, I mean, the endgame for these Magecart groups - is it the selling of the cards themselves, the selling of those numbers, or are they are they using the cards to purchase things for themselves, or to try to cash out that way? Do have any sense on that?

Yonathan Klijnsma: [00:25:15] 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. Bur 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 US, 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 US using stolen payment information, ship it to the mule in the US, 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.

Dave Bittner: [00:25:56] 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, you know, 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?

Yonathan Klijnsma: [00:26:17] It would, because it's a token transaction. You are not actually giving your payment information at that time, which is, you know, 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 sort of, like, 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.

Dave Bittner: [00:26:59] Yeah, 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.

Yonathan Klijnsma: [00:27:15] 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 reward members' transactions.

Yonathan Klijnsma: [00:27:36] 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.

Dave Bittner: [00:28:01] Our thanks to Yonathan Klijnsma 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.

Dave Bittner: [00:28:14] Thanks to Juniper Networks for sponsoring our show. You can learn more at juniper.net/security, or connect with them on Twitter or Facebook.

Dave Bittner: [00:28:23] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at enveil.com.

Dave Bittner: [00:28:32] The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technology. The coordinating producer is Jennifer Eiben. Editor is John Petrik. Technical editor is Chris Russell. Executive editor is Peter Kilpe. And I'm Dave Bittner. Thanks for listening.