Об атаках банковского трояна RTM на бухгалтеров и финансовых директоров писали довольно много, в том числе и эксперты Group-IB, но в публичном поле пока еще не было ни одного предметного исследования устройств, зараженных RTM. Чтобы исправить эту несправедливость, один из ведущих специалистов Group-IB по компьютерной криминалистике — Олег Скулкин подробно рассказал о том, как провести криминалистическое исследование компьютера, зараженного банковским трояном в рамках реагирования/расследования инцидента.

С чего все началось

О деятельности преступной группы RTM исследователям стало известно в декабре 2015 года. С тех пор фишинговые рассылки, распространяющие данный троян, попадают в электронные почтовые ящики потенциальных жертв с завидным постоянством.

Как вы уже знаете, c сентября по декабрь группа RTM разослала более 11 000 вредоносных писем. На достигнутом киберпреступники останавливаться не собираются, о чем свидетельствуют все новые рассылки, которые мы фиксируем как на сенсорах, защищающих наших клиентов, так и в рамках деятельности по сбору данных об актуальных угрозах.

В этой статье я расскажу, как провести криминалистическое исследование, или попросту форензику, образа накопителя компьютера, зараженного банковским трояном RTM.

Необходимые вводные

Представим, что мы не знаем о заражении компьютера RTM, а имеем лишь факт компрометации, результатом которой стало хищение денежных средств – это позволит выстроить процесс исследования более интересно, а также сделать его применимым и для других кейсов. Хочу также обратить внимание на тот факт, что в рамках данной статьи на обратной инженерии трояна я останавливаться не буду: во-первых, это не компетенция криминалиста, во-вторых, мой коллега, Семен Рогачев уже подробно об этом писал на Хабре.

Итак, все, что у нас есть – образ накопителя компьютера в формате «E01» (Encase Image File Format). Для начала неплохо было бы узнать, что там внутри. Как минимум, операционную систему, ведь именно от нее и ее версии, конечно, зависит наличие тех или иных криминалистических артефактов, которые нам предстоит исследовать.

1. Воспользуемся утилитой mmls из пакета the Sleuth Kit Браяна Кэрриера:



Что же мы имеем? Несколько NTFS-разделов, похожих на Windows. Нужно убедиться наверняка – попробуем отыскать файлы реестра, например, SOFTWARE.

2. Воспользуемся утилитами fls (the Sleuth Kit) и findstr, чтобы узнать соответствующий номер записи в главной файловой таблице (MFT):



Отлично, теперь мы можем скопировать необходимый нам для дальнейшего анализа файл с помощью icat (the Sleuth Kit):

icat -o 718848 E:\RTM.E01 234782 > SOFTWARE

Итак, у нас есть файл реестра SOFTWARE, извлечь наиболее значимую информацию из которого мы можем, например, при помощи RegRipper Харлана Карви. В данный момент нас интересует содержимое раздела Microsoft\Windows NT\CurrentVersion:



Теперь мы знаем, что исследуемый компьютер работал под управлением ОС Windows 7 Professional с пакетом обновления SP1, а, значит, знаем, с какими криминалистическими артефактами можем столкнуться, и какие из них нам могут понадобиться.

С чего же начать наши поиски? Вспомним парадокс Джесси Корнблума: «Malware can hide, but it must run». Неплохим началом может стать поиск потенциальных механизмов закрепления в системе, которые позволяют вредоносным программам осуществлять повторный запуск после перезагрузки компьютера.

Начнем с простого: возьмем файл реестра NTUSER.DAT из каталога пользователя (С:\Users\%username%\) с самой свежей датой модификации и извлечем из него данные при помощи все того же RegRipper. Если мы снова хотим получить номер записи необходимого нам файла средствами fls и findstr, то следует добавить параметр –p для fls – это позволит утилите вывести еще и полные пути к файлам. Зачем это нужно? Дело в том, что файл NTUSER.DAT есть в каталоге у каждого пользователя, а SOFTWARE один на всю систему, поэтому в данном случае важно получить номер записи определенного файла. В общем-то, использовать the Sleuth Kit совсем не обязательно, есть и более удобные инструменты, например, FTK Imager – бесплатный инструмент разработки AccessData, который может быть использован не только для создания криминалистических копий, но и исследования их содержимого:



Начнем с низко висящих фруктов, так называемых «run keys»:



Итак, что мы имеем? Раздел был последний раз изменен 7 ноября, и мы видим, что при входе пользователя запускается файл apg.exe из не самого стандартного расположения. Посмотрим, что еще можно найти в каталоге b7mg81:



TeamViewer? Интересно. Посмотрим на apg.exe поближе – воспользуемся PPEE:



Выглядит как TeamViewer, подписан как TeamViewer, значит это TeamViewer? Похоже на то. Но все не так просто. Давайте посмотрим на таблицу импортов:



Так, msi.dll, где-то мы этот файл уже видели, и это не С:\Windows\System32, а все тот же каталог b7mg81. Судя по размеру, ничего общего с оригинальным msi.dll он не имеет, а значит налицо — DLL Search Order Hijacking: операционная система начинает поиск необходимых библиотек с текущей директории, а это значит, что вместо легитимной msi.dll будет загружена та, которая находится в b7mg81.

Еще один интересный файл – TeamViewer.ini:


А вот и контр-форензика: судя по конфигурационному файлу, журналов наш TeamViewer не вел, и, видимо, использовался в качестве RAT. Что ж, неплохо. Пора выяснить, а запускался ли он вообще.

В Windows довольно много артефактов, указывающих на запуск исполняемых файлов. Давайте продолжим работать с реестром, на этот раз с файлом SYSTEM. Для того, чтобы извлечь из него данные, можно снова воспользоваться RegRipper.

Нас интересует ControlSet001\Control\Session Manager\AppCompatCache. Здесь мы найдем список исполняемых файлов с путями к ним, датами последней модификации (согласно атрибуту $STANDARD_INFORMATION), а также флагом, указывающим на то, запускался файл или нет:



Отлично, наш файл запускался как минимум один раз. Итак, у нас есть некоторый «pivot point», мы знаем, что 7 ноября на накопителе компьютера появился TeamViewer, который не вел журналов, и скорее всего не был виден пользователю, так как вместо легитимной библиотеки загружал ту, которая находится с ним в одном каталоге.

Самое время начать строить таймлайн. Думаю, хватит и того, что можно построить с помощью the Sleuth Kit. Начнем с уже известной нам утилиты fls:

fls.exe -m «C:/» -o 718848 -r -z GMT D:\RTM.E01 > bodyfile.txt

Теперь воспользуемся mactime, чтобы преобразовать полученный файл в таймлайн:

mactime.pl -d -b bodyfile.txt > timeline.csv

Таймлайны очень удобно анализировать в Timeline Explorer Эрика Циммермана. Наш таймлайн будет включать только события файловой системы. Если вы хотите, чтобы он включал и изменения в реестре, журналах и т.п., можете воспользоваться plaso. Лично я использую его крайне редко, так как обработка данных занимает очень много времени, а результат зачастую довольно избыточен.

Вернемся к таймлайну. Каталог b7mg81 был создан 7 ноября 2018 в 13:59:37:


А за две секунды до этого создается файл 21DA.tmp:


Если поискать его контрольную сумму, например, на VirusTotal, то мы получим довольно интересные результаты:



Очевидно, из данного файла и был распакован наш RAT. Идем дальше:


Еще раньше создается каталог LocalDataNT с довольно интересными файлами внутри. Взглянем, например, на WinPrintSvc.exe:


Remote Utilities – еще одно средство удаленного управления. А вот и еще один подозрительный файл, созданный несколькими секундами ранее:


Проверим его контрольную сумму:


Сразу несколько антивирусных продуктов детектируют его как «RemoteAdmin». Судя по всему, он и является источником Remote Utilities. Проверим, запускался ли обнаруженный RAT. На этот раз воспользуемся файлом реестра AmCache.hve из С:\Windows\AppCompat\Programs (получить данные из него в удобоваримом виде позволит все тот же RegRipper):


Как видно на иллюстрации, AmCache позволяет нам получить не только дату первого запуска, но и контрольную сумму файла.

Итак, мы имеет два RAT'а, но откуда они взялись? Хороший вопрос! Если еще поскроллить таймлайн, то мы увидим следы создания довольно подозрительного каталога и файла:


Несмотря на странное расширение, fnbfdnja.hej имеет привычный нам заголовок:


Что же нам покажет поиск по контрольной сумме на VirusTotal? А вот что:


Как видно на иллюстрации, некоторое антивирусное ПО детектирует наш файл довольно определенно – мы имеем дело с RTM. VT может помочь нам еще немного. Если мы посмотрим во вкладку «Relations», то увидим вот что:


Кажется, мы нашли виновника торжества – это «Документы за октябрь.exe». А может и нет, имя связанного с нашим файлом отличается, хоть контрольная сумма и совпадает. Так, снова .exe, а значит нам снова нужно искать следы запуска. Лично я очень люблю работать с реестром, поэтому снова воспользуюсь помощью уже известного файла NTUSER.DAT и RegRipper. В этот раз взглянем на UserAssist – из него мы получим имена и пути к файлам, даты их последнего запуска, а также количество этих самых запусков. Файла «Документы за октябрь.exe» не видно, зато виден другой файл:

C:\Users\%username%\Desktop\Документы среда.exe

Отлично, похоже это то, что нам нужно. Правда есть небольшая проблема – файла в положенном месте нет. Вернемся к таймлайну. После создания файла fnbfdnja.hej происходит вот что:


Файлы в каталоге Temp наверняка принадлежат RTM, но нас интересуют не они. Нас интересуют файлы $R6K21RQ.exe и $I6K21RQ.exe. Именно так выглядят помещенные в «Корзину» файлы – первый содержит непосредственно данные, второй – метаданные. Если мы посмотрим на содержимое $I6K21RQ.exe, сразу увидим путь к искомому файлу – «Документы среда.exe».

Самое время взглянуть, что нам предложит VT по его контрольной сумме:


Видим уже знакомые нам детекты – «RTM». Как оказалось, контрольная сумма нашего файла совпала с контрольной суммой «Документы за октябрь.exe». Более того, VT знает еще несколько файлов с такой же контрольной суммой:


Хорошо бы получить какие-нибудь сетевые индикаторы компрометации. Дампа памяти у нас нет, дампа сетевого траффика тоже, что делать? Файл подкачки! Но как найти иголку в стоге сена? И здесь нам тоже немного поможет VT, на этот раз вкладка «Behavior»:


Похоже на С2, не так ли? Посмотрим, есть ли что-нибудь подобное в нашем файле подкачки (pagefile.sys). Разумеется, есть:


Итак, мы подтвердили, что наш файл взаимодействовал с 185.141.61[.]246. Попробуем найти еще сетевых индикаторов. Одним из RAT'ов был TeamViewer, постараемся найти что-нибудь похожее на его ID. Для этого можно, например, воспользоваться регулярными выражениями:


Отлично, у нас есть еще один сетевой индикатор – 195.123.219[.]87. Разумеется, файлы подкачки пригодны не только для поиска сетевых индикаторов. Если мы вернемся к вкладке «Behavior» на VT, то увидим, что наш файл создает задачи в планировщике. Если мы поищем по строке «fnbfdnja.hej», то найдем вот что:


Созданная задача и запускает fnbfdnja.hej посредством rundll32.exe.

Что ж, пора закругляться. Самое время определить, откуда все-таки взялся файл «Документы среда.exe». Мы уже знаем, что это RTM, а раз это RTM, то наиболее вероятным вектором заражения является фишинговое письмо. В данном случае жертва использовала Microsoft Outlook, поэтому мы нашли OST-файл с почтой в привычном месте, а в нем – то самое фишинговое письмо:


Однако закончить наш пост я хочу не на этом, а на еще одном интересном артефакте. Если мы вернемся к файлу NTUSER.DAT и посмотрим значение параметра «Shell» раздела Software\Microsoft\Windows NT\CurrentVersion\Winlogon, то вместо привычного «explorer.exe» увидим вот что:


А это значит, что после входа пользователя вместо запуска «Проводника» будет осуществляться завершение работы системы, а с ним и завершение этой статьи.