Comment délivrer du code malveillant sans se faire prendre ?
C’est le challenge quotidien des red teams et des attaquants. Là où les équipes défensives installent de nouvelles solutions de sécurité (EDR, XDR, Antivirus nouvelles générations), les équipes offensives doivent redoubler d’ingéniosité pour éviter de se faire détecter et que ces outils alertent les SOCs.
Brancher une clé USB vérolée, envoyer un courriel contenant une archive ou un lien vers un dépôt compromis sont des attaques qui peuvent fonctionner pour les systèmes d’information les plus vulnérables. Mais ces derniers génèrent des journaux d’activités qui peuvent rapidement détecter une compromission.
La solution, détourner une fonctionnalité utiliser par tous, présent dans chaque navigateur web : le cache
NDLR La présentation se base sur l’OS Microsoft et sur les navigateurs Firefox & Chrome
Le cache what is it ?
Afin d’améliorer les performances des navigateurs web et de limiter la bande passante sur le réseau professionnel ou personnel, le cache permet d’enregistrer le contenu des pages web parcourues (HTML, CSS, JS, les images et les médias, les polices d’écriture).
Lors de la prochaine navigation sur ces mêmes pages web, l’utilisateur ne chargera qu’une partie des ressources et non la totalité. Ce qui rend un temps de réponse réduit et donc plus rapide.
Ce comportement peut être observé par le biais de l’inspecteur de votre navigateur pour identifier si une ressource a été chargée directement depuis le serveur web distant ou depuis votre cache.
Mise en cache de pages web via Firefox
Caché oui, mais, ce processus a une durée de vie bien définie. Conserver en mémoire disque la même ressource sans limites de temps peut provoquer des dysfonctionnements sur le site web. Par exemple, si la ressource a été mise à jour par le gestionnaire du site. Chaque ressource sur le disque possède donc une date d’expiration.
Où se cache t - il ?
Selon votre navigateur les ressources en cache peuvent être visible directement en saisissant : « about : cache » sur Firefox ou depuis votre disque.
C : \Users\John\AppData\Local\Mozilla\Firefox\Profiles\{profile folder}\cache2.
Ces fichiers n’ont pas d’extensions.
Fichiers en cache du navigateur Firefox avec date d’expiration
Comment le navigateur définit quel type de fichier il peut mettre en cache ?
Par le champ content type de la requête HTTP
Qui définit le content-type ?
Le serveur web distant
À vos claviers, prêts, hackez
Il suffit donc de créer un faux site web en plaçant dans les ressources un code malveillant. Dans l’exemple présenté cela sera un reverse Shell sous le format d’une dll (Dynamic Link Library) construite par le biais de Metasploit sur Kali Linux. Il ne reste que de lui donner un type « image » au niveau de la configuration du serveur web pour que cette dernière soit chargée sur le navigateur de la victime lors de sa consultation du site compromis. Le fichier de cache contiendra le contenu de calc.dll
Définition du type image sur le serveur web
Page HTML du site web malveillant avec la dll
Mais attendez ! C’est possible d’exécuter une dll depuis un fichier cache ?
Microsoft a implémenté une mesure pour le lancement d’un code arbitraire sans extension, ce qui pose un problème. Mais en rajoutant un « . » à la fin du fichier de cache, une exécution via rundll32 est réalisable.
Livraison réussie, mais…
Un exécutable peut donc être lancé, mais le prochain défi reste de trouver une manière d’exécuter silencieusement ce fichier et surtout d’identifier un moyen distinguer de manière dynamique ce dernier par rapport aux autres fichiers présents dans le cache.
Pourquoi ? Car sur disque, le fichier de cache a un nom composé de chiffres et de lettres aléatoires donc, il faut retrouver le fichier qui nous intéresse dans le but l’exécuter.
Pour ce dernier point, une simple technique répondra à cette problématique : en y insérant un flag (chaine de caractères définies à l’avance).
Concernant Firefox, nous pouvons configurer cet indicateur dans le header HTTP de la réponse au niveau du serveur web.
Rajout du header pour Firefox
Pour chrome, c’est légèrement plus complexe dû à un stockage en base de données SQLite. Nous pouvons néanmoins générer une chaine de caractères spécifique en début et à la fin du fichier calc.dll. Cela permettra de créer une regex avec ces deux paramètres pour identifier le fichier cible en vue d’une exécution.
À une exécution près
Pour ne pas déclencher d’alertes au niveau des EDR et rester sous les radars du SOC, l’exécution de cette dll doit être effectuée par un processus parent venant d’un programme légitime utilisé au sein de la société. Il doit également communiquer avec Internet pour qu’un Reverse Shell soit possible et qu’il soit encapsulé dans le protocole HTTP/HTTPS.
Autant utiliser un service, qui dialogue continuellement avec Internet et qui est installé sur quasiment tous les postes utilisateurs professionnels : Microsoft Teams.
Une attaque bien connue des anciennes versions de Teams et de Onedrive est d’abuser du dossier où l’application est installée. Ce dernier est le « localappdata », un espace où un utilisateur sans être administrateur peut lire les fichiers ET écrire.
C’est donc la parfaite cible.
Il faut également savoir que Microsoft Teams durant son exécution fait appel à des dlls nécessaires à son bon fonctionnement. Des appels peuvent également échouer, car les fichiers peuvent être répartis à plusieurs endroits sur le système Windows.
Le système Windows respecte un ordonnancement lors de la recherche d’une DLL :
- Le dossier de l’application même
- C : \Windows\System32
- C : \Windows\System
- C : \Windows
- Le dossier où le binaire de l’application a été exécutée
- Les dossiers listés dans la variable d’environnement PATH
En utilisant l’outil « process explorer » de la suite Sysinternals, nous pouvons identifier les appels du processus Teams et la recherche de certaines dlls. Celles qui ne sont pas trouvées directement dans le dossier de l’application même seront recherchées en suivant l’ordre de recherche du système d’exploitation de Microsoft.
First load, first execute
L’objectif est donc de modifier et de remplacer notre dll malveillante avec celle d’une existante nécessaire au fonctionnement de Team et qui ne se trouve pas déjà dans le dossier de l’application. Nous devons également faire référence à la vraie dll à la fin de notre programme. La raison ? Teams a besoin de certaines fonctions présentes dans la DLL légitime pour se lancer, sans cela le programme va se fermer en erreur.
Mais qui va faire cette copie ?
La réponse : l’utilisateur
L’objectif est de planifier une campagne de Social Engineering, de cibler une victime pour qu’il consulte le site web de l’attaquant afin qu’il charge en cache le contenu fichier dll malveillante. Ensuite, se faire passer pour le support utilisateur et prétexter la navigation sur un site d’un État questionnable (Russie, Chine,…). Lui envoyer une commande Powershell à lancer depuis son poste. Elle aura pour but de copier le fichier de cache contenant le flag dans le dossier de l’application Teams. Cette commande renommera également le fichier par un vrai nom de dll se trouvant dans system32 et qui est utilisée par Teams, ex : VERSION.dll.
Lors du prochain lancement de Teams, la dll sera exécutée, le Reverse Shell sera opérationnel et cette dernière fera également appel à la « VERSION.dll » légitime.
Cette technique se nomme DLL Proxying.
Voici un résumé de l’attaque :
Étape 1 : Mise en cache du payload
Étape 2 : Social engineering pour exécuter le payload
Étape 3 : Exécution du payload par Microsoft Teams
Comment se protéger ?
Faire du renforcement de poste utilisateur :
- Désactiver les moteurs de scripting pour les personnes n’ayant pas l’utilité
- Installer les programmes dans C : \Programs
- Créer une clé de registre pour vider le cache à chaque fin de session
• Faire de la détection
- Déclencher une alerte si ce n’est pas un process du navigateur qui manipule les fichiers en cache
- Monitorer l’activité localisée dans localappdata
Conclusion : une attaque pas forcément parfaite
De nombreuses limitations sont présentes pour cette attaque :
- Le cache a une durée de vie maximum, il faut donc exploiter l’attaque avant l’expiration de ce dernier
- Une attaque basée sur du spear phishing et sur du Social Engineering nécessitant une action de la victime
- Utilisation d’une vulnérabilité connue d’anciennes versions de Teams/Onedrive maintenant patchées
- Certains EDR détectent les DLLs Proxying et l’action de lancer un PowerShell de la part d’un utilisateur afin de copier un fichier dans le dossier appdata
- Attaque très sensible selon le type de navigateur utilisé (notamment pour retrouver notre payload)
- Le poste utilisateur peut être proxifié et un reverse Shell vers une IP ou un domaine non catégorisé peut être bloqué
Un bon attaquant est celui qui reste caché.
Le contenu de cet article est basé sur les recherches d’Aurélien Chalot (aurelien.chalot@protonmail.com)
Vicent L.
Ingénieur Sécurité
