>> Hello and welcome back to the course,
Identifying Web Attack Through Logs.
In the last video, we talked
about web application attacks,
OWASP, and URL components.
In this video, we'll discuss our first attack
and do some vulnerability scans.
Let's start with the learning objectives.
In this video, the learning objectives
are to review vulnerability scans and
their tools and to identify
vulnerability scans with web server log analysis.
First, let's remember what a vulnerability is.
As we said before, a vulnerability
is a weakness that can be
exploited and there is
a specific topic on vulnerabilities
>> in the OWASP Top 10.
>> Do remember, each topic is Topic A9,
using components with known vulnerabilities.
This is more related to the components
needed for the web application to work.
For example, if you're using an old version of PHP,
your web application can be
vulnerable even if all the components are updated.
If you have any vulnerabilities in
your web application, it's better to know.
Suppose you're SOC analyst working in a big company.
How do you know that your web application
>> is vulnerable?
>> You can investigate the web application code
and look for vulnerabilities,
but this would take a lot of time.
Another way is using vulnerability scanners.
Vulnerability scanners are software that
try to find weaknesses in your web application.
If you launch some known attacks and
check your applications responses,
depending on the web application response,
it'll say whether or not you have a vulnerability.
Vulnerability scanners are available to everyone.
You can use it to protect
your web application but an attacker
can also use them to find
vulnerabilities which they can exploit later.
Vulnerability scanners are also good
to test your security tools like IDS,
IPS, and the web application's firewall.
There are many vulnerability scanners available,
some open source and some paid.
In some companies,
vulnerability scans are not considered as an attack.
Sometimes it's called a pre-attack.
In this course, the vulnerability scans
will be just one type of an attack.
The vulnerability scanners can be used
to perform vulnerability scans.
Do you know any software that's
considered a vulnerability scanner?
Here are some examples of vulnerability scanners.
There are many others available.
Some scanners like sqlmap are
specific for one type of vulnerability.
Sqlmap is really useful in testing
your web application against SQL injection attacks.
Some other examples are Nikto,
Zed, Burp, and AppScan.
You can find a good list on this website.
Can you think of one way of identifying them?
The easiest way to identify
the vulnerability scanner is
checking the user agent. Like in this example.
The user agent is the sqlmap.
If you see a user agent related
to a vulnerability scanner in a log,
there is a good chance of
vulnerability scan is happening against the web server.
But what's the problem here?
Well, normally it's not that easy.
Remember that user agents are used to detect,
but they can be faked and
the vulnerability scanners usually have
the option to change the user agent. So be careful.
It's also possible for you to see
different user agents like programming languages,
for example, Python requests.
Let's use Nikto to perform a scan on our lab.
The first two lines are examples of Nikto requests.
We didn't change the user agent so
you can identify Nikto as the user agent.
We had close to 8,000 requests in less than one minute.
We have a big number of
requests in a small period of time.
This is common behavior
for different vulnerability scanners.
But if you want, you can run the scan as lower.
If we're doing a vulnerability scan,
you should look for all known vulnerabilities.
>> As we saw,
>> this is going to generate a lot of requests and many of
these requests will return errors, especially 404.
Do you agree with that statement?
Let's try to confirm the theory.
We'll crunch the numbers of the requests with
Nikto user agents and after,
we'll cut the same lines looking for 404.
The first is the number of lines that have
Nikto as a user agent and the second is
the number of lines that have Nikto as
the user agent and also had the 404 for error.
You can see that the number isn't really different.
That happens because we do a lot of
requests and most of these requests don't work.
This is a typical case in vulnerability scans.
Some important things to look for; the user agent,
the number of requests,
and the number of errors.
Now, let's analyze this log.
In the first line, you can see the user agent,
Nikto, a weird request,
and also a 404 error.
The other lines are similar, but
some of them don't have Nikto as
user agent and if you look at
all the requests, they're the same.
This is an example of a request
>> which crafted user agents.
>> In both cases, the user agent was Nikto.
Since the vulnerability scan has unknown behavior,
here are some directions that can help you
to identify a vulnerability scan.
Start looking for the user agents.
Look for scanners or unknown user agents.
Check the number of requests,
either many requests in a small period of time.
Are these requests coming from
the same client IP address?
Look for the number of errors and unexpected requests,
like PHP requests in a page that doesn't have PHP.
The more you know about your application,
the easier it's going to be.
Also, check if the requests are
two configuration pages or two administration pages.
Command or operational system words
and requests are suspicious as well.
Words like ping, cat,
and shell are examples of
these words used in vulnerability scans.
Post assessment question.
Consider this scenario.
The NOC team asked you to check
the behavior of one web server because they
found an increased number of
the weird requests and 404 errors.
The NOC team sent a print of
the webserver CPU and says that it looks normal.
You check the web server logs for
more information about the web server.
They say that it's an Apache and
this is not a WordPress [inaudible].
Here's a portion of the web server logs.
In the next slide, we'll have
some questions about this case.
I suggest that you pause
the video and make the log analysis.
Remember to get the key information on
the logs like IP requests,
and remember to answer the who,
when, and what.
I hope that you enjoy doing this log analysis.
Let's analyze together now.
We have the same client IP address
>> that is doing a lot of requests,
>> 10.1.0.10.
>> You also have more than one request at
the same time and many 404 errors.
For the first line, can you explain the 404?
The reason is, this request looks like
a WordPress request and
this application is not a WordPress application.
Now, based on this scenario,
as a SOC analyst, answer these questions.
Which IP address is causing the trouble?
The answer is letter C.
All the log lines contain this IP address.
Two, what behavior did you identify in the log?
Did you find an attack?
The answer is letter C, vulnerability scan.
In the last slide, we saw
some behaviors that confirm the vulnerability scan,
such as the many 404 errors,
the weird requests, the
many requests in a small period of time,
unexpected requests and others.
Your NOC team is waiting for your analysis.
Let's compose a possible answer to the NOC.
Here is a possible answer.
Then answer to the questions of who, when, and what.
In the real world, there are
other activities that need to perform,
like checking if the web server is
vulnerable or if any vulnerability was exploited.
A suggested action would be blocking
this IP address because it performed an attack.
>> Video summary.
>> In today's video, we discussed
vulnerability scan attacks.
We showed some vulnerability scanner examples
and how to identify this behavior.
First, check the user agents.
Look for many requests in a small period of time.
Look for many errors, especially 404.
Look for weird words and unexpected requests.
This includes our first attack example
>> in log analysis.
>> For the next video, we'll review brute force attacks
>> and identify brute force attacks
>> during web server log analysis.