Винятки Defender: помилка, що робить шкідливе ПЗ невидимим

Що насправді роблять винятки (і чому вони привабливі)

«Винятки» Defender звучать як дрібне налаштування. Насправді це ні. Це зміна межі безпеки. Коли ви виключаєте шлях, процес або розширення, ви кажете антивірусу, інтегрованому в ядро, притихнути в конкретних місцях — часто саме там, де шкідливе ПЗ любить оселитися, бо ці місця зайняті, шумні й наповнені довіреними бінарниками.

Більшість винятків виникає не з корисливих намірів. Вони зʼявляються через паніку з приводу продуктивності. Сервер збірки починає «тріщати». Пул VDI раптом працює, ніби на калькуляторах. Хтось запускає бенчмарк, бачить антивірусний фільтр у стеку, і інстинкт виживання організації спрацьовує: «Виключимо гарячу папку». Та папка стає гарячою зоною. Потім — сліпою плямою, яку доводиться пояснювати раді директорів.

Винятки не однакові

Defender підтримує кілька типів винятків. Кожен має інший радіус ураження і різний потенціал для зловживань:

• Винятки по шляху: «Не скануйте нічого в цій папці». Якщо цю папку можуть записувати неадміни, ви щойно створили дитячий садок для шкідливого ПЗ.
• Винятки по процесу: «Не скануйте файли, відкриті цим процесом». Це улюблене для розробників (компілятори, інструменти збірки) і для атакувальників (жити за рахунок довірених процесів).
• Винятки по розширенню: «Не скануйте файли з цим розширенням». Так ви випадково створюєте гавань для перейменованих зловмисних виконуваних файлів.
• Мережеві/UNC винятки: часто застосовуються для зниження навантаження на файловий сервер; часто неправильно зрозумілі; часто непослідовні на різних кінцях.

Чому люди все одно це роблять

Тому що це працює. Винятки можуть зменшити навантаження CPU, ввід/вивід і підвищення затримки. Вони можуть прискорити збірки розробників. Вони можуть усунути тікети «чому Outlook зависає?». Іноді вони навіть необхідні для застарілих додатків.

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

Цитата, яка має бути в кожному тікеті на виняток AV: «Сподівання — не стратегія.» — Джин Кранц

Ось у чому суть проблеми в одному реченні. Більшість рішень про винятки ґрунтуються на надії. «Сподіваємось, туди нічого поганого не потрапить.» «Сподіваємось, тільки система збірки туди пише.» «Сподіваємось, атакувальники не помітять.» Атакувальники помічають.

Як атакувальники використовують винятки

Атакувальникам не потрібно повністю вимикати Defender. Їм достатньо місця, щоб перепочити. Винятки дають їм це місце, і вони зазвичай стабільні після перезавантажень та оновлень, бо це — політика, а не тимчасовий стан виконання.

Сценарій атаки 1: «Жити в виключеному шляху»

Якщо C:\Build\ або D:\Tools\ виключені та доступні для запису, атакувальник скидає туди payload і запускає його звідти. Навіть якщо ви пізніше проскануєте диск, сканування при доступі, яке могло б заблокувати виконання, не відбулося. Деякі організації потім запускають офлайн-сканування і дивуються, чому система чиста; шкідливе ПЗ активно уникає будь-чого, що тригерить сканер.

Сценарій атаки 2: «Зловживання винятком процесу»

Винятки по процесу хитріші. Якщо ви виключили devenv.exe, msbuild.exe, node.exe або якийсь внутрішній агент, що читає й записує багато файлів, ви фактично сказали Defender: «Якщо цей процес торкається файла — не дивіться занадто пильно.»

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

Сценарій атаки 3: «Виграти війну управління»

У великих середовищах винятки керуються через групову політику, Intune, SCCM/ConfigMgr або сторонні шари політик EDR. Атакувальники люблять складність. Якщо вони здобувають адмінські права на одній машині, вони можуть не змінити централізовано застосовувані налаштування — хіба що ваша система контролю змін слабка і дозволяє локальні перевизначення, або ваші політики «татуюють» старі налаштування, які ніколи не очищуються.

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

Короткий жарт №1: Винятки — як «тимчасові» правила брандмауера — всі памʼятають, що додавали їх, ніхто не памʼятає, щоб їх видаляти.

Сценарій атаки 4: «Сховатися в загальному сховищі»

Ось кут зору інженера зберігання: люди виключають папки з високою інтенсивністю змін, бо вони викликають IO-ампліфікацію. Defender сканує операції відкриття/закриття; ваша система зберігання бачить це як додаткові читання, метадані та втрати кешу. На віддалених шарах це стає множником затримки. Тому команди виключають цілі томи, профілі або корені даних — часто на машинах із найкращими обліковими даними (адміни, агенти збірки, сервера деплойменту). Це не просто ризик. Це кошик із подарунками.

Факти та історія, які можна використати в аргументах

Кілька контекстних моментів, що допомагають, коли треба переконати завантажену організацію перестати ставитися до винятків як до безкоштовних ласощів:

1. Винятки передували сучасній логіці EDR. Традиційні AV-движки були орієнтовані на файли; винятки були грубим інструментом, щоб зробити системи придатними для роботи.
2. Біль болю продуктивності керував ранніми «найкращими практиками» в корпоративному AV. Коли ще були звичні шпиндельні диски й кілька гігабайтів ОЗП, виключення великих дерев були нормою.
3. Microsoft Defender еволюціонував у платформу. Те, що люди називають «Defender» сьогодні, включає хмарний захист, моніторинг поведінки, правила ASR і захист від маніпуляцій — отже винятки взаємодіють із багатьма шарами.
4. Атакувальники відстежують корпоративні конвенції. Папки збірки, тимчасові директорії та кеші інструментів поширені між компаніями; як тільки ви їх виключаєте, ви стандартизували місце для сховку.
5. Історично зловживали винятками по розширенню. Перейменування payload у «безпечне» розширення (або упаковка в контейнер) — старий трюк, який досі часто спрацьовує.
6. Дрейф політик реальний. Середовища накопичують винятки під час міграцій, встановлення вендорських продуктів і «тимчасових» виправлень; вони переживають цикли оновлення.
7. Сканування UNC/шарів завжди було дискусійним. Сканувати на клієнті? На сервері? Обох? Неправильна відповідь — «ніде», і це те, що створюють широкі винятки.
8. Видимість Defender залежить від логів. Якщо ви не збираєте операційні логи Defender (і не корелюєте їх із політикою), ви фактично працюєте в здогадках.
9. Винятки можуть підривати реагування на інциденти. Якщо ви збираєте артефакти з виключених шляхів, ваші інструменти live response можуть побачити файли, які Defender ігнорував під час виконання — і зʼявляться питання «чому це не спрацювало?».

Швидкий план діагностики

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

Перше: чи є винятки і звідки вони взялися?

• Перевірте локальні списки винятків Defender.
• Перевірте, чи керуються налаштування політикою (GPO/MDM).
• Перевірте стан захисту від маніпуляцій (tamper protection).

Друге: чи доступні виключені місця для запису для привілеїв, які ймовірні в атакувальника?

• Для кінцевих точок: чи може звичайний користувач там писати?
• Для серверів: чи може сервісний обліковий запис або агент збірки туди писати?
• Для спільних томів: хто має право Modfiy на шарі і NTFS?

Третє: чи логував Defender щось релевантне, чи відсутня телеметрія?

• Перегляньте операційні логи Defender навколо часу події.
• Підтвердіть, що пристрій звітує в центральну консоль безпеки.
• Перевірте, чи ваш SIEM індексує потрібні канали.

Якщо ви зробите ці три кроки, зазвичай швидко знайдете вузьке місце: або (a) винятки створили сліпу пляму, (b) політика застосована некоректно/відчужилася, або (c) ви працюєте без телеметрії.

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

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

Завдання 1: Перелічити всі винятки Defender (шляхи, процеси, розширення)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath; Get-MpPreference | Select-Object -ExpandProperty ExclusionProcess; Get-MpPreference | Select-Object -ExpandProperty ExclusionExtension"
C:\Build\
C:\Tools\Cache\
node.exe
msbuild.exe
.tmp
.log

Значення: Defender ігноруватиме ці місця/взаємодії процесів/розширення.

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

Завдання 2: Перевірити, чи керуються налаштування Defender (і ким)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled,IsTamperProtected"
AMRunningMode          : Normal
AntivirusEnabled       : True
RealTimeProtectionEnabled : True
IsTamperProtected      : True

Значення: Defender увімкнений, RTP увімкнено, і захист від маніпуляцій активний.

Рішення: Якщо захист від маніпуляцій вимкнено на кінцевих точках, увімкніть його перш ніж сперечатися про винятки. Tamper protection не вирішить усе, але підвищує вартість локального втручання.

Завдання 3: Швидко ідентифікувати широкі винятки (тест «весь диск»)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath | Where-Object {$_ -match '^[A-Z]:\\$' -or $_ -match '^[A-Z]:\\$|^[A-Z]:\\' }"
C:\
D:\

Значення: Хтось виключив цілі томи. Це не налаштування — це капітуляція.

Рішення: Відкрийте інцидентний тікет. Це терміново, якщо хост не ізольований і не компенсується іншими контролями.

Завдання 4: Перевірити стан правил ASR (і чи маскують винятки ризикову поведінку)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids; Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions | Select-Object -First 5"
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
1
1
2
1
1

Значення: Правила ASR налаштовані; дії відображають блокування/аудит/попередження залежно від мапінгу у вашому середовищі.

Рішення: Якщо ASR здебільшого в режимі «аудит», а винятки широкі, ви збираєте докази компрометації замість її запобігання. Переведіть важливі пристрої в режим блокування там, де можливо.

Завдання 5: Витягнути нещодавні виявлення Defender (локально), щоб побачити, що він бачить і що ні

cr0x@server:~$ powershell -NoProfile -Command "Get-MpThreatDetection | Select-Object -First 5 | Format-List"
ThreatID      : 2147724016
ThreatName    : Trojan:Win32/Wacatac.B!ml
ActionSuccess : True
InitialDetectionTime : 2/5/2026 8:41:12 AM
Resources     : {file:_C:\Users\jdoe\AppData\Local\Temp\q1.tmp}

Значення: Defender щось виявляє у тимчасовій локації; добре. Тепер запитайте, чи є схожі артефакти у виключених шляхах.

Рішення: Якщо виявлень мало під час активного інциденту, підозрюйте винятки, прогалини телеметрії або інший ланцюг виконання (скрипти, memory-only, зловживання підписами).

Завдання 6: Запитати операційний журнал Defender на предмет підказок про винятки

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 8:40:58 AM 1116 Microsoft Defender Antivirus detected malware or other potentially unwanted software.
2/5/2026 8:40:59 AM 1117 Microsoft Defender Antivirus took action to protect this machine from malware or other potentially unwanted software.

Значення: У вас є базова телеметрія виявлень локально.

Рішення: Якщо цей журнал порожній на машині, яку ви знаєте, що виконувала підозрілий код, перевірте, чи логування вимкнено, Defender замінено або винятки не дозволили згенерувати події сканування.

Завдання 7: Перевірити, чи підозріла папка виключена

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\Build\'; (Get-MpPreference).ExclusionPath -contains $p"
True

Значення: Папка виключена.

Рішення: Якщо ця папка використовується для прийому артефактів ззовні (пакети, збірки з PR, завантажені інструменти), вважайте її ворожою. Видаліть або звузьте виняток і компенсуйте це дружніми для продуктивності налаштуваннями сканування.

Завдання 8: Перевірити права запису на виключеному шляху (чи це drop zone?)

cr0x@server:~$ powershell -NoProfile -Command "icacls C:\Build\"
C:\Build\ BUILTIN\Administrators:(OI)(CI)(F)
         NT AUTHORITY\SYSTEM:(OI)(CI)(F)
         BUILTIN\Users:(OI)(CI)(M)
         CREATOR OWNER:(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

Значення: BUILTIN\Users мають Modify. На виключеному шляху це проблема.

Рішення: Або видаліть виняток, або ж закрийте ACL так, щоб лише необхідні сервісні обліки могли писати. Краще — і те, й інше, коли можливо.

Завдання 9: Перевірити «дриф політики» через реєстр (локальна політика проти ефективної)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths' -ErrorAction SilentlyContinue | Format-List"
C:\Build\ : 0
C:\Tools\Cache\ : 0
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths

Значення: Ці винятки, ймовірно, приходять із політики (GPO/MDM), а не як одноразове локальне виправлення.

Рішення: Виправляйте у джерелі істини. Локальне видалення зʼявиться знову після оновлення політики, і ви виглядатимете так, ніби «нічого не зробили».

Завдання 10: Визначити, чи Defender у пасивному режимі (типово при співіснуванні з EDR)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode"
AMRunningMode
------------
Normal

Значення: Defender активно захищає (не пасивний).

Рішення: Якщо ви бачите Passive або EDR Block Mode, зіставте відповідальності: який продукт виконує сканування, і де живуть винятки? Розділена безпека — це як залишити охоронця в туалеті.

Завдання 11: Зафіксувати налаштування захисту в режимі реального часу, що впливають на продуктивність

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object DisableRealtimeMonitoring,DisableIOAVProtection,DisableArchiveScanning,DisableBehaviorMonitoring | Format-List"
DisableRealtimeMonitoring : False
DisableIOAVProtection     : False
DisableArchiveScanning    : False
DisableBehaviorMonitoring : False

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

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

Завдання 12: Запустити контрольоване сканування конкретної папки (щоб виміряти вплив перед зміною політики)

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { Start-MpScan -ScanType CustomScan -ScanPath 'C:\Build\' } | Select-Object TotalSeconds"
TotalSeconds
------------
38.421

Значення: Користувацьке сканування цієї папки займає ~38 секунд на цьому хості. Це дані.

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

Завдання 13: Підтвердити, чи увімкнено хмарний захист (допомагає ловити масові загрози)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object MAPSReporting,SubmitSamplesConsent | Format-List"
MAPSReporting       : Advanced
SubmitSamplesConsent: SendSafeSamples

Значення: Хмарний захист і відправка зразків ввімкнені на адекватному рівні.

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

Завдання 14: Знайти нещодавні зміни налаштувань Defender (орієнтовний сигнал через логи подій)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 200 | Where-Object {$_.Id -in 5007} | Select-Object -First 5 TimeCreated,Message | Format-List"
TimeCreated : 2/5/2026 7:58:21 AM
Message     : Microsoft Defender Antivirus configuration has changed. If this is an unexpected event you should review the settings...

Значення: Event ID 5007 вказує на зміну конфігурації. Він не завжди скаже точно що, але підкаже коли.

Рішення: Корелюйте часову позначку з вікнами змін, оновленнями GPO, пушами Intune або підозрілою адмін-активністю. Якщо це поза контролем змін — ескалюйте.

Короткий жарт №2: Найшвидший спосіб пришвидшити Defender — виключити C:\. Також найшвидший спосіб пришвидшити реагування на інциденти… бо воно ніколи не закінчується.

Три міні-історії з корпоративних реалій

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

Компанія мала «стандартний базовий набір жорсткого захисту». Він добре виглядав у слайдах: Defender увімкнено, захист від маніпуляцій увімкнено, правила ASR активні (здебільшого в режимі аудиту), і «ретельно відібрані» винятки для продуктивності розробників. Усім подобалося ключове словосполучення: ретельно відібрані.

Під час розслідування підозрілого адміністративного входу респондери знайшли нове заплановане завдання, що запускало бінарник з C:\DevTools\. Ніяких алертів. Ніяких блокувань. Хеш файлу не був у відомих поганих наборах. Машина була інакше чистою. Перше припущення команди було класичним: «Напевно, це malware, що живе в памʼяті». Це припущення втратило час.

Насправді історія була нуднішою. C:\DevTools\ виключали роками через тепер уже списаний IDE, який погано працював з on-access скануванням. Папка залишилася в базісі, бо ніхто не хотів бути тим, хто зламає розробницьке середовище. Згодом ACL змінився. Група звичайних користувачів отримала Modify. Атакувальнику не потрібні були хитрі обхідні шляхи. Потрібна була лише записувана, виключена директорія та заплановане завдання.

Що боліло — не сам виняток. Боліло припущення, що винятки статичні, безпечні й переглянуті. Розслідування завершилося прибиранням політик, закриттям ACL і незручною усвідомленістю: базова конфігурація ніколи не тестувалася проти моделі нападника. Її тестували проти моделі служби підтримки.

Міні-історія 2: Оптимізація, яка вдарила у спину

Команда платформи керувала флотом Windows-агентів збірки. Після оновлення збірки стали повільні, і метрики показували сплески файлового IO. Робочий простір збірки містив тисячі дрібних файлів — кеші залежностей, розпаковані архіви, проміжні обʼєкти. Defender робив свою роботу: інспектував файлові операції.

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

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

Коли вони відкочували виняток, збірки знову сповільнилися — і тепер команда мала дві проблеми: безпека і продуктивність. Оптимізація не була неправильною сама по собі. Помилка була в радіусі ураження і відсутності компенсуючих контролів: жодної ізольованої мережі для збірок, жодних обмежень на запис, відсутність сканування при вхідних/вихідних артефактах, відсутність окремих проміжних томів з контрольованим доступом.

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

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

Інша організація мала політику, яку ніхто не любив: кожен виняток вимагав тікет із (1) виміряним впливом на продуктивність, (2) власником, (3) терміном закінчення і (4) оглядом ACL для виключеного місця. Люди скаржилися. Звісно, скаржилися. Це була зайва робота і гальмувала «швидкі виправлення».

Одного дня аналітик помітив дивну послідовність: машина, що запускала легітимний підписаний інструмент, неодноразово торкалася файлів у виключеній папці, яку використовував прикладний додаток для бізнесу. Ніяких хітів Defender. Але SIEM мав події створення файлів і логи запуску процесів (з іншої телеметрії), які не мали нормального вигляду.

Ключова деталь: тікет на виняток для тієї папки мав термін дії. Він мав бути переобґрунтований, і переобґрунтування вимагає перевірки прав запису. Коли перевірили, виявилось, що вендор змінив поведінку інсталятора; він розширив ACL під час оновлення. Виняток безшумно став небезпечним.

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

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

1) Симптом: «Defender увімкнено, але він ніколи не сигналізує на цьому хості»

Корінь: Шкідливе ПЗ виконується з виключених шляхів або через виключені процеси; Defender працює за конфігурацією.

Виправлення: Проведіть аудит винятків; видаліть широкі шляхи; перевірте ACL; додайте телеметрію виявлення для створення процесів і скриптової активності; повторно проскануйте раніше виключені локації контрольованим користувацьким скануванням.

2) Симптом: «Ми видалили виняток, але він повертається»

Корінь: Керована політика (GPO/Intune/ConfigMgr) повторно його застосовує, або залишилися «тату» в реєстрі.

Виправлення: Знайдіть джерело істини (шляхи політик у реєстрі та у системах управління пристроями); змінюйте централізовано; підтвердіть оновлення політики; документуйте власника і термін дії.

3) Симптом: «Лише розробники потерпають; інші — ні»

Корінь: Інструменти розробників або кеші збірки отримали винятки по процесу (наприклад, node.exe, msbuild.exe) або великі винятки шляхів на машинах розробників.

Виправлення: Замініть винятки по процесу на винятки шляхів у директоріях, які не доступні для запису користувачам, або ізолюйте кеші на рівні користувача зі скануванням під час завантаження; забезпечте найменші права на директорії інструментів.

4) Симптом: «VDI повільний, тому ми виключили профілі»

Корінь: Виключення C:\Users\ або дерев профілів, щоб зменшити навантаження під час логону і IO.

Виправлення: Не виключайте цілі профілі. Налаштуйте розклад сканування, увімкніть параметри продуктивності і націлюйте винятки на відомі великі, але низькоризикові кеші з жорсткими ACL. Розгляньте рішення з контейнеризацією профілів зі скануванням на межі контейнера.

5) Симптом: «CPU файлового сервера високий, тому ми виключили шари на клієнтах»

Корінь: Невизначеність, де сканування має відбуватися; виключення на клієнті зменшують навантаження, але створюють сліпі плями для файлів, до яких звертаються по SMB.

Виправлення: Ясно визначте відповідальність за сканування: скануйте при вході (на сервері) і/або на виході (на клієнті) залежно від ризику. Якщо ви виключаєте на клієнтах, забезпечте сканування на сервері й жорсткі правила запису і фільтрації файлів.

6) Симптом: «Ми виключили .log і .tmp, щоб зменшити шум»

Корінь: Надто широкі винятки по розширенню легко зловживати; payload може зберігатися з недвозначним розширенням.

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

7) Симптом: «Після встановлення вендорського додатку Defender перестав фіксувати його папку»

Корінь: Інсталятор вендора додав винятки (інколи виправдано, інколи абияк) і вони збереглися після оновлень.

Виправлення: Інвентаризуйте зміни після інсталяції (event ID 5007); вимагайте від вендора обґрунтування; звужуйте винятки; забороніть вендорам виключати записувані каталоги плагінів.

8) Симптом: «IR-скан знаходить шкідливе ПЗ, але воно не блокувалось раніше»

Корінь: Виконання відбулося з виключеної області або через виключений процес; пізніші скани використовували інші движки/режими або сканування відбулося після появи IOC.

Виправлення: Розглядайте винятки як первинного підозрюваного. Узгодьте превентивні контролі (сканування при доступі) з детективними (IR-сканування), щоб не порівнювати яблука з фруктовим салатом.

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

Покроково: Як виправити винятки без порушення продакшену

1. Інвентаризуйте ефективні винятки на типових кінцевих точках (розробка, VDI, сервери, кіоски). Категоризуйте за типом: шлях/процес/розширення.
2. Класифікуйте кожен виняток за ризиком:
   • Чи має виключене місце права запису для звичайних користувачів або широких груп?
   • Чи отримує воно недовірений контент (завантаження, вкладення, залежності збірки, імпорт з USB)?
   • Чи запускаються звідти виконувані файли?
3. Знайдіть власника (команда або додаток). Якщо власника немає — це вже проблема.
4. Додайте термін дії для кожного винятку. «Постійний» — це запах проблеми.
5. Звужуйте область:
   • Краще виключити конкретну підпапку кешу, ніж весь робочий простір.
   • Краще виключити директорію з не виконуваними даними, ніж директорію з інструментами.
   • Уникайте винятків по процесу, якщо не можете довести, що вони не створюють сліпих зон виконання.
6. Закрийте ACL на виключених шляхах. Якщо шлях виключено, він не повинен бути загальнодоступним для запису. Якщо запис має бути можливим — ізолюйте і скануйте на межі.
7. Вимірюйте продуктивність до й після за повторюваними тестами (час збірки, метрики IO). Немає бенчмарків — немає винятків.
8. Розгортайте по кільцям: пілот, ширша когорта, потім повний продакшен. Винятки множать ризики; не робіть «баг-банг» змін.
9. Моніторьте сигнали:
   • Операційні події Defender (зміни конфігурації, виявлення).
   • CPU і довжину черги диску на кінцевих точках і файлових серверах.
   • Тікети служби підтримки з тегами продуктивності або сумісності додатків.
10. Документуйте компенсуючі контролі, якщо винятки залишаються: обмеження на запис, біловий список застосунків, серверне сканування, сканування артефактів у CI/CD.
11. Повторний аудит щоквартально або після великих оновлень. Дриф трапляється тихо; потрібно регулярне виявлення.

Чекліст: Як має виглядати прийнятний запит на виняток

• Точний шлях/процес/розширення і обґрунтування, повʼязане з вимірюваним впливом.
• Доказ прав запису та перелік принципалів, які можуть писати.
• Чи може локація містити виконувані файли або скрипти.
• Компенсуючі заходи (наприклад, сканування при завантаженні, ізоляція агентів збірки, підписування артефактів).
• Власник і термін дії.
• План відкату і поетапне розгортання.

Чекліст: Червоні прапори (тримати як інцидент, а не як запит на налаштування)

• Виключення C:\, D:\, коренів профілів користувачів або цілих коренів застосунків з плагінами/макросами.
• Виключення загальних інструментів (powershell.exe, wscript.exe, cmd.exe) або хостів скриптів. Це майже письмове запрошення.
• Винятки без власника або «ми не знаємо навіщо, але це тут давно».
• Винятки на машинах з високими привілеями (сервера деплойmentu, хости для адмінів) без компенсуючих заходів.
• Винятки по розширеннях для типів, що можуть містити код на практиці (або їх легко перейменувати).

Питання й відповіді

1) Чи завжди винятки Defender — це погано?

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

2) Що гірше: виняток по шляху чи виняток по процесу?

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

3) Чи можуть атакувальники додати винятки самі?

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

4) Якщо захист від маніпуляцій увімкнено, чи ми в безпеці?

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

5) Ми виключаємо кеші збірки. Як робити це безпечно?

Зробіть виключену директорію кешу недоступною для запису людьми, лише обліковому запису агента збірки. Скануйте залежності під час завантаження, скануйте артефакти при публікації, тримайте агенти збірки ізольованими та відновлюваними. Звужуйте виняток до кешу, а не до робочого простору.

6) Чи слід виключати файли бази даних через продуктивність?

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

7) Чому винятки «повертаються» після видалення?

Бо ваше середовище управляється. GPO/MDM повторно застосовують налаштування, а деякі застарілі політики залишаються в реєстрових ключах, поки їх не видалять централізовано. Завжди виправляйте джерело політики, а не лише кінцевий пристрій.

8) Як виявити, що виключений шлях використовує шкідливе ПЗ?

Використовуйте іншу телеметрію: логи створення процесів, аудит створення файлів, Sysmon (де розгорнутий), датчики EDR і підозрілі заплановані завдання/сервіси, що вказують на виключені директорії. Також шукайте події зміни конфігурації Defender і раптові сплески створення файлів у виключених шляхах.

9) Чи прийнятні винятки по розширеннях?

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

10) Яка безпечна політика за замовчуванням?

За замовчуванням — без винятків. Додавайте їх лише з вимірюваним обґрунтуванням, власником, терміном дії і перевіркою ACL. Для продуктивності віддавайте перевагу налаштуванню розкладів сканування й звуженню області над широкими винятками.

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

Якщо ви використовуєте Windows у масштабі, у вас уже є винятки. Питання в тому, чи це контрольовані інженерні рішення, чи закам’яніла паніка.

1. Експортуйте ефективні винятки з репрезентативної вибірки кінцевих точок і серверів. Зробіть список у зрозумілому для людей вигляді.
2. Позначте очевидні ризики: виключення цілих томів, виключені шляхи доступні для запису, широкі виключення процесів.
3. Знайдіть джерело політики (локально чи керовано) і призначте власника для кожної групи винятків.
4. Закрийте права доступу на будь-якому виключеному шляху, що має залишитися. Якщо його може редагувати «Users», це не виняток — це поверхня атаки.
5. Поставте терміни дії на все і заплануйте щоквартальний огляд. Нудний процес — той, що працює, коли змінюються люди і памʼять зникає.

Найкращий час виправити винятки — до інциденту. Другий найкращий — одразу після того, як ви закінчите читати це і перед наступною зустріччю «чому Defender цього не спіймав?».