WEBVTT

00:00:00.000 --> 00:00:01.341
Now, given I'm from Europe,

00:00:01.341 --> 00:00:04.326
I've had a lot more experience personally with e-commerce attacks,

00:00:04.326 --> 00:00:09.380
both as a merchant of having websites attacked and as a card

00:00:09.380 --> 00:00:12.667
brand of seeing the forensic reports that people,

00:00:12.667 --> 00:00:13.560
like Aaron, would write,

00:00:13.560 --> 00:00:16.285
and they'd come to me as a card brand to look at how

00:00:16.285 --> 00:00:18.064
the attack worked in e-commerce.

00:00:18.065 --> 00:00:21.975
So, do you work e-commerce attacks, as well as point-of-sale attacks?

00:00:21.976 --> 00:00:22.265
Yeah.

00:00:22.265 --> 00:00:25.542
We've actually seen a shift more to e-commerce now.

00:00:25.542 --> 00:00:26.513
We're doing,

00:00:26.513 --> 00:00:31.191
probably 60% of our investigations are now e-commerce investigations.

00:00:31.191 --> 00:00:32.655
That's really interesting because, of course,

00:00:32.655 --> 00:00:34.205
when we moved to Chip and PIN in Europe,

00:00:34.205 --> 00:00:38.255
exactly the same thing happened because the criminals don't give up.

00:00:38.255 --> 00:00:39.586
They don't think, oh, I know.

00:00:39.586 --> 00:00:41.488
I'm bored of being a criminal.

00:00:41.489 --> 00:00:43.259
I'll go and do something else.

00:00:43.259 --> 00:00:45.141
They think, okay, the card data's not there.

00:00:45.142 --> 00:00:46.118
The card data's there.

00:00:46.118 --> 00:00:47.135
I'm going to go there.

00:00:47.135 --> 00:00:49.387
So 60% of your work's e-comm attacks now.

00:00:49.388 --> 00:00:51.663
Yeah, they're just, they're going after the low-hanging fruit.

00:00:51.663 --> 00:00:55.914
They're going to go where the easiest card data can be harvested.

00:00:55.915 --> 00:00:58.775
Now, there are two sorts of ways of attacking e-comm.

00:00:58.775 --> 00:01:01.459
You attack the server and steal the data from the server,

00:01:01.459 --> 00:01:02.187
or the infrastructure,

00:01:02.187 --> 00:01:06.657
or you put stuff on the server that then harvests the card

00:01:06.658 --> 00:01:09.389
numbers from the consumer's browsers.

00:01:09.389 --> 00:01:11.822
I've got the client-side attacks versus server-side attacks,

00:01:11.822 --> 00:01:14.182
and actually as we're recording now,

00:01:14.182 --> 00:01:16.849
those client-side attacks are becoming big news.

00:01:16.850 --> 00:01:19.235
A big airline in Europe got hit with one.

00:01:19.235 --> 00:01:23.609
A big electronics retailer in the US got hit with one last week.

00:01:23.610 --> 00:01:25.122
So they're more in the news than they have been.

00:01:25.122 --> 00:01:26.983
I've been seeing those attacks for four years,

00:01:26.983 --> 00:01:30.825
and we did a really good Pluralsight course a few months

00:01:30.825 --> 00:01:34.777
ago where Troy Hunt and I spoke about how to detect and

00:01:34.777 --> 00:01:36.499
defend against these attacks.

00:01:36.500 --> 00:01:39.266
But from the forensics side, what do you seeing the criminals doing?

00:01:39.266 --> 00:01:41.898
Are they doing the client-side JavaScript or are

00:01:41.898 --> 00:01:43.605
they still hitting e-comm servers?

00:01:43.606 --> 00:01:47.717
We've seen a lot of improved security measures in

00:01:47.717 --> 00:01:52.483
the last few years on e-commerce, especially protecting the server side,

00:01:52.483 --> 00:01:56.098
and we have file integrity monitoring products that are checking

00:01:56.098 --> 00:02:01.615
for any code that changes on the server itself,

00:02:01.616 --> 00:02:05.007
better secure programming practices.

00:02:05.007 --> 00:02:07.961
But what we're seeing is this uptake in the JavaScript attacks and

00:02:07.961 --> 00:02:12.668
inside the client browser that you mentioned.

00:02:12.669 --> 00:02:16.289
These attacks are very difficult to detect,

00:02:16.289 --> 00:02:18.382
even with something like FIM running,

00:02:18.382 --> 00:02:20.901
because that JavaScript can come from anywhere,

00:02:20.901 --> 00:02:23.015
not just the merchant's web server.

00:02:23.016 --> 00:02:27.399
It can come from anywhere in the supply chain that includes code on

00:02:27.399 --> 00:02:30.985
that checkout page in any of the shopping carts.

00:02:30.986 --> 00:02:33.805
Yeah, and if you look at people, if you look at --- I don't know about you,

00:02:33.806 --> 00:02:36.658
but as a very weird person,

00:02:36.658 --> 00:02:40.971
I actually do pull ATMs to check there's no skimmer on it,

00:02:40.971 --> 00:02:45.135
and every time I go to a web page with my payment card details,

00:02:45.136 --> 00:02:46.675
I fire up DevTools in Chrome,

00:02:46.676 --> 00:02:49.502
and I look at how many third-party JavaScript's on there.

00:02:49.502 --> 00:02:54.070
And it's scares me intensely that you get to a website with like 15

00:02:54.070 --> 00:02:57.615
different remote pieces of JavaScript on a payment page.

00:02:57.616 --> 00:02:58.462
Yeah, absolutely.

00:02:58.462 --> 00:03:02.965
We see those more and more, and they're so easy to hide because,

00:03:02.966 --> 00:03:04.006
like you said,

00:03:04.006 --> 00:03:07.895
there are more and more JavaScript's being included on those

00:03:07.896 --> 00:03:11.150
checkout pages and all it takes is one tiny,

00:03:11.150 --> 00:03:12.079
little link.

00:03:12.079 --> 00:03:17.338
We've found them buried inside hundreds of lines of other code,

00:03:17.338 --> 00:03:19.985
but one little link is all it takes,

00:03:19.986 --> 00:03:25.036
and they can harvest credit cards right out of the customer's checkout page.

00:03:25.036 --> 00:03:27.813
So the merchant's been told they've got a common point of,

00:03:27.813 --> 00:03:30.012
they are a point of compromise.

00:03:30.012 --> 00:03:32.530
How hard is it for you to find those attacks as a forensic?

00:03:32.530 --> 00:03:34.966
Because that's not about imaging anything because that

00:03:34.966 --> 00:03:38.485
JavaScript might be coming from an advertising network or a

00:03:38.485 --> 00:03:41.146
chat provider or something like that.

00:03:41.146 --> 00:03:45.716
Finding them is actually a fairly simple process for a forensic guy.

00:03:45.716 --> 00:03:48.685
It's as simple as right-clicking on the checkout page

00:03:48.685 --> 00:03:51.327
and looking at those JavaScripts, that you mentioned,

00:03:51.327 --> 00:03:53.725
with any of the browser tools or yeah,

00:03:53.726 --> 00:03:57.825
we have some more sophisticated proxy tools that we can run it through

00:03:57.825 --> 00:04:02.543
and check against different databases that we have that identify the

00:04:02.543 --> 00:04:05.539
more common attacks we see on the client side.

00:04:05.539 --> 00:04:07.254
So are you using threat intelligence services,

00:04:07.254 --> 00:04:11.264
like RiskIQ and people like that, to help look for those type of things?

00:04:11.265 --> 00:04:14.710
We have our own, but yes.

00:04:14.711 --> 00:04:16.717
So let's talk the server-side attacks.

00:04:16.718 --> 00:04:17.244
Declining?

00:04:17.244 --> 00:04:18.825
What's the percentage?

00:04:18.825 --> 00:04:21.025
What was the percentage client side/ server side now?

00:04:21.024 --> 00:04:26.569
I'd say probably almost 80% of my most recent cases

00:04:26.569 --> 00:04:29.175
have all been client-side attacks.

00:04:29.175 --> 00:04:29.711
Wow.

00:04:29.711 --> 00:04:33.740
It used to be the other way around where we didn't see very many.

00:04:33.741 --> 00:04:40.242
We'd see the controller files for the major shopping carts.

00:04:40.242 --> 00:04:47.148
We would see the attackers hitting those and modifying those.

00:04:47.148 --> 00:04:50.480
But if the merchant is using file integrity monitoring,

00:04:50.480 --> 00:04:53.176
it's going to catch those.

00:04:53.176 --> 00:04:57.319
And so, FIM, or file integrity monitoring,

00:04:57.320 --> 00:05:03.486
has been hugely successful in reducing the number of server-side attacks.

00:05:03.486 --> 00:05:04.479
Right.

00:05:04.479 --> 00:05:06.465
That's scary.

00:05:06.465 --> 00:05:10.999
That is really scary actually because I've been --- I think the last time I

00:05:10.999 --> 00:05:12.787
looked and spent some time with forensic investigators,

00:05:12.787 --> 00:05:17.281
they were saying, 30% client side, 70% server side.

00:05:17.282 --> 00:05:22.301
And I think --- the problem I see is that the server-side

00:05:22.301 --> 00:05:24.997
attack is noisy and requires persistence.

00:05:24.997 --> 00:05:25.966
You have to go in there.

00:05:25.967 --> 00:05:27.574
You have to modify code.

00:05:27.575 --> 00:05:29.613
You leave lots of artifacts lying around.

00:05:29.613 --> 00:05:31.128
Tell me if I'm getting this right.

00:05:31.128 --> 00:05:31.349
Yeah.

00:05:31.349 --> 00:05:31.571
Right.

00:05:31.571 --> 00:05:32.614
You leave artifacts lying around.

00:05:32.614 --> 00:05:33.900
You are noisy.

00:05:33.900 --> 00:05:35.186
Something detects you.

00:05:35.186 --> 00:05:35.816
But the client-side attack,

00:05:35.816 --> 00:05:39.283
it could be a third party or it wants into the server.

00:05:39.283 --> 00:05:40.312
You're there for 10 seconds.

00:05:40.312 --> 00:05:44.524
You put one include file so we're in a database in a content management system.

00:05:44.525 --> 00:05:45.762
That's tough to detect.

00:05:45.762 --> 00:05:49.789
How do you find things like content management systems?

00:05:49.789 --> 00:05:50.249
Well, again,

00:05:50.249 --> 00:05:54.538
the way I do it is I go to their checkout pages so I can see

00:05:54.538 --> 00:05:58.852
exactly the code as it appears in the checkout page to see if it's

00:05:58.852 --> 00:06:00.987
modified from what's sitting on the server.

00:06:00.987 --> 00:06:04.576
Sometimes it can get pretty intense where you have to go

00:06:04.576 --> 00:06:08.858
look through every single include file, and like you said,

00:06:08.858 --> 00:06:11.298
sometimes there's 30, 40, 50 includes,

00:06:11.298 --> 00:06:14.832
and you've got to search through and find the 1

00:06:14.832 --> 00:06:16.626
include that's been tampered with.

00:06:16.627 --> 00:06:18.901
And that include can be sitting in a database somewhere,

00:06:18.901 --> 00:06:21.656
and you can't run file integrity monitoring on a database.

00:06:21.657 --> 00:06:22.841
It's supposed to change.

00:06:22.842 --> 00:06:22.983
Yeah,

00:06:22.983 --> 00:06:24.767
that's the whole thing with FIM is that as soon as people

00:06:24.767 --> 00:06:29.091
move to content management systems, FIM stops being as valuable.

00:06:29.091 --> 00:06:31.488
But I also notice that a lot of that's encoded and

00:06:31.488 --> 00:06:33.308
obfuscate JavaScript that you're looking for.

00:06:33.308 --> 00:06:36.855
So, have you become a JavaScript expert in the last two years?

00:06:36.855 --> 00:06:41.981
Well, I come from a programming background, so JavaScript's nothing new to me.

00:06:41.981 --> 00:06:46.575
But we have seen the JavaScript obfuscation techniques emerging

00:06:46.575 --> 00:06:49.365
where they're encrypting their JavaScript,

00:06:49.365 --> 00:06:53.419
making it really difficult to read, but sometimes that a clue in and of itself.

00:06:53.419 --> 00:06:57.187
When you look, as a forensic analyst, you're looking at this module,

00:06:57.188 --> 00:06:59.048
and you're like, that's an awfully big module.

00:06:59.049 --> 00:07:01.142
Why is it encrypted like that?

00:07:01.143 --> 00:07:04.126
And most of time, we're pretty successful at decrypting those,

00:07:04.126 --> 00:07:09.640
and they turn out to be credit card malware.