Безпечно відключіть ризиковані функції Windows, які полюбляють зловмисники

Що саме зловмисники зловживають у Windows

Більшість успішних компрометацій Windows — це не «один магічний експлойт». Це ланцюг:

• Початковий доступ (фішинг, крадіжка токенів, відкритий RDP, вразливий VPN, шкідливий макрос).
• Виконання (PowerShell, WSH, дочірні процеси Office, планувальники завдань).
• Доступ до облікових даних (дамп LSASS, NTLM relay, кешовані облікові, сервісні акаунти з неправильними правами).
• Латеральний рух (SMB, WMI, WinRM, RDP, створення служб на зразок PsExec).
• Персистенція (елементи автозавантаження, планувальники, служби, зловживання GPO).
• Наслідки (розгортання ransomware, викрадення даних, пошкодження контролерів домену).

«Функції, які полюбляють зловмисники», зазвичай: старі, широко поширені й непомітні в повсякденній роботі. Вони також часто є легітимними адміністративними можливостями. Ось в чому пастка: якщо ви не можете відрізнити ІТ від зловмисника в логах, то атакувальник вже виграв гру прихованості.

Наша мета — зменшити кількість вбудованих інструментів, на які може покластися нападник, звузити зону ураження, коли він спробує рухатися, і зробити середовище гучнішим під час руху зловмисника.

Цікаві факти та історичний контекст (бо це не сталося випадково)

1. SMB1 походить з 1980-х ідеї LAN Manager: передбачення довірених мереж, голоске виявлення, мінімальна аутентифікаційна гігієна.
2. NTLM створювався для сумісності між старими версіями Windows і змішаними середовищами; він залишився, бо «працює всюди»—сильна спокуса.
3. LLMNR з’явився, щоб ім’я резолвилось “просто”, коли DNS налаштований неналежним чином. Атакувальники його обожнюють для перехоплення облікових даних у плоских мережах.
4. WMI став швейцарським ножем управління Windows — а згодом і латерального руху — бо дозволяє віддалене виконання процесів при наявності прав.
5. PowerShell спочатку створювався для автоматизації; посилення безпеки (логування, constrained language, AMSI) з’явилося пізніше, коли еволюціонував загрозовий модель.
6. Remote Registry існує здебільшого для старих інструментів управління. У сучасних середовищах часто це баласт з гострими краями.
7. Autorun/Autoplay свого часу були UX-фічею для знімних носіїв. Вони перетворилися на функцію для зловмисного ПЗ. UX програв цей бій.
8. TLS 1.0/1.1 затримувалися через бізнес-додатки та пристрої, які не хотіли оновлюватися. На це звернули увагу і нападники, і аудитори з відповідності.

Як відключати функції без самосаботажу

1) Виміряйте використання перед видаленням

Вимкнути SMB1 — легко. Знайти, що один сканер на складі все ще розмовляє SMB1 — справжня робота. Перед тим як виривати функції, ви інвентаризуєте залежності.

2) Надавайте перевагу «ізолювати» над «залишити увімкненим»

Якщо функція потрібна — обмежте її. Обмежуйте за:

• Мережею: тільки з адміністраторських підмереж, тільки до керуючих портів, тільки через jump host.
• Ідентичністю: конкретні групи, JIT-доступ, окремі адміністративні облікові записи.
• Пристроєм: PAW/SAW для адміністраторів, тьєринг (робочі станції не можуть адмініструвати сервери).
• Часом: підвищення прав лише за потреби, тимчасовий доступ, вікна змін.

3) Робіть відкат частиною дизайну

Якщо ви не можете швидко відкотити зміни, ви не впровадите їх. Для кожної зміни вирішіть:

• Що зламається, якщо ми помилимося?
• Як ми виявимо зламання менше ніж за 10 хвилин?
• Яка команда або GPO відкотить зміни?

4) Логуйте достатньо, щоб довести, що стало безпечніше

Хардінг, який неможливо валідувати, перетворюється на релігійну суперечку. Потрібні докази: менше NTLM-подій, менше відкритих керуючих портів, менше доступних рушіїв скриптів, менше подій «створено віддалену службу».

5) Не плутайте «відключено» з «недосяжно»

Вимкнення служби допомагає. Блокування порту на брандмауері хоста часто надійніше. Краще — робити і те, і інше, коли це можливо.

Парафраз ідеї Gene Kim: невеликі часті зміни з швидким зворотним зв’язком перемагають «великий вибух», особливо коли на кону — надійність.

Швидкий план діагностики (що перевіряти перше/друге/третє)

Це та частина, що використовується під час інциденту або зміни, коли хтось каже: «Чому все зламалося?» Вам потрібно швидко знайти вузьке місце, а не виграти суперечку.

Перше: підтвердіть, що змінилося і де

• GPO / Intune / локальна політика: застосувалося налаштування? До якої OU / групи пристроїв?
• Видалення функції vs відключення конфігурації: хтось видалив опціональну функцію (складніше відкотити) чи просто змінив політику?
• Сфера дії брандмауера: ми заблокували порт, потрібний для керування?

Друге: ідентифікуйте збійний шлях (резолюція імен, автентифікація, транспорт)

• Резолюція імен: DNS vs LLMNR/NBT-NS як fallback.
• Аутентифікація: Kerberos vs NTLM, сертифікатна vs парольна автентифікація.
• Транспорт: SMB vs WinRM vs WMI/DCOM vs RDP.

Третє: доведіть це одним чистим тестом з одного чистого хоста

• З відомо добре налаштованої адміністраторської робочої станції протестуйте конкретний протокол/порт.
• На цільовому сервері перевірте стан слухачів, статус служб і правила брандмауера.
• Перевірте журнали подій за відповідним підсистемам (SMBClient, WinRM, Security, Schannel).

Швидка «карта тріажу»

• Не вдається отримати доступ до файлів → перевірте діалекти SMB, порт 445, підпис SMB, гостьовий доступ.
• Віддалені команди падають → перевірте службу WinRM, слухач, брандмауер, неправильне використання TrustedHosts.
• Старий додаток не може підключитись → перевірте версії TLS/шифри, налаштування .NET, журнали Schannel.
• Затримки при вході → перевірте fallback для розв’язування імен і доступність контролера домену.

Ризикові функції Windows: вимкнути або загородити

SMB1 (вимкніть; ностальгії немає)

SMB1 — це плата за сумісність із відсотком у вигляді ризику. Якщо у вас ще є клієнти або сервери SMB1, потрібен план: ідентифікувати їх, ізолювати та вивести з експлуатації. Безпечний дефолт: SMB1 вимкнений скрізь.

Як варіант обмеження: якщо дійсно незмінний пристрій вимагає SMB1, помістіть його в окрему VLAN, обмежте SMB до єдиного файлового сервера й не дозволяйте йому спілкуватись з іншими мережевими сегментами.

LLMNR та NBT-NS (вимкніть, щоб зупинити легке перехоплення облікових даних)

LLMNR і NBT-NS «допомагають», коли DNS ламається. Атакувальники зловживають ними для спуфінгу і захоплення NTLM-хешів через атаки на зразок responder. Якщо DNS ненадійний — виправте DNS. Не зберігайте «пістолет у ногу».

NTLM (зменшити; потім вбивати там, де можна)

Kerberos — бажаний протокол у здоровому домені. NTLM — брудний fallback, який можна релеювати, знижувати або збирати. Не потрібно відключати NTLM глобально в перший день. Потрібен план скорочення, підкріплений подіями з логів і тимчасовими винятками.

PowerShell Remoting і WinRM (обмежити, а не масово відключати)

WinRM/PowerShell Remoting корисні за призначенням. Водночас вони цінні для нападників, бо виглядають як «трафік адміністрування». Краща практика — обмежити, хто може ним користуватися, звідки та добре логувати. На кінцевих пристроях, де не потрібні, відключіть.

WMI/DCOM віддалене адміністрування (суворо обмежити)

Віддалений WMI — класичний шлях латерального руху. Багато організацій можуть перенести завдання на WinRM з обмеженими кінцевими точками і кращим аудитом. Якщо залишаєте WMI віддаленим — звужуйте доступ до адміністраторських хостів і груп.

Remote Registry (зазвичай: вимкнути)

Якщо ви не використовуєте інструмент, що вимагає Remote Registry, вимкніть його. Це одна з тих служб, що тихо розширює можливості під час інфраструктурного вторгнення, не надаючи сучасної цінності.

Windows Script Host (WSH) та старі рушії скриптів (часто: вимкнути)

VBScript і JScript через WSH часто несуть payload. Багато середовищ можуть відключити WSH без втрати базової функціональності Windows. Якщо якийсь старий додаток його потребує — обмежте використання на його хостах.

Макроси Office та поведінка «дочірніх процесів» (агресивно контролювати)

Макроси не злі. Неконтрольовані макроси — злі. Надайте політику макросів, блокуйте макроси з інтернету і зменшуйте запуск Office дочірніх процесів, де можливо, через ASR-правила. У реальності будуть винятки — зробіть їх явними та підлягаючими огляду.

Експозиція RDP (звузьте площу атаки, а потім зменште привілеї)

RDP не злочинець сам по собі. RDP, відкритий у світ або широко увімкнений всередині з поганим контролем — точно злочинець. Використовуйте gateway/jump hosts, MFA, мережеву автентифікацію на рівні мережі та обмеження брандмауера на хості. І не використовуйте доменних адмінів для рутинного RDP.

Старий TLS та слабка криптографія (вимикайте старі протоколи на серверах першими)

Атакувальникам не потрібно ламати крипто, якщо ви досі пропонуєте застарілі протоколи. Вимкнення TLS 1.0/1.1 та слабких шифрів може зламати старі інтеграції, тому робіть це як SRE-зміну: виявлення, поетапне тестування та розгортання з моніторингом.

Autorun/Autoplay (вимкніть; бізнес-кейсу немає)

Знімні носії досі присутні в багатьох галузях. Autorun не повинен бути увімкнений. Якщо ви хочете автоматично відкривати щось при підключенні пристрою — робіть це через керований корпоративний інструмент, а не через фічу 2000-х з історією використання у malware.

Жарт #1: SMB1 — як залишати дисковий телефон, бо «він ще працює». Так — доки хтось не скористається ним, щоб подзвонити на великий тариф на ваш рахунок.

Практичні завдання: команди, виводи та рішення

Ці завдання призначені для запуску з адміністраторської оболонки (PowerShell) на Windows. Формат промпту нижче стандартизований; не надто переживайте через ім’я користувача. Важливе — те, що ви дізнаєтесь з виводу й яке рішення ухвалите далі.

Завдання 1: Перевірити, чи ввімкнено SMB1 (компонент сервера)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Format-List FeatureName,State"
FeatureName : SMB1Protocol
State       : Enabled

Що означає вивід: SMB1 встановлено та увімкнено на цій машині.

Рішення: Якщо це не ізольований спадок, заплануйте вимкнення/видалення. Перед зміною ідентифікуйте клієнтів, що залежать від SMB1 (див. Завдання 3).

Завдання 2: Безпечно вимкнути SMB1 (видалення функції) і підтвердити

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

Що означає вивід: SMB1 вимкнено; потрібен перезавантаження для завершення.

Рішення: Заплануйте перезавантаження. Якщо це файловий сервер — координуйте з користувачами та моніторьте помилки доступу до шарів після рестарту.

Завдання 3: Виявити використання SMB1 через журнали подій (SMB сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 10:12:41 AM 3000 SMB1 negotiation detected from client 10.20.5.44.
2/5/2026 10:05:09 AM 3000 SMB1 negotiation detected from client 10.20.5.44.

Що означає вивід: Клієнт з 10.20.5.44 намагається використовувати SMB1.

Рішення: Знайдіть власника пристрою. Якщо це застарілий пристрій — ізолюйте або оновіть. Не тримайте SMB1 глобально увімкненим, щоб захистити одну запилюжену куток.

Завдання 4: Перевірити статус підпису SMB (клієнт і сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature | Format-List"
EnableSecuritySignature  : True
RequireSecuritySignature : False

Що означає вивід: Підпис SMB підтримується, але не обов’язковий.

Рішення: В більшості підприємств вимагайте підпис SMB на серверах (особливо на DC і файлових серверах). Спершу перевірте сумісність зі старими клієнтами.

Завдання 5: Визначити, чи увімкнено LLMNR через реєстр (локальна перевірка)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue | Format-List"
EnableMulticast : 1

Що означає вивід: LLMNR явно увімкнено політикою (1).

Рішення: Встановіть це значення в 0 через GPO для доменних систем, потім перевірте надійність DNS у відповідних підмережах.

Завдання 6: Вимкнути LLMNR (локальне виправлення для тестування)

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast"
EnableMulticast : 0

Що означає вивід: LLMNR тепер вимкнено політикою на цьому хості.

Рішення: Перенесіть це до централізованої політики (GPO/Intune). Розгляньте також можливість вимкнення NBT-NS, де це доцільно (Завдання 7).

Завдання 7: Перевірити NetBIOS over TCP/IP (по інтерфейсу)

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=TRUE' | Select-Object Description,TcpipNetbiosOptions | Format-Table -AutoSize"
Description                          TcpipNetbiosOptions
-----------                          -------------------
Intel(R) Ethernet Connection         0

Що означає вивід: TcpipNetbiosOptions 0 зазвичай означає «За замовчуванням» (керується DHCP). 1 — увімкнено, 2 — вимкнено.

Рішення: Якщо NetBIOS не потрібен, встановіть 2 через настройки DHCP або локальні стандарти конфігурації. Спершу перевірте старі залежності (старі системи, інструменти виявлення).

Завдання 8: Перевірити, чи WinRM увімкнено і слухає

cr0x@server:~$ powershell -NoProfile -Command "winrm enumerate winrm/config/listener"
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true

Що означає вивід: WinRM увімкнено і слухає на HTTP 5985.

Рішення: Для серверів збережіть WinRM, але обмежте вхідні з’єднання адміністраторськими підмережами і забезпечте належну автентифікацію. На кінцевих пристроях розгляньте вимкнення, якщо не потрібен.

Завдання 9: Вимкнути PowerShell Remoting на кінцевих пристроях (цільовий)

cr0x@server:~$ powershell -NoProfile -Command "Disable-PSRemoting -Force; Get-Service WinRM | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name Status StartType
---- ------ ---------
WinRM Stopped Disabled

Що означає вивід: Служба WinRM зупинена і вимкнена; PS Remoting вимкнено.

Рішення: Застосуйте до OU/групи пристроїв робочих станцій, а не до серверів керування. Залишайте шлях аварійного відновлення (наприклад, віддалена оболонка EDR або інструменти керування в мережі).

Завдання 10: Перевірити статус служби Remote Registry

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RemoteRegistry | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name           Status  StartType
----           ------  ---------
RemoteRegistry Running Automatic

Що означає вивід: Remote Registry працює і встановлено автозапуск.

Рішення: Якщо не можете назвати інструмент, що потребує цього, вимкніть його (Завдання 11). Якщо інструмент потрібен — звузьте його доступ до управлінської VLAN і обмежте, хто може до нього діставатися.

Завдання 11: Вимкнути Remote Registry і блокувати вхідні з’єднання брандмауером для defense-in-depth

cr0x@server:~$ powershell -NoProfile -Command "Stop-Service RemoteRegistry -Force; Set-Service RemoteRegistry -StartupType Disabled; Get-Service RemoteRegistry | Format-Table -AutoSize"
Status  Name           DisplayName
------  ----           -----------
Stopped RemoteRegistry Remote Registry

Що означає вивід: Служба зупинена і не запускатиметься при завантаженні.

Рішення: Перевірте, чи система керування все ще працює. Якщо щось зламається — це має бути відома залежність; якщо це несподіванка, ви щойно знайшли недокументований ризик.

Завдання 12: Перевірити, чи увімкнено WSH (cscript/wscript)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -ErrorAction SilentlyContinue | Format-List"
Enabled : 1

Що означає вивід: Windows Script Host увімкнено.

Рішення: Якщо у вас немає санкціонованих VBScript логон-скриптів або застарілих адміністративних скриптів, відключіть WSH через політику та мігруйте автоматизацію на PowerShell з логуванням.

Завдання 13: Вимкнути WSH (цільовий пілот) і перевірити поведінку

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled"
Enabled : 0

Що означає вивід: WSH тепер вимкнено на цьому хості.

Рішення: Проведіть пілот у відділі спочатку (фінанси часто мають «таємні макроси/скрипти»). Відстежуйте звернення до helpdesk; ви картографуєте приховані залежності.

Завдання 14: Перевірити експозицію RDP (служба + правила брандмауера)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections | Select-Object fDenyTSConnections; Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName,Enabled,Direction,Action | Format-Table -AutoSize"
fDenyTSConnections
------------------
0

DisplayName                             Enabled Direction Action
-----------                             ------- -------- ------
Remote Desktop - User Mode (TCP-In)      True    Inbound  Allow
Remote Desktop - User Mode (UDP-In)      True    Inbound  Allow

Що означає вивід: RDP дозволено, а правила брандмауера активні.

Рішення: Якщо це не jump host або термінальний сервер, вимкніть RDP або звужуйте правила брандмауера до адміністраторських підмереж. Не залишайте його загальнодоступним «на випадок».

Завдання 15: Перевірити сигнали використання NTLM у журналах Security (локальна швидка перевірка)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 50 | Where-Object { $_.Message -match 'NTLM' } | Select-Object TimeCreated,Id,Message | Select-Object -First 3 | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 9:44:10 AM 4624 ... Authentication Package: NTLM ...
2/5/2026 9:43:58 AM 4624 ... Authentication Package: NTLM ...

Що означає вивід: Нещодавні входи використовували NTLM на цій системі.

Рішення: Не можна відключати NTLM всліпу. Потрібно ідентифікувати додатки/пристрої, що його викликають, і перевести їх на Kerberos або ізолювати.

Завдання 16: Перевірити налаштування протоколів TLS (Schannel) на предмет застарілих версій

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -ErrorAction SilentlyContinue | Select-Object PSChildName | Format-Table -AutoSize"
PSChildName
-----------
TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

Що означає вивід: Ключі протоколів присутні. Наявність не означає ввімкнення/вимкнення; потрібно перевірити підключі та значення.

Рішення: На серверах вимикайте TLS 1.0/1.1 після валідації залежностей. Починайте з внутрішніх сервісів без інтернет-експозиції, потім рухайтеся назовні.

Жарт #2: Вимикання старого TLS — як прибирати під холодильником: неприємно, давно пора і ви знайдете щось, що колись було їжею.

Три корпоративні міні-історії (анонімізовано, правдоподібно й надзвичайно знайомо)

Міні-історія 1: Інцидент, викликаний хибним припущенням

Вони припустили, що «внутрішня мережа» означає «довірена мережа». Це була середня компанія з плоскою LAN, кількома VLAN і великою вірою. LLMNR і NBT-NS залишили увімкненими, бо інколи DNS в одному будинку бував ненадійним і ніхто не хотів, щоб їх розбудили через проблеми з резолюцією імен.

Атакувальник отримав доступ до одного ноутбука користувача через банальний фішинговий вкладений файл. Ніяких експлойтів ядра. Ніяких феєрверків. Потім вони запустили налаштування на кшталт responder у тій же підмережі. Середовище охоче віддавало NTLM-спроби автентифікації кожного разу, коли машина намагалася резолвити ім’я, на яке DNS не відповідав достатньо швидко.

За кілька годин у них були облікові дані, придатні для подальших дій. Не одразу «доменний адміністратор». Гірше: сервісний акаунт, який мав локальні права адміністратора на великій кількості систем, бо це полегшувало розгортання програмного забезпечення. Далі далися взнаки віддалений WMI та SMB.

Післяінцидентна зустріч мала звичні питання: «Чому брандмауер не зупинив це?» і «Чому антивірус не вистачив?» Відповідь була простішою: мережа сама долучилася до компрометації, бо була налаштована приймати небезпечну fallback-поведінку як норму.

Виправлення не було героїчним. Вони налаштували DNS правильно, вимкнули LLMNR, зменшили NTLM і перестали давати деплоймент-акаунтам широкі локальні права. Найбільша зміна була культурною: «internal» перестало бути синонімом «безпечний».

Міні-історія 2: Оптимізація, що обернулася проти

Велике підприємство хотіло швидшого віддаленого адміністрування. Їхня команда патчінгу втомилась від повільного RDP і перевантажених jump box-ів, тож хтось «оптимізував», увімкнувши WinRM повсюдно та додав широкий TrustedHosts, щоб під’єднання були «менш дратівливі». Це спрацювало. Усе стало швидше. Кількість тикетів впала.

Потім атакувальник отримав опору на робочій станції. Маючи локальні права, він зміг прочитати достатньо конфігурацій і кешованих деталей, щоб почати використовувати ті ж зручні шляхи віддаленого управління. WinRM зробив латеральний рух чистішим, тихішим і менш залежним від старих, більш голосних інструментів. TrustedHosts знизив тертя способами, які також знизили безпеку.

Коли команда реагування переглядала журнали, усе виглядало як робота ІТ: віддалені команди, віддалені сесії, легітимні протоколи. Різниця була у годинах і в хостах джерела, які не відповідали звичним адміністративним паттернам, але це тонко, коли ви під тиском.

Проблема не в самому WinRM. WinRM може бути корисним. Проблема була у включенні його скрізь без мережевого обмеження, без суворих налаштувань кінцевих точок і без жорсткого контролю ідентичності. Вони переробили підхід: WinRM тільки з жорстких адмінських робочих станцій, тільки до серверів, і з інтенсивним логуванням. На кінцевих — вимкнено, якщо нема потреби.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Фінансова компанія дотримувалась суворої моделі тьєрингу: адміністратори використовували виділені адмінські робочі станції; доменні адміністратори не переглядали веб; і керуючі протоколи були обмежені правилами брандмауера до management VLAN. Це не було гламурно. Нові працівники скаржилися. У всіх хотілися винятки.

У них також була звичка, яка виглядає як паперова робота, поки не врятує: плани змін з явними кроками відкату. Кожна зміна з хардінгу мала розділ «як це відкотити о 2 ранку», і відкат тестували в лабораторії, що реально нагадувала продакшн.

Під час інциденту ноутбук підрядника був скомпрометований поза мережею, а потім підключений на місці. Атакувальник пробував класичний латеральний рух: сканування 445, спроби SMB, WinRM, RDP. Вони швидко наштовхнулися на стіни. Порти були недоступні з того сегменту, а вкрадені облікові дані не давали доступу, бо привілеї вимагали іншого акаунта, що використовувався лише з адмінських робочих станцій.

Атакувальник все ще завдав шкоди на тому одному ендпоінті. Але організація уникнула етапу «тепер це всюди». Урок не в тому, що «ми незламні». Урок у тому, що нудка сегментація і дисциплінована адмінська гігієна перетворюють катастрофу на тикет.

Типові помилки: симптом → корінь → виправлення

1) «Після вимкнення LLMNR деякі додатки не можуть знайти сервери за короткими іменами»

Симптоми: Користувачі скаржаться, що «раніше працювало», коли вводять короткі імена; деякі старі додатки таймаутять; helpdesk бачить переривчасті збої.

Корінь: DNS неповний (відсутні A-записи, неправильні search suffix), і LLMNR/NBT-NS виконували роль тимчасової латки.

Виправлення: Виправте DNS і параметри DHCP (список пошукових суфіксів), забезпечте наявність прямих/зворотних записів там, де потрібно, і оновіть додатки для використання FQDN. Тримайте LLMNR вимкненим.

2) «Видалення SMB1 зламало критичний пристрій»

Симптоми: Сканер/копір/старий пристрій не може записати на шар; у логах — помилки переговорів.

Корінь: Прошивка пристрою підтримує лише SMB1.

Виправлення: Оновіть прошивку або замініть пристрій. До того часу: ізолюйте пристрій в окремій VLAN, обмежте SMB до виділеного файлового сервера та моніторьте доступ до цього сервера.

3) «Вимкнення WinRM зламало патчинг»

Симптоми: Патчинг не проходить; віддалена інвентаризація падає; помилка згадує WSMan або з’єднання 5985/5986.

Корінь: Ваші інструменти покладалися на WinRM, а ви його відключили без заміни чи коректного охоплення.

Виправлення: Увімкніть WinRM там, де потрібно, але обмежте вхід лише до керуючих підмереж і адмін-хостів, використовуйте HTTPS, де доречно, і приберіть широкі TrustedHosts.

4) «Після посилення правил брандмауера RDP іноді недоступний»

Симптоми: Деякі адміністратори можуть підключитися, інші — ні. Працює з офісу, але не через VPN (або навпаки).

Корінь: Сфери брандмауера, засновані на IP-діапазонах, не включають всі джерела адміністраторів; пул VPN не був врахований.

Виправлення: Чітко визначте джерела адміністраторських мереж, задокументуйте їх і забезпечте доступ до RDP через gateway/jump host замість розпорошених allowlist-ів.

5) «Вимкнення WSH зламало логон-скрипти»

Симптоми: Дискові шарінги або принтери не підключаються після входу; користувачі скаржаться одразу після логіна.

Корінь: У вас досі є VBScript логон-скрипти або застарілі GPO-скрипти.

Виправлення: Міґруйте на PowerShell-скрипти з підписуванням і логуванням, або використайте Group Policy Preferences для карт/принтерів. Після міграції тримайте WSH вимкненим на кінцевих пристроях.

6) «Вимкнення TLS 1.0 зламало інтеграцію вендора»

Симптоми: Клієнт не може підключитися; сервер показує помилки Schannel; вендор каже «вчора працювало».

Корінь: Клієнт або сервер вендора підтримує лише застарілий TLS або слабкі шифри.

Виправлення: Оновіть інтеграцію. Якщо вимушено потрібен тимчасовий виняток — ізолюйте цей ендпоінт/сервіс і встановіть термін закінчення винятку з відповідальним власником.

7) «Ми вимкнули NTLM і аутентифікація почала випадати всюди»

Симптоми: Доступ до доменних ресурсів падає; старі додатки перестали аутентифікуватися; дивні помилки входу сервісів.

Корінь: Ви пропустили фазу вимірювання і не ідентифікували залежності NTLM; це можуть бути недоменні системи, старі NAS або неправильно налаштовані SPN, що перешкоджають Kerberos.

Виправлення: Тимчасово ввімкніть назад, збирайте події аудиту NTLM, виправляйте SPN і DNS, мігруйте або ізолюйте застарілі системи, після чого поступово знову застосовуйте обмеження.

Чек-листи / покроковий план

Фаза 0: Виберіть охоплення (не намагайтеся охопити все одразу)

• Почніть з робочих станцій (високий ризик фішингу) і експозиції серверного управління (велика зона ураження).
• Визначте, що означає «завершено» для пілотної OU/групи пристроїв.
• Вирішіть шлях відкату для кожного налаштування.

Фаза 1: Інвентаризація та базова лінія (1–2 тижні)

• Знайдіть використання SMB1 (Завдання 3) на файлових серверах.
• Заміряйте використання NTLM (Завдання 15) на репрезентативних серверах і кінцевих пристроях.
• Перелік місць, де потрібен WinRM (патчинг, CM, інвентаризація).
• Ідентифікуйте використання старих скриптів (WSH, логон-скрипти, завдання).
• Занотуйте поточний стан RDP і сферу дії брандмауера (Завдання 14).

Фаза 2: Швидкі перемоги з низьким ризиком поломки (спочатку пілот)

• Вимкніть Autorun/Autoplay (через політику) на всіх кінцевих пристроях.
• Вимкніть Remote Registry на кінцевих пристроях і більшості серверів (Завдання 10/11).
• Вимкніть LLMNR через політику (Завдання 6), потім виправляйте проблеми DNS, що з’являться.
• Обмежте RDP: приберіть на кінцевих пристроях; вимагайте jump host для серверів.

Фаза 3: Високий вплив із управлінням залежностями

• Широко вимкніть SMB1 (Завдання 1/2), ізолюйте винятки.
• Загартуйте WinRM: лише з адміністраторських підмереж, розгляньте HTTPS, приберіть широкі TrustedHosts.
• Зменште NTLM: почніть з аудиту, потім обмежуйте на цінних серверах (DC, файлові).
• Вимкніть WSH на кінцевих (Завдання 13), мігруйте скрипти.
• Поетапно відключайте TLS 1.0/1.1 на серверах, валідуйте кожну інтеграцію.

Фаза 4: Закріпіть зміни (те, що більшість організацій пропускає)

• Перенесіть хардінг у стандартні збірки (gold images, CM, policy-as-code де можливо).
• Вимагайте тикетів на винятки з власниками та датами закінчення.
• Моніторьте дрейф: періодичні перевірки повторного ввімкнення служб та відкриття правил брандмауера.
• Проводьте tabletop-вправи: «Якщо робоча станція скомпрометована — що вона може дістати?»

Питання та відповіді (FAQ)

1) Чи варто повністю відключити PowerShell?

Ні. PowerShell — ядро сучасного адміністрування Windows і інструментів безпеки. Загартуйте його: логування, обмежені кінцеві точки, обмеження віддалення і хто може що запускати.

2) Чи достатньо вимкнути SMB1, щоб зупинити ransomware?

Ні. Це прибирає поширений слабкий ланцюг, але ransomware поширюється різними шляхами: вкрадені облікові дані, віддалене виконання, відкриті керуючі протоколи і погана сегментація. Розглядайте вимкнення SMB1 як обов’язковий базовий крок, а не панацею.

3) Якщо я вимкну LLMNR, щось зламається?

Можуть з’явитися проблеми, якщо ваш DNS неохайний. Це не причина залишати LLMNR; це причина виправити DNS. Почніть з пілота, потім розширюйте.

4) Чому б просто не блокувати всі вхідні адміністраторські порти скрізь?

Можна, і часто це хороша ідея, але вам все одно потрібна площина управління. Дорослий підхід: адміністраторські порти доступні лише з жорстких адмінських робочих станцій/jump hosts у management-мережі.

5) Який найбезпечніший підхід до зменшення NTLM?

Спочатку аудитуйте, потім виправляйте блокери Kerberos (DNS/SPN/розбіжність часу), потім обмежуйте NTLM на найцінніших серверах. Робіть винятки явними і тимчасовими.

6) Чи виправданий Remote Registry?

Інколи — у нішевих інструментах або для специфічного застарілого управління. Якщо лишаєте — не відкривайте широко: обмежуйте доступ брандмауером, групами адміністраторів і management підмережами. Інакше — вимикайте.

7) Нам потрібен RDP для підтримки від вендора. Який найменш поганий варіант?

Використовуйте jump host з MFA, тимчасовим доступом і записом сесій, якщо є. Не відкривайте RDP прямо в інтернет і не давайте вендорам широких облікових записів.

8) Чи можна вимкнути WSH, якщо ми багато використовуємо Office?

Так — WSH не те саме, що макроси Office. WSH — це cscript/wscript, що виконує VBScript/JScript. Деякі організації досі мають VBScript логон-скрипти; мігруйте їх перед масштабним відключенням.

9) Як уникнути зламу старих додатків при вимкненні TLS 1.0/1.1?

Інвентаризуйте сервіси, що приймають TLS, і клієнтів, що підключаються. Вимикайте поетапно: спочатку некритичні сервіси, потім критичні з планом відкату. Якщо вендор не підтримує сучасний TLS — ізолюйте інтеграцію і плануйте заміну.

10) Який найбільший «тихий ризик», який ви бачите в Windows-середовищах?

Надмірно допущені шляхи латерального руху в поєднанні з зручністю для адміністраторів: широкі локальні права адміністратора, WinRM/WMI скрізь і слабка сегментація. Атакувальникам не потрібні екзотичні прийоми, якщо середовище створено для безперешкодного руху.

Висновок: наступні кроки, які можна впровадити цього тижня

Якщо ви хочете практичного прогресу — а не фантазії про ідеальний хардінг — зробіть це за тиждень:

1. Виберіть одну пілотну групу робочих станцій і застосуйте: вимкніть LLMNR, вимкніть Remote Registry, вимкніть WSH і обмежте RDP.
2. На файлових серверах перевірте статус SMB1 і події переговору SMB1; почніть ізоляцію або оновлення пристроїв, що залежать від SMB1.
3. На серверах інвентаризуйте використання WinRM, потім обмежте вхідний WinRM до management-підмереж замість перетворення його на загальні двері.
4. Почніть вимірювати NTLM використання і створіть беклог для скорочення. Не вгадуйте.
5. Напишіть кроки відкату для кожної зміни і протестуйте їх один раз. Це різниця між впевненим розгортанням і панічним відкатом.

Вимикання ризикових функцій Windows — не про доведення середовища до «ідеалу». Це про те, щоб зробити його нудно важким для нападників і очевидно гучним, коли вони пробують рухатися.