Пять редких техник закрепления хакеров в сети

За первые шесть месяцев 2026 года специалисты департамента комплексного реагирования на киберугрозы экспертного центра безопасности Positive Technologies (PT ESC IR) зафиксировали ряд редких техник закрепления на скомпрометированных хостах. Что за техники — рассказываем в этой статье.

Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Наша цель — рассказать о существующих уязвимостях, тактиках и техниках, которыми могут воспользоваться злоумышленники, и дать рекомендации по защите. Авторы не несут ответственности за использование кем-то информации из статьи.

Zabbix Agent — это легковесная служба сбора метрик с хоста и их передачи на сервер, штатно используемая администраторами.

Суть техники закрепления злоумышленников (например, группы PhantomCore) сводится к превращению легитимного агента в скрытый бэкдор. Они доставляют на хост собственный установщик ( zabbix.msi ) и подменяют в конфигурационном файле адрес сервера на подконтрольный C2.

Ключевые поля конфигурации для атаки:

Server= и ServerActive= задают IP или домен C2-сервера для пассивных и активных проверок;

Hostname= служит уникальным идентификатором жертвы в панели C2;

ListenPort= переназначает порт (по умолчанию 10050 ), чтобы избежать конфликта с родным агентом;

UserParameter= является ключевым элементом, позволяя регистрировать произвольные команды ОС как метрики Zabbix;

AllowKey=system.run[*] разрешает прямое выполнение команд.

Канал управления работает по нативному протоколу Zabbix (JSON поверх TCP/TLS), маскируя вредоносный трафик под легитимный мониторинг и позволяя агентам в активном режиме самостоятельно «стучаться» к C2. В рамках постэксплуатации злоумышленник через графическую оболочку Zabbix-сервера централизованно получает доступ к файлам, процессам и возможность бесшумно доставлять и запускать дополнительные скрипты на скомпрометированном хосте.

Основные признаки компрометации : внезапные исходящие соединения с нестандартными портами мониторинга ( 10050 / 10051 ) на внешние IP-адреса и наличие в конфигурационном файле агента вызовов оболочек ( cmd , sh , powershell ).

Злоумышленники применяли редкую технику закрепления через механизм TimeProvider (поставщик времени Windows), соответствующую тактике MITRE ATT&CK T1543.003 .

Суть метода заключается в том, что служба времени Windows ( W32Time ) при каждом запуске системы автоматически загружает все библиотеки, зарегистрированные в ветке реестра: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders .

Атакующие создавали в этом разделе собственного поставщика: в параметре DllName прописывали путь к вредоносной DLL , а параметру Enabled присваивали значение 1 . После перезагрузки ОС служба W32Time загружает указанную библиотеку в контексте процесса svchost.exe с привилегиями Local System , что обеспечивает скрытное и надежное закрепление в системе.

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

Для закрепления в инфраструктуре злоумышленники использовали редкую технику Component Object Model Hijacking (перехват COM-объектов).

Суть метода не в прямой подмене DLL системного сервиса (что легко обнаруживается), а в манипуляции структурой реестра Component Object Model. Атакующие создают собственный COM-объект, указывающий на вредоносную библиотеку, и перенаправляют на него вызовы доверенных системных компонентов через легитимный механизм совместимости.

Ключевым элементом атаки выступает раздел реестра TreatAs , изначально предназначенный для прозрачного перенаправления запросов с одного COM-объекта на другой. Злоумышленники находят системный CLSID , обращение к которому происходит регулярно и незаметно, и подменяют его обработку на свой объект.

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

Злоумышленники модифицируют ветку: HKLM\Software\Classes\CLSID{DCB00C01-570F-4A9B-8D69-199FDBA5723B}\TreatAs,

прописывая в значении по умолчанию CLSID своего вредоносного COM-объекта. В результате при работе с сетевыми профилями система автоматически перенаправляет вызов и загружает вредоносную DLL, размещенную по пути %systemroot%\system32\netprofmaaa.dl l (имя мимикрирует под оригинальную netprofm.dll ).

Требования к DLL: библиотека должна быть полноценным COM-сервером, реализующим все интерфейсы, ожидаемые от подменяемого объекта Network List Manager, и корректно экспортировать стандартные функции (Рисунок 2): DllGetClassObject() , DllCanUnloadNow() , DllRegisterServer() и DllUnregisterServer() .

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

Эта техника закрепления основана на перехвате DLL, загружаемой легитимной службой Windows Management Instrumentation (WMI), и в MITRE ATT&CK классифицируется как T1546.008 (Event Triggered Execution: Accessibility Features) или как частный случай DLL Hijacking.

Злоумышленники используют особенность запуска консоли WMIC ( wmic.exe ), которая является стандартным инструментом системного администрирования. При запуске WMIC пытается загрузить библиотеку wmiclnt.dll , но эта библиотека может отсутствовать в стандартной поставке Windows.

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

Атакующий размещает вредоносную wmiclnt.dll в C:\Windows\System32\wbem . Для активации может использоваться любой удобный злоумышленнику триггер — как конкретное задание в планировщике, так и перезапуск системной службы.

В первом случае создается Scheduled Task, периодически дергающий легитимную утилиту (например, wmic os get name ), что приводит к загрузке DLL и выполнению вредоносного кода в DllMain.

Во втором — применяется циклический перезапуск службы WMI командами net stop winmgmt /y и net start winmgmt , что также провоцирует обращение к подставной библиотеке и обеспечивает закрепление.

Для успешной загрузки и скрытной работы вредоносная wmiclnt.dll должна удовлетворять следующим условиям:

Функции экспорта: вредоносная DLL обязана реализовать и экспортировать все те же функции, которые пытается импортировать wmic.exe (Рисунок 3), чтобы процесс не упал с ошибкой.

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

Проксирование: для максимальной маскировки вредоносная DLL может выступать в роли «прокси», пробрасывая вызовы на реальный системный API, чтобы wmic.exe отрабатывал штатно и не вызывал подозрений.

Признаки компрометации:

=Появление файла wmiclnt.dll в директории C:\Windows\System32\wbem\ (в чистой системе этот файл отсутствует, хотя на старых версиях мог существовать; в современных Windows 10/11 и Server 20xx файл находится в директории C:\Windows\System32\ ).

Нестандартные дочерние процессы у wmic.exe (например, если из-под WMIC вдруг запускается powershell.exe или rundll32.exe с сетевым взаимодействием).

Еще одним признаком компрометации может служить событие Event ID 11 (Image Load), где поле "SignatureLevel": 1 указывает на unsigned / untrusted образ.

Systemd Generator — это исполняемый файл, который systemd запускает на этапе загрузки системы (или при выполнении daemon-reload) для динамического создания unit-файлов служб, целей и точек монтирования. Злоумышленники используют этот механизм для скрытого закрепления, поскольку генераторы выполняются с привилегиями root до запуска основных служб и редко проверяются администраторами.

Ключевые директории:

/etc/systemd/system-generators/*

/usr/local/lib/systemd/system-generators/*

/lib/systemd/system-generators/* (или /usr/lib/systemd/system-generators/ )

Механизм закрепления:

Злоумышленник помещает исполняемый файл в одну из ключевых директорий — скрипт или бинарный файл (обычно с маскирующим именем, например systemd-cp-generator ).

При каждой загрузке системы или выполнении systemctl daemon-reload — systemd запускает все найденные генераторы.

Генератор может: создать свой сервис в /run/systemd/system/ и включить его, перезаписать юниты существующих служб (особенно через /run/systemd/generator.early/ , где приоритет выше, чем у /etc/systemd/system/ ), отключить критически важные средства защиты, выполнить полезную нагрузку напрямую.

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

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

Контроль целостности — периодически сверяйте хеш-суммы файлов в директориях генераторов с эталонными.

Ограничение прав — запретите обычным пользователям и непривилегированным процессам запись в эти директории.

Анализ генераторов — проверяйте нестандартные или недавно появившиеся генераторы, особенно если они не от легитимных пакетов (openvpn, systemd-rc-local-generator и т.п.).

На этом пока что всё!

(Источник: https://t.me/ptescalator )