По следам RTM. Криминалистическое исследование компьютера, зараженного банковским трояном
Об атаках банковского трояна 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» увидим вот что: 
А это значит, что после входа пользователя вместо запуска «Проводника» будет осуществляться завершение работы системы, а с ним и завершение этой статьи.
