Benthic: шесть способов исказить картину Windows

Классификация без подмены понятий

Benthic в исследованном дереве — драйверный rootkit. Его основная точка сборки поведения находится в CustomDriverEntry, а не в EFI entrypoint. Драйвер создаёт управляющий объект, подключает обработчики IRP, клавиатурный фильтр, NSI, WFP и minifilter. Эта архитектура предполагает уже полученное исполнение в ядре. Само её наличие не демонстрирует первоначальное проникновение, обход Secure Boot или запись в SPI flash. E10

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

DKOM: исчезновение из списка не равно исчезновению процесса

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

Отсюда следует защитная гипотеза cross-view: объекты, потоки, дескрипторы и сетевые следы могут описывать активность, которой нет в одном перечислении процессов. Но два приложения, использующие один и тот же источник перечисления, не дают два независимых вида. Для проверки нужен другой путь получения сведений и понимание его собственной зависимости от ядра.

Фиксированные offsets делают образец чувствительным к версии структуры. В отчёте должны быть архитектура, точная сборка ОС и используемые символы. Нельзя объяснять отсутствие скрытия «сильной защитой» до исключения банального несовпадения layout. Отдельного внимания заслуживают завершение процесса и конкурентное изменение списка: сохранённая ссылка на соседа не обещает, что сосед останется жив до обратной операции.

Keyboard filter: конкретный стек и конкретный выход данных

Клавиатурный модуль присоединяется к KeyboardClass0, направляет запрос чтения ниже по стеку и устанавливает completion routine. По завершении чтения он обрабатывает KEYBOARD_INPUT_DATA при включённом флаге. В просмотренном фрагменте наблюдается отладочный вывод scan codes, а не доказанный универсальный сбор всего пользовательского ввода с доставкой на сервер. E14

Это различие имеет практический смысл. Ввод через другой стек, виртуальное устройство или иной путь нельзя автоматически включать в подтверждённый охват. Для Blue полезны состав device stack, адрес completion routine, происхождение драйвера и его время жизни. Сам фильтр ещё не означает rootkit: легитимные драйверы также располагаются в стеке устройств. Существенны назначение, авторизация установки и поведение.

NSI и WFP решают разные задачи

NSI-компонент заменяет dispatch для IRP_MJ_DEVICE_CONTROL у целевого драйвера и меняет completion routine определённого запроса. При завершении он удаляет из возвращаемого набора записи, связанные с выбранными портами. Это искажение представления о соединениях; оно не стирает пакет из внешнего сетевого датчика. В коде видны зависимости от внутреннего формата буфера и его полей. E15

WFP-компонент, напротив, принимает решение о разрешении или блокировке на основании удалённого IPv4-адреса. Здесь используется механизм классификации сетевого потока. Поэтому пропавшая строка в локальном списке и реально заблокированный connect — разные наблюдения с разными причинными цепочками. E16

Red: вопрос к эксперименту — какой именно наблюдатель перестал видеть активность. Утверждение «соединение скрыто» должно содержать источник данных, иначе его нельзя проверить.

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

WSK: HTTP-клиент ещё не завершённый C2

Просмотренная реализация WSK формирует заранее заданный HTTP GET, соединяется, отправляет запрос, получает ответ и закрывает сокет. Периодический системный поток повторяет эту операцию. В этом пути не обнаружен разбор ответа в команды с диспетчеризацией действий. Поэтому корректное описание — канал периодических запросов из ядра и заготовка для коммуникации, а не подтверждённый полноценный командный сервер. E17

Для защиты источник сетевой активности важнее рекламного названия: исходящий запрос из kernel-компонента может быть виден за пределами машины, даже когда обычное процессное объяснение неполно. Однако странное соответствие процессу без анализа стека и драйверов не позволяет приписать запрос именно Benthic.

Minifilter: фильтрация каталога и исключение для KernelMode

Файловый модуль работает на постобработке IRP_MJ_DIRECTORY_CONTROL и выбирает layout под конкретный FILE_INFORMATION_CLASS. Он сравнивает путь и имя с собственным списком, затем меняет возвращаемую последовательность записей. В начале явно исключён RequestorMode == KernelMode. Это важный пример ограниченного охвата: поведение зависит не только от имени файла, но и от типа запросившей стороны. E18

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

Управляющий интерфейс сам становится проблемой

Объект устройства создаётся с FILE_DEVICE_SECURE_OPEN. Этот флаг не является полным описанием ACL и не доказывает, кому доступен handle. Для вывода о доступности нужны security descriptor, INF и фактическая конфигурация. Одна строка IoCreateDevice не позволяет объявить интерфейс открытым всем пользователям. E11

Зато в обработчике IRP виден конкретный дефект границы буфера: ответ копируется в SystemBuffer без сравнения его длины с OutputBufferLength в этой функции. Возвращённый вложенным обработчиком status сохраняется в локальную переменную, но IoStatus.Status затем принудительно выставляется в STATUS_SUCCESS. Следовательно, результат управляющего клиента может не отражать ошибку операции. Это наблюдение по коду; эксплуатация ошибки и достижимость из непривилегированного контекста не проверялись. E12

Cleanup — часть механизма, а не приложение к нему

CustomDriverEntry подключает несколько компонентов последовательно. В ряде последующих ветвей ошибки удаляются device object и symbolic link, но в показанном пути нет симметричного отсоединения всех уже подключённых механизмов. Основной DriverUnload вызывает несколько процедур выгрузки, однако не повторяет полный список инициализации. Это повод проверять владение callback, ссылками и ресурсами в каждом частично успешном состоянии. E10

Такой rootkit может одновременно скрывать объект и ухудшать устойчивость системы. Авария не доказывает успешную защиту, а успешная загрузка не доказывает безопасный unload. В защитном исследовании стабильность, скрытность и привилегии должны измеряться отдельно.

Матрица наблюдений

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

 161  	if (Data->RequestorMode == KernelMode || Data->Iopb->MinorFunction != IRP_MN_QUERY_DIRECTORY || (Flags & FLTFL_POST_OPERATION_DRAINING))
 162  	{
 163  		return FLT_POSTOP_FINISHED_PROCESSING;
 164  	}

 163  	RtlCopyMemory(pIrp->AssociatedIrp.SystemBuffer, responseBuffer, strlen(responseBuffer) + 1);
 164  	pIrp->IoStatus.Information = strlen(responseBuffer) + 1;
 165  	pIrp->IoStatus.Status = STATUS_SUCCESS;