Уязвимость нулевого дня KnowledgeDeliver: 100% установок с одним hardcoded ключом

Сто процентов установок KnowledgeDeliver, выпущенных до 24 февраля 2026 года, подвержены одной и той же уязвимости нулевого дня, поскольку каждая из них содержала одинаковый hardcoded ASP.NET machineKey внутри стандартизированного web.config. Это не уязвимость в привычном смысле — это архитектура с общим секретом, маскирующаяся под неё. CVE-2026-5426 имеет оценку CVSS 7.5, которая занижает операционную серьёзность, если учесть, что предварительное условие (знание ключа) было выполнено для каждого клиента в первый же день развёртывания.

Цифры

Определим масштаб. KnowledgeDeliver — это система управления обучением (LMS), созданная компанией Digital Knowledge, используемая преимущественно в японских корпоративных и образовательных средах. Как сообщает SecurityWeek, принадлежащий Google Mandiant связывает эксплуатацию с угрозами, использующими атаки десериализации ViewState на основе hardcoded ключей, что в итоге привело к размещению веб-шеллов Godzilla и бэкдора Cobalt Strike в инфраструктуре жертв.

Оценка CVSS 7.5 заслуживает отдельного внимания. На бумаге 7.5 читается как «высокий, но не критический». На практике предварительное условие для эксплуатации — знание machineKey — было фактически заранее выполнено для каждой установки. Сравните это с CVE-2017-9248 в Telerik UI или с длинными цепочками ViewState в Sitecore: там требовались либо криптографические слабости, либо конкретные ошибки конфигурации для каждого развёртывания. Здесь ошибкой стал вендорский дефолт, распространившийся на всю клиентскую базу. Фактическое число уязвимых установок ближе к «все, кто скачал продукт», а не к «все, кто неправильно его настроил». Поищите CVE-2026-5426 — оценка не отражает это различие.

Цепочка атаки заслуживает детального разбора, поскольку каждый этап увеличивает затраты для защитников. Этап первый: десериализация ViewState, выполнение кода на стороне сервера. Этап второй: работающий в памяти веб-шелл Godzilla (также известный как Bluebeam), который не записывается на диск и обходит сигнатурное сканирование файлов. Этап третий: изменение ACL каталога в корне веб-приложения. Этап четвёртый: подмена JavaScript-файла в LMS, отображающего фальшивое предупреждение безопасности с предложением установить поддельный плагин. Этап пятый: Cobalt Strike, зашифрованный с ключом, содержащим название организации-жертвы.

Последняя деталь важнее, чем кажется. Mandiant оценивает, что пейлоад Cobalt Strike был подготовлен специально для целевой организации, что подразумевает разведку и инструментарий, адаптированный под каждую жертву, а не массовые атаки. Источник не раскрывает, сколько организаций пострадало, а это важно, поскольку определяет, была ли это точечная кампания против небольшого числа высокоценных японских целей или начало более широкого охвата. Если эксплуатация расширится, в течение 60 дней от Mandiant или JPCERT/CC следует ожидать публикации телеметрии с пересмотром числа жертв в сторону увеличения.

Что действительно нового

Десериализация ViewState — не новый класс уязвимостей. Она встречалась при эксплуатации Sitecore, в развёртываниях CentreStack и как повторяющийся вектор в кампаниях с использованием фреймворка Godzilla. Сама техника — заимствованная. Действительно новым является форма цепочки поставок в качестве предварительного условия.

В случаях с Sitecore и CentreStack злоумышленникам, как правило, приходилось извлекать или угадывать machineKey для каждой цели. Экономика была на стороне защитников: каждая новая жертва требовала свежей разведки. KnowledgeDeliver обнуляет этот экономический градиент. Как только любая отдельная установка инспектируется, или как только стандартизированный web.config получен из любого источника (утёкший образ установки, неправильно настроенный публичный экземпляр, бывший клиент), злоумышленник получает универсальный ключ для каждого развёртывания до 24 февраля. По форме это ближе к инцидентам с hardcoded-учётными данными от вендоров в 2024 году, чем к традиционной уязвимости десериализации.

Второй подлинно новый элемент — разворот через социальную инженерию. Большинство цепочек ViewState → веб-шелл останавливается на компрометации сервера. Здесь операторы пошли дальше и модифицировали JavaScript-файл приложения, чтобы отобразить фальшивое предупреждение безопасности с предложением установить поддельный плагин. Это переводит серверную компрометацию в первоначальный доступ на стороне клиента, расширяя радиус поражения с хоста LMS до каждого аутентифицированного обучающегося, который входит в систему. Для LMS, используемой в корпоративных средах, эта пользовательская база включает сотрудников с корпоративными устройствами и идентификаторами, связанными через SSO. Скомпрометировать LMS — значит получить точку водопоя для всей клиентской базы.

Третье — индивидуальный ключ Cobalt Strike для каждой жертвы. Шифрование пейлоада строкой, производной от названия организации-жертвы, — небольшая операционная деталь, говорящая о том, что операторы ведут целевую, а не оппортунистическую постэксплуатацию. Источник не раскрывает, один ли операторский кластер ответственен за все наблюдаемые вторжения, что важно, поскольку позволило бы отличить единую APT-кампанию от массового использования утёкшего ключа. Сопоставить наблюдаемые TTP с матрицей MITRE ATT&CK (T1190 — первоначальный доступ, T1505.003 — веб-шелл, T1059 — выполнение) несложно, но с атрибуцией всё иначе.

Что уже учтено командами безопасности

Ряд аспектов этого инцидента не должен удивить никого, кто управлял уязвимостями более года. Атаки через ASP.NET ViewState известны как минимум с 2014 года. Hardcoded секреты в вендорских конфигурациях задокументированы в OWASP Top Ten в разделах о криптографических сбоях и неправильной настройке безопасности. Godzilla и Cobalt Strike — это стандартные инструменты постэксплуатации, которые любой зрелый SOC уже должен обнаруживать с помощью сканирования памяти и анализа трафика маяков. Ни один из технических примитивов здесь не является новым.

Что не учтено: готовность региональных вендоров корпоративного программного обеспечения поставлять продукты с общим криптографическим материалом для всех клиентов в 2026 году. Десятилетие рекомендательных документов, руководств NIST и предупреждений OWASP должны были покончить с этой практикой. Этого не произошло. Я бы сказал, что это повторяющаяся слепая зона для команд безопасности, которые по умолчанию моделируют угрозы для приложения, но не для артефакта развёртывания, поставляемого вендором. Файл web.config — это не код приложения, это конфигурация, а аудиты конфигурации редко сверяют криптографический материал с базами известных дефолтных значений.

Также недооценено: LMS как высокоценная цель. Команды безопасности склонны моделировать LMS-платформы как системы низкой критичности, хранящие учебный контент. Это не так. Они обрабатывают SSO-утверждения, персональные данные пользователей, иногда платёжные данные для платного обучения, и в данном случае предоставляют контекст выполнения JavaScript для каждого аутентифицированного сотрудника каждого клиента. Компрометация LMS — это вектор компрометации учётных данных и конечных точек для всего корпоративного клиента. Ожидайте, что эта категория будет привлекать всё больше целевого внимания в 2026 году, и если так, к концу года следует ожидать как минимум ещё двух рекомендаций от LMS-вендоров с CVSS выше 7.0.

Контрарная точка зрения

Консенсусная трактовка будет такой: «исправьте, смените ключи, ограничьте доступ, двигайтесь дальше». Собственные рекомендации Mandiant именно таковы: отслеживайте вторжения, ротируйте machine keys, ограничьте доступ к LMS. Разумный совет. Вероятно, недостаточный.

Контрарная позиция: ротация machineKey на развёртывании, которое было скомпрометировано в течение неизвестного периода, не отменяет того, что уже могло произойти. Если Godzilla работал в памяти, если ACL каталогов были изменены, если JavaScript-файл был подменён для отправки поддельных плагинов аутентифицированным пользователям, то компрометация уже привела к утечке учётных данных и, возможно, закреплению на пользовательских устройствах. Ротация ключей закрывает парадную дверь после того, как грабители ушли через чёрный ход.

Более сложная и менее популярная рекомендация — полная позиция реагирования на инциденты для каждого экземпляра KnowledgeDeliver, работавшего до 24 февраля 2026 года: исходите из факта компрометации, пересоберите из чистых носителей, принудительно смените учётные данные для каждого пользователя, прошедшего аутентификацию через LMS в период уязвимости, и проверьте устройства этих пользователей на наличие пейлоада поддельного плагина. Это дорого. Большинство организаций этого не сделают. Они сменят ключи, запустят сканирование, ничего не обнаружат и объявят победу. Через шесть-двенадцать месяцев, если внутри японских корпоративных сетей появятся маяки Cobalt Strike, след приведёт именно сюда.

Ключевые выводы

• CVE-2026-5426 имеет оценку CVSS 7.5, но фактически уязвимы все установки KnowledgeDeliver до 24 февраля 2026 года, поскольку предварительное условие с machineKey было выполнено вендорским дефолтом.
• Цепочка атаки завершается бэкдором Cobalt Strike, зашифрованным индивидуально для каждой жертвы, что сигнализирует о целевых операциях, а не об оппортунистической массовой эксплуатации. Число жертв не раскрывается.
• Этап подмены JavaScript превращает компрометацию сервера LMS в точку водопоя для каждого аутентифицированного пользователя, расширяя радиус поражения за пределы самого хоста LMS.
• Рекомендованные Mandiant меры по устранению (смена ключей, ограничение доступа, мониторинг) — это минимум, а не максимум. Экземпляры, работавшие до 24 февраля, следует считать заведомо скомпрометированными до тех пор, пока доказательства с конечных точек не говорят об обратном.
• Проверяемый прогноз: если кампания ограничена одним оператором, телеметрия эксплуатации останется стабильной до третьего квартала 2026 года. Если ключ утёк широко, в течение 90 дней ожидайте, что стандартные сканеры начнут зондировать установки KnowledgeDeliver, а за этим последует эскалация рекомендаций от CISA или JPCERT.