Project: Penetration Testing Report

(20 Points)

SCENARIO

You have been hired as a junior security consultant and have been tasked with performing an in-house
penetration test to demonstrate your readiness to support the audit of a large corporate client that has
employed your firm’s services. Conducting a penetration test consists of 1) planning the test, 2)
preparing your test tools, 3) performing the test, 4) analyzing the data, and 5) writing up and
communicating your findings. The project will document your notional penetration test.

PROJECT OVERVIEW

Your project will be submitted in four sections. The final deliverable will include all combined sections:

 Pre-Test: Deployment of attack tools and victim host (Week 2)

 Testing (Mapping and Scanning): Mapping the target environment and conducting a
vulnerability scan (Week 4)
 Testing (Exploitation): Gaining Access through a vulnerability identified during the vuln scan
(Week 6)
 Analysis and Reporting: Communicating findings and providing mitigation recommendation
(Week 8)

SUPPORTING DETAILS

The purpose of this project is to evaluate the student’s ability to:

 Build and deploy an attack OS (Kali Linux or other similar operating system (OS))
 Configure and deploy a victim host (Metasploitable, Broken Web Apps, Mutillidae, other
exploitable OS or virtual machine (VM))
 Conduct a vulnerability scan
 Research a hardware or software vulnerability
 Discuss how the vulnerability can be exploited
 Exploit the vulnerability
 Evaluate the risk posed by this vulnerability
 Provide a recommended compensating control to mitigate the vulnerability
Students may choose to submit the project using one of two options - each option has pros and cons
that students should evaluate before making their decision.
 A) Local Lab: Requires access to a dedicated computer in which students have sufficient:
o access (continued access to the same machine for the duration of the course)
o permissions (administrative permissions to install software)
o storage (minimum of 30 GB available to the student for VM storage)
o memory (minimum of 8 GBs)
o bandwidth (downloading large VMs can take considerable time even with high-speed
Internet connections)
B) Remote Lab: Utilizes the online lab environment used to complete the weekly course
labs

PART 1 – PRE-TEST: DEPLOYMENT OF ATTACK TOOLS AND VICTIM HOST (WEEK 2)

PROJECT SECTION 1 DETAILS: The first part of your project consists of preparing and deploying
your testing tools (the attack OS) and the vulnerable host that will serve as your attack target.
Instead of requiring the use of two physical machines, we will utilize one physical machine and
we will leverage virtualization software to install a hypervisor (VirtualBox, VMware, etc.) along
with two (2) “guest” operating systems. For those new to virtualization, we are simply using
our “host OS” (Window, Mac, Linux) and installing a virtualization “software application” that
then allows us to run multiple OS’es on our “host OS” very quickly and easily. Many options
exist that provide virtualized solutions, e.g., cloud-based (Amazon Web Services, Microsoft
Azure, DigitalOcean, and many, many others) or local instances on our machines. Some
hypervisors run as the “host OS” (‘bare metal’ like VMware ESXi – common in enterprise
environments) or as hosted applications like VMware Fusion/Workstation, or Oracle VirtualBox.
First you decide which “free” virtualization software you want to install (VMware or Oracle) –
some may already have a preference, feel free to explore both options. If you are undecided,
go with VMware.
As mentioned earlier, you have two options to choose from:

OPTION 1 – LOCAL LAB

1. Virtualization Software. Choose your virtualization software (either works fine and they are both
free):
 VirtualBox:
o https://www.virtualbox.org/wiki/Downloads
 VMware Workstation Player:
o https://www.vmware.com/products/workstation-player/workstation-player-
evaluation.html
2. Attack OS/VM. Once your virtualization software is chosen, choose an attack OS to download. You
will use Kali Linux in the lab environment and would likely be the most comfortable with that.
 However, you may download any “attack OS.” Other options include: Parrot OS, BackBox,
BlackArch (advanced only – save yourself the pain and skip this one), and many others. Note: It will
be much easier to download a pre-built VM instead of the .iso image option. Additionally, the pre-
built images are specific to the virtualization software that you are using so choose accordingly.
 https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/
3. Vulnerable Target OS/VM. You will need a victim machine to target and exploit. Download a
virtual machine that you can attack. There are many options that are designed to help students
practice their skills and learn to exploit vulnerabilities in an approved, educational manner. Keep in
mind that these are inherently vulnerable and designed to be relatively easy to exploit. A
recommended best practice is to not allow other machines outside of your “virtual network” to be
able to communicate with them. There is a “NAT” network setting within your virtualization
software that helps to isolate your “lab” systems from the other devices on your local area
network. Many options exist, but here are a few:
 Metasploitable (also includes many of the ones below – the same as what is in the InfoSec labs).
There are a few versions out there – go with “Metasploitable2” - it can be downloaded from:
https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ or
https://information.rapid7.com/download-metasploitable-2017.html
 OWASP’s Broken Web Apps (includes WebGoat):
https://sourceforge.net/projects/owaspbwa/files/latest/download
 DVWA (Web Application): https://github.com/ethicalhack3r/DVWA/archive/master.zip.
 Bad Store (Web Application): https://www.vulnhub.com/entry/badstore-123,41/
 VulnHub: Many options exist here – somewhat like a “capture the flag” with near limitless
possibilities with new ones being added all of the time (Note: I would save these for after the
class project – more for fun) https://www.vulnhub.com
4. If you need additional help installing Kali, please review Kali Linux Revealed for step-by-step
instructions. There is also a course video during Week 2 that is very helpful
 https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

OPTION 2 – REMOTE LAB

The previous option is definitely a lot of fun and helps develop a better understanding of the
underlying architecture but, unfortunately, may not be a viable option for you depending on
your circumstances. Option 2 can be done without having to install any software and consists
of the student logging in to the InfoSec Learning labs to complete the project for the remainder
of the project sections. In lieu of downloading , installing and configuring software, Option 2
Part 1, requires research into an online cloud hosting provider and the deployment of a virtual
private server. This option also has some flexibility.
 Option 2A: Research and choose a cloud hosting provider and deploy a virtual private server
that you can remotely access and configure. Install any “free” operating system on the cloud
server. Typically, any Linux OS can be freely deployed without charge. Most, if not all, of the
 cloud hosting providers will require a credit card or PayPal account to verify identity and may
charge a nominal fee ($1 or more). The submission requirement for this option is to take a
screenshot of your newly created VPS with an open terminal window echoing (printing to
screen) your name and date simply to show that you created it.
 Option 2B: Research three cloud hosting providers and compare and contrast their offerings in
terms of a solution that you could use if you were to conduct your penetration testing from their
cloud services. Consider costs for computing time, storage, access, security, etc. The research
paper should be 1.5 – 2 pages in length with a minimum word count of 750 words.

PART 2 – TESTING (MAPPING AND SCANNING): MAPPING THE TARGET

ENVIRONMENT AND CONDUCTING A VULNERABILITY SCAN (WEEK 4)
PROJECT SECTION 2 DETAILS: The second part of your project has two parts. You may choose either
Project Lab Option (“Local Lab” or “Remote Lab”) below to complete the following requirements:
 Part A: Identifying the target system through network discovery using at least two network
discovery/mapping tools (e.g., Nmap, Netdiscover, Arp-scan, etc.) to identify networks and
targets. Identify what ports, services, and versions of software are running in the network
environment.
 Part B: Additionally, you will need to complete a vulnerability scan against your target host to
identify vulnerabilities that you can then use to exploit to gain administrative/root access in the
following project section

OPTION 1 – LOCAL LAB

Choose any of the tools within your chosen Attack VM (Kali, Parrot OS, etc.) to map your network
following the Part A requirements
Choose any vulnerability scanning software to download, install and configure (Open VAS, Nessus, etc.)
complete Part B. You should be able to find free “personal/home use versions).” Configure a scan to
run against your target host. If your target host is a deliberately vulnerable machine, you should find
plenty of “critical/high” vulnerabilities to choose for your attack in the following project section.

OPTION 2 – REMOTE LAB

You may choose to complete this portion of the project using the Infosec Learning Lab “Remote
and Local Exploitation.” No software downloads are required, so just configure your tools and
complete the scans. Follow the requirements in the Project Section 2 Details.
 PART 3 – EXPLOITATION: GAINING ACCESS THROUGH A VULNERABILITY
IDENTIFIED DURING THE VULN SCAN (WEEK 6)
PROJECT SECTION 3 DETAILS: The third part of your project requires you to exploit a vulnerability of
your choosing based on the previous section’s scanning. The exploit should be through a Metasploit
Module or other open-source/commercial tool or custom script/code. Select your vulnerability
carefully. You should thoroughly research your vulnerability before you start to exploit it – which is the
same process you would use in a professional capacity. The vulnerability MUST RESULT IN GAINING
SYSTEM/ROOT ACCESS on the target host. Compromised credentials (including no password or weak
password) is not a sufficient vulnerability to exploit.
During the course labs, you will have completed labs that require you to exploit a vulnerability. You
must choose an exploit that we have not done in class. I suggest doing a web search on “Metasploitable
Walkthrough” for additional ideas on Metasploit modules that could be used (if you have selected
Metasploitable as your vulnerable target), or research vulnerabilities specific to your vulnerable
framework. Keep in mind that your vulnerability should have been flagged during the vulnerability
scanning portion.

OPTION 1 – LOCAL LAB

Depending on your chosen vulnerable target host, you may have many more vulnerabilities to choose
from. I recommend that you keep it simple and stick with a vulnerability that is well documented so
there is sufficient write-ups and posts to follow. With that said, creativity and rigorous exploit research
is always welcomed and appreciated.

OPTION 2 – REMOTE LAB

Your choices are surprisingly not limited here. There are, of course, vulnerabilities in some of the web
applications that will not show up in a vulnerability scan with a tool like Nessus due to what Nessus is
actually looking at. With that said, web application vulnerabilities are a bit more complex than some of
the other software vulnerabilities that are well documented for Metasploitable. I recommend you stick
with a well-documented vulnerability.

PART 4: ANALYSIS AND REPORTING: COMMUNICATING FINDINGS AND PROVIDING

MITIGATION RECOMMENDATION (WEEK 8)
PROJECT SECTION 4 DETAILS: The fourth part of your project requires you to provide a well
written report documenting your results and reporting your findings and recommendations.
The report should include the following:
 Vulnerability Research: Research the vulnerability and discuss the specifics. What does the
software do and why does the vulnerability exist? You must explain the technical aspects of the
 vulnerability to get full credit. Remember: This is the research portion. Learn about the
vulnerability and discuss it in your own words – do not simply copy and paste.
 Vulnerability Analysis: Describe the vulnerability in terms of complexity, access, privileges
required, vulnerability scoring, etc. Reference the National Vulnerability Database (NVD)
scoring. Explore the links associated with the vulnerability in the NVD. This typically provides a
lot of high-level and low-level technical details. The difference between this section and the
vulnerability research section is that this should be specific to the implementation of the
software and the existing environment. For example, does the vulnerability exist across all
instances of this software or is it specific to a configuration or installation stack? Each
vulnerability should have a CVE and CVSS score that will help provide additional context.
 Vulnerability Exploitation: Discuss the steps that were taken for the exploitation. Please
provide the configuration of the script or the settings of the tool. To receive full credit for the
exploitation, you need to show system-level access, root-level access, or admin-level access.
 Testing Detail: You need to show elevated access. If you cannot show root (or privileged
access), choose another vulnerability. Run the following commands on the target machine once
you have fully compromised it:
o id
o hostname
o run the hostname command on the compromised machine and then re-run the
hostname command (see figure below)
o whoami
o One of the following commands: [ ifconfig ] |[ ipconfig ]
Figure 1 Evidence of Exploitation

 Risk Assessment: Use this area to discuss what the risk represents to an organization. Would it
change the risk if it were on a public-facing server as opposed to an internal server? What
happens if this exploit were successful? Assume that the vulnerable software would be installed
in a business environment, not your home lab network. Discuss the a few different risks that
would be dependent on where and how the vulnerable software would be installed across the
organization.
 Mitigation and Security Control Recommendation: Discuss how you fix this vulnerability. Can
you patch it? Are there additional security controls, protections, or sensing mechanisms that
could be installed to lessen the impact of an attack?

GUIDELINES
 The proposal document should be 7 to 10 pages, conforming to APA standards (double-spaced).
 At least two authoritative outside references are required. These should be listed on the last
page titled "References" - which does not count toward your overall page count.
 Screenshots are required for each major section - any sensitive information may be obfuscated
or redacted).
o Screenshots will be no larger than 1/4 page. The text within the screenshot should
appear readable so avoid taking “full screen” captures. Capture only the appropriate
detail. Terminal command output should be no smaller than an “equivalent” 12-point
font size (similar to the font in this document).
o Screenshots and images do not count toward the overall page count. The project may
extend into multiple pages depending on the number of screenshots
o Clear screenshots should be used. There are numerous options available to take
screenshots. Use Google, or go to https://www.take-a-screenshot.org for various
options. By no means should you take a picture with your smartphone or camera and
paste in.
 Appropriate in-text citations are required.
 This will be graded on quality of the research topic, technical demonstration/write-up, the
content quality, use of citations, grammar and sentence structure, and creativity.
 The paper is due during Week 8 of this course.
 This paper should effectively describe the vulnerability, risks and recommendation in a manner
that will allow TECHNICAL readers to understand the vulnerability, risk and mitigation. The
course material and research should provide you with the right level of technical understanding.
 Format: The paper must contain clearly labeled headings for each major section: Network
Mapping, Vulnerability Scan, Vulnerability Research, etc.

REFERENCES
 https://www.offensive-security.com/reports/penetration-testing-sample-report-2013.pdf (Links
to an external site.)
 Note: If you’ve never used Microsoft Word’s “References” feature to manage citations, please
invest some time in learning how to do this. You’ll be glad that you did.
https://support.office.com/en-ie/article/Add-a-citation-and-create-a-bibliography-
17686589-4824-4940-9c69-342c289fa2a5?ui=en-US&rs=en-IE&ad=IE
 Ensure that you cite your references in the text when you are using material from the reference.
https://owl.english.purdue.edu/owl/resource/560/18/
 GRADING RUBRIC

Final Deliverable
Category Weight % Description
Detailed discussion commensurate with the
PART 1 – PRE-TEST 10% option chosen, e.g., Local Lab build-out |
Remote lab (w/Option 2A or 2B).
Appropriate discussion and screenshots to
PART 2 – MAPPING AND document the tool usage and generated
10%
SCANNING output for the network mapping and
vulnerability scan
Appropriate discussion and screenshots to
document the tool usage and generated
output for the exploitation phase.
PART 3 – EXPLOITATION 20%
Screenshots should include post-exploitation
commands run to demonstrate system/root
access
Appropriate research and discussion,
including: vulnerability research, vulnerability
analysis, vulnerability analysis, Risk
Assessment and recommendations.
Exploitation should be written so that it could
PART 4 – ANALYSIS AND
40% be re-created with supporting evidence.
REPORTING
There must be clear evidence that the
screenshots are not simply taken from an
Internet page and that they are your own
work. A technically sound and logical
recommendation is provided and supported.
Full Credit: 2,000 words or more
Word Count 10%
Partial Credit: Less than 2,000 words
Ensure your paper is professional and
Spelling, grammar and
5% technically written using appropriate
Sentence Structure
terminology as discussed in class
Documentation and Appropriate APA citations/referenced
5%
Formatting sources and formats of characters/content.
A quality paper will meet or exceed all of the
Total 100%
above requirements.