Как стать автором
Обновить
Positive Technologies
Лидер результативной кибербезопасности

The Standoff 2021, ноябрь edition. Что не проскочило мимо песочницы PT Sandbox

Время на прочтение11 мин
Количество просмотров3K

С 14 по 16 ноября 2021 года на киберполигоне The Standoff происходило третье противостояние между атакующими и защитниками. Сражения прошли в стремительно развивающемся городе-государстве F, в инфраструктуру которого в этот раз входили следующие сектора: электроэнергетика, добывающая промышленность, жилищно-коммунальное хозяйство, логистика, нефтеперерабатывающий комбинат, металлургическое производство и департамент IT.

Реализовывать недопустимые события ринулись десять суперскилованных команд атакующих (red teams), а на бастионах защиты их встречали пять команд защитников (blue teams). И, как обычно, сторонним пристальным наблюдателем всего происходящего на киберарене был security operations center (SOC), который в этот раз представляла команда cyberART (ГК Innostage).

Однако сложно оставаться в стороне от такой захватывающей кибердвижухи. Несколько команд экспертного центра безопасности Positive Technologies — PT Expert Security Center (PT ESC) — не смогли удержаться и таки засунули свои носы сенсоры в гущу событий. Одной из таких команд был наш отдел обнаружения вредоносного ПО. С помощью песочницы PT Sandbox мы старательно изучали все файлы, которые влетали в инфраструктуру противостояния, и, вооружившись различными технологиями, искали вредоносный код:

  • обрабатывали файлы, используя статические правила PT ESC,

  • сканировали файлы антивирусными движками,

  • запускали файлы в изолированной среде, чтобы проанализировать их поведение с помощью правил PT ESC,

  • анализировали дампы сетевого трафика, используя правила PT Network Attack Discovery,

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

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

Общая статистика

Мы анализировали события в песочнице за период с 14 ноября 12:00 по 16 ноября 14:00. Стоит отметить, что, согласно регламенту кибербитвы, в период с 14 ноября 19:00 по 15 ноября 10:00 активных действий на площадке не было. За время проведения атак в песочнице было зарегистрировано 11 770 задач на анализ. В 3796 случаях было обнаружено вредоносное ПО. Ниже перечислены источники, из которых брались файлы на анализ:

  • вложения в письмах с почтовых серверов инфраструктуры города-государства F;

  • файлы из сетевого трафика, перехваченные с помощью PT Network Attack Discovery;

  • файлы, загруженные вручную через веб-интерфейс специалистами SOC.

На рисунках ниже представлено распределение всех файлов, поступивших на анализ, по источникам, а также распределение по источникам тех файлов, в которых был обнаружен вредоносный код.

Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникам
Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникам
Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникам
Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникам

Для наглядности распределим обнаруженные угрозы по шестичасовым интервалам времени:

Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в систему
Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в систему

Подмечаем ожидаемые пиковые нагрузки в первый (основной) день соревнований и в ночь на следующий день.

Как и прежде, специалисты отдела обнаружения вредоносного ПО Positive Technologies проанализировали все образцы, обнаруженные в PT Sandbox, для валидации детектов и отнесения образцов к семействам вредоносного ПО. На рисунке ниже — классификация файлов по семействам.

Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействам
Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействам

В распределение попало 448 уникальных образцов, дубликаты были отброшены.

Стейджеры (трояны-загрузчики первой стадии) популярных фреймворков Metasploit и CobaltStrike, а также эксплойты уязвимости CVE-2018-4993 в программе для просмотра PDF файлов Adobe Acrobat Reader мы видим в топе не в первый раз. Особенности этих вредоносов уже рассматривались, в том числе, и нами, поэтому не будем повторяться. Вместо этого отметим попытки эксплуатации уязвимости Zip Slip, которая позволяет перезаписать произвольные файлы в системе. Атакующие проводили атаки с использованием нашумевшей уязвимости 2021 года CVE-2021-40444 в программном продукте Microsoft Office через компонент MSHTML, которая приводит к запуску произвольного кода. Также отметим использование инструмента PowerMemory для извлечения учетных записей пользователей из атакованных систем,мы не встречали использование такой утилиты ранее.

Перечислим некоторых представителей оставшихся 38 вредоносных семейств, попавших на диаграмме выше в категорию Others:

1.       Эксплойты уязвимостей в программах Adobe Acrobat Reader, Microsoft Office, службе печати ОС Windows и netfilter ОС Linux:

2.       Инструменты для проксирования и туннелирования сетевого трафика:

3.       Фреймворки для генерации полезной нагрузки:

4.       Утилиты для повышения привилегий:

5.       Утилиты для получения учетных данных и горизонтального перемещения по сети:

Дальше разберем некоторые примеры детальнее.

ZipSlip

Начнем с наиболее распространенной группы образцов, которые составили пятую часть от общего числа. Рассмотрим эту группу на примере файла с как бы намекающим названием WleXZipPathTraversal1DRb.zip, который был перехвачен в сетевом трафике 14 ноября в 14:38 (здесь и далее время московское).

SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2

Образец представляет собой ZIP-архив, в котором происходит попытка эксплуатации уязвимости Zip Slip. Благодаря уязвимости класса Path Traversal происходит перезапись указанного файла атакующим.

Образец для тестирования уязвимости ZipSlip, SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2
Образец для тестирования уязвимости ZipSlip, SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2

Далее нам уже встретились боевые образцы. Вот пример перезаписи файла с хешами паролей пользователей (это позволит атакующим сменить пароль учетной записи):

Перезапись файла /etc/passwd уязвимостью ZipSlip, SHA256: 13aef0c541ab5a5c18aae98881c75fe6e567f6b1e45c1b7c69c7aab3a1d4b03d
Перезапись файла /etc/passwd уязвимостью ZipSlip, SHA256: 13aef0c541ab5a5c18aae98881c75fe6e567f6b1e45c1b7c69c7aab3a1d4b03d

А это PoC для Windows:

Перезапись файла :\Windows\win.ini уязвимостью ZipSlip, SHA256: d12d20c9d194baac402cc0c459ee46f5ea5c3b3152c75fd7ab2bfd3acdd881a8
Перезапись файла :\Windows\win.ini уязвимостью ZipSlip, SHA256: d12d20c9d194baac402cc0c459ee46f5ea5c3b3152c75fd7ab2bfd3acdd881a8

А вот пример с перезаписью файла, впоследствии приводящей к запуску произвольного кода на Python:

Запуск кода с помощью уязвимости ZipSlip, SHA256: 9df641b25f8adeed9f04ed26fb23a1f3643b536f6e4fee9fdd7ada9386472b88
Запуск кода с помощью уязвимости ZipSlip, SHA256: 9df641b25f8adeed9f04ed26fb23a1f3643b536f6e4fee9fdd7ada9386472b88

Что касается обнаружения, вся группа образцов детектировалась на этапе статического анализа с вердиктом tool_win_ZZ_ZipSlip__Trojan__ZIP.

Обнаружение уязвимости ZipSlip в PT Sandbox, SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2
Обнаружение уязвимости ZipSlip в PT Sandbox, SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2

CVE-2021-40444

Было приятно увидеть на противостоянии тренд этого года с точки зрения эксплуатаций программного пакета Microsoft Office. Уязвимость CVE-2021-40444 внесла разнообразие в ходовые документы с эксплойтами 2017–2018 годов под Equation Editor, которым счету нет. Для CVE-2021-40444 существует несколько вариаций, но мы рассмотрим первоначальный вариант, который встретился в «дикой природе», и попробуем описать простыми словами цепочку атаки:

  1. Пользователь получает офисный документ со ссылкой на дополнительные внешние данные. Ссылка содержит MHTML-схему, чтобы задействовать уязвимый MSHTML-компонент.

    2. Происходит загрузка HTML-страницы с эксплойтом.

    3. В загруженной странице содержится JavaScript, который загружает CAB-архив.

    4. CAB-архив содержит уязвимость ZipSlip, которая позволяет разместить содержащийся INF-файл в каталоге %TEMP%.

    5. INF-файл открывается с использованием схемы .cpl.

    6. Так как INF-файл — это на самом деле динамическая библиотека (DLL), происходит подгрузка библиотеки в процесс rundll32.exe в качестве Control Panel applet;

    7. Profit! Cостоялся запуск полезной нагрузки и выполнение вредоносного кода.

Обратим внимание на нетипичность ситуации с этой уязвимостью. Как правило, обнаруживаемые уязвимости затрагивают некоторые свежие версии атакуемого приложения и множество старых. В сентябре, изучая CVE-2021-40444, мы вскрыли любопытный факт — эксплойт не отрабатывает на Windows 7, но благополучно выполняется на Windows 10. Различное поведение объясняется отличиями в коде библиотек, не связанных с Microsoft Office.

Различия в работе Windows 7 и Windows 10 проявляются при интерпретации .cpl-схемы при запуске ненастоящего INF-файла. А именно — в работе метода GetUIObjectOf интерфейса CInternetFolder, который вызывается из библиотеки shell32.dll (именно в библиотеку shell32.dll происходит передача управления из движка MSHTML — вот такая немного нетривиальная цепочка). Реализация кода метода GetUIObjectOf в двух ОС расположена в разных библиотеках: в Windows 7 это ieframe.dll, а в Windows 10 — windows.storage.dll (уже здесь может закрасться мысль, что дальнейшее поведение будет отличаться). В самой функции происходит сравнение известных IID с тем, который передается в функцию (при интерпретации .cpl-схемы это IID_IContextMenu). Для IID_IContextMenu в Windows 7 возвращается InternetShortcut, в Windows 10 — DefaultContextMenu. Происходит это потому, что в ieframe.dll происходит проверка версии ОС в функции IsOs_Win8OrGreater.

Фрагмент реализации CInternetFolder::GetUIObjectOf в ieframe.dll, Windows 7 x64
Фрагмент реализации CInternetFolder::GetUIObjectOf в ieframe.dll, Windows 7 x64
Фрагмент реализации CInternetFolder::GetUIObjectOf в windows.storage.dll, Windows 10 x64
Фрагмент реализации CInternetFolder::GetUIObjectOf в windows.storage.dll, Windows 10 x64

После этого для полученного интерфейса будет вызван метод InvokeCommand. В СInternetShortcut::InvokeCommand строка запуска будет открыта в новом окне браузера (поведение в Windows 7), в CDefFolderMenu::InvokeCommand — произойдет выполнение команды, ассоциированной с расширением (поведение на Windows 10). Собственно, благодаря файловой ассоциации в Windows 10 и будет запущен процесс rundll32.exe с вызовом апплета, чего не случится в Windows 7.

Строка запуска файловой ассоциации cplfile
Строка запуска файловой ассоциации cplfile

Теперь посмотрим, как это обнаруживалось, на примере документа с именем Sample4.docx (SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1).

На этапе статического анализа был обнаружен подозрительный вложенный OLE-объект с вердиктом tool_win_ZZ_OfficeEmbedded__Risktool__SubObject__docx — случайность, не имеющая отношения к рассматриваемому эксплойту, которая сыграла нам на руку. Злоумышленники нередко используют встраиваемые OLE-объекты с вредоносным содержимым, поэтому такие документы выделяются из общего потока.

Обнаружение подозрительного документа с вложенным OLE-объектом в PT Sandbox, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1
Обнаружение подозрительного документа с вложенным OLE-объектом в PT Sandbox, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1

Непосредственно попытка эксплуатации выявлена в результате поведенческого анализа.

Обнаружение эксплойта CVE-2021-40444 в PT Sandbox, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1
Обнаружение эксплойта CVE-2021-40444 в PT Sandbox, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1

Документ был проанализирован в окружении Windows 7 x64, поэтому эксплойт не мог полноценно отработать (о чем мы рассказали выше). Несмотря на это, попытка эксплуатации была благополучно обнаружена, и вредонос не был пропущен.

Кстати, а вот фрагмент вредоносного содержимого с ссылкой на сам эксплойт, с использованием MHTML-схемы:

Фрагмент вредоносного содержимого, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1
Фрагмент вредоносного содержимого, SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1

Excel 4.0 Macros vs Nishang

Рассмотрим более длинную цепочку атаки на следующем примере. 15 ноября в 19:49 на почтовом сервере ДИТ города F было перехвачено письмо с документом CV.xls во вложении (SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447).

Статический анализ выявил макрос в офисном документе — tool_win_ZZ_OfficeMacro__Risktool__Generic__Excel40Macros. Не секрет, что макросы часто используют и в легитимных целях, но здесь нюанс — в документе используются макросы старого образца Excel 4.0.

Статическое выявление Excel 4.0 Macro, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
Статическое выявление Excel 4.0 Macro, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447

Вредоносная нагрузка в данном случае очень проста – происходит загрузка и запуск скрипта следующей стадии с помощью PowerShell.

Вредоносное содержимое в офисном документе с макросом, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
Вредоносное содержимое в офисном документе с макросом, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
Фрагмент сетевого трафика с полезной нагрузкой, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
Фрагмент сетевого трафика с полезной нагрузкой, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447

Загружаемый скрипт представляет собой запуск другого скрипта, закодированного Base64. После декодирования обратим внимание на наиболее характерные строки:

PowerShell-скрипт декодированных данных в Base64, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
PowerShell-скрипт декодированных данных в Base64, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447

А по комбинации выделенных строк уже не составит труда найти оригинальный скрипт Invoke-PowerShellTcp.ps1 в проекте пентестерского фреймворка Nishang — имплементации реверс-шелла по протоколу TCP на PowerShell:

Оригинальный скрипт реверс-шелла в проекте Nishang на github
Оригинальный скрипт реверс-шелла в проекте Nishang на github

Вот так это выглядело в поведенческом анализе.

Обнаружение Nishang в PT Sandbox, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447
Обнаружение Nishang в PT Sandbox, SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447

Немного других интересностей

И еще несколько любопытных историй в быстром темпе.

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

Goagent, sweet KZ

SHA256: 86838bc1fcef16bbe032ebb4a285b02f7a66e392926a15a7e2f092b6fd868323

Мы не сомневались, что вновь увидим срабатывание tool_mem_ZZ_Goagent__Backdoor, которое обнаруживает кастомный бэкдор одной из команд атакующих. Команда нам знакома. Мы уже встречались с ней и ее инструментарием на прошлых битвах The Standoff. В этот раз практически все как прежде: язык Golang, UPX, сбитые имена секций, необфусцированный код. Но есть и небольшое отличие — встретилась версия в виде динамической библиотеки (DLL) с запуском через экспортированную функцию. Ранее мы видели эти бэкдоры только в формате EXE.

Внезапный VMProtect

SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d

Перед началом мероприятия мы шутили с коллегами, которые общаются с красными командами, мол, вкиньте наши пожелания, чтоб чего-нибудь поинтереснее использовали. Так вот, нас услышали:

Образец под защитой VMProtect, SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d
Образец под защитой VMProtect, SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d

Мы сделали вид, что не обратили внимание на имя файла met9010.exe и ни о чем не догадались, и ушли разбираться 😎. Тут стоит отметить, что атакующие нас пожалели — образец был защищен простыми опциями: оригинальный программный код лишь упакован, без виртуализации, без Anti-VM-проверок. Распаковав образец, мы от души посмеялись — практически 5 мегабайт протектора свелись к анализу фрагмента кода размером меньше килобайта:

Дамп полезной нагрузки после снятия VMProtect, SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d
Дамп полезной нагрузки после снятия VMProtect, SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d

То, что получилось — стейджер фреймворка Metasploit. Тут можно вспомнить про имя файла, поступившего на анализ — met9010.exe.

Спасибо участникам — мы оценили. В следующий раз ждем образцы под протектором Themida.

«Песочница мешает шеллам? Или пропускает насквозь?»

SHA256: 163d6fc3cfbd7aab025889ed96d9877cba642ea3889ca6d80d76a63856d7516a

SHA256: 49c569d94230031016fd4eaf98f9dfbd15d345db1eb3fb1fe76678941e062e26

Еще одна отличительная черта этого соревнования — мы встретили простейшие, но все-таки техники уклонения от обнаружения в песочнице:

Фрагмент кода уклонения от обнаружения в песочнице, SHA256: 163d6fc3cfbd7aab025889ed96d9877cba642ea3889ca6d80d76a63856d7516a
Фрагмент кода уклонения от обнаружения в песочнице, SHA256: 163d6fc3cfbd7aab025889ed96d9877cba642ea3889ca6d80d76a63856d7516a

Впрочем, видимо, атакующие добавляли фрагменты Anti-VM второпях, и в некоторых случаях проверки не выполнялись. В качестве примера на рисунке ниже приведен фрагмент макроса офисного документа. Мы немного модифицировали код: вырезали инжектируемый шеллкод, вставили комментарии около обфусцированных строк. Несложно заметить, что делается проверка на присутствие процесса sandbox-clicker.exe в системе. Тем не менее список процессов в системе собирается до вызова функции Auto_Open, поэтому WMI-запрос не выполняется, и проверка на наличие процесса работает некорректно.

Фрагмент нерабочего кода уклонения от обнаружения в песочнице, SHA256: 49c569d94230031016fd4eaf98f9dfbd15d345db1eb3fb1fe76678941e062e26
Фрагмент нерабочего кода уклонения от обнаружения в песочнице, SHA256: 49c569d94230031016fd4eaf98f9dfbd15d345db1eb3fb1fe76678941e062e26

QuasarRAT

SHA256: b9be6fbfc7c7ec11be43ece795cc5076e2e618bf3d510c7093cc116e490dc2dd

Помимо упомянутого кастомного бэкдора, мы встретили инструмент open source для управления компьютером жертвы — QuasarRAT, также известный как xRAT. Это средство довольно-таки часто встречается в реальных атаках злоумышленников — приятно было встретить боевую малварь на противостоянии.

Обнаруженный бэкдор QuasarRAT в качестве поведенческого артефакта в PT Sandbox, SHA256: 7860fae6a54fec42e12ee236d016aee6426b50d7efb3f23269616ccefa524c07
Обнаруженный бэкдор QuasarRAT в качестве поведенческого артефакта в PT Sandbox, SHA256: 7860fae6a54fec42e12ee236d016aee6426b50d7efb3f23269616ccefa524c07
Фрагмент характерных строк бэкдора QuasarRAT, SHA256: b9be6fbfc7c7ec11be43ece795cc5076e2e618bf3d510c7093cc116e490dc2dd
Фрагмент характерных строк бэкдора QuasarRAT, SHA256: b9be6fbfc7c7ec11be43ece795cc5076e2e618bf3d510c7093cc116e490dc2dd

Заключение

В завершение мы по-прежнему хотим отметить важность использования нескольких технологий и даже конкурентных решений для эффективной защиты. Ниже приведена диаграмма, которая отражает доли ВПО, обнаруженные:

  • исключительно экспертизой PT ESC,

  • экспертизой как PT ESC, так и внешних вендоров,

  • исключительно экспертизой внешних вендоров.

Распределение детектов между технологиями обнаружения вредоносного ПО
Распределение детектов между технологиями обнаружения вредоносного ПО

Как и полгода назад, мы фиксируем прирост в широте охвата разнообразия ВПО внутренними знаниями продукта PT Sandbox. Также отмечаем, что единственно правильного подхода к обнаружению вредоносного кода не существует, а лучшие результаты показывает комбинация (если хотите, синергия) нескольких движков.

А мы ждем очередных соревнований и, конечно же, новых интересных семплов 😊. Спасибо за внимание!


Алексей Вишняков

Руководитель отдела обнаружения вредоносного ПО Positive Technologies

Теги:
Хабы:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Публикации

Информация

Сайт
www.ptsecurity.com
Дата регистрации
Дата основания
2002
Численность
1 001–5 000 человек
Местоположение
Россия