pwn1sher/frostbyteCombine l'injection AppDomain Manager avec l'incorporation de shellcode dans des binaires signés pour contourner la détection EDR/AV des payloads red team.
Ces derniers jours, j'ai expérimenté la technique d'injection via le gestionnaire AppDomain et j'ai obtenu un certain succès lors de mes précédentes missions Red Team contre certains EDR. Bien que cette méthode soit très efficace pour un vecteur d'accès initial, j'ai voulu publier une POC qui aidera à dissimuler votre shellcode ailleurs. Finis les fichiers DLL contenant du shellcode intégré !
Bien qu'il s'agisse d'une excellente technique lorsqu'elle est utilisée indépendamment, lorsqu'elle est couplée à une technique de livraison comme l'envoi d'un C# ClickOnce dans un fichier ISO/ZIP/VHD/VHDX, le vrai problème est que, 1 fois sur 10, la DLL pour le domaine d'application était détectée par les heuristiques IA/ML de l'AV/EDR. Cela est dû au fait que le fichier DLL doit être déposé sur le disque avant d'initialiser le domaine d'application. En ignorant les chargements de DLL distants pour l'instant (chemins UNC dans .config), la DLL du domaine d'application contiendrait le shellcode, et j'ai fortement ressenti que c'était la raison d'une probable détection statique, car le reste du code (les appels WINAPI) peut être résolu dynamiquement et assez bien obfusqué.
Je voulais améliorer cette technique en minimisant ce que la DLL contiendrait initialement. J'ai commencé par déposer un shellcode chiffré dans un fichier séparé sur le disque avec la DLL d'injection, mais je suis tombé sur cet article étonnant de Checkpoint intitulé « Campagne de Zloader » (https://research.checkpoint.com/2022/can-you-trust-a-files-digital-signature-new-zloader-campaign-exploits-microsofts-signature-verification-putting-users-at-risk/)
Version TLDR : Nous pouvons intégrer des données arbitraires dans certains champs du PE sans compromettre la signature du fichier. Ainsi, nos données seront intégrées et l'exécutable restera signé numériquement.
Plus d'informations à ce sujet - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
L'idée est donc d'intégrer un stub de shellcode chiffré dans un exécutable signé connu et de parvenir à le garder signé, comme le faisait le malware Zloader. Ainsi, la DLL du gestionnaire AppDomain ne contiendra plus le shellcode en elle-même, mais aura seulement la logique pour extraire le shellcode du binaire PE qui le charge, le déchiffrer et l'exécuter dans un thread séparé. Cette approche pourrait réduire le taux de détection statique de la DLL, tandis que votre shellcode est bien caché dans un binaire signé.
J'ai essayé d'y parvenir en modifiant manuellement des échantillons de ZLoader obtenus sur VirusTotal, mais j'ai ensuite découvert un projet qui avait déjà implémenté toutes ces techniques assez bien - Sigflip. Dans cette POC, j'ai utilisé le code du chargeur de Sigflip pour construire la DLL de l'AppDomain et l'injecteur SigFlip pour intégrer le shellcode chiffré dans notre exécutable C#.
Les gros blobs de shellcode, comme le shellcode Stageless de Cobalt Strike, ne résideront plus sur une DLL non signée sur le disque, quelles que soient les techniques d'obfuscation/encodage utilisées. La DLL est plus propre, plus petite et plus furtive avec un minimum de code, réduisant ainsi les chances de détection.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe qui sera un PE signé numériquement avec un shellcode chiffré intégré.csc /target:library /out:test.dll test.csCette POC n'est qu'une idée que j'avais en tête pour combiner deux techniques d'évasion de défense totalement différentes afin d'aider moi et d'autres Red Teamers à construire de meilleurs payloads d'exécution initiale pour leurs opérations. Ce projet utilise l'injection via le gestionnaire AppDomain comme exemple, mais cette idée est également applicable à d'autres techniques d'injection comme le DLL SideLoading, le DLL Hijacking, etc.
Tous les crédits reviennent à med0x2e, cette POC est construite sur la base de son projet SigFlip