Now, given I'm from Europe,
I've had a lot more experience personally with e-commerce attacks,
both as a merchant of having websites attacked and as a card
brand of seeing the forensic reports that people,
like Aaron, would write,
and they'd come to me as a card brand to look at how
the attack worked in e-commerce.
So, do you work e-commerce attacks, as well as point-of-sale attacks?
Yeah.
We've actually seen a shift more to e-commerce now.
We're doing,
probably 60% of our investigations are now e-commerce investigations.
That's really interesting because, of course,
when we moved to Chip and PIN in Europe,
exactly the same thing happened because the criminals don't give up.
They don't think, oh, I know.
I'm bored of being a criminal.
I'll go and do something else.
They think, okay, the card data's not there.
The card data's there.
I'm going to go there.
So 60% of your work's e-comm attacks now.
Yeah, they're just, they're going after the low-hanging fruit.
They're going to go where the easiest card data can be harvested.
Now, there are two sorts of ways of attacking e-comm.
You attack the server and steal the data from the server,
or the infrastructure,
or you put stuff on the server that then harvests the card
numbers from the consumer's browsers.
I've got the client-side attacks versus server-side attacks,
and actually as we're recording now,
those client-side attacks are becoming big news.
A big airline in Europe got hit with one.
A big electronics retailer in the US got hit with one last week.
So they're more in the news than they have been.
I've been seeing those attacks for four years,
and we did a really good Pluralsight course a few months
ago where Troy Hunt and I spoke about how to detect and
defend against these attacks.
But from the forensics side, what do you seeing the criminals doing?
Are they doing the client-side JavaScript or are
they still hitting e-comm servers?
We've seen a lot of improved security measures in
the last few years on e-commerce, especially protecting the server side,
and we have file integrity monitoring products that are checking
for any code that changes on the server itself,
better secure programming practices.
But what we're seeing is this uptake in the JavaScript attacks and
inside the client browser that you mentioned.
These attacks are very difficult to detect,
even with something like FIM running,
because that JavaScript can come from anywhere,
not just the merchant's web server.
It can come from anywhere in the supply chain that includes code on
that checkout page in any of the shopping carts.
Yeah, and if you look at people, if you look at --- I don't know about you,
but as a very weird person,
I actually do pull ATMs to check there's no skimmer on it,
and every time I go to a web page with my payment card details,
I fire up DevTools in Chrome,
and I look at how many third-party JavaScript's on there.
And it's scares me intensely that you get to a website with like 15
different remote pieces of JavaScript on a payment page.
Yeah, absolutely.
We see those more and more, and they're so easy to hide because,
like you said,
there are more and more JavaScript's being included on those
checkout pages and all it takes is one tiny,
little link.
We've found them buried inside hundreds of lines of other code,
but one little link is all it takes,
and they can harvest credit cards right out of the customer's checkout page.
So the merchant's been told they've got a common point of,
they are a point of compromise.
How hard is it for you to find those attacks as a forensic?
Because that's not about imaging anything because that
JavaScript might be coming from an advertising network or a
chat provider or something like that.
Finding them is actually a fairly simple process for a forensic guy.
It's as simple as right-clicking on the checkout page
and looking at those JavaScripts, that you mentioned,
with any of the browser tools or yeah,
we have some more sophisticated proxy tools that we can run it through
and check against different databases that we have that identify the
more common attacks we see on the client side.
So are you using threat intelligence services,
like RiskIQ and people like that, to help look for those type of things?
We have our own, but yes.
So let's talk the server-side attacks.
Declining?
What's the percentage?
What was the percentage client side/ server side now?
I'd say probably almost 80% of my most recent cases
have all been client-side attacks.
Wow.
It used to be the other way around where we didn't see very many.
We'd see the controller files for the major shopping carts.
We would see the attackers hitting those and modifying those.
But if the merchant is using file integrity monitoring,
it's going to catch those.
And so, FIM, or file integrity monitoring,
has been hugely successful in reducing the number of server-side attacks.
Right.
That's scary.
That is really scary actually because I've been --- I think the last time I
looked and spent some time with forensic investigators,
they were saying, 30% client side, 70% server side.
And I think --- the problem I see is that the server-side
attack is noisy and requires persistence.
You have to go in there.
You have to modify code.
You leave lots of artifacts lying around.
Tell me if I'm getting this right.
Yeah.
Right.
You leave artifacts lying around.
You are noisy.
Something detects you.
But the client-side attack,
it could be a third party or it wants into the server.
You're there for 10 seconds.
You put one include file so we're in a database in a content management system.
That's tough to detect.
How do you find things like content management systems?
Well, again,
the way I do it is I go to their checkout pages so I can see
exactly the code as it appears in the checkout page to see if it's
modified from what's sitting on the server.
Sometimes it can get pretty intense where you have to go
look through every single include file, and like you said,
sometimes there's 30, 40, 50 includes,
and you've got to search through and find the 1
include that's been tampered with.
And that include can be sitting in a database somewhere,
and you can't run file integrity monitoring on a database.
It's supposed to change.
Yeah,
that's the whole thing with FIM is that as soon as people
move to content management systems, FIM stops being as valuable.
But I also notice that a lot of that's encoded and
obfuscate JavaScript that you're looking for.
So, have you become a JavaScript expert in the last two years?
Well, I come from a programming background, so JavaScript's nothing new to me.
But we have seen the JavaScript obfuscation techniques emerging
where they're encrypting their JavaScript,
making it really difficult to read, but sometimes that a clue in and of itself.
When you look, as a forensic analyst, you're looking at this module,
and you're like, that's an awfully big module.
Why is it encrypted like that?
And most of time, we're pretty successful at decrypting those,
and they turn out to be credit card malware.