Введение
В марте 2020 года, в ходе исследования угроз информационной безопасности, специалисты 1 PT Eхреrt Security Center обнаружили неизвестный ранее бэкдор и назвали его xDll, по оригинальному названию в коде. В результате ошибки конфигурации контрольного сервера некоторые из папок сервера стали доступны извне. На сервере были обнаружены новые образцы:
Этот отчет посвящен детальному анализу новой сетевой инфраструктуры, связанной с ShadowPad, новым образцам ВПО группы Winnti, а также анализу связей с другими атаками, за которыми может стоять данная группа (см. раздел 1.2).
1. Исследование сетевой инфраструктуры
1.1. Обнаружение ShadowPad
Поначалу, при анализе бэкдора xDll (см. раздел 2.2), явной принадлежности к какой-либо APTгруппе обнаружить не удалось. Образец имел крайне интересный контрольный сервер www. g00gle_jp.dynamic-dns[.]net, что потенциально могло говорить об атаках на Японию. Исследуя сетевую инфраструктуру и разыскивая аналогичные образцы, мы обнаружили несколько доменов со схожим названием.
Рисунок 1. Сетевая инфраструктура группы Winnti на начальном этапе анализа
Названия доменов позволяют предположить, что атаки идут еще и на Южную Корею, Монголию, Россию и США. При дальнейшем исследовании инфраструктуры мы обнаружили несколько простых неизвестных нам загрузчиков (см. раздел 2.1), которые обращаются на связанные контрольные серверы и в ответ должны получить полезную нагрузку, зашифрованную с помощью операции XOR на ключе 0x37. Найденный загрузчик мы назвали SkinnyD (Skinny Downloader) из-за его малого размера и скудной функциональности. По структуре URL и некоторым строкам SkinnyD был очень похож на бэкдор xDll.
Рисунок 2. Структура открытых папок на обнаруженном сервере
Поначалу мы не смогли получить полезную нагрузку для SkinnyD, так как все контрольные серверы были неактивны. Но через некоторое время нам удалось обнаружить новые образцы бэкдора xDll. При анализе одного из них мы нашли открытые папки на его контрольном сервере. Файл с названием x.jpg — это бэкдор xDll, зашифрованный с помощью операции XOR на ключе 0x37. Это дает право предполагать, что xDll является полезной нагрузкой для SkinnyD.
Самым интересным на сервере оказалось содержимое папки cache.
Рисунок 3. Содержимое папки cache
Рисунок 4. Пример строк из журнала (подробное описание значений параметров см. в разборе xDll)
В ней находятся данные о жертвах и ВПО, которое загружается на зараженный компьютер. В названии файла жертвы ставится MD5-хеш-сумма от MAC-адреса зараженного компьютера, который присылает xDll, а в содержимом можно увидеть последнее время соединения с контрольным сервером. По тому, как меняется вторая часть названия файла с ВПО, можно предположить, что в него ставится серверное время в наносекундах, однако оно не является верным: оно относит нас в далекий март 1990 года. Почему был взят такой период времени, нам неизвестно.
В файлах с ВПО мы обнаружили ShadowPad, неизвестный ранее Pythonбэкдор и утилиты для развития атаки. Детальный анализ ВПО и утилит представлен в разделе 2.
С различной периодичностью 7 злоумышленники запрашивают через бэкдор xDll информацию с зараженных компьютеров. Она сохраняется в файл list.gif.
Здесь стоит заметить, что в тех образцах xDll, которые есть у нас, в поле «Domain» присылается именно название домена, в котором находится зараженный компьютер. Однако в журнале практически у всех компьютеров стоит SID пользователя, от имени которого запущен xDll. Возможно, это ошибка в коде определенной версии xDll, так как никакой полезной информации для злоумышленника это значение не несет.
Углубившись в сетевую инфраструктуру, мы обнаружили, что на многих серверах установлена одна и та же цепочка из SSL-сертификатов со следующими параметрами:
Рисунок 5. Параметры SSL-сертификата
Такой сертификат встречался в нескольких исследованиях, посвященных атакам с применением ShadowPad.
Первое — это исследование атаки на CCleaner в 2017 году. В нем эксперты Avast раскрыли некоторые подробности 8 той атаки. И на одном из скриншотов в этом документе можно увидеть такой же сертификат, что и в нынешних атаках.
Второе — доклад специалистов из FireEye на конференции Code Blue 2019 о кибератаках на Японию 9. В одной из атак специалисты обнаружили использование POISONPLUG (наименование ShadowPad, которое использует компания FireEye). При анализе инфраструктуры они обнаружили такой же сертификат на контрольных серверах ShadowPad.
Рисунок 6. Слайд из презентации FireEye
Поиск серверов с таким сертификатом помог нам выявить не только новые образцы и контрольные серверы ShadowPad, но и пересечения с другими атаками, которые ранее никак не связывались с Winnti (см. раздел 1.2).
В результате нам удалось найти более 150 IP-адресов с таким сертификатом или на которых он был установлен ранее, из них 24 были активными на момент написания статьи, — и 147 доменов, которые связаны с этими адресами. Для доменов мы обнаружили ВПО, связанное с Winnti.
За время исследования инфраструктуры домены группы переезжали с одного IP-адреса на другой множество раз, и это говорит об активной фазе атаки.
Однако неизвестно, что послужило мотивом использовать один SSL-сертификат практически на всех контрольных серверах ShadowPad. Возможно, причина крылась в том, что у злоумышленников был всего один образ системы, который устанавливается на контрольные сервера снова и снова, а может быть, все дело в излишней уверенности злоумышленников в собственной безнаказанности.
Такую историю с сертификатами мы наблюдали и при исследовании активности группы TaskMasters 10. В какой-то момент злоумышленники начали устанавливать на свои серверы самоподписанные сертификаты с одинаковыми метаданными, что в итоге и помогло обнаружить их инфраструктуру.
Ниже представлено распределение обнаруженных нами IP-адресов по местоположению.
Рисунок 7. Геолокация контрольных серверов
Около половины серверов группировки находятся в Гонконге. IP-адреса распределены по 45 уникальным провайдерам, при этом более половины серверов сконцентрированы на IP-адресах шести провайдеров, пять из которых находятся в Азии — в Гонконге, Китае, Южной Корее.
1.2. Пересечения с другими группами
1.2.1. TA459
В 2017 году компания Proofpoint выпустила отчет об атаках на Россию и Белоруссию с использованием ZeroT и PlugX 11. В отчете встречается домен yandax[.]net, который косвенно относился к инфраструктуре той атаки: этот домен находился на том же IP-адресе, что и один из серверов PlugX.
Рисунок 8. Данные регистранта домена yandax[.]net
За последние несколько лет на адрес dophfg@yahoo[.]com было зарегистрировано еще несколько доменов.
Рисунок 9. Домены с аналогичными WHOIS-данными
Исследуя инфраструктуру ShadowPad, мы наткнулись на активные серверы, которые связаны с двумя доменами из указанной выше группы — www.ertufg[.]com и www.ncdle[.]net. На этих серверах также находился типичный для ShadowPad SSL-сертификат. К тому же мы обнаружили образцы ShadowPad, которые соединяются с этими доменами. Один из них имел относительно старое время компиляции — июль 2017 года. Однако, судя по всему, оно ложное, так как контрольный сервер для него был зарегистрирован в августе 2018 года. Он также маскируется под компонент Bluetooth Stack для Windows компании Toshiba и имеет имя TosBtKbd.dll.
Рисунок 10. Структура доменов, связанных с ShadowPad
Здесь можно сделать еще одно предположение. Все тот же домен yandax[.]net в данных WHOIS изначально имел совершенно другой почтовые адрес — fjknge@yahoo[.]com. На этот адрес также зарегистрирован один из контрольных серверов NetTraveler — riaru[.]net. Атаки с использованием этого домена проводились на страны СНГ и Европы и были описаны исследователями из компании Proofpoint 12. В данном случае не исключен факт переиспользования инфраструктуры другой группой для маскировки своей активности. Но все же область этих атак, страны и отрасли, в значительной мере пересекается с областью интересов группы Winnti. Все это отдельные случаи косвенного пересечения, однако можно предположить, что за всеми атаками стоит одна группа.
1.2.2. Bisonal
На одном из IP-адресов инфраструктуры ShadowPad мы обнаружили домены, которые использовались при атаках с использованием Bisonal RAT в 2015—2020 годах.
Рисунок 11. Домены ShadowPad и Bisonal на одном IP-адресе
Также удалось обнаружить семпл Bisonal, связанный непосредственно с новой инфраструктурой ShadowPad.
Рисунок 12. Bisonal и инфраструктура ShadowPad
В ходе изучения этой связи мы наткнулись на презентацию 13 японского исследователя из NTT Security Хадзимэ Такаи (англ. Hajime Takai) с конференции JSAC 2020. В ней исследователь рассказывает об атаке на Японию, в цепочке которой присутствует xDll, загружающий Bisonal на зараженный компьютер.
Рисунок 13. Слайд из исследования Хадзимэ Такаи
Хадзимэ Такаи связывает эту атаку с кампанией Bitter Biscuit, о которой писали исследователи из Unit42 14. В той атаке также применялся Bisonal. Инструментарий для развития атаки, который был обнаружен Хадзимэ Такаи, практически полностью идентичен обнаруженному нами на сервере с ShadowPad, вплоть до соответствия некоторых хеш-сумм (см. раздел 2).
За атаками с применением Bisonal, как считают исследователи 15, стоит группа Tonto team. Атаки группы сконцентрированы преимущественно на трех странах — России, Южной Корее, Японии. Группа атакует правительственные организации, военные структуры, финансовые и промышленные предприятия. Все это тоже попадает в сферу интересов группы Winnti. А в связи с новыми подробностями об использовании Bisonal в связке с xDll и пересечении сетевых инфраструктур можно предположить, что за атаками с использованием Bisonal стоит группа Winnti.
1.3. Жертвы
По данным с сервера, заражены более 50 компьютеров. Точное расположение и отраслевую принадлежность всех их нам установить не удалось. Однако, соотнеся время последнего подключения зараженного ПК к серверу и время получения нами файла с этим временем, можно составить карту часовых поясов. Некоторые скомпрометированные организации нам удалось идентифицировать:
1.4. Активность
Активность на сервере (сбор информации с жертв и появление новых утилит) происходила вне рабочего времени относительно тех часовых поясов, в которых находились жертвы: у некоторых был вечер, а у кого-то ранее утро. Такая тактика характерна для Winnti. Группа действовала так же при компрометации CCleaner, о чем писал Avast.
2. Анализ ВПО и инструментов
По собранным нами данным, схема доставки в нынешней кампании выглядит следующим образом.
Рисунок 15. Схема доставки полезной нагрузки
Анализ времени компиляции найденных нами образцов ВПО показал соответствие с рабочим временем в часовом поясе UTC+8, в котором находятся Китай и Гонконг
Рисунок 16. Время компиляции ВПО в UTC+0
Рисунок 17. Время компиляции ВПО в UTС+8
2.1. Анализ SkinnyD
SkinnyD (Skinny Downloader) является простым загрузчиком. Он содержит в себе несколько адресов контрольных серверов, которые он последовательно перебирает.
Загрузка следующей стадии осуществляется с помощью GET-запроса на управляющий сервер по специальному URL-адресу, который генерируется согласно форматной строке, жестко прописанной в коде ВПО.
Рисунок 18. Форматная строка для URL
Получаемые с контрольного сервера данные ВПО проверяет следующим образом:
ВПО закрепляется на зараженном компьютере через ключ Environment\UserInitMprLogonScript 16.
Рисунок 19. Код закрепения в системе
В исследуемых экземплярах SkinnyD обнаружен интересный артефакт, связывающий его с xDll. Это строка «3853ed273b89687». Она не используется загрузчиком, возможно это артефакт билдера.
2.2. Анализ xDll
2.2.1. Дроппер
Дроппер представляет собой исполняемый файл, написанный на языке C и скомпилированный в среде разработки Microsoft Visual Studio. Имеет правдоподобную дату компиляции: 11.02.2020 09:54:40.
Рисунок 20. Общая информация о дроппере
Содержит полезную нагрузку в виде бэкдора xDll в секции data.
Рисунок 21. Еще один исполняемый файл в дроппере
Дроппер извлекает данные в объеме 59 392 байт и пытается записать их по одному из путей:
Рисунок 22. Установка сервиса
После запуска сервис создает отдельный поток, в котором запускает полезную нагрузку.
Рисунок 23. Запуск полезной нагрузки
Стоит заметить, что запуск другого варианта полезной нагрузки в виде DLL-библиотеки (browseui.dll) не предусмотрен.
2.2.2. Бэкдор xDll
Бэкдор представляет собой исполняемый файл, написанный на языке C++ и скомпилированный в среде разработки Microsoft Visual Studio с использованием библиотеки MFC. Также имеет правдоподобную дату компиляции: 10.02.2020 18:14:37.
Рисунок 24. Общая информация о полезной нагрузке
Создает отдельный поток, в котором происходят все полезные действия.
В начале работы выполняет разведку в системе и собирает пользовательскую информацию:
Рисунок 25. Получение MAC-адреса
Рисунок 26. Получение версии ОС
Рисунок 27. Проверка прав
Рисунок 28. Проверка окружения
Рисунок 29. Получение домена и имени пользователя
Рисунок 30. Получение информации о процессоре
Рисунок 31. Получение информации об оперативной памяти
Рисунок 32. Получение информации о языке системы
Затем бэкдор расшифровывает адреса управляющего сервера. В данном случае их два, но они совпадают: www.oseupdate.dns-dns[.]com. В теле бэкдора задан третий адрес (127.0.0.1), который замещается расшифрованным.
Рисунок 33. Расшифровка адреса контрольного сервера
После получения адреса управляющего сервера отправляется GET-запрос в следующем формате:
Рисунок 34. Пример запроса к серверу
Стоит отметить, что используется заданное значение поля HTTP-заголовка User-Agent:
Рисунок 35. Встроенный User-Agent
В ответ от сервера ожидается символ «1». Если нужный ответ приходит, отправляется POSTзапрос с базовой информацией о системе в формате JSON:
Рисунок 36. Отправка информации о системе
Стоит заметить, что формат JSON некорректен. Кроме того, пропущено значение поля In_IP. Вероятно, предполагалось, что будут определены как внутренний IP-адрес, так и внешний. Но логика определения внешнего адреса в данном варианте xDll еще не реализована. Еще одна характерная деталь: заданное значение поля HTTP-заголовка Referer: post_info. Значение поля HTTP-заголовка User-Agent также выбирается другое:
Следом запускается цикл обработки команд, поступающих от командного сервера. Для этого бэкдор отправляет GET-запрос, формат которого совпадает с описанным выше. Единственное отличие: значение параметра type: вместо «1» теперь значение «2».
В ответе от сервера ожидается строчная латинская буква (от a до z).
Вот так выглядит запрос команды и ответ:
Рисунок 37. Пример команды на загрузку файла
Следом запрашивается файл и возвращается его содержимое:
Рисунок 38. Содержимое файла, отправленное на сервер
Затем отправляется отчет об успешной загрузке:
Рисунок 39. Отчет об успешной загрузке файла
Вновь обратите внимание на характерное значение поля Referer: upfile, а также тип передаваемых данных (image/pjpeg — изображение) и имя передаваемого файла: {md5}.gif (используется хеш-сумма MAC-адреса).
Отметим, что в случае обработки команды по сбору листинга папки (команда d) запятая не является разделителем. Вместо этого ожидается, что путь до каталога начинается со второго символа: например, «d|C:\Users».
Рисунок 40. Листинг папки
Данные передаются в формате JSON, причем в этот раз форматирование корректно.
Ниже пример отправки информации, полученной в результате анализа системы (команда o).
Рисунок 41. Отправка информации о системе
Данные вновь передаются в формате JSON, но с меньшим числом ключей.
Шаблоны JSON-строки заданы в бэкдоре, а сама строка формируется конкатенацией, без использования специальных библиотек.
Впрочем, в некоторых случаях, когда достаточно короткого отчета, информация передается обычным текстом.
Рисунок 42. Результат команды на исполнение кода
2.3. ShadowPad
Как ранее указывалось, на одном из серверов xDll мы обнаружили открытые папки, в одной из которых находился ShadowPad. Особых различий с предыдущими версиями мы не выявили, поэтому ниже представлен краткий анализ свежей версии.
2.3.1. Загрузчик ShadowPad и обфускация
На первом этапе происходит дешифрование шеллкода, отвечающего за установку бэкдора в системе. Дешифрование осуществляется XOR-подобным алгоритмом, характерной особенностью которого является модификация ключа шифрования на каждой итерации при помощи арифметических операций с определенными константами.
Рисунок 43. Цикл расшифрования основного модуля
После дешифрования управление передается загрузчику, который отличается характерным типом обфускации.
Рисунок 44. Обфускация, используемая в загрузчике
Данный тип обфускации встречался в предыдущих версиях ShadowPad и заключается во вставке определенных байтов в различные участки кода, которые предварительно обозначены двумя противоположными условными переходами, указывающими на один и тот же адрес. Чтобы избавиться от данной обфускации, необходимо заменить указанные байты (например, на операционный код nop).
После получения необходимых адресов API-функций и размещения в памяти необходимых участков кода управление передается на этап установки бэкдора.
2.3.2. Модули ShadowPad
Как и предыдущие версии, этот бэкдор имеет модульную архитектуру. Ниже представлены модули, входящие в бэкдор по умолчанию.
Рисунок 45. Вызовы функций расшифрования и декомпрессии встроенных в бэкдор модулей
Идентификаторы указанных модулей не меняются от версии к версии, их установка и запуск также происходят в отдельном потоке при помощи реестра. Время компиляции модулей можно найти в так называемом служебном заголовке, который располагается перед шеллкодом.
Рисунок 46. Расположение времени сборки в заголовке шеллкода
Характерной особенностью любого экземпляра ShadowPad является шифрование строк, содержащихся в каждом модуле. Алгоритм шифрования похож на используемый при дешифровании бэкдора, отличаются лишь используемые при модификации ключа константы.
Достаточно интересен способ вызова некоторых API-функций в модулях ShadowPad. В некоторых экземплярах ВПО для каждой функции высчитывается адрес функции для каждого ее вызова, как показано на рисунке 47. Также для получения адресов вызываемых функций может использоваться специальная структура, на основании значений членов которой берутся адреса загрузки библиотек, после чего к ним прибавляются смещения нужных API-функций.
Рисунок 47. Код расшифровки строк в ShadowPad
Рисунок 48. Пример обфускации вызова API-функции
Рисунок 49. Деобфусцированные вызовы на примере модуля Install
Для закрепления на компьютере бэкдор копирует себя в папку C:\ProgramData\ALGS\ с именем Algs.exe, после чего создает службу с таким же именем.
Рисунок 50. Созданная для закрепления служба
После закрепления ВПО запускает новый процесс svchost.exe, после чего внедряет в него свой код и передает ему управление.
Рисунок 51. Код создания процесса и внедрения в него
2.3.3. Конфигурация ShadowPad
Во всех экземплярах бэкдора конфигурация зашифрована, за работу с ней отвечает модуль Config.
В данном случае конфигурация представляет собой последовательность шифрованных строк, в которой каждая строка следует за предыдущей без каких-либо дополнений нулями либо выравнивания. Шифрование конфигурации осуществляется тем же алгоритмом, которым зашифрованы строки.
Рисунок 52. Расшифрованная конфигурация ВПО
2.3.4. Сетевой протокол
Формат пакетов, использовавшийся во всех версиях ShadowPad, остался неизменным 17. Формирование пакетов, отправляемых на сервер, характеризуется тем, что тело пакета и его заголовок генерируются отдельно друг от друга. После их конкатенации (без какого-либо дополнения) пакет накрывается алгоритмом шифрования, логика которого близка к логике используемых для дешифрования основного модуля и строк внутри бэкдора. Реализация алгоритма представлена на рис. 53.
Рисунок 53. Код шифрования пакета, используемый при обмене с сервером управления
Шифрованные пакеты, принимаемые от сервера, имеют достаточно простую структуру (на примере Init-пакета):
Рисунок 54. Структура пакета ShadowPad
2.4. Python-бэкдор
Данный бэкдор был обнаружен на сервере в формате py2exe. Бэкдор написан на Python 2.7 и в начале имеет конфигурационные переменные.
Может выполнять удаленно три команды:
Рисунок 55. Конфигурация бэкдора
Рисунок 56. Команды на сбор информации о системе
Бэкдор имеет функцию закрепления через реестр:
После закрепления и сбора информации о системе происходит упаковка данных и их загрузка на управляющий сервер. Взаимодействие с сервером происходит через TCP-сокеты:
Перед отправкой данные дополняются некоторыми значениями, сжимаются ZLIB и кодируются в Base64.
Рисунок 57. Алгоритм упаковки данных
В коде на рис. 55:
Рисунок 58. Инициализация параметра flag
Рисунок 59. Формирование финального пакета данных
Рисунок 60. Пример сформированных данных
После отправки изначальных данных о системе бэкдор переходит в бесконечный цикл и ждет команду от сервера.
Рисунок 61. Основной цикл
2.5. Утилиты
На сервере мы также обнаружили утилиты для lateral movement. Большинство из них опенсорсные, доступны на GitHub и изначально написаны на Python, но сконвертированы в PE. На сервере имелись:
Рисунок 62. Модифицированная утилита для проверки MS17-010
При этом сканирование сети будет идти не по порядку, что может ввести в заблуждение специалистов по безопасности, а также будут пропущены адреса, в последних октетах которых стоят 1 и 2, так как на них очень редко находятся компьютеры пользователей.
Еще одна интересная утилита, обнаруженная на сервере, позволяет собирать информацию о домене, в который включен целевой компьютер. Информация включает в себя:
Интересно, что утилита скомпилирована в 2014 году на версии Microsoft Visual Studio 2005 года и имеет PDB «e:\Visual Studio 2005\Projects\DomainInfo\Release\Domain05.pdb».
Заключение
Мы проанализировали инфраструктуру группы Winnti, и можем заключить, что активность в ней идет с начала 2019 года. В настоящее время эта инфраструктура только разрастается, что говорит об активных действиях Winnti. По нашим данным, группа уже скомпрометировала более 50 компьютеров, и некоторые из которых них могут послужить «плацдармом» для последующих, более серьезных атак. Группа добавила в свой арсенал несколько новых видов ВПО — SkinnyD, xDll, Python-бэкдор. Мы обнаружили несколько важных связей между нынешней инфраструктурой Winnti и другими крупными атаками, к которым в прошлом группа могла иметь непосредственное отношение. Резко возросшая активность группы также может быть связана с эпидемией коронавируса. Многие компании отправили своих сотрудников на удаленную работу, и при этом, по нашим данным 21, 80% сотрудников используют для работы домашние компьютеры. Получается, что многие работники находятся вне досягаемости корпоративных средств защиты и политик безопасности. Это делает их очень уязвимой мишенью.
Источник https://ptsecurity.com/ru-ru/resear...hadowpad-novaya-aktivnost-gruppirovki-winnti/
В марте 2020 года, в ходе исследования угроз информационной безопасности, специалисты 1 PT Eхреrt Security Center обнаружили неизвестный ранее бэкдор и назвали его xDll, по оригинальному названию в коде. В результате ошибки конфигурации контрольного сервера некоторые из папок сервера стали доступны извне. На сервере были обнаружены новые образцы:
- ShadowPad;
- неизвестного ранее Python-бэкдора;
- утилиты для развития атаки;
- зашифрованного бэкдора xDll.
- игровая индустрия,
- разработка ПО,
- авиационно-космическая промышленность,
- энергетика,
- фармацевтика,
- финансовый сектор,
- телекоммуникации,
- строительство,
- образование.
Этот отчет посвящен детальному анализу новой сетевой инфраструктуры, связанной с ShadowPad, новым образцам ВПО группы Winnti, а также анализу связей с другими атаками, за которыми может стоять данная группа (см. раздел 1.2).
1. Исследование сетевой инфраструктуры
1.1. Обнаружение ShadowPad
Поначалу, при анализе бэкдора xDll (см. раздел 2.2), явной принадлежности к какой-либо APTгруппе обнаружить не удалось. Образец имел крайне интересный контрольный сервер www. g00gle_jp.dynamic-dns[.]net, что потенциально могло говорить об атаках на Японию. Исследуя сетевую инфраструктуру и разыскивая аналогичные образцы, мы обнаружили несколько доменов со схожим названием.
Названия доменов позволяют предположить, что атаки идут еще и на Южную Корею, Монголию, Россию и США. При дальнейшем исследовании инфраструктуры мы обнаружили несколько простых неизвестных нам загрузчиков (см. раздел 2.1), которые обращаются на связанные контрольные серверы и в ответ должны получить полезную нагрузку, зашифрованную с помощью операции XOR на ключе 0x37. Найденный загрузчик мы назвали SkinnyD (Skinny Downloader) из-за его малого размера и скудной функциональности. По структуре URL и некоторым строкам SkinnyD был очень похож на бэкдор xDll.
Рисунок 2. Структура открытых папок на обнаруженном сервере
Поначалу мы не смогли получить полезную нагрузку для SkinnyD, так как все контрольные серверы были неактивны. Но через некоторое время нам удалось обнаружить новые образцы бэкдора xDll. При анализе одного из них мы нашли открытые папки на его контрольном сервере. Файл с названием x.jpg — это бэкдор xDll, зашифрованный с помощью операции XOR на ключе 0x37. Это дает право предполагать, что xDll является полезной нагрузкой для SkinnyD.
Самым интересным на сервере оказалось содержимое папки cache.
Рисунок 3. Содержимое папки cache
Рисунок 4. Пример строк из журнала (подробное описание значений параметров см. в разборе xDll)
В ней находятся данные о жертвах и ВПО, которое загружается на зараженный компьютер. В названии файла жертвы ставится MD5-хеш-сумма от MAC-адреса зараженного компьютера, который присылает xDll, а в содержимом можно увидеть последнее время соединения с контрольным сервером. По тому, как меняется вторая часть названия файла с ВПО, можно предположить, что в него ставится серверное время в наносекундах, однако оно не является верным: оно относит нас в далекий март 1990 года. Почему был взят такой период времени, нам неизвестно.
В файлах с ВПО мы обнаружили ShadowPad, неизвестный ранее Pythonбэкдор и утилиты для развития атаки. Детальный анализ ВПО и утилит представлен в разделе 2.
С различной периодичностью 7 злоумышленники запрашивают через бэкдор xDll информацию с зараженных компьютеров. Она сохраняется в файл list.gif.
Здесь стоит заметить, что в тех образцах xDll, которые есть у нас, в поле «Domain» присылается именно название домена, в котором находится зараженный компьютер. Однако в журнале практически у всех компьютеров стоит SID пользователя, от имени которого запущен xDll. Возможно, это ошибка в коде определенной версии xDll, так как никакой полезной информации для злоумышленника это значение не несет.
Углубившись в сетевую инфраструктуру, мы обнаружили, что на многих серверах установлена одна и та же цепочка из SSL-сертификатов со следующими параметрами:
- Корневой: C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myCA, SHA1=0a71519 f5549b21510410cdf4a85701489676ddb
- Основной: C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myServer, SHA1=2d2 d79c478e92a7de25e661ff1a68de0833 b9d9b
Рисунок 5. Параметры SSL-сертификата
Такой сертификат встречался в нескольких исследованиях, посвященных атакам с применением ShadowPad.
Первое — это исследование атаки на CCleaner в 2017 году. В нем эксперты Avast раскрыли некоторые подробности 8 той атаки. И на одном из скриншотов в этом документе можно увидеть такой же сертификат, что и в нынешних атаках.
Второе — доклад специалистов из FireEye на конференции Code Blue 2019 о кибератаках на Японию 9. В одной из атак специалисты обнаружили использование POISONPLUG (наименование ShadowPad, которое использует компания FireEye). При анализе инфраструктуры они обнаружили такой же сертификат на контрольных серверах ShadowPad.
Рисунок 6. Слайд из презентации FireEye
Поиск серверов с таким сертификатом помог нам выявить не только новые образцы и контрольные серверы ShadowPad, но и пересечения с другими атаками, которые ранее никак не связывались с Winnti (см. раздел 1.2).
В результате нам удалось найти более 150 IP-адресов с таким сертификатом или на которых он был установлен ранее, из них 24 были активными на момент написания статьи, — и 147 доменов, которые связаны с этими адресами. Для доменов мы обнаружили ВПО, связанное с Winnti.
За время исследования инфраструктуры домены группы переезжали с одного IP-адреса на другой множество раз, и это говорит об активной фазе атаки.
Однако неизвестно, что послужило мотивом использовать один SSL-сертификат практически на всех контрольных серверах ShadowPad. Возможно, причина крылась в том, что у злоумышленников был всего один образ системы, который устанавливается на контрольные сервера снова и снова, а может быть, все дело в излишней уверенности злоумышленников в собственной безнаказанности.
Такую историю с сертификатами мы наблюдали и при исследовании активности группы TaskMasters 10. В какой-то момент злоумышленники начали устанавливать на свои серверы самоподписанные сертификаты с одинаковыми метаданными, что в итоге и помогло обнаружить их инфраструктуру.
Ниже представлено распределение обнаруженных нами IP-адресов по местоположению.
Рисунок 7. Геолокация контрольных серверов
Около половины серверов группировки находятся в Гонконге. IP-адреса распределены по 45 уникальным провайдерам, при этом более половины серверов сконцентрированы на IP-адресах шести провайдеров, пять из которых находятся в Азии — в Гонконге, Китае, Южной Корее.
1.2. Пересечения с другими группами
1.2.1. TA459
В 2017 году компания Proofpoint выпустила отчет об атаках на Россию и Белоруссию с использованием ZeroT и PlugX 11. В отчете встречается домен yandax[.]net, который косвенно относился к инфраструктуре той атаки: этот домен находился на том же IP-адресе, что и один из серверов PlugX.
Рисунок 8. Данные регистранта домена yandax[.]net
За последние несколько лет на адрес dophfg@yahoo[.]com было зарегистрировано еще несколько доменов.
Рисунок 9. Домены с аналогичными WHOIS-данными
Исследуя инфраструктуру ShadowPad, мы наткнулись на активные серверы, которые связаны с двумя доменами из указанной выше группы — www.ertufg[.]com и www.ncdle[.]net. На этих серверах также находился типичный для ShadowPad SSL-сертификат. К тому же мы обнаружили образцы ShadowPad, которые соединяются с этими доменами. Один из них имел относительно старое время компиляции — июль 2017 года. Однако, судя по всему, оно ложное, так как контрольный сервер для него был зарегистрирован в августе 2018 года. Он также маскируется под компонент Bluetooth Stack для Windows компании Toshiba и имеет имя TosBtKbd.dll.
Рисунок 10. Структура доменов, связанных с ShadowPad
Здесь можно сделать еще одно предположение. Все тот же домен yandax[.]net в данных WHOIS изначально имел совершенно другой почтовые адрес — fjknge@yahoo[.]com. На этот адрес также зарегистрирован один из контрольных серверов NetTraveler — riaru[.]net. Атаки с использованием этого домена проводились на страны СНГ и Европы и были описаны исследователями из компании Proofpoint 12. В данном случае не исключен факт переиспользования инфраструктуры другой группой для маскировки своей активности. Но все же область этих атак, страны и отрасли, в значительной мере пересекается с областью интересов группы Winnti. Все это отдельные случаи косвенного пересечения, однако можно предположить, что за всеми атаками стоит одна группа.
1.2.2. Bisonal
На одном из IP-адресов инфраструктуры ShadowPad мы обнаружили домены, которые использовались при атаках с использованием Bisonal RAT в 2015—2020 годах.
Рисунок 11. Домены ShadowPad и Bisonal на одном IP-адресе
Также удалось обнаружить семпл Bisonal, связанный непосредственно с новой инфраструктурой ShadowPad.
Рисунок 12. Bisonal и инфраструктура ShadowPad
В ходе изучения этой связи мы наткнулись на презентацию 13 японского исследователя из NTT Security Хадзимэ Такаи (англ. Hajime Takai) с конференции JSAC 2020. В ней исследователь рассказывает об атаке на Японию, в цепочке которой присутствует xDll, загружающий Bisonal на зараженный компьютер.
Рисунок 13. Слайд из исследования Хадзимэ Такаи
Хадзимэ Такаи связывает эту атаку с кампанией Bitter Biscuit, о которой писали исследователи из Unit42 14. В той атаке также применялся Bisonal. Инструментарий для развития атаки, который был обнаружен Хадзимэ Такаи, практически полностью идентичен обнаруженному нами на сервере с ShadowPad, вплоть до соответствия некоторых хеш-сумм (см. раздел 2).
За атаками с применением Bisonal, как считают исследователи 15, стоит группа Tonto team. Атаки группы сконцентрированы преимущественно на трех странах — России, Южной Корее, Японии. Группа атакует правительственные организации, военные структуры, финансовые и промышленные предприятия. Все это тоже попадает в сферу интересов группы Winnti. А в связи с новыми подробностями об использовании Bisonal в связке с xDll и пересечении сетевых инфраструктур можно предположить, что за атаками с использованием Bisonal стоит группа Winnti.
1.3. Жертвы
По данным с сервера, заражены более 50 компьютеров. Точное расположение и отраслевую принадлежность всех их нам установить не удалось. Однако, соотнеся время последнего подключения зараженного ПК к серверу и время получения нами файла с этим временем, можно составить карту часовых поясов. Некоторые скомпрометированные организации нам удалось идентифицировать:
- университет в США,
- аудиторская компания в Голландии,
- две строительные компании — одна в России, другая в Китае,
- пять фирм — разработчиков ПО: одна в Германии, четыре в России.
- Все потенциальные жертвы были уведомлены по линии национальных CERT.
1.4. Активность
Активность на сервере (сбор информации с жертв и появление новых утилит) происходила вне рабочего времени относительно тех часовых поясов, в которых находились жертвы: у некоторых был вечер, а у кого-то ранее утро. Такая тактика характерна для Winnti. Группа действовала так же при компрометации CCleaner, о чем писал Avast.
2. Анализ ВПО и инструментов
По собранным нами данным, схема доставки в нынешней кампании выглядит следующим образом.
Рисунок 15. Схема доставки полезной нагрузки
Анализ времени компиляции найденных нами образцов ВПО показал соответствие с рабочим временем в часовом поясе UTC+8, в котором находятся Китай и Гонконг
Рисунок 16. Время компиляции ВПО в UTC+0
Рисунок 17. Время компиляции ВПО в UTС+8
2.1. Анализ SkinnyD
SkinnyD (Skinny Downloader) является простым загрузчиком. Он содержит в себе несколько адресов контрольных серверов, которые он последовательно перебирает.
Загрузка следующей стадии осуществляется с помощью GET-запроса на управляющий сервер по специальному URL-адресу, который генерируется согласно форматной строке, жестко прописанной в коде ВПО.
Рисунок 18. Форматная строка для URL
Получаемые с контрольного сервера данные ВПО проверяет следующим образом:
- данные должны быть размером больше чем 0x2800 байт,
- данные должны начинаться с байтов «4D 5A» (MZ).
ВПО закрепляется на зараженном компьютере через ключ Environment\UserInitMprLogonScript 16.
Рисунок 19. Код закрепения в системе
В исследуемых экземплярах SkinnyD обнаружен интересный артефакт, связывающий его с xDll. Это строка «3853ed273b89687». Она не используется загрузчиком, возможно это артефакт билдера.
2.2. Анализ xDll
2.2.1. Дроппер
Дроппер представляет собой исполняемый файл, написанный на языке C и скомпилированный в среде разработки Microsoft Visual Studio. Имеет правдоподобную дату компиляции: 11.02.2020 09:54:40.
Рисунок 20. Общая информация о дроппере
Содержит полезную нагрузку в виде бэкдора xDll в секции data.
Рисунок 21. Еще один исполняемый файл в дроппере
Дроппер извлекает данные в объеме 59 392 байт и пытается записать их по одному из путей:
- %windir%\Device.exe
- %windir%\system32\browseui.dll
Рисунок 22. Установка сервиса
После запуска сервис создает отдельный поток, в котором запускает полезную нагрузку.
Рисунок 23. Запуск полезной нагрузки
Стоит заметить, что запуск другого варианта полезной нагрузки в виде DLL-библиотеки (browseui.dll) не предусмотрен.
2.2.2. Бэкдор xDll
Бэкдор представляет собой исполняемый файл, написанный на языке C++ и скомпилированный в среде разработки Microsoft Visual Studio с использованием библиотеки MFC. Также имеет правдоподобную дату компиляции: 10.02.2020 18:14:37.
Рисунок 24. Общая информация о полезной нагрузке
Создает отдельный поток, в котором происходят все полезные действия.
В начале работы выполняет разведку в системе и собирает пользовательскую информацию:
- имя компьютера;
- IP-адрес;
- кодовую страницу OEM;
- MAC-адрес (позднее от полученного значения вычисляется MD5-хеш-сумма, которая будет использоваться при взаимодействии с управляющим сервером);
Рисунок 25. Получение MAC-адреса
- версию ОС;
Рисунок 26. Получение версии ОС
- заданный идентификатор «sssss» (вероятно, характеризует данную версию бэкдора);
- информацию о том, является ли пользователь администратором;
Рисунок 27. Проверка прав
- находится ли в виртуальном окружении;
Рисунок 28. Проверка окружения
- домен и имя пользователя;
Рисунок 29. Получение домена и имени пользователя
- информацию о процессоре;
Рисунок 30. Получение информации о процессоре
- информацию об оперативной памяти;
Рисунок 31. Получение информации об оперативной памяти
- о языке системы.
Рисунок 32. Получение информации о языке системы
Затем бэкдор расшифровывает адреса управляющего сервера. В данном случае их два, но они совпадают: www.oseupdate.dns-dns[.]com. В теле бэкдора задан третий адрес (127.0.0.1), который замещается расшифрованным.
Рисунок 33. Расшифровка адреса контрольного сервера
После получения адреса управляющего сервера отправляется GET-запрос в следующем формате:
hxxp://{host}:{port}/{uri}?type=1&hash={md5}&time={current_time}, где:- host — адрес командного сервера;
- port — 80-й порт;
- uri — строка «news.php»;
- md5 — хеш-сумма MAC-адреса (вероятно, идентификатор жертвы);
- current_time — текущее время в системе.
Рисунок 34. Пример запроса к серверу
Стоит отметить, что используется заданное значение поля HTTP-заголовка User-Agent:
Рисунок 35. Встроенный User-Agent
В ответ от сервера ожидается символ «1». Если нужный ответ приходит, отправляется POSTзапрос с базовой информацией о системе в формате JSON:
- хеш-сумма MAC-адреса,
- имя компьютера,
- IP-адрес,
- версия ОС,
- имя домена,
- заданный идентификатор «sssss»,
- кодовая страница OEM.
Рисунок 36. Отправка информации о системе
Стоит заметить, что формат JSON некорректен. Кроме того, пропущено значение поля In_IP. Вероятно, предполагалось, что будут определены как внутренний IP-адрес, так и внешний. Но логика определения внешнего адреса в данном варианте xDll еще не реализована. Еще одна характерная деталь: заданное значение поля HTTP-заголовка Referer: post_info. Значение поля HTTP-заголовка User-Agent также выбирается другое:
Следом запускается цикл обработки команд, поступающих от командного сервера. Для этого бэкдор отправляет GET-запрос, формат которого совпадает с описанным выше. Единственное отличие: значение параметра type: вместо «1» теперь значение «2».
В ответе от сервера ожидается строчная латинская буква (от a до z).
Вот так выглядит запрос команды и ответ:
Рисунок 37. Пример команды на загрузку файла
Следом запрашивается файл и возвращается его содержимое:
Рисунок 38. Содержимое файла, отправленное на сервер
Затем отправляется отчет об успешной загрузке:
Рисунок 39. Отчет об успешной загрузке файла
Вновь обратите внимание на характерное значение поля Referer: upfile, а также тип передаваемых данных (image/pjpeg — изображение) и имя передаваемого файла: {md5}.gif (используется хеш-сумма MAC-адреса).
Отметим, что в случае обработки команды по сбору листинга папки (команда d) запятая не является разделителем. Вместо этого ожидается, что путь до каталога начинается со второго символа: например, «d|C:\Users».
Рисунок 40. Листинг папки
Данные передаются в формате JSON, причем в этот раз форматирование корректно.
Ниже пример отправки информации, полученной в результате анализа системы (команда o).
Рисунок 41. Отправка информации о системе
Данные вновь передаются в формате JSON, но с меньшим числом ключей.
Шаблоны JSON-строки заданы в бэкдоре, а сама строка формируется конкатенацией, без использования специальных библиотек.
Впрочем, в некоторых случаях, когда достаточно короткого отчета, информация передается обычным текстом.
Рисунок 42. Результат команды на исполнение кода
2.3. ShadowPad
Как ранее указывалось, на одном из серверов xDll мы обнаружили открытые папки, в одной из которых находился ShadowPad. Особых различий с предыдущими версиями мы не выявили, поэтому ниже представлен краткий анализ свежей версии.
2.3.1. Загрузчик ShadowPad и обфускация
На первом этапе происходит дешифрование шеллкода, отвечающего за установку бэкдора в системе. Дешифрование осуществляется XOR-подобным алгоритмом, характерной особенностью которого является модификация ключа шифрования на каждой итерации при помощи арифметических операций с определенными константами.
Рисунок 43. Цикл расшифрования основного модуля
После дешифрования управление передается загрузчику, который отличается характерным типом обфускации.
Рисунок 44. Обфускация, используемая в загрузчике
Данный тип обфускации встречался в предыдущих версиях ShadowPad и заключается во вставке определенных байтов в различные участки кода, которые предварительно обозначены двумя противоположными условными переходами, указывающими на один и тот же адрес. Чтобы избавиться от данной обфускации, необходимо заменить указанные байты (например, на операционный код nop).
После получения необходимых адресов API-функций и размещения в памяти необходимых участков кода управление передается на этап установки бэкдора.
2.3.2. Модули ShadowPad
Как и предыдущие версии, этот бэкдор имеет модульную архитектуру. Ниже представлены модули, входящие в бэкдор по умолчанию.
Рисунок 45. Вызовы функций расшифрования и декомпрессии встроенных в бэкдор модулей
| Название модуля | ID | Время компиляции |
| Root | 5E6909BA | GMT: Wednesday, 11 March 2020 г., 15:54:34 |
| Plugins | 5E69097C | GMT: Wednesday, 11 March 2020 г., 15:53:32 |
| Online | 5E690988 | GMT: Wednesday, 11 March 2020 г., 15:53:44 |
| Config | 5E690982 | GMT: Wednesday, 11 March 2020 г., 15:53:38 |
| Install | 5E69099F | GMT: Wednesday, 11 March 2020 г., 15:54:07 |
| DNS | 5E690909 | GMT: Wednesday, 11 March 2020 г., 15:51:37 |
Рисунок 46. Расположение времени сборки в заголовке шеллкода
Характерной особенностью любого экземпляра ShadowPad является шифрование строк, содержащихся в каждом модуле. Алгоритм шифрования похож на используемый при дешифровании бэкдора, отличаются лишь используемые при модификации ключа константы.
Достаточно интересен способ вызова некоторых API-функций в модулях ShadowPad. В некоторых экземплярах ВПО для каждой функции высчитывается адрес функции для каждого ее вызова, как показано на рисунке 47. Также для получения адресов вызываемых функций может использоваться специальная структура, на основании значений членов которой берутся адреса загрузки библиотек, после чего к ним прибавляются смещения нужных API-функций.
Рисунок 47. Код расшифровки строк в ShadowPad
Рисунок 48. Пример обфускации вызова API-функции
Рисунок 49. Деобфусцированные вызовы на примере модуля Install
Для закрепления на компьютере бэкдор копирует себя в папку C:\ProgramData\ALGS\ с именем Algs.exe, после чего создает службу с таким же именем.
Рисунок 50. Созданная для закрепления служба
После закрепления ВПО запускает новый процесс svchost.exe, после чего внедряет в него свой код и передает ему управление.
Рисунок 51. Код создания процесса и внедрения в него
2.3.3. Конфигурация ShadowPad
Во всех экземплярах бэкдора конфигурация зашифрована, за работу с ней отвечает модуль Config.
В данном случае конфигурация представляет собой последовательность шифрованных строк, в которой каждая строка следует за предыдущей без каких-либо дополнений нулями либо выравнивания. Шифрование конфигурации осуществляется тем же алгоритмом, которым зашифрованы строки.
Рисунок 52. Расшифрованная конфигурация ВПО
2.3.4. Сетевой протокол
Формат пакетов, использовавшийся во всех версиях ShadowPad, остался неизменным 17. Формирование пакетов, отправляемых на сервер, характеризуется тем, что тело пакета и его заголовок генерируются отдельно друг от друга. После их конкатенации (без какого-либо дополнения) пакет накрывается алгоритмом шифрования, логика которого близка к логике используемых для дешифрования основного модуля и строк внутри бэкдора. Реализация алгоритма представлена на рис. 53.
Рисунок 53. Код шифрования пакета, используемый при обмене с сервером управления
Шифрованные пакеты, принимаемые от сервера, имеют достаточно простую структуру (на примере Init-пакета):
Рисунок 54. Структура пакета ShadowPad
2.4. Python-бэкдор
Данный бэкдор был обнаружен на сервере в формате py2exe. Бэкдор написан на Python 2.7 и в начале имеет конфигурационные переменные.
Может выполнять удаленно три команды:
- «CMDCMD» — выполнить через cmd.exe;
- «UPFILECMD» — загрузить файл на сервер;
- «DOWNFILECMD» — скачать файл с сервера.
Рисунок 55. Конфигурация бэкдора
Рисунок 56. Команды на сбор информации о системе
Бэкдор имеет функцию закрепления через реестр:
После закрепления и сбора информации о системе происходит упаковка данных и их загрузка на управляющий сервер. Взаимодействие с сервером происходит через TCP-сокеты:
Перед отправкой данные дополняются некоторыми значениями, сжимаются ZLIB и кодируются в Base64.
Рисунок 57. Алгоритм упаковки данных
В коде на рис. 55:
- Flag — значение, инициализируемое при старте бэкдора;
Рисунок 58. Инициализация параметра flag
- Key — значение из конфигурационные изменения;
- Cmd — выполненная команда из конфигурационных переменных;
- Data — собранные данные.
Рисунок 59. Формирование финального пакета данных
Рисунок 60. Пример сформированных данных
После отправки изначальных данных о системе бэкдор переходит в бесконечный цикл и ждет команду от сервера.
Рисунок 61. Основной цикл
2.5. Утилиты
На сервере мы также обнаружили утилиты для lateral movement. Большинство из них опенсорсные, доступны на GitHub и изначально написаны на Python, но сконвертированы в PE. На сервере имелись:
- утилиты 18 для проверки наличия уязвимости MS17-010 и ее эксплуатации;
- утилита LaZagne 19 для сбора паролей;
- утилита 20 get_lsass для дампа паролей на x64-системах;
- NBTScan;
- утилита DomainInfo для сбора информации о домене.
Рисунок 62. Модифицированная утилита для проверки MS17-010
При этом сканирование сети будет идти не по порядку, что может ввести в заблуждение специалистов по безопасности, а также будут пропущены адреса, в последних октетах которых стоят 1 и 2, так как на них очень редко находятся компьютеры пользователей.
Еще одна интересная утилита, обнаруженная на сервере, позволяет собирать информацию о домене, в который включен целевой компьютер. Информация включает в себя:
- имя компьютера;
- имена пользователей компьютера, разбитые по группам;
- имя домена;
- имя группы, в которую входит текущий пользователь;
- имена групп, которые есть в домене;
- имена пользователей каждой группы.
Интересно, что утилита скомпилирована в 2014 году на версии Microsoft Visual Studio 2005 года и имеет PDB «e:\Visual Studio 2005\Projects\DomainInfo\Release\Domain05.pdb».
Заключение
Мы проанализировали инфраструктуру группы Winnti, и можем заключить, что активность в ней идет с начала 2019 года. В настоящее время эта инфраструктура только разрастается, что говорит об активных действиях Winnti. По нашим данным, группа уже скомпрометировала более 50 компьютеров, и некоторые из которых них могут послужить «плацдармом» для последующих, более серьезных атак. Группа добавила в свой арсенал несколько новых видов ВПО — SkinnyD, xDll, Python-бэкдор. Мы обнаружили несколько важных связей между нынешней инфраструктурой Winnti и другими крупными атаками, к которым в прошлом группа могла иметь непосредственное отношение. Резко возросшая активность группы также может быть связана с эпидемией коронавируса. Многие компании отправили своих сотрудников на удаленную работу, и при этом, по нашим данным 21, 80% сотрудников используют для работы домашние компьютеры. Получается, что многие работники находятся вне досягаемости корпоративных средств защиты и политик безопасности. Это делает их очень уязвимой мишенью.
Источник https://ptsecurity.com/ru-ru/resear...hadowpad-novaya-aktivnost-gruppirovki-winnti/