ShadowPad: новая активность группировки Winnti

Содержание

Введение

В марте 2020 года, в ходе исследования угроз информационной безопасности, специалисты ¹ PT Eхреrt Security Center обнаружили неизвестный ранее бэкдор и назвали его xDll, по оригинальному названию в коде. В результате ошибки конфигурации контрольного сервера некоторые из папок сервера стали доступны извне. На сервере были обнаружены новые образцы:

• ShadowPad;
• неизвестного ранее Python-бэкдора;
• утилиты для развития атаки;
• зашифрованного бэкдора xDll.

ShadowPad используется группой Winnti (APT41, BARIUM, AXIOM), которая активна по меньшей мере с 2012 года. Группа происходит из Китая ². Ключевые интересы группы — это шпионаж и получение финансовой выгоды. Основной арсенал группы состоит из ВПО собственной разработки. Winnti использует сложные методы атак, в числе которых supply chain и watering hole. Группа точно знает, кто их жертва: она очень осторожно развивает атаку и только после детального анализа зараженной системы загружает основной инструментарий. Группа атакует страны по всему миру: Россию, США, Японию, Южную Корею, Германию, Монголию, Белоруссию, Индию, Бразилию. Преимущественно нацелена на следующие отрасли:

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

Первая атака с использованием ShadowPad была зафиксирована в 2017 году ³. Бэкдор часто применяется в атаках типа supply chain (такими, к примеру, были взломы CCleaner ⁴ и ASUS ⁵). Последний отчет об активности группы Winnti с использованием ShadowPad был выпущен компанией ESET в январе 2020 года ⁶. Связей с нынешней инфраструктурой нам обнаружить не удалось. Однако в ходе исследования мы обнаружили пересечения новой инфраструктуры ShadowPad с инфраструктурой других групп, что может говорить о причастности группы Winnti к другим атакам, об организаторах и участниках которых не было известно ранее.

Этот отчет посвящен детальному анализу новой сетевой инфраструктуры, связанной с 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.

Поначалу мы не смогли получить полезную нагрузку для SkinnyD, так как все контрольные серверы были неактивны. Но через некоторое время нам удалось обнаружить новые образцы бэкдора xDll. При анализе одного из них мы нашли открытые папки на его контрольном сервере. Файл с названием x.jpg — это бэкдор xDll, зашифрованный с помощью операции XOR на ключе 0x37. Это дает право предполагать, что xDll является полезной нагрузкой для SkinnyD.

Самым интересным на сервере оказалось содержимое папки cache.

В ней находятся данные о жертвах и ВПО, которое загружается на зараженный компьютер. В названии файла жертвы ставится MD5-хеш-сумма от MAC-адреса зараженного компьютера, который присылает xDll, а в содержимом можно увидеть последнее время соединения с контрольным сервером. По тому, как меняется вторая часть названия файла с ВПО, можно предположить, что в него ставится серверное время в наносекундах, однако оно не является верным: оно относит нас в далекий март 1990 года. Почему был взят такой период времени, нам неизвестно.

В файлах с ВПО мы обнаружили ShadowPad, неизвестный ранее Pythonбэкдор и утилиты для развития атаки. Детальный анализ ВПО и утилит представлен в разделе 2.

С различной периодичностью ⁷ злоумышленники запрашивают через бэкдор 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

Такой сертификат встречался в нескольких исследованиях, посвященных атакам с применением ShadowPad.

Первое — это исследование атаки на CCleaner в 2017 году. В нем эксперты Avast раскрыли некоторые подробности ⁸ той атаки. И на одном из скриншотов в этом документе можно увидеть такой же сертификат, что и в нынешних атаках.

Второе — доклад специалистов из FireEye на конференции Code Blue 2019 о кибератаках на Японию ⁹. В одной из атак специалисты обнаружили использование POISONPLUG (наименование ShadowPad, которое использует компания FireEye). При анализе инфраструктуры они обнаружили такой же сертификат на контрольных серверах ShadowPad.

Поиск серверов с таким сертификатом помог нам выявить не только новые образцы и контрольные серверы ShadowPad, но и пересечения с другими атаками, которые ранее никак не связывались с Winnti (см. раздел 1.2).

В результате нам удалось найти более 150 IP-адресов с таким сертификатом или на которых он был установлен ранее, из них 24 были активными на момент написания статьи, — и 147 доменов, которые связаны с этими адресами. Для доменов мы обнаружили ВПО, связанное с Winnti.

За время исследования инфраструктуры домены группы переезжали с одного IP-адреса на другой множество раз, и это говорит об активной фазе атаки.

Однако неизвестно, что послужило мотивом использовать один SSL-сертификат практически на всех контрольных серверах ShadowPad. Возможно, причина крылась в том, что у злоумышленников был всего один образ системы, который устанавливается на контрольные сервера снова и снова, а может быть, все дело в излишней уверенности злоумышленников в собственной безнаказанности.

Такую историю с сертификатами мы наблюдали и при исследовании активности группы TaskMasters ¹⁰. В какой-то момент злоумышленники начали устанавливать на свои серверы самоподписанные сертификаты с одинаковыми метаданными, что в итоге и помогло обнаружить их инфраструктуру.

Ниже представлено распределение обнаруженных нами IP-адресов по местоположению.

Около половины серверов группировки находятся в Гонконге. IP-адреса распределены по 45 уникальным провайдерам, при этом более половины серверов сконцентрированы на IP-адресах шести провайдеров, пять из которых находятся в Азии — в Гонконге, Китае, Южной Корее.

1.2. Пересечения с другими группами

1.2.1. TA459

В 2017 году компания Proofpoint выпустила отчет об атаках на Россию и Белоруссию с использованием ZeroT и PlugX ¹¹. В отчете встречается домен yandax[.]net, который косвенно относился к инфраструктуре той атаки: этот домен находился на том же IP-адресе, что и один из серверов PlugX.

За последние несколько лет на адрес dophfg@yahoo[.]com было зарегистрировано еще несколько доменов.

Исследуя инфраструктуру ShadowPad, мы наткнулись на активные серверы, которые связаны с двумя доменами из указанной выше группы — www.ertufg[.]com и www.ncdle[.]net. На этих серверах также находился типичный для ShadowPad SSL-сертификат. К тому же мы обнаружили образцы ShadowPad, которые соединяются с этими доменами. Один из них имел относительно старое время компиляции — июль 2017 года. Однако, судя по всему, оно ложное, так как контрольный сервер для него был зарегистрирован в августе 2018 года. Он также маскируется под компонент Bluetooth Stack для Windows компании Toshiba и имеет имя TosBtKbd.dll.

Здесь можно сделать еще одно предположение. Все тот же домен yandax[.]net в данных WHOIS изначально имел совершенно другой почтовые адрес — fjknge@yahoo[.]com. На этот адрес также зарегистрирован один из контрольных серверов NetTraveler — riaru[.]net. Атаки с использованием этого домена проводились на страны СНГ и Европы и были описаны исследователями из компании Proofpoint ¹². В данном случае не исключен факт переиспользования инфраструктуры другой группой для маскировки своей активности. Но все же область этих атак, страны и отрасли, в значительной мере пересекается с областью интересов группы Winnti. Все это отдельные случаи косвенного пересечения, однако можно предположить, что за всеми атаками стоит одна группа.

1.2.2. Bisonal

На одном из IP-адресов инфраструктуры ShadowPad мы обнаружили домены, которые использовались при атаках с использованием Bisonal RAT в 2015—2020 годах.

Также удалось обнаружить семпл Bisonal, связанный непосредственно с новой инфраструктурой ShadowPad.

В ходе изучения этой связи мы наткнулись на презентацию ¹³ японского исследователя из NTT Security Хадзимэ Такаи (англ. Hajime Takai) с конференции JSAC 2020. В ней исследователь рассказывает об атаке на Японию, в цепочке которой присутствует xDll, загружающий Bisonal на зараженный компьютер.

Хадзимэ Такаи связывает эту атаку с кампанией Bitter Biscuit, о которой писали исследователи из Unit42 ¹⁴. В той атаке также применялся Bisonal. Инструментарий для развития атаки, который был обнаружен Хадзимэ Такаи, практически полностью идентичен обнаруженному нами на сервере с ShadowPad, вплоть до соответствия некоторых хеш-сумм (см. раздел 2).

За атаками с применением Bisonal, как считают исследователи ¹⁵, стоит группа Tonto team. Атаки группы сконцентрированы преимущественно на трех странах — России, Южной Корее, Японии. Группа атакует правительственные организации, военные структуры, финансовые и промышленные предприятия. Все это тоже попадает в сферу интересов группы Winnti. А в связи с новыми подробностями об использовании Bisonal в связке с xDll и пересечении сетевых инфраструктур можно предположить, что за атаками с использованием Bisonal стоит группа Winnti.

1.3. Жертвы

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

Большинство стран, находящихся в часовых поясах, отмеченных на карте, точно укладываются в область интересов группы Winnti.

Некоторые скомпрометированные организации нам удалось идентифицировать:

• университет в США,
• аудиторская компания в Голландии,
• две строительные компании — одна в России, другая в Китае,
• пять фирм — разработчиков ПО: одна в Германии, четыре в России.
• Все потенциальные жертвы были уведомлены по линии национальных CERT.

Учитывая, что ShadowPad применялся в атаках типа supply chain через поставщиков ПО, и мы знаем о компрометации по крайней мере пяти разработчиков ПО, можно утверждать, что либо мы имеем дело с подготовкой к очередному распространению ВПО, либо атака уже находится в активной фазе.

1.4. Активность

Активность на сервере (сбор информации с жертв и появление новых утилит) происходила вне рабочего времени относительно тех часовых поясов, в которых находились жертвы: у некоторых был вечер, а у кого-то ранее утро. Такая тактика характерна для Winnti. Группа действовала так же при компрометации CCleaner, о чем писал Avast.

2. Анализ ВПО и инструментов

По собранным нами данным, схема доставки в нынешней кампании выглядит следующим образом.

Анализ времени компиляции найденных нами образцов ВПО показал соответствие с рабочим временем в часовом поясе UTC+8, в котором находятся Китай и Гонконг

2.1. Анализ SkinnyD

SkinnyD (Skinny Downloader) является простым загрузчиком. Он содержит в себе несколько адресов контрольных серверов, которые он последовательно перебирает.

Загрузка следующей стадии осуществляется с помощью GET-запроса на управляющий сервер по специальному URL-адресу, который генерируется согласно форматной строке, жестко прописанной в коде ВПО.

Получаемые с контрольного сервера данные ВПО проверяет следующим образом:

• данные должны быть размером больше чем 0x2800 байт,
• данные должны начинаться с байтов «4D 5A» (MZ).

Загруженный бинарный файл расшифровывается с помощью XOR и загружается с помощью техники рефлективной загрузки PE. После того как бинарный файл загружен, управление передается на экспортируемый символ «MyCode».

ВПО закрепляется на зараженном компьютере через ключ Environment\UserInitMprLogonScript ¹⁶.

В исследуемых экземплярах SkinnyD обнаружен интересный артефакт, связывающий его с xDll. Это строка «3853ed273b89687». Она не используется загрузчиком, возможно это артефакт билдера.

2.2. Анализ xDll

2.2.1. Дроппер

Дроппер представляет собой исполняемый файл, написанный на языке C и скомпилированный в среде разработки Microsoft Visual Studio. Имеет правдоподобную дату компиляции: 11.02.2020 09:54:40.

Содержит полезную нагрузку в виде бэкдора xDll в секции data.

Дроппер извлекает данные в объеме 59 392 байт и пытается записать их по одному из путей:

• %windir%\Device.exe
• %windir%\system32\browseui.dll

Затем копирует себя в каталог %windir%\DeviceServe.exe и создает сервис с именем VService, тем самым обеспечивая автозапуск в качестве службы.

После запуска сервис создает отдельный поток, в котором запускает полезную нагрузку.

Стоит заметить, что запуск другого варианта полезной нагрузки в виде DLL-библиотеки (browseui.dll) не предусмотрен.

2.2.2. Бэкдор xDll

Бэкдор представляет собой исполняемый файл, написанный на языке C++ и скомпилированный в среде разработки Microsoft Visual Studio с использованием библиотеки MFC. Также имеет правдоподобную дату компиляции: 10.02.2020 18:14:37.

Создает отдельный поток, в котором происходят все полезные действия.

В начале работы выполняет разведку в системе и собирает пользовательскую информацию:

• имя компьютера;
• IP-адрес;
• кодовую страницу OEM;
• MAC-адрес (позднее от полученного значения вычисляется MD5-хеш-сумма, которая будет использоваться при взаимодействии с управляющим сервером);

• версию ОС;

• заданный идентификатор «sssss» (вероятно, характеризует данную версию бэкдора);
• информацию о том, является ли пользователь администратором;

• находится ли в виртуальном окружении;

• домен и имя пользователя;

• информацию о процессоре;

• информацию об оперативной памяти;

• о языке системы.

Затем бэкдор расшифровывает адреса управляющего сервера. В данном случае их два, но они совпадают: www.oseupdate.dns-dns[.]com. В теле бэкдора задан третий адрес (127.0.0.1), который замещается расшифрованным.

После получения адреса управляющего сервера отправляется GET-запрос в следующем формате:hxxp://{host}:{port}/{uri}?type=1&hash={md5}&time={current_time}, где:

• host — адрес командного сервера;
• port — 80-й порт;
• uri — строка «news.php»;
• md5 — хеш-сумма MAC-адреса (вероятно, идентификатор жертвы);
• current_time — текущее время в системе.

Вот как это выглядит:

Стоит отметить, что используется заданное значение поля HTTP-заголовка User-Agent:

В ответ от сервера ожидается символ «1». Если нужный ответ приходит, отправляется POSTзапрос с базовой информацией о системе в формате JSON:

• хеш-сумма MAC-адреса,
• имя компьютера,
• IP-адрес,
• версия ОС,
• имя домена,
• заданный идентификатор «sssss»,
• кодовая страница OEM.

Пример запроса:

Стоит заметить, что формат JSON некорректен. Кроме того, пропущено значение поля In_IP. Вероятно, предполагалось, что будут определены как внутренний IP-адрес, так и внешний. Но логика определения внешнего адреса в данном варианте xDll еще не реализована. Еще одна характерная деталь: заданное значение поля HTTP-заголовка Referer: post_info. Значение поля HTTP-заголовка User-Agent также выбирается другое:

Следом запускается цикл обработки команд, поступающих от командного сервера. Для этого бэкдор отправляет GET-запрос, формат которого совпадает с описанным выше. Единственное отличие: значение параметра type: вместо «1» теперь значение «2».

В ответе от сервера ожидается строчная латинская буква (от a до z). В таблице ниже приведены команды и соответствующие действия.

Вот так выглядит запрос команды и ответ:

Следом запрашивается файл и возвращается его содержимое:

Затем отправляется отчет об успешной загрузке:

Вновь обратите внимание на характерное значение поля Referer: upfile, а также тип передаваемых данных (image/pjpeg — изображение) и имя передаваемого файла: {md5}.gif (используется хеш-сумма MAC-адреса).

Отметим, что в случае обработки команды по сбору листинга папки (команда d) запятая не является разделителем. Вместо этого ожидается, что путь до каталога начинается со второго символа: например, «d|C:\Users».

Данные передаются в формате JSON, причем в этот раз форматирование корректно.

Ниже пример отправки информации, полученной в результате анализа системы (команда o).

Данные вновь передаются в формате JSON, но с меньшим числом ключей.

Шаблоны JSON-строки заданы в бэкдоре, а сама строка формируется конкатенацией, без использования специальных библиотек.

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

2.3. ShadowPad

Как ранее указывалось, на одном из серверов xDll мы обнаружили открытые папки, в одной из которых находился ShadowPad. Особых различий с предыдущими версиями мы не выявили, поэтому ниже представлен краткий анализ свежей версии.

2.3.1. Загрузчик ShadowPad и обфускация

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

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

Данный тип обфускации встречался в предыдущих версиях ShadowPad и заключается во вставке определенных байтов в различные участки кода, которые предварительно обозначены двумя противоположными условными переходами, указывающими на один и тот же адрес. Чтобы избавиться от данной обфускации, необходимо заменить указанные байты (например, на операционный код nop).

После получения необходимых адресов API-функций и размещения в памяти необходимых участков кода управление передается на этап установки бэкдора.

2.3.2. Модули ShadowPad

Как и предыдущие версии, этот бэкдор имеет модульную архитектуру. Ниже представлены модули, входящие в бэкдор по умолчанию.

Идентификаторы указанных модулей не меняются от версии к версии, их установка и запуск также происходят в отдельном потоке при помощи реестра. Время компиляции модулей можно найти в так называемом служебном заголовке, который располагается перед шеллкодом.

Характерной особенностью любого экземпляра ShadowPad является шифрование строк, содержащихся в каждом модуле. Алгоритм шифрования похож на используемый при дешифровании бэкдора, отличаются лишь используемые при модификации ключа константы.

Достаточно интересен способ вызова некоторых API-функций в модулях ShadowPad. В некоторых экземплярах ВПО для каждой функции высчитывается адрес функции для каждого ее вызова, как показано на рисунке 47. Также для получения адресов вызываемых функций может использоваться специальная структура, на основании значений членов которой берутся адреса загрузки библиотек, после чего к ним прибавляются смещения нужных API-функций.

Для закрепления на компьютере бэкдор копирует себя в папку C:\ProgramData\ALGS\ с именем Algs.exe, после чего создает службу с таким же именем.

После закрепления ВПО запускает новый процесс svchost.exe, после чего внедряет в него свой код и передает ему управление.

2.3.3. Конфигурация ShadowPad

Во всех экземплярах бэкдора конфигурация зашифрована, за работу с ней отвечает модуль Config.

В данном случае конфигурация представляет собой последовательность шифрованных строк, в которой каждая строка следует за предыдущей без каких-либо дополнений нулями либо выравнивания. Шифрование конфигурации осуществляется тем же алгоритмом, которым зашифрованы строки.

2.3.4. Сетевой протокол

Формат пакетов, использовавшийся во всех версиях ShadowPad, остался неизменным ¹⁷. Формирование пакетов, отправляемых на сервер, характеризуется тем, что тело пакета и его заголовок генерируются отдельно друг от друга. После их конкатенации (без какого-либо дополнения) пакет накрывается алгоритмом шифрования, логика которого близка к логике используемых для дешифрования основного модуля и строк внутри бэкдора. Реализация алгоритма представлена на рис. 53.

Шифрованные пакеты, принимаемые от сервера, имеют достаточно простую структуру (на примере Init-пакета):

2.4. Python-бэкдор

Данный бэкдор был обнаружен на сервере в формате py2exe. Бэкдор написан на Python 2.7 и в начале имеет конфигурационные переменные.

Может выполнять удаленно три команды:

• «CMDCMD» — выполнить через cmd.exe;
• «UPFILECMD» — загрузить файл на сервер;
• «DOWNFILECMD» — скачать файл с сервера.

Команду «ONLINECMD» бэкдор выполняет сразу после запуска: это сбор информации о системе с последующей отправкой на сервер.

Бэкдор имеет функцию закрепления через реестр:

После закрепления и сбора информации о системе происходит упаковка данных и их загрузка на управляющий сервер. Взаимодействие с сервером происходит через TCP-сокеты:

Перед отправкой данные дополняются некоторыми значениями, сжимаются ZLIB и кодируются в Base64.

В коде на рис. 55:

• Flag — значение, инициализируемое при старте бэкдора;

• Key — значение из конфигурационные изменения;
• Cmd — выполненная команда из конфигурационных переменных;
• Data — собранные данные.

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

После отправки изначальных данных о системе бэкдор переходит в бесконечный цикл и ждет команду от сервера.

2.5. Утилиты

На сервере мы также обнаружили утилиты для lateral movement. Большинство из них опенсорсные, доступны на GitHub и изначально написаны на Python, но сконвертированы в PE. На сервере имелись:

• утилиты ¹⁸ для проверки наличия уязвимости MS17-010 и ее эксплуатации;
• утилита LaZagne ¹⁹ для сбора паролей;
• утилита ²⁰ get_lsass для дампа паролей на x64-системах;
• NBTScan;
• утилита DomainInfo для сбора информации о домене.

В утилите для проверки MS17-010 есть небольшое изменение: злоумышленники добавили возможность проверять целую подсеть.

При этом сканирование сети будет идти не по порядку, что может ввести в заблуждение специалистов по безопасности, а также будут пропущены адреса, в последних октетах которых стоят 1 и 2, так как на них очень редко находятся компьютеры пользователей.

Еще одна интересная утилита, обнаруженная на сервере, позволяет собирать информацию о домене, в который включен целевой компьютер. Информация включает в себя:

• имя компьютера;
• имена пользователей компьютера, разбитые по группам;
• имя домена;
• имя группы, в которую входит текущий пользователь;
• имена групп, которые есть в домене;
• имена пользователей каждой группы.

Вся информация собирается легитимным способом с помощью API-функций библиотеки Netapi32.dll и сохраняется в папку с утилитой в формате XML.

Интересно, что утилита скомпилирована в 2014 году на версии Microsoft Visual Studio 2005 года и имеет PDB «e:\Visual Studio 2005\Projects\DomainInfo\Release\Domain05.pdb».

Заключение

Мы проанализировали инфраструктуру группы Winnti, и можем заключить, что активность в ней идет с начала 2019 года. В настоящее время эта инфраструктура только разрастается, что говорит об активных действиях Winnti. По нашим данным, группа уже скомпрометировала более 50 компьютеров, и некоторые из которых них могут послужить «плацдармом» для последующих, более серьезных атак. Группа добавила в свой арсенал несколько новых видов ВПО — SkinnyD, xDll, Python-бэкдор. Мы обнаружили несколько важных связей между нынешней инфраструктурой Winnti и другими крупными атаками, к которым в прошлом группа могла иметь непосредственное отношение. Резко возросшая активность группы также может быть связана с эпидемией коронавируса. Многие компании отправили своих сотрудников на удаленную работу, и при этом, по нашим данным ²¹, 80% сотрудников используют для работы домашние компьютеры. Получается, что многие работники находятся вне досягаемости корпоративных средств защиты и политик безопасности. Это делает их очень уязвимой мишенью.

Мы продолжаем отслеживать активность группы Winnti и не ожидаем, что группа будет снижать свою активность. Через некоторое время мы, возможно, столкнемся с новой атакой, подобной взлому CCleaner и ASUS.

IOCs

Файловые индикаторы

Сетевые индикаторы

SkinnyD

80.245.105.102

xDll

www.yandex2unitedstated.dns05.com

www.oseupdate.dns-dns.com

www.yandex2unitedstated.dynamic-dns.net

g00gle_jp.dynamic-dns.net

hotmail.pop-corps.com

www.yandex2unitedstated.dynamic-dns.net

ShadowPad

www.ncdle.net

www.ertufg.com

info.kavlabonline.com

ttareyice.jkub.com

unaecry.zzux.com

filename.onedumb.com

www.yandex2unitedstated.dns04.com

www.trendupdate.dns05.com

Bisonal

www.g00gleru.wikaba.com

Python backdoor

daum.pop-corps.com

Связанные домены

MITRE

 

1. twitter.com/Vishnyak0v/status/1239908264831311872
2. securelist.com/winnti-more-than-just-a-game/37029/
3. securelist.com/shadowpad-in-corporate-networks/81432/
4. blog.avast.com/update-ccleaner-attackers-entered-via-teamviewer
5. securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/ 
6. www.welivesecurity.com/2020/01/31/winnti-group-targeting-universities-hong-kong/
7. Период запроса колебался от нескольких дней до нескольких недель
8. blog.avast.com/update-ccleaner-attackers-entered-via-teamviewe
9. www.slideshare.net/codeblue_jp/cb19-cyber-threat-landscape-in-japan-revealing-threat-in-the-shadow-by-chi-en-shen-ashley- oleg-bondarenko
10. www.ptsecurity.com/upload/corporate/ru-ru/analytics/Operation-Taskmasters-2019-rus.pdf
11. www.proofpoint.com/us/threat-insight/post/APT-targets-russia-belarus-zerot-plugx
12. www.proofpoint.com/us/threat-insight/post/nettraveler-apt-targets-russian-european-interests
13. jsac.jpcert.or.jp/archive/2020/pdf/JSAC2020_3_takai_jp.pdf
14. unit42.paloaltonetworks.com/unit42-bisonal-malware-used-attacks-russia-south-korea/
15. blog.talosintelligence.com/2020/03/bisonal-10-years-of-play.html
16. attack.mitre.org/techniques/T1037/
17. media.kasperskycontenthub.com/wp-content/uploads/sites/43/2017/08/07172148/ShadowPad_technical_description_PDF.pdf
18. github.com/worawit/MS17-010/blob/master/checker.py
19. github.com/AlessandroZ/LaZagne
20. github.com/3gstudent/Homework-of-C-Language/blob/master/sekurlsa-wdigest.cpp
21. www.ptsecurity.com/ru-ru/research/analytics/remote-work-in-russia-and-the-cis-2020/