KnowledgeDeliver Zero-Day: 100% інсталяцій зі спільним ключем під загрозою

Сто відсотків інсталяцій KnowledgeDeliver, випущених до 24 лютого 2026 року, піддаються одному й тому самому zero-day, оскільки кожна з них містила однаковий hardcoded ASP.NET machineKey у стандартизованому web.config. Це не вразливість у традиційному розумінні — це архітектура зі спільним секретом, що маскується під неї. CVE-2026-5426 має оцінку CVSS 7.5, яка занижує операційну серйозність, якщо врахувати, що передумова (знання ключа) була виконана для кожного клієнта з першого дня розгортання.

Цифри та масштаб

Визначимо масштаб проблеми. KnowledgeDeliver — це система управління навчанням від компанії Digital Knowledge, що використовується переважно у японських корпоративних та освітніх середовищах. Як повідомляє SecurityWeek, команда Mandiant (власність Google) пов'язує експлуатацію з зловмисниками, які використовували атаки десеріалізації 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 був підготовлений спеціально для цільової організації, що свідчить про розвідку та інструментарій, адаптований під кожну жертву, а не про масову атаку. Джерело не розкриває кількість уражених організацій, що важливо, оскільки це визначає, чи була це точкова кампанія проти кількох цінних японських цілей, чи початок більш широкого охоплення. Якщо ви використовуєте KnowledgeDeliver, вважайте межу як «щонайменше одна підтверджена жертва, верхня межа невідома» і дійте відповідно. Якщо експлуатація розшириться, слід очікувати, що Mandiant або JPCERT/CC опублікують телеметрію протягом 60 днів з переглядом кількості жертв у бік збільшення.

Що справді є новим

Десеріалізація 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 — виконання) є straightforward, але атрибуція — ні.

Що вже враховано командами безпеки

Кілька аспектів цього інциденту не повинні дивувати нікого, хто займається управлінням вразливостями більше року. Атаки 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 лютого слід вважати скомпрометованими до отримання доказів протилежного з кінцевих пристроїв.
• Перевірюване прогнозування: якщо кампанія була обмежена одним оператором, телеметрія експлуатації залишиться стабільною до Q3 2026. Якщо ключ витік широко — очікуйте, що комерційні сканери почнуть зондувати екземпляри KnowledgeDeliver протягом 90 днів з подальшою ескалацією з боку CISA або JPCERT.