Обнаружен тихий метод блокировки EDR-агентов ниже уровня фильтрации пакетов
NewsMakerИсследователь показал технику, при которой агент безопасности не падает, но перестает передавать телеметрию.
У EDR-систем появился неприятный способ «ослепнуть» без взлома самого агента. Новый открытый инструмент EDRChoker показывает, что защитный процесс можно не убивать, не подменять и не атаковать напрямую. Достаточно почти полностью перекрыть для него сетевой канал через штатный механизм Windows, и агент продолжит выглядеть живым, но потеряет связь с облаком.
Инструмент разработал исследователь под ником @TwoSevenOneT. EDRChoker использует Windows Policy-Based Quality of Service, встроенный механизм управления качеством обслуживания сети. Обычно QoS нужен для приоритизации трафика, но в данном случае механизм превращается в способ резко ограничить пропускную способность для конкретных процессов. Для EDR-агента такая настройка означает почти полную изоляцию от серверов управления.
Современные EDR-платформы сильно зависят от постоянной связи между агентом на конечной точке и облачной инфраструктурой поставщика. Через этот канал уходят события безопасности, телеметрия и сигналы о подозрительной активности. По тому же каналу агент получает политики, команды администраторов и обновленные правила реакции. Когда связь рвется, защитная система не обязательно падает, но теряет одну из главных функций — быстро сообщать центру управления о происходящем на устройстве.
Раньше красные команды чаще мешали такой связи более прямыми способами. Например, создавали правила Windows Defender Firewall или использовали Windows Filtering Platform, чтобы отбрасывать исходящие пакеты EDR-агентов. У такого подхода есть заметный минус для атакующего: события блокировки и сброса пакетов хорошо видны многим защитным продуктам. Некоторые решения, включая Elastic Defend, уже умеют ловить подобные попытки обхода через WFP и поднимать тревогу.
EDRChoker идет по более тихому пути. Инструмент не запрещает трафик полностью, а снижает доступную скорость почти до нуля. На практике агент пытается подключиться к серверу, но соединение постоянно упирается в тайм-ауты. Даже обычное TLS-рукопожатие требует обмена несколькими килобайтами данных, включая цепочку сертификатов, а при искусственно «задушенном» канале нормальный обмен просто не успевает завершиться. Со стороны ситуация больше похожа на сетевую проблему, чем на классическую блокировку.
Техническая особенность связана с тем, где именно Windows применяет такие ограничения. Политики QoS обслуживает компонент pacer.sys, NDIS Lightweight Filter Driver. Он работает ближе к сетевому адаптеру, ниже уровня Windows Filtering Platform в сетевом стеке. Из-за этого мониторинг, который смотрит в основном на WFP-события, может не увидеть привычной картины блокировки. Трафик ограничивается раньше, чем до него добираются некоторые механизмы контроля.
По словам автора, EDRChoker принимает файл со списком процессов EDR и автоматически создает для них отдельные политики QoS. Для каждой политики используется имя процесса и случайный GUID, чтобы разные запуски инструмента не выглядели одинаково. Инструмент также умеет удалять созданные политики и очищать следы настройки.
Главный риск EDRChoker не в отдельной утилите, а в самой идее. Многие компании привыкли смотреть на EDR как на почти постоянный источник правды о конечных точках. Но облачная архитектура держится на стабильной связи. Если агент не может говорить с сервером, центр мониторинга получает не полную картину, а удобную иллюзию контроля. Процесс на машине все еще работает, значок может выглядеть спокойно, но телеметрия уже не доходит туда, где должна превратиться в тревогу и реакцию.
Для защитников вывод довольно неприятный, зато полезный. Одного контроля процессов, служб, firewall-правил и WFP-событий мало. Нужно следить за изменениями QoS-политик, подозрительными ограничениями полосы для защитных процессов и странными тайм-аутами у EDR-агентов. Чем глубже атакующие спускаются в сетевой стек Windows, тем меньше пользы от мониторинга только верхних уровней. Иначе организация рискует узнать о проблеме в самый классический момент индустрии безопасности — слишком поздно.
У EDR-систем появился неприятный способ «ослепнуть» без взлома самого агента. Новый открытый инструмент EDRChoker показывает, что защитный процесс можно не убивать, не подменять и не атаковать напрямую. Достаточно почти полностью перекрыть для него сетевой канал через штатный механизм Windows, и агент продолжит выглядеть живым, но потеряет связь с облаком.
Инструмент разработал исследователь под ником @TwoSevenOneT. EDRChoker использует Windows Policy-Based Quality of Service, встроенный механизм управления качеством обслуживания сети. Обычно QoS нужен для приоритизации трафика, но в данном случае механизм превращается в способ резко ограничить пропускную способность для конкретных процессов. Для EDR-агента такая настройка означает почти полную изоляцию от серверов управления.
Современные EDR-платформы сильно зависят от постоянной связи между агентом на конечной точке и облачной инфраструктурой поставщика. Через этот канал уходят события безопасности, телеметрия и сигналы о подозрительной активности. По тому же каналу агент получает политики, команды администраторов и обновленные правила реакции. Когда связь рвется, защитная система не обязательно падает, но теряет одну из главных функций — быстро сообщать центру управления о происходящем на устройстве.
Раньше красные команды чаще мешали такой связи более прямыми способами. Например, создавали правила Windows Defender Firewall или использовали Windows Filtering Platform, чтобы отбрасывать исходящие пакеты EDR-агентов. У такого подхода есть заметный минус для атакующего: события блокировки и сброса пакетов хорошо видны многим защитным продуктам. Некоторые решения, включая Elastic Defend, уже умеют ловить подобные попытки обхода через WFP и поднимать тревогу.
EDRChoker идет по более тихому пути. Инструмент не запрещает трафик полностью, а снижает доступную скорость почти до нуля. На практике агент пытается подключиться к серверу, но соединение постоянно упирается в тайм-ауты. Даже обычное TLS-рукопожатие требует обмена несколькими килобайтами данных, включая цепочку сертификатов, а при искусственно «задушенном» канале нормальный обмен просто не успевает завершиться. Со стороны ситуация больше похожа на сетевую проблему, чем на классическую блокировку.
Техническая особенность связана с тем, где именно Windows применяет такие ограничения. Политики QoS обслуживает компонент pacer.sys, NDIS Lightweight Filter Driver. Он работает ближе к сетевому адаптеру, ниже уровня Windows Filtering Platform в сетевом стеке. Из-за этого мониторинг, который смотрит в основном на WFP-события, может не увидеть привычной картины блокировки. Трафик ограничивается раньше, чем до него добираются некоторые механизмы контроля.
По словам автора, EDRChoker принимает файл со списком процессов EDR и автоматически создает для них отдельные политики QoS. Для каждой политики используется имя процесса и случайный GUID, чтобы разные запуски инструмента не выглядели одинаково. Инструмент также умеет удалять созданные политики и очищать следы настройки.
Главный риск EDRChoker не в отдельной утилите, а в самой идее. Многие компании привыкли смотреть на EDR как на почти постоянный источник правды о конечных точках. Но облачная архитектура держится на стабильной связи. Если агент не может говорить с сервером, центр мониторинга получает не полную картину, а удобную иллюзию контроля. Процесс на машине все еще работает, значок может выглядеть спокойно, но телеметрия уже не доходит туда, где должна превратиться в тревогу и реакцию.
Для защитников вывод довольно неприятный, зато полезный. Одного контроля процессов, служб, firewall-правил и WFP-событий мало. Нужно следить за изменениями QoS-политик, подозрительными ограничениями полосы для защитных процессов и странными тайм-аутами у EDR-агентов. Чем глубже атакующие спускаются в сетевой стек Windows, тем меньше пользы от мониторинга только верхних уровней. Иначе организация рискует узнать о проблеме в самый классический момент индустрии безопасности — слишком поздно.