Атака на AOMEI превратила штатный механизм обновлений и уведомлений AOMEI Backupper в канал доставки вредоносного ПО: злоумышленники трижды подменяли конфигурацию всего на 5–10 минут, а затем возвращали её к исходному виду. Для российских компаний это ещё одно напоминание: резервное копирование не только спасает после инцидента, но и само может стать точкой входа в инфраструктуру.
Кампания шла с апреля по июль 2026 года и затронула Windows-приложение AOMEI Backupper для бэкапа, клонирования дисков и восстановления систем, сообщает BleepingComputer. Исследователи лаборатории ManageEngine Threat Analysis Lab работали вместе с Google Threat Intelligence Group и Mandiant; активность они связали с группой, отслеживаемой под именем UNC7017. Среди известных пострадавших — организации из США, Австралии, Индии, Сингапура, Испании и Швейцарии, включая IT-сервисные компании, телеком и вузы. Но список вряд ли исчерпывающий: жертвой мог стать любой клиент, проверивший обновления в нужные несколько минут.
Первый сигнал появился 28 мая. Защитное решение ManageEngine заметило, что AOMEI Backupper на компьютерах двух несвязанных компаний в разных странах устанавливает Radmin — легитимный инструмент удалённого администрирования. Сам по себе Radmin не является вредоносной программой, но контекст выглядел красноречиво: загрузку запускал встроенный в Backupper рекламный механизм, который обычно показывает промоматериалы и уведомления. Воспроизвести инцидент сразу не удалось — тестовые машины получали уже нормальные файлы с серверов поставщика. Именно эта краткость и была частью замысла.
Пять минут, чтобы обойти проверку
Злоумышленники не заменяли обновления навсегда. Они временно меняли два файла конфигурации на инфраструктуре AOMEI: down_html.ini, где задаётся адрес пакета обновления, и Notifycfg.ini, управляющий уведомлениями. Первый перенаправлял Backupper на вредоносный ZIP-архив, второй позволял запустить полученное содержимое без действий пользователя. Google позже подтвердил эту цепочку в собственных тестах.
Ключевая деталь: атакующие изменили и контрольную сумму, ожидаемую клиентом. Поэтому архив проходил встроенную проверку целостности, хотя был подменён. Наблюдение за серверами позволило зафиксировать три периода раздачи вредоносной конфигурации: 28 мая с 05:40 до 05:50 UTC, 16 июля с 08:33 до 08:39 UTC и 20 июля с 10:35 до 10:40 UTC. После каждого окна файлы возвращались к легитимному состоянию. Обычная проверка «сейчас всё чисто» в такой схеме почти бесполезна: компрометация проявляется не постоянным индикатором, а короткими вспышками в телеметрии.
Через подменённые настройки доставлялись ранее не описанные компоненты CROSSROAD и SHINYROAD. CROSSROAD выступал загрузчиком: собирал сведения о машине, подтягивал дополнительные модули и закреплялся через запланированную задачу Windows. SHINYROAD работал как бэкдор и использовал легитимные компоненты Radmin для загрузки вредоносного кода и исходящего соединения с управляющим сервером. После этого оператор мог загружать новые полезные нагрузки или выполнять команды на скомпрометированном узле. Во время эпизода 20 июля исследователи также увидели попытку получить NTLM-хеши: невидимое уведомление заставляло систему обратиться к контролируемому атакующими WebDAV-ресурсу.
Поставщик исправляет серверы, но не уже заражённые ПК
ManageEngine сообщила, что впервые уведомила AOMEI о подозрительной активности 7 июня. Первоначально компания допускала, что контент мог быть перехвачен и изменён по пути к клиентам. Исследователи с этим не согласились: оба пострадавших устройства получали данные по HTTPS с доменов AOMEI, находились в разных странах и сетях, а исполняемый файл появлялся через штатную последовательность распаковки приложения. После фиксации новой подмены 16 июля специалисты передали поставщику хеши, различия файлов и сами изменённые конфигурации.
По данным исследователей, AOMEI планировала перенести затронутые файлы на новую инфраструктуру с более подробным журналированием; ей также рекомендовали сохранить доказательства до изменений и подключить специалистов по реагированию. Mandiant уведомила компанию о подмене 17 июля, а 29 июля AOMEI сообщила о корректирующих действиях. Производитель заявил, что вопрос имеет высокий приоритет и внутреннее расследование возглавляет технический директор. Компания также сообщила об обновлении серверов, устранении потенциальных уязвимостей и проверке размещённых файлов, но не раскрыла, каким именно способом злоумышленники получили доступ к инфраструктуре обновлений и подтверждённо ли закрыт исходный вектор.
Для команд ИБ атака на AOMEI — повод не ограничиваться установкой свежей версии программы. Нужно проверить конечные точки на незапланированную установку Radmin, задания планировщика, сетевые соединения и следы CROSSROAD или SHINYROAD, особенно если AOMEI Backupper использовался в мае—июле. Важен и процессный вывод для разработчиков: конфигурационные файлы, которые могут менять адрес загрузки, хеш пакета или запускать контент, обладают теми же рисками, что и сам сервер обновлений. Их стоит защищать строгой аутентификацией, неизменяемым аудитом, отдельными ключами подписи и мониторингом изменений.
Серверная очистка останавливает новые заражения, но не удаляет уже установленный бэкдор — в этом и состоит неприятная экономика атак на цепочку поставок. Чем больше полномочий у «вспомогательного» канала уведомлений или промо-контента, тем привлекательнее он для атакующего: защита обновлений должна охватывать не только исполняемые файлы, но и каждую настройку, которая говорит клиенту, что скачать и что запустить.