Almost completed chapter 6

docs/bibliography/bibliography.bib

@@ -713,7 +713,7 @@ AMD64 Architecture Processor Supplement},
 	title={CCNP Security Firewall 642-617 Official Cert Guide},
 	date={2011-10-01},
 	author={David Hucaby, David Garneau, Anthony Sequeira},
-	page={436},
+	pages={436},
 	url={https://books.google.es/books?id=-lvwaqFbIS8C&dq=syn+packet+firewall+ignore+payload}
 },
 
@@ -813,6 +813,112 @@ AMD64 Architecture Processor Supplement},
 	author={Michael Boelen},
 	date={2015-05-12},
 	url={https://linux-audit.com/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/}
+},
+
+@online{jynx2_infosecinstitute,
+	title={Blackhat Academy},
+	author={Blackhat Academy},
+	date={2012-03-15},
+	url={https://resources.infosecinstitute.com/topic/jynx2-sneak-peek-analysis/}
+},
+
+@article{ldpreload_so_jynx,
+	title={Linux Rootkit Detection With OSSEC},
+	author={Sally Vandeven},
+	date={2014-03-26},
+	pages={18-19},
+	url={https://www.giac.org/paper/gcia/8751/rootkit-detection-ossec/126976}
+},
+
+@proceedings{ldpreload_pros,
+	title={The Continued Evolution of
+Userland Linux Rootkits},
+	pages={3-6},
+	date={2022-03-13},
+	url={https://www.bsidesdub.ie/past/media/2022/darren_martyn_userland_linux_rootkits.pdf}
+},
+
+@proceedings{ldpreload_pros_2327,
+	title={The Continued Evolution of
+Userland Linux Rootkits},
+	pages={23-27},
+	date={2022-03-13},
+	url={https://www.bsidesdub.ie/past/media/2022/darren_martyn_userland_linux_rootkits.pdf}
+},
+
+@online{jynx_github,
+	title={Jynx-kit},
+	author={BlackHatAcademy.org},
+	url={https://github.com/chokepoint/jynxkit}
+},
+
+@online{jynx2_github,
+	title={Jynx-kit (2)},
+	author={BlackHatAcademy.org},
+	url={https://github.com/chokepoint/Jynx2}
+},
+
+@online{azazel_github,
+	title={Azazel},
+	url={https://github.com/chokepoint/azazel}
+},
+
+@online{azazel_wiki,
+	title={Azazel},
+	url={https://web.archive.org/web/20141102234744/http://blackhatlibrary.net/Azazel#Hooking_Methods}
+},
+
+@online{ld_preload_detect,
+	title={Linux Attack Techniques: Dynamic Linker Hijacking with LD Preload},
+	date={2022-05-18},
+	url={https://www.cadosecurity.com/linux-attack-techniques-dynamic-linker-hijacking-with-ld-preload/}
+},
+
+@online{suckit_rootkit,
+	indextitle={SucKIT rootkit},
+	url={https://github.com/CSLDepend/exploits/blob/master/Rootkit_tools/suckit2priv.tar.gz}
+},
+
+@online{suckit_lasamhna,
+	title={Linux Kernel Rootkits},
+	url={https://www.la-samhna.de/library/rootkits/basics.html#FLOW}
+},
+
+@online{dev_kmem,
+	title={kmem(4) - Linux man page},
+	url={https://linux.die.net/man/4/kmem}
+},
+
+@online{dev_kmem_debian,
+	title={mem(4)},
+	url={https://manpages.debian.org/buster-backports/manpages/port.4.en.html}
+},
+
+@online{dev_kmem_off_default,
+	title={Change CONFIG\_DEVKMEM default value to n},
+	url={https://lore.kernel.org/all/20161007035719.GB17183@kroah.com/T/}
+},
+
+@online{diamorphine_github,
+	title={Diamorphine},
+	url={https://github.com/m0nad/Diamorphine}
+},
+
+@online{incibe_rootkit_lkm,
+	title={Malware in Linux: Kernel-mode-rootkits},
+	author={Antonio López},
+	date={2015-03-26},
+	url={https://www.incibe-cert.es/en/blog/kernel-rootkits-en}
+},
+
+@online{reptile_github,
+	title={Reptile},
+	url={https://github.com/f0rb1dd3n/Reptile}
+},
+
+@online{usermode_helper_lkm,
+	title={call\_usermodehelper, Module Loading},
+	url={https://www.kernel.org/doc/htmldocs/kernel-api/API-call-usermodehelper.html}
 }
 
 

docs/chapters/chapter6.tex

@@ -1,4 +1,75 @@
 \chapter{Related work} \label{chapter:related_work}
 % Comparison of the rootkit with other eBPF and non eBPF rootkits.
+During this research work, we have developed a rootkit that loads itself in the kernel, incorporating functionalities at the network, and at both the user and kernel space. Although eBPF, the technology used for this rootkit, has been rarely explored before, many of the techniques presented here directly correspond or mimic those historically incorporated in classic rootkits, while others are also inspirated in techniques already explored with eBPF in recent research. 
+
+In this section, we will provide a comprehensive review on previous research and work on rootkits, its types and most relevant examples, apart from offering a comparison in terms of techniques and functionality with them. In particular, we will attempt to highlight the differences of our eBPF rootkit with respect with others that can be built with other methods and also compared to those already built using eBPF.
+
+\section{User-mode rootkits}
+As we mentioned during section \ref{section:motivation}, user-mode rootkits are those that are run at the same level as common user applications. They do not require to be loaded at the kernel to tamper with the execution of programs, but rather they usually redirect or substitute common system programs to achieve their malicious purposes.
+
+The most popular and commonly found technique in user-mode rootkits is the LD\_PRELOAD technique, which enables to redefine function calls at shared libraries. LD\_PRELOAD is an environment variable interpreted by the dynamic linker at runtime that indicates to preload a shared library before those already indicated at the ELF file \cite{ldpreload_pros}. If this preloaded library implements the same function as some other library, then the preloaded function overrides the original. This means that a rootkit may define functions into programs so that its custom malicious code is run instead of that from the original shared libraries, without the need of modifying any of these pro
+
+This type of rootkits are considered trivial to detect by an investigator, however they are easy to write and their capabilities can be quickly extended, which has motivated the creation of many LD\_PRELOAD rootkits.
+
+\subsection{Jynx/Jynx2}
+Jynx \cite{jynx_github} is one of the most well-known rootkits using the LD\_PRELOAD technique. It injects the name of its malicious library into the file \textit{/etc/ld.so.preload}, which acts similarly to defining the LD\_PRELOAD environment variable for each executable, but instead applying this setting to any program (since every program checks this file to know the libraries to preload) \cite{ldpreload_so_jynx}.
+
+Its first version, Jynx, was best known for implementing a backdoor by hooking the function accept() \cite{ldpreload_pros_2327}. This function, responsible of accepting a connection, was defined in a preloaded malicious library so that any connection (specifically encrypted ones) could be checked to come from a remote attacker. If they were, the rootkit would accept and establish a connection, followed by executing a remote root shell which provided the attacker with remote access.
+
+In its later version Jynx2 \cite{jynx2_github}, the rootkit incorporated other mechanisms focused on hiding the rootkit activity \cite{jynx2_infosecinstitute}. This included hiding Jynx's connections by hooking read calls at the /proc filesystem (which we covered in section \ref{section:proc_filesystem} so that processes related with the rootkit activity remain undisclosed. Other functionalities include file hiding, privilege escalation or multi-factor authentication in the rootkit backdoor.
+
+\subsection{Azazel}
+Azazel is another LD\_PRELOAD rootkit originally based on Jynx and that extends its functionalities in multiple areas, including additional anti-debugging and anti-detection techniques. This rootkit incorporates more hooked functions into its preloaded library to achieve capabilities such as:
+\begin{itemize}
+\item Avoid detection by programs such as ldd (which lists libraries to be loaded in an executable), ps (which lists processes) or lsof (that displays opened files by processes).
+\item Hide rootkit files and processes.
+\item Hide rootkit-related network connections.
+\item Incorporate backdoors (one launching an encrypted connection, another in plaintext).
+\item Clean logs and allow for local privilege escalation.
+\item Anti-debugging, by means of hooking ptrace() calls.
+\end{itemize}
+
+\subsection{TripleCross comparison}
+Jynx and specially Azazel are advanced rootkits with many functionalities, but they are restricted both because of the LD\_PRELOAD technique and because of working from the user space.
+
+In particular, the use of LD\_PRELOAD in a program can be detected by the \textit{export} command and removed via \textit{unset} \cite{ld_preload_detect}. This technique also does not work on statically-linked programs, that is, those at which the calls at libraries and exported functions are resolved at compile time \cite{ldpreload_pros}. On the other hand, because they only have access to user space programs and components, their activities can be more easily detected than a rootkit working from inside the kernel.
+
+Since TripleCross is composed of both a kernel-side component (the eBPF programs at the kernel) and a user-side component (the rootkit user program that communicates with eBPF), the capabilities of user-mode rootkits are more limited than those that could be eventually implemented in TripleCross, yet they are easier and faster to implement, and do not require loading an eBPF program in the kernel, an event which is likely to be logged by EDRs and IDSs. 
+
+With respect of the capabilities offered, the ability to hook function calls by preloading libraries so that malicious code is run can be considered analogous to eBPF tracepoint, kprobe and uprobes programs. On one hand, eBPF can modify parameters and execute code from the kernel transparently from user programs whilst, on the other hand, user-mode rootkits may execute any instruction at the preloaded libraries, but eBPF is restricted to a certain range of operations and those offered by eBPF helpers. Nevertheless, both types of rootkits are able to implement the key features of rootkits, including a backdoor and C2 system, and basic stealth mechanisms.
+
+\section{Kernel-mode rootkits}
+As we mentioned during section \ref{section:motivation}, kernel-mode rootkits are run at the same level of privilege as the operating system, thus enjoying unrestricted access in both the kernel and user space. These are the hardest and riskiest to develop (since they need to work with kernel structures and any error could cause a kernel panic), yet the offer the richest and most powerful variety of functionalities. Also, they mostly remain hidden from the user space, thus boosting their stealth, while at the same time thye are capable of  further hiding their activities thanks to their capabilities at both the user and kernel space.
+
+Historically, kernel-mode rootkits in Unix systems have been built as Loadable Kernel Modules (LKM), whose original purpose is to expand the capabilities of the kernel by adding new modules for specific tasks without the need of recompiling or even reloading the kernel. 
+
+\subsection{SucKIT rootkit}
+Although the great majority of kernel-mode rootkits are loaded as LKMs, SucKIT \cite{suckit_rootkit} belongs to one of the exceptions. This old rootkit uses the \textit{/dev/kmem} special file \cite{dev_kmem} for accessing kernel memory, including both reading and writing. This means that the rootkit could potentially find and overwrite key data at the kernel \cite{suckit_lasamhna}.
+
+Nowadays, this type of rootkit is not relevant outside of old machines, since distributions such as Debian have limited access to this file to kernels compiled with the CONFIG\_DEVKMEM parameter \cite{dev_kmem_debian} which is disabled by default \cite{dev_kmem_off_default}.
+
+\subsection{Diamorphine}
+Diamorphine \cite{diamorphine_github} is one of the best known kernel-mode rootkits, and it is implemented as a LKM. This type of rootkits commonly intercept and hook system calls from the kernel, executing malicious code (together with the original function) with the aim of achieving different malicious purposes.
+
+When a system call takes place in the user space, an interrupt is issued to the kernel, which checks the type of syscall that has been issued. This is done using a syscall table, which relates each system call to the function at the kernel where its implementation is stored. A common technique by LKMs is to modify the syscall table, so that it points to the functions implemented by the LKM, where the malicious code will be executed \cite{incibe_rootkit_lkm}. This code may be a modified version of the original (e.g.: a sys\_getdents64 call that lists files but hides those belonging to the rootkit) or modify kernel and user data received at the hooked function.
+
+Because LKMs are run directly in the kernel, they are not limitied and thus they can read, write and allocate kernel and user memory freely. It is also possible to hook and modify data at internal kernel functions by means of, for instance, kprobe programs.
+
+In the case of Diamorphine, it uses the aforementioned capabilities to hide processes, provide local privilege escalation, hide files and directories and implement a messaging protocol using system calls (it enables a malicious user to locally communicate actions to the rootkit with \textit{kill} signals). Most importantly, it hides itself from commands such as \textit{lsmod}, which list the LKMs loaded into the kernel, thus turning invisible.
+
+\subsection{Reptile}
+Reptile \cite{reptile_github} is another LKM rootkit which incorporates advanced stealth and network functionalities. Some of its most relevant capabilities include:
+\begin{itemize}
+\item Hiding files, directories, processes and network connections related to the rootkit activity.
+\item A backdoor that is operated via port-knocking triggers (which we explained in section \ref{subsection:triggers}).
+\item C2 capabilities via a custom shell (similar to the pseudo-shells of our rootkit).
+\end{itemize}
+
+\subsection{TripleCross comparison}
+Although TripleCross incorporates many of the techniques mentioned in Reptile and Diamorphine (backdooring, modification of files and directories or local privilege escalation) these capabilities are achieved using workarounds for the limitations of eBPF programs, namely not having write access in kernel memory. For instance, Reptile can grant root privileges to any program by overwriting the kernel data structure storing the user privileges, whilst this is not achievable for TripleCross, which has to take advantage of user buffers when reading the \textit{/etc/sudoers} file.
+
+Therefore, LKMs are more powerful since they enjoy almost no restrictions in the kernel, while TripleCross' modules will always be limited to those capabilities achievable without kernel memory modifications. In terms of developing complexity, LKMs are more difficult to develop, since eBPF programs will never crash the kernel (because of the eBPF verifier), whilst developing kernel modules may incur in causing kernel panics, often because of tiny kernel differences between kernel versions, which leads to having to adjust the LKM for multiple kernels. On the other hand, although an eBPF program is guaranteed to work once in the kernel, it requires deep knowledge of which actions are accepted by the verifier, and about which are the limitations of these programs.
+
+With respect to the techniques used we can also find similarities, since both LKMs and eBPF rootkits make heavy use of hooking syscalls and kernel functions, with the only difference that the instructions that can be executed at the eBPF probe function are restricted to those allowed by the eBPF helpers, whilst LKMs may read or write any memory section. In terms of the network, both eBPF and LKMs enjoy similar capabilities, with the exception that LKMs may create their own packets, whilst eBPF may only modify or drop existing ones. Finally, both LKMs and eBPF rootkits may execute user space programs (in eBPF, by hijacking calls or triggering actions via a messaging system such as a ring buffer, and in LKMs using, for instance, the function call\_usermodehelper \cite{usermode_helper_lkm}).
+
 
-%Move here part of the rootkit section at the intro.