The following table describes the purpose of each Makefile in detail:

| MAKEFILE  | BEFEHL | BESCHREIBUNG | ERZEUGTE DATEIEN |
| ------------- | ------------- | ------------- | ------------- |
| src/client/Makefile  | make  | Kompilierung des Rootkit-Clients | src/client/injector |
| src/Makefile  | make help  | Kompilierung von Programmen zum Testen der Rootkit-Funktionen sowie das bösartige Programm und die Bibliothek der Module für Ausführungshijacking und Bibliotheksinjektion | 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 | Kompilierung des Rootkits unter Verwendung der libbpf-Bibliothek | src/bin/kit |
| src/Makefile | make tckit | Kompilierung des TC-Egress-Programms des Rootkits | src/bin/tc.o |

### Installation
Sobald die Rootkit-Dateien unter src/bin/ generiert wurden, müssen die Programme *tc.o* und *kit* der Reihe nach geladen werden. Im folgenden Beispiel wird die Rootkit-Hintertür auf der Netzwerkschnittstelle *enp0s3* operieren:```
// 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

### Bibliotheksinjektion mittels GOT-Hijacking-Technik
Die in TripleCross integrierte Technik besteht aus 5 Stufen:

#### Lokalisieren der GOT und der Rücksprungadresse
Das Rootkit hookt den Systemaufruf mithilfe eines Tracepoint-Programms. Von dort aus lokalisiert es die Adresse im GOT-Abschnitt, die der PLT-Stub verwendet hat, um den Aufruf an die für den Syscall zuständige glibc-Funktion zu tätigen. 

Um zum GOT-Abschnitt zu gelangen, verwendet das eBPF-Programm die auf dem Stack gespeicherte Rücksprungadresse. Beachten Sie:
* Der .text führt einen *call* zum .plt aus, daher wird *rip* als *ret* auf dem Stack gespeichert.
* Der .plt führt einen *jump* zu glibc über .got aus, daher wird kein weiteres *rip* gespeichert. Es modifiziert oder speichert auch nicht den Wert von *rbp*.
* glibc führt einen *syscall* aus, der *rip* nicht im Stack, sondern in *rcx* speichert. 

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

Um also von eBPF aus zu überprüfen, ob eine Adresse im Stack die Rücksprungadresse ist, die uns zum korrekten GOT führt, müssen wir prüfen, dass es sich um die Rücksprungadresse des PLT-Stubs handelt, der die GOT-Adresse verwendet, die zu der glibc-Funktion springt, die den von uns aus eBPF gehookten Systemaufruf ausführt.

Zwei Techniken zum Auffinden der Rücksprungadresse wurden integriert:
* Mit sys_timerfd_settime durchsucht das eBPF-Programm vorwärts im Scan unter Verwendung der Syscall-Argumente.
* Mit sys_openat verwendet das eBPF-Programm die Daten in der *pt_regs*-Struktur der Tracepoints, um die Rücksprungadresse zu scannen.

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


#### Lokalisieren der Schlüsselfunktionen für den Shellcode
Der Shellcode muss dynamisch generiert werden, um ASLR und PIE zu umgehen, die die Adresse von Funktionen wie dlopen() bei jeder Programmausführung ändern.

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


#### Injizieren von Shellcode in eine Code Cave
Eine Code Cave kann durch Reverse Engineering einer ELF-Datei gefunden werden, wenn ASLR und PIE deaktiviert sind, aber normalerweise ist das nicht der Fall. Das eBPF-Programm sendet eine Anfrage an ein Userspace-Rootkit-Programm, das das /proc-Dateisystem verwendet, um eine Code Cave im .text (ausführbaren) Abschnitt zu lokalisieren und zu beschreiben.

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

#### Überschreiben des GOT-Abschnitts
Abhängig davon, ob Partial oder Full RELRO auf der ausführbaren Datei aktiv sind, überschreibt das eBPF-Programm den GOT-Abschnitt direkt oder mit dem /proc-Dateisystem.

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

#### Warten auf den nächsten Systemaufruf
Wenn der nächste Syscall im gekaperten Programm ausgeführt wird, verwendet der PLT-Abschnitt den modifizierten GOT-Abschnitt, kapert den Ausführungsfluss und leitet ihn zum Shellcode in der Code Cave um. Der Shellcode ist darauf vorbereitet, das Programm vor einem Absturz zu bewahren, und ruft die schädliche Bibliothek (*src/helpers/lib_injection.so*) auf. Diese Bibliothek führt einen fork() aus und startet eine Reverse Shell mit dem Angreifer-Rechner. Danach wird der Ausführungsfluss wiederhergestellt.

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



## Backdoor und C2
Die Backdoor funktioniert sofort ohne erforderliche Konfiguration. Die Backdoor kann mit dem Rootkit-Client-Programm ferngesteuert werden:

| CLIENT-ARGUMENTE | AKTIONSBESCHREIBUNG |
| ------------- | ------------- |
| ./injector -c \<Opfer-IP\> | Startet eine Klartext-Pseudo-Shell durch Verwendung des Ausführungshijacking-Moduls |
| ./injector -e \<Opfer-IP\> | Startet eine verschlüsselte Pseudo-Shell durch Befehlen der Backdoor mit einem muster-basierten Trigger |
./injector -s \<Opfer-IP\> | Startet eine verschlüsselte Pseudo-Shell durch Befehlen der Backdoor mit einem Multi-Packet-Trigger (beider Typen) |
./injector -p \<Opfer-IP\> | Startet eine Phantom-Shell durch Befehlen der Backdoor mit einem muster-basierten Trigger |
./injector -a \<Opfer-IP\> | Befiehlt dem Rootkit, alle eBPF-Programme zu aktivieren |
./injector -u \<Opfer-IP\> | Befiehlt dem Rootkit, alle seine eBPF-Programme zu trennen |
./injector -S \<Opfer-IP\> | Zeigt, wie die Backdoor eine Nachricht vor dem Kernel verstecken kann (Einfacher PoC) |
| ./injector -h | Zeigt Hilfe an |

### Backdoor-Trigger

Aktionen werden an die Backdoor mittels Backdoor-Triggern gesendet, die der Backdoor die auszuführende Aktion abhängig vom Wert des Attributs **K3** anzeigen:

| K3-WERT | AKTION |
| ------------- | ------------- |
| 0x1F29 | Anforderung zum Starten einer verschlüsselten Pseudo-Shell-Verbindung |
| 0x4E14 | Anforderung zum Starten einer Phantom-Shell-Verbindung |
| 0x1D25 | Anforderung zum Laden und Anhängen aller Rootkit-eBPF-Programme |
| 0x1D24 | Anforderung zum Trennen aller Rootkit-eBPF-Programme (außer denen der Backdoor) |


#### Muster-basierter Trigger
Dieser Trigger verbirgt den Befehl und die Client-Informationen, sodass sie von der Backdoor erkannt werden können, aber gleichzeitig für einen externen Netzwerk-Supervisor zufällig genug erscheinen. Er basiert auf dem Trigger, der von dem kürzlich entdeckten NSA-Rootkit [Bvp47](https://www.pangulab.cn/files/The_Bvp47_a_top-tier_backdoor_of_us_nsa_equation_group.en.pdf) verwendet wird.

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

#### Multi-Packet-Trigger
Dieser Trigger besteht aus mehreren TCP-Paketen, bei denen die Backdoor-Nutzlast in den Paket-Headern versteckt ist. Dieses Design basiert auf dem CIA-Implant [Hive](https://wikileaks.org/vault7/document/hive-DevelopersGuide/hive-DevelopersGuide.pdf), das im Vault-7-Leak beschrieben wurde. Die folgende Nutzlast wird verwendet:

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

Über die obige Nutzlast wird dann ein rollierendes XOR berechnet und je nach dem vom Rootkit-Client gewählten Modus in mehrere Teile aufgeteilt. TripleCross unterstützt Nutzlasten, die in der TCP-Sequenznummer versteckt sind:

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

Und im TCP-Quellport:

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

### Backdoor-Pseudo-Shells
Der Client kann Rootkit-Pseudo-Shells einrichten, eine spezielle Rootkit-zu-Rootkit-Client-Verbindung, die ein Shell-Programm simuliert und es dem Angreifer ermöglicht, Linux-Befehle remote auszuführen und die Ergebnisse zu erhalten, als würde er sie direkt auf der infizierten Maschine ausführen. In unserem Rootkit sind mehrere Pseudo-Shells integriert:

#### Klartext-Pseudo-Shell
Diese Shell wird nach einem erfolgreichen Lauf des Ausführungshijacking-Moduls erzeugt, das eine schädliche Datei ausführt, die wie folgt eine Verbindung mit dem Rootkit-Client herstellt:

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

#### Verschlüsselte Pseudo-Shell
Eine verschlüsselte Pseudo-Shell kann jederzeit vom Rootkit-Client angefordert werden und besteht aus einer TLS-Verbindung zwischen dem Rootkit und dem Rootkit-Client. Innerhalb der verschlüsselten Verbindung wird ein Übertragungsprotokoll zur Kommunikation von Befehlen und Informationen befolgt, ähnlich wie bei Klartext-Pseudo-Shells.

Das Starten einer verschlüsselten Pseudo-Shell erfordert, dass die Backdoor auf Trigger lauscht, die entweder muster-basierte Trigger oder beide Arten von Multi-Packet-Triggern akzeptiert:

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

#### Phantom-Shell
Eine Phantom-Shell verwendet eine Kombination von XDP- und TC-Programmen, um eBPF-Einschränkungen im Netzwerk zu überwinden, insbesondere dass es keine neuen Pakete generieren kann. Dazu modifiziert die Backdoor vorhandenen Datenverkehr, indem sie die Nutzlast mit den Daten der C2-Übertragung überschreibt. Die ursprünglichen Pakete gehen nicht verloren, da TCP-Retransmissionen das ursprüngliche Paket (ohne Änderungen) nach kurzer Zeit erneut senden.

Das folgende Protokoll veranschaulicht den Datenverkehr während der Ausführung eines Befehls mit einer Phantom-Shell:
<img src="https://assets.kitploit.com/production/public/readmes/5614/0aafe6b672757e4e9d37402c72ce14893a8a7f198030b2f2386df631c345d16b.png" float="left">

Eine Phantom-Shell wird vom Rootkit-Client angefordert, der einen von der Backdoor auszuführenden Befehl ausgibt:

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

Nachdem die infizierte Maschine ein beliebiges TCP-Paket sendet, überschreibt die Backdoor es und der Client zeigt die Antwort an:

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


## Ausführungshijacking-Modul
Grundsätzlich kann ein eBPF-Programm nicht selbst die Ausführung eines Programms starten. Dieses Modul zeigt, wie ein bösartiges Rootkit harmlose Programme ausnutzen kann, um im Userspace bösartigen Code auszuführen. Dieses Modul erreicht zwei Ziele:
* Ausführen eines bösartigen Benutzerprogramms unter Ausnutzung der Ausführung eines anderen Programms.
* Für den Userspace transparent sein, d.h., wenn wir die Ausführung eines Programms so kapern, dass ein anderes ausgeführt wird, sollte das ursprüngliche Programm ebenfalls mit möglichst geringer Verzögerung ausgeführt werden.

Dieses Modul funktioniert, indem es den Syscall sys_execve() kapert und seine Argumente so modifiziert, dass stattdessen ein bösartiges Programm (*src/helpers/execve_hijack.c*) ausgeführt wird. Diese Modifikation wird so vorgenommen, dass das bösartige Programm dann das ursprüngliche Programm mit den ursprünglichen Argumenten ausführen kann, um im Userspace keinen Verdacht zu erregen. Das folgende Diagramm fasst die Gesamtfunktionalität zusammen:

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

Die Argumente des ursprünglichen sys_execve()-Aufrufs werden so modifiziert, dass die ursprünglichen Argumente nicht verloren gehen (unter Verwendung von argv[0]), sodass das ursprüngliche Programm nach dem bösartigen ausgeführt werden kann:

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

Wir haben ein Beispieltestprogramm (*src/helpers/simple_execve.c*) zum Testen des Ausführungshijacking-Moduls integriert. Das Modul kann je nach Konfiguration auch jeden Aufruf im System kapern:

| DATEINAME | KONSTANTE | BESCHREIBUNG |
| ------------- | ------------- | ------------- |
| src/common/constants.h | PATH_EXECUTION_HIJACK_PROGRAM | Speicherort des bösartigen Programms, das bei erfolgreicher Ausführung eines sys_execve-Aufrufs ausgeführt werden soll |
| src/common/constants.h | EXEC_HIJACK_ACTIVE | Deaktivieren (0) oder Aktivieren (1) des Ausführungshijacking-Moduls |
| src/common/constants.h | TASK_COMM_RESTRICT_HIJACK_ACTIVE | Jeden sys_execve-Aufruf kapern (0) oder nur die in TASK_COMM_NAME_RESTRICT_HIJACK angegebenen (1) |
| src/common/constants.h | TASK_COMM_NAME_RESTRICT_HIJACK | Name des Programms, von dem aus sys_execve-Aufrufe gekapert werden sollen |

Nach einem erfolgreichen Hijack stoppt sich das Modul selbst. Das bösartige Programm *execve_hijack* lauscht auf Anfragen einer Klartext-Pseudo-Shell vom Rootkit-Client.

## Rootkit-Persistenz
Nach einem Neustart der infizierten Maschine werden alle eBPF-Programme aus dem Kernel entladen und das Userspace-Rootkit-Programm wird beendet. Selbst wenn das Rootkit automatisch erneut gestartet werden könnte, würde es nicht mehr über die Root-Rechte verfügen, die zum erneuten Anhängen der eBPF-Programme erforderlich sind. Das Rootkit-Persistenzmodul zielt darauf ab, diese beiden Herausforderungen zu bewältigen:
* Das Rootkit nach einem Neustart der Maschine automatisch und ohne Benutzereingriff ausführen.
* Sobald das Rootkit beim ersten Ausführen auf der Maschine Root-Rechte erlangt hat, muss es diese auch nach einem Neustart behalten.

TripleCross verwendet zwei geheime Dateien, die unter *cron.d* und *sudoers.d* erstellt werden, um diese Funktionalität zu implementieren. Diese Einträge stellen sicher, dass das Rootkit nach einem Neustart automatisch und mit vollen Rechten geladen wird. Diese Dateien werden vom Skript *deployer&#46;sh* erstellt und verwaltet:

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

Das Skript enthält zwei Konstanten, die für den zu infizierenden Benutzer auf dem Zielsystem konfiguriert werden müssen:

| SKRIPT | KONSTANTE | BESCHREIBUNG |
| ------------- | ------------- | ------------- |
| src/helpers/deployer.sh | CRON_PERSIST | Cron-Job zur Ausführung nach dem Neustart |
| src/helpers/deployer.sh | SUDO_PERSIST | Sudo-Eintrag zur Gewährung von passwortlosen Rechten |

## Rootkit-Tarnung
Das Persistenzmodul basiert auf dem Erstellen zusätzlicher Dateien, diese könnten jedoch irgendwann vom Systembesitzer oder von einem Software-Tool gefunden werden, sodass ein Risiko besteht, sie im System zu belassen. Zusätzlich müssen die Rootkit-Dateien an einem Ort gespeichert werden, an dem sie entdeckt werden könnten.

Unter Berücksichtigung des oben Gesagten bietet das Tarnungsmodul die folgende Funktionalität:
* Ein Verzeichnis vollständig vor dem Benutzer verstecken (damit wir alle Rootkit-Dateien darin verstecken können).
* Bestimmte Dateien in einem Verzeichnis verstecken (wir müssen die Persistenzdateien verstecken, können aber die Verzeichnisse *sudoers.d* oder *cron.d* nicht vollständig verstecken, da sie zum normalen Systembetrieb gehören).

Die vom Rootkit versteckten Dateien und Verzeichnisse können durch die folgenden Konfigurationskonstanten angepasst werden:

| DATEINAME | KONSTANTE | BESCHREIBUNG |
| ------------- | ------------- | ------------- |
| src/common/constants.h | SECRET_DIRECTORY_NAME_HIDE | Name des zu versteckenden Verzeichnisses |
| src/common/constants.h | SECRET_FILE_PERSISTENCE_NAME | Name der zu versteckenden Datei |

Standardmäßig versteckt TripleCross alle Dateien namens "*ebpfbackdoor*" und ein Verzeichnis namens "*SECRETDIR*". Dieses Modul wird automatisch nach der Rootkit-Installation aktiviert.

Die zur Erreichung dieser Funktionalität verwendete Technik besteht im Manipulieren der Argumente des Systemaufrufs sys_getdents():

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



## Lizenz
Das TripleCross-Rootkit und der Rootkit-Client sind unter der GPLv3-Lizenz lizenziert. Siehe [LICENSE](https://github.com/h3xduck/TripleCross/blob/master/LICENSE).

Die Bibliothek [RawTCP_Lib](https://github.com/h3xduck/RawTCP_Lib) ist unter der MIT-Lizenz lizenziert.

Das ursprüngliche Thesendokument und die enthaltenen Abbildungen werden unter [Creative Commons BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) veröffentlicht.