ANTICHAT - Техники закрепления в Windows: реестр, планировщик, WMI и COM-hijacking для Red Team

https://forum.antichat.xyz/attachmen...0ce5f00cfd.png

Ты получил initial access. Beacon живой, сессия стабильная. Но стоит пользователю перезагрузиться, IT-отделу прилететь с патчем или EDR убить процесс - и ты начинаешь всё сначала. Initial access - это разведка, социалка, обход периметра. Повторить весь цикл просто потому, что не позаботился о foothold, непрофессионально. Точка.

Persistence - разница между одноразовым попаданием и месяцами устойчивого доступа Windows. В MITRE ATT&CK тактика Persistence (TA0003) объединяет 19 техник с десятками подтехник. Все серьёзные APT - от Volt Typhoon (больше пяти лет необнаруженного доступа к критической инфраструктуре, если верить публичным отчётам) до Salt Typhoon - вкладываются именно в многослойное закрепление в системе Windows.

https://forum.antichat.xyz/attachmen...7113937687.png

На практике это выглядит так: даже в 2025–2026 году самые часто используемые техники — это банальные Run Keys и Scheduled Tasks.

Здесь разберу четыре persistence механизма для пентеста, которые я использую на engagement'ах (многие из них опираются на встроенные возможности системы - общий обзор этого подхода собран в руководстве по living off the land атакам Windows): реестровые ключи автозапуска, планировщик задач (включая Ghost Tasks - ни один русскоязычный источник их толком не покрывает), WMI-подписки и COM-hijacking. Для каждой техники - конкретные команды, OPSEC-соображения и артефакты, по которым blue team будет вас искать.
Требования к окружению
Прежде чем лезть в практику, зафиксирую контекст. Все техники закрепления в Windows ниже предполагают:

ОС: Windows 10/11 или Windows Server 2016+ (большинство работает и на более ранних версиях, но тестировалось на актуальных)
Доступ: активная сессия на целевой машине - Cobalt Strike beacon, Meterpreter shell, evil-winrm или RDP
Привилегии: для Run-ключей в HKCU и COM-hijacking хватит прав обычного пользователя; для записи в HKLM, работы с планировщиком от SYSTEM и создания WMI-подписок нужен локальный администратор
Инструменты оператора: Cobalt Strike (или аналог C2), SharPersist, PowerSploit; для анализа - Sysinternals Autoruns, Process Monitor, WMI Explorer

Реестр Windows - persistence через ключи автозапуска
Реестр Windows - база данных, которую система читает при каждой загрузке, каждом входе пользователя, каждом запуске процесса. Десятки ключей триггерят выполнение кода автоматически, и это делает реестр Windows persistence самым обширным семейством техник автозапуска Windows. Пойдём от очевидного к скрытному.
Run и RunOnce - точка входа и её пределы
Registry Run Keys / Startup Folder (T1547.001, Persistence / Privilege Escalation) - самый задокументированный метод. Ключи

Код:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Код:

HKLM\...\Run

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

Добавление записи от текущего пользователя без повышения привилегий:

Код:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "OneDriveSync" /t REG_SZ /d "C:\Users\Public\updater.exe" /f

. Через SharPersist тот же результат:

Код:

SharPersist -t reg -c "C:\Users\Public\updater.exe" -a add -k "hkcurun" -v "OneDriveSync"

.

HKCU-ключ работает только для текущего пользователя - залогинится другой, payload не запустится. HKLM-вариант работает для всех, но требует прав администратора. RunOnce удаляет запись после первого выполнения - для одноразового действия сойдёт, для устойчивого доступа - нет.

Главная проблема Run-ключей в 2025 году: каждый EDR на планете мониторит эти ключи. Windows Defender, CrowdStrike Falcon, SentinelOne - все алертят на новые записи, особенно если путь ведёт в

Код:

Temp

Код:

AppData

или

Код:

Public

. Если Run-ключ - ваш единственный метод закрепления, ждите обнаружения в первые часы. Но как decoy он работает отлично - аналитик находит знакомый артефакт, удаляет, закрывает тикет и считает инцидент исчерпанным. А вы работаете дальше через другой канал.
Winlogon Helper, IFEO и менее очевидные ключи реестра
За пределами Run/RunOnce живут реестровые техники, которые мониторятся значительно слабее, а исполнение кода дают в привилегированных контекстах.

Winlogon Helper DLL (T1547.004) работает через ключ

Код:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

. Два значения:

Код:

Userinit

- вызывается после аутентификации, поддерживает перечисление через запятую (можно дописать свой бинарник после дефолтного

Код:

userinit.exe

, не ломая логон); и

Код:

Shell

- по умолчанию

Код:

explorer.exe

. Замена Shell агрессивнее: подсунете свой бинарник без вызова explorer.exe - пользователь получит пустой рабочий стол без панели задач. Тревога мгновенная. Корректный подход - обёртка, которая запускает payload и затем explorer.exe. Всегда сохраняйте оригинальное значение (лично я пишу его в комментарий рядом с payload'ом - на случай, если придётся откатывать).

Image File Execution Options Injection (T1546.012) - ключ

Код:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

со значением

Код:

Debugger

. При запуске целевого процесса система выполняет указанный «отладчик» вместо него. Классика: регистрация

Код:

Debugger

для

Код:

notepad.exe

, указывающего на

Код:

cmd.exe

. Но есть продвинутый вариант, который большинство русскоязычных источников не упоминает: в том же IFEO-ключе ставим

Код:

GlobalFlag=0x100

(FLG_APPLICATION_VERIFIER) и создаём

Код:

VerifierDlls

со списком DLL. Провайдер Application Verifier (

Код:

verifier.dll

) подгружает указанные DLL при каждом запуске процесса - и Autoruns от Sysinternals по умолчанию эти записи не показывает. Тишина.

Accessibility Features (T1546.008) - утилиты специальных возможностей (

Код:

sethc.exe

Код:

utilman.exe

Код:

osk.exe

Код:

narrator.exe

) вызываются с экрана блокировки до аутентификации. Подмена

Код:

sethc.exe

или IFEO-отладчик для него даёт SYSTEM-шелл по пятикратному нажатию Shift на экране входа в систему (логон-экране), включая RDP. Метод грубый, но на серверах, где RDP остаётся после сброса всех паролей, он незаменим.

Менее мониторируемые ключи для опытного оператора:

Port Monitors (T1547.010) - DLL, зарегистрированная как монитор порта в

Код:

HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\

, грузится в Print Spooler (

Код:

spoolsv.exe

) с правами SYSTEM. По данным EN-источников, этот механизм использовал APT41 в кампаниях против финансового сектора.
Time Providers (T1547.003) - DLL в

Код:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\

грузится службой W32Time от SYSTEM. Перезапуск

Код:

net stop w32time && net start w32time

триггерит загрузку без полного reboot. Средства защиты крайне редко заглядывают в подключи TimeProviders.
Netsh Helper DLL (T1546.007) - DLL в ключе

Код:

HKLM\SOFTWARE\Microsoft\Netsh

грузится при каждом вызове

Код:

netsh.exe

, включая автоматические вызовы при DHCP renewal и Windows-диагностике.
Active Setup (T1547.014) - сравнивает ключи версий в HKLM и HKCU для каждого пользователя. Если версия HKLM выше, выполняется

Код:

StubPath

. В доменных средах это золото - payload автоматически срабатывает для каждого нового пользователя при первом логоне.

OPSEC реестрового persistence
Имя ключа определяет, насколько быстро вас найдут. Значения

Код:

backdoor

Код:

shell

Код:

reverse

- первое, что ищут аналитики через Autoruns и regex-запросы в SIEM. Мимикрируйте под легитимное ПО:

Код:

AdobeARM

Код:

MicrosoftEdgeAutoUpdate

Код:

TeamsAutoUpdate

. Но сначала проверьте, что на целевой машине это ПО вообще стоит:

Код:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" | Select DisplayName

- иначе «обновление» несуществующей программы привлечёт больше внимания, чем откровенное

Код:

payload.exe

. Проходили.

Общее правило: чем глубже ключ и чем реже его мониторит EDR, тем дольше вы останетесь незамеченным. Run-ключи - шум; Port Monitors, Time Providers и VerifierDlls - тишина.

ТехникаПривилегииКонтекст выполненияМониторинг EDRRun/RunOnce (T1547.001)Пользователь / АдминПользовательВысокийWi nlogon Helper (T1547.004)АдминSYSTEMСреднийIFEO Debugger (T1546.012)АдминЗависит от целиСреднийIFEO VerifierDllsАдминЦелевой процессНизкийPort Monitors (T1547.010)АдминSYSTEM (spoolsv)НизкийTime Providers (T1547.003)АдминSYSTEM (W32Time)НизкийActive Setup (T1547.014)АдминПользовательНи� �кий

Планировщик задач Windows - атака от schtasks до Ghost Task
Scheduled Task (T1053.005, Execution / Persistence / Privilege Escalation) - легитимный системный механизм, который атакующие используют для запуска payload'ов по расписанию, при логоне или по событию. По данным Red Canary Threat Detection Report, большинство вредоносных scheduled tasks настроены на выполнение от SYSTEM - максимальные привилегии без интерактивной сессии.
Создание задач через schtasks и PowerShell
Базовая команда:

Код:

schtasks /create /tn "Microsoft\Windows\Maintenance\HealthCheck" /tr "C:\Windows\Temp\updater.exe" /sc onlogon /ru SYSTEM /f

. Обратите внимание на путь в имени задачи - размещение в поддиректории

Код:

Microsoft\Windows\Maintenance\

создаёт видимость системной задачи. Без вложенности задача окажется в корне Task Scheduler и сразу бросится в глаза аналитику. Флаг

Код:

/f

перезаписывает существующую задачу без подтверждения - удобно при повторной установке.

Для тонкого управления триггерами - PowerShell с

Код:

Register-ScheduledTask

, который позволяет задать множественные триггеры: при логоне, при старте системы, повторение с интервалом. Альтернативный путь (описан в Atomic Red Team) -

Код:

Invoke-CimMethod

через WMI-класс

Код:

PS_ScheduledTask

, позволяющий импортировать задачу из XML-файла. Это даёт доступ к параметрам, недоступным через

Код:

schtasks

, - например, атрибут

Код:

Hidden

.

Задача под системное обслуживание с выполнением каждые 15 минут:

Код:

schtasks /create /tn "Microsoft\Windows\Maintenance\HealthCheck" /tr "C:\Windows\Temp\svc.exe" /sc minute /mo 15 /ru SYSTEM /f

.

Артефакты: создание задачи через

Код:

schtasks.exe

генерирует Event ID 4698 в Security Log (при включённой подкатегории Other Object Access Events) и Event ID 106 в журнале

Код:

Microsoft-Windows-TaskScheduler/Operational

. Модификация - Event ID 140, удаление - 141. По данным Red Canary, эффективная детекция начинается с мониторинга

Код:

schtasks.exe

с флагом

Код:

/create

в связке с вызовом

Код:

cmd.exe

Код:

powershell.exe

Код:

rundll32.exe

или

Код:

mshta.exe

.
Ghost Task - невидимая задача без Event ID 4698
Эту технику я не встречал ни в одном русскоязычном материале, хотя она активно используется в реальных атаках - Microsoft описывала её в контексте malware Tarrask.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше

Получить доступ просто — достаточно проявить активность на форуме

COM Hijacking - техника перехвата через HKCU
COM Hijacking (T1546.015, Event Triggered Execution: Component Object Model Hijacking - Persistence / Privilege Escalation) - техника, при которой атакующий регистрирует свою DLL в HKCU для CLSID легитимного COM-объекта. Когда приложение запрашивает этот объект, Windows проверяет HKCU раньше HKLM и грузит подставную DLL вместо оригинальной.

COM hijacking техника хороша тем, что не создаёт нового autorun-механизма. Payload срабатывает, когда легитимное приложение естественным образом обращается к своему COM-объекту - пользователь открывает Explorer, запускает MMC или что угодно, использующее целевой CLSID. Привилегии администратора не нужны: запись в HKCU доступна обычному пользователю.
Поиск целей через ProcMon
Обнаружение пригодных COM-объектов - ручной процесс, и тут незаменим Process Monitor от Sysinternals. Алгоритм, который я гоняю на каждом engagement'е:

Запускаем ProcMon с фильтрами:

Код:

Result

is

Код:

NAME NOT FOUND

и

Код:

Path

contains

Код:

InprocServer32

. Фильтр покажет все случаи, когда процесс ищет COM-DLL в HKCU и не находит.
Каждый такой промах - потенциальная цель для перехвата. Ключ содержит CLSID вида

Код:

{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

.
Убеждаемся, что CLSID зарегистрирован в HKLM:

Код:

Get-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\{целевой-CLSID}\InprocServer32"

. Если в HKLM объект есть, а в HKCU - нет, перехват возможен.
Создаём ключ:

Код:

reg add "HKCU\Software\Classes\CLSID\{целевой-CLSID}\InprocServer32" /ve /t REG_SZ /d "C:\Users\Public\legit.dll" /f

и добавляем

Код:

ThreadingModel

=

Код:

Both

.

При следующем обращении приложения к этому CLSID загрузится ваша DLL в контексте вызывающего процесса.
Практика перехвата и OPSEC
Для автоматизации поиска подверженных перехвату CLSID без многочасового наблюдения в ProcMon:

Код:

Код:

$hklm = Get-ChildItem "HKLM:\SOFTWARE\Classes\CLSID" -EA SilentlyContinue |

  Where-Object { Test-Path "$($_.PSPath)\InprocServer32" } |

  ForEach-Object { $_.PSChildName }

$hkcu = @((Get-ChildItem "HKCU:\Software\Classes\CLSID" -EA SilentlyContinue).Name |

  Split-Path -Leaf)

$hijackable = $hklm | Where-Object { $_ -notin $hkcu }

Write-Output "Candidates (upper bound, use ProcMon to refine): $($hijackable.Count)"

Скрипт демонстрационный - даёт верхнюю границу: практически всё содержимое HKLM\CLSID минус уже перехваченные объекты, то есть десятки тысяч записей. Без фильтрации по частоте обращений (через ProcMon) список бесполезен. Реальный набор hijackable CLSID получается только через ProcMon (фильтр

Код:

NAME NOT FOUND

на

Код:

InprocServer32

в HKCU) - без него отсеять регулярно вызываемые объекты невозможно. Запустите ProcMon на несколько минут и сопоставьте кандидатов с реальными обращениями.

OPSEC COM-hijacking: техника почти невидима для базовых EDR. Запись идёт в HKCU - UAC не нужен. DLL грузится легитимным процессом - нового подозрительного процесса нет. Нет scheduled tasks, нет сервисов, нет Run-ключей. Sysinternals Autoruns показывает COM-объекты на вкладке «COM Hijacks», но многие аналитики её пропускают при беглом осмотре. Основной операционный риск: если ваша DLL вызовет исключение, упадёт host-приложение, и пользователь побежит в поддержку. DLL должна корректно проксировать вызовы к оригинальной библиотеке - иначе вместо persistence получите incident response.
Сравнение техник закрепления в Windows
Для выбора persistence-механизма на engagement'е я ориентируюсь на четыре параметра: необходимые привилегии, надёжность (переживёт ли reboot и credential reset), частоту триггера и обнаруживаемость.

ТехникаПривилегииRebootCredential resetДетектируемостьRun Key HKCU (T1547.001)ПользовательДаНет (привязан к пользователю)ВысокаяScheduled Task (T1053.005)Админ для SYSTEMДаДаСредняяGhost TaskSYSTEMДаДаНизкаяWMI SubscriptionАдминДаДаСредняяCOM Hijacking (T1546.015)ПользовательДаНет (привязан к HKCU)НизкаяPort Monitors (T1547.010)АдминДаДаНизкая

Золотое правило post-exploitation закрепления: никогда не полагайтесь на один механизм. Зрелая стратегия - layered persistence. Ставите Run-ключ как «громкий» decoy, WMI-подписку как основной канал и COM-hijack как спящий запасной. Blue team находит Run-ключ, удаляет, закрывает тикет - а вы работаете через два оставшихся канала. Позже обнаружат WMI-подписку - COM-hijack всё ещё даёт сессию.

MITRE ATT&CK persistence Windows разбивает эти техники по подтактикам, но на практике границы размыты: WMI-подписка одновременно даёт и persistence, и execution, а Ghost Task сочетает persistence с defense evasion. Планируйте закрепление как систему, а не как одиночную технику.
Вопрос к читателям
При COM Hijacking через ProcMon на чистой Windows 10 22H2 я обычно нахожу 30–40 CLSID с

Код:

NAME NOT FOUND

Код:

HKCU\...\InprocServer32

. Но в корпоративных средах с SCCM agent, CrowdStrike sensor или Citrix Workspace набор хиджакабельных (подверженных перехвату) объектов совсем другой. У кого есть свежие ProcMon-дампы с корпоративных endpoint'ов - какие CLSID стабильно показывают

Код:

NAME NOT FOUND

и при этом вызываются регулярно (не единожды при логине, а каждые несколько часов)? Особенно интересуют связки с

Код:

explorer.exe

или

Код:

svchost.exe

как host-процессом - кидайте CLSID и имя процесса.