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.