Хакеры подменяли сервер обновлений AOMEI Backupper и раздавали бэкдор мимо антивирусов

16 июля 2026 года, с 08:33 по 08:39 UTC – шесть минут. Ровно столько сервер обновлений AOMEI Technology раздавал своим пользователям бэкдор, а потом вернул на место чистые, подписанные вендором файлы и продолжил работать как ни в чём не бывало. Кто опросил апдейт в эти шесть минут – получил загрузчик и скрытый удалённый доступ в придачу. Кто опросил минутой раньше или минутой позже – получил легитимное обновление и ничего не заподозрил.

Это supply-chain атака, после которой почти не остаётся улик. Ни бэкдора, вшитого в официальный релиз, ни испорченного конвейера сборки, ни даже внятного следа на сервере вендора: через 5–10 минут всё откатывается к норме. Стандартный рефлекс триажа – когда EDR поднял алерт на процесс, порождённый апдейтером, аналитик идёт проверять, что отдаёт сервер вендора, – здесь работает против него: сервер к моменту проверки снова чист, и алерт списывают в ложное срабатывание. Ни одного эксплойта, ни одной CVE в этой истории нет. Есть только доверие к автообновлению – тому самому механизму, который любой безопасник велит держать включённым, – и отсутствие криптопроверки там, где она обязана быть. Атаку, которой на сервере уже нет, всё-таки поймали, и то, как именно, не менее поучительно, чем сам имплант.

Отравление, которое живёт пять минут и откатывается само

AOMEI Backupper – массовый бэкап-клиент под Windows, и, как почти всякий такой клиент, он фоном опрашивает инфраструктуру вендора на предмет обновлений и промо-материала. Для атаки значимы ровно два файла. Первый – down_html.ini, который клиент тянет с https://www2.aomeisoftware.com/download/abpopup/: в нём номер версии, MD5 ожидаемого апдейт-пакета и URL, откуда скачать upgrade-now.zip. Второй – Notifycfg.ini с отдельного хоста account.aomeitech.com: он говорит локальному процессу уведомлений ABNotify.exe, что показать и какие программы из локального каталога запустить.

UNC7017 – так GTIG трекает кластер – не стала оставлять на этих файлах статичную закладку. Вместо этого контент подменялся вспышками по 5–10 минут, после чего down_html.ini и Notifycfg.ini возвращались к легитимному виду. GTIG называет это первым в их практике supply-chain, реализованным такими сверхкороткими окнами, и у решения есть точная инженерная цена. Персистентная модификация на сервере (путь SolarWinds и 3CX) бьёт по всем, кто скачает релиз, но оставляет в официальных файлах бинарную подпись, которую рано или поздно найдут при анализе уже выпущенных файлов. Эфемерное окно отдаёт нагрузку только тем клиентам, кто опросил апдейт в эти минуты, – улов меньше на порядки, – зато краулеры репозиториев и автоматические сканеры почти всегда видят аутентичные, подписанные файлы, а у защитников не остаётся живого вредоносного ответа сервера, чтобы его захватить. Это размен наблюдаемости на охват, и оператор работает на острие: он сознательно отдал масштаб ради того, чтобы его инфраструктурной активности как бы не существовало.

И это ровно та ситуация, которую мы уже разбирали в истории с отозванным Rust-крейтом, где бэкдор раздавал сам Cargo: канал, которому доверяют по определению, превращается в канал доставки, и жертва делает всё правильно – просто обновляется.

Как промо-попап AOMEI сам кликает по трояну

Самое изящное здесь в том, что эксплойта не понадобилось. UNC7017 использовала штатный механизм обновления и показа попапов ровно так, как он спроектирован. По умолчанию клиент скачивает апдейт-архив в каталог Tmphtml, распаковывает его в локальный html/ и исполняет инструкции из двух удалённых конфигов.

В окно подмены сервер отдавал клиенту upgrade-now.zip – бандл из 232 файлов легитимного промо-контента AOMEI, в котором притаились два чужих. Первый – upgrade-now.exe, неподписанный исполняемый файл. Второй – upgrade-now.html, в котором скрипт программно создаёт ссылку на этот соседний upgrade-now.exe и кликает её сам. Бандл рендерится во встроенном WebView апдейт-попапа; WebView трактует синтетический клик как навигацию по URL и отдаёт исполняемый файл системному шеллу. Эксплуатировать сам WebView не нужно – нужно лишь, чтобы HTML грузился локально.

А он грузится локально, потому что Notifycfg.ini указывает попапу на upgrade-now.html через file:///-путь внутри каталога установки AOMEI. Для WebView это локальный контент, и политика его исполнения совсем не та, что для страницы из сети. METAL, воспроизводя тот же путь в контролируемой среде, получала при этом чистую картинку: механизм отрабатывал штатно, тот же HTML, тот же попап, но указывал он на легитимный URL AOMEI, и никакого exe не прилетало. Разница между боевым и чистым прогоном была не в механизме, а во времени – в том, что именно сервер положил в эти файлы в конкретную минуту.

35 000 пустых секций, чтобы клиент проглотил чужой апдейт

Чтобы клиент принял и распаковал подменённый upgrade-now.zip, в down_html.ini в каждое окно инкрементировался минорный номер сборки – поле thrid – и синхронно переписывался ожидаемый MD5 под новый архив.

; down_html.ini, каким сервер отдавал его в окно 16 июля 08:33–08:39 UTC
thrid=6
; следом – MD5, пересчитанный под подменённый upgrade-now.zip,
; и URL загрузки, уводящий на promotion.storage-data.com

Вот первый структурный провал вендора, и он корневой: MD5 ожидаемого пакета лежит в том же самом неподписанном файле, что и сам редирект. Контрольная сумма заверяет не вендор – её заверяет тот, кто правит файл. Клиент проверяет лишь, что скачанный архив совпадает с хешем, который ему только что продиктовал злоумышленник. Криптографической проверки подписи – ни на архиве, ни на конфиге – нет вовсе. По меркам переднего края это решение вендора отстало от общедоступного: Authenticode на исполняемых файлах и асимметрично подписанный конфиг существуют десятилетиями, и любой из них обнулил бы всю кампанию – подменённый файл не прошёл бы проверку подписи. Цена отсутствия этой проверки – не частная дыра, а бесплатная компрометация любого клиента, опросившего сервер в нужную минуту.

Одновременно в то же окно 16 июля подменялся и Notifycfg.ini: в него впрыскивалось больше 35 000 повторяющихся секций вида [dummy_XXXXXX]. Это раздувание конфига перебивало штатную проверку версии, заставляя клиент инициировать обновление независимо от уже установленной сборки и немедленно исполнить распакованный upgrade-now.exe из локального html/. Грубая, но работающая механика: завалить парсер мусором так, чтобы сработала нужная ветка.

Невидимый пиксель, уводящий пароль по WebDAV

20 июля UNC7017 добавила в Notifycfg.ini второй вектор, и он показателен как отдельное инженерное решение. До подмены этот конфиг рисовал легитимный промо-баннер 400×380 про «World Cup Deals». Оператор заменил его невидимым окном 1×1 пикселя с максимальным приоритетом исполнения.

Width=1
Height=1
Priority=9999
; окно рендерит удалённый HTML по UNC-пути WebDAV (DavWWWRoot) → 8.210.84.56

Заставив клиент запросить удалённый ресурс file:// через WebDAV, оператор получил тихий механизм кражи учёток: эндпоинт принудительно отдаёт NetNTLMv2-хеши на подконтрольный IP 8.210.84.56 без какой-либо видимости для пользователя. Даже если бинарную нагрузку заблокировали, пароль всё равно уходит. Угол задуман грамотно – тот же попап-канал переиспользован под вторую, независимую цель, – но платит он наблюдаемостью: принудительная NTLM-аутентификация через внешний WebDAV тянет исходящий SMB и WebDAV-трафик на чужой IP, и для любой сети, где исходящий трафик на 445-й порт наружу закрыт или хотя бы мониторится (а это гигиенический минимум), луч виден сразу. Дешёвый довесок с высоким риском засветки – в отличие от основного канала, который как раз на незаметность и считан.

CROSSROAD: загрузчик, который прибирает за собой

Распакованный upgrade-now.exe – это CROSSROAD, 64-битный загрузчик на C, Stage-2 всей цепочки. Его задача – проверить окружение, прибраться на хосте, стащить основную нагрузку и прописать персистентность для Stage-3. И почти каждый его шаг подчинён анти-форензике.

Сначала ограничители. CROSSROAD проверяет, содержит ли его собственный путь подстроку AOMEI; если нет – запускает рутину самоудаления, но работу не прерывает. Перед вторичной загрузкой он уточняет геолокацию через DNS-сервисы myip.opendns.com, o-o.myaddr.l.google.com и HTTP-рефлекторы вроде checkip.amazonaws.com, api.ipify.org, ifconfig.me/ip, icanhazip.com – с характерными User-Agent'ами Anyviewer-loader/1.0 и Anyviewer-ipcheck/1.0 – кивок на второй продукт AOMEI, AnyViewer, который кампания задела наравне с Backupper (по разбору GTIG и Mandiant); в ряде веток, если код страны вернулся CN, основная ветка исполнения не запускается. Чтобы не плодить копии на хосте, берётся именованный мьютекс:

Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}

Дальше – самое интересное для нашей темы. Эфемерность жила не только на сервере: CROSSROAD повторяет её на эндпоинте. Он парсит локальный down_html.ini и возвращает thrid к дефолтному значению 5, а URL загрузки – на легитимный https://www2.aomeisoftware.com/download/abpopup/. То есть хост, с которого только что скачали троян, своими руками приводит конфиг обновления обратно к норме. Решение стоит оператору лишнего кода и лишнего наблюдаемого поведения – а значит, лишней поверхности для детекта, – но покупает за это главное: расследователь, пришедший на машину спустя часы, не увидит ни на сервере, ни в локальном конфиге указателя на нулевого пациента. Это осознанный размен в наблюдаемости: заплатить следом исполнения ради того, чтобы стереть след происхождения.

Анти-форензика продолжается и в метаданных. Ранний дроппер, попавший на VirusTotal 20 мая, нёс сфабрикованные даты сборки 2024 года – timestomping временных меток PE, чтобы сбить хронологию. После того как нагрузка извлечена из promotion.storage-data.com/config/component.zip, распакована встроенной miniz и прописана персистентность, CROSSROAD удаляет себя. Делает он это красиво: сбрасывает копию в %TEMP%, запускает её с флагом --nitrod, передавая PID родителя и путь оригинала, дочерний процесс дожидается смерти родителя, переименовывает основной поток данных :$DATA бинаря в альтернативный поток с характерным именем :wtfbbq через SetFileInformationByHandle и помечает файл на удаление по закрытию дескриптора. Персистентность при этом – внешняя: scheduled task RadminComponentRuntime, запускающий %LOCALAPPDATA%\Radmin\FamItrfc.exe --runtimechk каждые три часа.

Что характерно, повышать привилегии цепочке не пришлось. METAL разобрала 175 функций дроппера и не нашла ни манипуляций с токенами, ни обхода UAC – единственный API создания процессов в бинаре штатный CreateProcessW. Права цепочка наследует от процесса, который её запустил: ABNotify.exe работает под сервисом ABService.exe, а Radmin и его компоненты легли в C:\Program Files (x86)\, куда обычный пользователь не пишет. Значит, запускавший процесс AOMEI шёл с повышенными правами, возможно вплоть до SYSTEM, и этот уровень цепочка получила даром, не написав под него ни строки.

SHINYROAD едет внутри честного Radmin

Пакет, распакованный CROSSROAD в %LOCALAPPDATA%\Radmin\, – это административный бандл Famatech Radmin 3.x, и именно внутри него едет модульный бэкдор SHINYROAD. Собственной персистентности у него нет вовсе: он целиком полагается на тот самый scheduled task.

Запуск начинается, когда задача стартует легитимный подписанный бинарь Radmin – FamItrfc.exe --runtimechk. На старте он затягивает в себя неподписанную BlkScrDl.dll через search-order hijacking; имя выбрано так, чтобы маскироваться под штатную библиотеку «blank screen» самого Radmin. Это тот же приём, каким NeedyMantis подменял DLL в Poedit, curl и TightVNC: легитимная, подписанная программа сама грузит подсунутую рядом библиотеку, и на уровне цепочки процессов всё выглядит как работа доверенного админ-инструмента. Со-оптация коммерческого ПО тут сознательная – неизменный Radmin 3.x даёт укрытие бесплатно, – но у неё есть цена: неподписанная BlkScrDl.dll рядом с подписанным FamItrfc.exe и есть та аномалия, по которой всё и ловится. Своя закладка со своим подписанным сертификатом была бы незаметнее, но сжигаемый серт – дорогой и одноразовый актив; оператор выбрал чужую подпись и чистую DLL рядом.

Дальше BlkScrDl.dll находит config.zip, мапит его в секцию разделяемой памяти и динамически регистрирует csvc\RuntimeComponent.dll как in-process COM-сервер:

Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf   секция разделяемой памяти с config.zip
CLSID {21191641-0D7F-4CD9-9572-01AAE6E7851B}  RuntimeComponent.dll как in-process COM-сервер
AppID {9AD3E98A-4C7E-4F37-982D-D73D41E4F91B}

Когда Radmin инстанцирует этот CLSID, срабатывает AppID: он объявлен с суррогатом, поэтому COM-подсистема Windows поднимает имплант не в процессе Radmin, а внутри штатного dllhost.exe – подписанного Microsoft процесса-суррогата. Своего исполняемого файла у импланта нет вовсе, он работает под подписью Microsoft: сначала легитимный Radmin, теперь легитимный dllhost.exe – укрытие ступенчатое. DLL читает config.zip прямо из разделяемой памяти, извлекает зашифрованную нагрузку metadata.dat и расшифровывает её ChaCha20 с ключом и IV, выведенными через HMAC-SHA256. Расшифрованное – скомпилированный Python-байткод, который исполняется во встроенном интерпретаторе PocketPy, и уже он поднимает C2.

Архитектура SHINYROAD выдаёт зрелый замысел. Ранние варианты несли кастомные C-расширения (_pyio_compat, _pyio_struct, pkpy), чтобы не грузить с диска стандартные библиотеки Python, и общались по сырому TCP на 8.218.65.184:41397. Агент генерирует уникальный ID, снимая отпечаток с имени хоста и пользователя, аутентифицируется захардкоженным хендшейк-ключом и переводит весь дальнейший обмен на симметрику, выведенную из этого ID. В памяти движок умеет интерактивную удалённую оболочку через os.system, traffic chaffing – генерацию случайного мусорного трафика, чтобы сбить сетевые сигнатуры, – и динамическое расширение через пул потоков pkpy, не роняя модули на диск.

Adaptix под видом Nitro PDF – и вся скрытность насмарку

А вот финальная стадия ломает красоту разом. В середине июля, уже после разворачивания SHINYROAD, UNC7017 доставляла ADAPTAGENT – клиентскую часть готового фреймворка Adaptix C2. Маскировали её под промо- и сканер-тулзы Nitro PDF (NitroPromotion.exe), персистентность вешали на scheduled task \NitroRuntime:

powershell -Command "Start-Process 'C:\Users\<USER>\AppData\Local\Temp\NitroPromotion.exe' -WindowStyle Hidden"

Исполняемый файл сайдлоадил Eztwain4.dll (ADAPTAGENT) из %LOCALAPPDATA%\Nitro Pro\ и бил биконом на 8.210.84.56:6800 каждые две минуты.

Здесь видна классическая асимметрия ядра и обвязки. Ядро импланта – дорогое и тихое: встроенная Python-VM без следов на диске, своя криптосхема, свой бинарный протокол, chaffing против сигнатур. А поверх него навешена дешёвая шумная периферия: серийный C2 с предсказуемым двухминутным биконом на тот же IP, что светился на краже NTLM. Регулярный бикон с фиксированным интервалом – ровно тот паттерн, который ловит любой приличный сетевой анализ; и он сводит на нет усилия, вложенные в незаметность нижнего слоя. Стоило доводить нижний уровень до состояния «нас нет в сети», чтобы наверху поставить маячок, мигающий по таймеру, – дешевле было бы либо унести бикон в тот же скрытный транспорт, либо хотя бы развести его по джиттеру и инфраструктуре.

Три волны – от штатного Radmin до бесфайловой VM

Цепочка работала уже 28 мая, но финал у неё был другой. Родословная процессов, которую METAL восстановила из EDR, читается так: подписанный Backupper.exe распаковывает архив в ...\8.3.0\tmphtml\ и перекладывает в html\; подписанный ABNotify.exe запускает upgrade-now.exe из ...\8.3.0\html\upgrade-now\; неподписанный upgrade-now.exe сбрасывает компоненты Radmin и самоудаляется; подписанный rsetup64.exe ставит Radmin Server командой /intsetup. По разбору GTIG, майская волна ставила именно модифицированный Radmin Server – как самостоятельный канал удалённого доступа. Телеметрия METAL подтверждала только факт установки, но не то, что сервер слушал входящие: удалённый доступ в зрелой цепочке держался на отдельном компоненте.

Отсюда виден сдвиг почерка. Ранняя форма опиралась на готовый RAT – сам Radmin Server в роли бэкдора. Июльская оставила Radmin только носителем для сайдлоада SHINYROAD, а удалённый доступ увела в бесфайловую Python-VM. Оператор перешёл от «поставить RAT» к «одолжить подписанный бинарь, чтобы загрузить имплант, которого нет на диске», – и это тише на класс.

Инфраструктура менялась в такт. Майские payload'ы CROSSROAD жили на объектном хранилище Alibaba Cloud (serv.oss-cn-hongkong.aliyuncs.com); 16 июля редирект вёл на storage-data.com; 20 июля начальную загрузку увели в публичный бакет Google Cloud Storage (storage.googleapis.com/aomeiupdate/upgrade-now.zip), чтобы проскочить корпоративные прокси, режущие новорегистрированные домены, а вторичную нагрузку и C2 оставили на storage-data.com. Миграция с облачных провайдеров на выделенные домены и обратно сделана затем, чтобы защитнику было не на чем построить инфраструктурную блокировку. Селективность была зашита заранее: в whitelist.ini, замеченном 22 июня, стоял разрешённый IP 96.126.191.98, а геолокационные и EDR-проверки CROSSROAD означали, что загрузчик сам выбирает, где детонировать. И каждую волну инкрементировался thrid – 6 на 16 июля, 7 на 20 июля, – так что счётчик версий заодно работал журналом кампании.

Как METAL поймала атаку, которой не было на сервере

Поймала всё это первой METAL by ManageEngine – и история обнаружения стоит отдельного разбора, потому что эфемерность ломает не только триаж, но и само воспроизведение.

Сначала телеметрия EDR зафиксировала, как AOMEI Backupper ставит Radmin. 7 июня METAL уведомила AOMEI. Вендор ответил, что контент, мол, перехватили и подменили в транзите. METAL поставила клиент в контролируемой среде, опросила тот же промо-эндпоинт – и получила чистоту: тот же HTML, рендер попапа, легитимный URL AOMEI, никакого exe. Механизм доставки работал штатно от начала до конца. Образовались два свидетельства, указывающих в разные стороны: запись с эндпоинта показывала полную цепочку исполнения, а воспроизведение того же пути через ту же инфраструктуру не показывало ничего. Одно из двух было неверным.

METAL выбрала доверять телеметрии – и это методологически правильный выбор. EDR снимал родословную процессов в момент самого события, а не реконструировал постфактум; та же последовательность независимо всплыла на двух эндпоинтах в средах, не делящих ни инфраструктуры, ни администраторов, ни поставщиков. Одно неудавшееся воспроизведение – это точка данных, а не опровержение. Версия вендора про «перехват в транзите» фактуру не держала: оба эндпоинта тянули контент по HTTPS с хостов, принадлежащих AOMEI, из разных стран и по несвязанным сетевым путям, а исполняемый файл приезжал через собственную распаковочную последовательность приложения, а не писался на диск сторонним процессом. Контент был изменён до того, как достигал эндпоинта, – внутри вендорской раздачи.

Образец искали по отпечатку поведения. На диске ничего не выжило, поэтому из записанной родословной собрали поведенческий профиль – подписанный вендорский процесс распаковывает архив в свой промежуточный каталог, неподписанный потомок исполняется из каталога рендеринга, сохраняя вендорские метаданные, следом ставится инструмент удалённого администрирования – и по этому профилю пошли охотиться. Телеметрия сохранила и метаданные дроппера, включая имя продукта с опечаткой: «AOMEI Update Compent». Опечатка оказалась уникальным поисковым термином – по нему на VirusTotal нашёлся образец, который все движки сочли чистым. Чистым он выглядел не только из-за эфемерных окон: боевой C2-адрес в файле не лежит вовсе, он собирается только при расшифровке в памяти, и статическому анализу предъявлять нечего. В песочнице образец проверял геолокацию и искал конкретные EDR-агенты, завершаясь, если среда не подходила: он сам выбирал, где исполняться.

Оставался вопрос «когда» сервер отдавал не то. Точечная проверка на него не отвечала – подмена к моменту взгляда уже откатывалась. Тогда METAL перестала проверять и начала наблюдать: на конкретные URL раздачи повесили непрерывные автоматические мониторы, которые через фиксированные интервалы тянули и конфиг, и сам пакет, сверяя контент и хеш с предыдущей выборкой. 16 июля монитор поймал изменение в процессе – на краткое окно контент и его хеш сменились, пакет нёс нагрузку, и через минуты всё вернулось к базовой линии. Это и перевело дело из разряда «вывели из улик на эндпоинте» в «наблюдали напрямую». Приёмка, выраженная через наблюдаемый канал, здесь оказалась сильнее любой точечной: доказывали не метку, а сам факт подмены на вендорском пути, пойманный в момент. 17 июля полный профиль атаки ушёл в AOMEI, а индикаторы – в GTIG и Mandiant; 20 июля, пока мониторинг METAL был в простое, уже они зафиксировали повтор и захватили очередное короткое окно.

Сервер починили, эндпоинты остались заражёнными

Теперь про реакцию вендора, и тут слабое место видно по его же собственному журналу изменений. 17 июля Mandiant уведомила AOMEI и передала индикаторы; 29 июля AOMEI сообщила, что меры приняты. Меры были серверные. 9 октября вышла версия 8.5.0 с формулировкой «мигрировали сервер обновлений на новый, с дополнительными средствами контроля». И только 19 октября, уже после публичного раскрытия 15–16 октября, в версии 8.5.1 появилось то, что закрывает корень:

Добавлена проверка подписи конфигурационных файлов. Клиент откажется обрабатывать конфигурационные файлы, не прошедшие проверку подписи.

(в нашем переводе)

То есть проверка подписи конфигов – ровно то, отсутствие чего и сделало всю атаку возможной, – прилетела последней, спустя три месяца после уведомления и только под давлением публикации. Миграция сервера саму проблему не трогала: пока клиент готов принять неподписанный конфиг с самозаверенным MD5, не важно, с какого именно сервера его подсунут.

И есть второе следствие, которое важнее для всех, кто крутит AOMEI в парке. Серверная починка не лечит эндпоинты, скачавшие вредонос в ранние окна. Из-за того что подмена шла короткими вспышками, а загрузчик ещё и откатывал локальный конфиг, машины, получившие нагрузку, остаются скомпрометированными без ведома организации: прописанные через scheduled task резидентные payload'ы продолжают работать и после того, как вендор восстановил аутентичные .ini на раздаче. Факт того, что AOMEI «приняла меры», для заражённого хоста не значит ничего – там нужен ретроспективный хант по всему интервалу апрель–июль, а не вера в то, что серверный фикс закрыл вопрос.

Калибр операции и подпись, которую вендор добавил последней

Если свести решения в одну оценку, UNC7017 показала зрелую, но не ровную работу. На острие у неё две вещи. Первая – сама идея эфемерной подмены на вендорской раздаче: она перепридумывает supply-chain так, чтобы инфраструктурного следа почти не оставалось, и бьёт точно по рефлексу «проверь сервер вендора», превращая его в источник ложных отрицаний. Вторая – дисциплина анти-форензики, протянутая сквозь всю цепочку: откат конфига и на сервере, и на эндпоинте, timestomping, самоудаление через переименование потока в :wtfbbq, бесфайловая Python-VM вместо библиотек на диске. Это оператор, который думает не о том, как попасть, а о том, как не оставить, по чему реконструировать.

Слабее всего оператор сработал на верхнем слое. Дорогое тихое ядро накрыто серийным Adaptix с двухминутным биконом на засвеченный на краже NTLM IP: периферия дешевле и шумнее ядра, и именно она отдаёт всю операцию сетевому анализу. Второй NTLM-луч через внешний WebDAV – грамотный по замыслу, но громкий довесок, который в любой гигиеничной сети виден по исходящему трафику на 445.

Но главный урок, как часто бывает, не про оператора, а про вендора. Вся кампания держится не на эксплойте и не на нулевом дне, а на одном проектном решении: клиент обновления доверяет неподписанному конфигу, в котором контрольная сумма лежит рядом с редиректом и заверяется тем же, кто редирект и подменил. Доверенный канал без криптопроверки – это не частная ошибка, а структурный класс, превращающий любую подмену в раздаче в исполнение кода на клиенте бесплатно. AOMEI закрыла его подписью конфигов в 8.5.1 – правильным, но запоздалым и предсказуемым ходом; те же пять минут подмены против этой подписи не стоили бы ничего. Остальным, кто раздаёт десктопный софт через удалённые конфиги, стоит прочитать эту историю как чек-лист: подписывать не только бинарь, но и конфиг, пинить домены раздачи, не пускать file:// и WebDAV в обработчики попапов и развести апдейт от маркетинговых каналов – до того, как собственный апдейтер кликнет по чужому exe.

Кампанию разобрали Google Threat Intelligence Group и Mandiant (Tyler McLellan), атрибутировав активность кластеру UNC7017; первой же её зацепила и предъявила механику доставки команда METAL by ManageEngine.