Koadic: постэксплуатационный фреймворк на Windows Script Host и его ботнет-инфраструктура

Семейство: Koadic
Класс: ботнет-вредонос
Раздел: Ботнеты
Основание публикации: свежие наблюдения не старше 5 дней
Первое наблюдение в текущем наборе: 27.08.2026 10:56
Последнее наблюдение в текущем наборе: 27.08.2026 11:50
Образцов в пакете: 1; IOC: 1

Поведение, распространение и защита​


Что делает

Koadic (COM Command & Control) — открытый постэксплуатационный фреймворк, предназначенный для удалённого управления скомпрометированными хостами Windows. В отличие от классических бинарных троянов, его полезная нагрузка исполняется средствами самой операционной системы: интерпретаторами Windows Script Host (wscript.exe / cscript.exe), механизмами COM-автоматизации и встроенными утилитами. Это позволяет обходить контроль исполнения неподписанных PE-файлов и затрудняет детектирование по сигнатурам исполняемых модулей.

Фреймворк построен по модели «сервер управления — агент на жертве». Оператор разворачивает C2-сервер (как правило, на Linux-хосте), который раздаёт скриптовые стабы и принимает результаты. Агент на стороне Windows выполняет JScript/VBScript-код, загружаемый через COM-объекты (WScript.Shell, MSXML2.XMLHTTP, ADODB.Stream и аналогичные). Сетевое взаимодействие реализуется через HTTP/HTTPS-запросы к управляющему узлу; в текущей телеметрии зафиксирован индикатор типа ip:port с категорией botnet_cc, что указывает на прямое TCP-соединение с C2 без доменного имени.

Функциональные возможности фреймворка на уровне семейства включают:

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

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

Антианализ на уровне семейства сводится преимущественно к fileless-исполнению: на диске может не оставаться бинарного вредоносного файла, а весь код существует в памяти процессов-хостов. Это усложняет традиционное антивирусное сканирование и требует обращения к журналам скриптовых движков и телеметрии EDR.

Технический разбор образцов

Образец 1

Единственный образец в текущем пакете обладает крайне ограниченным набором метаданных:

  • Сигнатура на платформе сбора: «Koadic». Образец классифицирован по признаку, связанному с данным семейством, однако конкретный метод классификации (статический анализ, динамическая песочница, сетевой трафик) в метаданных не раскрыт.
  • Формат файла, MIME-тип, архитектура и размер не зафиксированы. Это согласуется с fileless-природой фреймворка: распространяемый артефакт может представлять собой скриптовый фрагмент, URL-загрузчик или сетевой индикатор, а не традиционный исполняемый файл.
  • Теги, YARA-правила, данные vendor intelligence и дополнительная файловая информация отсутствуют. Поведенческие детали (конкретные API, целевые приложения, методы эксфильтрации) из метаданных извлечь невозможно.
  • Способ доставки не указан.
  • Связанный IOC в базе индикаторов классифицирован как ip:port с типом активности botnet_cc. Это подтверждает, что наблюдаемая инфраструктура функционирует как узел управления ботнетом, принимающий соединения от агентов на заражённых хостах.
  • Дата первой регистрации — конец августа 2026 года; источник — MalwareBazaar.

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

Как распространяется

Для текущего образца метод доставки не подтверждён: поле delivery_method пусто, теги и дополнительные метаданные не содержат информации о векторе начального доступа.

На уровне семейства Koadic как открытый фреймворк не имеет собственного фиксированного канала распространения. Операторы могут доставлять начальный стаб любым удобным способом: фишинговые документы с макросами, запуск через PowerShell или WMI, эксплуатация уязвимостей веб-приложений, использование других загрузчиков. В публичных отчётах фиксировались случаи, когда скриптовые стабы Koadic загружались через вредоносные документы Office и через команды в уже скомпрометированных сессиях других RAT. Ни один из этих каналов не подтверждён для текущего наблюдения.

Как обнаружить

  1. Мониторинг порождения процессов: wscript.exe или cscript.exe, запущенные из нестандартных родительских процессов (офисные приложения, браузеры, службы), либо с аргументами, содержащими сетевые адреса.
  2. Контроль COM-активации: подозрительные вызовы объектов MSXML2.XMLHTTP, ADODB.Stream, WScript.Shell из процессов, не связанных с разработкой или администрированием.
  3. Сетевая телеметрия: исходящие HTTP/HTTPS-соединения или прямые TCP-подключения к нестандартным портам без доменного имени (паттерн ip:port), особенно с периодическими запросами малых объёмов, характерными для polling-модели C2.
  4. Журналы Windows Script Host: включение логирования JScript/VBScript через реестр позволяет фиксировать исполняемый код скриптовых агентов.
  5. WMI-активность: отслеживание создания потребителей событий (__EventConsumer) и подписок (__FilterToConsumerBinding), которые могут использоваться для закрепления.
  6. Поведенческие правила EDR: алерты на последовательность «офисный процесс → wscript/cscript → сетевое соединение → доступ к LSASS или хранилищам браузера».
  7. Проверка ключей автозагрузки (HKCU и HKLM ветви Run) и задач планировщика на наличие ссылок на скриптовые файлы или mshta/wscript.
  8. Сетевые IDS/IPS: сигнатуры на характерные HTTP-заголовки или структуру URI, используемые фреймворком для обмена с C2 (конкретные паттерны зависят от версии и конфигурации сервера).

Что делать при заражении

  1. Немедленно изолировать хост от сети (физически или через порт коммутатора), чтобы разорвать сессию с C2 и предотвратить латеральное перемещение.
  2. Сохранить оперативную телеметрию: дамп списка процессов, активные сетевые соединения, журналы событий безопасности и WMI, содержимое временных каталогов и кэшей браузеров.
  3. Проверить наличие закрепления: ключи Run, задачи планировщика, WMI-подписки, службы, ярлыки в папке автозагрузки. Удалить подтверждённые артефакты.
  4. Оценить компрометацию учётных данных: если агент имел доступ к памяти LSASS или хранилищам браузера, считать все пароли, токены и сессионные cookie данного пользователя скомпрометированными.
  5. Провести ротацию секретов: пароли доменных и локальных учётных записей, API-ключи, токены облачных сервисов, сертификаты, к которым хост имел доступ.
  6. Проверить соседние узлы и контроллеры домена на признаки латерального перемещения (WMI-вызовы, DCOM-активация, удалённое создание процессов) с данного хоста за период с момента предполагаемого заражения.
  7. Если целостность системы не может быть подтверждена (нет полной телеметрии, обнаружены следы инъекций в системные процессы), выполнить чистую переустановку ОС с восстановлением данных из проверенной резервной копии.
  8. После восстановления усилить мониторинг данного сегмента сети на предмет повторного появления аналогичных C2-паттернов.

Как снизить риск

  1. Ограничить исполнение Windows Script Host: через AppLocker или WDAC запретить wscript.exe и cscript.exe для пользователей, не нуждающихся в них; альтернативно — ограничить регистрацию COM-объектов скриптовых движков.
  2. Контролировать порождение процессов из офисных приложений и браузеров: блокировать запуск wscript, cscript, mshta, powershell дочерними процессами Word, Excel, Outlook через правила ASR (Attack Surface Reduction) в Microsoft Defender.
  3. Включить расширенное логирование: аудит создания процессов (событие 4688) с командной строкой, журналы WMI-активности, логирование скриптовых движков.
  4. Сегментировать сеть и ограничить исходящие соединения рабочих станций: запретить прямые TCP-подключения к произвольным портам вне корпоративных прокси, что блокирует паттерн ip:port, наблюдаемый в текущей инфраструктуре.
  5. Применять принцип наименьших привилегий: ограничить права локальных администраторов, чтобы затруднить повышение привилегий и доступ к памяти системных процессов.
  6. Развернуть правила EDR/SIEM, детектирующие последовательности COM-активации с последующим сетевым обращением из нетипичных процессов.
  7. Регулярно проверять и очищать WMI-репозиторий от несанкционированных подписок событий на критичных серверах и рабочих станциях.

Скачать образцы​


Скачать образцы можно здесь:

Просмотр скрытого контента доступен зарегистрированным пользователям!


Источники​


  1. MalwareBazaar — Koadic
  2. ThreatFox — IOC Koadic
  3. Malpedia — Koadic

История обновлений статьи​


  • 27.08.2026 — Опубликована первая версия материала.
 
Назад
Верх Низ