Beaucoup a été écrit sur les attaques du cheval de Troie bancaire RTM contre des comptables et des directeurs financiers, y compris des
experts du Groupe IB, mais jusqu'à présent, il n'y a pas eu une seule étude de cas d'appareils infectés par RTM dans le domaine public. Pour corriger cette injustice,
Oleg Skulkin , l'un des principaux experts du groupe IB en criminalistique informatique, a
expliqué en détail comment mener une enquête médico-légale sur un ordinateur infecté par un cheval de Troie bancaire dans le cadre d'une réponse / enquête sur incident.
Comment tout a commencé
Les chercheurs ont découvert les activités du groupe criminel RTM en décembre 2015. Depuis lors, des envois de phishing distribuant ce cheval de Troie ont été envoyés aux boîtes aux lettres électroniques des victimes potentielles avec une constance enviable.
Comme vous le savez déjà, de septembre à décembre, le groupe RTM a envoyé plus de 11 000 e-mails malveillants. Les cybercriminels ne vont pas s'arrêter à ce qui a été réalisé, comme en témoignent tous les nouveaux mailings que nous enregistrons à la fois sur des capteurs protégeant nos clients et dans le cadre de la collecte de données sur les menaces actuelles.
Dans cet article, je vais vous expliquer comment mener une enquête médico-légale, ou simplement médico-légale, sur l'image d'un lecteur d'ordinateur infecté par un cheval de Troie bancaire RTM.
Introduction nécessaire
Imaginez que nous ne connaissions pas l'infection de l'ordinateur RTM, mais seulement le fait d'un compromis, dont le résultat a été le vol d'argent - cela nous permettra de construire le processus de recherche de manière plus intéressante et de le rendre applicable à d'autres cas. Je voudrais également attirer l'attention sur le fait que dans le cadre de cet article, je ne m'attarderai pas sur l'ingénierie inverse du cheval de Troie: d'une part, ce n'est pas la compétence du médecin légiste, et d'autre part, mon collègue Semyon Rogachev a écrit à ce sujet en détail sur
Habré .
Donc, tout ce que nous avons, c'est l'image du lecteur de l'ordinateur au format «E01» (Encase Image File Format). Pour commencer, ce serait bien de savoir ce qu'il y a à l'intérieur. Au minimum, le système d'exploitation, car c'est de lui et de sa version, bien sûr, que dépend la présence de certains artefacts médico-légaux que nous devons étudier.
1. Nous utiliserons l'utilitaire mmls du pack du kit Sleuth de Brian Carrier:
Qu'avons-nous? Plusieurs partitions NTFS similaires à Windows. Nous devons nous assurer - nous essaierons de trouver des fichiers de registre, par exemple, des LOGICIELS.
2. Nous utiliserons les utilitaires fls (le kit Sleuth) et findstr pour trouver le numéro d'enregistrement correspondant dans la table de fichiers principale (MFT):
Ok, maintenant nous pouvons copier le fichier dont nous avons besoin pour une analyse plus approfondie en utilisant icat (le kit Sleuth):
icat -o 718848 E: \ RTM.E01 234782> LOGICIEL
Ainsi, nous avons un fichier de registre SOFTWARE, nous pouvons extraire les informations les plus importantes à partir desquelles, par exemple, en utilisant RegRipper Harlan Carvey. Nous sommes actuellement intéressés par le contenu de la section Microsoft \ Windows NT \ CurrentVersion:
Nous savons maintenant que l'ordinateur à l'étude exécutait Windows 7 Professionnel avec Service Pack SP1, ce qui signifie que nous savons quels artefacts médico-légaux nous pouvons rencontrer et lesquels nous pouvons avoir besoin.
Par où commencer nos recherches? Rappelez-vous le paradoxe de Jesse Kornblum: "Les logiciels malveillants peuvent se cacher, mais ils doivent fonctionner." Un bon début peut être la recherche de mécanismes de verrouillage potentiels dans le système qui permettent aux programmes malveillants de redémarrer après un redémarrage de l'ordinateur.
Commençons par un simple: prenez le
fichier de registre
NTUSER.DAT du répertoire utilisateur (C: \ Users \% username% \) avec la date de modification la plus récente et extrayez-en les données en utilisant le même RegRipper. Si nous voulons obtenir le numéro d'enregistrement du fichier dont nous avons besoin en utilisant fls et findstr à nouveau, nous devons ajouter l'option –p à fls - cela permettra à l'utilitaire d'afficher les chemins d'accès complets aux fichiers. Pourquoi est-ce nécessaire? Le fait est que chaque utilisateur a un fichier NTUSER.DAT dans le répertoire, et SOFTWARE est le seul pour tout le système, donc dans ce cas, il est important d'obtenir le numéro d'enregistrement d'un fichier spécifique. En général, l'utilisation du kit Sleuth n'est pas nécessaire du tout, il existe des outils plus pratiques, par exemple,
FTK Imager , un outil de développement gratuit AccessData qui peut être utilisé non seulement pour créer des copies médico-légales, mais aussi pour examiner leur contenu:
Commençons par les fruits bas, les soi-disant
«touches d'exécution» :
Alors qu'avons-nous? La section a été modifiée pour la dernière fois le 7 novembre et nous constatons que lorsque l'utilisateur se connecte, le fichier apg.exe est lancé à partir d'un emplacement non standard. Voyons ce que l'on peut trouver d'autre dans le répertoire b7mg81:
TeamViewer? Intéressant. Examinons de plus près apg.exe - utilisez
PPEE :
On dirait TeamViewer, inscrit en tant que TeamViewer, est-ce donc TeamViewer? Cela ressemble à ça. Mais ce n'est pas si simple. Regardons la table d'importation:
Donc, msi.dll, quelque part, nous avons déjà vu ce fichier, et ce n'est pas C: \ Windows \ System32, mais le même répertoire b7mg81. A en juger par la taille, cela n'a rien à voir avec le msi.dll d'origine, ce qui signifie qu'il est disponible -
DLL Search Order Hijacking : le système d'exploitation commence à rechercher les bibliothèques nécessaires dans le répertoire actuel, ce qui signifie qu'au lieu du msi.dll légitime, celui qui se trouve sera chargé dans b7mg81.
Un autre fichier intéressant est
TeamViewer.ini :
Et voici la contre-expertise: à en juger par le fichier de configuration, notre TeamViewer n'a pas conservé de journaux, et, apparemment, a été utilisé comme RAT. Enfin, pas mal. Il est temps de savoir si tout a commencé.
Il existe de nombreux artefacts sous Windows qui indiquent que les fichiers exécutables sont en cours d'exécution. Continuons à travailler avec le registre, cette fois avec le
fichier SYSTEM . Pour en extraire des données, vous pouvez à nouveau utiliser RegRipper.
Nous sommes intéressés par ControlSet001 \ Control \ Session Manager \ AppCompatCache. On trouvera ici une liste de fichiers exécutables avec leurs chemins d'accès, les dates de la dernière modification (selon l'attribut $ STANDARD_INFORMATION), ainsi qu'un indicateur indiquant si le fichier a été lancé ou non:
Génial, notre fichier a été lancé au moins une fois. Donc, nous avons un «point pivot», nous savons que le 7 novembre TeamViewer est apparu sur le lecteur de l'ordinateur, qui n'a pas gardé de journaux, et n'était probablement pas visible pour l'utilisateur, car au lieu de la bibliothèque légitime, il a chargé celle qui est en un avec lui catalogue.
Il est temps de commencer à construire une chronologie. Je pense que c'est assez de ce qui peut être construit en utilisant le kit Sleuth. Commençons par l'utilitaire fls que nous connaissons déjà:
fls.exe -m “C: /” -o 718848 -r -z GMT D: \ RTM.E01> bodyfile.txt
Utilisez maintenant mactime pour convertir le fichier résultant en une chronologie:
mactime.pl -d -b bodyfile.txt> timeline.csv
Les chronologies sont très pratiques à analyser dans l'
explorateur de chronologie d'Eric Zimmerman . Notre chronologie comprendra uniquement les événements du système de fichiers. Si vous souhaitez inclure des modifications dans le registre, les magazines, etc., vous pouvez utiliser plaso. Personnellement, je l'utilise extrêmement rarement, car le traitement des données prend beaucoup de temps et le résultat est souvent assez redondant.
Retour à la chronologie. Le catalogue b7mg81 a été créé le 7 novembre 2018 à 13:59:37:
Et deux secondes avant cela, le fichier 21DA.tmp est créé:
Si vous recherchez sa somme de contrôle, par exemple, sur VirusTotal, nous obtiendrons des résultats assez intéressants:
De toute évidence, notre RAT a été décompressé à partir de ce fichier. Allez-y:
Encore plus tôt, le répertoire LocalDataNT est créé avec des fichiers assez intéressants à l'intérieur. Jetez un œil à WinPrintSvc.exe, par exemple:
Remote Utilities est un autre outil de gestion à distance. Et voici un autre fichier suspect créé quelques secondes plus tôt:
Vérifiez sa somme de contrôle:
Plusieurs produits antivirus le détectent immédiatement comme "
RemoteAdmin ". Apparemment, il est la source de Remote Utilities. Vérifiez si le RAT détecté a été lancé. Cette fois, nous utiliserons le fichier de registre AmCache.hve de C: \ Windows \ AppCompat \ Programs (le même RegRipper permettra d'en obtenir des données sous une forme digestible):
Comme vous pouvez le voir dans l'illustration, AmCache nous permet d'obtenir non seulement la date du premier lancement, mais également la somme de contrôle du fichier.
Donc, nous avons deux RAT, mais d'où viennent-ils? Bonne question! Si vous faites toujours défiler la chronologie, nous verrons des traces de création d'un répertoire et d'un fichier assez suspects:
Malgré l'étrange extension, fnbfdnja.hej a un titre familier:
Que va nous montrer la recherche de total de contrôle VirusTotal? Et voici ce que:
Comme vous pouvez le voir sur l'illustration, certains logiciels anti-virus détectent notre fichier de manière très précise - nous avons affaire à
RTM . VT peut nous aider davantage. Si nous regardons l'onglet «Relations», nous verrons ceci:
Il semble que nous ayons trouvé le héros de l'occasion - c'est «Documents for October.exe». Ou peut-être pas, le nom associé à notre fichier est différent, bien que la somme de contrôle soit la même. Donc, encore une fois .exe, ce qui signifie que nous devons à nouveau rechercher des traces de démarrage. Personnellement, j'aime vraiment travailler avec le registre, donc je vais à nouveau utiliser l'aide du fichier NTUSER.DAT et RegRipper déjà bien connu. Cette fois, jetez un œil à
UserAssist - à partir de là, nous obtenons les noms et les chemins d'accès aux fichiers, les dates de leur dernier lancement, ainsi que le nombre de ces lancements. Le fichier «Documents for October.exe» n'est pas visible, mais un autre fichier est visible:
C: \ Users \% username% \ Desktop \ Documents environment.exe
Eh bien, cela semble être ce dont nous avons besoin. Certes, il y a un petit problème - il n'y a pas de fichier au bon endroit. Retour à la chronologie. Après avoir créé le fichier fnbfdnja.hej, voici ce qui se passe:
Les fichiers du répertoire Temp appartiennent probablement à RTM, mais cela ne nous intéresse pas. Nous sommes intéressés par les fichiers $ R6K21RQ.exe et $ I6K21RQ.exe. Voici à quoi ressemblent les fichiers placés dans la Corbeille - le premier contient les données elles-mêmes, le second contient les métadonnées. Si nous regardons le contenu de $ I6K21RQ.exe, nous voyons immédiatement le chemin vers le fichier souhaité - «Documents environment.exe».
Il est temps de jeter un œil à ce que VT nous offrira pour sa somme de contrôle:
Nous voyons des détections qui nous sont déjà familières - «RTM». Il s'est avéré que la somme de contrôle de notre fichier coïncidait avec la somme de contrôle «Documents for October.exe». De plus, VT connaît quelques fichiers supplémentaires avec la même somme de contrôle:
Ce serait bien d'obtenir une sorte d'indicateurs de compromis de réseau. Nous n'avons pas de vidage de mémoire, ni de vidage du trafic réseau, que dois-je faire? Échangez le fichier! Mais comment trouver une aiguille dans une botte de foin? Et ici, VT nous aidera un peu aussi, cette fois
l' onglet
Comportement :
Cela ressemble à C2, non? Voyons s'il y a quelque chose comme ça dans notre fichier d'échange (pagefile.sys). Bien sûr, il y a:
Nous avons donc confirmé que notre fichier interagissait avec 185.141.61 [.] 246. Essayons de trouver plus d'indicateurs de réseau. L'un des RAT était TeamViewer, nous allons essayer de trouver quelque chose de similaire à son ID. Pour cela, vous pouvez par exemple utiliser des expressions régulières:
Très bien, nous avons un autre indicateur de réseau - 195.123.219 [.] 87. Bien entendu, les fichiers d'échange ne conviennent pas uniquement à la recherche d'indicateurs de réseau. Si nous revenons à l'onglet Comportement sur VT, nous verrons que notre fichier crée des tâches dans le planificateur. Si nous regardons la ligne "fnbfdnja.hej", nous trouvons ceci:
La tâche créée lance fnbfdnja.hej via rundll32.exe.
Eh bien, il est temps d'arrêter. Il est temps de déterminer d'où provient le fichier "Documents environment.exe". Nous savons déjà qu'il s'agit de RTM, et puisqu'il s'agit de RTM, le vecteur d'infection le plus probable est un e-mail de phishing. Dans ce cas, la victime a utilisé Microsoft Outlook, nous avons donc trouvé le fichier .ost avec le courrier à l'emplacement habituel, et le même e-mail de phishing:
Cependant, je ne veux pas terminer notre article à ce sujet, mais sur un autre artefact intéressant. Si nous revenons au fichier NTUSER.DAT et regardons la valeur du paramètre "Shell" dans la section Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon, alors au lieu de l'habituel "explorer.exe" nous verrons ceci:
Et cela signifie qu'après la connexion de l'utilisateur au lieu de lancer l'Explorateur, le système s'arrêtera et avec lui la fin de cet article.