Исследователи из компании Sekoia изучили внутреннее устройство ботнета PolarEdge. Впервые описанный специалистами в феврале 2025 года вредонос связан с кампанией, нацеленной на устройства Cisco, ASUS, Qnap и Synology. Устройства объединяются в ботнет для пока неустановленных задач.
В августе 2025 года аналитики Censys более детально исследовали инфраструктуру ботнета. Тогда отмечалось, что PolarEdge демонстрирует характеристики, свойственные сетям Operational Relay Box (ORB), а активность малвари могла начаться еще в июне 2023 года.
В атаках, зафиксированных в феврале 2025 года, злоумышленники эксплуатировали известную проблему в роутерах Cisco (CVE-2023-20118), чтобы загружать через FTP шелл-скрипт с именем q. Затем этот скрипт скачивал и запускал бэкдор PolarEdge на скомпрометированном устройстве.
«Основная функция бэкдора — отправить данные о хосте на управляющий сервер, а затем ожидать команд через встроенный TLS-сервер, реализованный с помощью mbedTLS», — рассказывают теперь специалисты Sekoia.
PolarEdge поддерживает два режима работы: режим обратного подключения, где бэкдор выступает в роли TLS-клиента для загрузки файла с удаленного сервера, и отладочный режим, где бэкдор переходит в интерактивный режим для изменения конфигурации (то есть информации о сервере).
Конфигурация встроена в последние 512 байт ELF-файла и обфусцирована с помощью XOR с однобайтовым ключом 0x11. Однако по умолчанию малварь функционирует как TLS-сервер, который передает своим операторам информацию о зараженной системе и ожидает дальнейших команд.
TLS-сервер реализован с помощью mbedTLS v2.8.0 и использует кастомный бинарный протокол для парсинга входящих запросов, соответствующих определенным критериям, включая параметр с именем HasCommand. Так, если параметр HasCommand равен ASCII-символу 1, бэкдор извлекает и выполняет команду, указанную в поле Command, и передает обратно результат выполненной команды.
После запуска PolarEdge также перемещает (/usr/bin/wget, /sbin/curl) и удаляет определенные файлы (/share/CACHEDEV1_DATA/.qpkg/CMS-WS/cgi-bin/library.cgi.bak) на зараженном устройстве. Примечательно, что пока неясно, зачем злоумышленникам нужен этот шаг.
Кроме того, бэкдор использует широкий спектр методов защиты от анализа, чтобы скрыть информацию о настройке TLS-сервера и логике фингерпринтинга. Чтобы избежать обнаружения, он применяет маскировку процесса на этапе инициализации, случайным образом выбирая имя из предопределенного списка. Некоторые из имен: igmpproxy, wscd, /sbin/dhcpd, httpd, upnpd и iapp.
«Хотя бэкдор не обеспечивает сохранение после перезагрузки, он вызывает fork для порождения дочернего процесса, который каждые 30 секунд проверяет, существует ли еще /proc/<parent-pid>, — объясняют исследователи. — Если директория исчезла, дочерний процесс выполняет шелл-команду для перезапуска бэкдора».
