We use cookies at Copenhagen School of Design and Technology
At kea.dk we use our own cookies and cookies from our partners to collect personal information about you in the form of IP addresses, interests and digital footprints to fulfil various purposes. If you accept Marketing cookies, the information will be passed on to our partners within social media, advertising and analytics. In some cases, the cooperation partner may be established in unsafe third countries.
You can opt in and out of cookies by clicking the buttons below. You can always change or withdraw your consent by clicking on the cookie icon at the bottom left of your screen.
Necessary cookies ensure that the website can function properly
The website uses cookies to secure normal and appropriate function. It can be, for example, to remember your cookie selection.
All information gathered by these cookies is anonymous.
Marketing and 3rd party cookies target their content and ads on other sites
If you accept marketing cookies, third party providers can use cookie data for targeted marketing on their own and others' platforms. Third parties can also process information about your behavior on kea.dk and our other sites and link this data with other information you have given them or which they have collected from your use of their services.
Our business partners may combine this data with other information that you have provided to them in the past or that they have collected through your use of their services. The cooperation partner may be established in unsafe third countries that do not have the same level of protection as we do.
If you agree to Marketing cookies, third parties will receive information about your browser, IP address and the pages you visit on kea.dk and our subsites.
In this course we look at pentesting. The following material will describe the process of penetration testing, and the teams who work on pentesting. Then we will have a look at some tools used during pentesting, and what the report should contain. The course ends with a quiz.
What is pentesting?
A penetration test is a process whereby the IT-systems of a company are “tested” for any known vulnerabilities. These could be related to software defects (bugs), misconfigurations, as well as policy defects. This is mostly done by having an external security company conduct this methodical test, to document the security of the systems. In many cases, the job of the pentester will replicate what a “real” hacker would do. Therefore, most of the tools and methods used during a pentest are the same tools that black hats would use.
A successful penetration test is one that tests available services and devices within scope, for known defects, misconfigurations, sensitive data exposure and makes sure to document all the findings.
How does a pentester work?
A pentester generally follows the penetration testing method. This method is based on a structured procedure that performs penetration testing step-by-step.
The penetration testing method has generally 7 steps:
Planning & Preparation
Reconnaissance
Discovery
Analyzing information and risks
Active intrusion attempts
Final analysis
Report Preparation
How does each phase work?
1. Planning & Preparation
In the first step of this model the pentester plans and prepares the strategy for the penetration test and the scope of the test. This step starts with defining the goals and objectives of the penetration testing.
The common objectives of penetration testing are:
To identify the vulnerabilities and improve the security.
To test the IT-security of the technical systems of the company by an external third party.
2. Reconnaissance
In the second step, information is gathered with passive and active reconnaissance, meaning that the pentester interacts directly with the target system/network and then collects all information on public available servers, social media, databases, etc.
3. Discovery
Afterward the pentester uses automated tools to scan target assets and discover vulnerabilities.
Types of discovery:
Network discovery - Discovery of additional systems, servers and other devices.
Host Discovery - Open ports on these devices.
Service Interrogation – Interrogates ports to discover actual services that run on them.
4. Analyzing information and risks
In this step the pentester begins to classify the discoveries, by analyzing the information and putting each discovery in a risk group.
5. Active intrusion attempts
Then the pentester starts attempting the exploit discover in an organized order.
6. Final analysis
When all attempts on the found discoveries are done, it will be followed by a final analysis of all the findings.
7. Report preparation
Then the report preparation starts with overall testing procedures, followed by an analysis of vulnerabilities and risks. Going from the high risks and critical vulnerabilities that must be prioritized by the company to the low risks that must be done but it is not urgent.
The pentesting ends up with a report, containing:
Overall summary of the penetration testing.
Details of each step and the information gathered from the test.
Details of all the vulnerabilities and risks discovered.
Details of fixing the systems.
Suggestions for future improvements of the IT-security in the company.
Could not load the video because you have not accepted functional cookies. If you load the video, you accept that cookies from Youtube will be set in your browser.
If you wish to load videos automatically, you may choose to accept functional cookies in general.
A pentesting team is sometimes referred to as a red team. Although these terms are used many times as synonyms, a red team attack can be a more extensive attack, and therefore requiring much more planning and execution time. If performed correctly a red team can effectively simulate an Advanced Persistent Threat (APT) attack. A red team also tests things like Time-To-Detect (TTD) and Time-To-Mitigate (TTM).
TTD will test the ability of the system defenders (also called the blue team) to detect an attack within a reasonable time. This includes testing whether they have the correctly implemented Intrusion Detection Systems and logging/alerting.
On the other hand, the TTM will test the defender’s ability to react to these alarms without panicking. It will also reveal how well the automated systems will react to attacks, and how long it takes to be triggered. These automated processes could include automated firewall setups, ACL lists etc.
While a pentesting is done within 1-2 weeks, and finalized with a report, a red team can be working on a single attack for months.
Another team that can be involved in penetration testing is referred to as the purple team. As the name suggests it is a combination of the blue team and the red team. The purpose of that is to close the gap between the red team and the blue team and have a team that has a very good understanding of how the attackers work, and at the same time knows how to secure the systems.
As a sidenote, a pentesting can be combined by companies with a bounty-hunting program. That encourages white hats (ethical hackers) to conduct some pentesting as well.
What are the different approaches to penetration testing?
There are different kinds of approaches to penetration tests, depending on the weaknesses they attempt to exploit.
Different approaches to penetration testing:
Black Box Penetration Testing
This is the most common penetration testing approach that is used when hiring external companies, for example during an audit. Here the pentester has very little, or no knowledge at all on the internal systems or procedures of the IT-systems to be pentested.
This would then replicate what an attacker with no prior knowledge or access to the internal system, and networks would be able to find regarding the vulnerabilities and information leakages.
White Box Penetration Testing
During white box penetration testing, the team has access to the open systems, and their belonging source-code, configurations etc. Therefore, the pentester can perform not only test against the services/devices, but can also scan the code against any code or architectural defects. This includes doing code review on specific sensitive features. This makes finding vulnerabilities much more likely, but also requires some very extensive work and expertise.
White box testing is not the most common, because of its comprehensiveness and its cost.
Gray Box Penetration Testing
In grey box pentesting, the tester has some limited knowledge, and can even have an account that can be used for performing the penetration test. This includes possibly having access to some parts of the network or being allowed to “plant” files. This means that he can do whatever the black box tester can do and much more.
Comparing the approaches
While all of the above fall within the category of pentesting, there are big differences in the use of resources required for each, and equally a big difference in price. In most cases, the black box pentesting would at most replicate a day-to-day attack. Whereas the white box pentesting being the most comprehensive and effective, but also the most expensive, could be an overkill for many companies. Therefore, a gray box test can be a golden middle way, since it combines the 2 approaches, and is still reasonably priced.
Depending on these described conditions a company can choose the penetration test that would be optimal for its demands.
Pentesting tools
This section will deal with tools for web pentesting.
One of the most used tools for doing web pentesting is called Burp. It comes in a limited community edition, and 2 editions for enterprise and professional. We will here show some of the features that are available in the community edition, and how they can be used for pentesting.
Burp can be used during multiple of the fases we mentioned before, among others: active reconnaissance, active intrusion attempt.
Here you can see it maps all the requests, links and paths that it encounters during some clicking around on kea.dk.
Interception Proxy
When working with web applications it is always useful to be able to view the content of the requests and responses being sent back and forth. You can of course do that in wireshark or many other tools. But since burp is specialized http, you can not only view the headers and payload, but also edit them, and replicate.
Here you can see a request for kea.dk, with all the generated headers. This is a request from the web-browser, intercepted by Burp. You can forward this request as is, or you could edit some of the headers, and then forward it to KEA’s web server.
The response is equally intercepted, and both header and content can again be viewed or modified and then sent back to the browser.
Burp also keeps track of all the requests that have been made during the interception.
This makes it is possible to simply, right-clicking on any of the requests and sending it to the repeater. There the request header can again be tampered before being resent to the server.
Here is an example where the employee search (https://kea.dk/find-medarbejder) request is being repeated, to test multiple of the params sent in the request, and thereafter see the response that these generate.
Intruder
In Burp you also have the possibility to do intruder attacks, where it is possible to replace certain positions in a request with placeholders. You can then specify a list that these placeholders should be replaced with. Thereby you can very easily try out posting different values, and control what the response is to these changes.
In the following example we are trying to automatically test the response when changing the value of the name to search for (in this case “hans”). A number of different attack types can be applied. In this case Sniper is used, which is useful when only dealing with one value to intrude.
Now we can provide a list of names that the tools should use, and we can click on attack. Then the tool will start sending a request with each of these names, and save the response that is coming back from the server. In this case 1296 names were loaded, therefore 1296 requests will be sent.
Here you see the partial result of this attack. You can eventually keep an eye the length returned or you can set up a keyword to match against to flag that particular request.
Keep in mind that the community edition is a bit limited in that you are only allowed to run 1 thread, and you are not able to throttle the speed, that the requests are sent in.
The social engineering toolkit is a powerful tool that enables the pentester to easily perform social engineering attacks, without a lot of technical setup.
One of the simple attacks that is easily available is the site-clone harvester. This attack can be used for phishing. The idea is that you specify the site that you would like to clone, then the SET clones it, starts a web server, and starts serving that cloned page. All you need to do now is to lure the victim into visiting your clone and entering their credentials in order for you to get them.
Here is a small demo of this attack using SET. First select “Social-Engineering Attack” (option 1)
Then select “website attack vectors”, since we are cloning a website (option 2)
Then “credential harvester” is selected, for doing the phishing attack (option 3)
Finally, we select “site cloner” to automatically clone the target site (option 2)
Now we can enter the page we would like to clone (highlighted), and then we can visit the harvesters ip-address from a browser. In this case it is just localhost. Here you can see that it has cloned the URL: https://kea-fronter.itslearning.com/. Now SET is listening to whatever the victim is posting.
When the victim posts the form, his username and password are stored by SET (highlighted), and the browser is silently redirected to the original URL that was cloned. This way the victim might not notice that his/her credentials were stolen.
Combined with fakeDNS and sslstrip/sslsplit this can be a powerful attack.
A pentesting can also leave cyberspace, and have a more physical form, such as a combination of social engineering, and sneaking around. Here small physical devices come in handy. For many years USB-Keyloggers, which can be placed hidden between the keyboard and the PC, have been used to capture user’s login information, including passwords. These can then be used by the penetration tester to elevate the attack. Other devices include rubber ducky, which looks like an innocent USB flash drive, but acts like a small keyboard, that automatically starts typing in the preprogrammed exploits as soon as it is connected.
The bash bunny takes it a step further, placing a lightweight Linux terminal in a small USB device. This device when connected can act as an HID but can also perform more advanced data exfiltration or network hijacking.
During a pentest, many other tools are used for reconnaissance, scanning, exploiting (like Nmap, Nessus, Metasploit, etc). So please refer to the other courses for some of these tools (for example https://kea.dk/e-learning/reconnaissance).
Writing the report
A penetration testing should always be documented in written form. The documentation should provide easy access to the findings during the penetrations test.
The Report should include:
Executive summary Here a summary of non-technical nature is presented. This is meant for executives, who would like to get a quick overview of how severe the findings are, and what the consequences are if not fixed. Using technical descriptions (like SQLi, XSS etc) is discouraged in this section.
Technical summary Here the audience are the technical employees. Therefore, the summary should be written in a more technical fashion. It should still be short, and used as an overview of the findings.
Assessment results
Vulnerability descriptionsHere you have the detailed descriptions of the findings. This includes the vulnerability, where it is located (server, service, url etc.), and it is eventually related to a CVE (https://cve.mitre.org/). It should preferably state the accessibility of that vulnerability as well as the severity in case it is exploited.
RecommendationsIn this section recommendations for fixing that vulnerability are stated. Normally these are not stated as “code fixes” ready to implement, since most penetration tests are done in blackbox setup. These are instead generic fixes for the specific vulnerability. For example if SQLi is found, then a recommendation would be to make sure that all sql requests go through ORM or parametrized queries.
Supporting information
Output from toolsHere you provide output from the different tools. This includes screenshots and eventual logfiles. You should here remember to redact sensitive information that your penetrations test might have exposed.
Methodology for testHere you describe the scope that was targeted (servers, services etc.). In case there were servers/services that were omitted from the penetration test it should be stated here as well, together with a reason, and an eventual mitigation. Here is also where the pentester, stated the tools/techniques that were used during the pentesting.
These tools and techniques should be described quite precisely. For example, if nmap was used for the scan then, it should be stated what version of nmap, and what options were applied to the scan. This is important to make sure that the situation can be replicated, and eventually retested after an eventual fix.
It is also recommended to make sure that the most significant findings are highlighted with strong colors, in such a way that we force the report readers eye to notice them.
One important thing to keep in mind as a pentester is that blue teams/system admins can end up being offended revealing the vulnerabilities in the pentesting report and get quite defensive. This makes it even more important to have screenshots and other program output as documentation.
There are several tools that can assist in report writing, among them is dradis in its community edition (https://dradisframework.com/ce/). The strength of using a tool like dradis, is that it automatically can import the output of several pentesting tools, and combine/pivot the results. That makes report writing much easier and more consistent than using a standard text editor.
Try to find companies that do perform pentesting. How much info do they provide on their webpages about their tools/techniques?
Exercise 2
Download and install the tool Burp (https://portswigger.net/burp). Then try to replicate the techniques in this video:
Could not load the video because you have not accepted functional cookies. If you load the video, you accept that cookies from Youtube will be set in your browser.
If you wish to load videos automatically, you may choose to accept functional cookies in general.
