Уязвимость Kaspersky Endpoint Security: риск для привилегированного доступа

Уязвимость Kaspersky Endpoint Security: что произошло

Исследователь под псевдонимом NightmareEclipse 31 августа 2026 года опубликовал в открытом доступе экспериментальный proof-of-concept HardBreacher, который демонстрирует уязвимость Kaspersky Endpoint Security — одного из самых распространённых средств защиты конечных точек среди компаний России. С его помощью учётная запись без административных прав записала файл в защищённый системный каталог Windows, обойдя штатные ограничения операционной системы.

Тестирование эксплойта выполнялось на паре Kaspersky Endpoint Security версии 14.0.0.504 и Windows 11 25H2 с актуальными обновлениями. В результате в каталоге System32 появлялся файл _MY_SNAKE_IS_SOLID.dll, причём непривилегированный аккаунт получал на него полный набор прав доступа — при штатной работе системы такая операция недоступна рядовому пользователю даже в случае компрометации его учётных данных.

Причина кроется в механизме обмена данными между защитным продуктом и его собственным интерфейсным процессом: доверие внутри этого канала связи между компонентами и позволило обойти проверку прав доступа.

Сводка: ключевые факты о находке

Таблица собирает исключительно подтверждённые сведения на момент публикации — без домыслов о том, что ещё не прокомментировали ни автор находки, ни вендор.

Получил ли атакующий права SYSTEM: техническая суть эксплойта

Автор находки прямо отмечает: стабильно выполнить произвольный код с правами SYSTEM ему продемонстрировать не удалось — HardBreacher работает нестабильно и нередко завершается ошибкой. Но сама по себе способность бесконтрольно записывать данные в System32 от имени непривилегированного пользователя вызывает беспокойство: такой примитив часто служит первым звеном в цепочке эскалации привилегий, пусть и не давая злоумышленнику мгновенный полный контроль над системой.

Официальный номер CVE находке пока не присвоен, независимую проверку инструмент не проходил и в бюллетенях других вендоров не упоминается. При этом «Лаборатория Касперского» подтвердила проблему официально и подготовила исправление, которое устанавливается автоматически вместе с обычным обновлением продукта — без дополнительных действий со стороны администратора.

Почему у уязвимости пока нет CVE и записи в БДУ ФСТЭК

Отсутствие официального идентификатора не означает, что находка несерьёзна или недостоверна, — это лишь этап процедуры классификации, через который проходит любая уязвимость. Номера CVE присваивают уполномоченные организации-нумераторы (CNA), и происходит это только после подтверждения проблемы производителем; от подачи заявки до получения номера может пройти от нескольких дней до нескольких месяцев в зависимости от загрузки нумератора и полноты предоставленных материалов.

Реестр БДУ (банк данных угроз безопасности информации) поддерживает ФСТЭК России и использует его как базу для оценки угроз, в том числе применительно к объектам критической информационной инфраструктуры в рамках 187-ФЗ. Для организаций, которым по требованиям к КИИ необходимо учитывать угрозы безопасности информации, запись в БДУ ФСТЭК становится важным ориентиром при пересмотре модели угроз — поэтому такие компании обычно мониторят реестр вне зависимости от присвоения CVE.

Здесь производитель уже официально подтвердил проблему и выпустил патч, поэтому формальная классификация уходит на второй план по сравнению с фактическим устранением риска. Тем не менее компаниям, для которых важен комплаенс, стоит периодически проверять появление записи в БДУ ФСТЭК и следить за публикациями на профильных ресурсах вроде Securelist, где «Лаборатория Касперского» размещает технические разборы закрытых уязвимостей.

Кого затрагивает эта уязвимость

Под угрозой оказывается любая компания, которая использует этот продукт как основное средство защиты Windows-станций и серверов, — а среди среднего и крупного бизнеса в России таких немало. Особенно уязвимы организации, где защита конечных точек — единственный барьер контроля привилегий на рабочих местах, без дополнительных мер вроде управления привилегированным доступом (PAM) и жёсткого ограничения локальных администраторов.

Без централизованного контроля обновлений защитного ПО часть рабочих станций может неделями оставаться на уязвимой версии продукта — и именно эти узлы окажутся первой мишенью, если эксплойт станет более стабильным.

Как обнаружить попытки эксплуатации, не дожидаясь публичных вердиктов

Компания-производитель официально не сообщает, появились ли под эту проблему отдельные сигнатуры или поведенческие правила детектирования, — известно только, что она устранена патчем на уровне самого продукта. Поэтому организациям, для которых риск особенно критичен, стоит не полагаться только на защитное ПО, а наладить собственный контроль на уровне журналов операционной системы.

На практике стоит настроить в SIEM или EDR корреляцию событий создания файлов в системных каталогах Windows (например, Sysmon Event ID 11 для System32) и включить оповещения о записи со стороны нетипичных для этого процессов — в том числе компонентов самого антивируса. Также полезно зафиксировать эталонный список DLL и исполняемых файлов в System32 и периодически сверять его с реальным состоянием на критичных серверах: так незнакомый файл обнаружат быстрее, чем при ожидании обновления баз.

Перед развёртыванием обновления на всей инфраструктуре разумно сначала опробовать патч на ограниченной группе машин — стандартный приём, который снижает риск проблем совместимости и не останавливает бизнес-процессы.

Почему уязвимость в антивирусе — это риск для привилегированного доступа

Это далеко не рядовое приложение: продукт обладает широкими правами в системе и на диске, поэтому любая брешь в его защите потенциально расширяет площадь атаки на привилегированный доступ в целом. Если защитное решение удаётся обмануть, под сомнением оказывается сама идея «средство защиты равно доверенный узел», на которой строится модель безопасности многих организаций.

Для бизнеса это повод пересмотреть не частный случай, а весь подход к контролю привилегированного доступа: кто и как получает права локального администратора, отслеживаются ли попытки записи в системные каталоги, насколько быстро защитное ПО обновляется на всех узлах сети. Точечная эскалация привилегий на одной машине сама по себе не катастрофа, но в связке с украденными учётными данными или фишингом она способна стать звеном полноценной атаки на инфраструктуру.

Что делать бизнесу: чек-лист после новости об уязвимости

Патч для этой проблемы уже выпущен и распространяется автоматически, поэтому основная задача сейчас — не ждать исправления, а контролировать его установку и параллельно усиливать более широкие меры защиты привилегированного доступа.

1. Проверьте, что все рабочие станции и серверы с установленным продуктом получили свежее обновление баз и модулей; там, где автообновление отключено политикой, запустите проверку вручную.
2. Сократите число учётных записей с локальными правами администратора на рабочих местах; там, где административный доступ действительно нужен, заводите под него отдельные привилегированные учётки под контролем PAM-решения.
3. Настройте мониторинг попыток записи в системные каталоги Windows, включая System32, со стороны процессов, для которых такое поведение нетипично.
4. Включите многофакторную аутентификацию для всех административных и привилегированных учётных записей: саму брешь в защитном ПО это не закроет, зато заметно осложнит злоумышленнику использование украденного или подобранного пароля после локальной эскалации.
5. Регулярно пересматривайте права сотрудников и подрядчиков и отключайте неактивные учётные записи: избыточные права на рабочих местах увеличивают потенциальный ущерб от любой локальной уязвимости.
6. Подпишитесь на бюллетени безопасности вендора используемого защитного ПО, чтобы не пропустить дальнейшие сообщения по этой и смежным темам.

Частые вопросы

Что такое уязвимость HardBreacher в Kaspersky Endpoint Security?

Это экспериментальный proof-of-concept, который исследователь NightmareEclipse опубликовал 31 августа 2026 года. Он использует недочёт во взаимодействии продукта с собственным интерфейсным процессом и позволяет пользователю без привилегий записать файл в защищённый системный каталог Windows System32.

Получил ли исследователь права SYSTEM с помощью эксплойта?

Нет. Сам автор отмечает, что стабильно выполнить произвольный код с правами SYSTEM не получилось — HardBreacher работает нестабильно и нередко завершается ошибкой. Подтверждён лишь факт записи файла в System32 от имени обычного пользователя.

Присвоен ли уязвимости номер CVE?

На момент публикации официальный номер CVE не присвоен: инструмент не проходил независимую проверку и не упоминается в бюллетенях других вендоров. При этом «Лаборатория Касперского» официально подтвердила саму проблему.

Как проверить, что проблема в продукте уже устранена?

Вендор выпустил исправление, которое ставится автоматически вместе со штатным обновлением продукта. Администраторам стоит убедиться, что автообновление включено, а версии на всех узлах сети актуальны.

Нужно ли отслеживать эту уязвимость в реестре БДУ ФСТЭК для соответствия 187-ФЗ?

Организациям, относящимся к субъектам критической информационной инфраструктуры, стоит отслеживать появление записи в БДУ ФСТЭК при обновлении модели угроз. На момент публикации записи по этой проблеме в реестре нет, однако патч вендора уже устраняет саму причину — независимо от её формальной классификации.

Стоит ли менять антивирус из-за этой уязвимости?

Одна проблема, не подтверждённая независимо и уже закрытая патчем вендора, — недостаточный повод менять защитный продукт во всей инфраструктуре. Разумнее вовремя устанавливать обновления и усиливать меры контроля, которые не зависят от антивируса: ограничение прав администратора, MFA и PAM.

Как защитить привилегированный доступ, если уязвимость нашли в самом антивирусе?

Одного защитного ПО недостаточно — нужны меры, не зависящие от него: ограничение локальных прав администратора, многофакторная аутентификация для привилегированных учёток и управление привилегированным доступом (PAM), которое контролирует и фиксирует действия администраторов даже на потенциально скомпрометированном узле.

Итог: что важно запомнить бизнесу

Эта история ещё раз подтвердила: даже надёжное защитное ПО не снимает необходимости отдельно контролировать привилегированный доступ внутри компании. Патч уже выпущен, но рассчитывать только на обновления антивируса — не стратегия защиты, а её отсутствие.

Смягчить последствия подобных инцидентов позволяет эшелонированная защита: жёсткий контроль локальных администраторов, многофакторная аутентификация при входе в Windows, VPN и другие критичные системы, а также управление привилегированным доступом, которое ограничивает и фиксирует действия администраторов даже на скомпрометированном узле. Как партнёр СКБ Контур, мы помогаем бизнесу выстраивать такую защиту на базе решений линейки Контур.Эгида; если нужно понять, какие меры контроля привилегированного доступа и MFA подойдут именно вашей инфраструктуре, — обращайтесь за консультацией.