MANCHESTER METROPOLITAN UNIVERSITY

FINAL YEAR DISSERTATION

Exploring the effectiveness of honeypots

in identifying cyber threats

Author: Supervisor:
Gozie Chukwudi Dr Alex Akinbi
22520279

Degree: Department:
Computer Forensics and Security Computing and Mathematics

Faculty:
Science and Engineering

May 2024
Declaration
No part of this project has been submitted in support of an application for any other degree
or qualification at this or any other institute of learning. Apart from those parts of the project
containing citations to the work of others, this project is my own unaided work. This work
has been carried out in accordance with the Manchester Metropolitan University research
ethics procedures and has received ethical approval number 77469

Signed

_Gozie Chukwudi__________________________

i
Abstract
In the domain of cybersecurity, honeypot solutions are a commonly used technology to
gain further intelligence on attacker behaviours and patterns. The element of
deceptiveness plays a key role into this technology. Although, in a scenario whereby the
attacker has awareness before interaction and attacks a honeypot, how will the honeypot
react? Will there be a halt in its operations? This project seeks to provide answers to these
dilemmas through the development of a honeypot experiment. The project consists of a
range of orchestrated attacks on a honeypot to examine its reaction when subject to
various attack methods.

ii
Table of Contents
DECLARATION ...................................................................................................................................................I
ABSTRACT ........................................................................................................................................................II
LIST OF FIGURES............................................................................................................................................. IV
LIST OF TABLES ............................................................................................................................................... V
ABBREVIATIONS ............................................................................................................................................ VI
1. INTRODUCTION ...................................................................................................................................... 1
1.1. PROJECT BACKGROUND ............................................................................................................................. 1
1.2. AIM AND OBJECTIVES ................................................................................................................................ 2
1.2.1. Aim ............................................................................................................................................. 2
1.2.2. Objectives ................................................................................................................................... 2
1.3. DISSERTATION STRUCTURE ......................................................................................................................... 2
2. LITERATURE REVIEW ............................................................................................................................... 4
3. DESIGN ................................................................................................................................................. 12
4. IMPLEMENTATION .................................................................................................................................. 1
4.1. PROJECT SETUP ........................................................................................................................................ 1
4.2. TESTING AND RESULTS ............................................................................................................................... 9
5. EVALUATION ........................................................................................................................................ 14
6. CONCLUSIONS ...................................................................................................................................... 17
6.1. COMPLETED WORK................................................................................................................................. 17
6.2. IMPLICATION OF FINDINGS ........................................................................................................................ 17
6.3. PROBLEMS ............................................................................................................................................ 17
6.4. PERSONAL REFLECTION ............................................................................................................................ 18
6.5. LIMITATION AND FUTURE WORK ............................................................................................................... 18
REFERENCES................................................................................................................................................... 19
APPENDICES................................................................................................................................................... 22

iii
List of Figures
Figure 1 - Attacker and Defender views during attack (Ilg et al., 2023) ................................... 4
Figure 2 - LH, MH and HH architecture (Ilg et al., 2023) ......................................................... 8
Figure 3 -Flowchart of Experiment.......................................................................................... 12
Figure 4- Design of Honeypot System Architecture.................................................................. 1
Figure 5 - Attack VM ................................................................................................................. 1
Figure 6 - Honeypot VM............................................................................................................ 2
Figure 7- Installation of Cowrie dependencies .......................................................................... 3
Figure 8 - Cloning of Cowrie from GitHub ............................................................................... 3
Figure 9 - Virtual Environment.................................................................................................. 4
Figure 10 - Cowrie Status .......................................................................................................... 5
Figure 11 - IP config of Cowrie ................................................................................................. 6
Figure 12 - IP config of Attacker VM ....................................................................................... 7
Figure 13- SSH services activated ............................................................................................. 8
Figure 14 - Honeypot log functionality ..................................................................................... 8
Figure 15 - Brute Force users text file ..................................................................................... 10
Figure 16 - Brute Force password text file .............................................................................. 11
Figure 17 - Brute Force Attack Command .............................................................................. 11
Figure 18 - Honeypot SSH credentials .................................................................................... 12
Figure 19 - Honeypot Log........................................................................................................ 12

iv
List of Tables
Table 1 - Existing honeypot solution breakdown ...................................................................... 8
Table 2 - Configuration Tests .................................................. Error! Bookmark not defined.
Table 3 - Attack results ............................................................ Error! Bookmark not defined.

v
Abbreviations
Abbreviation Description
IDS Intrusion Detection System
DTK Deception Toolkit
LH Low - interaction Honeypot
MH Medium - interaction Honeypot
HH High interaction – Honeypot
CVE Common Vulnerabilities and Exposures
ICS/SCADA Industrial Control Systems/Supervisory Control and Data
Acquisition
LLM Large Language Models
NP Nondeterministic Polynomial time
OS Operating System
GPT Generative Pre-trained Transformer
UAV Unmanned Ariel Vehicle

vi
1. Introduction
This chapter gives a detailed summary of the project topic, with explanation concerning the
work that will be conducted. From this chapter, a generic concept of the problem and
projects solution will be gathered.

1.1. Project Background

Within the scope of cybersecurity, popular defence methods such as firewalls or IDS fail
to meet their standards when addressing cyber threats proactively. They are designed to
be reactive, only responding once an attack has been triggered. A survey was published
by Wakefield Research in 2022 involving 250 senior cybersecurity executives from
multiple business sectors. 61% of participants strongly believed that similar approaches
are not sufficient in handling incidents (Mike,2022).

In response to this challenge, honeypots have proven to be a standout tool, imposing

themselves as a proactive defence solution. This technology operates by tricking
attackers through simulating the appearance of a vulnerable system, effectively baiting
attackers to engage. The moment the honeypot is engaged with by an attacker, their
movement, actions, and behaviour can be monitored, revealing key insight into possible
attack approaches. Adoption of honeypot solutions is noticeable in the market. On a
global scale, the honeypot market is estimated to be valued at around $1.2 billion, with a
potential increase to $4.3 billion before 2032 (Sharma, 2024).

While this approach sounds optimistic, it raises a problem about its deceptiveness. In a
case where the perpetrator is aware of the existence of the honeypot before interaction,
the value and relevance of the honeypot fundamentally decrease, rendering it useless.
This issue reveals that the level of success a honeypot experiences is directly linked to
its ability to remain undetected during operation. Such an event can occur due to many
reasons, such as through reconnaissance tools or prior experience from the attacker. In
such a case, the perpetrator now has leeway to conjure cyberattacks of their choice
against the honeypot system.

From this dilemma, an abundance of questions can be posed. Is the honeypot able to
effectively continue it operation even when exposed? Does the behaviour of the system
alter when under attack? Is there a sense of deterioration, malfunctioning or adjustment

16
 within the system? This report aims to deliver answers to such questions through the
route of experimental research.

1.2. Aim and Objectives

1.2.1. Aim

The aim of the project is to configure and deploy a honeypot using Cowrie located
on a controlled virtualised environment. Once completed a range of cyberattacks will
be orchestrated targeting the honeypot, with the expectation of witnessing and
evaluating its coping mechanisms and reaction when exposed to attacks.

1.2.2. Objectives

The objectives of this project are as follows:

• Examine existing research based on honeypot solutions. Study their

functionality and behaviours

• Configure and deploy honeypot within chosen virtualised environment

• Design and execute specific cyberattacks to target honeypot with. Attempt to

be similar to real-world scenarios

• Inspect logs and interactions to analyse honeypots performance and stability

during attacks

• Evaluation on the honeypot’s performance and stability during stages of the

attacks.

1.3. Dissertation Structure

• Literature Review

This chapter reviews existing research on both academic and industry level
based around these concepts: honeypot technologies, Cowrie honeypot and
other similar platforms, attack mechanisms towards honeypots and
challenges towards implementation. The purpose of this chapter is to
pinpoint any aspects that can be used within the experiment
16
• Design

This chapter discusses the overall design of the experiment. Key

requirements of the honeypot system will be detailed. In addition, the
reasoning behind choices of attack will be thoroughly explained

• Implementation

This chapter reveals the entire implementation phase of the project, showing
the configuration of the virtual environment and activation of the honeypot.
Formation of cyberattacks against the honeypot will occur, showcasing the
results afterwards. Additional dependencies, software or network
configurations will be outlined.

• Evaluation

This chapter evaluates the success of the project through comparison

between its initial aim and objectives to the outcome.

• Conclusion

This chapter brings a close on the dissertation, providing a comprehensive

conclusion of the project. Judgment will be placed on the degree of success
achieved through completed works. Limitations experienced will also be
discussed, finally offering potential pathways to future works.

• References

This section contains a comprehensive list of work that was cited in this
dissertation

• Appendices

The end of this dissertation provides the appendices, any supporting

documentation that was mentioning within the main body will be listed here

16
2. Literature Review
This chapter will provide an extensive review on current literature based on the theme of
honeypots, focusing on architecture, functionalities, and the various types currently
available. Several challenges involving this technology will also be examined/

Honeypots have proven to be an essential tool for modern-day cybersecurity. The genesis
of this technology dates back to the 1980s, when Clifford Stoll introduced the concept of
honeypot, documented in his book “The Cuckoo’s Egg”, although no action was taken
upon his ideas. However, in 1998, there was an uprise in momentum through the
incorporation of multiple developers, creating the initial set of honeypot tools, such as
the DTK, formed by Fred Cohen, and Honeyd, created by Niels Provos. By 1999, the
idea of a proactive network defined in substitute for a reactive defence rapidly gained
popularity among individuals within the technological space (Yang et al,
2023). Honeypots are described as “dummies”, decoy resources that are utilised to
portray an authentic and vulnerable system, whereas in reality, its fake (Ilg et al.,
2023). Figure 1 captures such an event. An attacker may be fascinated by the so-called
system, intriguing them to the point of interaction. From here, any actions, commands,
or prompts performed by the attacker will be logged, providing analysis of the nature of
the attacker's operation. Due to honeypot's capabilities, other technological sectors seek
to implement the use of honeypots Franco et al., 2021), although M.R. and P (2022)
suggest that the inclusion of honeypots rarely improves security posture.

Figure 1 - Attacker and Defender views during attack (Ilg et al., 2023)

16
There is a diverse range of honeypots, each customised to different environments,
security goals, and resource constraints. In order to gain a more precise understanding of
honeypot variations, the honeypots discussed can be grouped based on 3 chosen
principles: technology, purpose, and interaction level. Such a framework that provides
classification to honeypots is viewed as important within the literature and endorsed by
researchers. Research conducted by Rabzelj et al (2023) dwells on the area of
specification, discussing the attributes, architecture, and functionalities of various
solutions.

Technology Based

Malware honeypots are intentionally created to lure in malicious software, known as

malware, geared towards deeply analysing its characteristics, behaviours, or any
mechanisms that it functions with. Once malware has interacted with the honeypot, the
honeypot will then capture the malware within the system. A more advanced honeypot
is capable on identifying malware through its CVE ID. In addition, each ID of malware
spotted will be tracked to observe the most frequent variant of malware.

Database honeypots imitate real-life database systems, e.g., SQL or MongoDB, to lure
in threats. They pose as such systems in a vulnerable state for the attraction of attackers
to perform attacks, e.g., SQL injections. In a case where an attacker tries to interfere
with the system, information is provided based on their activities for further research.

Email honeypots functions through handling common attacks targeted at emails e.g.
phishing, attachments filled with malware, spam etc. The honeypots are able to generate
fake email addresses, not intended to be utilised for communication. This approach
certifies that any email making initial contact with the fake accounts are deemed as
malicious.

Spam honeypots are similar to their email counterparts, but there is differentiation in their
implementation and purpose. Spam honeypots are often stationed on a website, used to
capture spam messages from emails.

Spider honeypots are created to lure in and catch web crawlers, automated bots that seek
to move around websites. When on these websites, the bots perform malicious activity,
such as stealing private information or exploiting security gaps within the website. Spider

16
honeypots solve this issue. By being implemented on web servers, they emulate URLS
and web pages, as well as other data that presents the system as a target for the bots.

Honeynets are networks of numerous honeypots, positioned to create a network

environment. A standard honeypot does not include many systems within itself, but with
this variant, it contains several network systems e.g. servers and applications. From an
attacker’s viewpoint, this would look similar to the architecture of a network belonging
to a decent-sized organization, filled with bundles of data that could be stolen. Normally,
data from each honeypot will be driven to a central location, allowing tracking alerts
much more easily (Zielinski and Kholidy, 2022).

Purpose Based

As the name suggests, research-based honeypots are variants tailored to identifying

attacker behaviours and techniques. By deployment, these solutions replicate vulnerable
systems in the hope of attracting attackers to interact with the trap. From here, research
personnel obtain data concerning the attackers’ strategies. Examples of research-based
honeypots include high interaction honeypots such as Cowrie and HoneyIoT. Similar
technology can mimic services that can be made a point of interest to threats, making it
hold value for investigational purposes. Many ideas of integration have been
brainstormed to increase the effectiveness of this class of honeypots.

Machine Learning implementation with honeypots has been leading in the race for a more
proficient solution, aiding honeypots' abilities the more. Human involvement is not
necessary, as adaptable honeypot configurations can automatically deploy and control
honeypot systems. (Fraunholz et al., 2021) The domain of IoT sees glimpses of research
honeypots being used, with some honeypot architecture designs being used to handle
complex problems relating to IoT devices and their security. (Surber and Zantua, 2022)

Production honeypots are purposely located within operational systems to pick out
attacks or signs of attacks in a quick response. Compared to research honeypots that pivot
towards the collection and analysis of data captured, this class is created to merge with
already functioning systems that contain real services. Aggarwal et al. (2021) promote
the addition of deception techniques to improve the usefulness of production honeypots,
such as the manipulation of the honeypot and machine features.

Interaction Based
16
Low interaction honeypots (LHs)

LHs emit the lowest interaction for attackers when they engage with the system. This
specific honeypot type has no operating system, instead offering a limited number of
attack avenues. Since emulation of services is possible with honeypots, such avenues
include servers and login shells. Such honeypots are normally utilised for low-end
attacks, such as brute force. Figure 2a presents the architecture of an LH. This solution
provides a more inexpensive solution, beneficial for environments with few resources
(Moric et al., 2025). However, research undertaken revealed the effectiveness of this kind
compared to honeypots with higher interaction levels in collecting attack data. HHs were
deployed alongside LHs. 76.12% of attack packets and 70.61% of unique attacker IPs
were recorded. On the other hand, 23.88% of attack packets were captured, with 29.39%
unique attacker IPs being identified (Kocaogullar et al., 2022).

Medium interaction honeypots (MHs)

MHs described by Moric et al. (2025) act as a balance for low and high interaction
honeypots, providing attacker interaction alongside controlled resource needs. MHs still
don’t give a legitimate operating system, although a simulation of real system processes
is available e.g., file systems or shell, where you can execute commands on. Due to this,
the honeypot conveys an appealing system for attackers. Figure 2b shows the honeypot
is apart from the OS. The emulation of the file systems is the trap in this case, which will
then produce logs of gathered intelligence once contacted by attackers. MHs are also
present in other domains, such as in the research of UAVs, assisting in their security
development (Jamil et al., 2024)

High interaction honeypots (HHs)

An HH example includes Window based honeypot HoneyWin, created to emulate IT

environments (Aung et al., 2025). This form of honeypot has increased chances of,
compared to other types. Here a functional operating system poised as vulnerable is
located. Although HHs bring the best results in terms of performance and data collection,
simultaneously the level of maintenance needed, and resource demands are significant.
Figure 2c shows the attacker having access to interact with the OS.

Table 1 presents examples of existing honeypot solutions, added with their features, use
cases, interaction level, and disadvantages.
16
 Figure 2 - LH, MH and HH architecture (Ilg et al., 2023)

Honeypot Interaction Features Best Use Case Disadvantages

Solution Level
Cowrie Medium Mirrors shell Analyzing brute Unable to run real
environment and force attacks and malware.
fake filesystem. Post-auth Only applicable to virtual
Captures environment
SSH/Telnet
commands.
Dionaea Low Records malware Collection and No command interaction;
payloads analysis of no deep engagement
Mirrors services malware
e.g. SMB,
HTTP, FTP
Honeyd High Simulation of Network Outdated solution, hard to
numerous hosts deception configure
with OS
fingerprints
Conpot Medium Emulation of Monitoring System not useful outside
ICS/SCADA infrastructure of of ICS, small scope
protocols industrial
organizations
T-Pot High Incorporation of Installation of Requires powerful system
honeypots e.g. multi honeypot to operate
Cowrie Dionaea. solutions
Addition of slack (centralized)
Table 1 - Existing honeypot solution breakdown

16
Review of challenges and limitations

Using the year range of 2021 – 2025, challenges and limitations within the scope of the
implementation, operation, development and architecture of honeypots were researched.
Multiple papers were reviewed, each discussing their unique honeypot proposals, although
each encountered some sort of complexity within their solutions.

Grigoriou et al. (2022) expose challenges in relation to honeypot incorporation within

ICS/SCADA systems. Deceptiveness and isolation are outlined as key issues. Due to the
insufficient number of protocols and communication methods within these systems,
perpetrators will have the ability to notice inconsistent or questionable behaviours in the
honeypot. This then brings up the task of attempting proper isolation to stop attackers from
gaining access to the legitimate system. Furthermore, the authors argue that operational
requirements of the ICS create restrictions, as the addition of honeypots could in fact disrupt
its operation, causing problems such as downtime.

Sladic et al (2024) propose the utilization of LLMs to drive next-generation honeypots

providing responses to attackers automatically within a shell environment. An issue arises
in relation to realism. GPT, an example of an LLM, possesses the ability to produce shell
interactions similar to a human. However, the responses generated are of an unpredictable
nature, potentially generating feedback that suggests to an attacker that the system is an
artificial creation. In addition, honeypots are able to create excessive amounts of event
information stored within their logs. The significance of this data can be beneficial, but it
can simultaneously allow the introduction of noise to signal issues. This happens when
honeypots are bombarded with low-value attacks, e.g., automated scans. From this point,
security personnel will be tasked to discern signs of threats occurring from background
noise, either through human assessment or complex filtering.

Raghul et al. (2024) focused on the combination of IDS and honeypots in order to construct
a proactive defence mechanism. The difficulty of this innovation is the technical complexity.
Both IDS and honeypots operate using specific data formats, frameworks for analysis, and
procedures for collecting data, so attempting to balance both solutions' inputs and outputs
without any performance problems will be essential. Additionally, the authors indicated
attention towards the honeypot system itself, emphasising that the system should be isolated.
16
Robust network architecture, e.g., network segmentation, would be convenient to prevent
attackers from using exploited honeypots to gain access to real systems.

Usman explores challenges involving intrusion detection. The study highlights an alarming
concern based on how attackers have generated new techniques to pinpoint and bypass
honeypots. The study gives prime illustrations of such techniques, such as OS fingerprints,
filesystem responses, and others. The authors mention that honeypots long term
sustainability remains in serious doubt, only if they are optimised to precisely simulate a
full system. (Usman et al., 2024).

Within this study, Selian et al. (2024) experimented with a Cowrie honeypot, taking
observations of logs over a period of time. However, Cowrie is manufactured as a medium-
levelled interaction honeypot, meaning that only a small percentage of the operating system
is modelled, with attackers denied full system access. As a result, engagement is restricted,
leading to inaccurate data logs of attacker activity. Another challenge the study shows is
towards the realism of a honeypot. The author argues that the honeypots lack the ability to
simulate targets with value, e.g. SSH endpoint, restricting their effectiveness to entice
attackers.

This research by M.R and P (2022) highlights the costly nature of upkeeping honeypots. A
precise OS and service imitation is vital in building a seemingly realistic environment, as
well as updates on software versions. Using high interaction honeypots will demand
ongoing monitoring and maintenance to protect them from being compromised by attackers.
Another challenge identified in this study addresses the correlation of events/alerts and noise
management. Correlation of events from both a honeypot and IDS systems is challenging,
relying on a SIEM solution to produce relevant data.

Zaman et al (2024) focus on the operational impact honeypots have on businesses. Adoption
into live environments poses multiple dangers, especially in a case where it's mistakenly
engaged with by authorised users. If poorly segregated, this may contribute to false positives
or performance issues. Furthermore, production networks are extremely performance-
limited, meaning that deploying such high-interaction honeypots needing substantial system
resources will prove to be a risk.

Finally, Katakwar et al (2022) examined the aspect of human behaviour and decision
making when faced with a honeypot, with a huge emphasis on attacker psychology. The
16
research concluded that the responses of attackers to honeypots can differ and are not always
as predictable. Another route of exploration in the study was witnessing the effects of
changing honeypot density (e.g., proportion of honeypots to the legitimate system) on
attacker behaviour. Although the problem in this case was finding the optimal balance.
Implementing a low number of honeypots increases the odds of an attacker not being
deceived. On the other hand, implementing a high number of honeypots can heighten the
chance of discovery, causing an attacker to disengage or modify their approach.

The presented studies reveal that despite honeypots being crucial for threat detection and
research purposes, the level of effectiveness and efficiency is tied down to multiple factors,
such as legal boundaries, scalability restraints and attacker expertise. In addition, a
consequential amount of engineering work will be necessary to preserve and enhance their
security, realism and stealthy nature.

16
3. Design
This chapter contains ideas and documentation of the design process. All reasoning
behind the choice of tools and components will also be listed. Before discussing on the
design 3 requirements have been set out to shape its developments, which are the
following:

• Requirements 1 – Should include common services e.g. SSH, Telnet. Host

machine and honeypot should contain basic security measures e.g. root users
and password.

• Requirement 2 - Configuration of honeypot to permit range of attacks to

occur.

• Requirement 3 – Configuration of Cowrie to simulate Linux shell

environments

Design Technique – Scenario Based

For the design technique, a scenario-based design was the optimal choice for the project.
Due to the series of hypothetical questions stated in relation to the problem, this technique
will path a design customed to such events. Fundamentally, this methodology looks at
the development of systems based on given scenarios, with the objective to observe
potential results. For this project in particular, the “scenarios” are attacks targeted
towards the honeypot. In addition, it is important that these scenarios or attacks are
realistic, a reproduction of situations that can happen in real life to improve the standard
of results obtained from the experiment. Figure 3 presents a basic flowchart design,
showing the flow of procedures.

Figure 3 -Flowchart of Experiment

16
System Architecture

Attack Structure

16
Figure 4- Design of Honeypot System Architecture

16
4. Implementation
In this chapter, discussion of the setup and results of the experiment is presented. Any
necessary commands utilised for the procedure will also be included. Any problems faced
whilst conducting the experiment will be addressed. Finally, an inclusion of testing of
key components of the experiment.

4.1. Project Setup

Firstly, both virtual machines were created through VirtualBox. Each machine had the
identical number of resources given, sufficient for their roles in the experiment. Figures
5 and 6 supports this with more detail, showcasing the allocated distributed RAM, hard
disk sizes and process cores. Beforehand, an ISO image was required for the machines
operating system. An ISO is a digital image of the content from an optical disc.
VirtualBox is capable of emulating a CD ROM drive for the ISO, allowing the
installation of the operating system. For the attacker VM, a Kali Linux 2025.1c image
was downloaded and selected. For the honeypot VM, the Ubuntu 20.4 was likewise
downloaded and selected. In terms of connectivity between machines, both incorporate
a Bridged Adapter.

Figure 5 - Attack VM

16
 Figure 6 - Honeypot VM

Now inside the virtual machine for the honeypot, the next step was to begin the
installation of Cowrie. The download was possible thanks to the provision of the official
Cowrie installation guide. Firstly was to navigate to the terminal and execute the
following sudo command as presented in Figure 7:

“sudo apt-get install git python3-pip python3-venv libssl-dev libffi-dev build-essential

libpython3-dev python3-minimal authbind”

When executed, the command installs the required software packages and tools needed
for Cowrie to correctly operate. Important bits from the command are as follows:
Authbind is crucial for the honeypot, as it creates the ability for Cowrie to bind itself to
“lower network pots”, a term labelled for the most common or well-known ports services
used. For this experiment port 22 (SSH) will be used. Pip,venv and minimal are Python
coded tools used to conduct management of the environment. Libssl-dev library supplies
files for OpenSSL, suited for encrypted communication. Once completed the following
command shown in Figure 8 was executed, which takes a copy of Cowrie’s source
directly from the repository located on GitHub. Once obtained, a new local directory
named cowrie will be created, containing folders, files and other metadata:

16
“git clone http://github.com/cowrie/cowrie”

Figure 7- Installation of Cowrie dependencies

Figure 8 - Cloning of Cowrie from GitHub

The next action was to create and activate the virtual environment, portrayed in Figure
9. The command changes the original shell environment, to the brand-new environment
with the name “cowrie-env”. As a result of this, all commands whether pip or Python are
sent towards the new environment. With Cowrie operating, insolation guarantees
containment of all previously downloaded libraries inside the environment. Visually, the
command has been executed successfully due to the change of the command prompt
regarding its active environment “(cowrie-env) who@honeyp:” As seen in Figure 10,
another set of installations occurs through the shown command. The first command
shows an upgraded on the pip to the most recent version. The next command involves
16
the “requirements.txt” file, which is read from the Cowrie directory. The file essentially
contains information regarding to the dependencies versions in order for Cowrie to
perform as expected.

Figure 9 - Virtual Environment

Activation of Cowrie, Check of status

16
 Figure 10 - Cowrie Status

IP configuration of both machines

16
Figure 11 - IP config of Cowrie

16
 Figure 12 - IP config of Attacker VM

SSH services running on honeypot

16
 Figure 13- SSH services activated

Logs functioning, ready to generate information

Figure 14 - Honeypot log functionality

16
4.2. Testing and Results

During the project setup a range of tests were included to validate the. Table 2 presents
these configuration tests

Test Description Expected Result Pass or

No. Fail
1 Ping test. Check connectivity from Ping successfully accepted Passed
attack to Honeypot IP by honeypot machine
2 See open ports through Nmap Port 22 open, Cowrie port Passed
2222 open (fake port)
3 IP configuration of honeypot (include Correct IPs configured for Passed
attacker) both machines
4 Installation of appropriate resources for Cowrie and attack tools Passed
Cowrie installed with latest
versions
5 Test for SSH login from attacker VM Attacker VM unable to Passed
SSH into target VM

Example Attack - Brute Force SSH

Addition of multiple login entries for user and password text files

53 possible users

16
Figure 15 - Brute Force users text file

16
 14 possible passwords

Figure 16 - Brute Force password text file

Brute Force Attack ssh

Figure 17 - Brute Force Attack Command

16
 Figure 18 - Honeypot SSH credentials

Figure 19 - Honeypot Log

Table 3 presents the details of all the attacks, detailing the tools used, description, and
the eventual outcome
16
Attack Name of Attack Tool Method Description Attack Outcome
No
1 SSH Brute Force Hydra SSH login attempts Honeypot was able
are orchestrated at a to capture all login
quick-fire rate through attempts Attack was
a password/username able to get required
list credentials of
honeypot

2 Bash command SSH and Bash Large amounts of Similar to previous

script commands executed attack, honeypot was
able to log all
commands
3 Simulated malware SSH and wget Simulation of No response from the
upload loop downloading malware honeypot
files into Cowrie
system
4 Nmap SSH Service Nmap with Range of high Nmap was able to
Fuzzing ssh scripts intensity request get port numbers.
directed at SSH Honeypot still
service upheld stability and
logged

16
5. Evaluation
The project aim was to create a functional honeypot system and create multiple attack
techniques to target the honeypot with, analysing its response during these attacks. In this
chapter the outlined aim and objectives will be compared against the actual achievements and
results of the project.

5.1. Fulfilment of aims and objectives

Aim - The aim of the project is to configure and deploy a honeypot using Cowrie located
on a controlled virtualised environment. Once completed a range of cyberattacks will be
orchestrated targeting the honeypot, with the expectation of witnessing and evaluating its
coping mechanisms and reaction when exposed to attacks.

This aim has been achieved. The project consists of the Cowrie honeypot located within a
virtual machine. Tailored attack methods were then constructed to target the honeypot,
outputting results detailed within Chapter 4.

Objective 1 - Examine existing research based on honeypot solutions. Study their

functionality and behaviours

This objective has been met. Presented in Chapter 2, an in-depth literature review based on the
current research of honeypot technologies, their functions, similar experiments and
classification are shown. The goal for the objective was to gain knowledge about this
technology, utilizing it for the design stage.

Objective 2 - Configure and deploy honeypot within chosen virtualised environment

This objective has been met. The project declares of the chosen virtual environment, which
was created through VirtualBox. On an Ubuntu OS, the Cowrie honeypot was downloaded
configured and deployed to meet the needs of the experiment.

Objective 3 - Design and execute specific cyberattacks to target honeypot with. Attempt
to be similar to real-world scenarios

This objective has been accomplished to a degree. Some of the attack methods used for the
project weren’t tailored towards Cowrie (SSH honeypot), such as the malware upload, which
is used generally, not specifically for SSH honeypots. Lack of available research based on
attacks limited the depth of attacks.

16
Objective 4 - Inspect logs and interactions to analyse honeypots performance and stability
during attacks

This objective has been met partially. Logs containing data of the attacks were presented, only
for the SSH attack. In addition, other areas of analysis should have been explored apart from
the logs.

Objective 5 - Evaluation on the honeypot’s performance and stability during stages of the
attacks.

This objective has been partially met. Within this chapter and the previous, the captured results
from attacks orchestrated on the honeypot have been evaluated. However, the objective states
observation during multiple stages. This might not have been fully reflected within Chapter 4,
only showing figures of the aftermath from the honeypot’s perspective.

5.2. Fulfilment of design requirements

Requirements 1 –Should include common services e.g. SSH, Telnet. Host machine
and honeypot should contain basic security measures e.g. root users and password.

The requirement was met. Cowrie already has SSH and Telnet services, so it was just a
case of downloading and activating them. The host machine however was completely
configured from scratch, adding security measures to the machine to provide realism to
the experiment.

Requirement 2 - Configuration of honeypot to permit range of attacks to occur.

This requirement was completed to an extent. Cowrie’s honeypot configuration files

permit you to make changes to its functions. The system focuses more around SSH and
Nmap based attacks. Specifically for the malware upload technique challenges grew in
terms of shaping the honeypot to handle it, as Cowries factory settings are not geared to
malware-based attacks.

Requirement 3 – Configuration of Cowrie to simulate Linux shell environment.

16
This requirement was completed. The file structure within Cowrie was designed to mirror
Linux environment. Multiple shell commands were tested to see their outputs. File
permissions and additional directories were included.

16
6. Conclusions
This chapter will draw a close on the project, together with an assessment of the level of
completion, problems faced during the project duration, and a discussion of potential
future work.

6.1. Completed Work

Overall, the project was a success. The project was created to bring solution to a
hypothetical question stated at the start. The aim was to witness the stability and
functionality of a honeypot once under attack. Firstly, research was needed to grasp the
concepts of honeypots, what type are available, and their functions. Using the knowledge
gained, I then used Cowrie, to configure and deploy the honeypot system in a virtual
setting used for the experiment. Research into the class of attacks that real honeypots face
was also done to aid me picking out the methods I wanted to replicate for the experiment,
although the standard of attacks could have been better. All the results from each attack
scenario were recorded.

6.2. Implication of findings

Findings from this research convey that despite attackers notice the presence of
honeypots and conduct attacks towards the system, Cowries functionalities never cease
and continues to operate, capturing logs of details concerning its engagement.
Specifically, within the examined SSH Brute Force attack where large numbers of
content filled text files were used, the system failed to show signs of stagnation, showing
how sturdy the solution is. However, this then raises other questions. Can the same
implications gathered from a medium – high interaction honeypot be applied to a low
interaction honeypot. With this hypothetical question and findings from the project more
research can be done to resolve this matter.

6.3. Problems

The major problem encountered throughout the project was the set up and
implementation of the Cowrie honeypot. Due to unfamiliarity with the system at first, it
took quite some time to get running, leading me to learn and consult about its architecture
through online material. In addition, its download onto the virtual machine was through
sudo commands. With multiple lengthy commands to execute, it was critical that care
16
 was taken at each step to ensure accuracy in the commands. Cowrie uses distinct Python
versions and libraries, which was not figured out until later. The system is very sensitive
to missing files, as any missing dependencies would not allow its operation to start,
requiring further troubleshooting. Eventually, the honeypot was successfully installed
onto the machine.

6.4. Personal Reflection

The project has been extremely fascinating to work on. Branching into tools like Hydra
and Cowrie not previously familiar to studying on attack methods was not an easy task,
although the personal progress made from the initial start has been considerable.
Development of skills such as analysis of system logs from the honeypot, were
developed. In addition, I dived into penetration testing on a minuscule scale through
using Hydra. The adaptability of using Linux is apparent, as through time using the
command language (bash) repetitively almost became second nature to me. From
memory and familiarity, I would be able to type in commands without extra guidance
from other material. Time management could have used much better within the project.
Configuring the honeypot system on the virtual box took large amounts of time, more
than I expected. It got to a point where consideration towards changing the scope of the
project became imminent. Thankfully after numerous days of trial and error, everything
came into place. It has given a new perspective on honeypot technology, as well as other
forms of defence and detection methods within cybersecurity.

6.5. Limitation and Future Work

Pertaining to future work, broadening the scope of honeypots used for the experiment
would be beneficial. For the experiment only 1 honeypot was created and implemented,
limiting the responses it gave as discussed within Chapter 4.3. Possibly, if I was to
implement other solutions and conduct attacks on them, then results would have been
much diverse compared to thee presented research. From here, comparative analysis
between honeypots can be achieved. Another suggestion is the analysis of the results
obtained. Other areas of the honeypot alongside the logs could be examined, such the
resource usage and performance. Details of the honeypots host machine e.g. CPU usage,
during the attacks can be studied. Expansion Lastly, results achieved within the project
may not resemble the output of a scenario that occurs in the real world, due to me

16
 orchestrating it independently on a VM. Exposure to the public, capturing real life
attackers and what they attempt on honeypots can be a proposal going forward in the
future.

References
Mike (2022). The Big Shift: From Reactive to Proactive Cybersecurity. [online] Xage
Security. Available at: https://xage.com/blog/the-big-shift-from-reactive-to-proactive-
cybersecurity/.
Sharma, R. (2024). Honeypot Technology Market Research Report 2032. Dataintelo.
Available at: https://dataintelo.com/report/global-honeypot-technology-market (Accessed: 1
May 2025).
Yang, X., Yuan, J., Yang, H., Kong, Y., Zhang, H. and Zhao, J. (2023) ‘A Highly Interactive
Honeypot-Based Approach to Network Threat Management.’ Future Internet, 15(4) p. 127.
Ilg, N., Duplys, P., Sisejkovic, D. and Menth, M. (2023) ‘A survey of contemporary open-
source honeypots, frameworks, and tools.’ Journal of Network and Computer Applications,
220, November, p. 103737.
Franco, J., Aris, A., Canberk, B. and Uluagac, A. S. (2021) ‘A Survey of Honeypots and
Honeynets for Internet of Things, Industrial Internet of Things, and Cyber-Physical Systems.’
IEEE Communications Surveys & Tutorials, 23(4) pp. 1–1.
M.R., A. and P., V. (2022) ‘Review of Cyber Attack Detection: Honeypot
System.’ Webology, 19(1) pp. 5497–5514.
Matej Rabzelj, Leon Štefanić Južnič, Volk, M., Kos, A., Kren, M. and Sedlar, U. (2023)
‘Designing and Evaluating a Flexible and Scalable HTTP Honeypot Platform: Architecture,
Implementation, and Applications.’ Electronics. Multidisciplinary Digital Publishing
Institute, 12(16) pp. 3480–3480.
Zielinski, D. and Kholidy, H. A. (2022) ‘An Analysis of Honeypots and their Impact as a
Cyber Deception Tactic.’ arXiv (Cornell University). Cornell University, December.
Surber, J. G. and Zantua, M. (2022) ‘Intelligent Interaction Honeypots for Threat Hunting
within the Internet of Things.’ Journal of The Colloquium for Information Systems Security
Education, 9(1) p. 5.
Fraunholz, D., Zimmermann, M. and Schotten, H. D. (2021) An Adaptive Honeypot
Configuration, Deployment and Maintenance Strategy. arXiv.org. [Online]
https://arxiv.org/abs/2111.03884.
Aggarwal, P., Du, Y., Singh, K. and Gonzalez, C. (2021) ‘Decoys in Cybersecurity: An
Exploratory Study to Test the Effectiveness of 2-sided Deception.’ arXiv:2108.11037 [cs],
August.

16
Moric, Z., Dakic, V. and Regvart, D. (2025) ‘Advancing Cybersecurity with Honeypots and
Deception Strategies.’ Informatics. Multidisciplinary Digital Publishing Institute, 12(1) pp.
14–14.
Kocaogullar, Y., Cetin, O., Arief, B., Brierley, C., Pont, J. and Hernandez-Castro, J. (2022)
Hunting High or Low: Evaluating the Effectiveness of High-Interaction and Low-Interaction
Honeypots.
Abdul Majid Jamil, Hassan Jalil Hadi, Li, S., Cao, Y., Ahmed, N., Faisal Bashir Hussain,
Chakkaphong Suthaputchakun and Wang, X. (2024) ‘Detection of Targeted Attacks Using
Medium-Interaction Honeypot for Unmanned Aerial Vehicle,’ January, pp. 164–185.
Aung, Y. L., Khoo, Y. L., Zheng, D. Y., Duo, B. S., Chattopadhyay, S., Zhou, J., Lu, L. and
Goh, W. (2025) HoneyWin: High-Interaction Windows Honeypot in Enterprise Environment.
arXiv.org. [Online] [Accessed on 8th May 2025] https://www.arxiv.org/abs/2505.00465.
Elisavet Grigoriou, Athanasios Liatifis, Panagiotis Radoglou-Grammatikis, Lagkas, T.,
Moscholios, I. D., Markakis, E. and Panagiotis Sarigiannidis (2022) ‘Protecting IEC 60870-
5-104 ICS/SCADA Systems with Honeypots,’ July.
Muris Sladić, Valeros, V., Catania, C. and Garcia, S. (2024) ‘LLM in the Shell: Generative
Honeypots,’ 220, July, pp. 430–435.
Raghul, S. A., G Gayathri, Bhatt, R. and Kumar, V. (2024) ‘Enhancing Cybersecurity
Resilience: Integrating IDS with Advanced Honeypot Environments for Proactive Threat
Detection,’ June.
F, M. U., Pavan S, R, S. M., Yogesh B, Babu, S., Thirumala Akash K and Ahmed, M. R.
(2024) ‘Intrusion Detection Landscape: Exploring Progress and Confronting Challenges in
Security Advances,’ February, pp. 1–8.
Selian, R. A., Naufal Azzahri, M., Muchallil, S., Nurdin, Y., Fauzie Afidh, R. P., Umam, K.
and Dawood, R. (2024) ‘Analyzing Cyberattack Patterns Using Cowrie Honeypot Deployed
on a Raspberry Pi 5.’ 2024 IEEE 2nd International Conference on Electrical Engineering,
Computer and Information Technology (ICEECIT). IEEE, November, pp. 272–277.
Zaman, Tao, L., Maldonado, M., Liu, C., Sunny, A., Xu, S. and Chen, L. (2024) Optimally
Blending Honeypots into Production Networks: Hardness and Algorithms. arXiv.org.
[Online] [Accessed on 5th May 2025] https://arxiv.org/abs/2401.06763.
Harsh Katakwar, Shashank Uttrani, Aggarwal, P. and Dutt, V. (2022) ‘Influence of different
honeypot proportions on adversarial decisions in a deception game.’ Proceedings of the
Human Factors and Ergonomics Society Annual Meeting. SAGE Publishing, 66(1) pp. 120–
124.

16
Bibliography
Installing Cowrie in seven steps — cowrie 2.6.1 documentation (2014) Cowrie.org. [Online]
https://docs.cowrie.org/en/latest/INSTALL.html.

16
Appendices
Appendix A – Feasibility Study

Project Background

In this advanced and ever-growing digital era, cybersecurity has been identified as a major
focus point for governments, organizations, and individuals worldwide. Threats in the area
of network security, such as DDoS, phishing and ransomware attacks are becoming more
challenging and sophisticated for traditional security measures to deal with. An approach in
which we can fully study and understand these network threats to a higher degree would be
done through the creation of honeypots. Honeypots are essentially systems created to lure
in attackers, trap them and conduct an analysis of their activity. Deceptiveness is a key
element for honeypots, but in a scenario where the attacker has awareness prior to engaging
with the honeypot, the system could be render useless. From this point the attacker might
have intentions of targeting the system with attacks. How will the react? Will the system
shut down? Will the systems stability and usability be shaken? This proposal aims to design
and implement a honeypot, the conduction of multiple attacks on the system to capture its
reaction

The first reason into why more attention must be drawn into this matter is due to increasing
cyber threats. As stated before, cyber-attacks are becoming more enhanced, and with the
number of attacks occurring increasing rapidly, more disruption and catastrophes are bound
to happen. This will lead to advanced security measures within cyber security to be
developed to combat these challenges. Within network security you will have your
commonly used defence mechanisms to protect the network, such as a firewall, intrusion
detection system (IDS) or endpoint security. Although these are suggested to utilize, they
are reactive techniques, meaning that action is only taken once the attack has happened. In
contrast, honeypots are proactive, able to identify activity before the attack itself has
occurred. They're proven to act as a warning signal, leading to a quick response. Finally,
findings from this project could be shared within the community of cyber security, adding
more threat intelligence for others to make note of.

Project Aim

The aim of this project is to construct a honeypot system and test its reactiveness to
simulated cyberattacks
16
Project Objectives

To accomplish these aims, I have set out the following objectives:

• Design and implement honeypot

• Simulate and capture attacks

• Analyse captured data

• Evaluate the effectiveness of the system

Project Resources

Resources needed for my project are split into 4 areas, which are the following:

Software:

• VirtualBox, used to handle the virtual environment for the network and honeypot

• Cowrie/Honeyd, used to set up the honeypot

• Metasploit, used to generate attack and test the honeypot

• Splunk/Python, used to construct the visualization of the data gotten from the
honeypot

• Microsoft Excel, used to track progress of project

Hardware:

• Computer System, preferably home system, but university systems when on site.

• Enough computer resource to run the virtual machine

Data requirements:

• Traffic Logs, obtained during the course of the attack using monitoring tools

• Simulated attack data, created by using Metasploit

Time and other resources:

• Guides related to honeypot installation

• Suitable time allocated to commence the procedure and document findings.

16
Timeline

Appendix B – Ethos Form

16
16
16
16
16
16
16