Le tableau suivant décrit en détail l'objectif de chaque Makefile :

| MAKEFILE  | COMMANDE | DESCRIPTION | FICHIERS RÉSULTANTS |
| ------------- | ------------- | ------------- | ------------- |
| src/client/Makefile  | make  | Compilation du client du rootkit | src/client/injector |
| src/Makefile  | make help  | Compilation des programmes de test des capacités du rootkit, ainsi que du programme malveillant et de la bibliothèque des modules de détournement d'exécution et d'injection de bibliothèque, respectivement | 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 | Compilation du rootkit à l'aide de la bibliothèque libbpf | src/bin/kit |
| src/Makefile | make tckit | Compilation du programme de sortie TC du rootkit | src/bin/tc.o |

### Installation
Une fois les fichiers du rootkit générés dans src/bin/, les programmes *tc.o* et *kit* doivent être chargés dans l'ordre. Dans l'exemple suivant, la porte dérobée du rootkit fonctionnera sur l'interface réseau *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

### Injection de bibliothèque via la technique de détournement de GOT
La technique intégrée dans TripleCross comprend 5 étapes :

#### Localisation de la GOT et de l'adresse de retour
Le rootkit intercepte l'appel système à l'aide d'un programme tracepoint. De là, il localise l'adresse dans la section GOT que le stub PLT a utilisée pour effectuer l'appel à la fonction glibc responsable de l'appel système.

Afin d'atteindre la section GOT, le programme eBPF utilise l'adresse de retour stockée dans la pile. Notez que :
* Le .text effectue un *call* vers le .plt, donc *rip* est sauvegardé en tant que *ret* dans la pile.
* Le .plt effectue un *jump* vers glibc en utilisant .got, donc aucun autre *rip* n'est sauvegardé. Il ne modifie ni ne sauvegarde non plus la valeur de *rbp*.
* Glibc effectue un *syscall*, qui ne sauvegarde pas *rip* dans la pile, mais le sauvegarde plutôt dans *rcx*.

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

Par conséquent, pour vérifier depuis eBPF qu'une adresse dans la pile est l'adresse de retour qui nous mènera à la GOT correcte, nous devons vérifier qu'il s'agit de l'adresse de retour du stub PLT qui utilise l'adresse GOT qui saute vers la fonction glibc effectuant l'appel système que nous avons intercepté depuis eBPF.

Deux techniques pour trouver l'adresse de retour ont été intégrées :
* Avec sys_timerfd_settime, le programme eBPF analyse en avant en utilisant les arguments de l'appel système.
* Avec sys_openat, le programme eBPF utilise les données de la structure *pt_regs* des tracepoints pour analyser l'adresse de retour.

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


#### Localisation des fonctions clés pour le shellcode
Le shellcode doit être généré dynamiquement pour contourner ASLR et PIE, qui modifient l'adresse de fonctions telles que dlopen() à chaque exécution de programme.

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


#### Injection de shellcode dans une code cave
Une code cave peut être trouvée en rétro-ingénierie d'un ELF si ASLR et PIE sont désactivés, mais ce n'est généralement pas le cas. Le programme eBPF envoie une requête à un programme rootkit de l'espace utilisateur qui utilise le système de fichiers /proc pour localiser et écrire dans une code cave dans la section .text (exécutable).

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

#### Réécriture de la section GOT
Selon que RELRO partiel ou complet est actif sur l'exécutable, le programme eBPF réécrit la section GOT directement ou via le système de fichiers /proc.

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

#### Attente du prochain appel système
Lorsque le prochain appel système est émis dans le programme détourné, la section PLT utilise la section GOT modifiée, détournant le flux d'exécution qui est redirigé vers le shellcode dans la code cave. Le shellcode est préparé pour empêcher le programme de planter, et appelle la bibliothèque malveillante (*src/helpers/lib_injection.so*). Cette bibliothèque effectue un fork() et génère un shell inverse avec la machine de l'attaquant. Ensuite, le flux d'exécution est restauré.

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



## Backdoor et C2
La backdoor fonctionne immédiatement sans aucune configuration nécessaire. La backdoor peut être contrôlée à distance à l'aide du programme client du rootkit :

| ARGUMENTS DU CLIENT | DESCRIPTION DE L'ACTION |
| ------------- | ------------- |
| ./injector -c \<Victim IP\> | Génère un pseudo-shell en texte clair en utilisant le module de détournement d'exécution |
| ./injector -e \<Victim IP\> | Génère un pseudo-shell chiffré en commandant la backdoor avec un déclencheur basé sur un motif |
./injector -s \<Victim IP\> | Génère un pseudo-shell chiffré en commandant la backdoor avec un déclencheur multi-paquets (des deux types) |
./injector -p \<Victim IP\> | Génère un shell fantôme en commandant la backdoor avec un déclencheur basé sur un motif |
./injector -a \<Victim IP\> | Ordonne au rootkit d'activer tous les programmes eBPF |
./injector -u \<Victim IP\> | Ordonne au rootkit de détacher tous ses programmes eBPF |
./injector -S \<Victim IP\> | Montre comment la backdoor peut cacher un message du noyau (PoC simple) |
| ./injector -h | Affiche l'aide |

### Déclencheurs de la backdoor

Les actions sont envoyées à la backdoor à l'aide de déclencheurs, qui indiquent à la backdoor l'action à exécuter en fonction de la valeur de l'attribut **K3** :

| VALEUR K3 | ACTION |
| ------------- | ------------- |
| 0x1F29 | Demande de démarrer une connexion pseudo-shell chiffrée |
| 0x4E14 | Demande de démarrer une connexion shell fantôme |
| 0x1D25 | Demande de charger et d'attacher tous les programmes eBPF du rootkit |
| 0x1D24 | Demande de détacher tous les programmes eBPF du rootkit (sauf ceux de la backdoor) |


#### Déclencheur basé sur un motif
Ce déclencheur cache la commande et les informations du client afin qu'il puisse être reconnu par la backdoor, mais semble en même temps suffisamment aléatoire pour un superviseur de réseau externe. Il est basé sur le déclencheur utilisé par le rootkit de la NSA récemment découvert [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">

#### Déclencheur multi-paquets
Ce déclencheur consiste en plusieurs paquets TCP sur lesquels la charge utile de la backdoor est cachée dans les en-têtes de paquets. Cette conception est basée sur l'implant [Hive](https://wikileaks.org/vault7/document/hive-DevelopersGuide/hive-DevelopersGuide.pdf) de la CIA décrit dans la fuite Vault 7. La charge utile suivante est utilisée :

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

Un XOR glissant est ensuite calculé sur la charge utile ci-dessus et elle est divisée en plusieurs parties, selon le mode sélectionné par le client rootkit. TripleCross prend en charge les charges utiles cachées sur le numéro de séquence TCP :

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

Et sur le port source TCP :

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

### Pseudo-shells de la backdoor
Le client peut établir des pseudo-shells de rootkit, une connexion client rootkit-à-rootkit spéciale qui simule un programme shell, permettant à l'attaquant d'exécuter des commandes Linux à distance et d'obtenir les résultats comme s'il les exécutait directement sur la machine infectée. Plusieurs pseudo-shells sont intégrés dans notre rootkit :

#### Pseudo-shell en texte clair
Ce shell est généré après une exécution réussie du module de détournement d'exécution, qui exécutera un fichier malveillant établissant une connexion avec le client rootkit comme suit :

<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">

#### Pseudo-shell chiffré
Un pseudo-shell chiffré peut être demandé par le client rootkit à tout moment, consistant en une connexion TLS entre le rootkit et le client rootkit. À l'intérieur de la connexion chiffrée, un protocole de transmission est suivi pour communiquer les commandes et les informations, similaire à celui des pseudo-shells en texte clair.

La création d'un pseudo-shell chiffré nécessite que la backdoor écoute les déclencheurs, qui accepte soit les déclencheurs basés sur un motif, soit les deux types de déclencheur multi-paquets :

<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 fantôme
Un shell fantôme utilise une combinaison de programmes XDP et TC pour surmonter les limitations eBPF au niveau du réseau, notamment le fait qu'il ne peut pas générer de nouveaux paquets. Pour cela, la backdoor modifie le trafic existant, en écrasant la charge utile avec les données de la transmission C2. Les paquets originaux ne sont pas perdus car les retransmissions TCP renvoient le paquet original (sans modifications) après un court laps de temps.

Le protocole suivant illustre le trafic lors de l'exécution d'une commande à l'aide d'un shell fantôme :
<img src="https://assets.kitploit.com/production/public/readmes/5614/0aafe6b672757e4e9d37402c72ce14893a8a7f198030b2f2386df631c345d16b.png" float="left">

Un shell fantôme est demandé par le client rootkit qui émet une commande à exécuter par la backdoor :

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

Après que la machine infectée envoie un paquet TCP quelconque, la backdoor le réécrit et le client affiche la réponse :

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


## Module de détournement d'exécution
En principe, un programme eBPF ne peut pas démarrer l'exécution d'un programme par lui-même. Ce module montre comment un rootkit malveillant peut tirer parti de programmes bénins afin d'exécuter du code malveillant dans l'espace utilisateur. Ce module atteint deux objectifs :
* Exécuter un programme utilisateur malveillant en tirant parti de l'exécution d'un autre programme.
* Être transparent pour l'espace utilisateur, c'est-à-dire que si nous détournons l'exécution d'un programme pour en exécuter un autre, le programme original doit également être exécuté avec le moins de retard possible.

Ce module fonctionne en détournant l'appel système sys_execve(), en modifiant ses arguments pour qu'un programme malveillant (*src/helpers/execve_hijack.c*) soit exécuté à la place. Cette modification est faite de telle sorte que le programme malveillant puisse ensuite exécuter le programme original avec les arguments originaux pour éviter d'éveiller les soupçons dans l'espace utilisateur. Le diagramme suivant résume la fonctionnalité globale :

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

Les arguments de l'appel sys_execve() original sont modifiés de manière à ce que les arguments originaux ne soient pas perdus (en utilisant argv[0]) afin que le programme original puisse être exécuté après le programme malveillant :

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

Nous avons intégré un programme de test exemple (*src/helpers/simple_execve.c*) pour tester le module de détournement d'exécution. Le module peut également détourner n'importe quel appel dans le système, selon la configuration :

| NOM DE FICHIER | CONSTANTE | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/common/constants.h | PATH_EXECUTION_HIJACK_PROGRAM | Emplacement du programme malveillant à exécuter après une réussite d'un appel sys_execve |
| src/common/constants.h | EXEC_HIJACK_ACTIVE | Désactiver (0) ou activer (1) le module de détournement d'exécution |
| src/common/constants.h | TASK_COMM_RESTRICT_HIJACK_ACTIVE | Détourner tout appel sys_execve (0) ou seulement ceux indiqués dans TASK_COMM_NAME_RESTRICT_HIJACK (1) |
| src/common/constants.h | TASK_COMM_NAME_RESTRICT_HIJACK | Nom du programme à partir duquel détourner les appels sys_execve |

Après un détournement réussi, le module s'arrêtera automatiquement. Le programme malveillant *execve_hijack* écoutera les demandes d'un pseudo-shell en texte clair de la part du client rootkit.

## Persistance du rootkit
Après le redémarrage de la machine infectée, tous les programmes eBPF seront déchargés du noyau et le programme rootkit de l'espace utilisateur sera tué. De plus, même si le rootkit pouvait être exécuté à nouveau automatiquement, il ne bénéficierait plus des privilèges root nécessaires pour attacher à nouveau les programmes eBPF. Le module de persistance du rootkit vise à relever ces deux défis :
* Exécuter le rootkit automatiquement et sans interaction de l'utilisateur après un redémarrage de la machine.
* Une fois que le rootkit a acquis les privilèges root la première fois qu'il est exécuté sur la machine, il doit les conserver même après un redémarrage.

TripleCross utilise deux fichiers secrets, créés sous *cron.d* et *sudoers.d*, pour implémenter cette fonctionnalité. Ces entrées garantissent que le rootkit est chargé automatiquement et avec tous les privilèges après un redémarrage. Ces fichiers sont créés et gérés par le 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">

Le script contient deux constantes qui doivent être configurées pour l'utilisateur à infecter sur le système cible :

| SCRIPT | CONSTANTE | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/helpers/deployer.sh | CRON_PERSIST | Tâche cron à exécuter après le redémarrage |
| src/helpers/deployer.sh | SUDO_PERSIST | Entrée sudo pour accorder des privilèges sans mot de passe |

## Furtivité du rootkit
Le module de persistance repose sur la création de fichiers supplémentaires, mais ils peuvent éventuellement être découverts par le propriétaire du système ou par un outil logiciel, donc il existe un risque à les laisser dans le système. De plus, les fichiers du rootkit devront être stockés à un endroit, où ils pourraient être découverts.

Compte tenu de ce qui précède, le module de furtivité offre les fonctionnalités suivantes :
* Cacher complètement un répertoire à l'utilisateur (afin de pouvoir y cacher tous les fichiers du rootkit).
* Cacher des fichiers spécifiques dans un répertoire (nous devons cacher les fichiers de persistance, mais nous ne pouvons pas cacher complètement les répertoires *sudoers.d* ou *cron.d*, car ils appartiennent au fonctionnement normal du système).

Les fichiers et répertoires cachés par le rootkit peuvent être personnalisés par les constantes de configuration suivantes :

| NOM DE FICHIER | CONSTANTE | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/common/constants.h | SECRET_DIRECTORY_NAME_HIDE | Nom du répertoire à cacher |
| src/common/constants.h | SECRET_FILE_PERSISTENCE_NAME | Nom du fichier à cacher |

Par défaut, TripleCross cachera tous les fichiers appelés "*ebpfbackdoor*" et un répertoire nommé "*SECRETDIR*". Ce module est activé automatiquement après l'installation du rootkit.

La technique utilisée pour réaliser cette fonctionnalité consiste à altérer les arguments de l'appel système sys_getdents() :

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



## Licence
Le rootkit TripleCross et le client rootkit sont sous licence GPLv3. Voir [LICENSE](https://github.com/h3xduck/TripleCross/blob/master/LICENSE).

La bibliothèque [RawTCP_Lib](https://github.com/h3xduck/RawTCP_Lib) est sous licence MIT.

Le document de thèse original et les figures incluses sont publiés sous [Creative Commons BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/).