APT StingyBasilisk: понеслась malware по трубам

В начале 2026 года команда расследования и реагирования на инциденты (PT ESC IR) обнаружила сложную угрозу, исходящую от группировки, которую мы назвали StingyBasilisk и которая активна как минимум с апреля 2022 года. Злоумышленники продолжительное время удерживали контроль над скомпрометированной инфраструктурой, действуя скрытно и маскируясь под легитимные средства защиты, применяемые организацией.

Исходный вектор заражения установить не удалось, но мы выявили развернутую сеть собственных агентов злоумышленника, управление которыми осуществлялось через именованные каналы Windows. APT-группировка StingyBasilisk применяла широкий набор техник сокрытия присутствия, что позволяет предположить шпионаж в качестве конечной цели атаки. Для закрепления на скомпрометированных хостах использовались COM Hijacking (для запуска SilentCOM) и Time Providers (для обеспечения персистентности TediousLoader). Перемещение внутри периметра выполнялось с использованием протокола SMB, а удаленный запуск — с помощью планировщика заданий Windows. Именно так с февраля 2026 года StingyBasilisk доставляла загрузчик CunningDoor. Все обнаруженные образцы ВПО представляли собой DLL-библиотеки, задача которых состояла в ожидании и исполнении полезной нагрузки в памяти процесса Windows.

Мы предполагаем, что в арсенале злоумышленников есть собственный C2-фреймворк, в котором полезная нагрузка представляет собой шелл-код, существующий только в памяти Windows. В качестве средства управления при этом может использоваться как именованный канал (named pipe), так и сетевое соединение с любым адресом. APT-группировка StingyBasilisk также использует технику нативного захвата сырых сокетов Windows для анализа сетевого трафика на скомпрометированном хосте с целью получения адресов C2-серверов. Из-за активного применения именованных каналов для управления и сложности обнаружения полезной нагрузки группировка и получила свое название.

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

Перемещение внутри периметра

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

Для доставки вредоносного ПО на целевые хосты использовался протокол SMB: файлы загружались в C:WindowsTemp. Для запуска применялся инструмент atexec из набора Impacket (удаленное выполнение команд с помощью планировщика заданий Windows). Инструмент подключался к целевому хосту по протоколу SMB и открывал именованный канал pipeatsvc, после чего через MS-RPC создавал задачу и сразу запускал ее. Старт задачи выполнялся с помощью метода SchRpcRun (Opnum 12) интерфейса ITaskSchedulerService с передачей аргументов. Во всех обнаруженных случаях имя задачи соответствовало паттерну [0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12} и отличалось от стандартного, используемого в скрипте Impacket.

{ "Event": { "EventData": { "Name": "TaskRegisteredEvent", "TaskName": "\11BBA9EF-3528-C48C-2221-D0D4DD92D971", "UserContext": "[REDACTED]" }, "System": { "Channel": "Microsoft-Windows-TaskScheduler/Operational", "Computer": "[REDACTED]", "Correlation": { "ActivityID": "9F2B3873-3333-0000-C834-338FB383D123" }, "EventID": "106", "EventRecordID": "104611", "Execution": { "ProcessID": "916", "ThreadID": "6132" }, "Keywords": "0x8000000000000000", "Level": "4", "Opcode": "0", "Provider": { "Guid": "DE7B24EA-73C8-4A09-985D-5BDADCFA9017", "Name": "Microsoft-Windows-TaskScheduler" }, "Security": { "UserID": "S-1-5-18" }, "Task": "106", "TimeCreated": { "SystemTime": "2026-02-12T13:38:28.7233228Z" }, "Version": "0" } }}

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

{ "Event": { "EventData": { "CommandLine": "C:\Windows\System32\rundll32.exe IKEYUI64.dll,ikeyUI_DlgSelectDeviceA", "NewProcessId": "0x00003008", "NewProcessName": "C:\Windows\System32\rundll32.exe", "ProcessId": "0x00000394", "SubjectDomainName": "[REDACTED]", "SubjectLogonId": "0x000003e7", "SubjectUserName": "[REDACTED]", "SubjectUserSid": "S-1-5-18", "TokenElevationType": "%%1936" }, "System": { "Channel": "Security", "Computer": "[REDACTED]", "Correlation": {}, "EventID": "4688", "EventRecordID": "28348842", "Execution": { "ProcessID": "4", "ThreadID": "10332" }, "Keywords": "0x8020000000000000", "Level": "0", "Opcode": "0", "Provider": { "Guid": "54849625-5478-4994-A5BA-3E3B0328C30D", "Name": "Microsoft-Windows-Security-Auditing" }, "Security": {}, "Task": "13312", "TimeCreated": { "SystemTime": "2026-02-12T13:38:28.8346135Z" }, "Version": "1" } }}

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

Закрепление

Для сохранения постоянства на скомпрометированных Windows-хостах злоумышленники использовали достаточно редко встречающиеся техники Component Object Model Hijacking и Time Providers.

COM Hijacking

Злоумышленники применили COM Hijacking, выбрав в качестве цели следующие COM-объекты:

1. Network List Manager с идентификатором {DCB00C01-570F-4A9B-8D69-199FDBA5723B}. Этот объект отвечает за управление сетевыми профилями и активно используется системными службами и приложениями, обращения к нему происходят при старте ОС, смене сетевого подключения и запуске сетевой диагностики.

2. Network Configuration с идентификатором {5b035261-40f9-11d1-aaec-00805fc1270e}. Используется операционной системой и сторонним софтом для настройки сетевых адаптеров.

Техника реализована через манипуляцию веткой реестра TreatAs, изначально предназначенной для обеспечения совместимости COM-объектов. Атакующие модифицировали раздел HKLMSoftwareClassesCLSID{DCB00C01-570F-4A9B-8D69-199FDBA5723B}TreatAs, прописав в значении по умолчанию CLSID собственного вредоносного COM-объекта. В результате при обращении любого процесса к Network List Manager или Network Configuration система прозрачно перенаправляла вызов и загружала вредоносную DLL-библиотеку, размещенную, к примеру, по пути %systemroot%system32netprofmprox.dll (имя почти повторяет имя оригинальной библиотеки netprofm.dll).

Ниже представлен пример перенаправления вызова COM-объекта (данные взяты из модуля инвентаризации COM-объектов утилиты PT Dumper):

{ "TimeLine": "2023-04-06T08:23:10Z", "OriginalCOM": { "TimeLine": "2023-04-06T08:23:10Z", "ModuleName": "", "CLSID": "{DCB00C01-570F-4A9B-8D69-199FDBA5723B}", "HivePath": "Windows\System32\Config\SOFTWARE:Classes\CLSID", "Description": "NetworkListManager", "TypeLib": "{DCB00D01-570F-4A9B-8D69-199FDBA5723B}", "Version": "1.0", "Treat": true, "TreatAs": "{EDC98819-728F-4166-9E89-EFAFE7855300}" }, "TreatCOM": [ { "TimeLine": "2023-04-06T08:22:59Z", "ModuleName": "", "CLSID": "{EDC98819-728F-4166-9E89-EFAFE7855300}", "HivePath": "Windows\System32\Config\SOFTWARE:Classes\CLSID", "Description": "Network Configuration Component Object", "Treat": false, "COMServers": [ { "Type": "InprocServer32", "FilePath": "%systemroot%\system32\netprofmprox.dll", "ThreadingModel": "Both" } ] } ]}

Для сохранения скрытности подмененная библиотека netprofmprox.dll выступает в роли полноценного COM-сервера: экспортирует DllGetClassObject(), DllCanUnloadNow(), DllRegisterServer() и DllUnregisterServer(), а фабрика классов создает объекты с ожидаемыми интерфейсами (включая INetworkListManager). Это позволяет избежать аварийных завершений вызывающих процессов и не демаскировать присутствие вредоносного кода.

Time Providers

Служба времени Windows (W32Time) при каждом запуске системы автоматически загружает библиотеки, зарегистрированные в ветке реестра HKLMSYSTEMCurrentControlSetServicesW32TimeTimeProviders. Атакующие создавали в этом разделе собственного поставщика, указывая в параметре DllName путь к вредоносной DLL-библиотеке, и задавали значение Enabled = 1.

В результате при старте ОС служба W32Time загружала указанную библиотеку в контексте процесса svchost.exe, запущенного от имени Local System, что обеспечивало надежное и скрытное закрепление.

Вывод модуля автозагрузки PT Dumper:

{ "Content": "ControlSet001\Services\W32Time\TimeProviders\HyperV\DllName: c:\windows\system32\wgtdgr.dll", "Hive": "SYSTEM", "KeyName": "ControlSet001\Services\W32Time\TimeProviders\HyperV", "TimeLine": "2025-12-16T17:08:53Z", "UserName": "", "ValueData": "c:\windows\system32\wgtdgr.dll", "ValueName": "DllName",}

Для успешной загрузки библиотека должна экспортировать функцию TimeProvOpen(), которую W32Time вызывает при инициализации провайдера. Эта функция служит точкой входа и должна соответствовать сигнатуре, ожидаемой службой времени. Как правило, именно из нее злоумышленники запускают основную полезную нагрузку.

TediousLoader

Вредоносный код динамической библиотеки, закрепленной в TimeProviders, реализован в функции экспорта TimeProvOpen. Это функция обратного вызова, которую запускает диспетчер поставщика времени в момент загрузки DLL-библиотеки службой W32Time.

В этой DLL реализована техника перехвата сетевого трафика через Winsock API, использующая встроенные возможности операционной системы Windows и не требующая сторонних библиотек. ВПО слушает все сетевые интерфейсы и просматривает входящие IP-пакеты, опознает замаскированную в полезной нагрузке команду по магической сигнатуре, по ее полям настраивает сетевой канал (connect, bind, listen), а затем принимает по нему внешний код, расшифровывает его и запускает в отдельном потоке.

Для установки слушателя сырых данных на сетевом интерфейсе запускается следующая последовательность действий:

• Получение списка всех сетевых адаптеров (Ethernet, Wi-Fi, VPN и т. д.) с помощью функции GetAdaptersAddresses.

• Создание raw-сокета для каждого адаптера:
  socket(AF_INET, SOCK_RAW, 0);

• Привязка сокета к первому unicast-IP-адресу адаптера (если адресов несколько, остальные игнорируются). Это позволяет перехватывать трафик, адресованный конкретному интерфейсу:
  bind(s_1, lpSockaddr, iSockaddrLength);

• Включение режима promiscuous mode и перевод сокета в неблокирующий режим:
  WSAIoctl(s, 0x98000001, &vInBuffer, 4u, 0, 0, &cbBytesReturned, 0, 0);
  ioctlsocket(s, 0x8004667E, &argp);
  Где SIO_RCVALL = 0x98000001 включает режим приема всех пакетов, а FIONBIO = 0x8004667E устанавливает неблокирующий режим. Это ключевой момент, который позволяет перехватывать весь трафик, проходящий через адаптер.

Далее в бесконечном цикле сниффер каждые 5 секунд проверяет все открытые raw-сокеты на наличие входящих данных. Для этого формируется структура fd_set (набор файловых дескрипторов), в которую помещаются все уникальные сокеты (до 64 штук). Функция select() блокирует выполнение программы максимум на 5 секунд, ожидая, пока хотя бы на одном из сокетов появятся данные для чтения; после ее возврата набор readfds модифицируется — в нем остаются только те сокеты, которые реально готовы к чтению. Далее код перебирает все сокеты из набора и для каждого проверяет макросом _WSAFDIsSet(*k, &readfds), был ли он отмечен как готовый. Если да — вызывает recv(*k, buf, 256, 0), который считывает до 256 байт сырого IP-пакета (включая IP-заголовок и часть полезной нагрузки) в буфер buf и затем передает эти данные и их длину в функцию обработчика для дальнейшего разбора.

Рисунок 1. Чтение 256 байт данных IP-пакета

Обработчик в функции Handler фильтрует и предварительно анализирует перехваченные IP-пакеты:

• Проверяет, что пакет — валидный нефрагментированным IPv4 длиной до 256 байт.

• Определяет протокол (ICMP, TCP или UDP) и вычисляет смещение полезной нагрузки после соответствующего заголовка.

• Сканирует payload в поисках 8-байтовой магической сигнатуры (вычисляемой как разность двух 64-битных значений на расстоянии 24 байт).

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

• При обнаружении нового уникального пакета передает указатель на найденную позицию в функцию HandlerPayload для дальнейшего разбора.

Во всех обнаруженных DLL-библиотеках значение 8-байтовой магической сигнатуры было различным.

Рисунок 2. Обработчик IP-пакета

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

Рисунок 3. Обработчик полезной нагрузки

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

Смещение относительно buf[pos]

Размер (в байтах)

Роль

0

8

Ключ деобфускации конфигурации, участвует в расчете magic-разности

8

16

Обфусцированная конфигурация сокета

24

8

Только для проверки magic-разности

Функция SettingSocket принимает 16-байтовую структуру деобфусцированной конфигурации, создает TCP-сокет (AF_INET / SOCK_STREAM) в зависимости от режима, указанного в конфигурации.

Режим задается битовой маской в байте 0:

• connect (бит 0) — активное подключение к адресу и порту из конфигурации;

• listen, accept (бит 1) — пассивное ожидание входящего подключения с тайм-аутом;

• bind (бит 2) — привязка к локальному адресу и порту.

При успехе сокет сохраняется через указатель a2, функция возвращает 1, иначе — 0.

Структура данных конфигурации представлена в таблице ниже.

Смещение

Размер (в байтах)

Поле

Описание

0

1

mode

Бит 0 = connect, бит 1 = listen, accept, бит 2 = bind

1

1

reserved

Не используется

2

1

delay

Период задержки (delay × 100 мс)

3

1

timeout

Тайм-аут select: сек = t/10, мкс = (t%10) × 100 000

4–7

4

conn_addr

IP-адрес для режима connect

8–9

2

conn_port

Порт для режима connect

10–13

4

bind_addr

IP-адрес для режима bind

14–15

2

bind_port

Порт для режима bind

После успешного соединения в одном из режимов, указанных выше, принимается полезная нагрузка, которая расшифровывается алгоритмом AES-256 в режиме CBC и исполняется в памяти процесса.

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

CunningDoor

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

В первом случае использовалась легитимная DLL-библиотека IKEYUI64.dll, которая запускала вредоносную библиотеку iKeyAPI.dll с помощью команды rundll32.exe IKEYUI64.dll, ikeyUI_DlgSelectDeviceA.

Функция экспорта ikeyUI_DlgSelectDeviceA последовательно запускала экпортируемые функции из iKeyAPI.dll: ikey_CreateContext, ikey_OpenDevice, ikey_DeleteContext.

Библиотека iKeyAPI.dll расшифровывала шелл-код, содержащийся в файле C:WindowsTempoluivzdz, тремя последовательными операциями XOR, где первый ключ статически определен в iKeyAPI.dll, второй — в файле C:WindowsTempsqlslzgqpukrpd, третий — первые 32 байта файла oluivzdz.

Затем управление переходило к расшифрованному шелл-коду, который динамически находил адреса требуемых Windows API, используя хеширование имен функций по модифицированному алгоритму FNV-1a.

Рисунок 4. Алгоритм хеширования имен функций

После успешного разыменования необходимых функций расшифровывалась конфигурация, в которой указан адрес C2-сервера. В примере ниже указаны имя named pipe и SDDL.

Рисунок 5. Конфигурация CunningDoor

Затем вредоносный шелл-код прослушивал созданный именованный канал и ожидал полезную нагрузку. Формат данных следующий:

• 16 байт — вектор инициализации для AES-256-CBC;

• 16 байт — MD5-сумма полезных данных;

• 4 байта — длина полезных данных;

• полезные данные — шелл-код.

Ключ для расшифровки полезной нагрузки задан статически в шелл-коде.

Во всех обнаруженных DLL CunningDoor, которые используют этот метод взаимодействия с C2-сервером, имя именованного канала задавалось по шаблону .pipe[a-z]+.[a-f0-9]{8}.

В другом случае на хост доставлялась легитимная библиотека eToken.dll с цифровой подписью SafeNet, которая запускала вредоносную DLPReel.dll. Вся логика реализована в экспортируемой функции REEL_Initialize.

Функциональность этой DLL такая же: расшифровывает шелл-код и передает управление на него. Различие — в конфигурации, где указаны IP-адрес и порт.

Рисунок 6. Конфигурация с IP-адресом в качестве C2-сервера

SilentCOM

Это семейство ВПО было обнаружено в реализации двух DLL-библиотек: netcfgprox.dll — COM Hijacking компонента Network Configuration, netprogmprox.dll — COM Hijacking компонента Network List Manager. Обе библиотеки являются COM-сервером и экспортируют стандартные функции: DllCanUnloadNow, DllGetClassObject, DllRegisterServer, DllUnregisterServer.

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

• Сначала выполняется обращение к реестру CLSID{идентификатор COM Hijacking}InProcServer32 для получения пути к легитимной библиотеке целевого COM-объекта. Вредоносная DLL считывает этот путь и динамически загружает оригинальную библиотеку в свое адресное пространство.

• После успешной загрузки легитимной DLL (например, netprofm.dll) вредоносная библиотека получает адреса ее экспортируемых COM-функций. Ключевой среди них является DllGetClassObject, отвечающая за создание фабрики классов запрошенного COM-объекта.

• При получении системного вызова, адресованного Network List Manager или Network Configuration, вредоносная библиотека проверяет переданные параметры и перенаправляет вызов оригинальной DllGetClassObject из легитимной библиотеки, передавая ей те же аргументы (IID класса, IID интерфейса и указатель на объект).

После успешного получения адресов экспортируемых функций легитимной библиотеки ВПО проверяет контекст запуска: командная строка процесса должна совпадать с svchost.exe -k netsvcs, в противном случае он принудительно завершается.

Далее расшифровывается конфигурация DLL, в которой содержится имя канала. К примеру, \.pipe4120e81-9a1a-4aca-97fb-a40da6acd500 и SDDL (Security Descriptor Definition Language) D: (A; GA;;; WD)S: (ML;;;;; S-1-16-0). Во всех обнаруженных DLL-библиотеках имя созданного именованного канала Windows соответствовало шаблону \.pipe[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}.

Основная задача вредоносного COM-объекта — ожидать поступления полезной нагрузки из именованного канала. Формат передаваемых данных следующий:

• 16 байт — вектор инициализации для алгоритма расшифрования AES-192-CBC;

• 3 байта — длина шелл-кода;

• полезная нагрузка.

Шелл-код SilentCOM

В ходе реагирования на инцидент специалисты PT ESC IR проводили мониторинг сетевого трафика с фильтрацией данных, передаваемых по именованным каналам Windows. Особое внимание уделялось каналам, чьи имена соответствовали регулярным выражениям, характерным для загрузчика SilentCOM и вредоносного ПО CunningDoor. В результате мониторинга удалось зафиксировать передачу полезной нагрузки и расшифровать шелл-код.

Рисунок 7. Шелл-код, отправленный в именованный канал

Из рисунка выше можно увидеть, что в выделенный текст включает: 16 байт — вектор инициализации, 3 байта — длина полезных данных, полезные данные.

Шелл-код содержит в себе загрузчик, который расшифровывает основную нагрузку и исполняет ее в контексте текущего процесса. Загрузчик использует технику прямых системных вызовов (direct system calls), обращаясь к нативным функциям в обход API: NtAllocateVirtualMemory — для выделения памяти, LdrLoadDll — для загрузки библиотек, LdrGetProcedureAddress — для получения адресов функций, NtProtectVirtualMemory — для изменения прав доступа к памяти, LdrUnloadDll — для выгрузки библиотек, NtFreeVirtualMemory — для освобождения выделенной памяти.

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

Генерация сессионного ключа разделена на два этапа. Сначала создаются два 32-байтовых значения (x_key, y_key), выполняющие роль приватных ключей агента. Для обмена сессионными ключами применяется протокол ECDH (Диффи — Хеллмана на эллиптической кривой Curve25519 с базовой точкой, равной 9).

Рисунок 8. Генерация общего сессионного ключа для ChaCha20

Алгоритм генерации сессионного ключа:

• Вычисляется публичный ключ клиента как произведение G × x_key и отправляется в именованный канал.

• Формируется сессионный ключ по формуле PublicKey_Server × x_key. Публичный ключ сервера задан статически и в одном из образцов имел значение DD 2B 6E 28 27 12 50 2D 3C 36 B6 FE C8 B2 B9 56 1B C9 CE A9 45 86 80 3C 88 9E C9 21 4B CF AC 06. При этом в обнаруженных полезных нагрузках значение публичного ключа сервера различалось.

• Генерируется один блок ChaCha20 объемом 64 байта. Из полученного блока извлекаются первые и последние 16 байт состояния ChaCha20.

• На основе данных, полученных на предыдущем шаге, формируется контекст шифрования ChaCha20. Содержащийся в нем ключ в дальнейшем используется для шифрования трафика между клиентом и сервером по именованному каналу. Константные значения для инициализации контекста ChaCha20 модифицированы и соответствуют 71 20 2F 78 48 3F D9 14 48 B0 13 DA 02 32 46 88.

Рисунок 9. Инициализация ключа ChaCha20

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

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

Важным индикатором, позволяющим обнаружить эту полезную нагрузку исключительно в памяти процессов Windows, является измененная константа контекста генерации ключа ChaСha20 71 20 2F 78 48 3F D9 14 48 B0 13 DA 02 32 46 88.

HenMapCaCon

Динамическая библиотека HenMapCaCon.dll написана на Go версии 1.18–1.19. Сборка выполнена с использованием механизма cgo, что обеспечивает совместимость с C-интерфейсом. Для усложнения анализа применена техника Stripping — удаление имен Go-функций из структуры pclntab. Стоит отметить, что сама по себе сборка DLL из Go-кода на практике встречается достаточно редко.

Основной вредоносный код реализован в экспортируемой функции StoreMini, которая создает TLS-сервер поверх именованного канала с использованием библиотеки go-winio. В процессе работы формируется канал с именем \.PIPEProProBitOpen и SDDL вида D:NO_ACCESS_CONTROL S:(ML;;;;;S-1-16-0), которое является дефолтным значением безопасности в go-winio. Эта строка устанавливает мандатный уровень целостности, запрещающий доступ к каналу процессам с недоверенным уровнем целостности (untrusted integrity level, S-1-16-0), при этом разрешая взаимодействие всем остальным процессам с более высокими привилегиями (Low, Medium, High, System).

При обращении к маршруту /qr с параметром s, содержащим данные для кодирования, сервер возвращает HTML-шаблон простого генератора QR-кодов. Страница отображает QR-изображение, сформированное с помощью внешнего сервиса Google Chart API (chart.apis.google.com), а также текстовое представление закодированной строки. Форма на странице позволяет ввести текст длиной до 1024 символов и отправить GET-запрос на корневой адрес /.

{{if .}}
{{.}}

{{end}}

Отдельного внимания заслуживает конечная точка /fetch, предназначенная для выгрузки файлов из скомпрометированной системы. Она принимает два параметра: key — значение ключа для прохождения верификации (в образце используется значение qzYMRSSTiWXZzuZxsSjlKiuXJCaNrsZVyZAYAKvCchfBzgpLSSZjEr), path — полный путь к запрашиваемому файлу.

Заключение

Группировка StingyBasilisk представляет собой одну из наиболее сложных угроз, с которыми мы столкнулись в начале 2026 года. Для закрепления в системе злоумышленники применяли COM Hijacking с подменой легитимных компонентов Network List Manager и Network Configuration, причем вредоносные DLL-библиотеки были реализованы с поддержкой COM-проксирования для сохранения стабильности работы системных служб. Дополнительно использовался механизм Time Providers.

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

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

(Индикаторы компрометации, список хакерских техник из матрицы MITRE ATT&CK и вердикты продуктов Positive Technologies можно посмотреть в полной версии исследования).

Даниил Григорян

Ведущий специалист департамента комплексного реагирования на инциденты

Источник: habr.com