kudaes/splitAppliquez une approche diviser pour régner pour contourner les EDR
Diviser pour mieux régner est un algorithme couramment utilisé en programmation pour résoudre un problème complexe en le divisant en de nombreux sous-problèmes plus simples. Nous pouvons appliquer cette approche à la sécurité offensive avec un objectif différent : tromper les EDR afin qu'ils perdent la trace de nos activités, les empêchant de déclencher une alerte. C'est similaire à ce que l'on peut voir récemment dans presque toutes les campagnes de phishing observées dans la nature : de longues chaînes d'infection, exécutant plusieurs fichiers étape par étape (par exemple .url -> .one -> .js -> .bat -> .dll) au lieu d'exécuter directement la charge utile finale. Chacun des fichiers exécutés effectue une tâche simple (télécharger un autre fichier, apporter une modification au registre, déplacer des fichiers entre des répertoires ou changer leurs noms/extensions, etc.) qui est difficile à qualifier de malveillante en soi, préparant l'environnement pour l'exécution finale.
J'ai décidé de tester cette idée simple, mais appliquée à un domaine différent : en l'occurrence, l'injection de processus distant. Le code présenté dans ce dépôt n'a rien de nouveau ; au contraire, il s'agit probablement de l'une des façons les plus courantes et les plus directes d'injecter un shellcode dans un processus distant : utiliser NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory, NtProtectVirtualMemory et NtCreateThreadEx. La seule différence est que je fork le processus en utilisant NtCreateUserProcess après chacun de ces appels. Étant donné que le processus forké reprend l'exécution à partir de RIP + 1 et que la mémoire est entièrement copiée depuis le parent, nous pouvons effectuer l'injection de processus distant en utilisant 5 processus différents ; il suffit de s'assurer que tout handle requis pour les appels API ultérieurs est correctement hérité.
De cette façon, nous découpons la procédure d'injection du shellcode en tâches plus simples et exécutons chacune d'elles dans un contexte séparé (processus).
J'ai testé cette preuve de concept contre trois des EDR les plus courants aujourd'hui : MDE, CrowdStrike et SentinelOne. Les résultats parlent d'eux-mêmes : 2 EDR sur 3 ont déclenché une alerte d'injection de processus distant lors de l'exécution de la preuve de concept sans les forks ; en revanche, aucun d'entre eux n'a déclenché d'alerte une fois que j'ai introduit le mécanisme de fork.
Bien sûr, même avec le mécanisme de fork, on peut voir dans la télémétrie brute les événements correspondant à la création de processus, à la création de threads ainsi que tout le comportement inter-processus, mais il semble que cela ne suffise pas aux EDR pour qualifier l'activité de malveillante, ce qui prouve le but de cette preuve de concept. En divisant le comportement malveillant en tâches plus simples et en exécutant chacune d'elles depuis un processus différent, nous pouvons tromper les EDR et les empêcher de déclencher une alerte.
Ce même résultat pourrait être obtenu de différentes manières ; j'ai simplement utilisé le mécanisme de fork pour simplifier mon code et réduire l'activité inter-processus.
Si vous souhaitez tester cela par vous-même, compilez le code avec et sans les appels à la fonction fork(), puis exécutez les deux charges utiles dans un environnement avec l'EDR de votre choix.
Étant donné que nous utilisons le plugin LITCRYPT pour obfusquer les littéraux de chaînes (uniquement pour le code Dinvoke_rs), il est nécessaire de définir la variable d'environnement LITCRYPT_ENCRYPT_KEY avant de compiler le code :
C:\Users\User\Desktop\Split> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"
Ensuite, compilez simplement le code et exécutez l'outil :
C:\Users\User\Desktop\Split> cargo build --release
C:\Users\User\Desktop\Split\target\release> split.exe -h
Cette technique à elle seule ne suffit pas à contourner un EDR ; si votre code n'est pas du tout opsec, il est très probable que vous soyez détecté de toute façon. Ce n'est pas une solution miracle, mais simplement une couche d'évasion supplémentaire que vous pouvez ajouter à vos outils. Néanmoins, le code présenté dans ce dépôt n'est pas opsec du tout, pour les raisons suivantes, entre autres :
D'un autre côté, je n'ai testé cette approche que contre les EDR mentionnés, et j'ignore si d'autres EDR seront également contournés. Vous pouvez la tester et me dire comment ça s'est passé ;)