Хабр, всем привет! Меня зовут Никита Полосухин, я старший системный аналитик центра мониторинга и реагирования на кибератаки RED Security SOC. Сегодня хочу продолжить нашу историю об открытии новых (новых ли?) плохих парней (и, вероятно, девушек), которые очень любят взламывать российские компании.

В июне мы рассказали о группировке Cloaked Shadow, которая характеризовалась обширным инструментарием, продвинутыми методами сокрытия и в целом высоким техническим уровнем. После этого мы получили возможность собрать и проанализировать новые данные и ранее не встречавшиеся образцы вредоносного программного обеспечения (ВПО), что помогло сделать много интересных выводов.

Для удобства разделим активность злоумышленников на два периода: 2023–2024 годы и 2025-й.

2023–2024

Самые ранние семплы датируются осенью 2023 года. Их можно разделить на две группы: opensource-утилиты для проксирования и туннелирования трафика внутри инфраструктуры и наружу, а также кастомные дропперы, которые расшифровывали и запускали полезную нагрузку в памяти.

Opensource-утилиты для проксирования и туннелирования трафика

Среди таких opensource-утилит, используемых группировкой, есть три типа инструментов:

1. ReverseSocks5

2. Dropbear

3. Reverse-ssh

Остановимся чуть подробнее на каждом.

ReverseSocks5

Это простой reverse-socks-бэкдор, который идентичен проекту на GitHub (ссылку на него дали выше).

Интересно здесь то, какие методы злоумышленники применяли для сокрытия своего присутствия.

* irqbalance — легитимный демон системы linux.
**На сервере, где мы нашли семпл youtube-dl.service, был установлен легитимный
сервис youtube-dl.
***Список легитимных инструментов sysstat:
- sar, 
- sadc,
- sa1,
- sa2,
- sadf.

Мы видим, насколько злоумышленники творчески подошли к вопросу сокрытия. Что еще интересно, так это регистратор доменов C2 — afraid.org. Об особенностях этой механики поговорим далее, пока отметим ее как уникальный индикатор.

Таким образом, закреплялись все эти семплы через стандартные службы Linux.

Dropbear

Сам семпл был обнаружен по пути /usr/bin/redis-daemon. На зараженном сервере, естественно, был установлен redis для целей команд разработки.

Казалось бы, злоумышленники просто использовали статически скомпилированный SSH-сервер, который может не писать логи подключений. Вот перечень действий для сокрытия, предусмотренных в dropbear по умолчанию; в нашем случае все они были активированы:

1. DISABLE_UTMP

2. DISABLE_LASTLOG

3. DISABLE_WTMP

4. DISABLE_SYSLOG

5. Disable password logins

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

Далее по ходу этой функции выделяется буфер в 4200 байт для ключа.

Все, что нам необходимо, — найти то же самое в коде вредоносного программного обеспечения (ВПО). Для этого можно привязаться к константе 4200 и искать выделение памяти на это количество байт.

И тут мы видим странный xor данных. Расшифровав его, получаем сам ключ:

b'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJUxOq/hUeolbkSSHXWEVzxu+X+VbRuqboJx46dgv0wF\n...

Что интересно, после проверки ключ шифруется обратно.

То есть даже в памяти процесса вы его вряд ли увидите.

Reverse-ssh

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

Вот краткая схема, как это работает:

Здесь мы видим, что вместо доменных имен используются IP-адреса с другими провайдерами, нежели предыдущие C2. Вот почему, строго говоря, на этом этапе мы не могли однозначно сопоставить эти семплы, reverse-socks5 и dropbear. 

Кастомные дропперы для расшифрования и запуска полезной нагрузки в памяти

Злоумышленники применяли известный в кругах форензеров загрузчик. Наши коллеги из Positive Technologies уже описали его и атрибутировали к группировке GOFFEE. Чтобы не оставлять семпл безымянным, назовем образец GOFFEE_LLoader. 

Внесем в общее знание об арсенале этой группировки немного новой информации. Мы видели три класса полезной нагрузки:

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

• DQuic. Bind-shell через протокол QUIC на базе проекта https://github.com/private-octopus/picoquic.

• Chisel. Интересно, что chisel был дополнительно обфусцирован через garble.

• Socat. Утилита для проксирования трафика.

Все семплы закреплялись через системные службы Linux. Как мы уже знаем, загрузчик проверяет argv[0] запуска, и если он не тот, который ожидается, семпл перезапускает себя через execve с нужным окружением и argv[0].

В разных семплах мы видели, что загрузчики немного отличаются друг от друга: где-то строки с требуемым cmdline хранятся as is, а где-то они зашифрованы тем же алгоритмом, что и полезная нагрузка.

import struct
from ida_bytes import get_bytes

def rol32(val, r_bits):
	r_bits &= 31
	return ((val << r_bits) & 0xFFFFFFFF) | (val >> (32 - r_bits))

def xor_roll_decrypt(data: bytes, key: int) -> bytes:
    total_size = len(data)
    decrypted = bytearray(data)
    for offset in range(0, total_size, 4):
        if offset + 4 > total_size:
            break
        cur_size = total_size - offset
        dword = struct.unpack_from("<I", decrypted, offset)[0]
        modifier = rol32(cur_size ^ key, cur_size % 13)
        dword ^= modifier
        struct.pack_into("<I", decrypted, offset, dword)
    return bytes(decrypted)

def main():
   
    src_addr = 0x2020E0
    payload_size = 0x11AB8
    xor_key = 0xD6A3D2BC
    name = 'some_malware'
    

    data = get_bytes(src_addr, payload_size)
    if not data:
        print("[!] Не удалось прочитать данные по адресу")
        return
    decrypted = xor_roll_decrypt(data, xor_key)
# Проверка ELF-заголовка
    if decrypted[:4] != b"\x7FELF":
        print("[!] Предупреждение: Заголовок ELF не распознан! Возможно, данные не ELF или ключ неверный.")
    else:
        print("[+] Заголовок ELF подтверждён.")

    with open(f"{name}_decrypted_payload.elf", "wb") as f:
        f.write(decrypted)

    print(f"[+] Расшифровка завершена. ELF сохранён как '{name}_decrypted_payload.elf'")

if name == "__main__":
	main()

Мы проинвентаризировали все подмены командных строк для обнаруженных нами семплов:

Кстати, находить такую подмену во время реагирования и расследования инцидента можно, сопоставляя comm и cmdline свойства процесса в Linux:

ps -e -o pid,ppid,comm,cmd -w –w

    4485     713 systemd-acpi    [acpi_thermal_pm]

    4494       2 kworker/1:2-eve [kworker/1:2-events]

    4505       2 kworker/0:0-eve [kworker/0:0-events]

    4598     713 nfs             avahi-daemon: running

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

Данные инструменты использовались до февраля 2025 года. А это значит, что CloakedShadow до этого времени, вероятнее всего, состояла из GOFFEE и еще одной или двух неатрибутированных группировок.

2025 год

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

Появление еще одного актора

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

• Коммуникация по зашифрованному DNS-туннелю с C2. Благодаря такому механизму общения с C2 и некорректно настроенным ретрансляциям dns-запросов внутри инфраструктуры жертвы злоумышленники получали прямой доступ к имплантам, установленным в сегментах без интернета.

• Загрузка shellcode-модулей.

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

Вот краткий алгоритм работы семпла:

1. Проверка окружения. Для запуска ВПО проверяются: 

   1. переменные окружения /proc/self/environ

   2. ARP-таблица через /proc/net/arp

   3. /etc/hostname 

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

3. Далее происходит генерация ключа шифрования для взаимодействия с C2.

4. Затем устанавливается сессия с C2 на базе DNS-туннеля через CNAME-записи.

5. После этого, получая команды с C2-сервера, семпл загружает в память shell-код и выполняет его.

В семпле есть интересный механизм — fallback channel. Каждую субботу семпл начинает опрашивать C2-сервер. Если он недоступен, берет из списка другие имена доменов и пытается соединиться с ними по нескольким зонам в строгом порядке: lol, lat, top, linu, cyou, in, sbs, work, casa, com. Например: 

1. erwintech.org

2. hxzjevason.lol

3. hxzjevason.lat

4. hxzjevason.top

5. hxzjevason.link

6. hxzjevason.cyou

7. …

Здесь erwintech.org — основной С2, ниже — fallback.

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

• Shellcode 'connect_tcp' launched in thread ID: 4791

• Shellcode 'checkin' launched in thread ID: 7520

• Shellcode 'shell' launched in thread ID: 17952

Однако восстановить их не получилось.

Для сокрытия своей активности атакующие используют монтирование директории легитимного процесса из procfs (первого попавшегося процесса с родителем PID=1) в каталог procfs вредоносного процесса: 

/bin/sh -c "mount -B /proc/pgrep -P 1 | shuf -n 1 /proc/$MAINPID”

Этот метод более подробно описали в своей статье наши коллеги из Group-IB.

Таким образом, просто так обнаружить процесс, в котором запущено ВПО, не получится. Детектировать эти вещи можно только через анализ списка монтирований.

В некоторых случаях злоумышленники использовали крайне интересную технику запуска и закрепления через модификацию существующих сервисов. Она описана в этой статье (пункт 5.8). 

Атакующие подкладывали ВПО как .so-библиотеку в систему и через механизм LD_PRELOAD подгружали его в службу. Для этого они использовали rsyslogd. Злоумышленники создали директорию rsyslog.service.d и внутри local.conf со следующим содержимым:

[Service]

Environment='LD_PRELOAD=libnsan.so'

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

Вот семплы, которые мы видели:

Список fallback-доменов вплоть до 2027 года мы дали в нашем канале.

Кроме этого, мы обнаружили еще один интересный семпл, который не мог не привлечь внимания. Он маскировался под легитимный питоновский скрипт оповещения в Telegram для Zabbix (zbxtg.py). Забрав его из зараженной системы, мы поняли, что это упакованный через UPX семпл, написанный на Go. Внутри он был обфусцирован, но мы обратили внимание на интересную деталь: в строках семпла имелось много base64-закодированного содержимого. 

Оказалось, что все эти строки расшифровываются вшитым в семпл RSA-ключом.

Теперь мы видим интересные значения:

Usage /ci
Error [%s]
Usage /token [PID]
Usage /cpri
Error [%s] Usage /kill_except
https://api.telegram.org/file/bot%s/%s
the bot is not bonded yet to a group
PASSED_HTTP_PROXY
Error [%s] Usage /kill_except
The shell was not init for [%d]
И другие.

Дополнительный анализ показал, что это бэкдор, общающийся через API Telegram. Быстрый поиск в интернете привел нас к статье коллег из Kaspersky ICS CERT. Сравнив их исследование с нашим, мы пришли к выводу, что имеем дело с Telegram-бэкдором Vasilek. 

Помимо упакованного в UPX бэкдора, мы встретили еще кастомный UPX launcher. Вот алгоритм его работы:

1. Семпл извлекает сам себя в /usr/sbin/zabbix_agentd1.

2. Дает права на исполнение "chmod +x /usr/sbin/zabbix_agentd1.

3. Создает службу, запускающую извлеченный ранее файл /etc/systemd/system/zabbix_agentd1.service. При этом служба создает свой приватный каталог tmp через PrivateTmp=yes. Зачем это нужно, станет понятно дальше.

4. Потом он дропает в директорию /tmp семпл zbxtg.py (тот самый, что был ранее описан).

5. Запускает его и удаляет.

Так мы увидели еще одну технику, которую использовали злоумышленники.

В тот же промежуток времени мы обнаружили семпл, написанный на… Rust. Проанализировав его, увидели, что это обычный chisel, который обернут в кастомный загрузчик на Rust. Однако закреплялся он через cron, чего ранее не встречалось. 

Итого на тот момент у нас был и аргумент за то, что этот экземпляр принадлежит той же группировке (собственный обфускатор), и аргументы против (Rust, закрепление).

Атрибуция

Исходя из технического анализа, данных Kaspersky Lab и наших исследований, можно отнести эту активность к группировке Cyberpartisans-BY, которая в последнее время получила медийную известность благодаря тому, что взяла на себя ответственность за атаки на некоторые крупные российские компании. Помимо бэкдора Vasilek, мы увидели еще один сложный бэкдор, функционирующий через DNS-туннели. В отчете коллег из Kaspersky фигурирует описание похожего семпла под именем PartisanDNS.

Эволюция инструментария известных акторов

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

Найденное нами ВПО представляет собой полноценный бэкдор, способный выполнять команды на целевом хосте Linux и строить цепочки прокси-подключений. Он написан на Go, имена типов и структуры данных в блоке main обфусцированы.

ВПО содержит конфигурацию, которая зашифрована с помощью xor на ключе в 8 байт, а тот зашит в начале зашифрованного сегмента памяти с конфигом, который сериализован в json. Конфигурация содержит следующие поля:

• M: режим работы ВПО. Если равно 2 — это клиент, если другое значение — ВПО начинает слушать как TLS-сервер, а после успешного подключения становится снова клиентом

• Pl — интервал между вызовами c2_dispatcher

• Pto — неизвестно

• T — реквизиты C2-сервера

• RI — интервал keepalive

• Rd — неизвестно

• С — неизвестно

• P — неизвестно

• Ch — неизвестно

• Ml — mutual tls аутентификация

• Ay — ключ шифрования AES для создания туннеля

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

Общий алгоритм работы выглядит следующим образом:

1. Считывание реквизитов C2, ключа AES и других параметров из конфига.

2. Определение режима работы ВПО: если mode = 2, семпл сразу переходит в режим клиента. При других значениях он запускает TLS-сервер на адресе зараженного сервера, ожидает подключения извне по TLS и после переходит в режим клиента с подключившимся хостом. При подключении используется mutual TLS.

3. В бесконечном цикле проверяется подключение по TLS к C2.

4. Если подключения нет, семпл спит и ждет timeout из параметра Pl. Если оно есть, строит внутри TLS-сессии зашифрованный AES-канал с ключом из конфига. При этом такой же механизм переподключения использует существующий канал, если он долгое время бездействовал.

5. Заходит в основной диспетчер подключений, выполняет полученную команду по протоколу и ждет, — интервал опроса составляет 30 секунд.

6. Возвращается на третий шаг.

Возможности ВПО

1. Выполнение shell-команд с помощью оболочки /bin/sh.

2. Соединение с socks5-прокси и организация «цепочки» между С2-сервером и socks5-peer.

3. Установление нескольких сессий и с C2, и с socks5-прокси-серверами.

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

Протокол взаимодействия

Принимаемые от C2 данные (после расшифрования TLS+AES):

• первые два байта — размер данных;

• третий байт — команда C2;

• далее идут данные (не более 4062 байт).

Отправляемые на C2 данные:

• opcode ответа — 2 байта;

• id сессии — 2 байта;

• до 4062 байт данных.

Команды C2

Протокол обработки команды на установления соединения с прокси-сервером (opcode 2,8)

Структура пакета (после первого байта команды):

• первый байт — 05 — версия socks5;

• второй байт — метод аутентификации socks;

• третий байт — адрес сервера:

  • 01 — ipv4:port

  • 03 — domain:port

  • 04 — ipv6:port

• после этого идут данные в соответствии с третьим байтом: 

  • для 1 — 6 байт;

  • для 3 — длина домена+2 байта порта;

  • для 4 — 18 байт.

Далее происходит вызов socks peer через Net.Dial. Если соединение успешно, на C2 улетает валидный socks-ответ 0x0500.

Отправка данных

У семпла есть два варианта: отправить служебные данные или информацию.

Для отправки данных реализован метод (*TunnelStruct).Write. Структура пакета следующая:

• 2 байта opcode;

• 2 байта id-сессии;

• до 4062 байт данных.

Для отправки служебных данных реализован отдельный метод (*TunnelStruct).WriteRandomPacket, который внутри вызывает тот же (*TunnelStruct).Write, но немного изменяет структуру пакета. 

Структура отправляемого пакета:

• 2 байта opcode;

• 2 байта id-сессии;

• до 154 байт рандомных данных.

Опкоды при отправке данных на C2

Статусы сессий

Samples

А теперь самое интересное: пытливый читатель может вспомнить, что в начале статьи уже фигурировал домен ignorelist.com. Кроме того, оба домена, которые мы видели в этих семплах, тоже упираются в регистратор afraid.org. 

Помимо этого, у нас есть поведенческие паттерны, мы фиксировали их и в 2024-м, и в 2025 году. В совокупности все это позволяет предположить, что группировка, размещающая reverse-socks5 в начале заражения, никуда не ушла и все это время присутствовала в инфраструктуре жертвы — в отличие от других акторов, которые либо перестали действовать (GOFFEE), либо пришли позже (Cyberpartisans-BY).  

Общие выводы

Пример этой долгой, целенаправленной и сложной по своей структуре атаки показал несколько вещей:

1. Известные с 2022 года группировки активно передают «коллегам»  доступы в инфраструктуры жертв и работают сообща.

2. Методы людей «по ту сторону баррикад» достаточно разнообразны. При этом хватает как известных утилит и небольших оберток над ними, так и своих сложных инструментов.

3. Сила отечественного ИБ-сообщества позволяет эффективно определять субъектов атак. Призываем всех игроков обмениваться информацией чаще и больше.

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

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

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