Хакеры использовали критическую уязвимость в сервере на базе KnowledgeDeliver — системы для дистанционного обучения. Ошибка получила индекс CVE-2026-5426 и позволяла атаковать сервер без авторизации: злоумышленники ставили web shell Godzilla и запускали код на уровне операционной системы.

По данным Mandiant, атака шла через ViewState deserialization, а её корнем стал общий заранее прописанный machine key в конфигурации веб-портала. Это типичная история, когда одна и та же слабость повторяется у множества клиентов сразу. Именно поэтому инцидент с LMS вышел за рамки одного сервера и стал показателем более широкой проблемы в настройках ASP.NET.

Что произошло и почему это важно

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

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

Три подхода к защите: от быстрых мер до системной проверки

1. Срочно обновить и пересмотреть конфигурацию

Самый прямой шаг — убрать старые стандартные настройки и перейти на уникальные ключи для каждого развёртывания. В статье источник прямо указывает, что установки до 24 февраля 2026 года опирались на шаблонный web.config с hardcoded machineKey.

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

2. Проверить сервер на признаки закрепления

Если сервер уже был под ударом, важно не только обновить систему, но и искать следы проникновения: изменённые JavaScript-файлы, новые скрипты, подозрительные учётные записи, посторонние процессы. Источник описывает модификацию приложения через JavaScript, который подсовывал пользователям установку „security authentication plugin“.

Здесь поможет нормальная проверка журналов, целостности файлов и сетевой активности. В похожих историях мы уже разбирали, как атакующие заходят через уязвимые платформы и закрепляются в них — см. разбор атаки на Ghost CMS.

3. Усилить цифровую гигиену у сотрудников

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

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

Кому какой вариант подходит

Для администраторов KnowledgeDeliver и похожих LMS первый приоритет очевиден: обновление, смена ключей, аудит конфигурации и поиск следов компрометации. Для команд безопасности важнее второй слой — мониторинг, проверка целостности и реакция на подозрительные изменения файлов.

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

На что обратить внимание сейчас

История с KnowledgeDeliver показывает, что опасны не только свежие уязвимости, но и скучные старые ошибки в конфигурации. Один общий ключ на десятки или сотни внедрений превращает локальный баг в массовую угрозу.

Похожим образом злоумышленники били и по другим платформам — от корпоративных хранилищ до сервисов для командной работы. Логика у них одна: найти стандартную слабость, добраться до десериализации, а затем закрепиться через web shell или подмену файлов. В отдельных случаях цепочка атаки была такой же жёсткой, как в случае с инцидентом вокруг KnowledgeDeliver и Godzilla.

Практический чек-лист

  • Проверьте, использует ли сервер стандартный или общий machine key.
  • Обновите KnowledgeDeliver и все зависимые компоненты до актуальных версий.
  • Осмотрите изменённые веб-файлы, особенно JavaScript и конфиги.
  • Проверьте журналы на подозрительные запросы ViewState и признаки выполнения кода.
  • Ищите следы web shell, новых учётных записей и посторонних процессов.
  • Обучите сотрудников не ставить неизвестные „плагины безопасности“ и не запускать поддельные установщики.
  • Включите регулярную проверку целостности файлов и уведомления о смене ключевых настроек.
  • Если сервер работал в уязвимой конфигурации, проведите полноценный аудит инцидента, а не только обновление.
Поделиться: