WEBVTT

00:00.000 --> 00:02.910
>> Hello and welcome
back to the course,

00:02.910 --> 00:05.370
Identifying Web
Attack Through Logs.

00:05.370 --> 00:06.990
In the last video, we talked

00:06.990 --> 00:08.775
about web application attacks,

00:08.775 --> 00:11.520
OWASP, and URL components.

00:11.520 --> 00:13.770
In this video, we'll
discuss our first attack

00:13.770 --> 00:15.915
and do some vulnerability scans.

00:15.915 --> 00:18.165
Let's start with the
learning objectives.

00:18.165 --> 00:20.205
In this video, the
learning objectives

00:20.205 --> 00:22.230
are to review
vulnerability scans and

00:22.230 --> 00:24.180
their tools and to identify

00:24.180 --> 00:28.410
vulnerability scans with
web server log analysis.

00:28.410 --> 00:31.500
First, let's remember
what a vulnerability is.

00:31.500 --> 00:33.860
As we said before,
a vulnerability

00:33.860 --> 00:34.910
is a weakness that can be

00:34.910 --> 00:36.680
exploited and there is

00:36.680 --> 00:38.720
a specific topic
on vulnerabilities

00:38.720 --> 00:40.714
>> in the OWASP Top 10.

00:40.714 --> 00:43.760
>> Do remember, each
topic is Topic A9,

00:43.760 --> 00:46.385
using components with
known vulnerabilities.

00:46.385 --> 00:48.380
This is more related
to the components

00:48.380 --> 00:50.525
needed for the web
application to work.

00:50.525 --> 00:53.960
For example, if you're using
an old version of PHP,

00:53.960 --> 00:55.970
your web application can be

00:55.970 --> 00:58.660
vulnerable even if all the
components are updated.

00:58.660 --> 01:00.650
If you have any
vulnerabilities in

01:00.650 --> 01:03.590
your web application,
it's better to know.

01:03.590 --> 01:07.475
Suppose you're SOC analyst
working in a big company.

01:07.475 --> 01:09.530
How do you know that
your web application

01:09.530 --> 01:10.759
>> is vulnerable?

01:10.759 --> 01:13.415
>> You can investigate
the web application code

01:13.415 --> 01:14.750
and look for vulnerabilities,

01:14.750 --> 01:17.005
but this would take
a lot of time.

01:17.005 --> 01:20.735
Another way is using
vulnerability scanners.

01:20.735 --> 01:23.920
Vulnerability scanners
are software that

01:23.920 --> 01:26.635
try to find weaknesses
in your web application.

01:26.635 --> 01:28.720
If you launch some
known attacks and

01:28.720 --> 01:30.670
check your applications
responses,

01:30.670 --> 01:32.740
depending on the web
application response,

01:32.740 --> 01:35.620
it'll say whether or not
you have a vulnerability.

01:35.620 --> 01:38.725
Vulnerability scanners are
available to everyone.

01:38.725 --> 01:40.510
You can use it to protect

01:40.510 --> 01:42.760
your web application
but an attacker

01:42.760 --> 01:44.740
can also use them to find

01:44.740 --> 01:47.215
vulnerabilities which
they can exploit later.

01:47.215 --> 01:49.750
Vulnerability scanners
are also good

01:49.750 --> 01:51.970
to test your security
tools like IDS,

01:51.970 --> 01:55.105
IPS, and the web
application's firewall.

01:55.105 --> 01:57.900
There are many vulnerability
scanners available,

01:57.900 --> 02:00.380
some open source and some paid.

02:00.380 --> 02:01.925
In some companies,

02:01.925 --> 02:04.940
vulnerability scans are not
considered as an attack.

02:04.940 --> 02:07.505
Sometimes it's
called a pre-attack.

02:07.505 --> 02:10.460
In this course, the
vulnerability scans

02:10.460 --> 02:13.160
will be just one
type of an attack.

02:13.160 --> 02:15.800
The vulnerability
scanners can be used

02:15.800 --> 02:18.430
to perform vulnerability scans.

02:18.430 --> 02:20.270
Do you know any software that's

02:20.270 --> 02:22.400
considered a
vulnerability scanner?

02:22.400 --> 02:25.490
Here are some examples of
vulnerability scanners.

02:25.490 --> 02:26.810
There are many others available.

02:26.810 --> 02:29.120
Some scanners like sqlmap are

02:29.120 --> 02:32.020
specific for one type
of vulnerability.

02:32.020 --> 02:34.520
Sqlmap is really
useful in testing

02:34.520 --> 02:37.955
your web application against
SQL injection attacks.

02:37.955 --> 02:40.940
Some other examples are Nikto,

02:40.940 --> 02:43.700
Zed, Burp, and AppScan.

02:43.700 --> 02:46.760
You can find a good
list on this website.

02:46.760 --> 02:50.180
Can you think of one way
of identifying them?

02:50.180 --> 02:52.190
The easiest way to identify

02:52.190 --> 02:53.900
the vulnerability scanner is

02:53.900 --> 02:56.750
checking the user agent.
Like in this example.

02:56.750 --> 02:59.555
The user agent is the sqlmap.

02:59.555 --> 03:01.730
If you see a user agent related

03:01.730 --> 03:03.470
to a vulnerability
scanner in a log,

03:03.470 --> 03:05.090
there is a good chance of

03:05.090 --> 03:07.610
vulnerability scan is happening
against the web server.

03:07.610 --> 03:09.770
But what's the problem here?

03:09.770 --> 03:12.545
Well, normally it's
not that easy.

03:12.545 --> 03:15.470
Remember that user agents
are used to detect,

03:15.470 --> 03:17.270
but they can be faked and

03:17.270 --> 03:19.550
the vulnerability
scanners usually have

03:19.550 --> 03:23.130
the option to change the
user agent. So be careful.

03:23.140 --> 03:25.700
It's also possible
for you to see

03:25.700 --> 03:27.920
different user agents like
programming languages,

03:27.920 --> 03:30.985
for example, Python requests.

03:30.985 --> 03:34.775
Let's use Nikto to perform
a scan on our lab.

03:34.775 --> 03:38.300
The first two lines are
examples of Nikto requests.

03:38.300 --> 03:40.510
We didn't change
the user agent so

03:40.510 --> 03:43.075
you can identify Nikto
as the user agent.

03:43.075 --> 03:46.845
We had close to 8,000 requests
in less than one minute.

03:46.845 --> 03:48.140
We have a big number of

03:48.140 --> 03:50.465
requests in a small
period of time.

03:50.465 --> 03:52.100
This is common behavior

03:52.100 --> 03:54.215
for different
vulnerability scanners.

03:54.215 --> 03:57.935
But if you want, you can
run the scan as lower.

03:57.935 --> 04:00.410
If we're doing a
vulnerability scan,

04:00.410 --> 04:02.870
you should look for all
known vulnerabilities.

04:02.870 --> 04:04.234
>> As we saw,

04:04.234 --> 04:06.980
>> this is going to generate
a lot of requests and many of

04:06.980 --> 04:10.690
these requests will return
errors, especially 404.

04:10.690 --> 04:13.360
Do you agree with
that statement?

04:14.120 --> 04:17.015
Let's try to confirm the theory.

04:17.015 --> 04:19.325
We'll crunch the numbers
of the requests with

04:19.325 --> 04:21.620
Nikto user agents and after,

04:21.620 --> 04:24.275
we'll cut the same
lines looking for 404.

04:24.275 --> 04:26.420
The first is the number
of lines that have

04:26.420 --> 04:28.850
Nikto as a user agent
and the second is

04:28.850 --> 04:30.350
the number of lines
that have Nikto as

04:30.350 --> 04:34.560
the user agent and also
had the 404 for error.

04:34.870 --> 04:38.365
You can see that the number
isn't really different.

04:38.365 --> 04:40.670
That happens because
we do a lot of

04:40.670 --> 04:43.255
requests and most of these
requests don't work.

04:43.255 --> 04:46.280
This is a typical case
in vulnerability scans.

04:46.280 --> 04:49.210
Some important things to
look for; the user agent,

04:49.210 --> 04:50.740
the number of requests,

04:50.740 --> 04:53.360
and the number of errors.

04:53.560 --> 04:56.900
Now, let's analyze this log.

04:56.900 --> 04:59.510
In the first line, you
can see the user agent,

04:59.510 --> 05:01.340
Nikto, a weird request,

05:01.340 --> 05:03.410
and also a 404 error.

05:03.410 --> 05:05.165
The other lines are similar, but

05:05.165 --> 05:06.800
some of them don't have Nikto as

05:06.800 --> 05:08.630
user agent and if you look at

05:08.630 --> 05:11.020
all the requests,
they're the same.

05:11.020 --> 05:13.160
This is an example of a request

05:13.160 --> 05:15.149
>> which crafted user agents.

05:15.149 --> 05:18.620
>> In both cases, the
user agent was Nikto.

05:18.620 --> 05:22.535
Since the vulnerability
scan has unknown behavior,

05:22.535 --> 05:24.440
here are some directions
that can help you

05:24.440 --> 05:26.660
to identify a
vulnerability scan.

05:26.660 --> 05:29.090
Start looking for
the user agents.

05:29.090 --> 05:32.315
Look for scanners or
unknown user agents.

05:32.315 --> 05:34.460
Check the number of requests,

05:34.460 --> 05:37.340
either many requests in
a small period of time.

05:37.340 --> 05:38.720
Are these requests coming from

05:38.720 --> 05:41.275
the same client IP address?

05:41.275 --> 05:44.405
Look for the number of errors
and unexpected requests,

05:44.405 --> 05:48.860
like PHP requests in a page
that doesn't have PHP.

05:48.860 --> 05:50.855
The more you know about
your application,

05:50.855 --> 05:52.645
the easier it's going to be.

05:52.645 --> 05:54.980
Also, check if the requests are

05:54.980 --> 05:58.430
two configuration pages or
two administration pages.

05:58.430 --> 06:00.710
Command or operational
system words

06:00.710 --> 06:02.615
and requests are
suspicious as well.

06:02.615 --> 06:04.160
Words like ping, cat,

06:04.160 --> 06:05.390
and shell are examples of

06:05.390 --> 06:08.700
these words used in
vulnerability scans.

06:09.730 --> 06:12.350
Post assessment question.

06:12.350 --> 06:14.095
Consider this scenario.

06:14.095 --> 06:15.920
The NOC team asked you to check

06:15.920 --> 06:18.110
the behavior of one web
server because they

06:18.110 --> 06:19.850
found an increased number of

06:19.850 --> 06:22.190
the weird requests
and 404 errors.

06:22.190 --> 06:24.020
The NOC team sent a print of

06:24.020 --> 06:26.660
the webserver CPU and says
that it looks normal.

06:26.660 --> 06:28.520
You check the web
server logs for

06:28.520 --> 06:30.245
more information
about the web server.

06:30.245 --> 06:32.630
They say that it's an Apache and

06:32.630 --> 06:35.030
this is not a
WordPress [inaudible].

06:35.030 --> 06:37.070
Here's a portion of
the web server logs.

06:37.070 --> 06:38.150
In the next slide, we'll have

06:38.150 --> 06:39.875
some questions about this case.

06:39.875 --> 06:41.840
I suggest that you pause

06:41.840 --> 06:43.910
the video and make
the log analysis.

06:43.910 --> 06:45.590
Remember to get the
key information on

06:45.590 --> 06:47.389
the logs like IP requests,

06:47.389 --> 06:49.030
and remember to answer the who,

06:49.030 --> 06:50.890
when, and what.

06:50.890 --> 06:54.570
I hope that you enjoy
doing this log analysis.

06:55.660 --> 06:58.505
Let's analyze together now.

06:58.505 --> 07:00.860
We have the same
client IP address

07:00.860 --> 07:02.450
>> that is doing a
lot of requests,

07:02.450 --> 07:05.344
>> 10.1.0.10.

07:05.344 --> 07:07.400
>> You also have more
than one request at

07:07.400 --> 07:10.115
the same time and
many 404 errors.

07:10.115 --> 07:13.495
For the first line, can
you explain the 404?

07:13.495 --> 07:16.310
The reason is, this
request looks like

07:16.310 --> 07:18.290
a WordPress request and

07:18.290 --> 07:21.995
this application is not
a WordPress application.

07:21.995 --> 07:23.720
Now, based on this scenario,

07:23.720 --> 07:27.415
as a SOC analyst,
answer these questions.

07:27.415 --> 07:30.760
Which IP address is
causing the trouble?

07:31.760 --> 07:34.830
The answer is letter C.

07:34.830 --> 07:38.365
All the log lines
contain this IP address.

07:38.365 --> 07:42.905
Two, what behavior did
you identify in the log?

07:42.905 --> 07:44.920
Did you find an attack?

07:44.920 --> 07:49.440
The answer is letter
C, vulnerability scan.

07:50.510 --> 07:52.550
In the last slide, we saw

07:52.550 --> 07:54.875
some behaviors that confirm
the vulnerability scan,

07:54.875 --> 07:57.020
such as the many 404 errors,

07:57.020 --> 07:58.400
the weird requests, the

07:58.400 --> 08:00.710
many requests in a
small period of time,

08:00.710 --> 08:02.860
unexpected requests and others.

08:02.860 --> 08:05.290
Your NOC team is waiting
for your analysis.

08:05.290 --> 08:08.380
Let's compose a possible
answer to the NOC.

08:08.380 --> 08:11.055
Here is a possible answer.

08:11.055 --> 08:14.840
Then answer to the questions
of who, when, and what.

08:14.840 --> 08:16.535
In the real world, there are

08:16.535 --> 08:18.245
other activities that
need to perform,

08:18.245 --> 08:20.090
like checking if
the web server is

08:20.090 --> 08:23.465
vulnerable or if any
vulnerability was exploited.

08:23.465 --> 08:25.610
A suggested action
would be blocking

08:25.610 --> 08:28.010
this IP address because
it performed an attack.

08:28.010 --> 08:32.364
>> Video summary.

08:32.364 --> 08:34.160
>> In today's
video, we discussed

08:34.160 --> 08:35.719
vulnerability scan attacks.

08:35.719 --> 08:38.300
We showed some vulnerability
scanner examples

08:38.300 --> 08:40.085
and how to identify
this behavior.

08:40.085 --> 08:42.050
First, check the user agents.

08:42.050 --> 08:44.510
Look for many requests in
a small period of time.

08:44.510 --> 08:47.450
Look for many errors,
especially 404.

08:47.450 --> 08:51.215
Look for weird words and
unexpected requests.

08:51.215 --> 08:54.020
This includes our
first attack example

08:54.020 --> 08:55.804
>> in log analysis.

08:55.804 --> 08:59.630
>> For the next video, we'll
review brute force attacks

08:59.630 --> 09:01.834
>> and identify
brute force attacks

09:01.834 --> 09:05.010
>> during web server
log analysis.