The Development of A Reconnaissance Tool Aiming To Achieve A More Efficient Information Gathering Phase of A Penetration Test

The Development of a
Reconnaissance Tool Aiming to

Achieve a More Efficient
Information Gathering Phase of a
Penetration Test
An Experimental Study
Madelen Dalseth
Thesis submitted for the degree of

Master in Informatics: Programming and System
Architecture - Information Security
60 credits
Department of Informatics
Faculty of mathematics and natural sciences
UNIVERSITY OF OSLO
Spring 2021
The Development of a
Reconnaissance Tool Aiming
to Achieve a More Efficient
Information Gathering
Phase of a Penetration Test
An Experimental Study
Madelen Dalseth
© 2021 Madelen Dalseth
The Development of a Reconnaissance Tool Aiming to Achieve a More

Efficient Information Gathering Phase of a Penetration Test
http://www.duo.uio.no/
Printed: Reprosentralen, University of Oslo

Abstract
Background. Ethical hacking is an approach whereby hackers

try to legally compromise a targeted system in order to identify
vulnerabilities. A typical feature of hacking is called a penetration test.
Today, penetration testers find that the information gathering phase of
a penetration test is too comprehensive and time-consuming. Therefore,
they have a great desire to find a solution to make this phase more
efficient.
Aim. This thesis aims to outline an approach that allows penetration

testers to execute the information gathering phase of a penetration test
more efficiently.
Method. In this thesis, I have developed a reconnaissance tool aiming

to make the information gathering phase of a penetration test more
efficient. Furthermore, I have conducted an experimental research to
examine how the newly developed tool affects this phase. After the
experiment was completed, an interview was conducted to gain insight
on how the penetration testers interpreted and understood the new
reconnaissance tool.
Results. Findings suggest that by introducing a new reconnaissance

tool in the information gathering phase of a penetration test brings
several advantages, including increased testing coverage, and less time
spent in this phase. However, the current version of the tool does not
provide all these advantages. Consequently, before being implemented
into the information gathering phase of a penetration test, the tool
needs additional refinement.
Conclusion. Implementing the developed reconnaissance tool in the

information gathering phase of a penetration test will be beneficial, but
it needs further refinement to perform optimally.
Keywords: ethical hacking, penetration test, penetration testing.
i
ii
Acknowledgements
Writing this Master’s Thesis has been both challenging and educational.
First, I want to give commendation to my supervisor, Nils Gruschka.
His valuable experience, feedback, and knowledge has been of great
help and support throughout this project, and has been a huge
contribution to how the thesis has evolved over time leading to the
currently final result.
Second, I would also like to express my thankfulness to the two
penetration testers from PwC, Nicolai Grødum and Martin Herrmann.
The company collaboration would not have been possible without their
encouragement, continuous support, and their incredible knowledge
within the field of ethical hacking and their coding skills.
Lastly, I owe deep gratitude to my family and boyfriend for their
continuous love, support, and inspiration - I would not be where I am
today without them.
iii
iv
Preface
In 2016, I enrolled into the study program called Informatics: Program-

ming and Network. During my first two years, I learned basic pro-
gramming skills and how to think as a developer. My curiosity and in-
terest for the field of informatics increased rapidly which made me take
courses covering broad areas within the field. Some of these courses
included databases, software testing, and information security. My fas-
cination for the field continued to increase. The mix of testing and in-
formation security especially caught my interest as I like to dig deep
into material to gain a thorough understanding. Therefore, I decided to
enroll the master program called Informatics: Programming and Sys-
tem Architecture with a specialization in Information Security. During
this master program I have taken a variety of security courses covering
different aspects of information security such as how to design a secure
system, network security, and security in operative systems and soft-
ware. Even so, it was the course “Ethical Hacking” which really caught
my interest and made me want to explore this discipline deeper.
v
vi
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 Information Security . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 The Five Security Terms . . . . . . . . . . . . . . . . . 6
2.2 Malicious Hacking vs. Ethical Hacking . . . . . . . . . . . . 7
2.3 Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Penetration Testing – Step by Step . . . . . . . . . . 9
2.3.2 Penetration Test vs. Vulnerability Scanning . . . . . 12
2.3.3 Internal vs. External Penetration Test . . . . . . . . 12
2.3.4 Black, White, and Grey Box Penetration Testing . . 12
2.4 The Computer Network . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 IP address, Ports, and Services . . . . . . . . . . . . . 15
2.4.3 Internet Control Message Protocol (ICMP) . . . . . 15
2.4.4 Transmission Control Protocol (TCP) . . . . . . . . . 16
2.4.5 User Datagram Protocol (UDP) . . . . . . . . . . . . . 19
2.5 Already Existing Tools . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Nmap - Network Mapper . . . . . . . . . . . . . . . . . 20
2.5.2 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.3 Burp Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.4 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Research Process 31
3.1 Conducting Research . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 My Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Define Problem and Identify Variables . . . . . . . . 31
3.2.2 Research Relevant Theory and Collect Requirements 32
3.2.3 Formulate Hypothesis . . . . . . . . . . . . . . . . . . 33
3.2.4 Requirement Analysis . . . . . . . . . . . . . . . . . . 33
vii
3.2.5 Platform Design . . . . . . . . . . . . . . . . . . . . . . 33
3.2.6 Platform Implementation . . . . . . . . . . . . . . . . 33
3.2.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.8 Reflection and Conclusion . . . . . . . . . . . . . . . . 34
4 Requirements Engineering 35
4.1 Conducting Requirements Engineering . . . . . . . . . . . . 35
4.2 Requirements Elicitation . . . . . . . . . . . . . . . . . . . . . 38
4.3 Requirements Analysis and Validation . . . . . . . . . . . . 41
4.3.1 Organizing the Requirements . . . . . . . . . . . . . . 41
4.3.2 Scenario and User Stories . . . . . . . . . . . . . . . . 45
4.4 Prioritizing the Requirements . . . . . . . . . . . . . . . . . . 48
4.5 Tracing the Requirements . . . . . . . . . . . . . . . . . . . . 48
5 Twizzlers’ System Design 51

5.1 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . 54
5.4 Use Case and Sequence Diagram . . . . . . . . . . . . . . . . 55
5.4.1 Execute Host Discovery . . . . . . . . . . . . . . . . . 56
5.4.2 Execute TCP and UDP Scan . . . . . . . . . . . . . . 57
5.4.3 Set Testing Status . . . . . . . . . . . . . . . . . . . . . 59
5.4.4 Set Vulnerability Status . . . . . . . . . . . . . . . . . 60
5.4.5 Extract Report . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Context models and Activity Diagrams . . . . . . . . . . . . 62
5.6 Data-Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Implementation of Twizzlers 69
6.1 Programming Language and Framework . . . . . . . . . . . 69
6.2 Implementation Details . . . . . . . . . . . . . . . . . . . . . . 69
6.2.1 Host Discovery . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.2 TCP and UDP Scan . . . . . . . . . . . . . . . . . . . . 71
6.2.3 Enqueue TCP and UDP Scans . . . . . . . . . . . . . 72
7 Testing 75
7.1 How To Use Twizzlers . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.1 Test Case 1: Execute Host Discovery, TCP Scan,
and UDP Scan . . . . . . . . . . . . . . . . . . . . . . . 77
7.2.2 Test Case 2: Provide Vulnerability Status on IP,
Port, and Service . . . . . . . . . . . . . . . . . . . . . . 80
7.2.3 Test Case 3: Provide Testing Status on IP, Port,
and Service . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2.4 Test Case 4: Provide Testing Status “DONE” on All
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.5 Test Case 5: Extract Report . . . . . . . . . . . . . . . 86
7.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 89
viii
8 Evaluation 91
8.1 Experimental Design . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2 Survey: Interview . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3 Conducting the Experiment and Interview . . . . . . . . . . 92
8.4 Results from Evaluation . . . . . . . . . . . . . . . . . . . . . 92
8.5 Validity of the Results . . . . . . . . . . . . . . . . . . . . . . . 93
8.5.1 Internal Validity . . . . . . . . . . . . . . . . . . . . . . 94
8.5.2 External Validity . . . . . . . . . . . . . . . . . . . . . . 95
8.6 Limitations of the Study . . . . . . . . . . . . . . . . . . . . . 96
9 Conclusion 97
9.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.1.1 Ethical Consideration . . . . . . . . . . . . . . . . . . . 98
9.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A Interview Template 107
ix
x
List of Figures
2.1 The relationship between a the five security terms.

Modified after [19]. . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Illustration of the seven layers in the OSI Model. Modified
after [41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 TCP Header. Modified after [16] . . . . . . . . . . . . . . . . . 17
2.4 The TCP 3-way handshake representing the session start-
up. Modified after [16]. . . . . . . . . . . . . . . . . . . . . . . 18
2.5 The format of the UDP Header. Modified after [3]. . . . . . 19
2.6 Default scan on the network range 127.0.0.1/24. . . . . . . 21
2.7 Scan with the T2 flag. . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Scan with the T4 flag. . . . . . . . . . . . . . . . . . . . . . . . 24
2.9 ICMP ping scan on the network range 127.0.0.1/32. . . . . 26
2.10 Service detection. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 OS detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 My research process throughout the thesis. . . . . . . . . . 32
4.1 The functional and non-functional requirements. . . . . . . 42

5.1 Block diagram showing the high-level structure of the

system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 The final high-level class diagram based on the system
requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 The entity relationship diagram. . . . . . . . . . . . . . . . . 55
5.4 A composite use case diagram. . . . . . . . . . . . . . . . . . . 56
5.5 Sequence diagram describing the execution of a host
discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.6 Sequence diagram describing the execution of a TCP scan. 59
5.7 Sequence diagram describing the process of adding a
testing status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.8 Sequence diagram describing the process of adding a
vulnerability status. . . . . . . . . . . . . . . . . . . . . . . . . 61
5.9 Sequence diagram showing the interaction when the
penetration tester is extracting a report. . . . . . . . . . . . 62
5.10 Context model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
xi
5.11 Activity diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.12 Data-flow diagram represented by a sequence diagram. . . 67
6.1 The method of executing a host discovery. . . . . . . . . . . . 70

6.2 The method of adding the results from the host discovery
in the database. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Execution of TCP and UDP scan. . . . . . . . . . . . . . . . . 72
6.4 The method of adding the results from the TCP scan in
the database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 The method of checking if a scan shall be added to the
queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6 The method of adding a TCP scan to the queue. . . . . . . . 74
7.1 The presented menu at start-up. . . . . . . . . . . . . . . . . 76

7.2 Step 1 in Test Case 1. . . . . . . . . . . . . . . . . . . . . . . . 79
7.3 Step 2 in Test Case 1. . . . . . . . . . . . . . . . . . . . . . . . 79
7.4 Step 3 in Test Case 1. . . . . . . . . . . . . . . . . . . . . . . . 79
7.5 Step 4 in Test Case 1. . . . . . . . . . . . . . . . . . . . . . . . 79
7.6 Step 5 in Test Case 1. . . . . . . . . . . . . . . . . . . . . . . . 79
7.7 The result of executing Test Case 1. . . . . . . . . . . . . . . 80
7.8 The presented vulnerability menu. . . . . . . . . . . . . . . . 81
7.9 The needed inputs from user when providing a vulnerab-
ility status on a service. . . . . . . . . . . . . . . . . . . . . . . 82
7.10 The result after executing test case 7.2 . . . . . . . . . . . . 82
7.11 The presented testing menu. . . . . . . . . . . . . . . . . . . . 83
7.12 The needed inputs from user when providing a testing
status on a service. . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.15 The summary in the scan report . . . . . . . . . . . . . . . . 88
7.16 The table in the scan report . . . . . . . . . . . . . . . . . . . 89
xii
List of Tables
4.1 Formulated user stories with associated requirements. . . 47
7.1 Test case for executing host discovery and different port
scans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2 Test case for providing a vulnerability status on one IP,
one port, and one service. . . . . . . . . . . . . . . . . . . . . . 81
7.3 Test case for providing a testing status on one IP, one port,
and one service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.4 Test case for providing the testing status “DONE” on all
services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.5 Test case for extracting the report. . . . . . . . . . . . . . . . 87
xiii
xiv
Chapter 1
Introduction
In this chapter, I will present the introduction to my master thesis.

First, I will explain the motivating scenario for this thesis, and then
present the contributions and research questions. I conclude with a
presentation of the thesis’ structure.
1.1 Motivation
In recent years, the use of electronic devices connected to the Internet
has increased rapidly. We can see it in our daily life where digital
devices have become a more central part of work, school, and personal
lives. Businesses take advantage of this by introducing more seamless
digital solutions for their customers. As a result, the customers take
advantage of these seamless digital solutions the businesses provide to
make their daily lives easier. Today, customers are just a key-stroke
away from, among other things, transferring money, checking their
account balance, and accessing their medical records. With this rapidly
growing digitalization in our society, it may be difficult as a consumer to
keep track on what kind of, how much, and where this information we
provide gets stored. With this in mind, businesses and consumers start
to worry about their computer security and the fear of being “hacked”
increases [34].
Organizations have responded by either creating a team in-house
consisting of security professionals, or hiring an external team. This
team is responsible for breaking into the organization’s computer
systems to identify existing vulnerabilities. They use the same tools and
techniques as real intruders, but they aim not to damage the system
or steal information [34]. The performance of such a security test is
called a penetration test, which consists of several steps. Some steps are
performed with automated tools, while others are performed manually.
This will be more thoroughly described in section 2.3.1, but it is
essential to mention here that there may arise some misunderstandings
when the team shall perform this kind of security test. This is because
organizations often believe that the team will do a simple scan of the
system, referred to as a vulnerability scan and based on that scan, tells
1
them which vulnerabilities they have. However, as will be shown in
section 2.3.1, the performance of a penetration test involves for more
resources than that.
1.2 Contributions
In this thesis, the contribution is mainly a Minimum Viable Product
(MVP), aiming to automate parts of the information gathering phase of
a penetration test. As a result, the penetration testing team may have
more time to perform manual testing to dig deep into the vulnerable
parts of the system identified in this initial phase.
The product to be developed is done in cooperation with Pricewa-
terhouseCoopers (PwC) Norway. PwC is a large consulting com-
pany established in 1998 with the merger between Price Waterhouse
and Coopers & Lybrand [46]. They provide services within various of
disciplines. The department of cyber security in Norway is only a few
years old, with a startup around five years ago. Even so, PwC Norway
is elected as the best cyber security department by Forrester Wave [37].
Their team within ethical hacking, called red team, provided me with
the initial case, which we together used to derive the topic of research
and problem description.
Further contributions are the knowledge gained during development
and evaluation of the product, in addition to the data and results
produced during the research process.
1.3 Research Questions

The overarching topic of the thesis is whether the current information
gathering phase of a penetration test may be carried out more
efficiently. By creating a new tool and implementing it as a part of the
information gathering phase of a penetration test, I want to determine
if there are resulting efficiencies. Based on this, the following research
questions are investigated in this thesis:
RQ1: How will a new reconnaissance tool affect time, resource

allocation and testing coverage in the information gathering
phase of a penetration test?
RQ2: What kind of functionality is needed in a new tool which

makes it beneficial for the penetration testers to apply it in their
work?
1.4 Structure of the Thesis

Chapter 2: Background provides a complete presentation of the
background literature and material I use as a foundation to address
2
my research question.
Chapter 3: Research Process outlines the research method used for

this thesis and how this methodology has been followed throughout the
project.
Chapter 4: Requirement Analysis presents the conducted process

when collecting and analyzing the requirements.
Chapter 5: Platform Design presents an overview of the architec-

tural design, including different models showing different aspects of the
system.
Chapter 6: Platform Implementation explains the chosen program-

ming language and framework used for implementation. Additionally,
the most relevant parts of the implementation are explained more in-
depth.
Chapter 7: Evaluation presents my findings from data collection and

data analysis.
Chapter 8: Conclusion summarizes and concludes the thesis as a

whole, and describes potential future work for the developed system.
3
4
Chapter 2
Background
The purpose of this chapter is to introduce information security,

how a computer network is built, and frequently used tools used in
information security. The first section aims to give the reader a brief
introduction to the most common information security terms. It is
followed by descriptions of the disciplines of hacking and ethical hacking
and an introduction to computer networks. The chapter concludes with
the most common tools for finding vulnerabilities in a system.
2.1 Information Security

Information Security aims to preserve the confidentiality, integrity and
availability (CIA) of critical assets - often referred to as “the CIA” triad.
To provide one or more of these protection types, security controls,
mechanisms, and countermeasures are implemented. The potential
vulnerabilities, risks, and threats to the asset are measured by their
potential to destruct one or more of the CIA principles [19].
The first three subsections give a further explanation of each CIA
principles. Then, the terms vulnerability, risk, and threat will be
defined as these terms often are interchanged. In addition, the terms
exposure and countermeasure will be defined to show the difference and
relationship between these five security terms. The aim is to provide
a thorough understanding of the most important terms used when
securing an information system and the relationships between them.
2.1.1 Confidentiality
Confidentiality is the first goal in the CIA-triad and helps ensure that
information is not disclosed to unauthorized persons, processes, or
units. This level of secrecy shall be kept when the information is located
on devices and systems within the network, when the information gets
transmitted, and when the information reaches its destination. There
are several ways an attacker can breach confidentiality. For instance,
the attacker can monitor the network, break encryption schemes, steal
password files, or use social engineering techniques like phishing. A
5
countermeasure to prevent these kind of attacks is to encrypt data
when it is stored and transmitted. This can be achieved by imposing
strict access control and data classification, and training the personnel
in proper data protection procedures [19].
2.1.2 Integrity
The second goal in the CIA-triad is Integrity. Integrity aims to
ensure that the accuracy and reliability of information and systems are
preserved and prevent unauthorized modification. The assets which
enforce and provide this protection type make sure that attackers
or mistakes by users do not break the integrity of systems or data.
However, if an attacker inserts a virus, logic bomb, or back door into
the system, the system’s integrity is broken. Consequently, this may
harm the integrity of the information held in the system by corruption,
malicious modification, or replacement of existing data with incorrect
data. To combat these threats, one can introduce strict access controls,
intrusion detection, and hashing [19].
2.1.3 Availability
Finally, the last goal in the CIA-triad is availability, which aims to
ensure reliable and timely access to data and resources to authorized
users. Suppose there occurs an interference in the network’s devices,
computers, or applications. In that case, they should recover quickly
and securely, so the productivity is not negatively affected. However,
ensuring availability is not so easy as it may sound. The first thing
to have in mind is that the network consists of many devices, like
servers, routers, and firewalls, which need to be up and running at all
times. Further, software consists of many components, like operating
system, anti-malware software, and applications, which need to execute
in a healthy manner. Finally, the last thing to have in mind is
the environmental aspects. Environmental aspects may include, for
instance, fire, flood, or electrical problems. These aspects will negatively
affect the organization’s operations. Based on this, it is vital for the
organization to thoroughly understand its operational environment and
its availability weaknesses in order to insert proper countermeasures
[19].
2.1.4 The Five Security Terms

As mentioned in section 2.1, the terms vulnerability, risk, and threat are
often interchanged. Additionally, the term exposure tends to be mixed
with the three terms. An important term that is used in this context, is
countermeasure. The following list will introduce a short definition on
each of the terms, and Figure 2.1 will present the relationship between
the five terms.
6
• Vulnerability: A weakness in the system allowing a threat
source to compromise the system’s security.
• Threat: Taking advantage of a vulnerability and thereby becom-

ing a danger to the system, company, or individual. The entity
that creates the threat is called a threat agent.
• Risk: The likelihood of a vulnerability being exploited by a threat

agent, and the corresponding impact this has on the business.
• Exposure: With the occurrence of a vulnerability, the organiza-

tion is exposed to possible losses and damages.
• Countermeasure: Actions taken to reduce the potential risks.

This can also be referred to as a control or safeguard [19].
Figure 2.1: The relationship between a the five security terms. Modified
after [19].
2.2 Malicious Hacking vs. Ethical Hacking

A threat agent’s key activity is hacking [47]. There are mainly two
different approaches in the discipline of hacking. The first approach,
called malicious hacking, involves compromising the system negatively
and with malicious intentions. These kinds of hackers are referred
7
to as black hat hackers. The second approach, referred to as ethical
hacking, involves using the same methods as the black hat hackers, but
with permission. Ethical hacking aims to secure the system by finding
vulnerabilities. These kind of hackers are referred to as white hat
hackers. In addition to these opposite approaches, there also exists an
approach in between. These hackers are referred to as grey hat hackers
and act as a mix of black and white hat hackers. Grey hat hackers will
try to compromise a system even if they do not have permission to do so.
However, suppose they manage to compromise the system. In that case,
they will not do any harm, but rather inform the administrators about
the vulnerability and propose solutions on how they can fix it [39].
The main differences between a black hat hacker and a white hat
hacker relate to authorization, motivation, and intent [14].
When acting as a white hat hacker, the hacker needs approval
before running any tests or attacks. This process is referred to as
authorization. After the hacker has obtained authorization, both hacker
and the client need to agree upon the scope of the test. The scope define
the targets that are authorized for the white hat hacker. White hat
hackers are obligated to respect the authorization and stay within the
scope of the test. On the other side, the black hat hacker does not face
the same constraints when attacking a system [14].
Another substantial difference between black and white hat hackers
is the motivation. A white hat hacker’s motivation lies in the foundation
of wanting to help the client to improve their security. Conversely, a
black hat hacker is often motivated by personal gain [14]. Black hat
hackers may work alone or in groups to, for instance, protest against
something or commit criminal acts. Their motivations may be different,
where some of them may involve financial gain, competitive advantage,
or to take revenge [20].
The last key difference involves the hacker’s intention for executing
an attack. A white hat hacker intends to simulate the same type of
attack as a black hat hacker by using the same tools and techniques.
As a result, the white hat hacker may determine at an early stage if
the client is vulnerable to this attack and improve the client’s security
[14, 20]. In addition, all the sensitive information the white hat hacker
obtains while compromising the client’s system, will not be shared with
anyone else than the client. On the other hand, a black hat hacker
intends is to use the obtained sensitive information as leverage for
personal gain [14].
White hat hackers often execute a typical engagement called a
network penetration test, abbreviated pentest [45]. This engagement will
be presented in the next section.
8
2.3 Penetration Testing
Penetration Testing, abbreviated pentest, is a typical ethical hacking
engagement [45]. A penetration test may be broken down in several
steps, which establish a thorough methodology for executing this kind
of security test [14]. The following subsection will present the different
steps a penetration tester executes during a penetration test. Further,
the difference between a penetration test and a vulnerability scanning
will be explained. Next, the two different execution methods of a
penetration test, referred to as internal and external, will be presented.
Finally, black, white, and grey box penetration testing will be presented.
2.3.1 Penetration Testing – Step by Step

The approaches for executing a penetration test vary from source to
source. The number of steps vary between four and seven, depending
on how thorough the penetration test is explained. I have chosen to
combine the approaches by Engebretson [14], Jaswal and Rahalkar [22],
and Weidman [48] to present the steps in a penetration test.
In Engebretson [14], the penetration test is presented with four
formal steps: reconnaissance, scanning, exploitation, and post exploit-
ation and maintaining access. In addition, this source also explains the
content and purpose of creating a final report, but does not include this
final report as one of the formal steps.
In Jaswal and Rahalkar [22], the process of a penetration test is
explained with six formal steps. These are called information gathering,
enumeration, gaining access, privilege escalation, maintaining access,
and covering tracks. This source does not include any steps regarding
creation of a contract or final report.
Weidman [48] presents the most thorough explanation of executing
a penetration test with seven formal steps. These steps include the
whole life cycle of a penetration test, from creating the contract to
the final report. This source has named the seven formal steps:
pre-engagement, information gathering, threat modeling, vulnerability
analysis, exploitation, post exploitation, and report.
Overall, Engebretson [14] and Weidman [48] explain each step more
in-depth compared to Jaswal and Rahalkar [22]. However, there exist
some linkage between the explanation of each step. For instance,
the explanation of information gathering, called reconnaissance in
Engebretson [14], presents the same substance. Engebretson [14] and
Weidman [48] also explain the different tools that may be used in this
step, which makes the explanation more thorough. This also applies to
the the step called exploitation in Engebretson [14] and Weidman [48],
and gaining access in Jaswal and Rahalkar [22].
One of the main differences is between Engebretson [14] and
Weidman [48] and involves explaining information gathering, scanning,
and vulnerability analysis. Engebretson [14] does not include port
scanning and the use of the tool Nmap as a part of the information
9
gathering step like Weidman [48] does. Instead, Engebretson [14] has
included this as a first step of the second step scanning. Further, in
the second step of the scanning step, Engebretson [14] specifies the
performance of a vulnerability scan, while Weidman [48] extracts this
as an own step.
I have chosen to use Weidman’s [48] approach supplemented by
elements discussed in Engebretson [14] and Jaswal and Rahalkar [22]
because it provides a broader explanation of a penetration test.
Pre-Engagement
In the pre-engagement step, the penetration testing team and the

client discuss and agree upon several important aspects regarding the
performance of the penetration test. This discussion and agreement
result in a contract between the two parties. The first important aspect
to agree upon is the scope. This gives the team an overview of, for
instance, which IP addresses and hosts they can use and not, and
what kind of actions they are allowed to perform. The second aspect,
discloses the testing window. This informs the testers of when they are
allowed to perform the test. For instance, the client may state that
the team can only perform the tests on Tuesdays between 20:00 and
06.00. Thirdly, the penetration testing team must retrieve the client’s
contact information. This is, so the team knows whom to contact and
how to contact - if they discover something serious. The fourth aspect
of getting clarified is the target. The team need to ensure they have the
authorization to perform a penetration test on the given target. There
may be scenarios where the company itself does not own the target, for
instance, a third party. If this is the case, it is essential to verify that the
client has formal approval from the third party to perform a penetration
test. Lastly, the parties need to discuss and agree upon the payment
terms. This includes how, when, and how much the penetration test
team will be paid. During this phase, the penetration testers should
also identify the client’s business goals for the penetration test and
understand what matters the most to them. As a result, both parties
know what to expect, and they are on the same page [48].
Information Gathering
The next step is Information Gathering. This step involves gathering

as much information about the target as possible [14]. The process of
gathering information is differentiated into two types. The first type is
called passive information gathering. This type collects the information
only through publicly available sources, like social media and search
engines. There is no direct contact with the target. Conversely,
active information gathering involves the use of specialized tools to
obtain information about the target [22]. One tool that is popular
to use in this step is a port scanner called Nmap. This tool will be
thoroughly explained in subsection 2.5.1. When performing this type
10
of information gathering, there is direct contact with the target. This
means that the firewall, the Intrusion Detection System (IDS), or the
Intrusion Prevention System (IPS) in the target network may notice
the information gathering attempt [22].
The information gathering is probably the most important step of
the whole process as the success of the penetration test depends on the
results of this step [14, 48]. This is because the more information the
penetration testers know about their target, the higher the chances that
they find the correct vulnerabilities and exploits that will work [22].
Threat Modeling
In the third step, Threat Modeling, the penetration testers use the
information gathered in the previous step to think like attackers and
develop plans of attack [48].
Vulnerability Analysis
Further, the penetration testers deliberately seek out vulnerabilities

in order to see how effective their exploit techniques are. This
is often done with the use of vulnerability scanners. To find the
vulnerabilities which have high probability of being present on the
client’s system, the vulnerability scanners utilize databases containing
known vulnerabilities and run a series of active checks. Even though
these scanners are very powerful to use, they will never replace critical
thinking. Therefore, the penetration testers will also do a manual
analysis and verify the results [48].
Exploitation
After completing all the previous steps, the penetration testers now
have a greater knowledge about the vulnerabilities in the system. This
may include, for instance, the ports that are open, what services these
ports are running, and what vulnerabilities are associated with those
services. They use this knowledge to run exploits against the discovered
vulnerabilities in an attempt to gain access to the client’s system [14,
48].
Post Exploitation
Next is the Post Exploitation step. In this step, penetration testers

will look for interesting files and gather as much information about the
targeted system as possible. In addition, the testers will aim to achieve
administrative access in the system. If the penetration testers achieve
this privilege level, they are not exposed to eviction from the system if
someone restarts the targeted system [14, 22, 48].
11
Reporting
Finally, the penetration testing team creates a report consisting of their
findings. The report includes, among other things, what the clients are
doing correctly, how the test team got access to their system, what the
test team found, and usually a proposal on how the client may fix their
problems [48].
2.3.2 Penetration Test vs. Vulnerability Scanning

When performing a vulnerability scan, the security testers use different
tools to identify potential security issues that attackers may exploit.
This scan is often a part of a penetration test. In the model presented in
section 2.3.1, the vulnerability scan is performed in step 4: Vulnerability
Analysis. Further, a penetration test goes beyond a simple vulnerability
scan by exploiting the vulnerabilities and simulating real attacks. This
way, the penetration tester gets an insight into what potential attackers
may gain after a successful attack [14, 48].
2.3.3 Internal vs. External Penetration Test

Depending on the client, the execution of a penetration test may vary.
Sometimes, the penetration testers are required to act as an insider.
This means that they act as, for instance, a malicious employee or an
attacker who successfully has breached the client’s perimeter. This type
of test is called an internal penetration test. Some clients may require
the penetration testers to simulate an attack via the Internet. This is
referred to as an external penetration test [48].
2.3.4 Black, White, and Grey Box Penetration Testing

In addition to the differences in the execution of a penetration test,
there are also differences in how thorough the test is executed. This
is differentiated by using the metaphorical expressions black box, white
box, and grey box [19].
When executing a black box penetration test, the tester does not
know the system’s internal design or any features beforehand. The
tester will gain all knowledge during the execution of the test [19]. The
advantage of this testing typically involves a more realistic approach of
how a skilled threat agent would attempt to gain access to the systems
and network [14]. Consequently, this kind of test will be best suited
for external penetration testers [19]. In addition, black box testing
is beneficial to use when the penetration testers test the company’s
incident response procedures to distinguish if their defenses can detect
and stop a targeted attack [14]. On the other hand, the disadvantages
of this approach are that there is a high probability that not all the
internal controls will be found. In addition, the penetration testing
team may unintentionally target a subsystem that is critical to daily
operations [19].
12
Compared to black box, when executing a white box penetration test,
the penetration testers receive a complete knowledge of the internal
design and all the system features before the testing starts [19]. This
approach aims to examine all the targeted system or network parts,
resulting in a complete evaluation of the system [14, 19]. This approach
may be an accurate representation of an insider threat, consequently
making it more suitable for an internal penetration test [19]. Even so, a
white box test does not reflect a realistic simulation of how most skilled
threat agents exploit networks. In addition, it does not make it possible
to test the organization’s incident response or early alert systems. By
executing a white box test, the testers do not strive to be stealthy, but
thorough [14].
Lastly, grey box testing is an approach somewhere in between
the previous two approaches. When executing a grey box test, the
penetration testing team receive some, but not all, information about
the internal system before the execution of the test starts. By receiving
some information beforehand, the team can plan their tactics toward
some areas that should be more thoroughly tested. At the same time,
by not receiving all the information, this type of testing allows the team
to discover other system features. By using this approach, the issues
with white and black box testing are mitigated [19].
2.4 The Computer Network

Alani [3] defines a computer network as a group of hosts connected
together to accomplish a certain task. A host is a device that can
communicate with a network, for instance, a computer, a server, or
a printer. The network’s purpose is to share resources between the
hosts, such as files, databases or display information on a web page.
In other words, resources is something one host possesses that can be
useful to someone else [3]. The hosts, or devices, communicate with
each other based on the rules of the given protocol. To transfer the
resources between the hosts, a protocol suite is used. This is a collection
of similar protocols working together to verify that the communication
happens appropriately. A model called Open Systems Interconnection
(OSI) describes the tasks a protocol suite performs when data moves
from one user interface to another [17]. This model is presented in the
following subsection.
2.4.1 OSI Model

The Open Systems Interconnection (OSI) model helps to visualize how
the network works on its different layers [41]. The model consists of
seven layers, where each layer has its way of handling the data. The
Protocol Data Unit (PDU) handles the type of data on each layer [3].
Each layer with its corresponding PDU is illustrated in Figure 2.2.
The two layers relevant for this thesis are the Network Layer and
13
Figure 2.2: Illustration of the seven layers in the OSI Model. Modified
after [41]
the Transport Layer. Therefore, only these two layers will be further
described.
At the Network Layer, the received data from the upper-layer
protocols gets divided into logical chunks called packets [17]. The
packets are the unit of data transmission, which makes it the PDU
[3, 17]. This layer performs routing and switching of the information
between the different networks, Local Area Networks (LANs), or
internetworks [35]. In the routing process, data moves throughout
an internetwork. An internetwork is a network consisting of several
smaller subnets. The subnets get created by placing several devices
called routers in the network. The routers select the path the data
shall take. To determine the path, the routers look at their internal
databases which are called routing tables. These tables detail which
router network interface, or port, information should be sent to reach a
specific subnet. Thus, the network layer aims to define protocols that
ensure that the data arrives at the correct destination [17].
The Transport Layer consists of protocols that ensure reliable
14
communication between the upper layers where there are no duplicates
or lost messages [17, 35]. These protocols break up messages, send them
through the subnet, and ensure correct reassemby at the receiving end
[35]. However, as we will see later in this chapter, there exist a protocol
that does not offer this reassurance.
Before introducing the protocols residing on these two network
layers, it is beneficial for the reader to gain a greater understanding of
the three terms IP address, port, and service. Therefore, the following
subsection will give the reader an explanation of these terms.
2.4.2 IP address, Ports, and Services

An IP address is a logical address that specifies where data is sent.
There are two different versions, IP version 4 (IPv4) and IP version 6
(IPv6), dependent on the IP protocol used [3, 33]. However, since IPv4
is the most widely used protocol for Internet, intranets, and private
networks throughout the world today, this IP version will be focused
on in this thesis [23]. The IPv4 address is 32-bit, divided into four 8-bit
groups that are separated with a dot, for instance 127.0.0.1 [3, 33].
Further, Shaw [41] defines a port as a way to access a networked
service on a computer. There are two different types of ports dependent
on which protocol the port uses. If the port uses the Transmission
Control Protocol (TCP) to send and receive data, the port is referred
to as a TCP port. If the port uses the User Datagram Protocol (UDP)
to send and receive data, the port is called a UDP port. Each computer
has a number of 65 535 TCP ports and 65 535 UDP ports [2].
The ports associate with a service and some services have associated
ports by default. The list of such services are long, and include Hypertext
Transfer Protocol (HTTP) which serves web pages and runs on port 80,
File Transfer Protocol (FTP) which allows file transfer and runs on port
21, and Domain Name Services (DNS) which runs on port 53 [16, 41].
To identify a port, one can add a colon after the IP address, so that the
address will look for instance like this: 127.0.0.1:80. This indicates that
the data will be sent to the IP address 127.0.0.1 and port 80 [41].
2.4.3 Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol (ICMP) resides on the Network
Layer in the OSI model [16]. This protocol is generally used for
communication between a gateway or destination host and a source
host. This communication aims to send control messages of various
sorts or signal errors. The following are the main responsibilities of
ICMP:
1. Report network errors: This may for instance include the

report of a network or a host being unreachable.
2. Report network congestion: There may be an incident where a

router or a gateway continues to receive packets even though their
15
buffers are full. As a solution, the router or gateway will send a
congestion notification to the sender.
3. Troubleshooting: This mechanism is used in the ping and trace

commands, and is executed with the use of echo request and echo
reply messages.
4. Report timeouts: If a packet’s Time To Live (TTL) reaches

zero before reaching its destination, it means that the packet is
discarded and will never reach its destination. In this case, the
router or gateway that discarded the packet will report back to
the packet’s source by using an ICMP message [3].
There exists several different ICMP services, but for this thesis
the only pertinent is the service called ping. This service is a
request/response protocol which is designed to determine if another
IP address is reachable. The one making the request sends a ping
request message to the elected IP address. Then, if the ping message
is delivered, the interface of the elected IP address will send a ping
response message to the IP address that made the request. The contents
of the first request message gets copied into the response message. This
makes it possible for the one who sent the request to be able to match
the response with the request [45].
The drawback with this protocol is that it does not provide
authentication, and therefore it is called a trusting protocol. However,
this trust may be broken in many different ways. A port scan is one of
those options [16].
2.4.4 Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP) reassures that all the data
that is sent through the network arrives at the correct destination
fully formatted [3]. The protocol is connection-oriented, meaning that a
connection must be established before the sender can transmit data to
the receiver [3, 33]. This is ensured by TCP’s 3-way handshake, which
will be explained later in this section. The protocol provides end-to-
end reliability making sure that all packets get delivered [3]. If the
delivery guarantees are not met, the connection gets terminated with
error messages [33].
The TCP protocol operates at the Transport Layer in the OSI
model, establishing a connection between the source and the destina-
tion. During this connection, the data is divided into segments at the
source and put together again at the destination. This TCP segment,
also called TCP header, consists of several fields illustrated in Figure
2.3.
The Source Port and Destination Port both contain a 16-bit port
number. The purpose of these port numbers is to identify the session
which sends data at the source host and the communicating session [3].
16
Figure 2.3: TCP Header. Modified after [16]
Both the Sequence and Acknowledgement Number fields contain

a 32-bit number [3]. This number works as a byte counter where it
keeps track of how many bytes are passed via the TCP connection.
The sender will send a sequence number to the recipient, and the
recipient will send back an acknowledgement number to the sender,
which implies that it has received all the bytes. At the very beginning
of a TCP session, the initial value of the sequence number is set.
There are two sets of sequence numbers for each session: (1) counts
the number of bytes going from Alice to Bob, (2) counts the number
of bytes going from Bob to Alice. However, there exist events where
the byte number increases without any transfer of data. Such events
can be session startup or session tear-down. The sequence and
acknowledgement number fields are the most important parts of the
TCP acknowledgement mechanism. This is because all the data
transferred via a TCP connection needs to be acknowledged by the
recipient within a particular time. Otherwise, the sender will resend
the unacknowledged data [16].
The Data Offset field indicates how long the TCP header is. To
measure the length in bytes, you take the unit of measure, which is
32-bit words, and multiply this 4-bit binary integer value by 4 [16].
Control Bits field is used to signal back and forth between the
session endpoints. The following control bits exists:
• URG: Indicates that the value in the Urgent Pointer field is

important and should be examined by the recipient.
• ACK: Specifies that the value in the Acknowledgement Number

field is important and should be examined by the recipient.
• PSH: Gives a signal to the recipient to “push” all queued input to

the application on the receiving side.
• RST: Informs to reset the connection.
17
• SYN: Notifies the recipient to synchronize to the specified Se-
quence Number which is used at the startup of the session.
• FIN: Indicates that the sender sends the segment containing the
last data. This control bit is used at the tear-down of the session
[16].
The Window Size field informs the opposite end of the TCP
connection how much memory resources that are available on your end
of the connection [16].
The Checksum field helps to ensure the integrity of the data
exchange. It is calculated as the ones-complement number of the 16-
bit pairs that make up the TCP header and the payload data that
follows. Additionally, the calculation includes some fields from the IP
header, specifically the source and target IP addresses. The checksum
is a mandatory field in TCP. It is always the sender who generates
checksum, while the recipient is the one always verifying it. In the event
of a checksum mismatch, the segment will be dropped at the receiving
end [16].
The Urgent Pointer field holds a 16-bit integer value indicating the
amount of urgent data included in the TCP header. For this value to be
noticed by the recipient, the URG control bit must be on [16].
As mentioned, before the communicating parties can begin to
transmit data to each other, a connection between the two needs to be
established. This is accomplished with TCP’s 3-way handshake. The
main parts of this handshake are the control bits SYN and ACK. Figure
2.4 illustrates this handshake, with a following explanation of each step.
Figure 2.4: The TCP 3-way handshake representing the session start-
up. Modified after [16].
1. The handshake begins with Host A sending a TCP segment with

the control bit SYN set, in addition to a random value in the
Sequence Number field, to Host B. By doing this, Host A is telling
Host B that it wants to begin a new session with Host B. This
means that, for transmissions from Host A to Host B, Host B must
synchronize the sequence number counter to the value given by
Host A.
18
2. Next, Host B will send a TCP segment having both the SYN and
ACK control bits activated back to Host A. Host B’s Acknowledge-
ment Number should contain the Sequence Number Host A sent
plus 1. This indicates that Host B has received Host A’s prior
transmission. In Host B’s Sequence Number field, Host B places a
random value. This value is used as a starting point to track how
many bytes Host B sends in Host A’s direction.
3. Finally, Host A sends a TCP segment with only the control bit
ACK activated. Host A puts the Sequence Number Host B sent,
plus 1, in its Acknowledgement Number field [16].
After completing these three steps, a connection is established and

the communicating parties may start to transfer data back and forth.
When the communicating parties want to terminate the connection, a
standard 4-step tear-down session is executed. In this tear-down session
the SYN control bit is replaced with FIN, while the ACK control bit is
still used [16].
2.4.5 User Datagram Protocol (UDP)

As opposed to TCP, the User Datagram Protocol (UDP) is a connection-
less protocol that means no connection before the transmission of data
can begin [3, 33]. As a result of this, there is a possibility that packages
may get lost and never get delivered to the recipient. In addition, it
is not certain that the state of the packet will be maintained, and in a
case with duplicated packets, these will not be removed [33]. All these
factors make this protocol somewhat unreliable [3]. However, similarly
to TCP, this protocol also operates at the Transport Layer in the OSI
model. Although, the UDP segments, also called UDP header, are some-
what simplified compared to the TCP header. The UDP header consists
of four 16-bit fields and is 8 bytes long. Figure 2.5 illustrates the UDP
header.
Figure 2.5: The format of the UDP Header. Modified after [3].
The Source Port and Destination Port fields works similarly as

they do in the TCP header [3]; the number in the former identifies the
program that sent the datagram, while the destination port identifies
the program to which the datagram is to be delivered [16].
The Length specifies the total number of bytes in this UDP segment.
This length combines the length of both the UDP header and the data.
19
Since the length of a UDP header without data is 8 bytes, the minimum
value for this field is eight [3, 16].
As in the TCP header, the Checksum helps to ensure the integrity
of the data. Also here, the source and IP addresses from the IP header
are included in the calculation. However, as a contrast, in UDP this
field is optional and it is the programmer’s decision if it shall be used or
not. If this feature is not used, the field will contain the value zero (0)
[16].
2.5 Already Existing Tools

My research on existing tools reveals that penetration testers have a
number of tools to use. One of the most popular tools is called Nmap.
This tool is used as a part of the solution of the tool to be developed.
Therefore, Nmap will be explained in a more extensively compared to
the other tools.
This subsection has two different objectives. The first objective, is
to give the reader a thorough understanding of what Nmap is, how
it works and its functionality. Secondly, this section aims to give the
reader a systematized overview over the already existing tools and their
purposes.
2.5.1 Nmap - Network Mapper

Network Mapper, famously known as Nmap, is a port scanner used to
retrieve information about a network. This information may include
the hosts available on the network, what kind of services (application
name and version) those hosts are offering, what Operating System
(OS) and OS versions they are running, and the type of packet filters
or firewalls that are in use [7]. As defined in Shaw [41], a port scanner
is a piece of software that attempts to connect to each specific target
port and see if that port is open - determining whether or not a TCP
three-way handshake can be established. The usage of Nmap is via
the command line in the terminal. Each Nmap command starts with
“nmap” followed by flags. There are many different flags, and the
result from the scanning depends on the specific flags used. The next
paragraphs will explain the flags most relevant for this thesis.
The Default Scan

When performing a port scan, you identify running services and
determine the port states on a remote host. To execute a default scan,
the minimum you need is a target. A target can be a host name, an IP
address, or a network range [7]. The latter one, can be specified in the
following three different formats:
• Specify multiple hosts: List the desired hosts to scan after each
other with a space between. For instance, to scan the IP addresses
20
127.0.0.1, 127.0.0.2, and 127.0.0.3, type the following command:
nmap 127.0.0.1 127.0.0.2 127.0.0.3 [7].
• Specify octet ranges: Use the character “-” to specify the desired
network range. To scan the IP addresses mentioned in the
previous bullet point, type the command nmap 127.0.0.1-3 in the
terminal. It is also possible to use wildcard by using the character
*. For instance, to scan from 127.0.0.0 to 127.0.0.255, type the
following expression in the terminal: nmap 127.0.0.* [7].
• Using the Classless Inter-Domain Routing (CIDR) notation:

The CIDR notation consists of an IP address and an IP or
network suffix. This IP or network suffix indicates the number
of network bits. For instance, IPv4 addresses are 32 bit, meaning
that the network suffix can be between 0 and 32. The suffixes
/8, /16, /24, and /32 are the four most common suffixes to
use. The /8 suffix indicates the netmask 255.0.0.0, the /16
suffix indicates the netmask 255.255.0.0, the /24 suffix indicates
the netmask 255.255.255.0, and the /32 suffix indicates the
netmask 255.255.255.255 [7]. This means that the CIDR notation
127.0.0.1/24 represents the 256 IP addresses from 127.0.0.1 to
127.0.0.254. Likewise, the CIDR notation 127.0.0.1/16 represents
all the IP addresses between 127.0.0-255.0-255, and the CIDR
notation 127.0.0.1/8 represents all the IP addresses between
127.0-255.0-255.0-255.
Figure 2.6: Default scan on the network range 127.0.0.1/24.
Figure 2.6 illustrates a default scan with network range using CIDR
notation as a target. The result of such a scan will show all the obtained
host information. This may include IPv4 or IPv6 address, reverse DNS
name, and interesting ports with service names. The service name is
obtained from a database distributed with Nmap. Each of the listed
ports also has a state which indicates which ports are of interest and
not for the penetration testers [7]. Nmap has the following states:
• Open: These ports are of special interest as they indicate that a

service is listening for connections on this port.
21
• Closed: Indicates that the port has received the probes, but the
conclusion is that there is no service running on this port.
• Filtered: Specifies that there were no signs that the port received
the probes and the state could not be established. In addition, it
specifies that the probes are dropped by some kind of filtering.
• Unfiltered: Apprises that the port received the probes, but a state
could not be established.
• Open/Filtered: Indicates that the port was open or filtered, but

the state could not be established.
• Closed/Filtered: Indicates that the port was closed or filtered,

but the state could not be established [7].
When running a default scan, the type of scan that gets launched
depends on the user privileges. As a privileged user Nmap will launch a
SYN Stealth Scan (-sS), and as an unprivileged user, Nmap will launch
a TCP Connect Scan (-sT). With the use of SYN Stealth Scan, raw
packets are used to send TCP packets that are specially crafted to detect
port states. This is done by using a technique known as half-open [7].
This technique addresses the TCP three-way handshake on an open port
in the following way:
1. Nmap begins with sending a TCP packet with the SYN flag to the
port.
2. Because the port is open, the port responds by sending the

SYN/ACK flag in return.
3. To finalize the connection, the OS running on the machine sends

a RST packet. This tells the port to forget about the attempted
connection. Nmap could also send this RST packet, but it does not
need to. The reason for this is that the OS running on the machine
will also receive the SYN/ACK response. This is something the
machine does not expect since it was Nmap that crafted the SYN
probe. This makes the OS responds to the unexpected SYN/ACK
with a RST packet.
By sending the RST packet as the last step, the three-way

handshake is never completed, and therefore this technique is called
half-open [27].
Alternatively, with the use of TCP Connect Scan, a high-level
connect() system call is used to retrieve information about the port
states. This means that each TCP connection is fully completed which
makes this scanning slower [7]. Compared to the SYN Stealth Scan,
which only needed three packets, this scan requires five packets. The
TCP Connect Scan begins the same way as the SYN Stealth Scan,
with the sending of SYN and SYN/ACK packets. The differences
22
between the two scan types are identified in step three where the
machine responds to the SYN/ACK packet with an ACK packet. As
a consequence, the connection is completed. Next, the port sends its
SSH banner string to the machine through the open connection. Finally,
when the host OS tells Nmap that it was a successful connection, Nmap
will terminate the connection by asking the host OS to terminate it with
a RST packet [28].
Specify Port Ranges and Optimization

As explained in 2.4.2, the TCP and UDP protocols each have 65 535
ports adding up to 131 070 ports, but by default, Nmap only scans the
1000 most popular ports. Even so, services can still be put online on any
of the 131 070 existing ports. As a result, some system administrators
and network engineers put services running on very high port numbers
to prevent getting detected by normal scans. However, when executing
port scans, it is possible to specify a specific port or the port range with
the -p flag [41]. This flag can be used in the following different formats:
• -p portnumber: This format is used when you only want to

scan one specific port [41]. For instance, if you type nmap -p 80
127.0.0.1, this will scan port 80 on the target 127.0.0.1.
• -pStartPort-EndPort: This will scan the specified range of ports.

For instance, if you type nmap -p1-443 127.0.0.1, this will scan
ports 1 to 443 on the target 127.0.0.1 [41].
• -pPort1,Port2,Port3,...,PortX: This will scan the ports specified

in the list [7]. For instance, if you type nmap -p21,53,80,443
127.0.0.1, this will only scan the ports 21, 53, 80 and 443 on the
target 127.0.0.1.
• -p-: This is a shortcut for scanning all the 65 535 ports [7, 41].
By narrowing down the number of ports to scan, the performance

will be optimized [7]. Another way to optimize the performance, is by
using the built-in timing flag. This flag is used by typing -T followed
by a number from 1-5, where 1 is the slowest and 5 is the fastest. By
default the speed of a scan is set to 3 [41].
Figure 2.7 and 2.8 illustrates the difference in speed between using
the -T2 flag and -T4 flag. We can see that when using -T2, it took
418.16 seconds to scan the 1024 first ports, but with -T4 it only took
3.28 seconds. Some people use -T2 because they are afraid of the host
crashing or they just want to be cautious, but they might not realize
how slow it actually is. By using this flag, the scan may take ten times
longer than with the default -T3 speed. So, for the cautious scanners,
it is recommended to use the default speed. However, when scanning
networks that are modern and reliable, it is recommended to use the
-T4 flag [29].
23
Figure 2.7: Scan with the T2 flag.
Figure 2.8: Scan with the T4 flag.
Host Discovery
Host discovery is usually one of the first steps during network
reconnaissance. The aim is to reduce a sometimes massive set of IP
ranges into a list of interesting or active hosts. To perform a port scan
on every single IP address is slow and generally unnecessary [30].
Further, the majority of the systems today are protected by some
traffic filtering, like firewalls. When scanning hosts protected by such
a system, the results may be incorrect due to some types of network
packets being blocked by the system’s rules. For instance, a host
may get marked as offline, but it is hidden behind a traffic filtering
system that did not permit the given requests. Nmap is an excellent to
bypass these network restrictions as it provides different ping scanning
techniques. Combining these different techniques makes it possible to
perform comprehensive scans to bypass the network restrictions [7].
When running Nmap, by default, it performs a host discovery
followed by a port scan on each host it determines online. However,
by adding the -sn flag, it skips the port scanning, and by adding the -Pn
flag it skips the host discovery [30]. There are several flags to control
the host discovery, but only the -PS, -PA, -PU, and -PE flags will be
explained for this thesis.
TCP SYN Ping Scan (-PS)

TCP SYN ping scan is a scanning technique used to probe different
ports to determine if a host is online. This scan is executed by entering
24
the command nmap -sn -PS <target> in the terminal. The -sn flag tells
Nmap to only perform host discovery and skip the port scanning phase,
while the -PS flag indicates that Nmap shall use TCP SYN ping scan.
The result is a list of hosts in the specified target [7].
When the command is executed, the following happens:
1. Nmap sends an empty TCP SYN packet to the default destination,

port 80 [7, 30]. To scan another port than port 80, it is possible to
specify the desired port in the same way as with the -p flag [30].
For instance, by typing -PS443, Nmap will send an empty TCP
SYN packet to port 443.
2. The next step depends on the port’s state. If the port’s state is
closed, the host will respond with a RST packet [7]. If the port’s
state is open, the host will execute the second step of the TCP
three-way handshake responding with a TCP SYN/ACK packet
[30]. This indicates that it is possible to establish a connection [7].
3. Finally, a RST packet is sent to reset the connection [7]. As with

the final step of the SYN Stealth Scan, it is the machine that sends
the packet to reset the connection [30].
TCP ACK Ping Scan (-PA)

The TCP ACK Ping Scan is very similar to the TCP SYN ping scan as
they both are used to check if a host is responding [7]. The difference
is that with TCP ACK ping scan, the ACK flag is sent instead of the
SYN flag [30]. This scan is done by entering the command nmap -sn
-PA <target> in the terminal, where -PA tells Nmap to use TCP ACK
ping scan. The result of this scan, is a list of hosts that responded to
the TCP ACK packets sent. When the hosts respond to the TCP ACK
packets sent, it means that the hosts are online [7].
1. Nmap sends an empty TCP ACK packet to the default destination,

port 80 [7, 30]. Just like with the TCP SYN ping scan, it is possible
to specify the desired port to scan [30].
2. There may be two different responses to this scan. If the host does
not respond to the request, it means that the host is offline. If the
host returns an RST packet, it means that the host is online and
will be listed as a result [7].
Nmap is offering both SYN and ACK ping probes to increase the
possibility to bypass firewalls. Some firewalls may have rules that block
incoming SYN packets, and in those cases, the ACK packets is helpful
as they penetrate these rules. In other cases, where the firewall has
a rule of dropping unexpected packets, a combination of both SYN and
ACK probes may be a good solution to use. This is done by specifying
both -PS and -PA in the command line [30].
25
UDP Ping Scan (-PU)
UDP Ping Scan is able to detect systems behind firewalls that have
strict TCP filtering, but has UDP exposed. This scan is done by
entering the command nmap -sn -PU <target> in the terminal, where
-PU indicates that Nmap shall use UDP ping scanning. With this scan,
Nmap determines if the target is reachable [7].
1. Nmap sends an empty UDP packet to the default destination, port

40125 [7, 30]. The reason for this uncommon port is that it is
often undesirable to send packets to open ports for this scan type.
However, if there is a desire to send the packet to another port,
this can be specified the same way as with SYN and ACK ping
scans [30].
2. Here, the response depends on the host’s availability. If the

request hits a closed port at the target, the response is a ICMP
port unreachable error. This response tells Nmap that the host
is online and available. If the response is other ICMP errors, or
there is a lack of response, it means that the host is offline and
unreachable [7, 30].
ICMP Ping Scan (-PE)

In general, ping scans are used to determine if a host is online. For this
task, the ICMP echo request messages were designed. These messages
are used by ping scan to detect the status of a host. To perform an ICMP
ping scan, enter the command nmap -sn -PE <target> in the terminal.
If there is a response from the host, a result shown in Figure 2.9 will
appear [7].
1. An ICMP echo request packet is sent to the target.
2. The expected result is a ICMP echo reply from the available hosts
[30].
Figure 2.9: ICMP ping scan on the network range 127.0.0.1/32.
Since ICMP echo requests have been around for a long time, many
hosts and firewalls block these requests. However, in addition to the
standard ICMP echo request, Nmap also supports two other ICMP ping
26
queries. These queries are the ICMP timestamp reply (-PP) and ICMP
address mark reply (-PM). By using these messages it may be possible
to bypass firewalls that only block ICMP echo requests [7, 30].
Version- and OS Detection

Nmap is recognised for providing one of the most extensive OS and
service fingerprints databases. This makes the version detection and
OS detection two very popular features of Nmap. For penetration
testers who are looking for vulnerabilities, it is very valuable to know
the platform (OS) and the exact version of a service. In addition,
fingerprinting services may reveal more information about the target,
like, for instance, specific protocol information [7].
To perform a service detection, enter nmap -sV <target> in the
terminal. The -sV flag activates service detection, which returns
additional service and version information. The result of this scan is an
additional column to the table called VERSION. This column displays
the specific service version. Additional information will be enclosed in
parentheses [7]. Figure 2.10 illustrates the result when executing the
command on the IP range 127.0.0.1/32.
Figure 2.10: Service detection.
Further, to perform an OS detection you need to run Nmap as

a privileged user and enter the command nmap -O <target> in the
terminal. The -O flag activates OS detection, which is done by using
the TCP, UDP and ICMP protocols to send several probes against open
and closed ports. This detection results in OS information presented at
the bottom of the port list [7]. This is illustrated in Figure 2.11.
The text surrounded in green in Figure 2.11 shows that Nmap
uses a naming scheme called Common Platform Enumeration
(CPE) to detect services and operating systems [7]. This scheme
is naming software applications, operating systems, and hardware
platforms in a standardized way. In addition, the naming scheme
is used to identify applications, hardware platforms, and oper-
ating systems [7, 31]. The standardized structure of a CPE
name is an URL that encodes the following seven ordered fields:
cpe:/<part>:<vendor>:<product>:<version>:<update>:<edition>:
<language>.
27
Figure 2.11: OS detection.
Not all the seven fields need to be filled, some of them can be left blank.
However, the main part of the name is the <part> field. This field may
hold one of three different values:
1. a, which stands for applications,
2. h, which stands for hardware platforms, or
3. o, which stands for operating systems [31].
If we again look at Figure 2.11, we can see that the CPE holds an o
in the <part> field, which indicates that it names an operating system.
2.5.2 Nessus
Another tool is called Nessus. Renaud Deraison first released this tool in
1998, and for the last 15 years, it is the most used vulnerability scanner
in the industry [24].
Nessus provides three essential components which makes it a
practical tool to use. First, Nessus’ foundation is a client/server model.
This means that the penetration testers are able to use their resources
for other elements while Nessus continues to run. This model also
provides scalability. With a machine that has more memory and
processing power, it is possible to run more tests simultaneously, which
decreases the scanning time. As a result, the penetration testers have
more time to perform, among other things, manual verification of the
findings, confirm the vulnerabilities manually in the event of "false
positives", and if it is necessary, interview the organization’s personnel
[38].
Secondly, Nessus provides a framework called Nessus Attack Script-
ing Language (NASL). This framework makes it possible for the penet-
ration testers to create their own plugins for vulnerability checks easily.
As a result, the penetration testers may use their expertise to create
customized vulnerability tests. For instance, if the penetration testers
perform an internal penetration test, they can create specific vulnerab-
ility tests for the unique protocols and services running in the internal
network [38].
28
Finally, Nessus are in possession of a Knowledge Base. When
running one plugin, the data obtained from this process gets stored in
the knowledge base. This makes it possible for the processes of another
plugin to use this stored data [38].
2.5.3 Burp Suite

Another tool that is popular among penetration testers is Burp Suite.
This tool is used to identify security flaws in web applications. Dafydd
Stuttard developed it under the name of PortSwigger. Today, Burp Suite
is actively developed by his company PortSwigger Ltd [40].
Burp Suite provides eight different tools. The penetration testers
choose one tool depending on the task they want to perform. For
example, if they want to scan websites for content and security
vulnerabilities, they will use a tool called scanner [8]. This section will
not detail all the tools, since it is not so relevant for this thesis.
2.5.4 Metasploit
Lastly, there is an open-source framework called Metasploit. This is a
very powerful tool used by both malicious hackers and ethical hackers to
identify vulnerabilities on networks and servers [36]. This framework
provides more than 3000 different modules to exploit different products,
applications, and platforms. As a result, this framework can be used
throughout the whole life cycle of a penetration test. This is shown by
Jaswal and Rahalkar [22] when presenting their approach for executing
a penetration test, Section 2.3.1. Even so, the framework is most useful
if it is integrated with other tools. For instance, by integrating it with
Nessus, the result from the Nessus vulnerability scan can be fed into
Metasploit which tells if the vulnerability can be exploited for real [22].
29
30
Chapter 3
Research Process
This chapter will describe the research process conducted throughout

this project. First, the research methodology I followed throughout the
entire process of conducting the thesis will be presented. Then, I will
explain how this research methodology was utilized.
3.1 Conducting Research

This research process aims to examine the effect of introducing
a new reconnaissance tool, called “Twizzlers”, in the information
gathering phase of a penetration test. To examine this effect, I will
conduct experimental research. This research methodology involves
manipulating one or more independent variables and evaluating how
this manipulation affects the dependent variable(s) [4]. The value of
the independent variable is, as the term implies, independent of other
variables in the study. This value is the cause of the effect. The value
of the dependent variable will be affected by the changes done in the
independent variable. This value is the effect of the cause [43]. The
following section will identify the dependent and independent variables
for this research process and describe how this research methodology
was conducted throughout the project.
3.2 My Process
Figure 3.1 illustrates the overall process I have been following from
start to finish of the thesis. Each circle has a distinct color and
represents a significant step in the process. The process model proposed
for experimental design is a model I have followed and conducted during
this thesis, and my research process is inspired by this process model.
3.2.1 Define Problem and Identify Variables

The first step involved to define the problem case. This was an
essential step of the process to determine what areas I wanted to
conduct the thesis on, and set the scope to narrow it down. Additionally,
31
Figure 3.1: My research process throughout the thesis.
the independent and dependent variables to be examined during the

research process were identified. In this research, the independent
variable will be the use of Twizzlers. Further, the dependent variable
will be time used in the information gathering phase, time used to
perform manually testing, and test coverage.
3.2.2 Research Relevant Theory and Collect Require-

ments
Next, I conducted a substantial literature study on the field of
information security, penetration testing, and the already existing and
used tools in the industry today. To understand how these tools work, I
also studied how the computer network are built and works. To conduct
this literature study, I read books, articles, and websites and gathered
all the knowledge I found relevant for this thesis. The gathered
knowledge are described in Chapter 2.
During this step, I also collected the system requirements for
Twizzlers. Chapter 4.2 explains the approach used to collect the
requirements.
32
3.2.3 Formulate Hypothesis
After the first two steps were completed, a great understanding of
the problem area was achieved, which was of great value when
formulating the hypotheses. Based on this understanding and the
research questions, the hypotheses are defined as followed:
• H1: By having Twizzlers automate time consuming tasks done

manually today, the time used in the information gathering phase
will be decreased.
• H2: By having Twizzlers automate time consuming tasks done

manually today, the penetration testers will gain more time to
perform manual testing.
• H3: By having Twizzlers automate scans that are executed

manually today, the testing coverage will be increased.
• H4: When Twizzlers creates a report of the findings, it gives the

penetration testers a good overview of the scanned network.
• H5: When the penetration testers have the possibility to provide a

vulnerability status, it gives them an excellent overview of which
parts of the system that are vulnerable and not.
• H6: When the penetration testers have the possibility to provide a

testing status, it gives them a good overview on what needs to be
further done.
3.2.4 Requirement Analysis

Further, I conducted a requirement analysis of the requirements
collected in the research phase of Section 3.2.2. This involved to
explain the methodology used to collect the requirements, organizing
the requirements in different groups and hierarchies, and finally to
prioritize them. This process is further described in the next chapter,
Chapter 4.
3.2.5 Platform Design

Based on the requirements collected in the second step, I designed the
tool to be developed by using different types of diagrams. These diagram
types, and how the diagrams were constructed, are further explained in
Chapter 5.
3.2.6 Platform Implementation

Based on both the requirements collected in the second step, and the
platform design designed in the previous step, I started to implement
the tool. A thorough explanation of the most relevant parts of the code
will be given in Chapter 6.
33
3.2.7 Evaluation
When I had a minimum viable product that fulfilled the collected
requirements, I began the evaluation phase. This phase was separated
in two main steps: conduct experiment and analyze and present results.
The experiment was conducted by having the penetration testers use
Twizzlers, which was complemented with an interview at the end.
After completing the experiment and the followed interview, I
obtained a lot of results which I analyzed to see if I had what I needed
to draw a conclusion and if the results were valid or not.
3.2.8 Reflection and Conclusion

The final step of my research process involved to reflect upon, evaluate,
and conclude. Furthermore, recommendations of future work are
presented.
34
Chapter 4
Requirements Engineering
The requirements of a system are a key factor in the success of

a development project. This is because, if the requirements are
formulated confusingly and incomprehensibly, the development team
will not completely understand what to develop. Consequently, the
result of the project will be negatively affected where the development
team does not develop a system that fulfills the client’s needs. On the
other side, if the requirements are formulated in a clear and distinct
manner, there will not be any uncertainties on what to develop to satisfy
the client’s needs. Therefore, it is crucial for the project’s success that
collecting and analyzing the requirements is done comprehensively and
holistically [26]. This chapter will present the process conducted when
collecting and analyzing the requirements for Twizzlers.
4.1 Conducting Requirements Engineering

In general, conducting requirements engineering is relatively similar
but partly different depending on the source. The different sources
present the process with a few variances, such as how the different
steps in the process are divided. I have chosen to compare the sources
Laplante [25], Liu [26], and Sommerville [42].
Laptane [25] presents the requirements engineering process with
the following five different activities: (1) Requirements elicita-
tion/discovery, (2) Requirements analysis and reconciliation, (3) Re-
quirements representation/modeling, (4) Requirements verification and
validation, and (5) Requirements management. Step (1) involves unveil-
ing the customer’s needs and wishes, in addition to identifying the dif-
ferent stakeholders. Laptane [25] presents numerous techniques with
great detail on how one may execute this step. Some of these techniques
are interviews, prototyping, scenarios, use cases, and user stories. Next,
step (2) comprises working with the requirements in their “raw” form.
This means that the requirements might be contradictory, inconsistent,
incomplete, vague, or meaningless. This may be avoided by using one
or several of the elicitation techniques from step (1). Further, step (3)
concerns converting the requirements into some model. Here, Laptane
35
[25] differentiate the models by the degree of formality: formal, semi-
formal, and informal. Formal models concern different mathematical
functions, semiformal models involve the use of a modeling language
such as Unified Modeling Language (UML), and informal models are
represented by using, among other things, natural language, sketches,
and flowcharts. Moreover, step (4) aims to check if the resulting require-
ments specification is a correct representation of the customer’s needs
and wishes. Finally, step (5) involves managing and tracing the require-
ments and changes in the requirements during the project.
In comparison, Liu [26] presents the requirements engineering pro-
cess with three main steps with associated sub-tasks for each step. The
first main step may be called (1) Capturing Requirements. The associ-
ated sub-tasks for this step are to (a) Identify the stakeholders for the
system, (b) Identify the requirement sources with users’ involvement, (c)
Apply a variety of data collection techniques, and (d) Use a computer-
based software tool to document and manage the requirements. Regard-
ing techniques for collecting the requirements, Liu [26] introduces the
following five techniques: user interviews, survey and questionnaire,
observation, the study of documents and reports, and study of similar
systems. The following primary step is (2) Requirements Analysis (RA)
and has four associated sub-tasks. The first sub-task is to (a) Rewrite
the original requirements. This involves rewriting the collected require-
ments into the correct format for how a requirement shall be formulated
- with the “shall” statement. The following activities comprise to (b) Or-
ganize the requirements into different categories and hierarchies and (c)
Prioritize the requirements. The last activity concerns to (d) Document
and record requirements. To conduct these activities, Liu [6] suggests
using an affinity diagram for organizing, a trade-off study to prioritize,
and some requirement management tool for documenting and record-
ing the requirements. Also, to achieve a great understanding of what
the users need, he suggests using scenarios and use cases. The third
main step is (3) Requirements Management. This step involves docu-
menting, categorizing, analyzing, tracing, and prioritizing the system
requirements into a structured database. This results in an effective
way of communicating the requirements and controlling changes to the
requirements.
Finally, Sommerville [42] presents the following three key activit-
ies in requirements engineering: (1) Requirements elicitation and ana-
lysis, (2) Requirements specification, and (3) Requirements validation.
Activity (1) has four sub-activities which creates an iterative process
where each activity gives continual feedback to other activities. This
iterative process begins with (a) Requirements discovery and under-
standing, followed by (b) Requirements classification and organization
and (c) Requirements prioritization and negotiation, and ends with a
(d) Requirements documentation. Activity (1a) involves communicating
with the stakeholders to identify their needs and wishes, and activity
(1b) groups and organize the related requirements. Further, activity
(1c) concerns resolving conflicting requirements by negotiating and pri-
36
oritize the requirements in a logical order. The last sub-activity, (d)
Requirements documentation, ensures that the requirements are doc-
umented. Sommerville [42] presents interviewing and/or observation,
ethnography, and stories and scenarios as techniques for this key activ-
ity. The next essential activity is (2) Requirements specification which
involves writing down the user and system requirements in a require-
ments document. This document is an official declaration of what the
system developers shall implement. Suggested techniques for describ-
ing user and system requirements are natural language supplemented
with suitable diagrams and tables, such as use cases, in the document.
The last essential activity is (3) Requirements validation. This activity
aims to check if the requirements reflect the system that the custom-
ers have imagined. However, Sommerville [42] argues that this activ-
ity overlaps with activity (1) as it concerns identifying problems with
the requirements. Finally, Sommerville [42] also presents the process
of requirement management, which shall begin when a draft of the re-
quirements document is available. He does not include this as one of
the critical activities of the requirements engineering process.
In conclusion, there are apparent similarities in how to conduct the
requirements engineering process. In general, all sources include dis-
covering the customer’s needs and wishes, identifying the stakehold-
ers, presenting the requirements understandably and clearly, validating
the requirements, and managing the requirements. Liu [26] and Som-
merville [42] also include organizing and prioritizing the requirements.
The differences mainly emerge in how the steps are divided, the naming
of each step, and how thorough each step and its associated techniques
are explained. Based on this, I have created a process for performing
requirements engineering which combines all three sources. This has
resulted in a process that fits more this project and involves the follow-
ing four steps: (1) Requirements elicitation, (2) Requirements analysis
and validation, (3) Prioritizing the Requirements, and (4) Tracing the
Requirements.
Identically with all three sources, the newly created process begins
with identifying the stakeholders and discover the customers needs and
wishes. The next step, called requirements analysis and validation,
involves to organizing and classifying related requirements by using
an affinity diagram suggested by Liu [26]. In addition, this step will
present scenario and user stories which was suggested as techniques
in all three sources. These two techniques provide the benefit of
achieving a great understanding of what the user needs. Additionally,
all three sources recommend the use of use case models when specifying
and analyzing the requirements. However, this modeling type is a
fundamental feature of the object-oriented modeling language called
Unified Modeling Language (UML). This language and its features
will be further introduced in Chapter 5 and consequently the use
case modeling will also be further explained there. Additionally,
Sommerville [42] argues that the use case is more useful in the system
design compared to in the requirements analysis. The reason for this
37
may be seen from two different perspectives: (1) The stakeholder’s
perspective and (2) The creation of a use case. In the perspective
of the stakeholders, they often do not understand the term use case
and do not find the model to be useful. Further, the stakeholders are
usually not interested in the details of every single system interaction.
Secondly, in the creation of a use case, the use case diagrams need to
be complemented with more detail, such as a textual description or
another UML diagram, to achieve a complete description of the user
interaction [42]. Based on this, it will be reasonable to conduct a use
case modeling in the next chapter, Chapter 5. Furthermore, when step
(2) is completed there might be identified lacks and problems in the
requirements. Therefore, just as Sommerville [42] argued, validation of
the requirements is naturally a part of this step. Next, the requirements
will be prioritized by performing a trade-off study which was also
suggested by Liu [26]. Finally, the requirements are traced throughout
the whole project. The next sections, will present how these steps were
executed in greater detail.
4.2 Requirements Elicitation

The first step accomplished was to identify the stakeholders for
Twizzlers. The penetration testing team at PwC requested the need
for this kind of tool, so naturally, they are a significant stakeholder. In
addition, other companies providing services within ethical hacking will
be seen as stakeholders for this new reconnaissance tool.
The next step involved discovering the customer’s needs and wishes.
This was accomplished by conducting several meetings with two of
the penetration testers at PwC. During these meetings, they explained
the purpose, aim, and how they imagine using the tool. Based on
this information, an iterative process of requirements suggestions and
feedback was completed.
During the first meeting with the penetration testers, they explained
that Twizzlers’ main purpose and aim was to do some basic scanning
to trigger a specific condition and then spawn off more scans on
that, resulting in a tree hierarchy that grows bigger and bigger. For
instance, running a basic Nmap scan results in identifying the open
ports (condition), then performing more scans on these open ports, and
performing even more scans on the result from the scanning of the open
ports. Finally, the results should be put in a database which is used to
generate a readable report. Based on this, the initial requirements were
the following:
• The system shall use Nmap scan.
• The system shall scan an entire range of IP addresses.
• The system shall scan after open ports.
• The system shall identify what kind of ports that are open.
38
• The system shall perform more scans on the ports that are open.
• The system shall put the results from the scan in a database.
• The system shall extract the information in the database to

generate a report in a readable format.
• The system shall make it easy to add other scanning types later
on.
In the first iteration, the requirements were reworded to be

more specific based on the feedback from the penetration testers.
Additionally, there were added more requirements to fulfill the aim of
Twizzlers. However, in the second iteration the wishes and needs for the
tool changed. The basic scanning was specified to be a host discovery on
IP ranges aiming to identify the hosts that are identified as “up” in the
network. Then, Twizzlers shall perform individual TCP and UDP port
scans on the found hosts. Further, each host, port, and service identified
during the scanning shall retrieve a testing status based on the progress
of the penetration test, and a vulnerability status. As before, all findings
from host discovery, TCP and UDP scan, in addition to the provided
testing and vulnerability statuses, shall be stored in a database used
to extract a readable report. Consequently, Twizzlers fits more its new
aim: to give the penetration testers an overview of which parts of the
system that hold the most vulnerable parts and act as a coordination
tool for managing the further process of a penetration test. In the third
iteration, the requirements were made even more specific and detailed
in collaboration with the penetration testers. The final requirements
are a result of continuous needs assessment and cooperation with the
penetration testers. The following are the final list of requirements:
1. All steps that include input by the operator should be implemented

in a way that are extendable to allow automation in future
releases.
2. The system shall have a database to insert and get results.
3. The system shall perform host discovery on IP ranges.
4. The results of the host discovery (found IPs) shall be inserted into
the database.
5. The system shall allow host discovery to be run multiple times on

the same ranges, adding new hosts to the database.
6. The host discovery method shall be configurable and tuneable for

each run, e.g. nmap parameters.
7. The system shall perform individual port scans on each of the

found IPs from the database.
8. (a) The individual port scans shall detect open TCP ports.
39
(b) The individual port scans shall detect open UDP ports.
9. (a) The individual port scans shall detect services running on

open TCP ports.
(b) The individual port scans shall detect services running on
open UDP ports.
10. The results of the individual port scans (open ports and services)
shall be inserted into the database.
11. The system shall allow individual port scans to be run multiple
times on the same IP, adding new ports/services to the database.
12. The individual port scans shall be configurable and tuneable for
13. The system shall be able to store a testing status (not checked/in-
progress/done) provided by the operator for each network, each IP,
each port, each service.
14. The system shall be able to display a calculated testing status

for each network, each IP, each port, each service.
15. The calculated status shall be based on the status set by the
operator, directly on an entity, or by the sum of the sub-
components.
16. If not directly set, the calculated testing status of a network shall
be “done” if the calculated status of all IPs in the network are
“done”.
17. If not directly set, the calculated testing status of an IP shall be

“done” if the calculated status of all ports on the IP are “done”.
18. If not directly set, the calculated testing status of a port shall be
“done” if the calculated status of all services on the port are “done”.
19. Likewise, the system shall be able to store a vulnerability status

(Vulnerable/not vulnerable) provided by the operator for each
network, each IP, each port, each service, extendable to include
full vulnerability details.
20. The system shall be able to export a testing report describing

testing coverage and vulnerabilities.
40
4.3 Requirements Analysis and Validation
This section will present and explain how the requirements have been
organized, in addition to present scenario and user stories.
4.3.1 Organizing the Requirements

Organizing the requirements involves categorizing and arranging the
requirements into different groups and hierarchies [26].
To organize the requirements, an affinity diagram was used. This
diagram aims to structure the collected requirements in a hierarchy
based on their relationship [26]. The conducted procedure to structure
the collected requirements is inspired by the procedure presented in Liu
[26].
To begin with, I wrote all the requirements on post-it notes and
began to brainstorm different ways to group them. During this process
there were two clear ways to organize them: (1) to differentiate between
the functional and non-functional requirements, and (2) to separate
them based on which functionality in the system they belong to. I began
to organize them based on functional and non-functional requirements.
The functional requirements define what the system shall do, while
the non-functional requirements define how the system shall perform
the functional requirements. The result of this process is presented in
Figure 4.1.
However, this list does not clearly show the relationship between
the requirements. To solve this problem, I further separated the
requirements based on which functionality they belong to. This resulted
in six functionality-groups which act as the “super groups”, with the
differentiation between functional and non-functional requirements as
“sub-groups”. Figures 4.2-4.4 present these six super-groups with their
belonging sub-groups. Some of the requirements fit into multiple
super-groups as they are covering several functionalities. For instance,
requirement number 4: The results of the host discovery (found
IPs) shall be inserted into the database, covers both functionalities
with regards to the database and the host discovery. Therefore, this
requirement is listed in both groups.
41
Figure 4.1: The functional and non-functional requirements.
This hierarchical structure of the requirements shows the relation-

ship between the functional and non-functional requirements. The re-
lationship presented in the Figures 4.2-4.4 can be explained in the fol-
lowing way:
• The non-functional requirement number 1 explains how all input

from the operator, functional requirement number 13 and 19, shall
42
be implemented: extendable to allow for automation in future

releases.
• The non-functional requirements number 5 and 6 explains how

the host discovery, functional requirement number 3, shall be
performed: multiple times on the same ranges while adding
new hosts to the database, in addition to being configurable and
tuneable for each run.
• The non-functional requirements number 11 and 12 explains how

the port scanning, functional requirements number 7, 8(a), 8(b),
9(a), and 9(b), shall be performed: parallel scans while adding
the new ports/services to the database, in addition to also being
configurable and tuneable for each run.
• The rest of the non-functional requirements, number 15, 16, 17

and 18, explains how the testing- and vulnerability status shall
be set. This applies to the functional requirements number 13, 14
and 19.
43
When finishing off this process, there is identified some lacks in the
non-functional requirements. The requirements does not specify how
the data shall be inserted and extracted from the database. In addition,
they do not specify how, i.e. in which format or file type, the report
shall be exported. This was deliberated with the penetration testers.
Regarding how data shall be inserted and extracted from the database,
it will be feasible to use SQL language. Moreover, the report should be
extracted by using some commonly used frameworks or standards.
44
4.3.2 Scenario and User Stories

Further, a scenario and several user stories were formulated based on
the collected requirements. The purpose of this is to acquire a greater
understanding of the penetration tester’s needs, and to describe how
the system will be used from the penetration tester’s perspective. As
a result, one gets an impression of how the system can fulfill the
penetration tester’s needs, and thereby verify the system requirements
without understanding the technical background.
As defined by Liu [26], a scenario is an informal description about
how the system will be used by users. The main focus of the scenario is
user tasks and how the system will respond to these tasks. In addition,
there are provided the information needed to describe the tasks, such as
context and environmental conditions [26]. The scenario made for this
project goes as follows:
“Jack returns to his office after completing the pre-engagement step.
The next step is to collect as much information about the client’s system
as possible, before starting on the manually testing. Therefore, he runs
Twizzlers on his computer. His aim is to identify and get an overview
of vulnerable parts in the client’s system. He begins with executing
a host discovery by entering an IP range into the entry field. If the
45
IP range is written in the correct format, Twizzlers accepts this and run
a host discovery. The results from this discovery will be saved in
the system. If the host is “up”, the system will continue with a TCP
and a UDP scan on this host. Thus, the system will ask for wanted
Nmap parameters for Jack to specify. If these are valid, the system
will execute the two scan types and put the results in the database.
Finally, Jack wants to get an overview of all the results from the
different scans, so he presses the “export report”-button. Twizzlers
retrieves all the saved results, and displays a report showing the found
vulnerabilities and how much of the client’s system that has been
tested so far.”
This scenario provides a starting point for translating the require-
ments into system functions. Because all system functions involve some
kind of action, the system functions can be derived from the scenario by
highlighting the verbs. In the provided scenario, all the key verbs and
associated nouns are highlighted. As a result, it becomes clear what
kind of action each functionality in the system shall provide. For in-
stance, by looking at the words begins, and executing a host discov-
ery, it indicates that the very first functionality the system shall provide
is a host discovery.
Moreover, a user story defines the requirements from the perspective
of the user. These stories are defined more informally than the system
requirements and have the following format: “As a <role>, I want to
<action>, so that <benefit>”. Here, the <role> indicates the end-
user interacting with the system, the <action> refers to the system’s
behavior, and the <benefit> is the desirable achievement.
Based on the collected requirements for this project, the user stories
presented in table 4.1 were formulated. These user stories express how
this system will give value to the user, and they assist in keeping the
focus on the user during the implementation of the system.
46
Requirement
User Story
Number
As a penetration tester, I want the system to have
2, 4, 10 a solution to save the results from the different
scans, so I can retrieve and analyze them later.
As a penetration tester, I want to perform a host
3 discovery on an IP-range, so I get an overview of
all hosts in that range.
As a penetration tester, I want to specify Nmap
parameters between each host discovery, so I can
6
affect what, and how, the scan shall be performed
(such as rapidity and specific ports).
As a penetration tester, I want to perform indi-
vidual TCP port scans on each host found in the
7, 8(a), 9(a) host discovery, so I can detect which ports that are
open and identify the services running on that open
TCP port.
As a penetration tester, I want to perform indi-
vidual UDP port scans on each host found in the
7, 8(b), 9(b) host discovery, so I can detect which ports that are
open and identify the services running on that open
UDP port.
As a penetration tester, I want to specify Nmap
parameters between each port scan, so I can affect
12
what, and how, the scan shall be performed (such
as rapidity and specific ports).
As a penetration tester, I want to be able to store a
testing status for each network, each IP, each port,
13 and each service, so I can mark the elements that
has not been checked, which elements that are in
progress, and which elements that are done.
As a penetration tester, I want to see the calculated
14 testing status, so I have an overview of the process
and what needs to be done.
As a penetration tester, I want to be able to store a
19 vulnerability status, so I can mark which parts of
the system that are vulnerable and not.
As a penetration tester, I want to download a report
of the test, so I get an overview of the testing
20 coverage and vulnerabilities which resides in the
system. Based on this I know where to focus the
manually testing.
Table 4.1: Formulated user stories with associated requirements.
47
4.4 Prioritizing the Requirements
To prioritize the requirements, a trade-off study was performed. A
trade-off study is an effective method to choose and prioritize the most
critical elements among a variety of alternatives [1]. There exists
various approaches to perform this method. The one used for this
project involves to rank the requirements with the range urgent, high,
normal, and low. By using these levels of rank, it intuitively signals
what needs to be done right away and what can be postponed. At the
beginning of the project the requirements was prioritized the following
way:
Priority Requirement Number

Urgent 2, 3, 4, 7, 8(a), 8(b), 9(a), 9(b), 10
High 1, 5, 6, 11, 12, 13, 14, 19, 20
Normal 15, 16, 17, 18
Low
The reasoning for this priority goes as follows: All the requirements
that are ranked to urgent involves the main parts of the system.
Without a database saving the results, a functioning host discovery and
port scan, there is no usable system. Therefore, these requirements
are number one priority to fulfill. When the functionality of these
requirements are working, there is time to tweak the functionality
and implement how these methods shall work. Additionally, the new
functionality requirements 13, 14, 19, and 20 provides are of high
importance to the system due to the system’s aim: give the penetration
testers an overview of where the most vulnerable parts of the system
lies and how much of the system that is tested. Finally, when this new
functionality operates properly, the remaining requirements detailing
how the functionality shall work may be implemented.
The priority rank of each requirement was changing continuously
throughout the project. When one, or several, of the higher ranked
requirement(s) got fulfilled, naturally one, or several, of the lower
ranked requirement(s) retrieved a higher rank. For instance, when all
the requirements ranked to urgent was completed, requirement number
1, 6, and 11 was pushed up from high priority to urgent priority. This
was a continuous process and happened to all the requirements during
the whole thesis.
4.5 Tracing the Requirements

Throughout the project, the requirements have been traced by using a
management tool to create a list of all the requirements with associated
tasks, check boxes, and priority status. Whenever a task is considered
done, the check box gets ticked off. When all tasks associated to
the requirement are done and ticked off, the requirement itself are
considered achieved and also gets ticked off.
48
Tracing the requirements this way, results in maintaining a good
overview of the project at all times. It clearly shows what needs to be
done, the tasks in progress, and the finished tasks. In addition, the
integrity of the requirements is retained throughout the system’s life
cycle.
49
50
Chapter 5
Twizzlers’ System Design
Rasmussen [6] defines a system as an integrated set of components that

accomplish a defined objective. Further, system design is a process that
involves defining and modeling the complex interactions between the
system’s components [6]. The models developed during this process
are abstracted models which present different views and perspectives
of the system. Only the system’s main characteristics are included in
the models, whereas small details are intentionally left out to make
them more comprehensible. The purpose of system modeling concerns
three different aspects of the development phase: (1) The models are
used during the requirement analysis process to obtain the system’s
requirement in detail, (2) In the design process, the models are helpful
when describing the system to the developers who shall implement the
system, and (3) When implementation is finished, the models are used
to document the structure and operation of the system [42].
A system is usually modeled by using different graphical notations
from the Unified Modeling Language (UML). This has become the
standard language for object-oriented modeling, and therefore is the
chosen modeling language used for system’s design in this thesis.
UML offers 13 different diagram types, making it possible to create
a bunch of different system models. Even so, this thesis will focus
on the five diagram types shown to be most popular to use for
representing the essential parts of a system [42]. This chapter will
present these five diagram types, and explain how each diagram is
used to model the different aspects of the system. Additionally, entity
relationship modeling will show a high-level view of the database
before implementation starts. This allows certainty to capture the
tables needed and the different elements required in each table before
implementing the database. However, first and foremost, an overview
of the system’s architecture will be presented.
5.1 Architectural Design

The first step in designing the system is to develop a high-level
model of the system’s architecture. This model identifies the system’s
51
main structural components and shows the relationship between them,
aiming to give an overview of how these components are organized [42].
To create an architectural model of the system to be developed,
a diagram called block diagram is used. This model shows the
system’s structure in a high-level fashion, excluding all details. The
main advantage of this model concerns the communication with
the stakeholders. As such, a simplified, intuitive presentation of
the system may be readable and understandable for people from
different disciplines. Consequently, the software engineers and the
stakeholders may relate to the model and achieve good discussions
concerning the system. However, it may be argued that these
diagrams are not sufficient for representing the architectural design
due to a lack of details, such as identifying the relationship type
between the system components and the external properties of the
components. These contradictions result in two different ways to
use the architectural model: (1) To achieve good communication
with the stakeholders leading to informative discussions where all
participants are on the same page, and (2) To use the added detail
to gain a greater understanding for evolving the system. The latter,
which concerns developing the architectural model in detail by using
various architectural description languages, is an expensive and time-
consuming process. There is uncertain how cost-effective this approach
is, and therefore this approach is not extensively used [42]. Based on
this, this thesis will stick to using the less detailed block diagram.
Figure 5.1: Block diagram showing the high-level structure of the

system.
Figure 5.1 shows the high-level structure of the system to be

developed. In this system, the penetration tester will interact with the
Twizzlers. This new tool uses Nmap to perform the different kind of
scans on a target. Additionally, Twizzlers has a database to insert and
extract the results retrieved from the scanning process.
52
5.2 Class Diagram
A class diagram is a structural model that shows how a system is

organized regarding the different components in the system and their
relationship. Class diagrams show the system’s classes and how these
classes are associated [42].
When creating a class diagram for the system to be developed, the

first step was to look at the requirements and identify essential objects.
As stated in the requirements, the system shall execute some different
scans: Host Discovery, TCP scan, and UDP scan, in addition to setting
a status on each element of the result from the scanning and create
a report. This results in the five objects: (1) Host Discovery, (2) TCP
scan, (3) UDP scan, (4) Status, and (5) Report. These five objects are
represented in different squares as a class.
Further, the relationship between the classes needs to be illustrated.

This was done by again studying the requirements. The requirements
also express that all the different types of scans shall run the specific
type of scan, add the results from the scan to a database, and retrieve
parameters from the penetration tester between each scan. As a result,
a superclass called “Scan” was appended to the diagram containing
methods to address these functions. Then, the three classes Host
Discovery, TCP scan, and UDP scan, may inherit these methods
from the superclass, which makes them the sub-classes. This is shown
in the class diagram with an arrow from the sub-classes pointing up
to the superclass. Additionally, there exists an association between the
superclass and the two classes Status and Report. This is displayed
in the class diagram with a solid line between the classes. This solid
line also has a name indicating the type of relationship. For each
association, it is also specified the number of objects involved. The
association between the scan-class and the report-class is annotated
with 1 and (1..*). This means that precisely one report is made, but this
report may contain one or several scans. Also, the association between
the scan-class and the status-class is annotated with (1..5) and (1..*).
This means that there may be one to five different types of statuses
that may be applied on one or several scans. The five different statuses
are specified in the requirements and are not checked, in-progress, done,
vulnerable, and not vulnerable. The first three statuses apply to the
testing status, and the two last statuses apply to the vulnerability
status. As a result, the status-class is altered to be a superclass with
“Testing status” and “Vulnerability status” as the corresponding
sub-classes. Just like the different scanning types, this is illustrated
in the diagram with an arrow pointing from the two sub-classes up to
the superclass. Based on this, the resulting class diagram for Twizzlers
is shown in Figure 5.2.
53
Figure 5.2: The final high-level class diagram based on the system
requirements.
A class diagram can be expressed in different levels of detail

dependent on how far one has come in the development process
[42]. Figure 5.2 expresses the class diagram in a relatively high-level
fashion with not many details. When the implementation phase is
completed, this class diagram will be extended with class attributes,
several methods, and different implementation decisions, may result
in new classes, interfaces, or abstract classes. Nevertheless, this
high-level class diagram is very useful to begin, and use during, the
implementation phase as it is presenting a well-organized structure of
the main classes and its relationships.
5.3 Entity Relationship Diagram

To show a proposal on how the database may be structured, and
the relationship between the entities in the database, an Entity
Relationship Diagram (ERD) is used. This diagram contains three
main components: (1) Entities, (2) Attributes, and (3) Relationships. An
entity is referred to as a “thing”, like an object or event, that can have
data stored about it. An attribute is a property or characteristic of an
entity, and the relationship illustrates how the entities are associated
[13].
The entity relationship diagram for Twizzlers is shown in Figure
5.3. This diagram contains two different entities: (1) The scan itself,
and (2) The result from the scan. The former contains three attributes:
name, IP address, and status. The purpose of the name is to specify
the type of scan (TCP or UDP), and the purpose of the IP address is
to specify which host the scan is operating on. The status of the scan
may be planned, running, or done. Furthermore, the result from the
scan contains the following attributes: IP address, port, protocol, state,
and service. Additionally, it contains a vulnerability status and testing
status for each IP address, port, and service, resulting in 11 attributes.
However, for simplicity, the vulnerability status and testing status are
only listed once in Figure 5.3. The top three attributes are underlined
to specify that these together form the primary key. This means that
54
these three attributes need to be unique for each entity set, and that
only the combination of these attributes can sufficiently identify a tuple
(row) in the table. Finally, the relationship between these two entities
may be interpreted as follows: a scan may result in several results, but
the result comes from one specific scan.
Figure 5.3: The entity relationship diagram.
5.4 Use Case and Sequence Diagram
Use Case and Sequence Diagram are both a type of interaction modeling.
The former describes the interaction between a user and a system
using a graphical model complemented by additional information. The
graphical model identifies the actor involved in the interaction and
specifies the type of interaction. The actor may be human or other
systems and are represented as stick figures. The type of interaction
is represented in a named ellipse. To connect the actor with the
interaction, there are drawn lines between them. Each interaction has
its own use case diagram, but if the numbers of interactions between an
actor is not too high, there may be possible to collect several use cases in
one diagram. This is called a composite use case diagram. The graphical
model is complemented by writing a textual description or using other
graphical models, like a sequence diagram. A sequence diagram shows
the sequence of interactions that happen during a specific use case. This
is modeled by representing the objects and actors at the top with dotted
lines drawn vertically. On these dotted lines, some rectangles indicate
the lifeline of the object. This means the time the object instance is
a part of the computation. The interactions between the actors and
objects are illustrated with named arrows, where the name indicates
calls to the objects, their parameters, and return values. If calls to
the object lead to different outcomes, this is represented with a box
called alt. This box shows the different outcomes in square brackets,
and the alternative interaction options are separated by a dotted line.
The diagram is read from top to bottom [42].
55
For the system developed in
this thesis, there is one main actor:
the penetration tester. When look-
ing at the system requirements, it
is clear that the penetration tester
has six possible scenarios where it
interacts with the system: (1) To
execute a host discovery, (2) To ex-
ecute a TCP scan, (3) To execute a
UDP scan, (4) To provide a testing
status, (5) To provide a vulnerab-
ility status, and (6) To extract the
report of the scanning. Based on
this, a composite use case diagram
was created. This diagram is illus-
trated in Figure 5.4.
Further, five sequence dia-
grams were made to achieve the
complete description of the inter-
action illustrated in the compos-
ite use case diagram. The reason-
ing for only making five, and not
six, is further explained in subsec- Figure 5.4: A composite use case
tion 5.4.2. The following five sub- diagram.
sections will present the different
sequence diagrams developed for
each use case with a description of how to interpret the diagram.
5.4.1 Execute Host Discovery

The first sequence diagram addresses the interaction between the
penetration tester and the system when executing a host discovery.
Figure 5.5 illustrates this diagram and may be read as follows:
1. The penetration tester supplies an IP-range to the instance HD of

the HostDiscovery object class.
2. The instance HD calls the penetration tester to get the wanted

Nmap parameters.
3. The penetration tester supplies and returns the Nmap parameters

to be included in this scan.
4. If the parameters are invalid, the instance HD will return an error

message to the user. If the parameters are valid, the instance HD
will run a host discovery on the given IP with the specified Nmap
parameters.
5. Then, the instance HD calls the database, supplying the ScanRes-

ult, to parse the results from the scan.
56
6. If one of the host’s in the database is up, this host needs to be
further scanned. Therefore, an instance of a TCP and a UDP scan
with the open host will be created.
7. Eventually, the result from the host discovery scan will be

returned and displayed to the penetration tester. If all the host’s
in the database are down, the result from the host discovery scan
will be returned and shown to the penetration tester right away.
The IP-range is the stimulus added to begin this process. Based on

this, the precondition for this use case, is that the penetration tester
has an IP-range ready to write as input to the system, and the system
is ready to retrieve some input from the user. The data created in this
process is the results from the host discovery, and the system’s response
is these results shown to the penetration tester.
Figure 5.5: Sequence diagram describing the execution of a host

discovery.
5.4.2 Execute TCP and UDP Scan

The second diagram shows the interaction between the penetration
tester and the system when executing a TCP scan. This is illustrated in
Figure 5.6 and may be read as follows:
57
1. To begin with, the instance TCP of the TCPScan object class calls
the database to return the IP-addresses located in the database.
2. The database returns its IPs to the instance TCP.
3. Further, the instance of TCP triggers its getParameters() method

to retrieve the Nmap parameters from the penetration tester.
4. The penetration tester supplies and returns the wanted Nmap

parameters to the instance TCP.
5. If the parameters are invalid, the instance TCP will return an

error message to the user. If the parameters are valid, the instance
TCP will run a TCP scan on the IPs retrieved from the database
with the specified Nmap parameters.
6. Then, the instance TCP calls the database, supplying the Scan-
Result, to parse the results from the scan.
7. If one of the host’s in the database is up, this host needs to be

further scanned. Therefore, an instance of a UDP scan with the
open host will be created. Eventually, the result from the TCP
scan will be returned and displayed to the penetration tester. If
all the host’s in the database are down, the result from the TCP
scan will be returned and shown to the penetration tester right
away.
This is a process that begins right after the host discovery is done,
and is therefore started by an internal event of extracting the hosts
identified as “up”. When this internal event is done, the system is
waiting for some input parameters from the penetration tester. So, to
continue this process, the system is dependent on stimulus from the
penetration tester. Based on this, this process has two preconditions:
(1) The penetration tester has some Nmap parameters ready to write
as input, and (2) There exists some open hosts in the database. Just
like in the host discovery process, the data created is the results from
the TCP scan, and the system’s response is these results shown to the
penetration tester.
With regards to the UDP scan, it will involve the exact same process
as the one described above, with the only difference being the type of
scan. This also applies to the step with creating a new scan in the event
of an open host - this will then be a TCP scan.
58
Figure 5.6: Sequence diagram describing the execution of a TCP scan.
5.4.3 Set Testing Status

The third sequence diagram illustrates the interaction between the
system and the penetration tester when the penetration tester provides
a testing status. Figure 5.7 shows this diagram and may be read as
follows:
1. First, the instance TS of the TestingStatus object class triggers its

getTestingStatus() method to retrieve the testing status from the
penetration tester.
2. Then, the penetration tester provides the testing status which is

returned to the instance of TS.
3. If the penetration tester does not provide a testing status, and

the system fulfills the conditions given in requirements 16-18, the
system automatically sets the status to “done”. If the penetration
tester provides a testing status, the instance of TS calls the
database, supplying the given status, to save this status in the
database.
In this scenario, an input from the penetration tester specifying the

testing status, whether it is empty or not, is the needed stimulus for
this process to start. Consequently, this is one of the preconditions for
59
this use case. Secondly, there need to exist some results in the database
from previously executed scans, so the penetration tester has elements
(the network, IP addresses, ports, and services) to provide the testing
status on. The system will respond by changing the status of the given
element.
Figure 5.7: Sequence diagram describing the process of adding a testing

status.
5.4.4 Set Vulnerability Status

The second last sequence diagram addresses a somewhat similar
interaction as the previous one. In this sequence diagram, the difference
is that the penetration tester shall provide a vulnerability status, and
there are no conditions in the event of an empty status. Here, the
penetration tester shall only provide if the element (the network, IP
address, port, or service) is vulnerable or not. If this information is
given, it will be stored in the database. This is illustrated in Figure 5.8.
Similarly, with the previous one, a stimulus is needed to input from
the penetration tester to begin this process. Further, some results in
the database need to exist, so the penetration tester has elements to
provide a vulnerability status on. Lastly, in this process, the system
will respond by changing the status of the given element.
60
Figure 5.8: Sequence diagram describing the process of adding a
vulnerability status.
5.4.5 Extract Report

The last sequence diagram illustrates the system interaction when
the penetration tester is extracting the report. Figure 5.9 shows this
diagram and may be read as follows:
1. The penetration tester triggers the ExtractReport method in an

instance of TR of the TestingReport object class.
2. The instance TR calls the database to return all the information it

has saved during the scanning.
3. If the database is empty, it will return an error message informing

that it has no information stored. If the database has saved some
data, it will return all the saved information.
4. Then, the instance of TR will generate a report and return this

report to the penetration tester.
In this process, the stimulus is a user command issued by the

penetration tester. For this process to complete with success, the
precondition is that scans have been executed successfully, thus there
exist some data in the database. The data created is all the information
retrieved from the database when generating the report, and the
system’s response is the generated report displayed for the penetration
tester.
These diagrams show the intended interaction between the penetra-
tion tester and the system in a high-level fashion. There is still some
parts of the interaction that is not shown in these diagrams as these are
dependent on implementation decisions. For instance, the diagrams do
not specify how to check if a host is up or down, but that is not important
at this stage - the main interaction is still plausible addressed.
61
Figure 5.9: Sequence diagram showing the interaction when the
penetration tester is extracting a report.
5.5 Context models and Activity Diagrams

In developing a new system, there is a high possibility that this
new system shall be integrated into an already existing system with
different automated processes. Therefore, it is important to get an
overview of the already existing system and its functionalities to plan
where the new functionality shall be implemented. A context model
may be created to show the other systems included in the environment
to attain this overview. These models are relatively simple and do not
show what kind of relationships there are between the already existing
systems and the new system to be developed. Consequently, these kind
of models are often used alongside other models, like activity diagrams
[42].
Sommerville [42] defines an activity diagram as a diagram that
shows the activities in a process and the flow of control from one
activity to another. A filled circle indicates where the process begins,
and rectangles with round corners represent the different activities
in the process. To represent the flow control, arrows are drawn from
one activity to another. A solid bar specifies the coordination of the
activity. In an event where one or several activities lead to a solid
bar, it is impossible to proceed before all of these activities have been
completed. If several activities are followed from a solid bar, it means
that these activities may be executed in parallel. To specify election or
different scenarios, an election diamond is used. This is represented
with a rotated square with the election, or scenario, specified in square
brackets. The arrows specify which of the flows are followed. Activity
diagrams may also include objects to, for instance, specify the different
systems used for each activity. The objects are shown in the diagram
by using rectangles with pointed corners. Finally, a filled circle inside
62
another circle indicates the end of the process [42].
In the early phases of this
project, there was decided that
Twizzlers shall use Nmap as a
part of the solution to perform
the different types of scans. As
Figure 5.10: Context model.
this is a widespread tool among
penetration testers, research was
conducted to see if a system provides the functionality to run different
scans. As a result, a wrapper library called SaltwaterTaffy was found
and will be a part of the environment of Twizzlers [12]. This results in
the simple context model illustrated in Figure 5.10.
After obtaining an excellent overview of the functionalities Salt-
waterTaffy offers, a plan of what kind of, and where, the new function-
ality shall be implemented was created. Based on this, an activity dia-
gram was made to illustrate which activities SaltwaterTaffy provides,
and which activities Twizzlers shall provide. Figure 5.11 shows that all
the activities, including the execution of a scan type, are the responsibil-
ity of SaltwaterTaffy. In contrast, all other activities, such as validating
input, queueing the scans, and adding to the database, are the respons-
ibility of Twizzlers. Additionally, the diagram shows that the host dis-
covery process must be finished before proceeding with the TCP and
UDP scanning, and that the TCP and UDP scanning may be executed
in parallel. Also, the TCP and UDP scanning must be completed before
a testing and vulnerability status can be set, in addition to extracting
the report.
63
Figure 5.11: Activity diagram.
5.6 Data-Flow Diagram

Behavioral models provides an overview of the actions, or the expected
actions, of a system when responding to some stimuli from the
environment. These stimuli may be data or events. When the stimuli
64
are data, it is the input data that controls and triggers the system
processing. On the other side, when the stimuli are events, an external
event triggers the system’s processing. Twizzlers is dependent on
input data both from the penetration tester and from the database to
trigger the system processing. Thereby, Twizzlers is stimulated by data,
making it reasonable to create a data-driven model for this system [42].
A data-driven model shows all the actions taking place from the
first input being processed to the corresponding output, responding
to the system. To create such a model, a data-flow diagram may be
used. This diagram helps analysts and designers track and document
how data in a specific process moves through the system. As a result,
they achieve a greater understanding of what is happening in the
process. Additionally, data-flow diagrams are pretty intuitive and
straightforward, which is a great advantage for communication with
stakeholders. There are two ways to model the data-flow, where one is
more satisfactory if the stakeholders are non-experts. In that scenario,
it will be beneficial to use an activity diagram to model the data-flow.
This diagram highlights the operations and activities, and is more
intuitive and comprehensible. In the scenario of the stakeholders being
engineers or experts, there may be preferable to use a sequence diagram
to model the data-flow. The sequence diagram was presented in section
5.4, but there are some changes in how it is modeled when using it for
this purpose. This diagram type still highlights the objects on the top
with vertical dotted lines, but all the messages sent between the objects
are only sent from left to right. As a result, it will show the system’s
sequential data processing [42]. Since the stakeholders in this project
are experts, a sequence diagram will be sufficient to use.
Figure 5.12 illustrates the processing sequences in the system by
using a sequence diagram. The objects are represented on the top, the
activities are shown with named arrows, and the parameters are the
data needed to execute the activity and continue the process. When
reading from the top to the bottom, it may be interpreted in the
following way:
1. The process begins with the penetration tester supplying (action)

an IP-range (data) to the instance HD of the Host Discovery object
class.
2. Then, the instance HD will validate (action) this IP-range. If the

validation is ok, the penetration tester will supply (action) the
wanted Nmap parameters (data) to the instance HD.
3. Again, the instance HD will validate these parameters. If the

validation is ok, the instance HD will execute a host discovery
(action) with the given Nmap parameters and IP-range (data).
4. When the execution is done, the instance HD will call the database
to save (action) the results (data) from the discovery.
65
5. Further, the instance TCP of the TCP scan object class, will call
the database (action) to retrieve the saved IP addresses.
6. Then, the penetration tester will supply (action) its wanted Nmap
parameters (data) for this TCP scan.
7. Just like the instance HD, the instance TCP will validate these
parameters (action). If the validation is ok, the instance TCP will
execute a TCP scan (action) on the extracted IP address and Nmap
parameters (data).
8. When the execution is done, the instance TCP will call the
database to save (action) the results (data) from the TCP scan.
9. For the instance UDP of the UDP scan object class, the steps
will be the same as for the instance TCP (steps 5-8). The only
difference is that there will be an execution of a UDP scan, and
not TCP scan.
10. Next, the penetration tester will supply (action) a testing status
(data) to the instance S of the Status object class, whereas the
instance S will call the database to save (action) this status (data).
The same process is executed with the vulnerability status.
11. Finally, the instance R of the Report object class, will call the
database to extract all the saved information (action), and then
generate a report (action) with this given information (data).
This model and corresponding explanation show with clarity the

actions to be executed, the data needed to execute the different actions,
and how the actions shall respond to the given data. As a result, this
diagram may be very helpful in the later phases of this project, such
as in the implementation- and evaluation phase, as it shows all actions
and associated data from start to finish.
66
Figure 5.12: Data-flow diagram represented by a sequence diagram.
67
68
Chapter 6
Implementation of
Twizzlers
This chapter will present the implementation of the final minimum

viable product. The first section describes shortly the programming
language and framework used when implementing. Finally, some code
snippets of the most relevant parts of the implementation will be shown
and explained more in-depth.
6.1 Programming Language and Framework
The system is written in C# with .NET Core. As shown in the models in

the previous chapter, Chapter 5, the system consists of different classes
and objects which results in the need of an object-oriented programming
language. This is fulfilled by using C#. Additionally, C# provides several
benefits such as performance, simplicity, and a rich library. Moreover,
when C# is used with .NET Core, it is capable to run on every operating
system. To implement the database design illustrated in 5.3, there
is used an SQLite database for benefits of being easy to use, its good
performance and reliability.
6.2 Implementation Details
This section will present and explain the implementation of how the
different scans are running and put in the database, in addition to
how the TCP and UDP scans are added to a queue for execution
after the host discovery. When looking at the requirements and how
these are prioritized, it is evident that this functionality fulfills all the
requirements prioritized as urgent (2, 3, 4, 7, 8(a), 8(b), 9(a), 9(b), 10),
and some of the requirements prioritized as high (5, 6, 11, 12). Based
on this, the aforementioned functionality is considered to be the most
relevant parts of the implementation.
69
6.2.1 Host Discovery
Figure 6.1: The method of executing a host discovery.
Primarily, all the different scan types implement an interface called

“IScanType”. When executing the different scans, a queue of all the
scans that implements this interface will be iterated over.
Figure 6.1 shows how the method RunScan() executes a host
discovery. First and foremost, the method retrieves Nmap parameters
from the user by calling another method in the class. This method
simply just asks the user for Nmap parameters. Further, the RunScan()
method creates a target object with the IP-range specified from the user.
The IP-range is retrieved in the main program where the whole session
gets started by the user specifying an IP-range. Then, a host discovery
object is created with the IP-range as a parameter. Next, a scanner
object is created with the recently created target as a parameter. Next,
the specified Nmap parameters is added to the scan, and the number of
scanned ports is saved in a variable called “scannedPorts”. This variable
is used when calculating the testing coverage. Finally, a host discovery
is executed and the results are added to the variable “hostResult” which
is returned.
70
Figure 6.2: The method of adding the results from the host discovery in
the database.
Furthermore, the returned value from the RunScan() method is

given as a parameter to the method ParseResult(). This method is
presented in Figure 6.2 and is responsible for adding the results to
the database. This method starts with creating two separate lists
containing the TCP and UDP ports which already exist in the database.
The purpose of this, is to have a basis for comparison in the if-statement.
Next, the method is first looping through the hosts from the host
discovery, and then through the host’s ports. Inside these two loops, a
check is performed to see if the database already contains the resulting
host(s). This is done by checking if one of the newly created lists
contains the resulting host’s port number and is the same protocol
type - and if so - the database is updated with the new resulting host.
The database is updated in case some information about the host has
changed from the last executed scan. On the other hand, if the resulting
host is not already in the database, it gets added.
6.2.2 TCP and UDP Scan

The execution of both TCP and UDP scan is relatively similar to the
execution of a host discovery where only the target type, scan type, and
one extra line make the difference. In these executions the target is
an IP address, and not a whole IP-range. Also, the scan type is a SYN
Stealth Scan (-sS) for TCP, and a Udp Scan (-sU) for UDP. Additionally,
the RunScan() method for both TCP and UDP has one extra line. Both
the scan execution and the extra line is shown in Figure 6.3. The call
on UpdateScan() updates the scan table in the database. This needs
71
to be done due to the status of the scan is changing from “planned” to
“running”.
Figure 6.3: Execution of TCP and UDP scan.
Similarly to the host discovery, also here the result from the
RunScan() method is given as a parameter to the method ParseResult().
This method is also quite similar to the one in host discovery. The
difference involves the port’s protocol type that is extracted from the
database, and also here the scan needs to be updated from “running”
to “done”. Figure 6.4 shows the code implemented for TCP. The only
difference between the code for TCP and UDP is that UDP, naturally,
creates a list with UDP ports and UpdateScan() has “NMAP UDP” as
parameter instead of “NMAP TCP”.
Figure 6.4: The method of adding the results from the TCP scan in the
database.
6.2.3 Enqueue TCP and UDP Scans

When the host discovery is finished, and if there are hosts up, TCP
and UDP scans will automatically be added to a queue. This is done
by checking the aforementioned; if there are hosts up, in addition to
72
check if the scan is already in the queue. This is done by a method
called TCPTriggerCheck() for TCP, and UDPTriggerCheck() for UDP.
For simplicity, and also as the methods are quite similar, only the
TCPTriggerCheck() will be shown and explained here. Even so, the
UDPTriggerCheck() is performing the same checks, only for UDP.
Figure 6.5: The method of checking if a scan shall be added to the queue.
Figure 6.5 shows the implementation of TCPTriggerCheck(). This

method is looping through the resulting hosts from the previous scan
and creates a new scan object with the resulting hosts’ IP address.
Moreover, the scans in the scan database is retrieved and saved in
another scan object. If these two scan objects are identical, the method
will return false, indicating that the scan already exists in the scan
database. However, if the scans are not identical and the resulting
hosts are up, the method will return true. This indicates that the scan
needs to be added to the queue. To add the scan to the queue, another
method called TCPTriggerCallback() is executed. This method is shown
in Figure 6.6. This method adds a new scan to the queue, and adds this
scan to the scan database with the status “planned”. This method is
also specified for UDP, called UDPTriggerCallback(), and adds a UDP
scan to the queue instead of a TCP scan.
73
Figure 6.6: The method of adding a TCP scan to the queue.
74
Chapter 7
Testing
Testing involves using a variety of techniques to systematically and

methodically examine a work product. The aim of the testing is not
always the same for all software projects, and may also vary throughout
the software development cycle [18]. During the implementation of
Twizzlers, there were performed unit tests aiming to assure that every
component worked as intended separately. When these unit tests
executed with success, and the implementation evolved, several test
cases were made and executed. The aim of these test cases are
to examine if all the system requirements for Twizzlers have been
satisfied. This chapter will present and explain the execution of these
test cases, with a conclusion of whether the associated requirements are
satisfied or not. However, first an explanation of how to use the tool will
be given.
7.1 How To Use Twizzlers

The minimum viable product of Twizzlers does not have a proper
graphical user interface (GUI), and is therefore run in the Terminal.
This is not the optimal usage of the tool, but due to the time
constraints for this project, a proper graphical user interface needs to
be implemented later. Even so, a simple console menu is implemented
to increase the usability to some extent.
At start-up, the user is presented with a main menu that contains
five different choices:
1. To run a host discovery and port scan
• This option starts the process of executing a host discovery

and associated port scans.
2. To provide a vulnerability status
• This option allows the user to provide a vulnerability status

on an IP address, port, or service.
3. To provide a testing status
75
• This option allows the user to provide a testing status on an
IP address, port, or service.
4. To extract a report
• This option allows the user to extract a report consisting of

the results from the scanning, the provided statuses, and the
testing coverage.
5. Exit the program
• This option exits the program.
This menu is shown in Figure 7.1. The vulnerability and testing

statuses will be set as the team progress through the penetration test.
The aim of these statuses is to centralize note-taking and link these
to specific findings, such as open ports. After further investigations,
the vulnerability status of a specific finding is set, whereas the testing
status is used to coordinate and decide further actions. This means that
when a penetration tester begins to explore a finding, for instance an
open port, the testing status is changed to “in-progress”. The status is
set to “done” after the penetration tester is finished. Consequently, the
testing status shows other penetration testers what needs to be done.
The different choices presented in the main menu will be further
described in the test cases in the following section, section 7.2.
Figure 7.1: The presented menu at start-up.
7.2 Test Cases

As defined in Hambling et al. [18], a test case is a set of preconditions,
inputs, actions (where applicable), expected results and post-conditions,
based on test conditions. The test cases are created based on a specific
objective, and the purpose of executing test cases is to practice a certain
program path or to verify that a particular requirement has been
fulfilled [21]. The next subsections present five different test cases to
test the newly developed system, Twizzlers. The aim is to verify that
the program behaves as expected, in addition to verify the associated
requirements. When listing the associated system requirements for
each test case, the enumeration corresponds to the list that presents
the system requirements in Chapter 4.
76
7.2.1 Test Case 1: Execute Host Discovery, TCP Scan, and
UDP Scan
This test case will exercise the program path of executing the three
different scans. The test case is defined in Table 7.1. The associated
requirements for this test case are the following:
3. The system shall perform host discovery on IP ranges.
4. The results of the host discovery (found IPs) shall be inserted into
the database.
5. The system shall allow host discovery to be run multiple times on

the same ranges, adding new hosts to the database.
6. The host discovery method shall be configurable and tuneable for

7. The system shall perform individual port scans on each of the

found IPs from the database.
8. (a) The individual port scans shall detect open TCP ports.
(b) The individual port scans shall detect open UDP ports.
9. (a) The individual port scans shall detect services running on

open TCP ports.
(b) The individual port scans shall detect services running on
open UDP ports.
10. The results of the individual port scans (open ports and services)
shall be inserted into the database.
11. The system shall allow individual port scans to be run multiple
times on the same IP, adding new ports/services to the database.
12. The individual port scans shall be configurable and tuneable for
The execution of the test case presented in Table 7.1 are shown in
Figures 7.2-7.7. The input provided by the user is marked with a blue
square, and the associated result is marked with a green square.
Figure 7.2 shows how the system responds to Step 1 in the test
case: asking the user for an IP-range. When the input value stated
in the test case has been provided, the system responds by asking the
user to specify Nmap parameters. This is shown in Figure 7.3. The
system responds to this Nmap parameter by executing a host discovery,
illustrated in Figure 7.4. This figure shows that one host is up in the
given IP-range, and due to this a TCP and an UDP scan for this host
have been added to the queue. The first scan to execute is the TCP scan,
77
Test Case ID: 1
Precondition(s): User have an IP-range which contains one,
or several, host(s) that are up.
Expected Result: All scans are executed without failure
and the results are displayed for the user.
Post-condition(s): Database contains the results the scans.
the scans.
Actions: Input:
1. Choose “Execute host discovery and port
“1”.
scans” from the main menu
2. Specify IP-range 127.0.0.1/32.
3. Specify Nmap parameters “-T4”
4. Specify new Nmap parameters for TCP
“-T4 –top-ports100”
scan
5. Specify new Nmap parameters for UDP
“-T4 -p631,400”
scan
Actual Result: As expected.
Passed/Failed: Passed.
Table 7.1: Test case for executing host discovery and different port
scans.
and therefore the system again will ask for new Nmap parameters and
responds by executing the scan. The result from this scan is shown in
Figure 7.5. Since an UDP scan for this host already is in the queue,
and the TCP scan has just been executed for this host, no triggers are
met and no more scans will be queued. The same process applies for the
UDP scan shown in Figure 7.6. Finally, the results from this specific
scanning will be shown to the user, in addition to an overview of all
findings and statuses, and the menu. This is shown in Figure 7.7.
This execution results in a passed status on the test case, and
thereby all of the requirements have been fulfilled. This test case
verifies that the system performs host discovery, TCP scan, and UDP
scan with success, resulting in requirements number 3 and 7 are
fulfilled. Additionally, between each scan the user is able to provide
wanted Nmap parameters which satisfy requirements number 6 and 12.
Moreover, by queuing TCP and UDP scans on the hosts that are open, it
allows the scans to be run multiple times at the same IP, which fulfills
the first part of requirement number 11. In addition, since the user is
presented with the menu one more time after an action is executed, the
user may execute one more host discovery and port scans on the same
ranges. As a result, the system allows to run a host discovery several
times on the same ranges, which fulfills the first part of requirement
number 5. Furthermore, the results show that the found IP, (open) TCP
and UDP ports, and the services running on these ports, are saved in
the database and displayed to the user. This satisfies the requirements
number 4, 8(a), 8(b), 9(a), 9(b), 10, and the last part of 5 and 11.
78
Figure 7.2: Step 1 in Test Figure 7.3: Step 2 in Test
Case 1. Case 1.
Figure 7.4: Step 3 in Test Case 1.
79
Figure 7.7: The result of executing Test Case 1.
7.2.2 Test Case 2: Provide Vulnerability Status on IP,

Port, and Service
This test case will exercise the program path of providing a vulnerab-
ility status on one IP address, one port, and one service. The test case
is defined in Table 7.2. The associated requirement for this test case is
the following:
19. Likewise, the system shall be able to store a vulnerability status

(Vulnerable/not vulnerable) provided by the operator for each
network, each IP, each port, each service, extendable to include
full vulnerability details.
Figures 7.8-7.10 depict the execution of the test case outlined in

Table 7.2. The user’s input is denoted by a blue square.
When Step 1 in the test case is executed, the user is displayed with
a new submenu that provides four different choices for the user. This
submenu is illustrated in Figure 7.8. Furthermore, when the test case’s
Step 2 is completed, the user needs to specify a host, a port, and a service
to provide a vulnerability status on. This is done by writing the input
values specified in steps 3-6 into the command line in the Terminal and
press enter. This is shown in Figure 7.9. Likewise, when steps 7 and 11
are executed, the input values specified in steps 8, 9, 10, 12, and 13, are
inserted the same way.
80
Figure 7.8: The presented vulnerability menu.
Finally, Figure 7.10 shows the result of the final execution of the test
case. The green squares mark the chosen IP address, port, and service
and their associated vulnerability status provided during the test case.
This shows that after the user has provided all the input values stated
in the test case, the chosen IP address, port, and service have the correct
vulnerability status. This fulfills the associated requirement to some
degree. The requirement also states that each network shall retrieve,
store, and display a vulnerability status, but the system only does this
for each IP address, port, and service.
Test Case ID: 2

Precondition(s): Host discovery and an individual port scan
has been executed.
Expected Result: The provided status for each IP address,
port, and service is displayed for the user.
Post-condition(s): The provided status for each IP address,
port, and service is saved in the database.
Actions: Input:
1. Choose “Provide vulnerability status” from
“2”.
the main menu
2. Choose “Provide vulnerability status on
“1”.
service” from the submenu
3. Choose a host “127.0.0.1”.
4. Choose a port “631/tcp”
5. Choose a service “ipp CUPS”
6. Specify a vulnerability status “Not Vulnerable”
7. Choose “Provide vulnerability status on port”
“2”.
from the submenu
8. Choose a host “127.0.0.1”.
9. Choose a port “631/udp”
10. Specify a vulnerability status “Vulnerable”
11. Choose “Provide vulnerability status on IP”
“3”.
from the submenu
12. Choose a host “127.0.0.1”.
13. Specify a vulnerability status “Vulnerable”
Table 7.2: Test case for providing a vulnerability status on one IP, one
port, and one service.
81
Figure 7.9: The needed inputs from user when providing a vulnerability
status on a service.
Figure 7.10: The result after executing test case 7.2
7.2.3 Test Case 3: Provide Testing Status on IP, Port, and

Service
This test case will exercise the program path of providing a testing
status on one IP address, one port, and one service. Compared to the
previous test case (Table 7.2), this test case will be rather similar. The
difference is the type of status provided, but for simplicity, the same
IP address, port, and service will acquire the testing status. The test
case is defined in Table 7.3, and the associated requirements are the
following:
13. The system shall be able to store a testing status (not checked/in-
progress/done) provided by the operator for each network, each IP,
each port, each service.
14. The system shall be able to display a calculated testing status
for each network, each IP, each port, each service.
82
components.
Figures 7.11-7.13 depict the execution of the test case outlined in

Table 7.3. The user’s input is denoted by a blue square.
When the test case’s first step is executed, the user is displayed with
a new submenu that provides four different choices for the user. This
submenu is illustrated in Figure 7.11. Furthermore, when completing
the rest of the steps, the user provides the host, port, service, and testing
status as shown in Figure 7.12.
Figure 7.11: The presented testing menu.
Figure 7.12: The needed inputs from user when providing a testing
status on a service.
Finally, Figure 7.13 depicts the outcome of the test case’s final
execution. Similarly to Figure 7.10, the green squares mark the
chosen IP address, port, and service and their associated testing status
provided during the test case. This shows that the user may provide a
testing status on an IP address, port, and service, and that the provided
status is stored in the system and finally displayed for the user. Based
on this, the first part of requirement number 15 is verified and fulfilled,
while 13 and 14 are verified, but only partly fulfilled. The reason for
not being completely fulfilled, is that there are only the IP address,
port, and service that retrieve, store, and display the testing status.
Requirements number 13 and 14 also state that the network shall
retrieve, store, and display a testing status.
83
Test Case ID: 3
has been executed.
Expected Result: The provided status for each IP address,
port, and service is displayed for the user.
Post-condition(s): The provided status for each IP address,
port, and service is saved in the database.
Actions: Input:
1. Choose “Provide testing status” from the
“3”.
main menu
2. Choose “Provide testing status on service”
“1”.
from the submenu
3. Choose a host “127.0.0.1”.
4. Choose a port “631/tcp”
5. Choose a service “ipp CUPS”
6. Specify a testing status “Not Checked”
7. Choose “Provide testing status on port” from
“2”.
the submenu
8. Choose a host “127.0.0.1”.
9. Choose a port “631/udp”
10. Specify a testing status “In-progress”
11. Choose “Provide testing status on IP” from
“3”.
the submenu
12. Choose a host “127.0.0.1”.
13. Specify a testing status “Done”
Table 7.3: Test case for providing a testing status on one IP, one port,
and one service.
84
7.2.4 Test Case 4: Provide Testing Status “DONE” on All
Services
This test case will exercise the program path of providing the testing
status “DONE” on all services, and identify how this affects the testing
status of the associated port and IP address. The test case is defined in
Table 7.4, and the associated requirements are the following:
components.
16. If not directly set, the calculated testing status of a network shall
be “done” if the calculated status of all IPs in the network are
“done”.
17. If not directly set, the calculated testing status of an IP shall be

“done” if the calculated status of all ports on the IP are “done”.
18. If not directly set, the calculated testing status of a port shall be
“done” if the calculated status of all services on the port are “done”.
Figure 7.14 shows the result of executing the test case presented in
Table 7.3. The green squares illustrate that after executing this test
case, the testing statuses to the service’s associated ports are set to
“DONE”, in addition to the port’s IP address. This verifies and fulfills
the second part of requirement number 15, in addition to number 17
and 18. However, requirement number 16 is not fulfilled for the same
reason mentioned in the two previous subsections: the network is not
being stored and displayed for the user.
85
Test Case ID: 4
has been executed.
Expected Result: All services, ports, and their associated
IP address displays the testing status “DONE” for the user.
Post-condition(s): The testing status “DONE” is saved in
database for all ports and services associated with the
IP address.
Actions: Input:
1. Choose “Provide testing status” from the
“3”.
main menu
2. Choose “Provide testing status on service”
“1”.
from the submenu
3. Choose a host “127.0.0.1”.
(1)“631/tcp”,
4. Choose a port (2)“400/udp”,
“(3)631/udp”
(1)“ipp CUPS”,
5. Choose a service (2)“work-sol”,
(3)“ipp”
6. Specify a testing status “Done”
7. Perform step 2-6 three times
Table 7.4: Test case for providing the testing status “DONE” on all
services.
7.2.5 Test Case 5: Extract Report

This test case is the final test case and will exercise the program path of
extracting the report created based on the different scans executed, and
the provided vulnerability and testing statuses. The test case is defined
in Table 7.5, and it only has one associated requirement which is the
following:
20. The system shall be able to export a testing report describing

testing coverage and vulnerabilities.
When this test case is executed, a report is created based on the

different scans executed in Test Case 1 (Table 7.1), the vulnerability
status provided in Test Case 2 (Table 7.2), and the testing statuses
provided in Test Case 3 (Table 7.3) and Test Case 4 (Table 7.4).
The first page of the report provides a summary of the testing
done containing a measure for testing coverage, in addition to some
informational metrics which provides some useful information if they
are interpreted correctly. This is shown in Figure 7.15.
86
Test Case ID: 5
have been executed.
Expected Result: A report is created and shown to the user.
Post-condition(s): Report is created.
Actions: Input:
1. Choose “Extract Report” from the main menu “4”.
2. Open file “Sample.pdf ”.
Table 7.5: Test case for extracting the report.
The first metric in the report, “Ports in Total”, gives the penetration
tester, to some extent, an idea of how much of the targeted system that
are tested (testing coverage). This is an important value as it gives
a quantitative evaluation of the scope and the quality of the testing.
Additionally, it gives an estimate of how much more testing that needs
to be done [18]. However, independent on whether the penetration
testers execute a black, white, or grey box penetration test, this metric
may be very difficult to measure. The reason for this, is that it may
be difficult to identify the values needed for an equation to retrieve the
percentage of the testing coverage. Nevertheless, for this project, there
are used the data available in Twizzlers to give the penetration testers
an idea of how much of the targeted system that are tested. This is done
by counting the number of ports that are scanned when executing a host
discovery, and the following TCP and UDP scans, and then divide this
number of the total amount of TCP and UDP ports (131 070). As seen
in the report in Figure 7.15, Test Case 1 results in 0.84% test coverage
when examining the number of ports scanned.
The remaining calculations in the report, vulnerable ports, and
tested ports and services, give the penetration tester an overview of the
extent of vulnerable ports, in addition to the tested ports and services.
This may be referred to as an informational metric. The limitations and
the values of such a metric may be analogous to classical coding metrics,
such as lines of code or code quality. The value of such calculations is
valuable in the extent of automation and the degree of intuitiveness. To
calculate for instance the lines of code, vulnerable ports and services,
and the number of, for instance, “done” ports, the effort of manual
counting is easily eliminated by a process that automates the counting.
Furthermore, the resulting values is understandable and intuitive in
the way that they are displayed for the user and visualize the effect of
the measurement [5].
On the other side, such calculations also have some limitations.
The calculations may not always tell the whole truth, as it is just
one numerical number that might have been calculated without
taking other external factors into consideration. When for instance
87
measuring the lines of code, such external factors may be the developer’s
experience. For instance, a developer who is experienced may use fewer
lines to develop a specific functionality compared to one who is not
so experienced, which will affect the measure when calculating the
developer’s produced lines of codes [5]. Similarly, when providing a
status, the external factor which may affect the calculations is who
provides the different statuses. The reasoning for this, is that there is no
clear definition of when an IP address, port, or service shall be identified
as vulnerable or not vulnerable, and done, in-progress, or not checked.
Furthermore, the experience level of the penetration tester also applies
in this case, as one with more experience may have more knowledge
about what needs to be further checked or tested before an instance’s
status is updated. For example, one penetration tester may provide the
testing status “done” on a certain port, while another penetration tester
will provide the testing status “in-progress” on the same port. This may
be due to the experience level of the penetration tester, or the indistinct
definition of when to provide the different statuses, or a combination of
the two.
For this project, the different informational metrics are calculated
by counting the amount of ports and services which are provided
with a status, or a specific status, and divided this number by the
total of ports and services identified during the different scans. The
percentages shown in Figure 7.15 are based on the execution of the
previous executed test cases.
Figure 7.15: The summary in the scan report
The rest of the pages in the report contains a table listing all the
88
results from the different scans (IP address, port, and service), in
addition to their associated vulnerability and testing statuses. Figure
7.16 shows the resulting table from all the previous executed test cases.
When examining this table, it contains all the results retrieved from
the scans executed in Test Case 1, in addition to the correct service
is marked as “not vulnerable”, and the correct port and IP address is
marked as “vulnerable”. Moreover, all the services and ports belonging
to the IP address “127.0.0.1”, and the IP address itself, have the testing
status “DONE” which was carried out in Test Case 4. Accordingly, is
requirement number 20 fulfilled.
Figure 7.16: The table in the scan report
7.2.6 Summary
To summarize, the requirements number 3, 4, 5, 6, 7, 8(a), 8(b),
9(a), 9(b), 10, 11, 12, 15, 17, 18, and 20 are fulfilled. Furthermore,
requirements number 13, 14, 16, and 19 are only fulfilled to some
extent. The remaining requirements, requirements number 1 and 2,
are also fulfilled, however this concerns how the system is implemented
which is shown in Chapter 6. The different scan types implement an
interface which is called “IScanType” that is iterated over when running
the different scans. This implementation makes it possible to allow for
automation in future releases, and thereby requirement 1 is fulfilled.
Finally, Chapter 6 also shows how the results from the different scans
are added to the database, thus requirement number 2 is achieved.
89
90
Chapter 8
Evaluation
This chapter aims to evaluate how Twizzlers affects the current inform-
ation gathering phase of a penetration test. First, the experimental
design and type of survey will be explained. Then, the execution of the
experiment will be described. Finally, the results from the research will
be presented and its validity and limitations discussed.
8.1 Experimental Design

The experiment to be conducted involves three different dependent
variables, an independent variable, and a group of participants. As
mentioned in 3.2, the three dependent variables for this experiment
are: (1) the time used in the information gathering phase, (2) the time
used to perform manually testing, and (3) test coverage. Furthermore,
the independent variable is the use of the new tool, Twizzlers. This
experiment will examine how the independent variable will affect the
dependent variables. Further, the group of participants will include the
two penetration testers from PwC. Since the group of participants are
not randomly chosen, and they will participate in every condition of the
independent variable, a quasi-experimental, repeated measures design
is employed [15, 32].
8.2 Survey: Interview

After the experiment is completed, an interview will be conducted.
The reasoning for complementing the experiment with an interview,
is that an interview provides an insight on how the penetration
testers interpret and understand the tool used during the experiment.
Additionally, it provides an opportunity to go in-depth with the
penetration testers to understand their opinions and aspects on the new
tool. This gives valuable information that may be used when answering
the research questions.
An interview can be conducted in three different ways: (1) struc-
tured, (2) semi-structured, or (3) unstructured, depending on how pre-
determined the questions are [9]. For this research, a semi-structured
91
interview is conducted with a number of predetermined questions, in
addition to some follow up questions. This is because there are some
specific questions I want to be answered, while it also allows for elab-
oration and discussion on different aspects and topics during the inter-
view.
8.3 Conducting the Experiment and Interview

There were only one of the two penetration testers that participated
in the experiment. The experiment was conducted by having the
penetration tester run the tool in his environment, and then execute a
scan on their network. When this scan was finished, the penetration
tester provided some different statuses to the results and extracted
the report. Afterwards, I asked the predetermined questions found
in Appendix A. The penetration tester answered these questions in a
comprehensible and detailed manner. Consequently, there was no need
for neither the planned follow-up questions nor some unplanned follow-
up questions. To summarize, it was a successful evaluation where
everything worked as planned.
8.4 Results from Evaluation

Even though there already exist several tools used in the information
gathering phase today, the penetration tester who conducted the
experiment and was interviewed afterwards would most certainly
implement one more tool in the information gathering phase. However,
this only applies if the new tool to be implemented in the process
provides some more information that they do not obtain otherwise, or
if it provides some other advantages such as usability (easier to use) or
performance (quicker).
The newly developed tool, Twizzlers, will surely provide some more
advantages compared to the already existing tools. It will increase the
performance and provide a good overview of more extensive networks.
Additionally, although the penetration tester does not have a specific
number of how much of the targeted system is covered during a
penetration test today, the tester is sure that Twizzlers will help to
increase the testing coverage. The reason for this is, that Twizzlers
automates scans that are executed manually today. When executing
these scans manually, there is a risk that the penetration tester skips
or forgets something, which adversely affects the testing coverage.
Likewise, according to the penetration tester, it is difficult to state the
exact time used on the penetration testing process and exclusively in
the information gathering phase. Nevertheless, the penetration tester
is optimistic that Twizzlers will help to decrease the time spent and
the amount of work. The reasoning for this, is that Twizzlers will
automate time consuming tasks that are currently done manually, such
as scanning a large number of hosts. Today, one of the penetration
92
testers executes different commands, waits for the result, takes a quick
look at them, and then decides what other commands to run against
these hosts depending on, for instance, what ports that are open.
Twizzlers already improves this process by automatically executing
some of these steps (it takes an IP-range and scan all hosts, and if
sensible, it spins off more scans on the results). Consequently, the
penetration testers will retrieve some freed time used on other tasks
in the penetration testing phase, such as on manual testing and clients.
However, in the current state of the tool, Twizzlers will not
ultimately provide all these advantages even though it works in
principle. The reason for this, is that the tool still has some
shortcomings. The critical functionality that needs to be expanded is
the triggers. The tool needs to add more triggers that run if certain
conditions are met. As a result, the tool will be able to provide more
results after only one execution. This shortcoming, and several more,
will be presented in the final chapter, Chapter 9, Section 9.2. Despite
these shortcomings, the tool still has the potential to become an effective
tool that is plausible to implement in the information gathering phase
in the future. The tool’s implementation is constructed in a way that
is easy to extend, so with more work, the tool may become the efficient
and usable tool the penetration testers have in mind.
When the tool has matured, it will be introduced in the information
gathering phase, where the penetration testers first will provide a range
of IP addresses and run a scan. When this scan is finished, they
will collect the information and extract the report at different times to
achieve an overview of the executed scans and the results.
Based on these results, it is reasonable to conclude that hypotheses
H1, H2, H3, and H4 defined in Chapter 3, subsection 3.2.3, are
confirmed. However, the remaining hypotheses, H5 and H6, are neither
confirmed nor denied as the vulnerability and testing statuses were not
directly evaluated during the experiment and following interview. More
on this in Section 9.2.
8.5 Validity of the Results
When conducting empirical research, it is important to assess the

validity of the study and its results. This is because there exists a
number of threats that may influence the results of the study. As
a consequence, the results of the study may be wrong [10]. As
mentioned, the design of this experiment is a quasi-experimental,
repeated measures design. This design may provide some threats to
both the internal and external validity, and thereby the validity of the
conducted study. The next subsections will present the two types of
validity, and discuss to what extent the different validities have been
preserved in this study.
93
8.5.1 Internal Validity
Internal validity is to which extent the dependent variable indeed
affects the independent variable(s) and that it is a possibility that there
is no other explanation for the findings [11]. Several factors threaten
the internal validity of this study.
The first factor is subject selection. This involves selecting parti-
cipant subjects that represent a population, and how these participants
are selected [10]. For this study, there were selected two participant
subjects that represent the population of penetration testers. When con-
ducting the experiment, only one of them participated. As a result, the
results from the evaluation are only based on one person’s usage and
interpretation of the tool. Additionally, there were chosen the two pen-
etration testers who provided me with the initial case. This means that
the penetration tester who conducted the experiment may already know
how the resulting tool shall behave and is thereby biased.
Secondly, another factor that affects the internal validity is called
testing. If the participants are allowed to use the independent variable
several times, it is a probability that they learn the results and adjust
their responses correspondingly [10, 11]. The participant for this
experiment is one of the two that has been involved throughout the
whole project. Consequently, the participant has seen the development
of the tool, and may already have established some prejudices and
definite opinions about the tool even before the evaluation began. Due
to this, the results may be biased.
Furthermore, motivation is the next factor that may harm the
internal validity. This factor concerns that the participants are either
motivated or resistant to use the new approach, method, or technique
they are presented for. As a result, their response or performance when
implementing the new approach, method, or technique may be affected
[10]. Regarding this new tool, the participant already wished for a new
tool to implement in the information gathering phase of a penetration
test, which will positively affect the time used in this phase. With this in
mind, the participant was already very excited about the idea of using a
new tool. As a result, the participant may overlook the negative aspects
of the newly developed tool and only focus on the advantages.
The penultimate factor affecting the internal validity is ignoring
relevant factors. This involves that all factors in the experiment setup
is not accounted for, such as how usable the tool used in the experiment
is [10]. As mentioned in the previous paragraph, the participant in this
experiment needs and wants the newly developed tool. Consequently,
the participant only sees what it wants to see and may overlook the
negative aspects. Even though this tool is far from finished, the
participant is still very positive. The participant commented on the
tool’s potential for improvement, but tended to overlook it since the
participant is focusing on its potential.
The final factor concerns a variable called the confounding variable.
This variable is a third unmeasured variable that may influence
94
both the dependent and independent variable [44]. This variable
affects the internal validity, both beneficial and disadvantageous. The
advantage of this variable is that it may be easier to control when
conducting a quasi experiment than an actual experiment. As a
result, the internal validity is strengthened. However, since there
is a lack of randomization, it may be difficult to verify that all the
confounding variables are accounted for. As a consequence, this will
lower the internal validity [15]. For this experiment, the confounding
variable may involve aspects that have been explained in the previous
paragraphs, such as the participant learns how to use the tool after
testing it several times, and thereby have learned how it works and
made up an opinion that may influence the results. However, there is
no certainty that all the confounding variables are considered.
Given all these threats to the internal validity, it is sensible to
infer that the internal validity of the conducted study is not well
preserved. To mitigate these threats, the study ought to have more
than one participant. With more than one participant, the experiment
may have a more extensive set of results containing several different
interpretations of the tool. Additionally, the experiment would have
profited from having more objective participants, such as penetration
testers from another company, resulting in removing the bias from the
results.
8.5.2 External Validity

External validity concerns to what extent the results may be generalized
and applied to other settings [11]. Cruzes and Othmane [10] presents
three different factors that may threaten the external validity. The
first one is representation of the population, which involves that the
selected participants should represent the population for which the
study is applicable [10]. The selected participants for this experiment
are professional penetration testers. Hence, the selected participants
represent the population to which the study applies. As a result, the
external validity is strengthened. The next factor Cruzes and Othmane
[10] present is representation of the setting. This implies that the setting
of the study should represent the study goals. The final factor presented
is the context of the study. This suggests that when and where the
study is conducted may have an impact on how generalizable the results
are. The experiment conducted was carried out at the penetration
tester’s workplace during working hours, using the penetration tester’s
computer. This means that the experiment was conducted in a real-
world environment, and not in a laboratory setting. As an outcome, it
is attainable to presume that this experiment may be generalized and
conducted with other penetration testers in another penetration testing
environment. This results in mitigating the two final external threats.
Based on this, it is plausible to conclude that the external validity of the
conducted study is preserved.
95
8.6 Limitations of the Study
It is essential to note the limitations of this study. The most significant
limitations of my thesis are time and society’s restrictions. If the
timeframe for this thesis had been longer, it would have been beneficial
to include more participants in the study resulting in more objectiveness
and mitigating the bias. Additionally, there would be more time for
implementation resulting in a more completed tool used during the
experiment.
Moreover, with the constant change in the society’s restrictions
due to the ongoing COVID-19 pandemic, it was only possible to have
two physical meetings with the penetration testers from PwC, and
none with my supervisor. Consequently, the correspondance with the
penetration testers and my supervisor has mainly been via e-mail
and online meetings. This means that the experiment was conducted
using an online meeting platform which may have had an impact on
the results. This is because I did not observe the penetration tester
using the tool and it is also, to some extent, difficult to have a natural
conversation under such circumstances. Although online meetings
are efficient, they will never replace human interaction. Further, the
university campus has been closed due to lockdown for the majority of
the thesis period resulting in lack of informal discussions with fellow
students and my supervisor.
96
Chapter 9
Conclusion
9.1 Summary
This thesis aimed to identify whether it was possible to make the
current information gathering phase of a penetration test more efficient
or not. Therefore, a new tool called “Twizzlers” was developed. When
a satisfactory minimum viable product of this tool was implemented,
experimental research was conducted to examine how this tool affected
the information gathering phase of a penetration test. After the
experiment was completed, an interview was conducted to acquire an
insight on how the penetration testers interpreted and understood the
tool used during the experiment. Based on the conducted research, I
found it possible to accomplish a more efficient information gathering
phase. However, the developed tool still needs some significant
improvements before the desired efficiency is wholly accomplished. In
the light of the overarching aim for this thesis, there were formulated
two research questions which will be answered next.
RQ1: How will a new reconnaissance tool affect time, resource

allocation and testing coverage in the information gathering
phase of a penetration test?
In general, when selecting a tool to make a method, process, phase,
or approach more efficient, it is essential to do careful investigations, so
the tool does not introduce more disadvantages than advantages.
After executing the experiment and following interview on how the
newly developed tool will affect time, resource allocation and testing
coverage in the information gathering phase of a penetration test,
the results from the evaluation show that it will beneficially affect
the three variables. The time used in the information gathering
phase will be decreased as the tool automates several time-consuming
tasks. Additionally, the tool provides a decent outline of more extensive
networks resulting in better performance of the remaining phases of
a penetration test. Consequently, the freed time make it possible
to allocate the resources in another way than today by adding more
resources to perform manual testing and with clients. Finally, the newly
97
developed tool will also increase the testing coverage by automating
tasks that are done manually today.
RQ2: What kind of functionality is needed in a new tool which

makes it beneficial for the penetration testers to apply it in their
work?
As shown in this thesis, there already exist several other tools that
may be used in the information gathering phase of a penetration test.
Therefore, it is vital that this newly developed tool introduces some new
functionality and/or advantages that the already existing tools do not
provide. The aim for Twizzlers is not to become a new vulnerability
scanner, like for instance Nessus is, but rather do reconnaissance more
efficiently and give the penetration testers an excellent overview of
where the most vulnerable parts are in the system. To achieve this
aim, Twizzlers needs to automate several scans that are performed
manually today to do reconnaissance. In addition, these scans need to
be run in parallel to make the scanning even more efficient. Moreover, to
provide an excellent overview of the scanning process, the penetration
tester needs to provide a vulnerability status and a testing status on
the results from the executed scan. Finally, Twizzlers must generate
a report that describes the vulnerabilities and testing coverage of the
targeted system.
Even though Twizzlers has fulfilled these system requirements to
a great extent, it still needs to be further improved to achieve the
beneficial effects explained in the answer of RQ1. However, the current
version of the tool has a great potential to be improved and eventually
achieve its aim. That being said, it is crucial to keep in mind that
the automated and manually testing complement each other - the
automated steps do not give all the information; we need to perform
manually testing as well. In addition, it is not possible to perform a
fully automated security test as the human creativity is still the most
robust tool.
9.1.1 Ethical Consideration

Most of the tools used for penetration testing today are open-source and
available to anyone who wants to explore the concepts of hacking. This
may result in black hat hackers using the tools for malicious purposes.
This may also apply to the newly developed tool, Twizzlers, but as of
today, this tool is not an open-source tool available for anyone to use.
Nevertheless, if this tool one day becomes an open-source tool available
for everyone, it is plausible to believe that black hat hackers may misuse
it. Even so, this is not the intention of the tool. This tool is intended to
be used by white hat hackers to make the information gathering phase
more efficient, thereby having more time for manual testing.
98
9.2 Future work
For Twizzlers to become the more efficient and usable tool the
penetration testers have in mind, there are still several elements that
need to be in place. First and foremost, the tool needs to provide more
automation of time consuming tasks and different techniques, such as
automatically discover new IP addresses and domain names. Further,
there is required more triggers that are run if certain conditions are
met, and several scans must run in parallel. Moreover, there should
be added the functionality needed for multiple people to use the tool
simultaneously. The future aims to get multiple agents (hosts) to run
and perform different parts of the scan. This may result in achieving
better and faster coverage of the targeted system. Additionally, when
multiple users use the tool simultaneously, each user should be provided
with an identification. This identification helps to show who is working
on the different findings. Furthermore, it may be beneficial for the
penetration testers to add more extensive comments on the different
resulting hosts to elaborate further on the progress and results of
the penetration testing. Finally, the usability in general needs to be
improved. The current version of Twizzlers is run in the Terminal,
which is not the ultimate solution for usability. To improve this, a proper
graphical user interface ought to be created.
Regrading the research, several experiments and interviews with
more participants need to be conducted aiming to reduce the bias of
the results and improve the functionality. Additionally, conducting
more experiments and interviews will be helpful to confirm or deny the
remaining hypotheses, H5 and H6.
99
100
Bibliography
[1] Azad M. Madni A. Terry Bahill. Tradeoff Decisions in System

Design. Gewerbestrasse 11, 6330 Cham, Switzerland: Springer
International Publishing AG. ISBN: 978-3-319-43710-1.
[2] Lawrence Abrams. TCP and UDP Ports Explained. Url:
https://www.bleepingcomputer.com/tutorials/tcp-and-udp-ports-
explained/. Mar. 2004.
[3] Mohammed M. Alani. Guide to OSI and TCP/IP Models. 1st ed.
Cham: Springer International Publishing AG, 2014. ISBN: 978-3-
319-05151-2.
[4] Rebecca Bevans. A guide to experimental design. Website:
https://www.scribbr.com/methodology/experimental-design/.
Revised on August 4, 2020. Dec. 2019.
[5] Kaushal Bhatt, Vinit Tarey and Pushpraj Patel. ‘Analysis Of
Source Lines Of Code(SLOC) Metric’. In: IJETAE Exploring
Research and Innovations 2 (Apr. 2012), pp. 150–154.
[6] Hossein Bidgoli. Encyclopedia of Information Systems. Contains
approximately 220 separate articles. The one used in thesis:
Systems Design by Jeremy Rasmussen, Pages 361-377. Academic
Press Imprint, 2002. ISBN: 978-0-12-227240-0.
[7] Paulino Calderon. Nmap: Network Exploration and Security
Aduiting Cookbook - Second Edition. 2nd ed. Livery Place, 35
Livery Street, Brimingham, B3 2PB, UK: Packt Publishing, May
2017. ISBN: 978-1-78646-745-4.
[8] PortSwigger Community. How to use Burp Suite for penet-
ration testing. Online on portswigger’s official website. Link:
https://portswigger.net/burp/documentation/desktop/penetration-
testing.
[9] Mike Crang and Ian Cook. Doing Ethnographies. DOI: https://dx-
doi-org.ezproxy.uio.no/10.4135/9781849208949. SAGE Publications
Ltd., 2007. ISBN: 9781849208949.
[10] Daniela Soares Cruzes and Lotfi ben Othmane. Threats to Validity
in Empirical Software Security Research. Url:
http://hdl.handle.net/11250/2470488. 2017.
101
[11] Arlin Cuncic. Understanding Internal and External Validity: How
These Concepts Are Applied in Research. Url:
https://www.verywellmind.com/internal-and-external-validity-
4584479. Sept. 2020.
[12] Thom Dixon. SaltwaterTaffy. Code on GitHub:
https://github.com/thomdixon/SaltwaterTaffy. First publish was
2013, has been done commits since. Aug. 2013.
[13] Sonia Dumitru. What is an Entity Diagram (ERD)? Link:
https://medium.com/@soni.dumitru/what-is-an-entity-relationship-
diagram-erd-13daee5b2a. Mar. 2020.
[14] Patrick Engebretson. The Basics of Hacking and Penetration
Testing, 2nd Edition. 2nd ed. 225 Wyman Street, Waltham, MA
02451, USA: Syngress, 2013. ISBN: 978-0-12-411644-3.
[15] Stephanie Glen. Experimental Design. "Experimental Design"
From StatisticsHowTo.com: Elementary Statistics for the rest of
us! https://www.statisticshowto.com/experimental-design/.
[16] Michael Gregg et al. Hack the Stack: Using Snort and Ethereal to
Master the 8 Layers of an Insecure Network. 1st ed. 800 Hingham
Street, Rockland, MA 02370: Syngress Publishing, Inc., Nov. 2006.
ISBN : 9780080507743.
[17] David Groth and Toby Skandier. Netowrk+ Study Guide: Exam
N10-003. 4th ed. 10475 Crosspoint Blvd., Indianapolis, Indiana:
Wiley Publishing, Inc., May 2005. ISBN: 9780782144062.
[18] Brian Hambling et al. Software Testing - An ISTQB-BCS Certified
Tester Foundation guide 4th edition. 4th ed. The Chartered
Institute for IT, First Floor, Block D, North Star House, North Star
Avenue, Swindon, SN2 1FA, UK.: BCS Learning Development
Limited, July 2019. ISBN: 9781780174921.
[19] Shon Harris and Fernando Maymí. CISSP, All-in-One Exam
Guide, Eighth Edition, 8th Edition. 8th ed. The address: McGraw-
Hill Education, 2018. ISBN: 978-1-26-014264-8.
[20] Kevin M. Henry. Penetration Testing: Protecting Networks and
Systems. 1st ed. Unit 3, Clive Court, Bartholomew’s Walk,
Cambridgeshire Business Park, Ely, Cambrudgeshire, CB7 4EA,
United Kingdom: IT Governance Publishing, June 2012. ISBN:
978-1-84928-373-1.
[21] ‘ISO/IEC/IEEE International Standard - Systems and software
engineering – Vocabulary’. In: ISO/IEC/IEEE 24765:2010(E).
1st ed. DOI: 10.1109/IEEESTD.2010.5733835,
EISBN: 9780738162058. IEEE, Dec. 2010, pp. 1–418.
[22] Nipun Jaswal and Sagar Rahalkar. The Complete Metasploit
Guide. Livery Place, 35 Livery Street, Brimingham, B3 2PB, U.K.:
Packt Publishing Ltd., June 2019. ISBN: 978-1-83882-247-7.
102
[23] Inc. Juniper Networks. Understanding IPv4 and IPv6 Protocol
Family. Url:
https://www.juniper.net/documentation/us/en/software/junos/
interfaces-security-devices/topics/topic-map/security-interface-ipv4-
ipv6-protocol.html.
Also in full PDF:
https://www.juniper.net/documentation/us/en/software/junos/
interfaces-security-devices/interfaces-security-devices.pdf. Mar. 2021.
[24] Himanshu Kumar. Learning Nessus for Penetration Testing.
1st ed. Livery Place, 35 Livery Street, Brimingham B3 2PB, UK:
Packt Publishing Ltd., Jan. 2014. ISBN: 978-1-78355-099-9.
[25] Philip A. Laplante. Requirements Engineering for Software and
Systems. 3rd ed. Applied software engineering series. 6000
Broken Sound Parkway NW, Suite 300, Boca Raton, FL 33487-
2742: Taylor Francis, CRC Press, 2017. ISBN: 9781138196117.
[26] Dahai Liu. Systems Engineering: Design Principles and Models.
1st ed. 6000 Broken Sound Parkway NW, Suite 300, Boca Raton,
FL 33487-2742: CRC Press, Aug. 2015. ISBN: 9781482282467.
[27] Gordon "Fyodor" Lyon. Nmap Network Scanning. Used free online
edition. Link: https://nmap.org/book/synscan.html. Insecure.Com
LLC, 2011. ISBN: 978-0-9799587-1-7.
[28] Gordon "Fyodor" Lyon. Nmap Network Scanning. Used free on-
line edition. Link: https://nmap.org/book/scan-methods-connect-
scan.html. Insecure.Com LLC, 2011. ISBN: 978-0-9799587-1-7.
[29] Gordon "Fyodor" Lyon. Nmap Network Scanning. Used free
online edition. Link: https://nmap.org/book/performance-timing-
templates.html. Insecure.Com LLC, 2011. ISBN: 978-0-9799587-
1-7.
edition. Link: https://nmap.org/book/man-host-discovery.html. In-
secure.Com LLC, 2011. ISBN: 978-0-9799587-1-7.
edition. Link: https://nmap.org/book/output-formats-cpe.html. In-
secure.Com LLC, 2011. ISBN: 978-0-9799587-1-7.
[32] S. A. McLeod. Experimental design. Simply Psychology.
https://www.simplypsychology.org/experimental-designs.html. Jan.
2017.
[33] Paul C. van Oorschot. Computer Security and the Internet.
Gewerbestrasse 11, 6330 Cham, Switzerland: Springer, Cham,
2020. ISBN: 978-3-030-33648-6.
[34] C.C Palmer. ‘Ethical Hacking’. In: IBM systems journal 40.3 (Sept.
2001). DOI: 10.1147/sj.403.0769, pp. 769–780.
103
[35] Crystal Panek. Networking Fundamentals. 1st ed. 111 River
Street, Hoboken, NJ 07030: Sybex, John Wiley Sons, Inc., Nov.
2019. ISBN: 978-1-119-65074-4.
[36] Jeff Petters. What is Metasploit? The Beginner’s Guide. Online.
Link: https://www.varonis.com/blog/what-is-metasploit/. This site
was updated 3/29/2020. Mar. 2020.
[37] PwC rated as a Leader among European and Asia Pacific Cyberse-
curity Consulting Providers. Url: https://www.pwc.com/gx/en/news-
room/press-releases/2019/forester-wave-cybersecurity-leader.html.
Nov. 2019.
[38] Russ Rogers. Nessus Network Auditing, Second Edition. 2nd ed.
30 Corporate Drive, Burlington, MA 01803: Syngress Publishing,
Inc. and Elsevier, Inc, Oct. 2011. ISBN: 978-1-59749-208-9.
[39] Zaid Sabih. Learn Ethical Hacking from Scratch. Livery Place, 35
Livery Street, Brimingham, B3 2PB, UK: Packt Publishing Ltd.,
July 2018. ISBN: 978-1-78862-205-9.
[40] Dhruv Shah, Riyaz Ahmed Walikar and Carlos A. Lozano. Hands-
On Application Penetration Testing with Burp Suite. 1st ed.
Livery Place, 35 Livery Street, Brimingham B3 2PB, UK: Packt
Publishing Ltd, Feb. 2019. ISBN: 978-1-78899-406-4.
[41] David Shaw. Nmap Essentials. 1st ed. Community experience
distilled. Livery Place, 35 Livery Street, Brimingham B3 2PB,
UK.: Packt Publishing Ltd., May 2015. ISBN: 9781783554065.
[42] Ian Sommerville. Software Engineering. 10th ed. Edinburgh Gate,
Harlow, Essex CM20 2JE, England: Pearson Education Limited,
2016. ISBN: 978-0-13-394303-0.
[43] Lauren Thomas. Independent and dependent variables. Website:
https://www.scribbr.com/methodology/independent-and-dependent-
variables/. Revised on September 18, 2020. May 2020.
[44] Lauren Thomas. Understanding confounding variables. Online:
https://www.scribbr.com/methodology/confounding-variables/. Re-
vised: April 2, 20201. May 2020.
[45] John R. Vacca. Computer and Information Security Handbook,
3rd Edition. 3rd ed. An optional note. 50 Hampshire Street, 5th
Floor, Cambridge, MA 02139, United States: Elseiver Inc., May
2017. ISBN: 978-0-12-803843-7.
[46] Vår Historie. Url: https://www.pwc.no/no/om-oss/historie.html.
[47] Dr. Stilianos Vidalis and Dr. Andrew Jones. Analyzing Threat
Agents Their Attributes. Tech. rep.
Url: https://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.104.6908rep=rep1type=pdf
DOI: 10.1.1.104.6908. Geo-Bureau Ltd, 47 Cowbridge Road,
Pontyclun, Rhondda Cynon Taf, UK, CF72 9EB: Geo Bureau.
104
[48] Georgia Weidman. Penetration Testing. 1st ed. No Starch Press,
May 2014. ISBN: 9781593275648.
105
106
Appendix A
Interview Template
Interviewer: Date: Time:
Penetration Tester: Place:
1. There already exists several different tools used in the

information gathering phase. Would you use another one?
2. How will Twizzlers impact business performance?
3. How will Twizzlers be introduced in the information

gathering phase?
4. How will Twizzlers evolve over time?
5. How much time do the team use on penetration testing

now - both on the whole penetration testing process and
exclusively in the information gathering phase?
6. How can Twizzlers assist to affect the time used today?
7. How much of the targeted system is covered during a

penetration test today?
8. Do you think today’s testing coverage will be increased by

using the new tool?
(a) If yes: Why do you think so, and how do you think it
will help to increase the testing coverage?
(b) If no: Why not?
107

The Development of A Reconnaissance Tool Aiming To Achieve A More Efficient Information Gathering Phase of A Penetration Test

Uploaded by

Copyright:

Available Formats

The Development of A Reconnaissance Tool Aiming To Achieve A More Efficient Information Gathering Phase of A Penetration Test

Uploaded by

Document Information

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

The Development of A Reconnaissance Tool Aiming To Achieve A More Efficient Information Gathering Phase of A Penetration Test

Uploaded by

Copyright:

Available Formats

The Development of a

Reconnaissance Tool Aiming to

Thesis submitted for the degree of

The Development of a Reconnaissance Tool Aiming to Achieve a More

Printed: Reprosentralen, University of Oslo

Background. Ethical hacking is an approach whereby hackers

Aim. This thesis aims to outline an approach that allows penetration

Method. In this thesis, I have developed a reconnaissance tool aiming

Results. Findings suggest that by introducing a new reconnaissance

Conclusion. Implementing the developed reconnaissance tool in the

Keywords: ethical hacking, penetration test, penetration testing.

In 2016, I enrolled into the study program called Informatics: Program-

5 Twizzlers’ System Design 51

A Interview Template 107

2.1 The relationship between a the five security terms.

3.1 My research process throughout the thesis. . . . . . . . . . 32

4.1 The functional and non-functional requirements. . . . . . . 42

5.1 Block diagram showing the high-level structure of the

6.1 The method of executing a host discovery. . . . . . . . . . . . 70

7.1 The presented menu at start-up. . . . . . . . . . . . . . . . . 76

4.1 Formulated user stories with associated requirements. . . 47

In this chapter, I will present the introduction to my master thesis.

1.3 Research Questions

RQ1: How will a new reconnaissance tool affect time, resource

RQ2: What kind of functionality is needed in a new tool which

1.4 Structure of the Thesis

Chapter 3: Research Process outlines the research method used for

Chapter 4: Requirement Analysis presents the conducted process

Chapter 5: Platform Design presents an overview of the architec-

Chapter 6: Platform Implementation explains the chosen program-

Chapter 7: Evaluation presents my findings from data collection and

Chapter 8: Conclusion summarizes and concludes the thesis as a

The purpose of this chapter is to introduce information security,

2.1 Information Security

2.1.4 The Five Security Terms

• Threat: Taking advantage of a vulnerability and thereby becom-

• Risk: The likelihood of a vulnerability being exploited by a threat

• Exposure: With the occurrence of a vulnerability, the organiza-

• Countermeasure: Actions taken to reduce the potential risks.

2.2 Malicious Hacking vs. Ethical Hacking

2.3.1 Penetration Testing – Step by Step

In the pre-engagement step, the penetration testing team and the

The next step is Information Gathering. This step involves gathering

Further, the penetration testers deliberately seek out vulnerabilities

Next is the Post Exploitation step. In this step, penetration testers

2.3.2 Penetration Test vs. Vulnerability Scanning

2.3.3 Internal vs. External Penetration Test

2.3.4 Black, White, and Grey Box Penetration Testing

2.4 The Computer Network

2.4.1 OSI Model

2.4.2 IP address, Ports, and Services

2.4.3 Internet Control Message Protocol (ICMP)

1. Report network errors: This may for instance include the

2. Report network congestion: There may be an incident where a

3. Troubleshooting: This mechanism is used in the ping and trace

4. Report timeouts: If a packet’s Time To Live (TTL) reaches

2.4.4 Transmission Control Protocol (TCP)

Both the Sequence and Acknowledgement Number fields contain

• URG: Indicates that the value in the Urgent Pointer field is