Vendredi, mes amis. Aujourd'hui, nous partageons avec vous un autre matériel traduit à la veille du lancement du
cours de rétro-ingénierie .
J'ai eu une bonne idée de comment amener un utilisateur à exécuter votre application sans ingénierie sociale ou à l'aide d'exploits tiers. De plus, vous pouvez simplement aller de l'avant et lancer une infection de masse des fichiers exécutables, mais cela peut provoquer de nombreux problèmes imprévus et signifiera également que les applications signées numériquement des fournisseurs de confiance apparaîtront comme des fichiers non approuvés. C'est une bonne idée de «capturer» une seule DLL. Je n'appellerai pas cette méthode contourner UAC (Contrôle de compte d'utilisateur), car vous devez toujours obtenir la permission d'exécuter l'application (pas la vôtre).
Bibliothèque de chargement
Vous connaissez peut-être déjà ce concept, mais je vais tout de même vous expliquer de quoi il s'agit. Lorsque l'application appelle LoadLibrary dans la DLL, mais ne fournit pas le chemin d'accès complet au fichier, le système vérifie d'abord la clé de registre KnownDlls, dans laquelle il recherche le chemin d'accès, s'il n'y est pas, le système cherchera dans le répertoire à partir duquel l'application a été exécutée, puis il recherchera dans les chemins système tels que system32 / syswow64.
Vous pouvez bien placer votre DLL dans le même répertoire que l'application et lui donner le même nom qu'une DLL système normalement chargée, mais dans tous les cas, votre DLL doit répondre aux exigences suivantes:
- L'application doit télécharger la dll par son nom et non par le chemin complet (comme c'est souvent le cas);
- La bibliothèque requise ne doit pas exister dans HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs;
- Votre DLL doit correspondre à l'architecture du processeur (rappelez-vous que les processeurs 64 bits ignoreront simplement les bibliothèques 32 bits et vice versa);
- La bibliothèque est située dans System32 ou Syswow64, car des chemins spécifiques ne fonctionnent souvent pas.
Le virus ZeroAccess a utilisé cette méthode pour tirer parti de «l'ingénierie sociale» et forcer l'utilisateur à exécuter le fichier. Pour commencer, le programme d'installation d'Adobe Flash a été téléchargé à partir de celui officiel, la DLL du bot a été enregistrée dans le même répertoire que le programme d'installation, puis le programme d'installation a été lancé. Lorsque le programme d'installation est exécuté, le contrôle de compte d'utilisateur affiche un message indiquant que l'application est fournie par une source fiable de «Adobe Systems Incorporated», et l'utilisateur est le plus susceptible d'installer cette application (cela conduit à l'exécution d'une DLL de bot malveillante).
S'agit-il d'une véritable mise à jour de Flash Player? Ou ZeroAccess? Personne ne le sait.Méthode moins invasive
Imaginez qu'il existe un dossier dans lequel se trouvent 90% des applications nécessitant des droits de compte élevés et qu'il est accessible en écriture sans ce type de droits. Eh bien, un tel dossier existe et c'est le
%userprofile%Downloads . Vous comprenez probablement où je veux en venir.
Je ne m'attendais pas à trouver une DLL qui charge la plupart des applications et remplit en même temps tous les critères d'une DLL malveillante, et après environ cinq minutes de recherche, j'ai trouvé une mine d'or:
dwmapi.dll . Cette bibliothèque remplissait non seulement tous les critères, mais téléchargeait également tous les fichiers d'installation. Maintenant, créons notre propre DLL, nommez-la
“dwmapi.dll” , placez-la dans le dossier Téléchargements et exécutez le fichier d'installation.
Succès! Mais le fait est que dès que nous démarrons l'installation, cela ne fonctionnera pas, car nous avons remplacé une bibliothèque importante, mais c'est facile à corriger. Nous infectons la DLL.
Création d'une DLL d'infect
Au début, je voulais simplement ajouter un nouvel en-tête de section, modifier le champ NumberOfSections dans l'en-tête PE, puis ajouter ma section à la fin du fichier PE. Il s'est avéré qu'immédiatement après le dernier en-tête de section, il existe un répertoire d'importation associé qui sera écrasé par notre en-tête de section. Par conséquent, après environ 2 heures d'écriture d'une application pour restaurer tout PE à partir de zéro, quelqu'un m'a rappelé que le répertoire d'importation lié n'existe que pour accélérer le téléchargement des fichiers importés et peut être écrasé, puis simplement désactivé dans l'en-tête PE.
Pendant les 15 minutes suivantes, j'ai tenu CTRL + Z pour revenir à mon point de départ et me suis senti stupide. Après deux lignes de code, mon infecteur a fonctionné comme il se doit et j'ai pu passer à l'étape suivante. Désormais, l'infecteur déconnecte et réécrit simplement le répertoire d'importation associé avec un nouvel en-tête de section, ajoute une nouvelle section à la fin du fichier PE, ajuste SizeOfImage pour accueillir la nouvelle section, puis modifie AddressOfEntryPoint pour pointer vers notre nouvelle section.
Tout ce dont nous avons besoin maintenant, c'est du code que nous y mettons.
Shellcode
Le choix évident était de forcer la section ajoutée à exécuter le shellcode, nous n'avons donc pas eu à nous soucier des délocalisations et de l'importation. Le code réel est assez simple et écrit en utilisant des macros FASM pratiques, je vais rapidement expliquer comment cela fonctionne.
- La pile est vérifiée pour s'assurer que dwmapi.dll a été appelé par DLL_PROCESS_ATTACH;
- La structure Ldr PEB est utilisée pour obtenir l'adresse de base de Kernel32 et Ntdll;
- Une implémentation GetProcAddress simple est utilisée pour importer les fonctions suivantes: NtOpenProcessToken, NtQueryInformationToken, NtClose, ExpandEnvironmentStringsA, CreateProcessA;
- Le jeton de processus actuel est ouvert et le code lui demande de confirmer que l'application à partir de laquelle nous démarrons dispose des droits d'administrateur UAC;
- Il s'avère que le chemin cmd.exe, puis la ligne de commande est appelée;
- L'exécution est retransférée au point d'entrée réel de dwmapi.dll, c'est pourquoi l'exécution peut continuer.
Tout mettre ensemble
Le résultat final de l'opération infecte dwmapi.dll avec notre shellcode et le place dans le dossier de téléchargement, dès que l'utilisateur télécharge et exécute le programme d'installation, ce qui nécessite des droits d'administrateur, une ligne de commande sera appelée en tant qu'administrateur (en raison de Wow64FsRedirect et du fait que la plupart des paramètres fonctionnent sous wow64, nous pouvons utiliser le même code sur les systèmes Windows 32 bits et 64 bits).
Vous pouvez trouver l'infecteur complet et le shellcode sur mon github:
https://github.com/MalwareTech/UACElevator .
C’est tout. Rendez-vous sur le parcours!