Penetration Test Assignment
For this assignment, consider that your team is a group of consultants that offers cybersecurity penetration testing and risk assessment services. You have been retained by Humbleify.
Humbleify is a place for people who enjoy humbling to connect. Find local humbling events or just share your favorite tips and stories with others who love to humble.
Humbleify is in talks to connect their network systems with another company that has required that Humbleify undergo a penetration testing assessment as part of the negotiations. Furthermore, Humbleify is seeking cybersecurity insurance, who also requires that Humbleify undergo a cybersecurity risk assessment, including a penetration test.
Therefore, Humbleify has hired you to assess one of their public-facing webservers. In this project, the company has intentionally not given you very much background information on this asset – they would like you to see what you can find out, going in “blind.” But you are only authorized to perform an evaluation of this particular server.
Accessing the asset
The company has given you access to a vagrantbox virtual machine version of their webserver.
It is hosted on vagrantcloud as box
To launch the virtual machine, follow the instructions on https://github.com/security-assignments/pentest-humbleify.
Once you have launched the virtual machine on Kali, you will be able to access the asset at the following ip address on the
Your Kali instance’s IP address on this network is the same as it has been for
all other labs:
A power-user msfconsole-user move is to set your
LHOST not to an explicit ip
address, but rather, an interface name. You can therefore run
LHOST virbr1 wherever an lhost is required in msfconsole. Set these values
perhaps save a few more keystrokes over the course of the assignment.
You have signed the following contractual agreement with Humbleify for your penetration test assessment:
Humbleify and your esteemed consultancy hereby enter into a contractual agreement for you to carry out a vulnerability assessment of a specific Humbleify asset described below.
Your objectives are threefold:
Document vulnerabilities that you are able to successfully exploit on the server. Describe in detail what you did and what level of access you were able to obtain. If you obtain a user account with limited privileges, document whether you were able to escalate the privileges to root. Document each exploit that you are able to successfully launch.
Document potentially sensitive information that you are able to obtain from the server. These could include user files or web, database, or other server files.
For both 1 and 2 above, argue for methods that could protect the vulnerabilities and sensitive information from > exploitation.
You are hereby authorized to perform the agreed-upon vulnerability assessment of the Humbleify vagrantbox virtual machine with IP address 192.168.56.200. Your scope of engagement is exclusively limited to the single Humbleify asset.
- Access the server through any technological means available.
- Carry out activities that may crash the server.
You may not:
- Social engineer any Humbleify employees.
- Sabotage the work of any other consultancy team hired by Humbleify.
- Disclose to any other party any information discovered on the asset.
Furthermore, note the following:
- This is a vagrantbox development version of a live asset. The vagrant-standard privileged user
vagrantis present on this virtual machine, but not on the live version of the asset. Therefore, any access via the
vagrantuser is moot and out of scope.
Remember that your contract is not merely to access the asset and its sensitive information. Rather, your contract is to document all possible vulnerabilities/attack vectors.
Written Report Deliverable
You should write the report for a managerial audience, one that isn’t versed in information security concepts. In other words, you need to explain the concepts in terms that can be easily understood by managers without technical experience. If you use technical or unfamiliar terms, include a glossary of the terms used.
There is no length requirement for the report, but your report must not exceed 20 pages (not including appendices).
In writing your report, organize for impact. This means you should discuss the most serious vulnerabilities first. Further, in your description, start by describing macro-level issues and then discuss micro-level details. This practice makes it easier for a readers to quickly process your report.
You can think of this process like a pyramid, where at the top you have the one-page executive summary of your findings, and each successive section provides more granular detail. At the end of the main body of your report, the “supporting details” section should have sufficient details on how to replicate the exploits you found, including step-by-step commands run in Metasploit or other tools. This way, a manager can quickly get a sense of the report by reading the first page and then can choose to continue reading to get lower-level details.
Continuing the pyramid analogy, appendices are at the very base. Appendices are
for very technical information that would bog down the report if included in the
main body. For example, a Nessus report or detailed output from
nmap do not belong in the report because the information is too
technical for a managerial reader to process. Also, they tend to be lengthy and
would interrupt the flow of your report. Instead, refer the reader to the
appendices for very technical and lengthy information. (Do not include a Nessus report.)
Finally, whenever you show a command or output from a command in the main body of your report, use excerpts or highlighting to point out the most relevant information, and explain what you show with accompanying text. Imagine you are writing to a manager or executive who doesn’t understand security and needs you to clearly explain your findings and their implications.
Writing technical material for a managerial audience is crucial skill for information systems practitioners and managers alike – especially in information security.
Your report will be graded using the following rubric:
Starting from this report template, create your report.
Per the contract, the client will not answer most questions about the Humbleify server. However, you are welcome to ask general questions about the lab material to your friends and advisors.
This section includes tips that may not have been covered in the labs.
Tips – General
- Did your scan show that the server is running something on port 80? If so, it’s probably a web page! Try browsing to it by using kali’s firefox, and put your server’s ip address into the address bar.
You may find tools such as the following useful:
scp- one way to copy files from one computer to another, including from your server to kali. You could also use a meterpreter shell to download files if you have one.
scpcode (from Kali) – mind the dot at the end!:
scp [email protected]:/full/path/to/file/on/midterm/server .
That will open an
sshconnection to the midterm server as the specified user, and copy a file (that the user must have permission to read!) from the specified path down to the current directory (
.means ‘current directory that I’m in on Kali’).
Note that this must be run on Kali. Meaning it cannot be run from within an exploited shell on the midterm server or from within an ssh connection to the midterm server. You cannot scp a file from the midterm server to Kali, because you cannot open an ssh session from the midterm server to kali, because there is no ssh server listening on Kali.
ssh- for logging into remote servers
hydrato crack ssh logins
hyrdacan try to bruteforce ssh logins. Read the documentation for hydra’s
-eflag. For example, to try the reverse of a username of a password, you would pass
-e r. You can pass multiple values for
-e, like it shows in the documentation.
Tips – Productivity
- Put an entry for the target in Kali’s
/etc/hostsfile to make it so that you don’t have to keep typing out the IP address of humbleify’s server.
Tips – Password Cracking
- hashcat expects hashes to be fed to it in a certain format. See here for guidance for that.
- Remember that you need to tell hashcat what type of hash you are trying to
crack (with the
-mflag). It can sometimes be tricky to know what kind of hash you have. Try installing and using the package
In your experience with hashcat, you passed it a hash, and then if it cracked it, it would by default match the plaintext with the hash. For example, if I had:
user: foobar password: dogman hash: a8uf33kljufd88
Then I could ignore the username, and feed the following to hashcat:
And if it cracked it, it would output:
However, if you have several hashes you are trying to crack at once, it is convenient if hashcat also associates a hash with a username. You can do that by passing the username:hash to hashcat as follows:
… and also set the
--usernameflag in your hashcat call, so that hashcat knows that you are feeding in a prepended username.
If you do this, hashcat will output the crack thusly:
Remember that you can view cracked passwords that are saved in hashcat’s potfile by using the
hashcat --show a8uf33kljufd88
If you want to crack usernames and passwords at the same time, you can ‘unshadow’ the files first. This puts the usernames and passwords into the same file.
unshadow [passwd file] [shadow file] > myunshadowed_file
- Just like in the password-cracking lab, if you want to take a crack at hashes
/etc/shadow, you need to put them into a format that hashcat can understand. Read
man shadow, and then read
man crypt, to understand how to interpret the values in
man cryptwill also help you figure out which hash type is being used.
- You have to manually edit the unshadowed file and remove everything except
for the username and the hash. See here
(except, you can leave in the usernames, if you pass the
- You have to manually edit the unshadowed file and remove everything except for the username and the hash. See here (except, you can leave in the usernames, if you pass the