La siguiente tabla describe el propósito de cada Makefile en detalle:

| MAKEFILE  | COMANDO | DESCRIPCIÓN | ARCHIVOS RESULTANTES |
| ------------- | ------------- | ------------- | ------------- |
| src/client/Makefile  | make  | Compilación del cliente del rootkit | src/client/injector |
| src/Makefile  | make help  | Compilación de programas para probar las capacidades del rootkit, y el programa malicioso y la biblioteca de los módulos de secuestro de ejecución e inyección de bibliotecas, respectivamente | src/helpers/simple_timer, src/helpers/simple_open, src/helpers/simple_execve, src/helpers/lib_injection.so, src/helpers/execve_hijack |
| src/Makefile | make kit | Compilación del rootkit utilizando la biblioteca libbpf | src/bin/kit |
| src/Makefile | make tckit | Compilación del programa de salida TC del rootkit | src/bin/tc.o |

### Instalación
Una vez que los archivos del rootkit se generan en src/bin/, los programas *tc.o* y *kit* deben cargarse en orden. En el siguiente ejemplo, la puerta trasera del rootkit operará en la interfaz de red *enp0s3*:```
// TC egress program
sudo tc qdisc add dev enp0s3 clsact
sudo tc filter add dev enp0s3 egress bpf direct-action obj bin/tc.o sec classifier/egress
// Libbpf-powered rootkit
sudo ./bin/kit -t enp0s3

### Inyección de librería mediante la técnica de secuestro de GOT
La técnica incorporada en TripleCross consta de 5 etapas:

#### Localización de GOT y la dirección de retorno
El rootkit secuestra la llamada al sistema utilizando un programa tracepoint. Desde allí, localiza la dirección en la sección GOT que el stub de PLT utilizó para realizar la llamada a la función de glibc responsable de la syscall.

Para llegar a la sección GOT, el programa eBPF utiliza la dirección de retorno almacenada en la pila. Nótese que:
* El .text hace una *llamada* al .plt, por lo que *rip* se guarda como *ret* en la pila.
* El .plt hace un *salto* a glibc usando .got, por lo que no se guarda ningún otro *rip*. Tampoco modifica ni guarda el valor de *rbp*.
* Glibc hace una *syscall*, que no guarda *rip* en la pila, sino que lo guarda en *rcx*.

<img src="https://assets.kitploit.com/production/public/readmes/5614/d216fa5b7b656bb52587027db28f3e3902fa8389d0b2944a1f7e870d6d2e6bee.jpg" float="left">

Por lo tanto, para verificar desde eBPF que una dirección en la pila es la dirección de retorno que nos llevará al GOT correcto, debemos comprobar que es la dirección de retorno del stub de PLT que utiliza la dirección GOT que salta a la función de glibc que realiza la llamada al sistema que hemos secuestrado desde eBPF.

Se han incorporado dos técnicas para encontrar la dirección de retorno:
* Con sys_timerfd_settime, el programa eBPF escanea hacia adelante en la pila utilizando los argumentos de la syscall.
* Con sys_openat, el programa eBPF escanea utilizando los datos de la estructura *pt_regs* de los tracepoints para escanear la dirección de retorno.

<img src="https://assets.kitploit.com/production/public/readmes/5614/61217fb3fd84bec65cbbee906dd27860e5e1c211912cfe450ea4cf9051fa480b.png" float="left">


#### Localización de funciones clave para el shellcode
El shellcode debe generarse dinámicamente para eludir ASLR y PIE, que cambian la dirección de funciones como dlopen() en cada ejecución del programa.

<img src="https://assets.kitploit.com/production/public/readmes/5614/6cbb620495d8cb9711e499fd5b1ae9ea845c03d0c33019cf008b456a95d5ddd6.png" float="left">


#### Inyección de shellcode en un code cave
Se puede encontrar un code cave mediante ingeniería inversa de un ELF si ASLR y PIE están desactivados, pero normalmente ese no es el caso. El programa eBPF envía una solicitud a un programa rootkit en espacio de usuario que utiliza el sistema de archivos /proc para localizar y escribir en un code cave en la sección .text (ejecutable).

<img src="https://assets.kitploit.com/production/public/readmes/5614/c7daea0eed684437b5c7d971d0f69f5aac9138861d44da36c5368be9f97666d1.png" float="left">

#### Sobrescritura de la sección GOT
Dependiendo de si RELRO Parcial o Completo está activo en el ejecutable, el programa eBPF sobrescribe la sección GOT directamente o mediante el sistema de archivos /proc.

<img src="https://assets.kitploit.com/production/public/readmes/5614/7e69ec2982ee8c77c39b42f364ab25e52c40d96890f7413b3afe04dde1b825c3.png" float="left">

#### Espera de la siguiente llamada al sistema
Cuando se emite la siguiente syscall en el programa secuestrado, la sección PLT utiliza la sección GOT modificada, secuestrando el flujo de ejecución que se redirige al shellcode en el code cave. El shellcode está preparado para evitar que el programa se bloquee, y llama a la librería maliciosa (*src/helpers/lib_injection.so*). Esta librería ejecuta un fork() y genera una shell inversa con la máquina atacante. Posteriormente, se restaura el flujo de ejecución.

<img src="https://assets.kitploit.com/production/public/readmes/5614/4e780cbcba855fe11a55f6a34709d83d855a4235960b15b69470233147f04318.png" float="left">



## Backdoor y C2
El backdoor funciona de fábrica sin necesidad de configuración alguna. El backdoor puede controlarse de forma remota utilizando el programa cliente del rootkit:

| ARGUMENTOS DEL CLIENTE | DESCRIPCIÓN DE LA ACCIÓN |
| ------------- | ------------- |
| ./injector -c \<IP de la víctima\> | Genera una pseudoshell en texto plano utilizando el módulo de secuestro de ejecución |
| ./injector -e \<IP de la víctima\> | Genera una pseudoshell cifrada ordenando al backdoor con un disparador basado en patrones |
| ./injector -s \<IP de la víctima\> | Genera una pseudoshell cifrada ordenando al backdoor con un disparador multipaquete (de ambos tipos) |
| ./injector -p \<IP de la víctima\> | Genera una shell fantasma ordenando al backdoor con un disparador basado en patrones |
| ./injector -a \<IP de la víctima\> | Ordena al rootkit activar todos los programas eBPF |
| ./injector -u \<IP de la víctima\> | Ordena al rootkit desvincular todos sus programas eBPF |
| ./injector -S \<IP de la víctima\> | Muestra cómo el backdoor puede ocultar un mensaje del kernel (PoC simple) |
| ./injector -h | Muestra la ayuda |

### Disparadores del backdoor

Las acciones se envían al backdoor mediante disparadores, que indican al backdoor la acción a ejecutar según el valor del atributo **K3**:

| VALOR K3 | ACCIÓN |
| ------------- | ------------- |
| 0x1F29 | Solicitud para iniciar una conexión de pseudoshell cifrada |
| 0x4E14 | Solicitud para iniciar una conexión de shell fantasma |
| 0x1D25 | Solicitud para cargar y vincular todos los programas eBPF del rootkit |
| 0x1D24 | Solicitud para desvincular todos los programas eBPF del rootkit (excepto los del backdoor) |


#### Disparador basado en patrones
Este disparador oculta la información del comando y del cliente para que pueda ser reconocido por el backdoor, pero al mismo tiempo parece lo suficientemente aleatorio para un supervisor de red externo. Se basa en el disparador utilizado por el rootkit de la NSA descubierto recientemente [Bvp47](https://www.pangulab.cn/files/The_Bvp47_a_top-tier_backdoor_of_us_nsa_equation_group.en.pdf).

<img src="https://assets.kitploit.com/production/public/readmes/5614/58cec7ee2dbd89b6c7d71d60c006a1a98d7b9165b20bdbe006467a82d5dc30ab.png" float="left">

#### Disparador multipaquete
Este disparador consiste en múltiples paquetes TCP en los que la carga útil del backdoor está oculta en los encabezados de los paquetes. Este diseño se basa en el implante [Hive](https://wikileaks.org/vault7/document/hive-DevelopersGuide/hive-DevelopersGuide.pdf) de la CIA descrito en la filtración Vault 7. Se utiliza la siguiente carga útil:

<img src="https://assets.kitploit.com/production/public/readmes/5614/45a8348c3d366af4941d9cca845c281fc8c5a565353fc8fe3fb91350f39dd5f8.png" float="left">

Luego se calcula un XOR rodante sobre la carga útil anterior y se divide en múltiples partes, según el modo seleccionado por el cliente del rootkit. TripleCross soporta cargas útiles ocultas en el número de secuencia TCP:

<img src="https://assets.kitploit.com/production/public/readmes/5614/2b9d7fd46f7133e3eeda694e0b4791fbed2a51616b7d2f14e989a9e0e56af9e2.png" float="left">

Y en el puerto de origen TCP:

<img src="https://assets.kitploit.com/production/public/readmes/5614/1a6ea6da628a9902eaf55cc3c1549a2ecf26cba211275acdce6bc5491b34140c.png" float="left">

### Pseudoshells del backdoor
El cliente puede establecer pseudoshells del rootkit, una conexión especial de rootkit a rootkit que simula un programa de shell, permitiendo al atacante ejecutar comandos de Linux de forma remota y obtener los resultados como si los estuviera ejecutando directamente en la máquina infectada. Se incorporan múltiples pseudoshells en nuestro rootkit:

#### Pseudoshell en texto plano
Esta shell se genera tras una ejecución exitosa del módulo de secuestro de ejecución, que ejecutará un archivo malicioso que establece una conexión con el cliente del rootkit de la siguiente manera:

<img src="https://assets.kitploit.com/production/public/readmes/5614/6495b5b62c33ae136b8c965658d9c5f501e609029bde7fcefe7266966f8effbb.png" float="left">
<img src="https://assets.kitploit.com/production/public/readmes/5614/5301e208d9853760eabdc14772c57a3639f28d71d050ee82d151bff93a76cedf.png" float="right">

#### Pseudoshell cifrada
El cliente del rootkit puede solicitar una pseudoshell cifrada en cualquier momento, consistente en una conexión TLS entre el rootkit y el cliente del rootkit. Dentro de la conexión cifrada, se sigue un protocolo de transmisión para comunicar comandos e información, similar al de las pseudoshells en texto plano.

Generar una pseudoshell cifrada requiere que el backdoor escuche disparadores, que acepta tanto disparadores basados en patrones como ambos tipos de disparadores multipaquete:

<img src="https://assets.kitploit.com/production/public/readmes/5614/d4929247af8895f78522f28c4ac8087e74d76b91320c67e0b37ea841cd8869d0.png" float="left">
<img src="https://assets.kitploit.com/production/public/readmes/5614/6e2a72d04028212a4917397b75b052a4bdf3c0529fb6c5e336b7fc0a06571728.png" float="right">

#### Shell fantasma
Una shell fantasma utiliza una combinación de programas XDP y TC para superar las limitaciones de eBPF en la red, específicamente que no puede generar nuevos paquetes. Para ello, el backdoor modifica el tráfico existente, sobrescribiendo la carga útil con los datos de la transmisión C2. Los paquetes originales no se pierden ya que las retransmisiones TCP envían el paquete original (sin modificaciones) nuevamente después de un breve tiempo.

El siguiente protocolo ilustra el tráfico durante la ejecución de un comando utilizando una shell fantasma:
<img src="https://assets.kitploit.com/production/public/readmes/5614/0aafe6b672757e4e9d37402c72ce14893a8a7f198030b2f2386df631c345d16b.png" float="left">

Una shell fantasma es solicitada por el cliente del rootkit que emite un comando para ser ejecutado por el backdoor:

<img src="https://assets.kitploit.com/production/public/readmes/5614/e07dec48ff6a22e708b6d4b0d762473cc6483f065011cd6cdccdac49f12f916b.png" float="left">

Después de que la máquina infectada envíe cualquier paquete TCP, el backdoor lo sobrescribe y el cliente muestra la respuesta:

<img src="https://assets.kitploit.com/production/public/readmes/5614/19bea585b78a0bb1d52aa7c63ff05a0111551a0cc767732775491641e1dec021.png" float="left">


## Módulo de secuestro de ejecución
En principio, un programa eBPF no puede iniciar la ejecución de un programa por sí mismo. Este módulo muestra cómo un rootkit malicioso puede aprovechar programas benignos para ejecutar código malicioso en el espacio de usuario. Este módulo logra dos objetivos:
* Ejecutar un programa de usuario malicioso aprovechando la ejecución de otro programa.
* Ser transparente para el espacio de usuario, es decir, si secuestramos la ejecución de un programa para que se ejecute otro, el programa original también debe ejecutarse con la menor demora posible.

Este módulo funciona secuestrando la llamada al sistema sys_execve(), modificando sus argumentos para que se ejecute un programa malicioso (*src/helpers/execve_hijack.c*) en su lugar. Esta modificación se realiza de tal manera que el programa malicioso pueda luego ejecutar el programa original con los argumentos originales para no generar sospechas en el espacio de usuario. El siguiente diagrama resume la funcionalidad general:

<img src="https://assets.kitploit.com/production/public/readmes/5614/601610696506e303f91a7957ec2a3d61f73f7d0e036430a9f67bd80a6f19b2d3.png" float="left">

Los argumentos de la llamada original a sys_execve() se modifican de tal manera que los argumentos originales no se pierden (usando argv[0]) para que el programa original pueda ejecutarse después del malicioso:

<img src="https://assets.kitploit.com/production/public/readmes/5614/e483317a3bdac422cdfc49ca92acdcefe624ddceb5b2ed036ccec141c8d1e5e6.png" float="left">

Hemos incorporado un programa de prueba de ejemplo (*src/helpers/simple_execve.c*) para probar el módulo de secuestro de ejecución. El módulo también puede secuestrar cualquier llamada en el sistema, según la configuración:

| NOMBRE DE ARCHIVO | CONSTANTE | DESCRIPCIÓN |
| ------------- | ------------- | ------------- |
| src/common/constants.h | PATH_EXECUTION_HIJACK_PROGRAM | Ubicación del programa malicioso a ejecutar al secuestrar una llamada sys_execve con éxito |
| src/common/constants.h | EXEC_HIJACK_ACTIVE | Desactivar (0) o activar (1) el módulo de secuestro de ejecución |
| src/common/constants.h | TASK_COMM_RESTRICT_HIJACK_ACTIVE | Secuestrar cualquier llamada sys_execve (0) o solo aquellas indicadas en TASK_COMM_NAME_RESTRICT_HIJACK (1) |
| src/common/constants.h | TASK_COMM_NAME_RESTRICT_HIJACK | Nombre del programa desde el cual secuestrar las llamadas sys_execve |

Después de un secuestro exitoso, el módulo se detendrá a sí mismo. El programa malicioso *execve_hijack* escuchará solicitudes de una pseudoshell en texto plano desde el cliente del rootkit.

## Persistencia del rootkit
Después de que la máquina infectada se reinicia, todos los programas eBPF se descargarán del kernel y el programa rootkit en espacio de usuario será finalizado. Además, incluso si el rootkit pudiera ejecutarse automáticamente de nuevo, ya no disfrutaría de los privilegios de root necesarios para vincular nuevamente los programas eBPF. El módulo de persistencia del rootkit tiene como objetivo abordar estos dos desafíos:
* Ejecutar el rootkit automáticamente y sin interacción del usuario después de un reinicio de la máquina.
* Una vez que el rootkit ha adquirido privilegios de root la primera vez que se ejecuta en la máquina, debe mantenerlos incluso después de un reinicio.

TripleCross utiliza dos archivos secretos, creados bajo *cron.d* y *sudoers.d*, para implementar esta funcionalidad. Estas entradas aseguran que el rootkit se cargue automáticamente y con privilegios completos después de un reinicio. Estos archivos se crean y gestionan mediante el script *deployer&#46;sh*:

<img src="https://assets.kitploit.com/production/public/readmes/5614/88500b779b9ad5ba771803900a8abfffd08f3a6be59518e690534779a4134cf8.png" float="left">
<img src="https://assets.kitploit.com/production/public/readmes/5614/5ae61ed98af6d7c8aa9448fed3de553712ffb5c63e95d98a6f4300ff407bce23.png" float="right">

El script contiene dos constantes que deben configurarse para el usuario a infectar en el sistema objetivo:

| SCRIPT | CONSTANTE | DESCRIPCIÓN |
| ------------- | ------------- | ------------- |
| src/helpers/deployer.sh | CRON_PERSIST | Tarea de cron a ejecutar después del reinicio |
| src/helpers/deployer.sh | SUDO_PERSIST | Entrada de sudo para otorgar privilegios sin contraseña |

## Sigilo del rootkit
El módulo de persistencia se basa en crear archivos adicionales, pero eventualmente podrían ser encontrados por el propietario del sistema o por alguna herramienta de software, por lo que existe un riesgo al dejarlos en el sistema. Además, los archivos del rootkit deberán almacenarse en alguna ubicación, donde podrían ser descubiertos.

Teniendo en cuenta lo anterior, el módulo de sigilo proporciona la siguiente funcionalidad:
* Ocultar un directorio completamente del usuario (para que podamos ocultar todos los archivos del rootkit dentro).
* Ocultar archivos específicos en un directorio (necesitamos ocultar los archivos de persistencia, pero no podemos ocultar los directorios *sudoers.d* o *cron.d* por completo, ya que pertenecen al funcionamiento normal del sistema).

Los archivos y directorios ocultados por el rootkit se pueden personalizar mediante las siguientes constantes de configuración:

| NOMBRE DE ARCHIVO | CONSTANTE | DESCRIPCIÓN |
| ------------- | ------------- | ------------- |
| src/common/constants.h | SECRET_DIRECTORY_NAME_HIDE | Nombre del directorio a ocultar |
| src/common/constants.h | SECRET_FILE_PERSISTENCE_NAME | Nombre del archivo a ocultar |

Por defecto, TripleCross ocultará cualquier archivo llamado "*ebpfbackdoor*" y un directorio llamado "*SECRETDIR*". Este módulo se activa automáticamente después de la instalación del rootkit.

La técnica utilizada para lograr esta funcionalidad consiste en manipular los argumentos de la llamada al sistema sys_getdents():

<img src="https://assets.kitploit.com/production/public/readmes/5614/7f928351c1c07e7b6a534846c5374788449e03455191cddf8c7f02af2c885852.png" float="left">



## Licencia
El rootkit TripleCross y el cliente del rootkit están licenciados bajo la licencia GPLv3. Consulte [LICENSE](https://github.com/h3xduck/TripleCross/blob/master/LICENSE).

La biblioteca [RawTCP_Lib](https://github.com/h3xduck/RawTCP_Lib) está licenciada bajo la licencia MIT.

El documento de tesis original y las figuras incluidas se publican bajo [Creative Commons BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/).