3CX supply chain: когда легитимный инсталлятор приносит троян

Атака на 3CX Desktop App оказалась неприятной сразу по нескольким причинам. Не потому что сложная - механика там достаточно понятная. А потому что ломает базовую эвристику: «скачал с официального сайта вендора, подпись валидная - значит, безопасно». В случае с 3CX эта логика не сработала.

Что произошло

3CX - популярный VoIP-комплекс, которым пользуются сотни тысяч организаций по всему миру: колл-центры, офисные АТС, CRM-интеграции. В конце марта 2023 года несколько вендоров в области ИБ почти одновременно зафиксировали подозрительное поведение у официального 3CX Desktop App для Windows и macOS. Оказалось, что в официальный инсталлятор была встроена вредоносная нагрузка - причём подписанная валидным сертификатом 3CX.

Схема атаки:

• Инфицированный инсталлятор распространялся с официального сайта 3CX и через механизм автообновления. Пользователи скачивали его штатным способом.
• Вредоносные DLL - ffmpeg.dll и d3dcompiler_47.dll - подгружались легитимным процессом 3CXDesktopApp.exe. Это техника DLL sideloading: основной бинарник чистый, нагрузка в библиотеке.
• Зашифрованный пейлоад читался из .ico-файлов, которые подтягивались из публичного GitHub-репозитория. Стеганография уровня «спрятано на виду».
• Итог - на машинах с заражённым клиентом устанавливался бэкдор, который выходил на C2-серверы атакующих.

Атаку связали с Lazarus Group (Северная Корея). Примечательно другое: первоначальным вектором заражения самой 3CX предположительно стала другая supply chain атака - через Trading Technologies X_Trader, то есть цепочка supply chain внутри supply chain.

Что это меняет в практике

До 3CX supply chain атаки в публичном пространстве ассоциировались прежде всего с SolarWinds (2020) - и там вектор тоже был через обновление ПО, но масштаб и специфика другие. 3CX отличается тем, что это массовый коммерческий продукт, стоящий в тысячах организаций, с автообновлением, которое пользователи включают не задумываясь.

Фактически атакующие использовали доверие к вендору как оружие. И вот здесь начинается неудобный вопрос: сколько у вас установлено сторонних приложений, которые имеют механизм автообновления и которые вы не проверяете после каждого обновления?

Что мы проверяли у клиентов

Когда история с 3CX стала публичной в апреле, мы прошлись по клиентам, у кого в стеке была IP-телефония или UC-решения. 3CX Desktop App оказался у трёх организаций - в разных версиях, с разным статусом обновлений.

Версии. Уязвимыми считались сборки 18.12.407 и 18.12.416 для Windows, 18.11.1213 для macOS. У одного из клиентов стояла именно уязвимая версия - автообновление было включено, и оно успело прокатить заражённый билд.

Признаки компрометации. Проверяли по IoC-листам от CrowdStrike и Mandiant: хэши файлов, имена процессов, C2-адреса в сетевых логах. Признаков активности бэкдора не нашли - либо повезло, либо C2 к тому моменту уже был заблокирован на уровне периметра (у этого клиента был UTM с обновляемыми сигнатурами, и блокировки по репутации IP сработали раньше, чем мы пришли смотреть).

Что сделали. Удалили все установленные версии 3CX Desktop App, установили актуальную чистую сборку 18.12.422 (вышла в начале апреля уже без нагрузки), заблокировали автообновление до ручного контроля, добавили хэши уязвимых дистрибутивов в мониторинг.

Про sideloading и DLL - почему это работает

Техника DLL sideloading известна давно, и тем не менее она регулярно всплывает в громких инцидентах. Механика простая: приложение при запуске ищет DLL по определённым путям, и если в рабочей директории лежит файл с нужным именем - он и подгружается, независимо от того, чей это файл. Никакой проверки подписи загружаемой библиотеки 3CXDesktopApp.exe не делал.

В результате весь trust chain рушится: бинарник подписан валидно, но что он загрузит в рантайме - вопрос отдельный. AV-решения исторически доверяли подписанным бинарникам и не углублялись в то, что те подтягивают. Несколько лет назад это было оправдано по соображениям производительности. Сейчас это дыра.

Что стоит проверить в своей инфраструктуре

По итогам работы с клиентами мы выработали короткий список вопросов, который стал частью нашего аудита сторонних приложений:

• Реестр приложений с автообновлением. Есть ли вообще список всего ПО, которое обновляется само, без участия администратора? Обычно ответ «нет» - и это уже проблема.
• Версионный контроль. Кто фиксирует, какая версия какого приложения стоит на каждой рабочей станции? EDR решает это частично, но не везде есть EDR.
• Изоляция бизнес-критичного ПО. Если клиентское приложение работает с финансовыми данными или имеет доступ к корпоративной телефонии - стоит ли оно на тех же машинах, где открывают почту и браузер? Часто да.
• Что происходит после обновления. Есть ли хотя бы хэш-верификация дистрибутива перед установкой? Или «скачалось - запустилось»?
• Сетевая активность приложения. Куда ходит конкретный клиент после запуска? Если никто не знает - узнать несложно через EDR или network monitoring, зато неожиданно информативно.

Про DLL sideloading отдельно: стоит посмотреть, какие приложения при запуске загружают DLL из своей рабочей директории, а не из System32. Это делается статически (Process Monitor или аналоги в режиме аудита) и даёт список кандидатов на такой же вектор.

Коллатеральный ущерб от доверия к вендору

История с 3CX хорошо иллюстрирует то, что мы называем «коллатеральными модулями» - всё, что приехало вместе с легитимным инсталлятором. Патч-менеджмент традиционно смотрит на версии ОС, браузера, офисного ПО. Сторонние коммуникационные клиенты, корпоративные телефонные приложения, утилиты от вендоров железа - они в этот реестр попадают редко, а автообновление у них включено по умолчанию.

Ирония в том, что именно автообновление продаётся вендорами как фича безопасности: «у вас всегда будут свежие патчи». Это правда. И это же стало вектором доставки трояна в случае с 3CX. Доверие к каналу обновления оказалось оружием.

Мы не говорим «отключайте автообновления везде» - это другая крайность, которая ведёт к незакрытым CVE. Но между «обновляется само» и «кто-то смотрит что приехало» должна быть хотя бы минимальная точка контроля. В большинстве инфраструктур, которые мы видим, её нет.