В конце мая 2025 года система мониторинга угроз Xlab зафиксировала распространение ELF-файла под названием «w» с IP-адреса 111.119.223[.]196. Искусственный интеллект идентифицировал его как связанный с угрозой PolarEdge, при этом файл остался незамеченным антивирусными сканерами VirusTotal. Это событие породило предположения о возобновлении активности группировки. В ходе последующего расследования был выявлен ранее неизвестный компонент RPX_Client, чьей основной функцией является интеграция скомпрометированных устройств в пул прокси-серверов управляющих серверов (C2) с поддержкой выполнения удаленных команд.
Описание
PolarEdge впервые была документирована компанией Sekoia 25 февраля 2025 года. Данная угроза использует уязвимые IoT-устройства и периферийное сетевое оборудование в сочетании с арендованными VPS для создания сети операционных релейных боксов (ORB). Подобно резидентным прокси, ORB-сети нацелены не на прямые атаки, а на долгосрочное скрытное присутствие и маскировку трафика, представляя собой инфраструктурную сервисную платформу для киберпреступности.
Эффективность ORB-сетей в обходе систем обнаружения, сокрытии источников атак и усложнении атрибуции привлекла внимание продвинутых persistent threats (APT). Компания Mandiant даже предположила, что рост популярности ORB может привести к снижению значимости традиционных индикаторов компрометации (IOC) в обнаружении и анализе атак. В августе-сентябре 2025 года компания Censys опубликовала два отчета о PolarEdge, выделив серверный компонент RPX_SERVER, функционирующий как шлюз обратного прокси-подключения. Однако из-за использования сертификатов PolarSSL, не являющихся уникальными для злоумышленников, уверенность в прямой связи RPX_SERVER с PolarEdge была поставлена под сомнение.
Несмотря на это, Xlab с высокой долей уверенности атрибутирует часть инфраструктуры и компонент RPX_Server группировке PolarEdge. Ключевыми основаниями стали: стилистическое сходство скриптов распространения, функциональная совместимость RPX_Client и RPX_Server, а также обнаружение в базах данных RPX_Server записей о распространении RPX_Client с адреса 111.119.223[.]196.
Обнаружение обоих компонентов позволило исследовать архитектуру PolarEdge. Установлено, что для управления узлами и распределения задач используются RPX_Server, Go-Admin и Nginx. На текущий момент идентифицировано 140 C2-серверов и свыше 25000 IP-адресов зараженных устройств.
Инфраструктура и масштабы
Благодаря анализу скриптов и использованию сертификатов PolarSSL на порту 55555 через платформу QiAnXin было обнаружено 161 подозрительных IP-адреса. После проверки по протоколу взаимодействия подтверждена активность 140 RPX-серверов. Все они размещены на VPS в сетях ASN45102, ASN37963 и ASN132203, принадлежащих Alibaba Cloud и Tencent Cloud.
Клиентская база RPX, полученная из частично доступных данных, включает более 25000 IP-адресов, в основном IoT-устройств и маршрутизаторов. Инфекции зафиксированы в 40 странах, с концентрацией в Юго-Восточной Азии и Северной Америке. На первом месте по количеству заражений находится Южная Корея (41.97%), за ней следуют Китай (20.35%), Таиланд (8.37%) и Малайзия (5.98%). Устройства идентифицируются по полю «brand»: доминируют ktcctv (KT CCTV) и tvt (Shenzhen TVT DVR), составляя свыше 90% от всех случаев.
Хронология и атрибуция
Первые следы активности, связанные с распространением RPX_Client, прослеживаются с апреля 2025 года, когда злоумышленники использовали уязвимость CVE-2023-20118. Файл «w», выступавший в роли загрузчика, был впервые замечен в декабре 2023 года с IP-адреса 82.118.22.155. Анализ связанных доменных имен (beastdositadvtofm[.]site) и их пересечений с известной инфраструктурой PolarEdge (icecreand[.]cc, centrequ[.]cc) подтвердил принадлежность этого адреса к группировке.
Сходство ELF-файла «w» с известными образцами PolarEdge, включая схожие строковые константы и модификации секций, а также идентичная стилистика скриптов распространения с адреса 111.119.223.196, позволили окончательно атрибутировать RPX_Client как компонент PolarEdge.
Технический анализ
Скрипт «q», используемый для развертывания, загружает архив «wget.tar», содержащий исполняемый файл rpx_client и скрипт rpx.sh для обеспечения персистентности. RPX_Client маскирует свой процесс под «connect_server», использует PID-файл /tmp/.msc и конфигурационный файл .fccq с параметрами, зашифрованными XOR 0x25.
Клиент устанавливает два соединения с C2-сервером: на порт 55555 (взаимодействие с RPX_Server для регистрации и прокси-трафика) и на порт 55560 (управление через Go-Admin для выполнения команд). Регистрация узла включает обмен UUID и данными о версии и типе устройства.
RPX_Server функционирует как шлюз обратного прокси: он не подключается к целям напрямую, а назначает зарегистрированным клиентам (RPX_Client) установить соединение с целью и ретранслировать трафик через выделенный порт. Это создает многоуровневую цепочку, эффективно скрывающую источник атаки. Сервер поддерживает протоколы SOCKS5, SOCKS5 over TLS и Trojan.
Управляющий компонент Go-Admin предоставляет веб-интерфейс через Nginx на порту 19999, позволяя операторам управлять узлами, проверять сессии и экспортировать конфигурации для инструментов вроде Clash.
Через порт 55560 клиенты получают команды, включая выполнение произвольных системных инструкций, смену C2-сервера (change_pub_ip) и самообновление (update_vps). Наличие в логах RPX-серверов записей о командах, отправленных на адрес 111.119.223.196, дополнительно подтверждает его роль в инфраструктуре PolarEdge.
Заключение
Обнаружение RPX_Client и RPX_Server раскрыло механизмы работы одной из ключевых подсистем PolarEdge. Архитектура, сочетающая тысячи скомпрометированных IoT-устройств и десятки серверов-ретрансляторов, создает мощный барьер, серьезно затрудняющий расследование инцидентов. Взаимосвязь между бэкдор-выборками PolarEdge и RPX-системой требует дальнейшего изучения. Xlab призывает профессиональное сообщество к обмену информацией для противодействия подобным сложным угрозам.
Индикаторы компрометации
