Evaluating Digital Forensic Readiness: A Honeypot Approach

Philip Zimmermann

and Sebastian Obermeier

Hochschule Luzern Informatik, Campus Zug-Rotkreuz, Suurstofﬁ 1, 6343 Risch-Rotkreuz, Switzerland

Keywords:

Digital Forensics, Forensic Readiness, Honeypot.

Abstract:

Digital forensic readiness has proven to be a challenging undertaking for small to medium-sized companies.

To improve, it is important to evaluate the effectiveness of forensic processes. In this paper, an approach for

a forensic honeypot is proposed that simulates an environment based on real company devices and is hosted

in the cloud. The data collected is used for the evaluation of the forensic process, enabling the identiﬁcation

of discrepancies within the forensic readiness approach. The experimental results show the feasibility of the

approach in collecting forensic evidence in a short time. The paper also discusses limitations with regard to

the introduction of new security threats and the use and placement of endpoint intrusion detection systems.

1 INTRODUCTION

Malware attacks pose a serious threat to the security

and integrity of digital systems, especially for small-

to-medium enterprises (SMEs), which may lack ade-

quate resources and expertise to deal with them. How-

ever, not all SMEs are equally exposed to malware

risks, and some may never encounter a malware in-

cident in their operations. This does not mean that

they can afford to be complacent or unprepared, as

malware attacks can occur at any time and cause sig-

niﬁcant damage. Therefore, it is essential for SMEs to

adopt a proactive approach to digital forensics, which

is the process of collecting, preserving, and analyzing

digital evidence in the event of a cyberattack. This ap-

proach is known as digital forensic readiness (DFR),

and aims to minimize the impact of malware inci-

dents and facilitate recovery and investigation pro-

cesses. Measuring the effectiveness and functionality

of the DFR process is challenging without a genuine

or simulated incident. This paper aims to transform

a company device into a virtual honeypot, allowing

SMEs to evaluate their DFR capabilities.

1.1 Problem Description

Achieving forensic readiness is not a trivial task, as

it requires careful planning, testing, and evaluation of

the forensic capabilities and procedures of an organi-

zation. Furthermore, testing the forensic readiness of

https://orcid.org/0009-0007-8765-9703

https://orcid.org/0000-0003-2802-7427

an organization is challenging, as it cannot be done re-

alistically without simulating a malware attack, which

may be unethical or not practicable, e.g., due to the

criticality of the system. Therefore, there is a need

for novel methods and tools that can help SMEs to as-

sess and improve their forensic readiness in a safe and

effective manner.

One method of simulating cyber attacks within a

company is to use red teaming (Mansﬁeld-Devine,

2018) (Oakley, 2019), which is a simulated cyberat-

tack that tests the security posture and incident re-

sponse capabilities of an organization. Although it

can provide valuable information on the strengths and

weaknesses of defensive measures as well as the ef-

fectiveness of the forensic readiness, red teaming also

has some potential downsides, especially for small

and medium enterprises (SMEs) that may have lim-

ited resources and expertise: First, red teaming is a

costly and time-consuming exercise that can divert re-

sources and attention from other business priorities.

Second, red teaming may not cover all the possible

scenarios and attack vectors that affect the forensic

capabilities and forensic readiness of an organization.

Third, red teaming can introduce new risks and vul-

nerabilities and can generate a large amount of data

that could overwhelm the forensic analysis capabili-

ties of an SME.

Another approach would be the use of dedicated

honeypots such as T-Pot

(Washofsky, 2021). How-

ever, as the company’s internal systems are typically

different from the honeypot, the resulting data may

https://github.com/telekom-security/tpotce

Zimmermann, P. and Obermeier, S.

Evaluating Digital Forensic Readiness: A Honeypot Approach.

DOI: 10.5220/0012713600003767

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 615-621

ISBN: 978-989-758-709-2; ISSN: 2184-7711

615

not reﬂect the actual company infrastructure. In addi-

tion, it may not yield enough data to test the forensic

approaches. Nevertheless, we keep the idea of using

a honeypot, but more tailored to the actual SME.

1.2 Contributions

This paper

1. creates a concept for transforming a company de-

vice into a virtual honeypot

2. deﬁnes the steps that are needed to deploy and run

the honeypot securely in a cloud environment in

order to gather data for forensic analysis

3. evaluates the concept in a real-world experiment

and discusses the feasibility of the approach

Note that neither the process of sanitizing a sys-

tem such that no identiﬁable personal information is

present nor the actual analysis of the gap in the foren-

sic process is part of this document, as this is highly

depending on the type of company.

2 RELATED WORK

Numerous publications exist that explore the concept

of honeypots or forensic readiness, but linking both

does not seem common. (Kebande et al., 2016) fo-

cuses on utilizing honeypots for the collection of po-

tential digital evidence (PDE) within a BYOD (Bring

Your Own Device) setting, but does not transform ac-

tual devices into honeypots.

A comparison of the major cloud platforms for

the deployment of honeypots is made in (Kelly et al.,

2021). The paper conﬁrms that threat actors try to

abuse cloud-based services.

During our investigations, we concluded that the

main use of honeypots is to detect attacks in an early

state – both in IT (Dodson et al., 2020) and OT net-

works (Priya and Chakkaravarthy, 2023) – since in-

teraction with the honeypot is typically not a normal

operational activity and can reveal security issues in

the cloud environment (Singh, 2021).

Regarding an optimal honeypot deployment,

(Verma and Dubey, 2020) discusses the advan-

tages and disadvantages of different deployment ap-

proaches.

The authors of (Biedermann et al., 2012) utilize a

cloning mechanism to duplicate a live VM facing an

attack, redirecting the assault for analysis and learn-

ing from the attacker. To ensure rapid cloning during

live attacks, an approach is used to adapt the Xen hy-

pervisor (Barham et al., 2003), enabling rapid dupli-

cation of existing VMs. However, this approach is not

compatible with modern cloud environments, as users

lack the ability to make modiﬁcations to the hypervi-

sor in that setting.

To analyze data of a honeypot system, machine-

learning based approaches are becoming a viable op-

tion (Setianto et al., 2022).

To summarize, honeypots are frequently used to

detect attacks in an early stage, but the use for evalu-

ating a company’s forensic readiness is currently not

a common practice.

Once data is collected through the approach pro-

posed in this paper, forensic readiness capabilities

should be evaluated. Different models exist for this

approach, for example, (Taiwo and Claims, 2022).

Forensic analysis is also standardized in ISO/IEC

27043. However, such models are typically only ap-

plicable to companies that have a forensic footprint

and knowledge about forensic readiness. Our ap-

proach helps speed up this process, as our experi-

ments conﬁrmed that incident data will most likely

be generated in less than a week.

3 SOLUTION APPROACH

In order to fulﬁll the two goals of ”forensic readiness”

as described by Tan (Tan, 2001), it is necessary to as-

sess the ability to gather pertinent digital evidence. To

evaluate this capability, a forensic honeypot is pro-

posed that simulates an environment based on real

company devices. This environment is exposed to the

public internet, and all interactions and potential inci-

dents are recorded by the forensic honeypot. The data

from the system used as the attack surface is then pro-

cessed using the existing forensic analysis approach.

The investigator can determine whether the collected

data are sufﬁcient or whether the forensic readiness

approach should be extended or modiﬁed.

For the purpose of this paper, the following re-

quirements have been formulated.

Attack Detection. The system must be capable of

detecting attacks and generating corresponding

alerts over the duration of the data collection

Traceability. The attacker’s actions must be accu-

rately tracked, i.e., what, when, how, and by

whom actions were taken.

Security. An attack on the honeypot must not jeop-

ardize the security of the surrounding systems.

Transparency. The honeypot should not be recog-

nizable as such to external parties. It shall be

transparent.

High Interaction. The honeypot should have a high-

level interaction capability.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

616

The basic idea behind the construction of the hon-

eypot is to transform an existing system into that hon-

eypot and use it to attract attackers and collect foren-

sically relevant data. To achieve this, an existing sys-

tem is selected and rebuilt within the honeypot envi-

ronment. To allow investigation of security incidents,

the vulnerable system is periodically cloned. Backups

are created periodically from these clones to simplify

analysis, such as recovering traces obscured by the at-

tacker. Services like a Host Intrusion Detection Sys-

tem (HIDS) are then installed on the clone, allowing

monitoring of the environment without revealing this

to the attacker.

For proof of concept, two virtual machines with

restricted scope serve as the vulnerable system. How-

ever, the described method can also be applied to

complex systems as potential attack surfaces.

The operation of the honeypot is divided into three

phases.

• Normal Operation: The system is deployed. To

stimulate an investigatable security incident, vul-

nerabilities can be introduced into the services be-

ing used. This can be done, for example, by em-

ploying services with known security ﬂaws. Once

an attack occurs, an alert is generated, and the pro-

cess transitions to the next phase.

• Data Collection: Upon detecting an attack on the

honeypot, the duration for data collection can be

determined based on the severity of the attack. Af-

ter this period elapses, the vulnerable system is

shut down and forensic analysis starts.

• Forensic Analysis: During the forensic analysis

of the honeypot, the resources that participated in

the security incident are analyzed: the image of

the vulnerable system and any data from the re-

spective surrounding systems like HIDS.

Upon completion of these three phases, the imple-

mentation of DFR will be reviewed. The data col-

lected by the honeypot are used for the review, al-

lowing the identiﬁcation of discrepancies between the

data collected from the forensic process and the actual

data generated during the incident.

3.1 Special Case: HIDS and Remote

Management

A special case concerns the management system of

intrusion detection systems used, especially endpoint

detection and response (EDR) systems. In this con-

text, there are two viable options:

A) Setting up a new HIDS-Management Server in-

stance within the Honeypot environment may result in

higher costs due to licenses. Nevertheless, the honey-

pot remains self-contained, reducing the risk of an at-

tacker using the HIDS-Management Server for lateral

movement into the company network.

B) Alternatively, connecting an existing HIDS-

Management Server in the SME environment to the

honeypot eliminates the need for extra license fees.

However, this approach expands the attack surface,

potentially allowing attackers to exploit the connec-

tion for lateral movement into the company network.

To come to an informed decision, the SME should

ﬁrst evaluate its current licensing situation for HIDS/

EDR. Following this, it is crucial to take into account

any regulatory requirements that may apply. A com-

prehensive risk assessment should then be conducted,

recognizing the ﬁnancial limitations and the overall

risk tolerance of the organization.

4 IMPLEMENTATION

For the implementation, we have used a system based

on the university notebooks. As there is no standard

HIDS throughout the university, we have employed

OSSEC (Open Source HIDS SECurity)

. It is cru-

cial to recognize that any HIDS could be appropriate

for the task. OSSEC+ was selected due to its open-

source nature. The honeypot experiment was set up

in Google Cloud using Ansible for automation.

In order to import an existing system as an attack

surface into the honeypot, it needs to be ensured that

this is done securely. For this purpose, the suggested

process is outlined, comprising both a setup phase (1-

4) and an operational phase (5-8).

1) Sanitization: The system must undergo sanitiza-

tion to prevent any potential leakage of sensitive in-

formation or credentials to an attacker

2) Import: To enable the import of the system,

it should be exported in a compatible format using

suitable tools like Disk2VHD

. For Google Cloud,

the Open Virtualization Format (OVF)

is a suitable

choice, the virtualized system should be exported in

such a format.

3) Prevention: Implement ﬁrewall rules that block

outgoing trafﬁc (egress) from the system to ensure

that attackers cannot use it as a staging area.

4) Introduce Vulnerability: To gain insights into

the DFR capabilities, an attack should be analyzed.

To facilitate this, intentionally introducing a vulner-

ability can increase the likelihood of a successful at-

https://www.ossec.net/

https://learn.microsoft.com/en-us/sysinternals/

downloads/disk2vhd

https://www.dmtf.org/standards/ovf

Evaluating Digital Forensic Readiness: A Honeypot Approach

617

tack. This step is optional and can also be completed

at a later time.

5) Deploy/ Simulate Attack: The system can then be

deployed, and speciﬁc scenarios can be tested by sim-

ulating attacks. This proactive approach eliminates

the need to wait for malicious parties to initiate an at-

tack. Alternatively, the system can be deployed with-

out simulating an attack. This allows the collection of

data that closely resembles real-life scenarios.

6) Preparing HIDS-Server: The Connection from

the HIDS-Agent to the HIDS-Server needs to be pre-

pared so it can be established after the cloning.

7) Clone: The system undergoes cyclical cloning, fol-

lowed by the installation of the HIDS-Agent on the

cloned system to enable monitoring.

8) Monitor: Active monitoring of the HIDS and ﬁre-

wall logs is crucial to prevent any abuse of the system.

Figure 1 illustrates a run of the cloning task. As

this cloning task introduces a novel concept that has

not been previously observed in other honeypots, it

will be thoroughly illustrated.

• Step 1: At ﬁrst, a snapshot of the attack surface or

vulnerable host is created. Any existing snapshots

are deleted.

• Step 2: A disk is generated based on the snapshot,

with the current date as its label. Disks with the

same label are removed, while those with a differ-

ent label are retained, this enables us to retain a

daily backup of the disk.

• Step 3: The newly created disk is used to create a

new instance.

• Step 4: Involves conﬁguring the OSSEC+ agent

on the cloned attack surface.

The entire sequence repeats at a predeﬁned interval of

45 minutes. At the heart of the cloning operation is

the cloning of the disks outlined in step 2. The corre-

sponding ansible code is shown in Figure 2. The an-

sible module google.cloud.gcp compute disk is uti-

lized. This module enables the manipulation of disks,

involving actions such as deletion and creation. Pa-

rameters for this module include the zone where the

disk will be generated, the disk’s name (which serves

as a unique identiﬁer for the associated instance, in-

cluding the creation date), and the size. Notably, disks

will undergo continuous creation and deletion, with

one disk retained at the conclusion of each day.

Figure 3 presents the network topology of the ap-

proach, comprising of four key components:

• OSSEC+-Server: This server functions as the

HIDS server, responsible for aggregating and pro-

cessing alerts generated by agents on the attack

surface clone and syslog messages from the attack

surface.

Internal

Attack Surface

Snapshot

Compute Engine

Attack Surface

Compute Engine

Attack Surface Clone

Compute Engine

01.01.2024

Persistent

Disk

02.01.2024

Persistent

Disk

03.01.2024

Persistent

Disk

04.01.2024

Persistent

Disk

Figure 1: Process of the cloning task.

- name: 'Delete old disk'

google.cloud.gcp_compute_disk:

project: "{{ project }}"

auth_kind: "{{ auth_kind }}"

service_account_file: "{{ service_account_file }}"

state: 'absent'

zone: "{{ zone }}"

ignore_errors: true

loop:

- {sign: 'v'}

- {sign: 'w'}

- {sign: 'm'}

google.cloud.gcp_compute_disk:

project: "{{ project }}"

source_snapshot:

selfLink: "{{item.link}}"

auth_kind: "{{ auth_kind }}"

service_account_file: "{{ service_account_file }}"

state: 'present'

zone: "{{ zone }}"

size_gb: "{{item.size}}"

loop:

- {sign: 'v', link: "{{self_link}}", size: 15}

- {sign: 'w', link: "{{web_self_link}}", size: 15}

- {sign: 'm', link: "{{win_self_link}}", size: 125}

Figure 2: Ansible code for disk rotation.

• Ansible Coordinator: This component orches-

trates the cloning process of the attack surface.

• Attack Surface: These are virtual machines

(VMs) that serve as the attack surface. They col-

lect syslog messages and transmit them to the

OSSEC-Server.

• Attack Surface Clone: The attack surface clone

replicates the original attack surface. An OSSEC

Agent operates on this machine, generating alerts

for further processing.

Firewall rules serve as a robust protective mea-

sure, efﬁciently intercepting and mitigating unautho-

rized communication attempts and the activation of

malicious software originating within the honeypot

environment. These regulations endorse exclusively

inbound network trafﬁc, while strictly limiting activi-

SECRYPT 2024 - 21st International Conference on Security and Cryptography

618

Internal

Ansible Coordinator

Compute Engine

OSSEC+-Server

Compute Engine

Attack Surface

Compute Engine

Attack Surface Clone

Compute Engine

TCP: 22

UDP: 514

UDP: 1514

all

TCP: 80,443

WAN

Figure 3: Network topology and ﬁrewall rules.

ties such as initiating reverse shells and executing at-

tacks on external systems located outside the prede-

ﬁned attack surfaces. The establishment of connec-

tions between the deﬁned attack surfaces remains pos-

sible. Due to the utilization of software-deﬁned net-

working in the Google Cloud network, each instance

functions as if it possesses its own ﬁrewall. Con-

sequently, ﬁrewall rules must be conﬁgured on both

endpoints.

5 EXPERIMENTAL EVALUATION

To validate the forensic honeypot, two attack sur-

faces based on university devices were provisioned

and conﬁgured according to the eight step plan de-

ﬁned earlier.

• Linux host with SSH: A Debian system with a ssh

server that allows user login with standard pass-

words.

• Windows 10 host with RDP: A Windows 10 host

with RDP enabled that can be accessed with a

blank password.

While the Linux host was sourced from a server

in the university environment, the Windows host was

cloned from a live system on a laptop, converted to

the OVF format, and subsequently integrated into the

GCP environment. Following this integration, ﬁre-

wall rules were established to enable communica-

tion. A crucial rule implemented is an implicit deny

rule, restricting all trafﬁc that is not explicitly permit-

ted. The vulnerability introduced pertained to pre-

conﬁgured blank or standard passwords. Additional

vulnerabilities were later incorporated for simulated

tests. The system was then deployed to attract real at-

tackers. The Agent connections were established on

the OSSEC-Management Server before executing the

initial cloning task, allowing the Agents to connect as

soon as they were installed on the clones. The An-

sible playbook for continuous cloning was initiated,

and the logs of the HIDS and ﬁrewall were intermit-

tently monitored manually.

The assessment period was 24. Nov. 2023 to 29.

Nov. 2023. The ﬁrst successful login for the user

”pi” occurred following a series of unsuccessful login

attempts by the same attacker. This event triggered an

alert by OSSEC at 9:31. The initiation of the second

phase, namely the data collection, is indicated by this

alert. The data collection timeframe has been estab-

lished with a deadline set for the 29th. Shortly there-

after during the next clone cycle, OSSEC detected the

generation of a new ﬁle that according to VirusTotal

is classiﬁed as a ”trojan” malware. Subsequently, OS-

SEC signaled a modiﬁcation in the /etc/passwd ﬁle,

indicating that the user’s password had been changed

to prevent unauthorized access. In the Google Cloud

Platform (GCP) logs, this marked the beginning of an

increase in the ﬁrewall logs. Approximately every 30

minutes, 50,000 connection requests from the now in-

fected host were blocked. It is important to note that

the vulnerable machine is cloned, resulting in the gen-

eration of only 25,000 requests per machine in real-

ity. Following the data collection phase, an image ﬁle

of the virtual machine was acquired. The honeypot’s

ﬁndings could be corroborated with the actual data on

the system. In a real-world scenario, the disparities

between the intelligence gathered from the virtual ma-

chine image and logs from other systems would be as-

sessed in comparison to the intelligence collected by

the honeypot. These differences provide insights into

how the DFR process can be enhanced and whether

adjustments are needed.

Table 1 provides information on the usage of the

honeypot during the evaluation phase.

Table 1: Statistics honeypot evaluation.

Windows Debian

Successful Logins 1257 249

Actions on Host None Malware Installed

In order to illustrate how a real-world attack sce-

nario would occur, an attack was conducted on both

machines as part of a student exercise. The Debian

machine was conﬁgured with sudo version 1.8.19p1-

2.1, which contains a vulnerability identiﬁed as CVE-

2021-3156. This vulnerability enables an attacker to

exploit a heap-based buffer overﬂow, thereby acquir-

ing root privileges.

During an attack, OSSEC detected a brute force

attack on SSH credentials, marking a successful login

https://www.virustotal.com

Evaluating Digital Forensic Readiness: A Honeypot Approach

619

after numerous failed attempts as suspicious. Subse-

quently, the alert system ﬂagged the creation of the

ﬁle linpeas.sh, with relevant details such as the alert

timestamp, originating host, alert type, and MD5 and

SHA1 hashes of the new ﬁle, as illustrated in Figure

4. Similarly, OSSEC signaled the creation of the ex-

ploit ﬁle exploit userspec.py

. The exploit, generat-

ing approximately 2000 alerts, indicated a segmenta-

tion fault caused by the exploit. Notably, OSSEC did

not recognize the multitude of segmentation faults as

indicative of a buffer overﬂow. The creation of a new

user ”gg”, resulting from the exploit script, triggered

another alert. OSSEC also detected the password

change associated with this newly generated user.

The attack executed on the Windows machine dif-

fered, as the machine did not possess any well-known

security ﬂaws. The attack focused on installing mal-

ware and involved the following steps: Login to the

machine with the blank password, install executable

on the machine, simulate a dropped ﬁle in the au-

tostart directory, and simulate changed and added reg-

istry keys. OSSEC detected each of these actions and

created alarms.

"_index": "ossec-alerts-3.x-2023.12.07",

"_type": "_doc",

"_id": "2RRiRIwBmKL8NDW4whs9",

"_version": 1,

"_score": 1,

"_source": {

"@timestamp": "2023-12-07T13:06:11.155Z",

"hostname": "(debvuln) 10.182.0.31->syscheck",

"decoder": "syscheck_integrity_changed",

"SyscheckFile": {

"path": "/tmp/linpeas.sh"

"rule": {

"firedtimes": 3369,

"groups": [

"local",

"syslog",

"syscheck"

"level": 10,

"comment": "File added to the systen.",

"sidid": 554

"agent_name": "debvuln",

"agentip": "10.182.0.31",

"timestamp": "2023 Dec 07 13:06:10",

"id": "1701954370.1141060"

Figure 4: Json alert.

6 DISCUSSION

The experimental evaluation revealed that real-world

attacks manifested within a few hours of online pres-

ence. The honeypot demonstrated effective detection

of intrusions and malicious actions on hosts such as

the installation of malware or the creation of a new

user as the result of a privilege escalation. For show-

casing advanced attacks, we included two vulnerabil-

https://github.com/worawit/CVE-2021-3156

ities into the VMs. The requirements of Section 3 can

be evaluated as follows:

Attack Detection. In both, simulated and actual sce-

narios, the honeypot identiﬁed the attacks.

Traceability. In both simulated and real-world situa-

tions, it was feasible to precisely trace the actions of

the attacker, including what, when, who, and how of

their activities.

Security. An attack on the honeypot must not com-

promise the security of the surrounding systems. The

vulnerable host and its clone establish two outgoing

connections to the rest of the system: one for sending

Syslog messages to the OSSEC server and another for

the clone’s communication with the OSSEC server

via the OSSEC agent. With ﬁrewall rules blocking

additional communication, an attack on the honeypot

does not pose a threat to other honeypot systems. The

productive subsystems are in a separate environment,

and the use of GCP ensures galvanic isolation of the

honeypot from the productive system.

Transparency. The sole conﬁguration on the at-

tack surface host involves the ”rsyslog.conf,” enabling

the transmission of Syslog messages to the OSSEC

server. This host, which functions as a complete vir-

tual machine with either Linux or Windows OS, hides

its honeypot nature from external attackers.

High Interaction As the vulnerable host is a fully

functional instance of a virtual machine, the interac-

tion level of the honeypot can be classiﬁed as ”high.”

We have observed no automatic containment by

the cloud provider when the ﬁrewall blocks outgoing

requests, making it technically possible to replicate a

realistic environment. Real-world attacks manifested

shortly after deployment, conﬁrming the viability of

using it as a honeypot and creating valuable data to

evaluate the effectiveness of DFR processes. Our ﬁre-

wall conﬁguration has ensured that the honeypot is

not exploited as an entry point for attacks on addi-

tional systems. Moreover, costs can be adjusted as

required since the infrastructure is in the cloud.

Known limitations of the system include the in-

ability to create an exact 1:1 replica of an existing en-

vironment. Sanitization of data before deployment in-

cludes, for example, the deletion of sensitive personal

or sensitive company data, which inherently modiﬁes

the system. However, as relevant aspects of the foren-

sic readiness system are preserved, we consider the

impact of this modiﬁcation to be negligible.

While it is crucial that ﬁrewall rules limit out-

bound trafﬁc for security reasons, yet this also pro-

vides attackers a way to detect the honeypot.

Furthermore, the mere presence of critical compo-

nents in the honeypot could potentially leak informa-

tion, leading to a decision to exclude them. Striking

SECRYPT 2024 - 21st International Conference on Security and Cryptography

620

a balance between accurately portraying the system

and limiting the disclosure of information to potential

attackers becomes an important consideration that is

based on the individual company’s business.

Another limitation concerns the host-based intru-

sion detection systems (HIDS), in our experiments

OSSEC. It requires proper conﬁguration as the default

conﬁguration fails to provide alerts for newly created

ﬁles and the inability to recognize buffer overﬂows

generated in simulations as attacks. Custom rules can

be set up to conﬁgure these aspects, but it remains

unclear which other attack scenarios may not be de-

tected by OSSEC. However, this is based on the HIDS

used in the individual company, and other HIDS may

perform differently.

However, regardless of the HIDS, there is no as-

surance that the system is completely secure and that

attackers cannot exploit the honeypot; however, since

the honeypot is an isolated system, the impact of such

an incident is limited. By implementing robust se-

curity mechanisms and incorporating additional man-

ual controls (e.g., limited storage space and compu-

tational power), a high level of conﬁdence in the sys-

tem’s security can be achieved. In addition, our exper-

iments have shown that the time span until an attacker

exploits the system is in the range of days. This means

that the risk of the honeypot being used as a dissem-

ination facility for illegal content is limited when its

monitored frequently.

7 SUMMARY AND CONCLUSION

Forensic readiness and its evaluation are important el-

ements for a holistic security architecture. The pre-

sented approach can be used to analyze forensic readi-

ness capabilities before an actual incident occurs or

even before an attack simulation is conducted. It is

based on cloning an existing system, sanitizing it to

transform it into a honeypot, and deploying it in a

cloud environment. The experiments carried out have

shown that this approach is feasible, reasonably se-

cure, and generates actual data for forensic investi-

gations as attacks on the honeypots are conducted.

Therefore, we consider our approach an important

step in enabling a forensic readiness assessment using

existing company systems and processes, especially

for small and medium enterprises.

REFERENCES

Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T.,

Ho, A., Neugebauer, R., Pratt, I., and Warﬁeld, A.

(2003). Xen and the art of virtualization. In Proceed-

ings of the nineteenth ACM symposium on Operating

systems principles, pages 164–177. ACM.

Biedermann, S., Mink, M., and Katzenbeisser, S. (2012).

Fast dynamic extracted honeypots in cloud comput-

ing. In Proceedings of the 2012 ACM Workshop on

Cloud computing security workshop, pages 13–18.

ACM.

Dodson, M., Beresford, A. R., and Vingaard, M. (2020).

Using global honeypot networks to detect targeted ics

attacks. In 2020 12th International Conference on Cy-

ber Conﬂict (CyCon), volume 1300, pages 275–291.

Kebande, V. R., Karie, N. M., and Venter, H. S. (2016).

A generic digital forensic readiness model for BYOD

using honeypot technology. In 2016 IST-Africa Week

Conference, pages 1–12.

Kelly, C., Pitropakis, N., Mylonas, A., McKeown, S., and

Buchanan, W. J. (2021). A comparative analysis

of honeypots on different cloud platforms. Sensors,

21(7).

Mansﬁeld-Devine, S. (2018). The best form of defence–the

beneﬁts of red teaming. Computer Fraud & Security,

2018(10):8–12.

Oakley, J. G. (2019). Professional Red Teaming: Conduct-

ing Successful Cybersecurity Engagements. Apress.

Priya, V. D. and Chakkaravarthy, S. S. (2023). Container-

ized cloud-based honeypot deception for tracking at-

tackers. Scientiﬁc Reports, 13(1):1437.

Setianto, F., Tsani, E., Sadiq, F., Domalis, G., Tsakalidis,

D., and Kostakos, P. (2022). Gpt-2c: A parser for hon-

eypot logs using large pre-trained language models.

In Proceedings of the 2021 IEEE/ACM International

Conference on Advances in Social Networks Analysis

and Mining, page 649–653, New York, NY, USA. As-

sociation for Computing Machinery.

Singh, K. D. (2021). Securing of cloud infrastructure using

enterprise honeypot. In 2021 3rd Intl. Conference on

Advances in Computing, Communication Control and

Networking (ICAC3N), pages 1388–1393.

Taiwo, A. and Claims, I. (2022). An extended digital foren-

sic readiness and maturity model. Forensic Science

International: Digital Investigation, 40:301348.

Tan, J. (2001). Forensic readiness. Cambridge, MA:@

Stake, 1. Publisher: Citeseer.

Verma, A. S. and Dubey, A. (2020). A review on honey-

pot deployment. LJP London Journal of Research in

Computer Science and Technology, 20(1).

Washofsky, A. D. (2021). Deploying and analyzing con-

tainerized honeypots in the cloud with T-Pot. PhD the-

sis, Monterey, CA; Naval Postgraduate School.

Evaluating Digital Forensic Readiness: A Honeypot Approach

621