В Notepad++ утверждают, что трафик обновлений перехватывался в течение нескольких месяцев в 2025 году, при этом злоумышленники перехватывали и выборочно перенаправляли некоторых пользователей на вредоносную инфраструктуру. BleepingComputer сообщает, что взлом начался в июне 2025 года и закончился 2 декабря, после того как хостинг-провайдер обнаружил нарушение и отключил доступ.
Этот инцидент служит полезным напоминанием о том, что «загрузка по HTTPS» — это не исчерпывающая информация о безопасности. Системы обновления нуждаются в надежной сквозной проверке, поскольку именно инфраструктура, которой вы доверяете, может быть скомпрометирована.
Что использовали нападавшие
BleepingComputer описывает уязвимость в механизмах проверки обновлений в старых версиях Notepad++, позволяющую злоумышленникам распространять поддельные манифесты обновлений и перенаправлять загрузки.
Сообщается, что кампания носила узконаправленный и избирательный характер, что соответствует стратегии того, кто больше заботится о доступе к конкретным целевым группам, чем о массовом распространении.
Сроки имеют значение:
- Первоначальный компромисс будет достигнут в июне 2025 года.
- Временные сбои в начале сентября после обновлений ядра/прошивки.
- Доступ через украденные внутренние учетные данные будет сохраняться до 2 декабря.
Этап "учетные данные сохранились после устранения проблемы" — классический пример ошибки при реагировании на инциденты: обновления сервера недостаточно, если у злоумышленника уже есть ключи.
Что изменила программа Notepad++ после инцидента?
Как сообщает BleepingComputer, Notepad++ перевел клиентов на нового хостинг-провайдера, обновил учетные данные и улучшил проверку подлинности.
Начиная с версии 8.8.9, WinGUP:
- Проверяет сертификаты и подписи установщиков.
- Использует XML-файл обновления с криптографической подписью.
В рамках проекта также планируется ввести обязательную проверку подписи сертификата в версии 8.9.2.
Такая последовательность — необязательные проверки → более строгие проверки → обязательные проверки — это именно то, как со временем должна совершенствоваться система распространения программного обеспечения.
Вредоносный аспект: Chrysalis и установление авторства
На сайте BleepingComputer приводится ссылка на исследование Rapid7, в котором указывается, что аналогичная кампания была организована китайской APT-группой, известной как Lotus Blossom (также упоминаемой под другими псевдонимами), и с помощью пользовательского бэкдора Rapid7 под названием «Chrysalis».
В целенаправленных инцидентах, связанных с цепочками поставок, полезная нагрузка часто бывает уникальной. Именно поэтому ключевая задача защиты заключается не в «обнаружении именно этого вредоносного ПО», а в «затруднении доставки любой несанкционированной полезной нагрузки через программу обновления».
Что организациям следует делать по-другому?
Если вы управляете программным обеспечением в корпоративной среде, этот инцидент указывает на несколько нарушений защитных механизмов по умолчанию:
- Избегайте автоматических обновлений для потребителей.по возможности, в критически важных системах.
- Используйте управляемое распространение программного обеспечения.(подписанные пакеты во внутренних репозиториях, Intune/SCCM и т. д.).
- Закрепить и проверить подписидля установщиков и обновлений.
- Отслеживайте «пути обновления».в качестве критически важной инфраструктуры: DNS, политики проверки TLS, поведение прокси-серверов и цепочки выполнения на конечных устройствах.
Если вы являетесь частным пользователем, практические шаги будут проще:
- Обновите Notepad++ до актуальной версии с официального сайта.
- С подозрением относитесь к запросам на обновление, которые не похожи на обычные уведомления установщика.
- Избегайте рекламных объявлений с призывами «скачать сейчас» в результатах поиска, которые имитируют официальные страницы.
Итог
Шестимесячная проблема с «захватом» Notepad++ при обновлении заключалась не в одной конкретной ошибке, а в нарушении границ доверия. Если злоумышленник может изменить манифест или проверки подписи слабые, «обновления» по своей сути превращаются в удалённое выполнение кода. Решение заключается в сквозной проверке, которую невозможно обойти, даже если хостинг-провайдер окажется под угрозой.