OWASP Top 10 TryHackMe

28 min readJul 15, 2020

Hello guys back again with another walkthrough this time am going to be taking you how I’ve solved the last 3 days challenges of the owasp Top10 room. This room will go through top 10 vulnerabilities that most web application may have and will teach you the basics on how to solve them it’s really a fun challenge and without much say let’s jump in

[Day 1] Injection

The first day we are presented with a room that has command injection vulnerability meaning we can execute system commands from the website. This vulnerability is really dangerous because it can not only lead to exposure of sensitive files from the web server but can also lead to the exposure of the source code of the web server that can lead to the system being further compromised. I had already done a pentest on that specific web page before so am not going to be going deeper into the vulnerability but I’ll leave a link to the root where i explain the vulnerability

On navigating to the site we get a standard webpage

And the website allows us to enter commands sweet. Let’s try “ifconfig” a simple Linux command and as seen below we get an output back meaning there is command injection vulnerability on the web server

This will not always be the case since some command injection might be blind meaning no output is seen on the screen. I gave out few tricks that i normally use to confirm if a specific parameter is vulnerable to OS command injection even if there’s no output on the screen example of which include

Do a sleep command and measure the time response of the web server
Doing a ping command that will make the vulnerable server ping back to your box
Directing the output (stdout) of a command to a file in a directory that you can control like /var/www/html and try seeing if you can access the file

For this specific box i created a python script that automates the exploitation of the box which am going to be showcasing below

Just by inputting the IP Address of the web server we get a shell on the box though it’s not persistent

The next best thing is getting a reverse shell on the box which shouldn’t be that hard. I’ll leave a link of my GitHub page at the end

My GitHub Link

OS command injection article

[Day 2] Broken Authentication

Broken authentication is a type of misconfiguration or vulnerability that allows an attacker to bypass authentication mechanism that the server uses this allows an attacker to have access to pages or places where they shouldn’t be able to have access to

For example a server is vulnerable to SQL Injection meaning an attacker can dump contents of the database that might include password hashes crack them and get access to the system using those credentials
Second scenario is that a user password is weak that by doing a bruteforce attack the password can be easily guessed and this leads to compromising a system
Third scenario is that the web server assigns session id’s that are weak meaning that an attacker by doing a little fuzzing they can be able to reverse the session id and cause him/her to create countless more valid session id’s
And so many more can’t explain all of them for now

This room will teach us about SQL Truncation attacks an attack that i myself have come to know if it lately due to a room that i did on HackTheBox platform. The successful exploitation of this vulnerability leads to user account compromise, as it means an attacker can access any users account with his own password. This vulnerability occurs due to MySQL truncating the input given and it leaves two different account with same usernames in a database an this will cause an attacker to login to the account he/she want. The threat is based on the fact that if the stored string does not fit into a column with a specific text data type, it will crop and store the value in a truncated form

Navigating to the webpage we get a standard login page

Bruteforce or SQL Injection wont work on the login page since the vulnerability arises in the register page. Navigating to the register page we get a standard registration form

Trying to register an account with a username that already exists we get an error as seen below This user is already registered

This is a vulnerability on it’s own since it can lead to username enumeration attacks if we have valid usernames we can then bruteforce the passwords and we might be lucky and get valid credentials. But enough of that so we can register a username that already exists what if we add a couple of spaces to the username????

I’ll intercept the request with burpsuite so that we can see more clearly

The request without being modified we get an error

Let’s add a couple of spaces to the username

Now let’s try to login with those credentials

And voila we get logged in with our own credentials and we have the flag

You can do the same with the other user Arthur

[Day 3] Sensitive Data Exposure

Sometimes backup are left on the server by ignorant developers and sometimes this backup contain sensitive information like credentials that can lead to compromising of a server let’s take a look from the server’s webpage below

It’s a standard webpage nothing fancy when looking at the source code

Navigating to the login page we get nothing interesting but viewing the page source we see some comments left by the author which tells us that there is a database in /assets

Navigating to /assets we get a database file called webapp.db

I downloaded the database file to my localbox

opening the file with less we get a bunch of gibberish

Doing a file command against the server we see it’s a SQLite 3.x database

The best program that i use to open SQLite databases is sqlitebrowser which comes preinstalled in Parrot SEC OS

Let’s open the databases and see what it contains using the command

sqlitebrowser webapp.db

And we see the database has two tables sessions and users

The session table is empty as seen below

The users table however has sensitive information

It has password hashes of different users example above the hash highlighted is for the user admin. Let’s try to crack the hash using an online hash cracker called hashes.org

And after submitting the hash we see that there was a match the admin’s password was qwertyuiop

Let’s try to login with those credentials

And voila as seen above we have access to the admin console and we have our flags and that’s it for Sensitive Data Exposure

[Day 4] XML External Entity

XML (eXtensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. And truthfully speaking it’s it’s becoming a fundamental language in most web applications these days like Facebook because of how it stores and transports data. Although it has numerous advantages it also has some downside. If XML is parsed incorrectly in a web application it might lead to vulnerabilities which include

Local File Inclusion
Remote Code Execution
Server Side Request Forgery
Cross Site Request Forgery
And many more vulnerabilities

TryHackMe released a forth challenge which you have to exploit a XXE vulnerability. At the end of the article I’ll leave a python script that i created that automates the process of retrieving files from the server and also some link to useful articles you can read that will help you understand the vulnerability even more. Without much say let’s jump in

On opening the webpage we get a standard webpage

And it has a textbox which we can input the payload

The payloads that i normally user are from PayloadAllTheThings Since there payloads almost always work

Let’s first test for the vulnerability using the payload below

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example "Doe"> ]>
 <userInfo>
  <firstName>John</firstName>
  <lastName>&example;</lastName>
 </userInfo>

When the XML parser parses the external entities the result should contain “John” in firstName and "Doe" in lastName

Let’s try it out

And as seen above like magic it works the name John Doe was displayed

Now let’s try a payload that leads to disclosure of sensitive files from the server like passwd file which will give us a good idea of the users of the system. I’ll use the classic XXE payload below

<?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM 'file:///etc/passwd'>]><root>&test;</root>

And voila we get the contents of passwd file now let’s use the python script since i love it’s formatting an it makes the job of typing a bit easier

Below is the script that i created

Let’s see the script in action

You just type the IP Address and the file you want to extract

And voila we see the has been extracted

And from the above output we see that the box has a user called falcon. Sometime when user generate ssh private and public keys they don’t specify a directory where the keys will be stored so the keys get stored in the default directory which is

/home/user/.ssh/id_rsaexample/home/falcon/.ssh/id_rsa

Let’s see if we can get the ssh private keys for this user falcon

And voila as seen above we were able to get the ssh keys which are not even encrypted

Using encryption provides an addition layer of security to the private keys is a strong passphrase is used. So we could potentially use this ssh keys to log into the box without needing additional authentication but in our case it won’t work since the public keys had not been added to the authorized_keys file as seen below

But since we have the vulnerability we can find other files that might lead to further compromising the system and probably getting a shell but that’s it for now guys till the next challenge is released

Below is the source code of the python script i created

import requests
import re
import sysclass bcolors:
    OKBLUE = '\033[94m'
    OKGREEN = '\033[92m'
    ENDC = '\033[0m'sess = requests.session()
IPAddress = sys.argv[1] 
while True:    
    filename = input(bcolors.OKBLUE + "Enter the name file you want to view > " ) + bcolors.ENDC
    payload = """<?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM 'file://"""
    payload += filename
    payload += """ '>]><root>&test;</root>"""
    url = "http://" + IPAddress + "/home"
    postdata = {
        "xxe" : payload
    }
    output = sess.post(url, data=postdata).textbegin = output.find("</main>")
    end = output.find("<center>")
    out = output[begin :end]
    file = re.sub("</main>", "", out).strip()
    print (bcolors.OKGREEN + file + bcolors.ENDC)

Till next time take care

PayloadAllTheThings

[Day 5] Broken Access Control

Broken Access Control is a type of vulnerability where there’s Exposure of Sensitive Data or a type of vulnerability that allows access to place that aren’t allowed for standard users to view. Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others(example is an admin user can access the admin panel while a standard user cannot access the admin panel ). These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Broken Access Control can cause an attacker to access data and perform actions of other users with same level of access on that particular server (a concept commonly known as Horizontal privilege escalation) or can cause an attacker to access data and perform action that are above their level like and administrator(a concept commonly known as vertical privilege escalation). If a particular web application is vulnerable to this kind of vulnerability it might not only lead to exposure of sensitive data but might also lead to a particular server being compromised completely since most admin webpages like admin panels have a way to execute code (system commands)

TryHackMe released this particular challenge a night ago and am here to show you the servility of this particular vulnerability without much say let’s jump in

After deploying the box we get a pretty bare web page which has a login textbox

TryHackMe gave use the login credentials

noot:test1234

Let’s login to the page and see what we see

We don’t get anything useful but our vulnerability is in the URL parameters but before we continue i discovered something after finishing the challenge we could bypass the login page which is another access control vulnerability. Because an unauthorized user is able to view the note.php without using any credentials whatsoever. The page would normally require credentials to view but however due to this vulnerability we could bypass the login authorization.

How i discovered this broken access control vulnerability in the login page was when i was doing some light fuzzing using wfuzz (i will show later down the walkthrough) normally the moment you authenticate to a particular web application, the web application gives you

A cookie (a unique identifier string used to identify you and give you access to restricted pages )
A session ID or phpsessid which does the same function as a cookie

When i was about to fuzz the parameter i knew that since i had performed authentication some cookie had been assigned to me and i knew i would need those cookie for a successfull fuzzing but when i intercepted the request using burpsuite there was no cookie as shown below

That’s how i knew we could bypass the login page since there was nothing to identify is we had logged in using credentials or now but i’ll show the unintended route later for now lets finish the challenge the intended way first

So we’ve been able to login to the web application and we see the parameter note takes numbers so i decided to fuzz a range between 0 - 100 using wfuzz a web application fuzzer. My thinking was that if the notes were identified by numbers we could be able to extract now notes just by fuzzing by using random numbers.

And as seen two payloads came back with a different response that the rest

0 and 1

-c specifies that the output should have colors (since are awesome)--hh tell wfuzz  not to show us pages with 0 characters (this is because if we put a random payload the webpage returns blank)-z range,0-100 wfuzz generate numbers from zero to 100 and the use them as the payload[http://10.10.56.213/note.php?note=FUZZ] finally the URL where we've inserted FUZZ in caps tells wfuzz to put our payload there

We already know the contents of 1 let’s try 0 in that not parameter and see what we see

And navigating to the URL we get the flag

Challenge done !!!!!!

Now the unintended method

It’s going to be purely fuzzing which is a technique all penetration testers should know and understand and this will only happen if as a hacker or a pentester is willing to do pentest in a lot of web application but enough of that

When we navigate to the webpage we are presented with a login panel

Let’s do a directory bruteforcing and see what we’ll get back

Since i was getting a lot of 404 NOT FOUND errors i decided to tell wfuzz not to show my pages with that specific response

And after filtering the request we get 2 pages

index.php
note.php (remember we werenot supposed to be able to view note.php without creds but we are yet we haven’t supplied any credentials)

Index.php gives us the login page

note.php gives us a blank page

But you can pass parameters to PHP webpages am sure most of you know to fuzz for parameters I’ll use burp-parameter-names.txt wordlist from seclists

And after about 30 seconds of fuzzing we get the parameter “note”

Now we can fuzz for the value that note parameter can accept this was a gamble since it can take any value but there are targeted wordlist out there that might help but seen from the first intended way we found it accepted numbers and we were able to extract the flag from one of the notes i don’t want to repeat that last fuzzing since we did above but that was it for the challenge till tomorrow take care

[Day 6] Security Misconfiguration

Hello guys sorry for the delay releasing the walkthrough but as we always say better late than never. We are going to be doing the day 6 challenge from tryhackme . This challenge wasn’t hard at all but i kinda took long to do a writeup since i thought i could exploit the challenge in two different ways but one led me to a really dip rabbit hole. Without much say let’s jump in.

Security misconfiguration is a type of vulnerability where Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories etc. to gain unauthorized access or knowledge of the system. This room explains explain clearly the impact of exploiting this kind of vulnerability can have to a system since Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. This challenge explain clearly how leaving your software system running on default credential can make it real easy for attackers to exploit your system

On opening the web application using Mozilla we get a standard login panel

If you look at the hints on tryhackme it says that there’s a documentation and those documents may have default credentials. If you’ve worked with web applications before you know that there are specific directories and files that are common in many web application and in many cases they contain the documentation and version the application is running. example of this directories include

1. readme.txt
2. http[s]://url/docs
3. http[s]://url/documentation
4. changelog.txt
5. The good old way online documentation
6. README.md

So i knew that probably one of this files might be on the web application and i decided to do a directory bruteforcing with gobuster but to cut the long story shot i really didn’t find anything. So i decided to google and see if it was a production app because if so we can be able to pull documentation from online platform but my google search yield no results

Next i though that it could be an opensource project and we know various platform where open source projects are public examples of which include GitHub, gitlab, gogs etc. Since GitHub is mostly known i started with it and voila we get a repository

Looking at the repository it has a README.md file that mostly where the documentations are places

On opening the file we get a default credentials for the web application is

pensive:PensiveNotes

As seen below

Let’s try those credentials and see if they work

And voila as see above we able to login with those credentials and we have the flag

THE RABBITHOLE

So tryhackme about 2 days ago released a room called overpass really easy but i wouldn’t recommend for absolute beginners because you need to do some static code analysis. So let’s jump over to overpass i explain the concept then we’ll do the same for this challange

On opening the webpage for overpass we get a standard web page that advertizes a password manager called overpass

Going a directory bruteforce we get there’s a directory called admin navigating to it we get a login prompt

I decided to try commonly used credential

admin:admin

But got incorrect credentials provided

So i decided to use developer tools that Mozilla offers and found that the web application calls a file called login.js

Taking a look at the file a found that there was a function that had a vulnerability that could allow us to pass authentication

The JavaScript file waits for the response from the web server and if the body of the response has the string “Incorrect Credentials” it wouldn’t allow you to login to the web application but if you’ve worked with burpsuite before you know you ca change the server’s response and this leads to the vulnerability. Am sure most of you know that in most cases on a successful login we get 302 Found response and a location header telling the browser where to take use

Looking on the JavaScript again we see that on a successful login attempt we get redirected to /admin

So let’s intercept the request with burpsuite and change the response

Right click and select “Do intercept” then click on “response to this request”

Then forward the request

We get the server response let’s change it a bit

To look as you’ll see in the screenshot below

The forward all the request after modifying the server response

Going back to Mozilla and refreshing the tab we get logged in like magic

Without providing any valid credentials we have tricked the web application to think that we had provided valid credentials and we’ve been given unauthorized access to the admin panel cool right???

Now if you’ve seen that that on the administrative panel is a private key that we can use to login to the box after cracking the passphrase

Now back to our challenge

Using developer tools that Mozilla offers let’s see what files are called when we send a login request

Looking at the requests made we see that there’s also a login.js file called everytime we try to login to the application

Let’s do dome static code analysis on the JavaScript file

And as seen above we see the same vulnerability on the JavaScript file. The JavaScript file looked at the server response and if there is the string “Incorrect credentials” or “An unspecified error occurred” it assumes that we provided invalid credentials and doesn't log us into the web application but same as before we can change the server response and bypass the login

If the login was successful we get redirected to /mynotes

So let’s intercept the request and change the response

I’ll use the credentials

admin:admin

Which we know it’s not valid

Then intercept the server’s response as we did before and modify it a bit

And after forwarding all the request and going back to the web application

We are logged in as seen above just like that and a session cookie has been assigned to us

i thought that since we had a valid login session token we could chain that with Insecure Direct Object Reference vulnerability to get the flag but i was wrong and it led me down to a rabbit hole for sometime till i gave up but yes we’ve been able to bypass the login

Thats it for now i’ll release the next challange in a few minutes

[Day 7] Cross-site Scripting

Cross-site Scripting (XSS) is a client-side code injection attack. The attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or web application. Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application. Tryhackme released this challenge yesterday and since i really haven’t exploited this vulnerability much I’ll keep on point

Let’s jump in

First let’s register using the credentials below

hello:hello

And after registering we get logged into the web application immediately

Question 1:

to create a popup with JavaScript we use alert. This will cause the web application to display what we want on our screen

The payload for this question is

<script>alert("Hello")</script>

And we get our first flag

Question 2:

We want the alert message to print the IP Address

The payload for this question is

<script>alert(window.location.hostname)</script>

And as seen below we have the flag. The script payload alerts what is inside the bracket and in our case it’s the hostname

Question 3

One sure way of testing fro xss vulnerability is by seen if it accepts HTML tags . If the HTML tags are not filtered probably the web application is vulnerable to xxs injection

Let’s see below

The payload I’ll use

<b>Coding Rocks</b>

If the code gets displayed in bold it means probably the site is vulnerable to XSS attacks

After clicking the comment button

We see below our text gets commented in bold and we have the flag

Question 4

This challenge requires us to use xxs attack to cause a popup to appear with our cookies

The payload I’ll use is

<script>alert(document.cookie)</script>

And we get our cookies displayed as seen below

And we get the flag

Question 5

Defacing a website with JavaScript

After analyzing the source code i noticed that we could probably cheat by visiting that URL but got caught

But on visiting the URL we get a wierd message

But offcourse we can bypass with with burpsuite but no we’ll stick to the intended route

Let’s use the intended route

I used the payload below

<script>document.querySelector('#thm-title').textContent = 'I am a hacker'</script>

It just changes the title of the webpage from what it used to be. After submitting the payload we get the flag as seen below

And looking at the title it has been changed

That’s it for now guys till next time take care

[Day 8] Insecure Deserialization

Hello guys back again with a solution for the next challenge. This time we are going to be talking about Insecure Deserialization which is a vulnerability that has a really huge effect if it’s exploited successfully. Before we talk about this vulnerability in details lets first understand what serialization and deserialization means

Serialization is the process of converting complex data structures, such as objects and their fields, into a “flatter” format that can be sent and received as a sequential stream of bytes. The reason as to why serialization is important is because it enables the transportation of complex data and also allows the storage of complex data

Deserialization is the process of restoring this byte stream to a fully functional replica of the original object, in the exact state as when it was serialized. This basically means changing the data back to the state it was previously before being serialized

Although serialization and deserialization has numerous advantages it also comes with disadvantages. When user-controllable data is deserialized by a website, this potentially enables an attacker to manipulate serialized objects in order to pass harmful data into the application code. And we’ve seen sites running certain framework being hacked before using this method. Example of frameworks with this particular vulnerability include:

Python
PHP
Java
NodeJS

But for this challenges we go into depth in exploiting python web server with insecure deserialization vulnerability. The reason as to why this vulnerability arises is because there is a general lack of understanding of how dangerous deserializing user-controllable data can be. Web developers think that since there are some checks being done on user input it assures them of complete safety against this kinds of attack but no system is 100% hack proof. So the best action to take in any of this server is to ensure that no user input is deserialized at all. Below you’ll see the impact of a successful exploitation of this vulnerability. Without much say let’s jump in

Insecure Deserialization cookies

Cookies as we’ve mentioned before gives the user authorization to restricted content as we’ve mentioned before. But remember cookies also can be manipulated and this can cause an attacker to gain admin privileges if the cookies are trusted without validation

Let’s see below

When we deploy the box we get an IP Address and on visiting the url we get a nice looking webpage

But we are required to register

so i registered with the credentials

admin:admin

And we are directly logged in

I decided to intercept the request using burpsuite

And we see a cookie has been assigned to us and it appears to be carrying our credentials and also it’s not encrypted but in clear text also the session identification appears to be base64 encoded let’s decode using our terminal

On decoding we get our first flag as seen below

Looking at the cookie again we see that the way it determines whether we are an admin or a normal user is by using the cookie

What if we change the value from a user to an admin. I intercepted the request using burpsuite and changed the user_type value to admin and then forwarded the request

Going back to my web browser i found out that i was automatically logged in to the admin panel and we get our second flag

We’ve been able to perform a privilege escalation from a standard user to an admin just by changing the content of the cookie. This was possible because there was no validation if the cookie had been altered or not

Insecure Deserialization Remote Code Execution

In this challange we’ll be exploiting python’s pickles vulnerability. pickle is supposed to allow us to represent arbitrary objects. An obvious target is Python’s subprocess.Popen objects. If we can trick the target into instantiating one of those, they’ll be executing arbitrary commands for us! and this is where remote code execution comes into play. I’ve written a writeup on this particular vulnerability before based on a tryhackme box called PeakHill so i wouldn’t go into much details but i’ll leave a link down below if you want to take a look

The reason as to why this writeup took longer than expected is because i was writing a python script that automates the entires process of exploiting this vulnerablity and the only job you have to do is to add IP Addresses and listening port. As I’ve said before as a pentester one of these day you’ll need to learn programing if you already don’t know and what is a better time to start than now. If you find a small challange you can code something little and see if it work

Below is the python script i created

What the script basically does is that it creates the payload and send it automatically to the web server and gives you a shell

Let’s see the script in action

And as seen above we have a shell on the web server i’ll leave a link of my GitHub page where you can get the script but for now we have a shell on the box let’s get the final flag

Looking at home directories we get one user cmnatic

Looking at his directory we get the final flag for the challenge

And that’s it for this challenge till next time take care

My GitHub Link

PeakHill Walkthrough

[Day 9] Components with Known Vulnerabilities

The reason why we do a nmap scan when doing a pentest is always not only to know the ports that are open in a particular box but also to know the versions of services that are running in that particular box because we might be lucky and find a service that is vulnerable to a particular exploit and the exploit is open source. As pentester am sure we all know about exploitdb it’s the world largest database which contain open source exploits of vulnerable programs and anyone can have access to them . This exploits are written by bug bounty hunters and pentesters who either found the vulnerability or who understand how to code and since the exploit wasn’t available they decided to create one.

This challenge showcase a web server running Online Book Store 1.0 which in 2020 had a remote code execution vulnerability and there was a public exploit in the exploitdb.

The exploit doesn’t require credentials since it an authenticated remote execution vulnerability. Since we have information about the web server let’s go ahead and exploit it

First i copied the exploit to my localbox and saved it then executed it after specifying a URL

And voila as seen above we have a shell on the box though not persistent. This will remain an issue unless a patch is installed in the system and this means upgrading to the latest software

That’s it for this challenge till next time take care

[Day 10] Insufficient Logging & Monitoring

Insufficient Logging & Monitoring is not a vulnerability in itself rather it’s a category that covers the lack of various best practices that could in turn prevent or damage control security breaches. The best way to determine whether your logging and monitoring is on peak is immediately after a penetration testing The testers’ actions should be recorded sufficiently to understand what damages they may have inflicted. This log files are stored internally and at no time should they be accessed externally. But sometimes we’ve seen these log files being accessed externally. The best example i can give is if an attacker find a local file inclusion vulnerability on the web server and he/she had read access to this log files. The attacker will try to find the best way to avoid detection since he has an idea of how logging and monitoring is done on the web server

The king of information that this log files should contain include

logins attempts
password changes
high value transactions
Failed login attempts
HTTP status codes
Time stamps (What page and information was accessed at what time)

With this information you can be able to determine whether you were breached or not.

How can Insufficient Logging & Monitoring be prevented:

By ensuring that all generated logs are stored in a format that can be easily understood and grasped
Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar
Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis
The application should be able to detect, escalate, or alert for active attacks in real time or near real time

So TryHackMe released a challenge on the same about 12 hours ago it requires us to analyse a log file

After i downloaded the login file to my local box. I decided to take a look at it

And they appear to be login attempts

But some login attempts appear odd since they come from the same IP Address but for 4 consecutive times they appear to be failed login attempts since we are getting an error code of 401 Unauthorized. And due to this if you analyze the log file correctly you could have noticed that it could be a brute force attack and the malicious IP Address is 49.99.13.16 because all the failed login attempts comes from that one specific IP Address. A brute force attack is where an attacker tries random passwords with the hope that he/she will find a valid password.

That’s it for this room till next time take care