С 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.
На рисунках ниже представлено распределение всех файлов, поступивших на анализ, по источникам, а также распределение по источникам тех файлов, в которых был обнаружен вредоносный код.
Для наглядности распределим обнаруженные угрозы по шестичасовым интервалам времени:
Подмечаем ожидаемые пиковые нагрузки в первый (основной) день соревнований и в ночь на следующий день.
Как и прежде, специалисты отдела обнаружения вредоносного ПО Positive Technologies проанализировали все образцы, обнаруженные в 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:
CVE-2008-2992
CVE-2015-1641
CVE-2017-0199
CVE-2017-11882
CVE-2021-1675 (aka PrintNightmare)
CVE-2021-22555
2. Инструменты для проксирования и туннелирования сетевого трафика:
Chisel
Dnscat2
Netcat
Revsocks
Socat
3. Фреймворки для генерации полезной нагрузки:
Empire
Koadic
Nishang
OffensiveVBA
SharpShooter
Shellter
Unicorn
4. Утилиты для повышения привилегий:
JuicyPotato
PrintSpoofer
SweetPotato
WinPEAS
5. Утилиты для получения учетных данных и горизонтального перемещения по сети:
Mimikatz
Nanodump
Rubeus
SharpHound
Winexe
Дальше разберем некоторые примеры детальнее.
ZipSlip
Начнем с наиболее распространенной группы образцов, которые составили пятую часть от общего числа. Рассмотрим эту группу на примере файла с как бы намекающим названием WleXZipPathTraversal1DRb.zip, который был перехвачен в сетевом трафике 14 ноября в 14:38 (здесь и далее время московское).
SHA256: 310e9b0acbcfafe49171698a1a083381c32964fc9678c1f449dd3ca11a2ef7d2
Образец представляет собой ZIP-архив, в котором происходит попытка эксплуатации уязвимости Zip Slip. Благодаря уязвимости класса Path Traversal происходит перезапись указанного файла атакующим.
Далее нам уже встретились боевые образцы. Вот пример перезаписи файла с хешами паролей пользователей (это позволит атакующим сменить пароль учетной записи):
А это PoC для Windows:
А вот пример с перезаписью файла, впоследствии приводящей к запуску произвольного кода на Python:
Что касается обнаружения, вся группа образцов детектировалась на этапе статического анализа с вердиктом tool_win_ZZ_ZipSlip__Trojan__ZIP.
CVE-2021-40444
Было приятно увидеть на противостоянии тренд этого года с точки зрения эксплуатаций программного пакета Microsoft Office. Уязвимость CVE-2021-40444 внесла разнообразие в ходовые документы с эксплойтами 2017–2018 годов под Equation Editor, которым счету нет. Для CVE-2021-40444 существует несколько вариаций, но мы рассмотрим первоначальный вариант, который встретился в «дикой природе», и попробуем описать простыми словами цепочку атаки:
Пользователь получает офисный документ со ссылкой на дополнительные внешние данные. Ссылка содержит 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.
После этого для полученного интерфейса будет вызван метод InvokeCommand. В СInternetShortcut::InvokeCommand строка запуска будет открыта в новом окне браузера (поведение в Windows 7), в CDefFolderMenu::InvokeCommand — произойдет выполнение команды, ассоциированной с расширением (поведение на Windows 10). Собственно, благодаря файловой ассоциации в Windows 10 и будет запущен процесс rundll32.exe с вызовом апплета, чего не случится в Windows 7.
Теперь посмотрим, как это обнаруживалось, на примере документа с именем Sample4.docx (SHA256: 071e36eb8a72afc57ea73c30aadff0bc88c5cd4f688270b2a3ee108fec3fb9a1).
На этапе статического анализа был обнаружен подозрительный вложенный OLE-объект с вердиктом tool_win_ZZ_OfficeEmbedded__Risktool__SubObject__docx — случайность, не имеющая отношения к рассматриваемому эксплойту, которая сыграла нам на руку. Злоумышленники нередко используют встраиваемые OLE-объекты с вредоносным содержимым, поэтому такие документы выделяются из общего потока.
Непосредственно попытка эксплуатации выявлена в результате поведенческого анализа.
Документ был проанализирован в окружении Windows 7 x64, поэтому эксплойт не мог полноценно отработать (о чем мы рассказали выше). Несмотря на это, попытка эксплуатации была благополучно обнаружена, и вредонос не был пропущен.
Кстати, а вот фрагмент вредоносного содержимого с ссылкой на сам эксплойт, с использованием MHTML-схемы:
Excel 4.0 Macros vs Nishang
Рассмотрим более длинную цепочку атаки на следующем примере. 15 ноября в 19:49 на почтовом сервере ДИТ города F было перехвачено письмо с документом CV.xls во вложении (SHA256: 14e52d4e15da53acdb25aba7cfc9a99ba15c8faa4840b0e7dfbd12313cda5447).
Статический анализ выявил макрос в офисном документе — tool_win_ZZ_OfficeMacro__Risktool__Generic__Excel40Macros. Не секрет, что макросы часто используют и в легитимных целях, но здесь нюанс — в документе используются макросы старого образца Excel 4.0.
Вредоносная нагрузка в данном случае очень проста – происходит загрузка и запуск скрипта следующей стадии с помощью PowerShell.
Загружаемый скрипт представляет собой запуск другого скрипта, закодированного Base64. После декодирования обратим внимание на наиболее характерные строки:
А по комбинации выделенных строк уже не составит труда найти оригинальный скрипт Invoke-PowerShellTcp.ps1 в проекте пентестерского фреймворка Nishang — имплементации реверс-шелла по протоколу TCP на PowerShell:
Вот так это выглядело в поведенческом анализе.
Немного других интересностей
И еще несколько любопытных историй в быстром темпе.
Следующие образцы встречались в меньшем количестве, но от этого они не становятся менее значимыми. Давайте бегло посмотрим, что мы еще поймали.
Goagent, sweet KZ
SHA256: 86838bc1fcef16bbe032ebb4a285b02f7a66e392926a15a7e2f092b6fd868323
Мы не сомневались, что вновь увидим срабатывание tool_mem_ZZ_Goagent__Backdoor, которое обнаруживает кастомный бэкдор одной из команд атакующих. Команда нам знакома. Мы уже встречались с ней и ее инструментарием на прошлых битвах The Standoff. В этот раз практически все как прежде: язык Golang, UPX, сбитые имена секций, необфусцированный код. Но есть и небольшое отличие — встретилась версия в виде динамической библиотеки (DLL) с запуском через экспортированную функцию. Ранее мы видели эти бэкдоры только в формате EXE.
Внезапный VMProtect
SHA256: 0f76497fcc729aacb1d42b7100684967537b2d7a86e5d03644f44bc1b339375d
Перед началом мероприятия мы шутили с коллегами, которые общаются с красными командами, мол, вкиньте наши пожелания, чтоб чего-нибудь поинтереснее использовали. Так вот, нас услышали:
Мы сделали вид, что не обратили внимание на имя файла met9010.exe и ни о чем не догадались, и ушли разбираться
Интересные статьи
Интересные статьи
