The lab network should be regarded as a hostile environment. No sensitive information should be stored on your Kali Linux machine in the unlikely event that someone is able to gain access to it. You can help protect yourself by stopping services when they are not being used and by making sure any default passwords have been changed.
VPN Labs Overview
The following graphic is a simplified diagram of the PWK labs. You will initially connect via VPN into the Student Network and hack your way into additional networks as the course progresses. Once you have completed the course videos, you will have the basic skills required to penetrate most of the vulnerable computers in our lab. Certain machines will require additional research and a great deal of determination in order to compromise them.
Please note that the IP addresses presented in this guide (and the videos) do not necessarily reflect the IP addresses in the Offensive Security lab. Do not try to copy the examples in the lab guide verbatim; you need to adapt the examples to your specific lab configuration.
All the machines in the lab range ARE vulnerable to some type of attack/exploit. Remember that there are several vulnerable machines within this range that act as routers and lead to additional vulnerable networks. Other departments have no restricted ranges for attacking and the whole /24 network is allowed to be targeted.
If you continuously scan or attack machines which are outside your allowed lab range, you might receive a warning email from our system. Breaking the lab rules multiple times might get your VPN account temporarily disabled.
Students are not able to communicate between VPN addresses. Read the "Resources and Downloads" section in our forums as they contain important links and downloads that you will require for the course. We strongly recommend you refer to the information available in the following forum threads prior to connecting to the labs:
Lab vs Exam
Metasploit usage is encouraged in the labs. Metasploit is a great tool and you should learn all of the features it has to offer. While Metasploit usage is limited in the OSCP certification exam, you don't want to place arbitrary restrictions on yourself during the learning process. More information about Metasploit usage can be found in the forums at the link below:
Each student is provided with twelve (12) reverts every 24 hours, enabling them to return a particular lab system to its pristine state. This counter is reset every day at 00:00 GMT but should you run out early and require more, you can contact us and we will be able to reset your revert counter for you. The minimum amount of time between machine reverts is 5 minutes. Active Directory targets will take up to 10 minutes to revert. In the drop-down menu to select which machine to revert, you are able to see when the machine was last reverted. If you are attacking a machine that has not been reverted for a long period of time, it may be in an altered state. Please make sure you revert it before attacking it. However, if you notice the machine has been reverted recently, this may be because another student is working on the box. You may wish to work on another target until they have finished.
For more information about the recommended VMware Kali image to use during PWK course, please visit: Kali VM
There is no need to update the virtual machine in order to complete the course exercises; however, you are free to do so if you wish. Bear in mind that updating software may introduce new bugs or issues (especially if you have opted to use the "bleeding edge" repo). If you choose to update the VM, we strongly suggest that you create a snapshot of the VM before doing so.
The Offensive Security lab is a shared environment so please be certain to keep the following points in mind as you explore:
- Do not change user passwords. Instead, add users to the system if possible. If the only way into the machine is to change the password, then we request that you change it back once you no longer require it.
- Any firewall rules that you disable on a machine should be restored once you have gained the desired level of access.
- Do not leave machines in a non-exploitable state.
- Delete any successful and failed exploits from a machine once you are done. If possible, create a directory to store all of your exploits in first. This can help reduce the chance that someone will accidentally use your exploit against the target.
The following restrictions are strictly enforced in the network. If you continually violate any of the restrictions below, Offensive Security reserves the right to disable your lab access.
- Do not ARP spoof or conduct any other type of poisoning or man-in-the-middle attacks against the network.
- Do not delete or relocate any key system files or hints unless necessary for privilege escalation.
- Do not change the contents of the network-secret.txt or proof.txt files.
Do not intentionally disrupt other students who are working in the labs. This includes but is not limited to:
- Shutting down machines
- Kicking users off machines
- Blocking a specific IP or range
- Hacking into other students' personal clients or Kali VMs
Our lab firewall will automatically issue a temporary ban on your account as part of a defensive mechanism we have put in place if a user initiates multiple concurrent connections to the lab over a short period of time. This temporary ban will expire after 10 minutes. Please ensure that you are not logging in from multiple locations and when you disconnect from the VPN, ensure that you use the ctrl-c keyboard combination to kill the connection as simply closing the terminal may just background the connection. Please be aware that attempting to connect to the lab while the ban is in effect will reset the ban timer so you must allow for 10 minutes to pass before attempting a new connection.
Clean Up Scripts
Some of the machines in the labs will contain clean up scripts. These are used in client-side attack vectors in particular in order to help ensure that the exploit/machine remains available for use by other students.
Cloned Lab Machines
The lab you are connecting to is shared by a number of different students. We limit the number of students in each lab to reduce the possibility of more than one student working on the same target concurrently and we have a number of cloned machines for targets that are particularly popular. You are not required to gain access to both although you are free to do so. The cloned systems are indicated by the number "2" at the end of their hostname.
The IP addresses of the systems in the lab are not in any specific sequence. You should not start at 10.11.1.1 and work your way through the targets in numerical order. One of the most important skills you will need to learn as a penetration tester is to scan a number of machines and try to find the lowest hanging fruit. You may not be able to fully compromise a particular network without first moving into another.
Gaining access to some machines in the labs will first require you to gain access and/or information from other machines in the labs. Details or acknowledgement of a machine which requires a dependency will not be given out by any of the course administrators. Determining if a machine has a dependency is an important part of the information gathering process and needs to be discovered by each student individually.
A number of machines in the labs will have their firewall enabled and may not respond to ICMP packets. If an IP address does not respond to ICMP packets, this does not indicate that the target is down or does not exist.
It is not required to spend an excessive amount of time cracking the root or Administrator passwords to all systems in the lab. If you have tried all of the available wordlists in Kali and information gathered throughout the labs, then you can stop at this point, as there is another vector possible. If you have a significant amount of cracking hardware, then feel free to continue to crack as many passwords as you can.
The firewalls and networking devices that connect the networks together are not directly exploitable. Although they are in scope and you may attempt to gain access to them, they are not intentionally created for you to do so. In addition, we discourage lengthy attacks such as bruteforce- or DDOS-type attacks as it will only make the firewalls, and the networks connected to them, inaccessible for you and other students.
The proof.txt files located on machines throughout the network can be submitted on the
submit proof tab of your student Control Panel. This tab allows you to track your progress in the labs, and view the targets still remaining. Note that once a proof file is submitted, it will no longer appear in the drop down list.
These files are provided as a way to prove to yourself that you have gained access to a particular machine and should be included in your lab report as trophies. Submitting the contents of the files in the Control Panel will not contribute to your exam score or bonus points - the
submit proofs tab is entirely for your own use.
These files should be seen as "trophies" and not the end goal to reach. You should still aim to get a shell on each box with the highest level of privileges you possibly can.
The IT, Dev, and Admin networks are not directly routable from the Public network but the Public network is routable from all other networks. You will need to use various techniques to gain access to the other networks. Some of these include making use of dual-homed machines or client-side exploits.
The PWK labs contain a number of simulated clients that can be exploited using client side attacks. These clients will do things that any typical human would do in a corporate setting. There are hints and information throughout the lab that will lead you to finding the simulated clients. Doing thorough post-exploitation information gathering may provide indications that target machines are communicating with one another. The various simulated clients will perform their action at different time intervals. The most common interval is one action per minute.
Some of the machines in the labs contain scripts that will automatically restart crashed services. This is not the case for every system but should be taken into consideration when exploiting a particular target. If you believe a service should be running and/or are not getting the expected results, you can always revert the machine manually via your student control panel.
Your Personal Client machines have multiple uses while you are in the labs. You can use them for buffer overflow exercises, testing payloads, or compiling exploits. Your assigned client machines will automatically be powered off and reverted after you have been disconnected from the VPN for a period of time. You will need to power on your client machines via the student control panel whenever you connect to the VPN.
If you wish to make your remote desktop session window larger than the default setting, you can do so by the following methods:
rdesktop -g 1440x900 -u USER -p PASSWORD IP_ADDRESS
This will set the screen size to a fixed resolution of your choice.
rdesktop -g 95% -u USER -p PASSWORD IP_ADDRESS
This will set the remote desktop to automatically detect and then use 95% of the maximum size.
Once inside a session, you can press "ctrl + alt + enter" to toggle full screen mode.
LAB CONTROL PANEL
Once logged into the VPN lab, you can access your lab control panel. Through this control panel, you can manage, revert, and reset lab machines and passwords. You can access the panel using the address sent to you in your welcome email. If you encounter an SSL certificate warning, you may accept it.
Unlocking Additional Networks
Initially, the control panel will allow you to revert machines on the Student Network as well as your own dedicated personal clients. Certain vulnerable servers in the lab will contain a network-secret.txt file with an MD5 hash in it. These hashes will unlock additional networks in your control panel.
Reporting for Penetration Testing with Kali Linux
Upon completion of the course lab guide and videos, you will be conducting a full-fledged penetration test inside our VPN labs for the THINC.local domain. While reporting of the course exercises and the VPN labs is not mandatory, it might be beneficial to you as not only will you be able to refer to your own report in the near future, it might also help you achieve the OSCP certification in the event you are shy of passing by a few points after having taken the corresponding certification exam. For more information, refer to the PWK Reporting Requirements page.
The final documentation should be submitted in the format of a formal Penetration Test Report. Your report should include the results of all course exercises added as an appendix, an executive summary, and a detailed rundown of all machines. A template for this report in both a MS Word and Open Office format can be found on the PWK Reporting Requirements page.
Students opting for the OSCP certification must submit an additional exam report that deals with the certification challenge (exam) lab. The exam report and lab report should be submitted via two separate PDF documents, archived together into a 7z file. This archive must be sent to our Certification Board no more than 24 hours after the completion of the certification exam. Please note that reporting of the VPN labs and course exercises is mandatory for those students planning to claim CPE credits prior to having successfully passed the OSCP certification exam.
To deal with the volume of information gathered during a penetration test, we like to use Cherrytree, a multipurpose note-taking application, to initially document all our findings. Using an application like Cherrytree helps both in organizing the data digitally as well as mentally. When the penetration test is over, we use the interim documentation to compile the full report. Cherrytree is available in Kali Linux as an extra application and has convenient built-in features such as screen grabbing and HTML export capabilities.
It doesn't really matter which program you use for your interim documentation as long as the output is clear and easy to read. Get used to documenting your work and findings — it's the only professional way to get the job done!