Transcription performed by LeahTranscribes[FULL TRANSCRIPT]
JACK: In October 2015, Carlos, a Florida man, was manufacturing credit card skimming devices. These are little devices you can stick on a gas pump and anyone who comes and swipes their credit card at the gas pump will get their number saved to this little device. It’s a popular attack because not everyone is watching the gas pumps so you can easily sneak your skimmer onto it. It’s hard to sneak a skimmer onto a point of sale terminal in a store because the clerk is standing right there but gas pumps are usually standing right there in the open for anyone to just go use. [MUSIC] Carlos’s skimmers were slick; they were small, battery-powered, and can store up to a gigabyte of data on them. He stuck one on a gas pump and came back a few days later, plugged a USB cable into it, and downloaded all the credit card data off there. This is called track data.
This was amazing for Carlos so now that one skimmer seemed to be working pretty well, Carlos started planting more and more skimmers all over Miami, Florida. Then he’d come back, hook up a USB cable, and download all the card track data. Carlos thought this was great but now what? How do you turn the track data into money? He thought about this; one could try selling the track data online but you don’t get that much for each card. Carlos was, after all, a DIY kind of guy so he bought a credit card writer and a bunch of blank credit cards. He would then transfer the credit card track data to these blank cards. This allowed him to go to the store and buy stuff with these stolen cards but Carlos had a lot of stolen cards, so he got two more Florida men to help him, two guys named Yordano and Gilner. Carlos wrote about fifty credit cards to blank cards and gave them to Yordano and Gilner and sent them both to Washington state to try to cash in on this.
The theory was that Washington was on the opposite side of the US from Florida which was far away from Carlos, giving him a perceived security buffer. But on top of that, he made them go to Spokane, Washington which is far away from Seattle where the FBI or Secret Service might be stationed and looking for this kind of activity. Spokane was just far enough away from the feds and just big enough to have enough unique stores around town to do this. The plan was to buy as many gift cards as possible with these stolen cards. The two men started buying tons of gift cards, like $200 pre-paid VISA cards. They did this, a lot of this. They bought tons of gift cards with these stolen credit cards that Carlos gave them. See, gift cards don’t have a name attached to them so it’s much easier to use them anonymously or sell them. It’s a way to launder the money.
The plan was going great and Carlos, back in Florida, was telling them he’d buy all the gift cards for half price, giving everyone a nice cut of the whole operation. The math still works out; if Carlos could get $100 per stolen card, that’s still way more than selling them on the black market. Everyone here was happy. [MUSIC] But then, one of the stolen cards happened to be stolen by someone who lived in Washington state. They saw this fraudulent purchase and immediately reported it. Quickly, the authorities got the CCTV footage of the store and saw Yordano and Gilner buying these gift cards. The authorities found what hotel the two were staying in and arrested them. The cops found a total of $35,000 in gift cards in their hotel room. Both were found guilty of credit card fraud but Carlos was still back in Florida. He wasn’t quite in the clear, though; he was brought to Washington and charged as a conspirator but with a typical trial, he was placed on a standard release condition until his trial began.
He went back home to Florida to wait for the trial. Now, this is where Carlos, our Florida man, really shines. While on release for his trial for credit card fraud, Carlos continued to make skimmers and put them on gas pumps all over Miami. He would continue to scrape the data off these devices, stealing more and more cards while waiting for his trial. The police searched his apartment and found even more stuff than he originally was charged with and this brought all-new charges against him. He was found guilty in both Washington and in Florida. He had to serve a 30-month sentence for his crimes in Washington and Florida gave him an additional 144-month prison sentence. This Florida man was going to serve a total of fourteen years in prison for skimming credit cards. That case is closed; there’s no more skimming going on in Miami now, right? No, not exactly. Skimming like this is growing in popularity and in fact, the Secret Service has seen such a problem with it that they had to enact Operation Deep Impact to combat this. Due to its popularity, it’s not just credit card readers anymore. This problem of credit card skimming has now infected the online world, too.
JACK (INTRO): [INTRO MUSIC] [00:05:00] These are true stories from the dark side of the internet. I’m Jack Rhysider. This is Darknet Diaries. [INTRO MUSIC ENDS]
JACK: As I was saying, credit card skimming isn’t just at the pump; it’s happening online in ways that you might not be aware of and I want to talk about it. Today, we’re gonna talk to one of the leading researchers of this problem.
JON: My name is Jonathan Klijnsma and I’m the head of threat research for RiskIQ.
JACK: Is it Yonathan or Jonathan?
JON: Technically Yonathan but we say Jonathan. I’m Dutch so the pronunciation goes two ways.
JACK: Okay, so Jonathan works for this company called RiskIQ. What they do is nothing short of amazing.
JON: I’m the head of threat research within RiskIQ. RiskIQ, what we do, is we do data collection and one of the biggest points of data collections for us is web crawling. We deal with about two billion pages a day. It’s not just like sending Wget to a website. It’s a custom-made engine running JavaScript, interpreting JavaScript.
JACK: Jonathan has this insane web crawling bot that goes out to two billion websites a day. [MUSIC] It goes to Alexa’s top two million and then spiders out from there. He’s able to do research on what he finds. He can filter it, organize it, compare it, alert on it. What he’s looking for is malicious activities on these websites. This is what a threat researcher might do; scour the internet looking for seriously bad stuff to investigate on.
JON: We’ve been crawling for a long time. One of our key things is history. We have a lot of that so even if we find something later on, it’s like, Antivirus products – it’s cat and mouse. If something’s completely new, done in a way that’s never been done before, nobody will detect it until they figure out what it is or until they’ve been told what it is, or until they see it. One of the things is, if we find something that we haven’t seen before, we can always go back and see when something started, when something first appeared.
JACK: This, to me, is incredible because basically, Jonathan has historical records of two billion web pages that he can pull up from days ago, weeks ago, months ago, years ago. This is sort of like his own private way-back machine. He can look to see what was on those pages for as far back as years but more specifically he can look to see what malware might be on those pages. Yeah, websites can exploit your browser; if you have an outdated browser or plugin or something, a web page can take control of your browser and infect you. It does this through JavaScript or Flash or Silverlight, or some back-end language, or something else.
JON: Our main point is just data collection. We can make conclusions on the data. One of the things we’re able to do is, if we point our crawl to a website, it can tell us it’s running WordPress version something with these plugins installed on an Apache server that has PHP version something and we’ll match the CVEs for example, to it. The threat research team is there to find the bad stuff so when we’re crawling a website, could be that there’s a skimmer on there. Could be that you’re being redirected to an exploit kit. Could be that there’s just some scams going on; you’re redirected to a tech support thing.
JACK: Sometime back in 2015, the team at RiskIQ started noticing some interesting stuff happening to websites running Magento. [MUSIC] Magento is an E-commerce site builder, just like how you can download WordPress and have it host your own blog. Magento is the same thing but for making online stores. You download the Magento PHP bundle and it has templates and themes for how your store looks. You customize the store to make it look how you want and then you list the items you want for sale and then you publish it. Now, people can go to your Magento store, see your selection, put the items in the cart, and check out. Of course, when they check out, they enter their credit card details to buy something from you. Very cool for someone who wants to set up an online [00:10:00] shop but also comes with a risk. See, Magento itself is safe and secure.
I mean, it’s owned by Adobe at this point and it’s open-source and there’s a lot of developers working on it. But there are people who quickly set up their online shop using Magento and don’t think much about the security. They think they’re done and then they focus on their product and marketing but what the shop owners fail to do is put any focus on security. If you don’t update Magento, it can become vulnerable to well-known attacks. If you don’t secure your servers that you’re hosting it on, it can leave you open. Yeah, if you don’t use strong passwords to access Magento as an admin, then yeah, you get it. Here’s the crazy part; there are over 100,000 online stores right now running Magento. Even if 1% of them didn’t have good security, that means 1,000 online stores are easily hackable. This can be a problem. It is a problem, a problem that Jonathan saw. He saw there was a particular group of hackers online looking for exploits in Magento.
JON: When we were recently looking at this back in 2015, these guys would always compromise Magento. One of the files they would modify originally was mage.php which is one of the core files of Magento. They would skim you when you would go to your checkout to your cart. We had to give it a name internally to reference it and at some point, this turned into Magecart.
JACK: Whoa, this group of hackers in 2015 had found their way into websites running Magento and then found where the checkout section was and put in some JavaScript to make a copy of any credit cards that were entered on that page, giving the hackers a copy of the credit card. They were doing credit card skimming on the website and the team at RiskIQ called this group Magecart.
JON: [MUSIC] The skimming code is a small piece of JavaScript. It can be as small as fifteen lines but we’ve seen them up to 1,500 lines. It all depends what they’re actually doing with their skimmer. For the most part it’s very basic; you want to get payment data. But these small pieces of JavaScript are just loaded into a website and from the browser perspective, it’s just another script ‘cause browsers don’t really differentiate when to load up a web page. There’s a whole lot of stuff happening. If you’re on a mobile device, they change how the website looks. If you’re on a desktop, they change how it looks. These scripts have the same level of access to any data in the web page so once you’re entering payment data, the same script that gets you a popup to, I don’t know, submit your e-mail address or to subscribe to a newsletter, that same script also has access to this payment data. There’s no differentiation.
Once these bad guys just get their script running on your website, that’s all they need ‘cause that script basically goes through everything that you see on the website and when you’re entering the payment information on your payment form, what they look for is this form. There’s different ways of identifying this form. Some of them look for really identifiable names like Payment Form or Payout or they look for fields that have names like System Number or Credit Card Number. Once they identify a form that might hold potential payment data, they wait for you to hit the button for payment which what actually happens when you do it, is you submit this data back to the website in the terms of their browser. It’s called submitting a form. These skimmers, these small pieces of JavaScript wait for you to do this. Once you do this, they quickly take your form data, send it over to their own server so they have your card data. Then they let it go through as if you normally submit your data for payment during a checkout process.
JACK: Yikes. In as little of fifteen lines of JavaScript, your credit card can land in the hands of the wrong people who can then do what they want with it. If you think about what you enter on the website; you put your name, the credit card number, the expiration date, and that little code on the back. That’s more than enough for a criminal to just use to buy something else on another website or print that number to a blank card and go buy gift cards. But in order for this to work, the hackers need to put that malicious JavaScript on the website in order for it to execute. Getting it on the website isn’t always easy but there are some ways to do it.
JON: A lot of different ways. Some of them breach these websites directly, so an online store can be breached directly and they’d find a way to load in the script by putting it – for example, a lot of these platforms have the option to add Google Analytics Code, for example. You can add your little snippet of Google Analytics to the footer. What they sometimes do is they add their JavaScript to this snippet for Google Analytics. There’s just a lot of different ways you can add it depending on the platform. But the way to get it on the website is you either breach it directly or you go through a third party, like I said. A lot of websites load in ads, load in live chat support from remote services, a whole bunch of different things. You can be compromised through a supply chain by which you [00:15:00] technically not have a lot of control over ‘cause you don’t control the servers for the live chat service that you have on your website, but if the bad guys get in there and they put their script in the live chat server scripts, it gets loaded with that. We’ve observed this a whole bunch of times.
JACK: You might not think about the supply chain of websites but if you’re a website owner, you should. [MUSIC] Most websites today don’t just run HTML and that’s it; they also use CSS which stylizes the page and then they bring in JavaScript which brings in more features and functionality. But typically, you don’t code all this CSS and JavaScript yourself. You find a library that someone else made and bring it over. Now, you’re running code on your website that you didn’t write. When your users come to it, that JavaScript you took from some other library executes in the user’s browser. All this is fine because you’re probably using an open-sourced library that has all its bugs squashed and people are actively updating it. But here’s the thing; a lot of people who run websites don’t host this JavaScript library themselves.
They just link to it so when a user comes to their site, it says oh, you need this jQuery library from this other site before you can see this page, and your browser just automatically goes to that site, gets jQuery, and runs it. But think about going to a store to buy bottled water; the store didn’t bottle the water. They ordered it from a bottling plant and then stocked it for you to buy. The store trusts that bottle of water is good and won’t make people sick. But what if someone did get into the bottling company and poison the water? Then that water gets bottled and shipped to many stores all over. This is poisoning the supply chain. The same thing can happen online. Imagine what would happen if that central JavaScript library got hacked and started hosting JavaScript libraries with credit card skimming code in it? Yikes. That’s just what happened with Magecart; the hackers were getting this malicious JavaScript into these sites through the supply chain.
JON: That’s the current one we’ve seen, some 17,000 or so websites, probably a lot more by now, that are just loading content from S3 buckets that are not secured properly or incorrectly configured, basically. They end up with skimming code.
JACK: The thing is, the website owners would never know if their supply chain got hacked unless they go through and look at every line of JavaScript code to confirm it’s correct, and then do that every day to make sure it hasn’t changed. Well, that’s where Jonathan and his team come in; they’re looking at this particular thing every day. What they’re seeing is staggering. There are tons and tons of websites out there that have malicious JavaScript running on them.
JON: Way too many. One example I can give you, one third-party supplier that we observed hit about 100,000 websites and appeared that it was affected. That’s just one third-party.
JACK: Would all those websites be E-commerce? My blog doesn’t have a credit card form, you know.
JON: Right, yeah, that’s one of the things. We see a lot of websites hit. It’s the same with the Amazon campaign that we see right now. A lot of sites get hit; not a lot of them actually run payment data through their website. Not all of them are E-commerce sites. While we see a lot of them get hit, it’s not always that for one, they’re processing payments or two, that the skimmer even reaches that payment or the checkout page ‘cause that’s another thing. If you set up your E-commerce site properly, you shouldn’t run ads, for example, on your checkout page. You want to avoid running any external party on your checkout page. We still see it happen, obviously, but it’s one of the advice steps we give. But from the third-parties, it isn’t always an E-commerce site but it’s kind of hard to tell you exactly how many, but it’s got to be in the hundreds of thousands, easily.
JACK: Just to be clear, not all these sites that are compromised are running Magento. This is just where the term is originated from and where we get the name. The hackers have fanned out to many different platforms now but also continue to target Magento sites.
JON: It’s a really prevalent problem. Web skimming is the go-to thing by now if you want to steal credit card data. It’s not as much direct breaches anymore; it’s just, get a web skimmer on a web page and you get payment data.
JACK: [MUSIC] Now, while the Magecart hacking group initially started as a single group in 2015, over the last four years, it’s grown to be a common tactic used by many hackers. Jonathan originally had one Magecart hacking group but now there’s Magecart hacking Group 2 and Group 3 and Group 4, and so many more. They all skim credit cards from websites. While Jonathan was researching all this and tracking all these different groups, out of nowhere, he saw this on the news.
REPORTER: Hundreds of thousands of British Airways passengers have had their bank details stolen in [00:20:00] one of the biggest data breaches to hit a UK company. The airline discovered on Wednesday that bookings made between August the 21st and September the 5th had been compromised with hackers taking credit card details, along with e-mails and addresses.
JACK: Even the CEO of British Airways came on TV to say what’s been stolen.
CEO: We know that information that has been stolen is name, address, e-mail address, credit card information; that would be credit card number, of course expiration date, and the three-letter code on the back of the credit card.
JON: On September 6th last year, they announced that they had suffered a data breach. They put up a web page, they had some, I think, interviews pre-lined up with BBC. They said they had about 380,000 affected customers and they had a really specific timeframe for it, as well. They said there was theft of customer data between 10:58 British Standard Time, August 21st until 9:45 British Standard Time, September 5th. There was a really specific timeframe and they basically said if you believe you may be affected because you made a booking or paid to change a booking with a credit card or debit card on ba.com or the mobile app between these and these dates, we recommend that you contact your bank.
For us, when they started saying credit card, debit card, ba.com or mobile app, something told us like maybe something’s going on, ‘cause we were expecting that at some point, something big would happen. We took the fact that they said ba.com was affected, their mobile app was affected, and they had a really, really specific on-the-minute timeline. The end time you can understand ‘cause that will be they investigated and they cleaned up, so they will know once they cleaned up. But they had a very specific timeline for when it started.
JACK: Now, keep in mind that the web crawlers at RiskIQ have been going out to British Airways websites for years, taking a snapshot of everything there, day after day. British Airways was not saying how they were hacked. Even to this day, they never told us how the hackers stole all these credit cards but Jonathan wanted to find out and he was in the perfect position to look back at the history of the British Airways website to see if he could find out what happened for himself. After the break, we’ll hear what he finds. Stay with us.
JON: What we started to do is just, okay, within the timeframe, let’s first find what actually happens. [MUSIC] They said August 21st until September 5th, so let’s grab all our call data and go through their website and just see what happened during that time and was there a change before that timeframe to within that timeframe, and was there anything really specific? We were going through crawls, a whole bunch of crawls. We started going through it and we noticed a change in the file and specifically, the file was a JavaScript library called Modernizr. Modernizr in itself is nothing super interesting; it’s a way to make sure that your website will work on older and newer browsers. It helps you with that. But one of the things we noticed, that before this date that they gave – so, they said it started on August 21st. When we went to the timeframe the British Airways said they were affected, the file had been modified on the 21st of August, exactly the timeframe that they gave.
But we were looking at the file ‘cause it was modified and we noticed that the technique that we observed so many times at the bottom of this JavaScript library, they added a really, really, really tiny script and they made it even smaller by minimizing it but if you wrap it out and you look at it, it was about twenty-two lines of JavaScript. It was very, very small. The skimmer then would go through the payment form and [00:25:00] pull out the data and send it off. They did it in a very simple way. The reason for that is, they just grabbed it, push it out to the server, and once we have it, we’ll go through it, sort it and clean it out, and do all of that. Their point was just, we need to make sure that somebody’s doing a payment, and then just send off all the data. We can scrub it later. Just try to get as much while we have this organization breached. They changed just one JavaScript file and there are maybe a hundred different files on that – for the website, for ba.com.
It’s a big website; there’s a lot of libraries, there’s a lot of stuff going on. They modified just this file ‘cause they had figured out that both mobile transactions as well as desktop transactions would load in this file. They had done their homework; they really figured out what – the cross-action between mobile payments and mobile desktop payments. It was this file that was always loaded. They took their time to figure this out. They went in, they breached BA. We don’t know how but they breached BA. They went on the server and they added their teeny, tiny snippet of code to this Modernizr library. When BA confirmed, 380,000 people were affected just by this web skimming attack.
JACK: Whoa. This is crazy. That skimmer was only on BA’s website for a month which is a big haul for using such a little piece of code, and to hide it by sticking it in a well-known library that you didn’t write means you’ll probably never know it’s there. Now, we don’t know how BA discovered this but what typically happens is when people start using the cards fraudulently, they get reported and then the credit card companies will do a report on the reported cards to try to find a common purchase point. This will then narrow down where they think the credit card breach might have occurred and notify that company. This might have been how BA discovered this but still today, there’s been no explanation on how BA discovered this or how the hack happened, or what happened, really.
JON: British Airways never explained exactly what happened. They tried to avoid it in any kind of media engagement. If you look at what they did PR-wise, they basically tried to flush it out with other news. They tried as hard as possible to make sure that nobody was talking about this. Until this day, we still don’t know exactly what happened internally.
JACK: The CEO said they would reimburse anyone who was a victim of credit card fraud from this. That seemed to be the end of this incident. It quietly fell off the news cycles and disappeared until this year. [MUSIC] In 2019, the ICO had one last say in the matter. The ICO is a regulatory body in the UK, sort of like the Federal Trade Commission in the US. They investigated this and thought British Airways wasn’t following proper regulations regarding online security. The ICO found that over 500,000 user details were stolen from this hack. After their investigation, they found that British Airways wasn’t following proper GDPR policies and gave them a fine totaling $237,000,000 US dollars, or £183,000,000 British pounds.
This is a record-high fine for anyone violating GDPR but $237,000,000 is just 1.5% of their earnings during the year they were breached. It’s enough to make BA notice this but I’m not sure if it’ll hurt them that much in the long run. [MUSIC] Now that Jonathan has been studying this Magecart hacking group for a few years and he saw exactly what happened with British Airways, he was able to take this knowledge and searched his database of cashed websites to see if this same group might be hacking another website.
JON: We know that this group, for them, this web skimming is a tool in their arsenal. It was a week later; we published British Airways and then a week later we were looking at this.
JACK: They did find the same skimming code on another website. This time, it was on the website newegg.com.
JON: The thing is, I’m not from the US. I’m Dutch so I’ve been looking at this, not being aware that Newegg was a big thing ‘cause I’d never actually heard of it and it was just one of the many hits that we were looking at when we go through our data.
JACK: Newegg is one of the largest retailers in the US. In 2016, they made 2.6 billion dollars. It’s one of the top ten biggest online stores in the US. They mostly sell computers and computer parts. In fact, I’ve ordered many, many things from Newegg.
JON: What happened there was it was another breach. Newegg has kind of a different payment process. This is again where you can see that these guys [00:30:00] are quite smart about it. We noticed that on August 13th, they registered a domain called neweggstats.com. It was registered on August 13th. Going through our data on the Newegg website, one of the things we noticed is that the checkout process is a little bit more elaborate than BA. Their process goes that, you need to go through the store, put a product in your shopping cart. You go to the first step of the checkout which is where you enter your delivery information like your billing address and your shipping address.
Then you click Next. You go to a new page and this is where, actually, you go and put in your payment information. In that page, directly in there, it wasn’t a JavaScript library like with British Airways. They had put an additional script tag and they added some additional scripts. This one was fifteen lines. It was slightly smaller. They had condensed their code a little bit but again, this script would look for a really specific button. This one was specific to the Newegg checkout. Again, it would do the desktop payments and mobile payments.
JACK: By adding fifteen lines of JavaScript, the hackers were scraping every credit card entered into Newegg’s site and because this site was so popular, they must have been getting tens of thousands of credit cards a day; maybe much more than that. What’s worse is that Newegg had no idea this was going on. Jonathan and his research team saw this while it was happening. The hackers were live on Newegg sites, scraping every card they saw. The team realized this was a big site and even though they found skimmers on thousands of other sites, this one was really big and actually so big that they wanted to do more research about this and reach out to the site.
Jonathan and his team moved quickly; they grabbed all the details they could and gave all the information to Volexity. I don’t know exactly why they worked with Volexity but this is a company they trust and it does incident response. Volexity took this data and reached out to Newegg to tell them about this problem, and probably said at the same time hey, if you want help cleaning it up, we can help you. Within a short time after that, Newegg had their site cleaned up. In total, the hackers had their skimmer code on the Newegg website for a total of thirty-three days.
JON: We were at the party with which we published, Volexity. They ended up talking with them directly to inform them. We were doing this over the weekend to inform them. Then they got it cleaned up. They were informed but they never made a very big public statement and up to date, I don’t know if they’ve done one but even then, there hasn’t been any update on it since.
JACK: There aren’t any good articles online where Newegg admitted to this. All I found was this tweet where Newegg said quote, “Yesterday, we learned one of our servers had been injected with malware which was identified and removed from our site. We’re conducting extensive research to determine exactly what info was obtained and we’re sending e-mails to customers potentially impacted. Please check your e-mail.” End quote. I’m concerned about this; I’m a customer of Newegg and I had no idea this happened until I talked to Jonathan here. Newegg didn’t e-mail me about this breach and I don’t even think they knew about it until Jonathan found this and told them. There’s very little from Newegg talking about this at all. When a company doesn’t own up to the bad stuff that happens to them, it just makes me wonder what other stuff they’re hiding.
If they had other breaches, they probably wouldn’t have told anybody about those, either. What shady stuff might they be doing with our user data? Now I’m reading that until 2016, Newegg was an American company but then, a Chinese company bought a majority stake in Newegg. Now it’s under Chinese control. Oh, Newegg. [00:35:00] [MUSIC] I once had my bicycle stolen. I was stupid and I left it at the train station for six hours with a cheap lock. I came back and the lock was cut; the bike was gone. The first place I looked for this stolen bike was Craigslist. This is where people sell their old stuff and yeah, I’m sure a lot of it is stolen.
I didn’t ever see my bike again but it was worth a look. There’s a similar thing you can do for stolen credit cards like this; when a big breach like this happens and tens of thousands of credit cards get stolen, the thieves can’t just cash out on that many cards. I mean, imagine printing ten thousand blank credit cards and standing in line at a store, trying to buy every single $200 gift card you can. You’d be doing it for months and surely get caught along the way. The thieves have no choice but to sell them on the dark markets. Now, Jonathan knows this, so after a breach like this happens, he goes on a hunt to try to find where these cards are for sale.
JON: [MUSIC] We don’t publically state which market it is just because there’s a lot of ongoing investigations. This is probably going to be a story that will go on for a long time but one of the ways is, there weren’t any other card sales going up at the time and a little bit after BA got cleaned up, there was a sudden dump of cards. Whenever these guys put up the sales of cards, they also list where the cards come from ‘cause it’s important for the people who buy cards to know where the cards are valid. ‘Cause if you use a US card for fraud in the US, it’ll be less noticeable than if you take a US card and go to Europe and Eastern Europe and start using it there. There will be a bigger red flag than just using it in the US. There’s a lot of reason for them to want to know what was going on. When they put up this sale, about a week after BA got cleaned up, they called it XMassive and they had EU, UK, and US cards in there. They didn’t specify how many.
They said high-validity, 95%, which usually means it’s a pretty – it’s a recent dump, basically ‘cause at times, cards will be invalidated if you sit too long on your card data, cards will get invalidated because people get new cards or they lose their card, they issue a new one. There’s a lot of reasons but the validity goes down quite often. This one had a high-validity rate. They said 85 to 95% which is pretty high. Then if you look at the countries, they said UK, US, Germany, Italy, Spain, Canada, France. The list just went on which meant it was a very big international organization. Now, one Intel vendor which we worked with at the time, decided to pursue some of these cards and see where they were valid from and where they were used from.
[MUSIC] They ended up linking it to the BA dump. Once we got Newegg cleaned up, again, a week later, they pushed an update. They said they had – they called it US Eagle. It was the name of the dump they were selling and they said it was half a million cards. They said 90 to 95% validity. That’s really, really high. That’s high confidence. They said it was a US mix only. Only US cards. If you get half a million cards, you need to breach a big organization. They said nothing about the states or anything ‘cause a lot of times when it’s US-only, they put in the states of where the cards were from. They didn’t put any of that in but again, somebody sampled some of the cards and they ended up being able to link it back to the Newegg breach.
JACK: It’s so much fun to watch the internet through a lens of how other people see it. Jonathan can see the history of two billion web pages and can find what web pages are currently being skimmed and then a week later, go and chase down those stolen cards on the dark net. It’s quite an incredible way to see things. He sees what lies just behind the front page. He watches what stirs in the darkness. It’s also fascinating to look at the supply chain of stolen cards. First, there’s a group who does the hacking to get the credit card data and then this probably gets sold super-cheap to some other group just to post it for sale. Then that gets in the hands of many people around the world who then use these stolen credit cards to make illegal purchases with it. Yeah, you might be able to buy a stolen credit card for like, twenty bucks, and then use it to buy a $200 gift card but you have a high chance of getting caught and going to jail over it because this is a serious crime in the US and specifically, the group that tracks financial fraud is the US Secret Service.
Yeah, they also protect the president [00:40:00] but they spend a lot of time chasing down fraudsters, too. They take this stuff very seriously and when alerted, they can move very quickly to try to track down someone who swiped a card that’s known to be stolen. I’m sure Newegg got to know the Secret Service very well after all this was over. Now, Jonathan has been tracking these hacking groups for years. He calls them Magecart Group 1, Magecart Group 2, and so on. At least seven different distinct hacking groups are doing this kind of credit card web skimming now but I can’t find any articles saying that anyone from any of these Magecart groups have been arrested. Jonathan hasn’t been able to track down anyone to a single person because as he puts it…
JON: They are criminals and, in my eyes, if you make something personal, they will make it personal. [MUSIC] I personally don’t want to know who they are.
JACK: But that doesn’t stop Jonathan from trying to disrupt them. He often goes into battle with them.
JON: One of the very interesting groups I have, or well, we have. We published about them a bunch of times. We call them Magecart Group 4 and they’re a very technically advanced group. We’ve been messing with them, taking down their infrastructure from time to time to force their hand, to see their attempts mess up. Just to see if we can get some more insight to them. We’ve been at this group for a long time. We took down I think about a hundred domains initially when we first decided to disrupt them completely. They set up new domains.
JACK: How did you take them down?
JON: We worked with Shadow Server and abuse.ch and with the registrars that have those domains registered. We have to prove that whatever’s happening on those domains is bad and is only for a bad purpose. With that, they give over DNS control for those domains. They move them away from the customers who bought them. They give DNS control and what we did is we sink-holed them with Shadow Server which is a non-profit organization which means that anybody who hits up those sink holes will end up in Shadow Server reports. What happens with those, is those are accessible for law enforcement but they will also be sent out to the owners of the IP space that’s affected. It’s sort of automated reporting on that something happened. It’s one of the ways that we try to do this reporting of Magecart-affected stores and affected infrastructure. ‘Cause like I said, we can’t scale to contact 17,000 individuals to tell them that something’s going on.
This was one of the ways. We took down those domains initially, made sure that they were sink-holed through Shadowserver, that reporting would go out. Those guys, again, they registered new domains. We waited a little bit and we took it down again. Same thing, they registered new domains and they started making mistakes. Because we were so actively taking it down, that they were rushed into setting up new infrastructure. They started making little mistakes which made it even easier for us to track them and track new infrastructure they had set up, and slowly piece together links. But there was a funny side effect to this, as well. [MUSIC] One of the things they were trying to figure out is how we would get to their domains. I’m not gonna explain it just because it’s a really nice trick that still works and we don’t want them to know how it works. But we were able to identify the domains the whole time and take it down.
What they would do, is they’d try to figure out what part of it was going wrong. They would change the registrars. That doesn’t really matter for us. They would change where they were hosting but with that, they were moving through all kinds of IP space that if you looked around a little bit in it, you would find so much more bad things that 100%, the hosters that they were using; not per se the people that were hosting the IP space or hosting the servers but the people who would sell access to those servers for use were what we would call bulletproof hosters, or at least, criminal hosters. By going through all this IP space, they were telling us exactly where to look. Slowly, they were telling us oh, yeah, this is another piece of bad IP space that you should probably have a look and maybe blacklist a few things, take some things down. This continued on.
Up ‘til to date, we still find new infrastructure from them. We’re again waiting a little bit and we’ll probably do another takedown just to keep forcing their hand. Because they’re the most advanced group, we also think they have the best throughput, not in the sense of 380,000 cards like with BA but they’re advanced enough that whatever card got skimmed gets put on sale really quickly. We think their advancement is also that they have good ways of selling out the data once they get it. Right now, we can’t do anything to them themselves. We don’t know who they are, exactly. They’re really good at setting up their infrastructure and making sure it’s really hard to link it to anybody at all. We’re just [00:45:00] here to disrupt the whole time in different ways. Sometimes it’s takedown of domains, sometimes we take down servers from them just to disrupt them, to try to stop them from being able to get to more card data.
JACK: How does RiskIQ get money? How do you get paid? Because this kind of research isn’t really funded by anyone.
JON: We get paid by customers who use our data as in, we have different products. One of the products is that you have raw access, or you have a web UI which gives you access to our different data sets that you can go through. We have a product where, like I said, we do the vulnerability tracking, configuration tracking for companies’ websites, we map infrastructure for companies. We have it all different ways. We also have people that just buy bulk access to APIs on our data.
JACK: Now, you might be wondering as a consumer or a website owner, how can you protect yourself from these Magecart bandits?
JON: As a consumer, it’s actually really hard. We don’t have a full answer for it. The one thing I would suggest is – one of the things I like to do is on the website where you can pre-store your card data, for example, one of the places where I still do transactions is Amazon. I’m very skeptical about every teeny, tiny, small store I find. But for the most part, just keep track of the expenses and keep track of your card and if there’s anything that looks off, banks are more than happy to reissue. For website owners, there’s a lot of things. There’s the high-level stuff like please don’t run ads on my checkout page. There’s no need for it. You don’t need analytics on a checkout page. Somebody navigated your website, was able to put stuff in this cart, and is doing a checkout. He doesn’t need much more at that point. With that, there’s also a lot of technical things you can do.
One of the things you can do which is called Subresource Integrity, is you can give the browser a checksum, a half checksum of the file you will be loading. Now, let’s say, for example, the British Airways one. They would have had SRI on their page. The attackers would not have noticed. They would modify the file, the checksum would not have matched, and the browser wouldn’t even execute the modified library. That’s one. Another one you have is separating the payment process from the website through something like iframe sandboxing. The point is just to make sure that that payment data, the point where somebody’s entering payment data, becomes as isolated as possible. Nothing should be able to touch it. The only thing that needs to know about it is the server that’s gonna process the payment to authorize it. Isolating that is mostly key. Then there’s one thing, they’re called CSP header. It’s Content Security Policies.
You can basically define where data can come from and go to from your website. One of the things is, if everybody in the world is really good at setting up CSP headers, we would have a whole lot less web skimming capabilities ‘cause they send off data to remote servers almost all the time and if you set up CSP headers to say you can only send data here, which should be your own website pretty much, it would not be able to send that data and the browser would not allow the skimmer to send out data to the remote website. Of course, caveats do this; one of the reasons why a lot of websites don’t run CSP headers or do it incorrectly is because they want to have ads. Ads reach out to a remote server who then inserts content from another remote server which it can’t know beforehand ‘cause somebody will be running an ad campaign from somewhere.
It gets really complicated so a lot of websites that run ads have a hard time defining strict CSP or Content Security Policies ‘cause they just have so much content coming from everywhere. There’s a lot of different ways going through this. I think the most important part besides general security hygiene is putting in small barriers and isolating your payment data. When you’re on a payment page there shouldn’t be a whole lot of extra things happening there. It doesn’t need to look very, very pretty and like, movements and animations and all of that. Make it very simple and isolate the payment data as much as possible.
JACK: Hm, it sounds like this problem is growing. It’s getting bigger and it’s not going away anytime soon. So, be safe out there because online credit card skimming will continue until security improves.
JACK: I have some very sad news to add here at the end. On Jan 6th 2021 Jonathan passed away. Shortly after I interviewed him he was diagnosed with cancer. He put up the fight of his life for 15 months. He was 29 years old. I am saddened from this news and already miss him tremendously.
JACK (OUTRO): [OUTRO MUSIC] A big thank you to our guest Jonathan Klijnsma for doing so [00:50:00] much research in this area and sharing it with us. Jonathan has fallen on some hard times; if his work is valuable to you, take a look at the show notes and see what you can do to help him. I know I’ll be helping. You can buy Darknet Diaries shirts and stickers at shop.darknetdiaries.com and in case you’re wondering, the shop is hosted and ran by Shopify. I don’t have enough time or confidence to run a secure E-commerce website, especially not hearing this story. They do all of it for me; I just tell them what’s for sale. Shopify, I hope you’re listening so that you can keep things secure on my store. This show is made by me, the crimson carder, Jack Rhysider. Sound design was done by the art connoisseur Andrew Meriwether. Editing help this episode by the dancing Damienne. Our theme music is by the sizzling Breakmaster Cylinder. Even though people ask me how to make money on the darknet every time I say it, this is Darknet Diaries.
[OUTRO MUSIC ENDS]
[END OF RECORDING]