Ты получил initial access. Beacon живой, сессия стабильная. Но стоит пользователю перезагрузиться, IT-отделу прилететь с патчем или EDR убить процесс - и ты начинаешь всё сначала. Initial access - это разведка, социалка, обход периметра. Повторить весь цикл просто потому, что не позаботился о foothold, непрофессионально. Точка.
Persistence - разница между одноразовым попаданием и месяцами устойчивого доступа Windows. В MITRE ATT&CK тактика Persistence (TA0003) объединяет 19 техник с десятками подтехник. Все серьёзные APT - от Volt Typhoon (больше пяти лет необнаруженного доступа к критической инфраструктуре, если верить публичным отчётам) до Salt Typhoon - вкладываются именно в многослойное закрепление в системе Windows.
На практике это выглядит так: даже в 2025–2026 году самые часто используемые техники — это банальные Run Keys и Scheduled Tasks.
Здесь разберу четыре persistence механизма для пентеста, которые я использую на engagement'ах: реестровые ключи автозапуска, планировщик задач (включая 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 - тишина.
| Техника | Привилегии | Контекст выполнения | Мониторинг EDR |
|---|---|---|---|
| Run/RunOnce (T1547.001) | Пользователь / Админ | Пользователь | Высокий |
| Winlogon 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.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 с фильтрами:
ResultisNAME NOT FOUNDиPathcontainsInprocServer32. Фильтр покажет все случаи, когда процесс ищет 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.
Практика перехвата и 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)"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), частоту триггера и обнаруживаемость.| Техника | Привилегии | Reboot | Credential reset | Детектируемость |
|---|---|---|---|---|
| Run Key HKCU (T1547.001) | Пользователь | Да | Нет (привязан к пользователю) | Высокая |
| Scheduled Task (T1053.005) | Админ для SYSTEM | Да | Да | Средняя |
| Ghost Task | SYSTEM | Да | Да | Низкая |
| 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 и имя процесса.
Последнее редактирование модератором:
