На последних трёх внутренних пентестах - банк, производственная компания, госучреждение - я насчитал около 120 машин на Windows 10 22H2, где после 14 октября 2025 года не изменилось ровным счётом ничего. Те же дефолтные GPO, открытый SMBv1, LSASS без RunAsPPL. Mimikatz снимал NTLM-хеши без малейшего сопротивления, а Pass-the-Hash (T1550.002) давал lateral movement до контроллера домена за минуты - причём на тех же машинах отлично работали living off the land техники, разобранные в полном руководстве по LOLBAS и обходу EDR. Ниже - чеклист, который я использую и как атакующий (чтобы знать, что ломать), и как автор рекомендаций в отчёте (чтобы знать, что закрыть первым). Подход един для харденинга Windows 10 после окончания поддержки и для усиления защиты Windows 11 - разница лишь в доступных механизмах.
Почему EOL Windows 10 - подарок для атакующего
Русскоязычные материалы о Windows 10 после EOL сводятся к двум советам: «подключите ESU» или «купите новый ПК». Ни один не разбирает, что конкретно происходит с attack surface непропатченной системы с позиции пентестера.После 14 октября 2025 года каждая новая CVE в ядре Windows 10 становится перманентным 0-day. Microsoft продолжает выпускать патчи для Windows 11 и Server - diff между пропатченной и непропатченной версией публикуется открыто. По сути это Exploitation for Privilege Escalation (T1068) на блюдечке: исследователь (или злоумышленник) reverse-diff'ит октябрьский Patch Tuesday для Windows 11 и пишет эксплойт для Windows 10, где fix никогда не появится.
По данным CyberMaxx, «even previously unknown zero-day vulnerabilities may be weaponized more aggressively once attackers are confident no fixes will ever arrive». Не теория - после EOL Windows 7 в 2020 году массовая эксплуатация непропатченных уязвимостей началась в течение нескольких месяцев.
Нюанс, который часто упускают: обновления сигнатурных баз Microsoft Defender Antivirus продолжат приходить до 2028 года. Но Defender ловит известные вредоносы по сигнатурам и ML-моделям - а не закрывает дыру в ядре ОС. Уязвимость в win32k.sys или ntoskrnl.exe антивирусная сигнатура не заткнёт. Это как ставить замок на дверь, в которой дыра размером с кулак.
Fingerprinting хоста: что проверить перед харденингом
Прежде чем применять GPO, нужно понять текущее состояние машины. Этот же чеклист я использую на пентесте для оценки - стоит ли тратить время на конкретный хост или двигаться дальше.Требования к окружению: Windows 10 22H2 или Windows 11 23H2/24H2, PowerShell 5.1+, права локального администратора. Все команды выполняются локально или через PSRemoting на доменной машине.
Что проверять:
- Build и патч-уровень -
systeminfo | findstr /B /C:"OS Version". Build ниже 19045 (Win10 22H2) - хост на устаревшей feature-версии ещё до EOL. - LSASS Protection - ключ
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL. Значение отсутствует или равно 0 - Mimikatz снимет хеши без дополнительных телодвижений. - SMBv1 -
Get-SmbServerConfiguration | Select EnableSMB1Protocol. True - хост уязвим к relay-атакам и целому классу RCE. - UAC level - ключ
HKLM\...\Policies\System\ConsentPromptBehaviorAdmin. Дефолтное значение 5 - UAC bypass тривиален через десятки публичных техник. - Credential Guard -
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard. Не в списке активных сервисов - NTLM-хеши лежат в памяти LSASS открытым текстом. - PowerShell language mode -
$ExecutionContext.SessionState.LanguageMode. FullLanguage - любой payload выполнится без ограничений.
| Что проверяем | Плохой результат | Вектор атаки |
|---|---|---|
| RunAsPPL = 0 | LSASS dump (T1003.001) | Credential access |
| SMBv1 = True | Relay, EternalBlue-подобные | Lateral movement |
| UAC level = 5 | UAC Bypass (T1548.002) | Privilege escalation |
| Credential Guard отсутствует | Pass-the-Hash (T1550.002) | Lateral movement |
| PowerShell FullLanguage | Fileless execution (T1059.001) | Execution |
Для автоматизации - HardeningKitty: PowerShell-модуль, который прогоняет хост по CIS Benchmark и Microsoft Security Baseline, выдаёт CSV со всеми отклонениями. PingCastle делает то же на уровне домена - сканирует AD и оценивает защищённость с конкретными рекомендациями. CIS Microsoft Windows 10 Enterprise Benchmark v3.0.0, согласно данным NIST NCP (checklist ID 1162), протестирован на Windows 10 22H2 и содержит полный перечень GPO-рекомендаций двух уровней: Level 1 для всех систем (минимальное влияние на функциональность) и Level 2 для сред с повышенными требованиями (по данным CIS, «could result in some reduced functionality»). DISA STIG для Windows 10 даёт аналогичную базу с привязкой к DoD-контролям.
Защита учётных данных: LSASS, Credential Guard, NTLM
LSASS Protection и Credential Guard
LSASS Memory (T1003.001, credential-access) - первое, что проверяет пентестер после получения локального админа. Дамп LSASS даёт NTLM-хеши, Kerberos-тикеты и часто - пароли в открытом виде через WDigest.{HIDE]RunAsPPL (Protected Process Light) включается одним ключом реестра:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f. После перезагрузки LSASS запускается как Protected Process, и стандартный Mimikatz с sekurlsa::logonpasswords получает ошибку доступа. Обход существует - через загрузку уязвимого подписанного драйвера (BYOVD), но это уже совсем другая история: атакующему нужен kernel-level доступ и конкретный уязвимый драйвер. Планка поднимается на порядок.Параллельно - отключение WDigest:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 0 /f. Без этого пароли могут валяться в памяти в открытом виде даже с RunAsPPL. Видел это на проекте в 2024-м - RunAsPPL стоит, а WDigest забыли. Половина работы.Credential Guard (Windows 10 Enterprise/Education и Windows 11) изолирует NTLM-хеши и Kerberos-тикеты в отдельной виртуальной машине на базе VBS. Включается через GPO:
Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security. Требования к железу: UEFI Secure Boot, TPM 2.0, поддержка Intel VT-x / AMD-V. Credential Guard закрывает Pass-the-Hash (T1550.002) для интерактивных логонов. Но не защищает от Kerberoasting и AS-REP Roasting - эти атаки работают на уровне AD, а не локальной памяти.Когда что применять: Credential Guard - для modern-инфраструктуры с VBS-совместимым оборудованием. На legacy-железе без TPM 2.0 единственная защита - RunAsPPL + отключение WDigest. На внутреннем пентесте я всегда проверяю оба контроля: RunAsPPL есть, но WDigest не отключён - классическая полумера.[/HIDE]
Отключение NTLM, LLMNR, NBT-NS
На внутреннем пентесте я запускаю Responder и жду. В среде без отключённых LLMNR и NBT-NS первый NTLMv2-хеш приходит обычно за минуты - кто-то набрал несуществующее имя в проводнике, Windows широковещательно спрашивает сеть «кто это?», Responder отвечает «я» и перехватывает хеш. Иногда даже кофе заварить не успеваешь.Закрываем тремя GPO:
- LLMNR off:
Computer Configuration → Administrative Templates → Network → DNS Client → Turn Off Multicast Name Resolution → Enabled - NBT-NS off: через скрипт в GPO, отключающий NetBIOS over TCP/IP на всех сетевых интерфейсах
- SMBv1 off:
Set-SmbServerConfiguration -EnableSMB1Protocol $false- закрывает класс relay-атак и legacy-RCE
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Deny All. Но тут осторожнее: legacy-приложения и сетевые принтеры часто зависят от NTLM. Перед блокировкой - режим Audit All минимум на две-три недели, чтобы собрать список зависимых сервисов через Event ID 8001–8004 в журнале NTLM. Иначе утром после раскатки GPO зазвонят все телефоны разом.Внутренний пентест vs внешний: отключение LLMNR/NBT-NS критично для внутреннего пентеста и red team. При внешнем пентесте эти протоколы не видны за периметром, но lateral movement после initial access всё равно будет их эксплуатировать - так что защита нужна в обоих сценариях.
Контроль привилегий и выполнения кода
UAC: дефолт - не барьер
Bypass User Account Control (T1548.002, privilege-escalation, defense-evasion) - одна из наиболее стабильно работающих техник. Дефолтный UAC (ConsentPromptBehaviorAdmin = 5) автоматически повышает привилегии для приложений из доверенных каталогов. Техники обхода - DLL hijacking в auto-elevate бинарях, fodhelper.exe, eventvwr.exe - работают именно потому, что дефолтный UAC предупреждает, но не блокирует.Настройки безопасности Windows для UAC:
ConsentPromptBehaviorAdmin = 2- запрос на каждое повышение. Закрывает большинство автоматических UAC bypass.FilterAdministratorToken = 1- применяет UAC к built-in Administrator, который по дефолту ему не подчиняется.EnableLUA = 1- должен быть всегда, но проверяйте: полностью отключённый UAC встречается чаще, чем хотелось бы.
PowerShell и Attack Surface Reduction
PowerShell (T1059.001, execution) - основной движок fileless-атак. Полностью убить нельзя - административные задачи от него зависят. Но ограничить - обязательно.Constrained Language Mode урезает доступ к .NET-вызовам, COM-объектам и Add-Type. Включается через WDAC-политику (не через переменную окружения - её обходят тривиально). В CLM стандартные payload'ы от Empire, Covenant и аналогичных C2-фреймворков ломаются.
PowerShell v2 - удалить обязательно:
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root. PowerShell 2.0 не поддерживает AMSI и Script Block Logging, поэтому атакующие целенаправленно даунгрейдят на него. Старый добрый даунгрейд - если он доступен, его используют.Script Block Logging - GPO
Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging. Записывает каждый выполненный блок в Event ID 4104. Атакующему не мешает, но даёт blue team полную картину. На внутреннем пентесте отсутствие этого логирования означает, что мои PowerShell-команды полностью невидимы для SOC.Attack Surface Reduction (ASR) rules - набор правил Windows Defender, блокирующих типовые вектора: Office-макросы, создающие дочерние процессы; PSExec и WMI lateral movement; credential stealing из LSASS.
Код:
# Блокировка credential stealing из LSASS через ASR
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 `
-AttackSurfaceReductionRules_Actions EnabledAppLocker vs WDAC: на EOL-хостах с Windows 10 Enterprise AppLocker - минимально достаточный контроль приложений. Правила по publisher + hash для критичных каталогов закрывают ~80% сценариев запуска произвольного кода. Обходится через DLL side-loading в доверенных каталогах и через LOLBins (MSBuild, Installutil). WDAC мощнее - блокирует managed installers и закрывает LOLBin-вектора - но значительно сложнее в развёртывании. Для legacy-инфраструктуры с EOL-машинами AppLocker - разумный компромисс; для modern-среды с централизованным управлением - WDAC.
Аудит и Windows Defender на EOL-хосте
Disable or Modify Tools (T1562.001) и Disable Windows Event Logging (T1562.002) - стандартные действия атакующего на позднем этапе. Чтобы отключать было что, логирование сначала нужно включить. По дефолту Windows записывает минимум - и этим минимумом пользуются.Критичные политики аудита через
Advanced Audit Policy Configuration:| Подкатегория | Что детектирует |
|---|---|
| Audit Logon (Success, Failure) | Brute force, Pass-the-Hash |
| Audit Sensitive Privilege Use (Success) | SeDebugPrivilege, token manipulation |
| Audit SAM (Success) | Дамп SAM-базы |
| Audit Process Creation (Success) | Запуск вредоносных процессов |
| Audit Audit Policy Change (Success) | Попытка отключить аудит (T1562.002) |
Обязательно:
Include command line in process creation events через GPO (Administrative Templates → System → Audit Process Creation). Без этого Event ID 4688 показывает имя процесса, но не аргументы. Разница между «видим svchost.exe» и «видим svchost.exe -k netsvcs с подозрительным parent PID» - это разница между пропущенной атакой и детектом.Для EOL-машин Windows Defender - единственный антивирус с гарантированными обновлениями сигнатур до 2028 года. Что ужесточить:
- Tamper Protection - запрещает отключение Defender через реестр или GPO (закрывает T1562.001). Включается через Windows Security UI или Intune.
- Cloud-delivered protection:
Set-MpPreference -MAPSReporting Advanced- подозрительные файлы отправляются в облако для ML-анализа. - Controlled Folder Access - защита от шифровальщиков: блокирует запись в защищённые папки для недоверенных процессов.
Сетевая изоляция и приоритеты внедрения
Если миграция на Windows 11 невозможна прямо сейчас, EOL-хосты нужно изолировать на сетевом уровне. Не замена харденингу - дополнительный барьер. VLAN-сегментация с ограничением трафика к серверным подсетям, Windows Firewall с явным allowlist для входящих соединений (RDP только через VPN, WinRM с конкретных IP администраторских станций), перенаправление журналов с EOL-хостов в SIEM с повышенным приоритетом. На внутреннем пентесте я целенаправленно ищу EOL-машины - через них проще попасть в защищённые сегменты. Изоляция ломает эту цепочку.Не все меры одинаково критичны. Приоритеты по соотношению эффекта к сложности:
| Приоритет | Мера | Закрываемый вектор | Сложность |
|---|---|---|---|
| 1 | RunAsPPL + WDigest off | T1003.001 LSASS dump | Низкая |
| 2 | SMBv1 off | Relay, legacy RCE | Низкая |
| 3 | LLMNR/NBT-NS off | Responder relay | Низкая |
| 4 | ASR rules + Script Block Logging | T1059.001, fileless | Средняя |
| 5 | UAC hardening | T1548.002 bypass | Низкая |
| 6 | Credential Guard | T1550.002 PtH | Средняя (VBS) |
| 7 | AppLocker/WDAC | Arbitrary code exec | Высокая |
| 8 | Сетевая изоляция | Lateral movement | Средняя |
Первые три пункта закрываются за час групповой политикой и не ломают совместимость в подавляющем большинстве сред. Если в организации прямо сейчас есть EOL Windows 10 - начните с них.
Для полного аудита по CIS Benchmark Windows 10 v3.0.0 (Level 1 + Level 2) или DISA STIG Windows 10 - HardeningKitty автоматизирует проверку и формирует отчёт с отклонениями от baseline.
Я регулярно наблюдаю одну картину: администраторы констатируют «обновления больше не приходят» и продолжают жить как раньше, а безопасники пишут в отчёте «рекомендуем мигрировать на Windows 11» - и считают задачу решённой. Между рекомендацией и реальной миграцией проходят месяцы, иногда годы. Всё это время хосты стоят с дефолтными настройками.
Три GPO из первых строк таблицы - RunAsPPL, SMBv1 off, LLMNR off - занимают 15 минут и убирают примерно 70% того, что я эксплуатирую на типовом внутреннем пентесте. Но харденинг без проверки - театр безопасности. Включили RunAsPPL - а проверили, что LSASS действительно запущен с PPL? Отключили SMBv1 на сервере - забыли про клиентскую часть? Настроили ASR rules, а Defender в passive mode? Единственный способ валидировать - попробовать атаку. HardeningKitty и PingCastle дают быстрый конфигурационный аудит, но настоящую проверку обеспечивает только offensive тестирование. Без него windows hardening checklist остаётся списком галочек, а не реальной защитой. На WAPT эту связку «харденинг → проверка → обход → доработка» проходят в лабах с реальной AD-инфраструктурой.
Последнее редактирование:
