The platform develops virtual classrooms that not only allow users to deploy training environments with the click of a button, but also reinforce learning by adding a question-answer approach. Its a comfortable experience to learn using pre-designed courses which include virtual machines (VM) hosted in the cloud.

TryHackMe Advent of Cyber 2 Day 2 Walkthrough


While using a question-answer model does make learning easier, TryHackMe allows users to create their own virtual classrooms to teach particular topics enabling them to become teachers. This not only provides other users with rich and varied content, but also helps creators reinforce their understanding of fundamental concepts.



Room :- https://tryhackme.com/room/adventofcyber2

 

Advent of Cyber 2

Get started with Cyber Security in 25 Days - Learn the basics by doing a new, beginner friendly security challenge every day leading up to Christmas.

Task 7 [Day 2] Web Exploitation The Elf Strikes Back!

After your heroic deeds regaining control of the control centre yesterday, Elf McSkidy has decided to give you an important job to do.

"We know we've been hacked, so we need a way to protect ourselves! The dev team have set up a website for the elves to upload pictures of any suspicious people hanging around the factory, but we need to make sure it's secure before we add it to the public network. Please perform a security audit on the new server and make sure it's unhackable!" TryHackMe Advent of Cyber 2 Day 2 Walkthrough

You listen to the briefing and accept the task, pressing the deploy button to start the server as you do so.

McSkidy once again gives you a dossier of useful information to help you with your task, which you read as you wait for the server to boot:


 

GET Parameters and URLs

We looked briefly at the differences between GET and POST requests in the previous dossier; however, the emphasis was on the POST requests used in a login form. The server you'll be testing today employs a concept called "GET parameters". Just as POST requests can be used to send information to the server, so too can GET requests be used; however, there is one important difference. With POST requests the data being sent is included in the "body" of the request. With GET requests, the data is included in the URL as a "parameter". This is best demonstrated with an example:

https://www.thebestfestivalcompany.co.uk/index.php?snack=mincePie

(Please Note: this site is completely fictitious. It does not exist, and connecting to it is not part of the task)

There are 7 different parts which make up this URL. Let's look at each of them in turn:

1. First up we have the protocol (https://). This specifies whether the request should be made using HTTP, or HTTPS. In our example, we are using HTTPS.
2. Next we have the subdomain (www). This is traditionally "www" (World Wide Web) to signify that the target is a website; however, this is not essential. Indeed, subdomains can be basically anything you want; for example, a lot of websites use things like "assets", or "api" to indicate different subdomains with different uses. (e.g. https://api.thebestfestivalcompany.co.uk).
3. The next part of the URL is the domain (thebestfestivalcompany). Domains need to be registered and are used as links between a memorable word or phrase, and an IP address. In other words, they're used to give a name to the server running a website.
4. Next up we have the TLD (Top Level Domain) -- .co.uk, for our example. Top-level domains are used by DNS to determine where to look if they want to find your domain. Previously top-level domains had specific uses (and many still do!), but this is not always the case these days. For example, .co.uk  indicates a company based in the UK, .com indicates a company based in the US.
5. We then have the resource that we're selecting -- in this case that is the homepage of the website: index.php. As a side note, all homepages must be called "index" in order to be correctly served by the web server without having to be specified fully, unless this parameter has been changed from the default in the webserver configuration. This is how you can go to [https://tryhackme.com](https://tryhackme.com) without having to specify that you want to receive the home page -- the index page is served automatically because you didn't specify!
6. The final two aspects of the URL are the most important for our current topic: they both relate to GET parameters. First up we have ?snack=. Here ? is used to specify that a GET parameter is forthcoming. We then have the parameter name: snack. This is used to identify the parameter to the server. We then have an equals sign (=), indicating that the value will come next.
7. Finally, we have the value of the GET parameter: mincePie, because who doesn't like mince pies, right?
8. It's important to note exactly which part of the URL is the GET parameter. Specifically, we are talking about ?snack=mincePie. If there was more than one parameter, we would separate them with an ampersand (&). For example: ?snack=mincePie&drink=hotChocolate. In this way we can send multiple values to the server, distinguished by keys (i.e. "mincePie" is identified by the key: "snack").

It's important to note exactly which part of the URL is the GET parameter. Specifically, we are talking about ?snack=mincePie. If there was more than one parameter, we would separate them with an ampersand (&). For example: ?snack=mincePie&drink=hotChocolate. In this way we can send multiple values to the server, distinguished by keys (i.e. "mincePie" is identified by the key: "snack").

 

File Uploads

There are countless uses for file uploads in the modern internet -- profile pictures, school/university submissions, diagrams, pictures of your dog, you name it! Whilst file uploads are very common, they're also very easy to implement in an insecure fashion. For this reason, it's important that we understand the gravity of the attack vector.

When you have the ability to upload files to a server, you have a path straight to RCE (Remote Command Execution). An upload form with no restrictions would mean that you could upload a script that, when executed, connects back to your attacking machine and gives you the ability to run any command you want. It would be very unusual to find a file upload with no filtering; but it's much less uncommon to find a file upload that employs flawed filtering techniques which can be circumvented to upload a malicious script. The script has to be written in a language which the server can execute. PHP is usually a good choice for this, as most websites are still written with a PHP back end.

There isn't time to go over every kind of filter bypass in this task (there is literally an entire room on this topic, which is recommended for further practice). Instead, we'll just cover one of the most common types of filter and its bypass:
 

File Extension Filtering: As the name suggests extension filtering checks the file extension of uploaded files. This is often done by specifying a list of allowed extensions, then checking the uploaded file against the list. If the extension is not in the allowlist, the upload is rejected.
    

So, what's the bypass? Well, the answer is that it depends entirely on how the filter is implemented. Many extension filters split a filename at the dot (.) and check what comes after it against the list. This makes it very easy to bypass by uploading a double-barrelled extension (e.g. .jpg.php). The filter splits at the dot(s), then checks what it thinks is the extension against the list. If jpg is an allowed extension then the upload will succeed and our malicious PHP script will be uploaded to the server.

When implementing an upload system, it's good practice to upload the files to a directory that can't be accessed remotely. Unfortunately, this is often not the case, and scripts are uploaded to a subdirectory on the webserver (often something like /uploads, /images, /media, or /resources). For example, we might be able to find the uploaded script at https://www.thebestfestivalcompany.co.uk/images/shell.jpg.php.

Reverse Shells

Let's assume that we've found somewhere to upload our malicious script, and we've bypassed the filter -- what then? There are a few paths we can take: the most common of which is uploading a reverse shell. This is a script that creates a network connection from the server, to our attacking machine. The majority of webservers are written with a PHP back end, which means we need a PHP reverse shell script -- there happens to be one already on Kali/AttackBox at /usr/share/webshells/php/php-reverse-shell.php (Note: if you're not using Kali or the provided AttackBox, the same script can be found here.

 

Copy the webshell out into your current directory (cp /usr/share/webshells/php/php-reverse-shell.php .), then open it with your text editor of choice.
 

Scroll down to where it has $ip and $port (both marked with // CHANGE THIS). Set the IP to your TryHackMe IP Address (which can be found in the green bubble on the navbar, if you're using the AttackBox, or by running ip a show tun0 if you're using your own Linux VM with the OpenVPN connection pack) -- making sure to keep the double-quotes. Set the port to 443 with no double quotes, then save and exit the file. Congratulations, you now have a fully configured PHP reverse shell script!

 

PHP reverse shells can be very easily activated when stored in an accessible location: simply navigate to the file in your browser to execute the script (and send the reverse shell):

In the diagram, we first upload our shell. We then navigate to it in our browser, causing the server to send a reverse shell back to our waiting listener.
For a more in-depth explanation of reverse shells, check out the Intro to Shells room.

Reverse Shell Listeners

We've spoken at length about reverse shell listeners, but what are they? In short, a reverse shell listener is used to open a network socket to receive a raw connection -- like the one created by a reverse shell being executed! The simplest form of listener is created by using a program called netcat, which is installed on both Kali and the AttackBox by default. We can create a listener for an uploaded reverse shell by using this command: sudo nc -lvnp 443. This essentially creates a listener on port 443. In a real-world environment, you would want to use a common port such as 443 that is not filtered by firewalls in most scenarios, increasing the chances our reverse shell connects back.. Once netcat has been setup, our reverse shell will be able to connect back to this when activated.

The full explanation can be found in the Intro to Shells room linked above, if you're interested.

Putting it all together

This was a lot of information, so let's put it all together and look at the full process for exploiting a file upload vulnerability in a PHP web application:

Find a file upload point.
 

Try uploading some innocent files -- what does it accept? (Images, text files, PDFs, etc)

•     Find the directory containing your uploads.
•     Try to bypass any filters and upload a reverse shell.
•     Start a netcat listener to receive the shell
•     Navigate to the shell in your browser and receive a connection!

At the bottom of the dossier is a sticky note containing the following message:
For Elf McEager:
    

You have been assigned an ID number for your audit of the system: ODIzODI5MTNiYmYw . Use this to gain access to the upload section of the site. TryHackMe Advent of Cyber 2 Day 2 Walkthrough
    

Good luck!

You note down the ID number and navigate to the displayed IP address (Your TryHackMe IP) in your browser.

Let's start

1) What string of text needs adding to the URL to get access to the upload page?

Ans :- ?id=ODIzODI5MTNiYmYw



2) What type of file is accepted by the site?

HINT :- There are three filetypes accepted by the upload form. These can be found by checking the page source code. They all have something in common in that they are types of ____ file.

Ans :- image


3) Bypass the filter and upload a reverse shell.

In which directory are the uploaded files stored?

HINT :-  The filter can be bypassed using the technique taught in the task. The answer can be found with a tool such as Gobuster, or by checking each of the common directories from the dossier.

gobuster dir -u http://10.10.254.172/  -w  /usr/share/dirb/wordlists/common.txt --wildcard

You can also use BURP SUITE with uploading a php reverse shell file (change the extension with your Tunnel IP and Port (.jpg.php)

Ans :- /uploads/



4) Activate your reverse shell and catch it in a netcat listener!

Ans :- no answer needed

5) What is the flag in /var/www/flag.txt? 

First of all we will upload a reverse shell file with the extension (.jpg.php ) and burp suite intercept is ON.

 

Now, finally we will use netcat listener and access a PHP reverse shell file in "Elf Strike's" website with uploads parameter and click on it php-reverse-shell..jpg.php file.

Ans :- THM{MGU3Y2UyMGUwNjExYTY4NTAxOWJhMzhh}

 

See you soon, with another task N day. So till then bookmark our website

Disclaimer

 
The platform develops virtual classrooms that not only allow users to deploy training environments with the click of a button, but also reinforce learning by adding a question-answer approach. Its a comfortable experience to learn using pre-designed courses which include virtual machines (VM) hosted in the cloud.

TryHackMe Advent of Cyber 2 Day 1 Walkthrough


While using a question-answer model does make learning easier, TryHackMe allows users to create their own virtual classrooms to teach particular topics enabling them to become teachers. This not only provides other users with rich and varied content, but also helps creators reinforce their understanding of fundamental concepts.



Room :- https://tryhackme.com/room/adventofcyber2

 

Advent of Cyber 2

Get started with Cyber Security in 25 Days - Learn the basics by doing a new, beginner friendly security challenge every day leading up to Christmas.

Task 6 [Day 1] Web Exploitation A Christmas Crisis

"The Best Festival Company's brand new OpenVPN server has been hacked. This is a crisis!

The attacker has damaged various aspects of the company infrastructure -- including using the Christmas Control Centre to shut off the assembly line!

It's only 24 days until Christmas, and that line has to be operational or there won't be any presents! You have to hack your way  back into Santa's account (blast that hacker changing the password!) and getting the assembly line up and running again, or Christmas will be ruined!"

The Web:

The Internet is one of those things that everyone uses, but few people bother to learn about. As hackers, it is vital that we understand what exactly the web is, and how it works.

When you open up your web browser and navigate to a website, it seems so simple, but what is really happening behind the scenes?

First of all, your computer communicates with a known DNS (Domain Name System) server to find out where the website can be found on the internet. The DNS server will then return an IP address for the remote server. This can be used to go directly to the website. You can think of the internet as being quite like the planet itself -- we have lots of locations, all over the world. 

These places all have a street address -- this is akin to the domain name of a website (i.e. tryhackme.com, or google.com); but they also have co-ordinates which can be used to pinpoint their location with absolute accuracy. 

These co-ordinates are like the IP address of a website. If you know the street address of a location, you can enter it into Google Maps and be given the exact coordinates, which can then be put into a SatNav to take you there with pinpoint accuracy!

In the same way, your browser is given the address of a website (i.e. tryhackme.com). It sends this address off to a DNS server, which tells it the "co-ordinates" (the IP address) of the site. Your computer doesn't understand the original, human-readable domain name, but it does understand what an IP address is! The IP can then be used to find the server across the internet, allowing your computer to request the content of the website. Of course, in reality, this is a highly simplified analogy, so a more in-depth explanation of this process can be found here.

HTTP(S):

Once your computer knows where it can find the target website, it sends something called a HTTP (Hypertext Transfer Protocol) request to the webserver.

This is just a standard network request, but it is formatted in a way that both your web browser and the server can understand. In practice, this means adding certain "headers" to the request which identify it as a HTTP request, and tell the server a variety of other information about the request, as well as your own browser. Amongst many other headers, HTTP requests always have a method and a target. These specify what to retrieve from the server (the target), and how to retrieve it (the method). The method most commonly used to retrieve information is called the GET method. When sending data to the server, it's more common to use a method called POST.

Cookies:

HTTP is an inherently stateless protocol. This means that no data persists between connections; your computer could make two requests immediately after each other, and, without relying on separate software, the web server would have no way to know that it was you making both the requests. This begs the important question: if HTTP is stateless, then how do login systems work? The web server must have a way to identify that you have the right level of access, and it can hardly ask you to enter your password every time you request a new page!

The answer is cookies -- tiny little pieces of information that get stored on your computer and get sent to the server along with every request that you make. Authentication (or session) cookies are used to identify you (these will be very important in your mission today!). The server receives your request with the attached cookie, and checks the cookie to see what level of access you are allowed to have. It then returns a response appropriate to that level of access.

For example, a standard user should be able to see (but not interact with) our control panel; but Santa should be able to access everything! Cookies are also often used for other purposes such as advertising and storing user preferences (light/dark theme, for example); however, this will not be important in your task today. Any site can set cookies with a variety of properties -- the most important of these for today's task are the name and value of the cookies, both of which will always be set. It's worth noting that a site can only access cookies that are associated with its own domain (i.e. google.com can't access any cookies stored by tryhackme.com, and vice versa).



It's important to note that cookies are stored locally on your computer. This means that they are under your control -- i.e. you can add, edit, or delete them as you wish. There are a few ways to do this, however, it's most commonly done by using your Browser Developer Tools, which can be accessed in most browsers by pressing F12, or Ctrl + Shift + I. With the developer tools open, navigate to the Storage tab in FireFox, or the Application tab in Chrome/Edge and select the Cookies menu on the left hand side of the console.

In the above image you can see a test cookie for a website. The important attributes "Name" and "Value" are shown. The name of a cookie is used to identify it to the server. The value of the cookie is the data stored by the server. In this example the server would be looking for a cookie called "Cookie Name". It would then retrieve the value "CookieValue" from this cookie.

These values can be edited by double-clicking on them, which is great if you can edit a session or authorisation cookie, as this can lead to an escalation of privileges, assuming you have access to an Administrator's authorisation cookie.

Having read the lengthy dossier,  you get ready to hack your way back into Santa's Christmas Control Centre! You enter the IP address at the top of the screen into your browser search bar and press enter to load the page.

1) Register for an account, and then login.

What is the name of the cookie used for authentication?
 

HINT :- Check your Browser's Developer tools. These can usually be accessed with F12 in most browsers, or Ctrl + Shift + I otherwise.

Ans :-  auth

2) In what format is the value of this cookie encoded?

HINT :- Often used as a "shorthand for binary".

Ans :- Hexadecimal

 

3) Having decoded the cookie, what format is the data stored in?

HINT :- Use CyberChef to decode the cookie. The format is a very common one, often linked to JavaScript. (https://gchq.github.io/CyberChef/#recipe=From_Hex('Auto'))

First of all we will copy this cookies value (session's cookies ) and then decode it in cyberchef website. ( link in the above )

Check out this format, look like javascript object notation 

{"company":"The Best Festival Company", "username":"whoiskumaratul"}

Ans :-  JSON 

4) Figure out how to bypass the authentication.

What is the value of Santa's cookie?

HINT :- Remember, you can edit your cookies value! Why not use the decoded cookie you got in the last question, update the username with "santa" and re-encode it? 

Now, we will change the value of username, like whoiskumaratul, This is my username, there may be something else in your case. so, You have to re-encode the entire format by typing the Santa username in place of your username.

Before

{"company":"The Best Festival Company", "username":"whoiskumaratul"}

After

{"company":"The Best Festival Company", "username":"santa"}

let's decode the value in "To Hex" and Delimiter is NONE and Bytes per line is 0.

Ans :-   7b22636f6d70616e79223a22546865204265737420466573746976616c20436

f6d70616e79222c2022757365726e616d65223a2273616e7461227d

5) Now that you are the santa user, you can re-activate the assembly line!

What is the flag you're given when the line is fully active?
 

Now, replace your cookies to the santa's cookies and refresh the page. Then click to enable every Active button.

See you soon, with another task N day. So till then bookmark our website

Disclaimer

 
The platform develops virtual classrooms that not only allow users to deploy training environments with the click of a button, but also reinforce learning by adding a question-answer approach. Its a comfortable experience to learn using pre-designed courses which include virtual machines (VM) hosted in the cloud.

TryHackMe Further Nmap Walkthrough


While using a question-answer model does make learning easier, TryHackMe allows users to create their own virtual classrooms to teach particular topics enabling them to become teachers. This not only provides other users with rich and varied content, but also helps creators reinforce their understanding of fundamental concepts.



Room :- https://tryhackme.com/room/furthernmap

 

Further Nmap

An in depth look at scanning with Nmap, a powerful network scanning tool.


Deploy the machine!

Please Note: This machine is for scanning purposes only. You do not need to log into it, or exploit any vulnerabilities to gain access.

 

Task 2 Introduction

When it comes to hacking, knowledge is power. The more knowledge you have about a target system or network, the more options you have available. This makes it imperative that proper enumeration is carried out before any exploitation attempts are made.

Say we have been given an IP (or multiple IP addresses) to perform a security audit on. Before we do anything else, we need to get an idea of the “landscape” we are attacking. What this means is that we need to establish which services are running on the targets. For example, perhaps one of them is running a webserver, and another is acting as a Windows Active Directory Domain Controller. The first stage in establishing this “map” of the landscape is something called port scanning. When a computer runs a network service, it opens a networking construct called a “port” to receive the connection.  Ports are necessary for making multiple network requests or having multiple services available. For example, when you load several webpages at once in a web browser, the program must have some way of determining which tab is loading which web page. This is done by establishing connections to the remote webservers using different ports on your local machine. Equally, if you want a server to be able to run more than one service (for example, perhaps you want your webserver to run both HTTP and HTTPS versions of the site), then you need some way to direct the traffic to the appropriate service. Once again, ports are the solution to this. Network connections are made between two ports – an open port listening on the server and a randomly selected port on your own computer. For example, when you connect to a web page, your computer may open port 49534 to connect to the server’s port 443.

As in the previous example, the diagram shows what happens when you connect to numerous websites at the same time. Your computer opens up a different, high-numbered port (at random), which it uses for all its communications with the remote server.

Every computer has a total of 65535 available ports; however, many of these are registered as standard ports. For example, a HTTP Webservice can nearly always be found on port 80 of the server. A HTTPS Webservice can be found on port 443. Windows NETBIOS can be found on port 139 and SMB can be found on port 445. It is important to note; however, that especially in a CTF setting, it is not unheard of for even these standard ports to be altered, making it even more imperative that we perform appropriate enumeration on the target.

If we do not know which of these ports a server has open, then we do not have a hope of successfully attacking the target; thus, it is crucial that we begin any attack with a port scan. This can be accomplished in a variety of ways – usually using a tool called nmap, which is the focus of this room. Nmap can be used to perform many different kinds of port scan – the most common of these will be introduced in upcoming tasks; however, the basic theory is this: nmap will connect to each port of the target in turn. Depending on how the port responds, it can be determined as being open, closed, or filtered (usually by a firewall). Once we know which ports are open, we can then look at enumerating which services are running on each port – either manually, or more commonly using nmap.

So, why nmap? The short answer is that it's currently the industry standard for a reason: no other port scanning tool comes close to matching its functionality (although some newcomers are now matching it for speed). It is an extremely powerful tool – made even more powerful by its scripting engine which can be used to scan for vulnerabilities, and in some cases even perform the exploit directly! Once again, this will be covered more in upcoming tasks.

For now, it is important that you understand: what port scanning is; why it is necessary; and that nmap is the tool of choice for any kind of initial enumeration.

1) What networking constructs are used to direct traffic to the right application on a server?

Ans :- Ports

 

2) How many of these are available on any network-enabled computer?

Ans :- 65535

3) [Research] How many of these are considered "well-known"? (These are the "standard" numbers mentioned in the task)


Ans :- 1024

Task 3 Nmap Switches

Like most pentesting tools, nmap is run from the terminal. There are versions available for both Windows and Linux. For this room we will assume that you are using Linux; however, the switches should be identical. Nmap is installed by default in both Kali Linux and the TryHackMe Attack Box.


Nmap can be accessed by typing nmap into the terminal command line, followed by some of the "switches" (command arguments which tell a program to do different things) we will be covering below.


All you'll need for this is the help menu for nmap (accessed with nmap -h) and/or the nmap man page (access with man nmap). For each answer, include all parts of the switch unless otherwise specified. This includes the hyphen at the start (-).



1) What is the first switch listed in the help menu for a 'Syn Scan' (more on this later!)?

Ans :- -sS


2) Which switch would you use for a "UDP scan"?


Ans :- -sU


3) If you wanted to detect which operating system the target is running on, which switch would you use?

Ans :- -O


4) Nmap provides a switch to detect the version of the services running on the target. What is this switch?

Ans :- -sV



5) The default output provided by nmap often does not provide enough information for a pentester. How would you increase the verbosity?

Ans :- -v




Verbosity level one is good, but verbosity level two is better! How would you set the verbosity level to two?
(Note: it's highly advisable to always use at least this option)

We should always save the output of our scans -- this means that we only need to run the scan once (reducing network traffic and thus chance of detection), and gives us a reference to use when writing reports for clients.

6) What switch would you use to save the nmap results in three major formats?

Ans :- -oA



7) What switch would you use to save the nmap results in a "normal" format?

Ans :- -oN



8) A very useful output format: how would you save results in a "grepable" format?

Ans :- -oG


Sometimes the results we're getting just aren't enough. If we don't care about how loud we are, we can enable "aggressive" mode. This is a shorthand switch that activates service detection, operating system detection, a traceroute and common script scanning.

9)How would you activate this setting?

Ans :- -A



Nmap offers five levels of "timing" template. These are essentially used to increase the speed your scan runs at. Be careful though: higher speeds are noisier, and can incur errors!

10) How would you set the timing template to level 5?

Ans :- -T5


We can also choose which port(s) to scan.

11) How would you tell nmap to only scan port 80?

Ans :- -p 80


12) How would you tell nmap to scan ports 1000-1500?

Ans :- -p 1000-1500


A very useful option that should not be ignored:

13) How would you tell nmap to scan all ports?

Ans :- -p-


14) How would you activate a script from the nmap scripting library (lots more on this later!)?

Ans :-  --script


18) How would you activate all of the scripts in the "vuln" category?

Ans :- --script=vuln

Task 4 [Scan Types] Overview

When port scanning with Nmap, there are three basic scan types. These are:

•     TCP Connect Scans (-sT)
•     SYN "Half-open" Scans (-sS)
•     UDP Scans (-sU)

Additionally there are several less common port scan types, some of which we will also cover (albeit in less detail). These are:

•     TCP Null Scans (-sN)
•     TCP FIN Scans (-sF)
•     TCP Xmas Scans (-sX)

Most of these (with the exception of UDP scans) are used for very similar purposes, however, the way that they work differs between each scan. This means that, whilst one of the first three scans are likely to be your go-to in most situations, it's worth bearing in mind that other scan types exist.

In terms of network scanning, we will also look briefly at ICMP (or "ping") scanning.

Task 5 [Scan Types] TCP Connect Scans

To understand TCP Connect scans (-sT), it's important that you're comfortable with the TCP three-way handshake. If this term is new to you then completing Introductory Networking before continuing would be advisable.


As a brief recap, the three-way handshake consists of three stages. First the connecting terminal (our attacking machine, in this instance) sends a TCP request to the target server with the SYN flag set. The server then acknowledges this packet with a TCP response containing the SYN flag, as well as the ACK flag. Finally, our terminal completes the handshake by sending a TCP request with the ACK flag set.

 

This is one of the fundamental principles of TCP/IP networking, but how does it relate to Nmap?

Well, as the name suggests, a TCP Connect scan works by performing the three-way handshake with each target port in turn. In other words, Nmap tries to connect to each specified TCP port, and determines whether the service is open by the response it receives.


For example, if a port is closed, RFC 793 states that:


"... If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset.  In particular, SYNs addressed to a non-existent connection are rejected by this means."


In other words, if Nmap sends a TCP request with the SYN flag set to a closed port, the target server will respond with a TCP packet with the RST (Reset) flag set. By this response, Nmap can establish that the port is closed.

If, however, the request is sent to an open port, the target will respond with a TCP packet with the SYN/ACK flags set. Nmap then marks this port as being open (and completes the handshake by sending back a TCP packet with ACK set).



This is all well and good, however, there is a third possibility.

What if the port is open, but hidden behind a firewall?

Many firewalls are configured to simply drop incoming packets. Nmap sends a TCP SYN request, and receives nothing back. This indicates that the port is being protected by a firewall and thus the port is considered to be filtered.

That said, it is very easy to configure a firewall to respond with a RST TCP packet. For example, in IPtables for Linux, a simple version of the command would be as follows:


iptables -I INPUT -p tcp --dport <port> -j REJECT --reject-with tcp-reset

This can make it extremely difficult (if not impossible) to get an accurate reading of the target(s).



1) Which RFC defines the appropriate behaviour for the TCP protocol?

Ans :- RFC 793



2) If a port is closed, which flag should the server send back to indicate this?

Ans :- RST

Task 6 [Scan Types] SYN Scans

As with TCP scans, SYN scans (-sS) are used to scan the TCP port-range of a target or targets; however, the two scan types work slightly differently. SYN scans are sometimes referred to as "Half-open" scans, or "Stealth" scans.


Where TCP scans perform a full three-way handshake with the target, SYN scans sends back a RST TCP packet after receiving a SYN/ACK from the server (this prevents the server from repeatedly trying to make the request). In other words, the sequence for scanning an open port looks like this:

This has a variety of advantages for us as hackers:

• It can be used to bypass older Intrusion Detection systems as they are looking out for a full three way handshake. This is often no longer the case with modern IDS solutions; it is for this reason that SYN scans are still frequently referred to as "stealth" scans.
•  
  
• SYN scans are often not logged by applications listening on open ports, as standard practice is to log a connection once it's been fully established. Again, this plays into the idea of SYN scans being stealthy.
•  
• Without having to bother about completing (and disconnecting from) a three-way handshake for every port, SYN scans are significantly faster than a standard TCP Connect scan.

There are, however, a couple of disadvantages to SYN scans, namely:

• They require sudo permissions[1] in order to work correctly in Linux. This is because SYN scans require the ability to create raw packets (as opposed to the full TCP handshake), which is a privilege only the root user has by default.
•  
  
• Unstable services are sometimes brought down by SYN scans, which could prove problematic if a client has provided a production environment for the test.

All in all, the pros outweigh the cons.

For this reason, SYN scans are the default scans used by Nmap if run with sudo permissions. If run without sudo permissions, Nmap defaults to the TCP Connect scan we saw in the previous task.



When using a SYN scan to identify closed and filtered ports, the exact same rules as with a TCP Connect scan apply.


If a port is closed then the server responds with a RST TCP packet. If the port is filtered by a firewall then the TCP SYN packet is either dropped, or spoofed with a TCP reset.


In this regard, the two scans are identical: the big difference is in how they handle open ports.


[1] SYN scans can also be made to work by giving Nmap the CAP_NET_RAW, CAP_NET_ADMIN and CAP_NET_BIND_SERVICE capabilities; however, this may not allow many of the NSE scripts to run properly.

1) There are two other names for a SYN scan, what are they?

Ans :- Half-Open, stealth



2) Can Nmap use a SYN scan without Sudo permissions (Y/N)?

Ans :- N

Task 7 [Scan Types] UDP Scans

Unlike TCP, UDP connections are stateless. This means that, rather than initiating a connection with a back-and-forth "handshake", UDP connections rely on sending packets to a target port and essentially hoping that they make it. This makes UDP superb for connections which rely on speed over quality (e.g. video sharing), but the lack of acknowledgement makes UDP significantly more difficult (and much slower) to scan. The switch for an Nmap UDP scan is (-sU)


When a packet is sent to an open UDP port, there should be no response. When this happens, Nmap refers to the port as being open|filtered. In other words, it suspects that the port is open, but it could be firewalled. If it gets a UDP response (which is very unusual), then the port is marked as open. More commonly there is no response, in which case the request is sent a second time as a double-check. If there is still no response then the port is marked open|filtered and Nmap moves on.


When a packet is sent to a closed UDP port, the target should respond with an ICMP (ping) packet containing a message that the port is unreachable. This clearly identifies closed ports, which Nmap marks as such and moves on.


Due to this difficulty in identifying whether a UDP port is actually open, UDP scans tend to be incredibly slow in comparison to the various TCP scans (in the region of 20 minutes to scan the first 1000 ports, with a good connection). For this reason it's usually good practice to run an Nmap scan with with --top-ports <number> enabled. For example, scanning with  nmap -sU --top-ports 20 <target>. Will scan the top 20 most commonly used UDP ports, resulting in a much more acceptable scan time.


When scanning UDP ports, Nmap usually sends completely empty requests -- just raw UDP packets. That said, for ports which are usually occupied by well-known services, it will instead send a protocol-specific payload which is more likely to elicit a response from which a more accurate result can be drawn.



1) If a UDP port doesn't respond to an Nmap scan, what will it be marked as?

Ans :- open|filtered



2) When a UDP port is closed, by convention the target should send back a "port unreachable" message. Which protocol would it use to do so?

Ans :- ICMP

Task 8 [Scan Types] NULL, FIN and Xmas

NULL, FIN and Xmas TCP port scans are less commonly used than any of the others we've covered already, so we will not go into a huge amount of depth here. All three are interlinked and are used primarily as they tend to be even stealthier, relatively speaking, than a SYN "stealth" scan. Beginning with NULL scans:


As the name suggests, NULL scans (-sN) are when the TCP request is sent with no flags set at all. As per the RFC, the target host should respond with a RST if the port is closed.

FIN scans (-sF) work in an almost identical fashion; however, instead of sending a completely empty packet, a request is sent with the FIN flag (usually used to gracefully close an active connection). Once again, Nmap expects a RST if the port is closed.

As with the other two scans in this class, Xmas scans (-sX) send a malformed TCP packet and expects a RST response for closed ports. It's referred to as an xmas scan as the flags that it sets (PSH, URG and FIN) give it the appearance of a blinking christmas tree when viewed as a packet capture in Wireshark.

The expected response for open ports with these scans is also identical, and is very similar to that of a UDP scan. If the port is open then there is no response to the malformed packet. Unfortunately (as with open UDP ports), that is also an expected behaviour if the port is protected by a firewall, so NULL, FIN and Xmas scans will only ever identify ports as being open|filtered, closed, or filtered. If a port is identified as filtered with one of these scans then it is usually because the target has responded with an ICMP unreachable packet.


It's also worth noting that while RFC 793 mandates that network hosts respond to malformed packets with a RST TCP packet for closed ports, and don't respond at all for open ports; this is not always the case in practice. In particular Microsoft Windows (and a lot of Cisco network devices) are known to respond with a RST to any malformed TCP packet -- regardless of whether the port is actually open or not. This results in all ports showing up as being closed.


That said, the goal here is, of course, firewall evasion. Many firewalls are configured to drop incoming TCP packets to blocked ports which have the SYN flag set (thus blocking new connection initiation requests). By sending requests which do not contain the SYN flag, we effectively bypass this kind of firewall. Whilst this is good in theory, most modern IDS solutions are savvy to these scan types, so don't rely on them to be 100% effective when dealing with modern systems.



1) Which of the three shown scan types uses the URG flag?

Ans :- xmas


2) Why are NULL, FIN and Xmas scans generally used?

Ans :- Firewall Evasion



3) Which common OS may respond to a NULL, FIN or Xmas scan with a RST for every port?

Ans :- Microsoft Windows

Task 9 [Scan Types] ICMP Network Scanning

On first connection to a target network in a black box assignment, our first objective is to obtain a "map" of the network structure -- or, in other words, we want to see which IP addresses contain active hosts, and which do not.


One way to do this is by using Nmap to perform a so called "ping sweep". This is exactly as the name suggests: Nmap sends an ICMP packet to each possible IP address for the specified network. When it receives a response, it marks the IP address that responded as being alive. For reasons we'll see in a later task, this is not always accurate; however, it can provide something of a baseline and thus is worth covering.



To perform a ping sweep, we use the -sn switch in conjunction with IP ranges which can be specified with either a hypen (-) or CIDR notation. i.e. we could scan the 192.168.0.x network using:



    nmap -sn 192.168.0.1-254

or

    nmap -sn 192.168.0.0/24



The -sn switch tells Nmap not to scan any ports -- forcing it to rely purely on ICMP packets (or ARP requests on a local network) to identify targets.


 

1) How would you perform a ping sweep on the 172.16.x.x network (Netmask: 255.255.0.0) using Nmap? (CIDR notation)

Ans :- nmap -sn 172.16.0.0/16

Task 10 [NSE Scripts] Overview

The Nmap Scripting Engine (NSE) is an incredibly powerful addition to Nmap, extending its functionality quite considerably. NSE Scripts are written in the Lua programming language, and can be used to do a variety of things: from scanning for vulnerabilities, to automating exploits for them. The NSE is particularly useful for reconnaisance, however, it is well worth bearing in mind how extensive the script library is.


There are many categories available. Some useful categories include:

•     safe:- Won't affect the target
•     intrusive:- Not safe: likely to affect the target
•     vuln:- Scan for vulnerabilities
•     exploit:- Attempt to exploit a vulnerability
•     auth:- Attempt to bypass authentication for running services (e.g. Log into an FTP server anonymously)
•     brute:- Attempt to bruteforce credentials for running services
•     discovery:- Attempt to query running services for further information about the network (e.g. query an SNMP server).

A more exhaustive list can be found here.


In the next task we'll look at how to interact with the NSE and make use of the scripts in these categories.


1) What language are NSE scripts written in?

Ans :- lua


2) Which category of scripts would be a very bad idea to run in a production environment?

Ans :-  intrusive

Task 11 [NSE Scripts] Working with the NSE

In Task 3 we looked very briefly at the --script switch for activating NSE scripts from the vuln category using --script=vuln. It should come as no surprise that the other categories work in exactly the same way. If the command --script=safe is run, then any applicable safe scripts will be run against the target (Note: only scripts which target an active service will be activated).



To run a specific script, we would use --script=<script-name> , e.g. --script=http-fileupload-exploiter.



Multiple scripts can be run simultaneously in this fashion by separating them by a comma. For example: --script=smb-enum-users,smb-enum-shares.



Some scripts require arguments (for example, credentials, if they're exploiting an authenticated vulnerability). These can be given with the --script-args Nmap switch. An example of this would be with the http-put script (used to upload files using the PUT method). This takes two arguments: the URL to upload the file to, and the file's location on disk. 


For example:

nmap -p 80 --script http-put --script-args http-put.url='/dav/shell.php',http-put.file='./shell.php'


Note that the arguments are separated the commas, and connected to the corresponding script with periods (i.e.  <script-name>.<argument>).



A full list of scripts and their corresponding arguments (along with example use cases) can be found here.



Nmap scripts come with built-in help menus, which can be accessed using nmap --script-help <script-name>. This tends not to be as extensive as in the link given above, however, it can still be useful when working locally.



1) What optional argument can the ftp-anon.nse script take?

Ans :- maxlist

Task 12 [NSE Scripts] Searching for Scripts

Ok, so we know how to use the scripts in Nmap, but we don't yet know how to find these scripts.


We have two options for this, which should ideally be used in conjunction with each other. The first is the page on the Nmap website (mentioned in the previous task) which contains a list of all official scripts. The second is the local storage on your attacking machine. Nmap stores its scripts on Linux at /usr/share/nmap/scripts. All of the NSE scripts are stored in this directory by default -- this is where Nmap looks for scripts when you specify them.

There are two ways to search for installed scripts. One is by using the /usr/share/nmap/scripts/script.db file. Despite the extension, this isn't actually a database so much as a formatted text file containing filenames and categories for each available script.


Nmap uses this file to keep track of (and utilise) scripts for the scripting engine; however, we can also grep through it to look for scripts. For example: grep "ftp" /usr/share/nmap/scripts/script.db.


The second way to search for scripts is quite simply to use the ls command. For example, we could get the same results as in the previous screenshot by using ls -l /usr/share/nmap/scripts/*ftp*:


Note the use of asterisks (*) on either side of the search term


The same techniques can also be used to search for categories of script. For example:

grep "safe" /usr/share/nmap/scripts/script.db

Installing New Scripts

We mentioned previously that the Nmap website contains a list of scripts, so, what happens if one of these is missing in the scripts directory locally? A standard sudo apt update && sudo apt install nmap should fix this; however, it's also possible to install the scripts manually by downloading the script from Nmap (sudo wget -O /usr/share/nmap/scripts/<script-name>.nse https://svn.nmap.org/nmap/scripts/<script-name>.nse). This must then be followed up with nmap --script-updatedb, which updates the script.db file to contain the newly downloaded script.



It's worth noting that you would require the same "updatedb" command if you were to make your own NSE script and add it into Nmap -- a more than manageable task with some basic knowledge of Lua!


Search for "smb" scripts in the /usr/share/nmap/scripts/ directory using either of the demonstrated methods.



1) What is the filename of the script which determines the underlying OS of the SMB server?

Ans :- smb-os-discovery.nse


2) Read through this script. What does it depend on?
 
Ans :-  smb-brute

Task 13 Firewall Evasion

We have already seen some techniques for bypassing firewalls (think stealth scans, along with NULL, FIN and Xmas scans); however, there is another very common firewall configuration which it's imperative we know how to bypass.

Your typical Windows host will, with its default firewall, block all ICMP packets. This presents a problem: not only do we often use ping to manually establish the activity of a target, Nmap does the same thing by default. This means that Nmap will register a host with this firewall configuration as dead and not bother scanning it at all.

So, we need a way to get around this configuration. Fortunately Nmap provides an option for this: -Pn, which tells Nmap to not bother pinging the host before scanning it. This means that Nmap will always treat the target host(s) as being alive, effectively bypassing the ICMP block; however, it comes at the price of potentially taking a very long time to complete the scan (if the host really is dead then Nmap will still be checking and double checking every specified port).

It's worth noting that if you're already directly on the local network, Nmap can also use ARP requests to determine host activity.

There are a variety of other switches which Nmap considers useful for firewall evasion. We will not go through these in detail, however, they can be found here.



The following switches are of particular note:


-f:- Used to fragment the packets (i.e. split them into smaller pieces) making it less likely that the packets will be detected by a firewall or IDS.


An alternative to -f, but providing more control over the size of the packets: --mtu <number>, accepts a maximum transmission unit size to use for the packets sent. This must be a multiple of 8.


--scan-delay <time>ms:- used to add a delay between packets sent. This is very useful if the network is unstable, but also for evading any time-based firewall/IDS triggers which may be in place.
   
   
--badsum:- this is used to generate in invalid checksum for packets. Any real TCP/IP stack would drop this packet, however, firewalls may potentially respond automatically, without bothering to check the checksum of the packet. As such, this switch can be used to determine the presence of a firewall/IDS.



1) Which simple (and frequently relied upon) protocol is often blocked, requiring the use of the -Pn switch?

Ans :- ICMP



2) [Research] Which Nmap switch allows you to append an arbitrary length of random data to the end of packets?

Ans :-  --data-length

Task 14 Practical

Use what you've learnt to scan the target machine and answer the following questions!


1) Does the target (10.10.99.0)respond to ICMP (ping) requests (Y/N)?


Ans :- N


2) Perform an Xmas scan on the first 999 ports of the target -- how many ports are shown to be open or filtered?


Ans :- 999

3) There is a reason given for this -- what is it?
 
 

Ans :- No Response

4) Perform a TCP SYN scan on the first 10000 ports of the target -- how many ports are shown to be open?


Ans :- 5


5) Open Wireshark (see Cryillic's Wireshark Room for instructions) and perform a TCP Connect scan against port 80 on the target, monitoring the results. Make sure you understand what's going on.


Ans :- Noa nswer needed


6) Deploy the ftp-anon script against the box. Can Nmap login successfully to the FTP server on port 21? (Y/N)

Ans :- Y

Task 15 Conclusion

You have now completed the Further Nmap room -- hopefully you enjoyed it, and learnt something new!

There are lots of great resources for learning more about Nmap on your own. Front and center are Nmaps own (highly extensive) docs which have already been mentioned several times throughout the room. These are a superb resource, so, whilst reading through them line-by-line and learning them by rote is entirely unnecessary, it would be highly advisable to use them as a point of reference, should you need it

Disclaimer