%!TEX encoding = IsoLatin
%!TEX main = honeypot_and_generative_ai.tex

This chapter presents the results obtained by SYNAPSE during various experiments aimed at analysing human and AI-driven interactions. They were designed to evaluate SYNAPSE's effectiveness in detecting and mapping cyberattacks within the MITRE ATT\&CK framework and understand its comparative performance against traditional honeypot systems. The first set of results will examine data from real-world attackers connected to SYNAPSE, analysing extracted information such as IP addresses and reputation, country, region, city, continent, time zone, ports used, and the number and duration of connections. This data offers a global perspective on the types of attacks and their geographical distribution. The second section will focus on controlled user experiments, where individuals with different levels of expertise interacted with both SYNAPSE and DENDRITE. By analysing their feedback and interactions, we will assess SYNAPSE's performance, including its ability to differentiate between malicious activities and legitimate behaviour. This will help determine how SYNAPSE performs when used in parallel with a traditional honeypot and how well it can detect nuanced behaviours. The final section explores AI vs AI scenarios where AI systems attacked SYNAPSE. This part evaluates how SYNAPSE responds to these AI-driven attacks and its ability to map them accurately to the MITRE ATT\&CK framework using its SYNAPSE-to-MITRE extension. These results provide critical insights into AI's evolving role in conducting and defending against cyberattacks, highlighting SYNAPSE's real-time ability to detect, respond, and map complex adversarial activities.

\section{Experiment One: ``Unmasking the Attackers''}

The primary goal of this experiment was to understand how SYNAPSE could capture data from real-world cyber attackers. To achieve this, SYNAPSE was deployed in an open, exposed state on an Oracle Cloud Infrastructure (OCI) virtual machine (VM). Attackers were able to connect to the VM via two main methods: the first involved scanning known IP ranges of the Oracle Cloud Infrastructure, and the second involved accessing a deliberately leaked public IP address that was shared across platforms like ``Pastebin''\footnote{\url{https://pastebin.com/}}. To facilitate access, a common and easily guessable username and password combination like \textit{oracle/oracle} was set, ensuring that attackers could effortlessly log into the system. Upon gaining access, they generally did not engage with the Linux terminal presented by SYNAPSE. Instead, their behaviour suggested they were trying to conduct other malicious activities, such as using the machine as part of botnets, launching further attacks, or exploiting it for other illicit purposes. In this context, attackers might have been leveraging the machine for Distributed Denial of Service (DDoS) attacks, hosting malicious content, or scanning other networks from within the compromised system. Although they did not interact with the terminal as expected, this experiment demonstrated SYNAPSE's capability to extract critical data whenever a connection occurred. This allowed for a detailed analysis of global attack patterns, even when direct interaction with the system was minimal. The focus of this experiment, therefore, shifted to studying the connection metadata and understanding how SYNAPSE can gather and analyse this information to improve detection and response to malicious activities.

\subsection{Securing the Trap}

Several security measures were implemented on the VM hosting the honeypot to ensure that SYNAPSE remained a controlled environment and was not exploited to launch further attacks. First, ``msmtp''\footnote{\url{https://marlam.de/msmtp/}}, a lightweight SMTP client used for sending emails, was configured on the VM to alert the system administrator each time someone logged in or out of the machine. This was achieved by leveraging the Pluggable Authentication Modules (PAM) system, allowing scripts to be executed upon specific authentication events. In this case, a script was triggered during login or logout, sending an email containing critical information such as the user's or attacker's IP address and relevant metadata. This ensured real-time monitoring of any suspicious access to the machine.

In addition, how SYNAPSE is coded and executed on the VM inherently provides a layer of security. Attackers who connected via SSH were immediately confined within a Python script. If they attempted to close or bypass the script, their connection would be terminated, preventing them from directly interacting with the operating system.
However, this mechanism alone was not foolproof, as sophisticated attackers might still attempt to inject malicious packets or exploit vulnerabilities that could allow them to break free from this containment and gain access to the underlying filesystem. If they succeeded, attackers could hijack the VM for malicious activities, such as launching further attacks, or even gain access to sensitive API keys for OpenAI and VirusTotal, leading to potential financial and operational damage to the research. To mitigate this risk, ``msmtp'' was used to send alerts whenever specific files on the filesystem were accessed. While this did not prevent from gaining access, it acted as a detection mechanism, allowing for real-time notifications if someone breached the security boundary and accessed critical files. This solution had pros and cons: while it provided immediate awareness of a security breach, it did not stop it. It relied on reactive measures rather than preventative ones, allowing for post-incident response rather than preemptive protection. To enhance this detection capability, ``auditctl''\footnote{\url{https://linux.die.net/man/8/auditctl}}, a tool used to manage the Linux Audit framework, was also employed. It allowed for continuous file access monitoring, generating logs and alerts whenever specific sensitive files were touched. This provided an additional layer of scrutiny to ensure any unauthorised access to critical files was swiftly detected.

Finally, a crucial step was taken to restrict the VM's ability to send specific types of packets in egress, effectively isolating the machine from initiating outbound connections. Limiting outgoing network traffic ensured that even if an attacker managed to infiltrate the VM, they could not use it to launch subsequent attacks or cause harm to other systems. This protected external machines from being compromised and reduced the risk of legal or ethical issues arising from the VM being part of a broader attack network. These security measures were designed to safeguard SYNAPSE and the underlying VM, ensuring attackers could connect to and interact with the system. However, they could not exploit it for further malicious purposes.

\subsection{Captured Data}

This experiment was conducted over ten days, during which the SYNAPSE honeypot was left exposed online, attracting numerous connections from attackers throughout the day. During this time, many different IPs attempted to access the system, with some returning on multiple occasions across different days, while others made several connections in quick succession. Throughout the experiment, \textbf{33 distinct IP addresses} were connected to the honeypot. This activity allowed the collection of invaluable data on these interactions, which is critical for analysing patterns, behaviours, and potential threats. This analysis will not disclose the IP addresses to avoid legal concerns and respect privacy. Instead, the focus will be summarising the extracted data associated with these connections.

\subsubsection{IP Reputations}

Throughout the experiment, SYNAPSE was accessed by IP addresses with various reputations, ranging from negative to zero. IPs with negative reputations have been flagged for past malicious activities, while IPs with zero reputations indicate that no prior harmful behaviour has been recorded. 
However, the presence of zero-reputation IPs does not necessarily guarantee their harmlessness. During the study, there were several instances where IPs with zero reputation were flagged as malicious or suspicious in their most recent analysis. This could suggest that the IP addresses were newly compromised or recently repurposed for malicious intent. The delayed update of reputation databases may allow such IPs to remain undetected for some time before their activities are flagged. These cases highlight the importance of continuously updating reputation databases and the challenge of relying solely on reputation as an indicator of threat potential.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.6\textwidth]{figures/reputations.png}}
    \caption{IP Reputations in Experiment One.}\label{fig:reputations}
\end{figure}

Graph \ref{fig:reputations} presents the reputation scores of individual IP addresses connected to the SYNAPSE honeypot during the experiment. Each horizontal line on the y-axis represents a single IP address, and the x-axis shows the corresponding reputation value. Reputation scores are negative values, with more negative numbers indicating a higher likelihood of the IP being associated with malicious or suspicious activity. For example, an IP with a reputation score of -19 represents one highly malicious and has a history of involvement in cyberattacks or harmful behaviour. On the other hand, IPs with scores closer to zero have a lower risk or may only be mildly suspicious, possibly flagged for unusual behaviour but not yet involved in significant attacks. In this graph, we can observe several IPs with reputation scores between -1 and -2, indicating lower levels of risk, and some IPs with more negative scores, such as -6, -7, and -19, showing the honeypot attracted a mix of highly suspicious and confirmed malicious actors.

\subsubsection{Geolocations}

During the experiment, a wide range of geolocation data was extracted from the IP addresses that connected to SYNAPSE. This data included information about the countries, regions, cities, time zones, and continents where the attackers were based. Extracting geolocation data is highly valuable, as it helps reveal patterns in the geographic origins of cyberattacks. Understanding where attackers are coming from can aid in attributing threats to specific regions, identifying hotspots of malicious activity, and shaping defence strategies accordingly. It also highlights the global nature of cyber threats, providing deeper insights into the tactics and behaviours of attackers worldwide.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.7\textwidth]{figures/geolocations.png}}
    \caption{Geolocations in Experiment One.}\label{fig:geolocations}
\end{figure}

Map \ref{fig:geolocations} represents the geolocation information extracted from IP addresses connected to the SYNAPSE honeypot during the experiment. Each coloured region on the map corresponds to a specific city or region from which attackers accessed the system. The legend on the right side indicates the locations associated with these attacks, including significant areas such as Moscow, New South Wales, Karnataka, and Taipei City. In the context of the experiment, this map highlights the global nature of the attacks, demonstrating that SYNAPSE attracted connections from multiple continents, including Europe, Asia, and Oceania. The geolocation data extracted highlights an exciting pattern: most connections during the experiment came from eastern regions. For instance, areas like Moscow, Karnataka, and Taipei City are critical sources of malicious activity. This aligns with global trends where certain areas of the eastern hemisphere, especially Eastern Europe and parts of Asia, have been linked to higher volumes of cyberattacks. The prominence of Moscow in this data, the connection having -19 of reputation, could reflect the broader use of sophisticated cybercriminal infrastructure in that region, often associated with organised cybercrime or even state-sponsored operations.
Additionally, the active presence of attackers from regions such as Taipei City, Daegu, and Karnataka suggests that these Asian areas are becoming increasingly essential hubs for cyber operations. This may be driven by the rapid growth of digital infrastructure in these regions, alongside rising technological expertise, which allows for both innovation and exploitation in cyberattacks. The fact that most connections came from the eastern areas also ties into time zone patterns. Many attacks are likely timed to coincide with peak local working hours, reflecting an organised approach from attackers who may be operating when defenders in other parts of the world are less active. This global time zone dynamic could explain why certain regions are more prominent in the data, as attackers exploit not only geographic vulnerabilities but also the rhythms of global internet activity.
In conclusion, the accuracy of these geolocation results varied, with SYNAPSE achieving impressive precision in some cases, identifying locations within a 10 km range of the actual source. However, the accuracy was broader in other instances, with up to 1000 km deviations. Despite these variations, the data remains instrumental in mapping the regions from which the attacks originated.

\subsubsection{Number and Duration of Connections}

The number of connections and their durations, extracted by SYNAPSE for each IP address, are essential metrics in this experiment. The number of connections helps identify persistent attackers, with repeated attempts potentially indicating a more determined or automated effort. Connection durations reveal the nature of the interactions, where longer durations suggest active engagement with the system, while shorter ones may indicate quick scans or automated attempts. Together, these metrics offer insights into attacker behaviour, persistence, and potential risks, enhancing our understanding of the threats targeting the honeypot.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.75\textwidth]{figures/number_of_connections.png}}
    \caption{Number of Connections with relative Durations in Experiment One.}\label{fig:number_of_connections}
\end{figure}

Graph \ref{fig:number_of_connections} illustrates the relationship between the number of connections made by single attackers and the corresponding mean duration of these connections in seconds. It is possible to observe a wide variability in the duration of connections, with some attackers maintaining very brief interactions while others remained connected for significantly more extended periods. Most connections with lower counts, typically between one and eight, are characterised by short durations. This suggests that many attackers were likely performing quick, automated activities such as scanning or probing the system for vulnerabilities without prolonged interaction.
However, there are several notable instances where attackers with just a single connection stayed connected for much longer, up to around 150 seconds. This suggests more deliberate interactions, where attackers may have attempted more sophisticated actions requiring a more extended connection. On the other hand, there are cases where attackers made multiple connections, up to 16, but their average connection durations remained relatively short. This could indicate repeated automated attempts to breach the system or exploit different vulnerabilities without staying connected for extended periods. These attackers may have been using scripts or bots designed to rapidly attempt a wide range of attacks, possibly hoping to find a weakness without needing sustained interaction. Overall, the data extracted by this experiment reveals two key behaviours: attackers who engage in quick, repeated connections that are likely automated and those who maintain longer, singular connections, suggesting more engaged, possibly manual attempts to explore the system.

\subsubsection{Time of Connection}

Understanding the time intervals during which connections to the SYNAPSE honeypot occurred is crucial for identifying patterns in attacker behaviour. Time interval correlation can help reveal peak activity periods, showing when attackers are most likely to engage with the system. By analysing these intervals, we can determine whether attacks are concentrated around specific times. This might indicate automated attacks triggered at regular intervals or time zone-related patterns, where attackers are active during local working hours. Additionally, time interval analysis can uncover whether specific attacks are coordinated or sequential, helping to differentiate between random, opportunistic threats and more organised, persistent attempts.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.65\textwidth]{figures/time_intervals.png}}
    \caption{Time Intervals and relative Number of Connections in Experiment One.}\label{fig:time_intervals}
\end{figure}

Graph \ref{fig:time_intervals} displays the number of connections to the SYNAPSE honeypot across four distinct time intervals, highlighting variations in attack activity throughout the day. The first time interval, from approximately 00:14:10 to 06:10:13, shows the highest number of connections, with 25 recorded during this period. This suggests that many attacks occurred during the early morning hours, which may indicate that many connections were automated, likely running during off-peak hours to avoid detection or take advantage of quiet periods on the network. In the second time interval, from 06:10:13 to 12:06:15, the number of connections drops significantly, with only 12 connections recorded. This decline in activity could suggest a temporary lull, possibly due to the attacks' automated nature or the targeting of different time zones where attackers might not be as active during this period.
Interestingly, in the third interval, between 12:06:15 and 18:02:18, there is a resurgence in connections, with 17 recorded during this period. This midday increase may suggest that the attackers, or their automated systems, are programmed to strike during certain times of the day when network defences might be weaker. It could also indicate activity timed to match specific time zones, where attackers are more active during business hours or early afternoon. Finally, during the last interval, from 18:02:18 to 23:58:21, the number of connections drops again, down to 11. This pattern likely reflects a winding down of activity towards the end of the day, further suggesting that many of the connections may have been automated, scheduled to operate during specific time windows, and that there were fewer manual attacks during these late hours.

\section{Experiment Two: ``Through the Eyes of the Intruder''}\label{sec:experiment_two}

This section presents the results of the second experiment. The primary objective was to evaluate SYNAPSE's ability to enhance cybersecurity by observing user interactions without providing any information about the systems they were engaging with. \textbf{18 individuals}, with varying levels of expertise, were tasked with interacting with two separate machines, one running SYNAPSE and the other running DENDRITE. Crucially, the participants were not told that these systems were honeypots nor that one incorporated generative AI. This deliberate lack of context ensured that their interactions would be natural and free from bias, providing a more precise test of how effectively SYNAPSE could deceive users. Participants were free to engage with the machines however they saw fit, whether through essential exploration or attempting direct attacks on the system. Some opted to combine both approaches. The absence of specific instructions or context was a critical design choice, ensuring their actions and decisions were uninfluenced by preconceived notions. Each participant was fully informed that their IP addresses and geolocations would be tracked during the experiment, and they provided consent for this data collection before proceeding. Following the interaction, participants were asked to complete a comprehensive survey to capture their experiences. Key questions focused on whether they detected anything unusual or artificial about the systems and if they could discern that one of the environments was not entirely natural. This feedback was essential to evaluating SYNAPSE's ability to simulate a real-world system convincingly while operating in parallel with DENDRITE.

This section will detail the impressive results of these interactions, exploring how SYNAPSE's AI capabilities enhanced the security and deception mechanisms and demonstrated its superiority over a traditional honeypot like DENDRITE. By analysing user behaviour, it will be possible to understand how well SYNAPSE disguises itself and misleads intruders, providing strong evidence of its potential in real-world cybersecurity applications.

\subsection{Interaction Types}

The interactions between participants and the systems were categorised into three main types: basic interaction, attacking the system, and combining both. Participants were free to interact with the machines in any way they preferred, which provided a diverse range of behaviours for analysis.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.6\textwidth]{figures/interaction_types.png}}
    \caption{Interaction Types in Experiment Two.}\label{fig:interaction_types}
\end{figure}

Basic interaction involved navigating the file system, creating or modifying files, and other standard, non-aggressive activities. As shown in Figure \ref{fig:interaction_types}, 44\% of participants engaged solely in these benign interactions, focusing on exploration without attempting to compromise the system. This group approached the machines like a regular system, providing insights into how well the honeypots simulated an authentic environment for standard users. Conversely, 44\% of participants took a more aggressive approach by attempting to attack the systems. This group tested the machines for vulnerabilities or tried to launch disruptive actions, simulating a direct assault on the system's security. A smaller subset of participants, comprising 11\%, combined both approaches. These users initially engaged in basic exploration but later transitioned to attacking the system, reflecting a scenario where one might first explore the architecture before launching an offensive.

The experiment also tested SYNAPSE's AI capabilities to determine whether an interaction constituted an attack. The AI performed exceptionally well, distinguishing between benign interactions and attacks with perfect accuracy. After each session, the AI's classification of whether an attack occurred was compared to the participants' self-reported interaction types (basic, attack, both). In every case, the AI's evaluation aligned perfectly with the participants' declarations, demonstrating the system's robust ability to detect malicious behaviours with high precision.

\subsection{Participants Perception of Systems Behavior}

Following the experiment, survey questions were administered to assess how participants perceived the systems they interacted with. These questions aimed to gauge whether the users noticed any differences between the two machines, detected any unusual behaviour or felt that one or both were inaccurate.

\subsubsection{Perceived Similarity in System Interaction}

Participants were asked whether they found the two systems to be similar regarding interaction. This question was designed to determine how well SYNAPSE, with its AI-driven adaptability, blended with the static equivalent DENDRITE from the user experience perspective. If participants perceived the two systems as identical, it would suggest that SYNAPSE successfully mimicked a traditional environment without revealing its AI-enhanced capabilities. On the other hand, if participants noticed differences, their responses could offer insights into whether SYNAPSE's dynamic nature or DENDRITE's static characteristics were more apparent during the interaction. Answers to the question ``Did the two machines seem identical to you in terms of interaction?'' are reported in Table \ref{tab:answers_1}, where the ``first'' machine indicates SYNAPSE, while the ``second'' one is DENDRITE.

\begin{table}[tbh]
    \begin{center}
        \begin{tabular}{|c|p{9cm}|}
        \hline
        \textbf{Participant} & \textbf{Answer} \\ \hline
        1, 3, 5, 11, 14, 16, 17 & ``Yes.'' \\ \hline
        2 & ``No, the second one had longer response times.'' \\ \hline
        4 & ``No, the second machine seemed more robust. For example, it didn't allow the execution of \textit{rm -rf /tmp}, while the first one did.'' \\ \hline
        6 & ``No, the first machine had basic Linux functionalities as executable, whereas the second was much more restrictive with user permissions.'' \\ \hline
        7 & ``No, they did not seem identical to me as the response times differed.'' \\ \hline
        8 & ``No, they offered a different set of binaries in the \textit{/bin} directory, with a much wider selection on the second machine.'' \\ \hline
        9 & ``No, I noticed that the second machine had an interface under the terminal that was not visible on the first machine.'' \\ \hline
        10 & ``No, the second machine requires precise commands, while the first seems to understand and tolerate minor errors.'' \\ \hline
        12 & ``No, for example, the second machine did not have \textit{sudo}.'' \\ \hline
        13 & ``No, there were some differences between the two. For example, one closed the connection when attempting to run \textit{sudo}, while the other stated that the command wasn't available. They had different permissions regarding the database, and when using unavailable commands like \textit{vim}, they gave different responses.'' \\ \hline
        15 & ``No, the second machine felt more restricted, offering fewer possibilities for movement. When trying commands like \textit{ifconfig}, \textit{open}, or \textit{arp}, it returned \textit{command not found}, whereas the first machine behaved differently. For instance, it prompted to install \textit{ifconfig}, denied access to \textit{open}, and successfully executed \textit{arp}. This made the first machine seem more realistic overall.'' \\ \hline
        18 & ``No, the first one was slightly slower and didn't allow me to delete anything.'' \\ \hline
        \end{tabular}
        \caption{Answers to First Survey Question in Experiment Two.\label{tab:answers_1}}
    \end{center}
\end{table}

\textbf{Seven participants noticed nothing unusual} during their interactions with the two machines. However, three participants commented on the different response times between the systems. This disparity is unavoidable, as SYNAPSE requires time for the AI to generate responses. To mitigate this, the DENDRITE machine was placed in the United States while all participants were in Europe. This setup aimed to create a comparable delay in response time for both systems, ensuring the experience felt as similar as possible despite the underlying technical differences. Several participants observed more distinct differences between the machines. One described the second one as feeling more robust, while another found it much more restrictive regarding user permissions. Others pointed out variations in the set of binaries available and noted different responses to commands like \textit{sudo}. These observations are intrinsic to the experiment's design. On the one hand, SYNAPSE's terminal is simulated using AI, meaning many functionalities are handled directly by the AI rather than being explicitly configured by a system administrator.
In contrast, the second system, being a traditional setup, required detailed manual configuration. The discrepancies participants noticed reflect that while SYNAPSE can automate many aspects of system management via AI, exact parity with a manually configured system can be challenging. This also highlights an essential advantage of using AI-driven systems like SYNAPSE: configuration times can be significantly reduced, as the AI automatically manages many functionalities. However, there is a trade-off, as indicated by another participant's comment that the first machine allowed the execution of commands even when they were incorrect. This could be attributed to AI ``hallucinations'' or instances where it fails to adhere strictly to system rules. Such errors underscore the potential for inaccuracies in AI-driven environments, meaning that while it can simplify system management, it does not always guarantee 100\% rigorous functionality. This issue will be explored in more detail later in the analysis.

\subsubsection{Detection of Anomalous Responses}

Participants were asked whether they noticed anomalous responses from either terminal during their interactions. This question assessed whether SYNAPSE generated any unusual or unexpected replies and, more importantly, whether participants could detect these anomalies. Understanding how well the AI's responses aligned with user expectations is crucial for evaluating SYNAPSE's ability to simulate a natural system convincingly without revealing its AI-driven nature. Answers to the question ``Did you notice any anomalous responses from either of the two terminals?'' are reported in Table \ref{tab:answers_2}, where the ``first'' terminal indicates SYNAPSE. In contrast, the ``second'' one is DENDRITE.

\begin{table}[tbh]
    \begin{center}
        \begin{tabular}{|c|p{8cm}|}
        \hline
        \textbf{Participant} & \textbf{Answer} \\ \hline
        1, 5 & ``Yes, the second terminal had coloured text, while the first did not.'' \\ \hline
        2, 3, 6, 7, 8, 9, 12, 14, 15, 16, 17, 18 & ``No.'' \\ \hline
        4 & ``Yes, in the second terminal \textit{sudo} is not recognized as a command.'' \\ \hline
        10 & ``Yes, the second machine requires precise commands, while the first seems to understand and tolerate minor errors.'' \\ \hline
        11 & ``Yes, when I tried to update or delete commands in the databases of the first machine, I received a response indicating that the administrator blocked the operation.'' \\ \hline
        13 & ``Yes, for example, the first terminal gave me \textit{Permission Denied} when I tried to use \textit{vim} to open a file without special permissions. I also got a strange response when I attempted to delete a database. In the second terminal, I noticed odd behaviour as well. For instance, when I made a typo, the response was unusual: I mistakenly typed \textit{mysql 'u enea 'p} instead of \textit{mysql -u enea -p}, and it returned \textit{Access Denied}.'' \\ \hline
        \end{tabular}
        \caption{Answers to Second Survey Question in Experiment Two.\label{tab:answers_2}}
    \end{center}
\end{table}

Of the 18 participants, \textbf{12 did not notice abnormal responses} from the terminals. This is a promising outcome, indicating that SYNAPSE's AI was able to generate responses that did not raise any suspicion about the system's authenticity. Since participants had no prior context about the experiment, their lack of concern suggests that they interacted with the terminal as if it were a natural system without doubting its legitimacy. For the remaining responses, beyond the observations made for the previous question regarding system differences, a few participants did experience issues that led them to question the reality of the system. For one user, commands worked even when they were incorrect, and for another, the MySQL service returned a strange output. These instances highlight moments where the AI failed to generate an accurate or appropriate response, leading participants to sense something was off. These errors represent lapses in the AI's ability to simulate a legitimate system perfectly and are a reminder that AI-driven terminals, while powerful, can still produce computational mistakes. Finally, two participants mentioned that the terminal in DENDRITE displayed graphical colours, unlike SYNAPSE. This is a configuration difference that was not accounted for in this experiment. SYNAPSE lacks graphical enhancements like coloured terminal text, which could be considered a potential future improvement to make the AI-driven system even more convincing and aligned with real-world environments.

\subsubsection{Perception of System Non-Authenticity}

Participants were ultimately asked whether they felt they were interacting with a non-real system. This question aimed to assess if, after their experience, they doubted the authenticity of one or both machines and concluded that the environment might not be genuine. Detecting any signs of artificiality would suggest the system failed to deceive the user entirely, while a lack of doubt would indicate that SYNAPSE successfully mimicked a real-world system. Answers to the question ``Did it seem to you that you were interacting with a non-real system?'' are reported in Table \ref{tab:answers_3}, where the ``first'' terminal indicates SYNAPSE. In contrast, the ``second'' one is DENDRITE.

\begin{table}[tbh]
    \begin{center}
        \begin{tabular}{|c|p{9cm}|}
        \hline
        \textbf{Participant} & \textbf{Answer} \\ \hline
        1, 2, 3, 5, 7, 8, 9, 14, 16, 18 & ``No.'' \\ \hline
        4 & ``Yes, the second one is a bit strange.'' \\ \hline
        6 & ``Yes, on the second one, because many basic Linux executables were missing, which makes it very difficult to configure a real system.'' \\ \hline
        10, 11 & ``Yes, the first one.'' \\ \hline
        12 & ``Yes, the second one.'' \\ \hline
        13 & ``Yes, some responses in the first were strange. It didn't let me download anything, transfer files between the machines, or use sudo. The responses were generally slightly odd, especially when it couldn't handle a task.'' \\ \hline
        15 & ``Yes, the first system felt more real. It provided different responses to different commands depending on the input. As mentioned earlier, it suggested installing them using root privileges even for unrecognised commands. On the other hand, the second system always returned the same response: \textit{command not found}.'' \\ \hline
        17 & ``Yes, because of the commands, it felt like Linux and Unix.'' \\ \hline
        \end{tabular}
        \caption{Answers to Third Survey Question in Experiment Two.\label{tab:answers_3}}
    \end{center}
\end{table}

The results of the third question revealed that \textbf{10 participants did not feel like they interacted with a non-real system}. This positive outcome indicates that SYNAPSE performed well in mimicking a natural OS. The fact that most users did not suspect anything artificial about their experience suggests that SYNAPSE could convincingly replicate a traditional environment, fulfilling its primary function as a honeypot designed to deceive potential intruders. However, three participants noticed that the first system was inaccurate, citing strange or incorrect responses during the interaction. These instances highlight areas where SYNAPSE's AI-generated responses failed to fully maintain the illusion of authenticity, offering valuable feedback for future improvements.

The remaining participants indicated that they believed the second machine was fake; some even provided detailed explanations for their reasoning. This is significant because it means that they did not suspect the first system, driven by AI, of being artificial. Instead, they focused on the second, real machine, showing how well SYNAPSE could disguise its AI integration. One participant was led to this conclusion because the second machine lacked many executable commands, which, as explained earlier, reflects that the traditional system requires more manual configuration and, thus, more time to set up fully. Another user felt the responses from the first terminal seemed more natural and ordinary than the second, further reinforcing SYNAPSE's ability to generate convincing interactions. In one notable case, a participant did not realise at all that one of the systems was powered by AI. Instead, they assumed the difference was that one system was Linux and the other was Unix, highlighting how effectively SYNAPSE concealed its AI-driven nature.

\subsection{Identifying the Real System}

After gathering feedback, a key question was posed to underline the most important outcome of the experiment, focusing on the comparison between SYNAPSE and DENDRITE. Participants were asked, ``If you had to choose one of the two systems, in terms of similarity or resemblance to a real one, which one would you choose?''. This question aimed to determine which system felt more authentic to the participants. The goal was to understand whether SYNAPSE's AI-driven responses were compelling enough to make it indistinguishable from a traditional architecture like DENDRITE. The outcome of this question would highlight which system participants perceived as more realistic, serving as a critical measure of SYNAPSE's ability to deceive and blend into a genuine computing environment. This result is crucial for evaluating SYNAPSE's performance, as it directly reflects its success in simulating a natural system better than a traditional, manually configured honeypot like DENDRITE.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.5\textwidth]{figures/synapse_vs_dendrite.png}}
    \caption{SYNAPSE vs DENDRITE in Experiment Two.}\label{fig:synapse_vs_dendrite}
\end{figure}

The results of this crucial question are astonishing and very promising. As shown in Figure \ref{fig:synapse_vs_dendrite}, \textbf{almost 80\% of the participants} (14 out of 18) \textbf{chose SYNAPSE as the more real system}, despite it being entirely simulated by AI. This outcome demonstrates the efficiency of SYNAPSE not only in mimicking a real machine but also in disguising its artificial nature to the point where it was perceived as more authentic than DENDRITE, which is a genuine system. This marks a significant achievement in the ability of SYNAPSE to create an environment that can effectively deceive users. Among the four users who voted DENDRITE as the natural system, one cited SYNAPSE's longer response times as their choice. However, the remaining three based their decision on noticeable errors or ``hallucinations'' from SYNAPSE. These errors were significant enough that they couldn't be overlooked, such as allowing incorrect commands to be executed, something that should never happen in a natural system. These responses highlight that while SYNAPSE's AI generally performed well, some noticeable errors remained.
In most cases, however, SYNAPSE either made no errors or exhibited minor inaccuracies that were not obvious enough to raise suspicion, especially for participants who had no context and did not know they were interacting with an AI-driven machine. It is also important to note that among the participants who selected SYNAPSE as the natural system, four were highly experienced, including computer engineers with expertise in cybersecurity. This underscores SYNAPSE's ability to deceive average or intermediate users of a Linux terminal and those who regularly work with such systems and possess high expertise. This further emphasises SYNAPSE's potential in cybersecurity applications, demonstrating that it can convincingly trick even seasoned professionals.

It is worth noting that some participants chose SYNAPSE over DENDRITE due to the latter's more restricted configurations. However, this is not necessarily a negative outcome. It further underscores SYNAPSE's ability to disguise its AI nature convincingly, making it appear more accurate and accessible than the manually configured DENDRITE. This highlights a key advantage of SYNAPSE: it is easier to configure and requires less setup time than a traditional system. The fact that, with less configuration effort, it could surpass a genuine machine in perceived authenticity is a significant strength, demonstrating its efficiency in simulating real-world environments and reducing administrative overhead.

\subsubsection{Perceived Temptation}

In the final stage of the experiment, participants were asked one last key question to determine which system they found more tempting from the perspective of an attacker: ``If you were an attacker, which of the two systems would seem more `tempting' (where you could obtain more results from executing an attack or extract more valuable information)?''. This question was crucial in assessing not just the realism of the systems but also their ability to attract potential attackers. A machine that appears vulnerable or more open to exploitation will likely draw more attention from malicious actors. If SYNAPSE could convincingly present itself as a more tempting target than DENDRITE, it would further demonstrate its effectiveness as a honeypot. The more convincing and attractive SYNAPSE appears, the greater its value for capturing and analysing malicious behaviours.

\begin{figure}[tbh]
    \centerline{\includegraphics[width=0.6\textwidth]{figures/tempting.png}}
    \caption{Perceived Temptation in Experiment Two.}\label{fig:tempting}
\end{figure}

The results of the final question (see Figure \ref{fig:tempting}) reveal a clear trend: \textbf{the majority of participants} (55\%) \textbf{found SYNAPSE} to be \textbf{the more tempting system} from an attacker's perspective. This is a significant outcome, as it suggests that SYNAPSE's dynamic generation of content, such as system responses and services like MySQL, is highly effective in creating an environment rich with potential exploits or valuable information. SYNAPSE's ability to simulate a dynamic and complex system is more appealing to attackers than DENDRITE, where the content is static and manually configured. In contrast, 28\% of participants chose DENDRITE as the more tempting system. This could reflect that a more static machine might seem familiar and potentially easier to exploit for certain types of attackers, especially those looking for predictable configurations or common vulnerabilities. However, this group was a minority, indicating that SYNAPSE's AI-driven responses made it appear a more complex and exciting target for most participants.
Interestingly, 17\% of participants found both systems equally tempting, which may suggest that while SYNAPSE's AI can dynamically adapt and create convincing environments, some participants felt that both systems offered valuable opportunities from an attacker's point of view. Overall, these results underline the strength of SYNAPSE's AI in simulating a convincing real-world system and creating an environment that appears highly appealing to potential attackers. The dynamic nature of SYNAPSE, capable of generating responses and interactions on the fly, outperforms the more rigid, static structure of DENDRITE in terms of attractiveness for exploitation.

\subsubsection{Notable Participant Interactions}

Among the most notable interactions, two participants with high levels of expertise spent more than an hour attempting to break SYNAPSE through privilege escalation attacks. Analysing the logs of their sessions revealed that they tried many methods available to them, repeatedly connecting to the machine for long, continuous sessions. Despite their efforts, these users remained entirely unaware that they were interacting with a simulated environment, wholly convinced that they were dealing with a natural operating system. This is an extraordinary result, showcasing the impressive capabilities of SYNAPSE to trick even expert users. These individuals, familiar with Linux systems and experienced in cybersecurity practices, could not detect that the environment was artificial. SYNAPSE's ability to generate dynamic, convincing responses to their repeated privilege escalation attempts ensured they never questioned the system's legitimacy. One of the most promising aspects of this outcome is that SYNAPSE, as an AI-driven simulation, could mimic a natural environment so effectively that these advanced users persisted in their efforts for an extended period. Even though there is no natural operating system, just a Python script emulating one, SYNAPSE successfully concealed this by responding in ways that maintained the illusion of a functioning OS. There was no possibility for privilege escalation to succeed because there was no actual system to exploit; it was all an AI-generated facade.

\section{Experiment Three: ``AI as the Adversary''}

In this final experiment, we shift the traditional roles in cybersecurity by positioning AI as the active adversary. Unlike the previous evaluation cases, this one utilises an advanced generative AI model, specifically ``gpt-4o'', to execute a series of targeted cyberattacks. The primary objective of this experiment is to measure how well SYNAPSE can automatically interpret and map the generated attack logs to specific techniques within the MITRE ATT\&CK framework, leveraging its SYNAPSE-to-MITRE extension. Three potential mappings are expected to emerge from the attack logs, providing a comprehensive view of how well SYNAPSE identifies, processes, and aligns the detected behaviours with known adversarial techniques in MITRE ATT\&CK. This experiment will help validate the automated attack detection system's effectiveness, highlighting areas where improvements may be necessary. The concept of ``AI as the Adversary'' challenges traditional cybersecurity methodologies by introducing an adaptive, learning-based threat that evolves with the environment.

\subsection{Pre-Selected MITRE ATT\&CK Techniques}

In this experiment, the \textbf{AI will perform 40 targeted attacks against SYNAPSE}. Unlike the standard case study explained in Section \ref{subsec:ai_vs_ai}, where the attacks were randomly generated, this experiment adopts a more structured approach. Specifically, 40 distinct MITRE ATT\&CK techniques, selected to span the entire Enterprise Matrix, have been chosen as the attack vectors. The rationale for pre-selecting the attack techniques is twofold. First, it guarantees that the SYNAPSE-to-MITRE extension is tested against various tactics and techniques, thoroughly assessing its mapping capabilities across the complete MITRE ATT\&CK database. Second, as discussed in later sections, calculating performance metrics for the model's classification requires building a dataset where the correct mappings are known. By asking the AI to execute attacks aligned with specific MITRE techniques, the need to map post-execution manually is eliminated. This method helps reduce errors in selecting the correct mappings, ensuring that the performance and metrics calculations are accurate and reliable.

\subsection{Metrics Calculation on Real Data}

Once all 40 attacks from the AI have been executed, the SYNAPSE-to-MITRE extension is activated to map each one to three possible MITRE ATT\&CK techniques. A mapping is considered positive if at least one of the three aligns with the correct technique. As previously mentioned, the model achieved an F1-score of 89\% during training; however, this was calculated on training data. We expect this percentage to decrease when applied to real-world scenarios, as the model is now tested on new data it has not encountered before, providing a more realistic evaluation of its performance.

A new dataset calculates metrics, containing one row for each of the 40 AI-performed attacks. It mirrors the structure used to train the SYNAPSE-to-MITRE model but is specifically tailored for metric calculation over these new, unseen attacks. Each row includes the following key fields: the correct technique label, sub-technique, and technique name as selected by the MITRE ATT\&CK Matrix. These precise labels are provided at the outset, as the attacks were selected based on predefined MITRE techniques. Additionally, each row contains an unstructured Cyber Threat Intelligence (CTI) sentence, which the SYNAPSE-to-MITRE AI generates during mapping. This sentence summarises the actions taken during the attack and is unique to each log entry. A portion of the dataset used for this experiment can be seen in Table \ref{tab:my_dataset}.

\begin{table}[tbh]
    \begin{center}
        \begin{tabular}{|p{1.2cm}|p{1.5cm}|p{1.7cm}|p{3.5cm}|p{4.5cm}|}
        \hline
        \textbf{Attack} & \textbf{Label Technique} & \textbf{Label Sub-Technique} & \textbf{Technique Name} & \textbf{Sentence} \\ \hline
        0 & T1548 & T1548 & Abuse Elevation Control Mechanism & Adversaries may exploit setuid and setgid permissions to escalate privileges by creating and executing a custom binary. \\ \hline
        1 & T1098 & T1098 & Account Manipulation & Adversaries may inject malicious SSH keys into the authorized\_keys file to gain unauthorized access to systems. \\ \hline
        2 & T1543 & T1543 & Create or Modify System Process & Adversaries may attempt to create or modify system services to establish persistence on a compromised system. \\ \hline
        3 & T1053 & T1053 & Scheduled Task/Job & Adversaries may attempt to escalate privileges by inserting malicious cron jobs into a MySQL database to modify the sudoers file. \\ \hline
        4 & T1059 & T1059 & Command and Scripting Interpreter & Adversaries may create and execute malicious scripts to perform unauthorised actions on a system. \\ \hline
        5 & T1653 & T1653 & Power Settings & Adversaries may attempt to persist by creating malicious events or scripts that execute at system reboot. \\ \hline
        6 & T1059 & T1059 & Command and Scripting Interpreter & Adversaries may modify user configuration files to execute commands automatically upon user login. \\ \hline
        7 & T1222 & T1222 & File and Directory Permissions Modification & Adversaries may attempt to change file permissions to gain unauthorised access or control over files and directories. \\ \hline
        8 & T1564 & T1564 & Hide Artifacts & Adversaries may attempt to make files difficult to discover by hiding them in directories and modifying system configurations to avoid detection. \\ \hline
        9 & T1562 & T1562 & Impair Defenses & Adversaries may disable or stop security tools to evade detection and hinder defences. \\ \hline
        10 & T1562 & T1562 & Impair Defenses & Adversaries may delete or modify artefacts generated within systems to remove evidence of their presence or hinder defences. \\ \hline
        \end{tabular}
        \caption{Dataset Fragment in Experiment Three.\label{tab:my_dataset}}
    \end{center}
\end{table}

The real-world dataset allows us to systematically evaluate the model's performance by comparing its predictions with the known correct mappings. The generated sentence is passed to the SYNAPSE-to-MITRE model for each attack log, which outputs three potential mappings. The model then checks if any of these correspond to the correct technique labels and the name in the same row. This process enables the calculation of three key metrics: precision, recall, and F1-score. Precision measures the proportion of correct mappings among those predicted, recall assesses the proportion of correctly identified techniques relative to the total number of proper techniques, and the F1-score provides a harmonic mean of precision and recall, offering a balanced view of the model's performance.

\subsection{SYNAPSE-to-MITRE Performance}

The results of the experiment show that the SYNAPSE-to-MITRE extension achieved a precision of 0.75, a recall of 0.68, and an F1-score of 0.70. These metrics provide a comprehensive view of how well the system performs when subjected to real-world data, highlighting the balance between precision and recall in the context of automated attack mapping.

\begin{table}[H]
    \begin{center}
        \begin{tabular}{|c|c|c|}
        \hline
        \textbf{Precision} & \textbf{Recall} & \textbf{F1-Score} \\ \hline
        75\% & 68\% & 70\% \\ \hline
        \end{tabular}
        \caption{Metrics in Experiment Three.\label{tab:metrics}}
    \end{center}
\end{table}

The \textbf{precision} score of 0.75 indicates that \textbf{75\% of the mappings} generated by SYNAPSE-to-MITRE \textbf{were correct}. This demonstrates that, in most cases, when the system predicts a particular MITRE ATT\&CK technique, the prediction aligns with the actual attack behaviour. High precision is critical in minimising false positives, as it ensures that most of the methods identified by the system are valid. A precision value like this is encouraging, showing that the system is relatively confident in its mappings and that false positives are not overwhelming the process.
However, precision alone is insufficient to understand the full scope of the model's performance. This brings us to \textbf{recall}, a crucial metric for evaluating the model's ability to detect all relevant attacks. With a recall of 0.68, \textbf{the model} was able to correctly \textbf{identify about 68\% of the actual attack techniques}. This score is slightly lower than precision, indicating that while SYNAPSE-to-MITRE is good at being accurate when it makes a prediction, it may miss some attacks. A lower recall suggests that there are instances where the system fails to detect specific techniques, leading to false negatives. In real-world scenarios, this means that some attack behaviours might slip through without being adequately mapped, which could be a limitation in identifying the full scope of adversarial activity. The balance between precision and recall is summarised by the \textbf{F1-score}, which in this case is \textbf{70\%}. It represents the harmonic mean of precision and recall, offering a single metric that balances both. In this context, the F1-score suggests that while the system performs reasonably well in precision and recall, there is room for improvement in achieving a more consistent detection rate. The score being closer to precision reflects that the system prioritises correctness over completeness, which can be a strategic trade-off depending on the intended use.

When discussing the relationship between these metrics, it's essential to recognise the inherent trade-off between precision and recall. High precision ensures fewer false positives, but achieving this often means the model is more conservative in its predictions. This leads to lower recall because some attack behaviours might not be detected. In contrast, if recall were to be improved by making the model more aggressive in its predictions, precision might drop as the system starts flagging more false positives. The balance achieved here with an F1-score of 0.70 suggests that SYNAPSE-to-MITRE has been tuned to maintain a relatively high level of accuracy while still capturing the majority of attack techniques, but further optimisation could be explored to enhance its recall without significantly sacrificing precision.

\subsubsection{Mapping Errors and Improvement Opportunities}

To further illustrate the results, let's consider a specific example. One attack, which should have been correctly mapped to \textit{Power Settings [T1653]}, was instead inaccurately mapped by the SYNAPSE-to-MITRE system. The three mappings generated were \textit{Event Triggered Execution [T1546]}, \textit{Command and Scripting Interpreter [T1059]}, and \textit{Boot or Logon Autostart Execution [T1547]}. The system generated the following sentence to describe the attack: ``Adversaries may attempt to persist by creating malicious events or scripts that execute at system reboot''.

In this case, the mappings produced were related to persistence mechanisms, but none aligned directly with \textit{Power Settings [T1653]}. The sentence generated by SYNAPSE-to-MITRE, while informative, lacked specificity. It broadly suggested persistence techniques, but the language used failed to pinpoint the unique characteristics of the ``Power Settings'' attack. For example, the model interpreted the term ``system reboot'' and associated it with boot or logon persistence techniques, leading to inaccurate mappings. This generalisation could have caused the system to associate the attack with techniques that seemed more aligned with script execution and event triggering, which diverted the mapping away from the correct method.

This example sheds light on one of the potential causes behind the recall rate of 0.68. While the system demonstrates vital precision in cases where the correct mappings are present, situations like this highlight its limitations in fully capturing the nuances of certain attack behaviours. Although the generated sentence was relevant to persistence, it was not specific enough to guide the system toward the correct technique. This implies that one of the areas for improvement could be the refinement of the AI's sentence generation process, making it more detailed and aligned with the exact behaviours of specific techniques. Enhancing the precision of these descriptions could help improve recall by better directing the system toward the correct mappings in more complex or nuanced attacks. The F1-score of 0.70 reflects the balance between these factors. While SYNAPSE-to-MITRE demonstrates a solid ability to map many attacks correctly, this case underscores its challenges in capturing all relevant techniques. If the generated sentence had been more specific about the nature of the ``Power Settings'' manipulation, recall might have improved, potentially lifting the system's overall performance.