2 hours 5 minutes
hello and welcome back to the course, identifying with attacks through logs.
In the last video, we talked about Web application attacks. Ah, wasp and you are all components
In this video, we'll discuss our first attack and do some vulnerability scans.
Let's start with a 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, Ah, vulnerability is a weakness that could be exploited,
and there is a specific topic on vulnerabilities in the A WASP Top 10.
Do you remember? Each topic is Topic a nine
using components with no vulnerabilities.
This is more related to the components needed for the Web application toe work.
if you're using an old version of PHP, your your Web application can be vulnerable even if all the components are updated.
So if you have any vulnerabilities in your Web application,
it's better to know.
Suppose your sock 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, air 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 will say whether or not you have a vulnerability.
Vulnerability. Scanners are available. Toe everyone
so you can use it to protect your Web application. But attacker can also use them to find vulnerabilities, which they can exploit later.
Vulnerability scanners are also good to test your security tools like I. D. S, I. P s and the Web applications 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.
So 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 SQL map, are specific For one type of vulnerability.
SQL map is really useful in testing your Web application against SQL injection attacks.
Some other examples are nick toe, zed Burp and APP scan.
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 SQL Man.
If you see a user agent related to a vulnerability scanner in a log,
there's a good chance of vulnerability. Skin 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 in 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,
Let's use Nick Toe to perform a scan on our lab.
The first two lines are examples of Nick. No requests.
We didn't change the user agent so you could identify nicked OAS. The user agent.
We had close to 8000 requests in less than one minute, so 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 four Oh four.
Do you agree with that statement?
so let's try to confirm the theory
will crunch the numbers of the requests with Nick Toe user agents and after we'll count the same lines looking for 404.
The first is the number of lines that have nicked OAS the user agent, and the second is the number of lines that have nicked as the user agent and also had the 404 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.
let's analyze this log
in the first line, you can see the user agent Nick toe a weird request and also a four oh four error.
The other lines are similar, but some of them don't have Nick toe as user agent. And if you look at all the requests
at the same,
this is an example of requests which crafted user agents.
In both cases, the user agent was nick Toe.
Since the Vulnerability scan has unknown behavior,
here are some directions that can help you toe identify a vulnerability scanner.
Start looking for the user agents.
Look for scanners or unknown user agents.
Check the number of the requests. Are there many requests in a small period of time? Are these requests coming from the same client I P 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 is well, words like Ping Cat and Shell are examples of these words. Used invulnerability stands
post assessment question.
Consider this scenario,
the knock 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 knock team sent a print of the Web server 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 deploy.
Here's a portion of the Web server locks.
The next slide will 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 type 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 I P address that is doing a lot of requests. 10.1 point oh 10.
You also have more than one request at the same time, and many four or four 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 sock analyst, answer this questions
which I p addresses causing the trouble.
The answer is, let her seat
all the long lines contain this I p address
what behavior did you identify in the law?
Did you find an attack?
The answer is, let her seat
In the last slide, we saw some behaviors that confirmed the vulnerabilities can, such as theme, metaphor of four errors, the weird requests, the many requests in a small period of time, unexpected requests and others.
Your knock team is waiting for your analysis.
Let's compose a possible answer to the knock.
Here is a possible answer,
and in 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 I p address because it performed an attack
In today's video, we discussed vulnerability skin 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 4 to 4.
Look for weird words and unexpected requests.
This includes our first attack example and log analysis.
For the next video,
we'll review brute force attacks and identify brute force attacks during Web server log analysis.