PolarEdge — нова загроза для мережевих і NAS‑пристроїв, яку дослідники вперше зафіксували в активних атаках у лютому 2025 року. За даними Sekoia та вимірювань інфраструктури Censys (серпень 2025), активність може тягнутися щонайменше з червня 2023-го. Набір технічних ознак вказує на ORB‑архітектуру — розподілені проксі‑мережі, що допомагають зловмисникам маскувати трафік і ускладнюють атрибуцію.
Масштаб і цілі: Cisco, ASUS, QNAP, Synology під прицілом
Оператори PolarEdge націлені на пристрої від Cisco, ASUS, QNAP і Synology, перетворюючи їх на вузли проксі‑ланцюгів. Такий підхід підвищує живучість ботнету: блокування окремих IP мало впливає на загальну керованість інфраструктури, а шкідливий трафік розчиняється серед легітимних з’єднань периферійних девайсів.
Вектор компрометації: експлуатація CVE-2023-20118 у маршрутизаторах Cisco
У зафіксованих атаках використовується відома уразливість CVE‑2023‑20118 у маршрутизаторах Cisco. Через FTP на пристрій завантажується невеликий shell‑скрипт q, який витягує і запускає бекдор PolarEdge. Це типовий для IoT/SoHo сценарій: мінімальний завантажувач створює точку опори, після чого встановлюється повнофункціональна шкідлива компонента.
Архітектура бекдора: TLS‑сервер, власний протокол і збір телеметрії
Ключова функція бекдора — збір відомостей про хост із подальшою передачею на C2 і очікування команд через вбудований TLS‑сервер. Реалізація спирається на mbedTLS v2.8.0 і кастомний бінарний протокол. Поле HasCommand керує виконанням команд: значення ASCII «1» змушує клієнт витягнути інструкцію з поля Command, виконати її на пристрої та повернути результат.
TLS‑клієнт/сервер і режими роботи
PolarEdge підтримує два режими: backconnect (бекдор ініціює TLS‑підключення та завантажує файли з віддаленого вузла) і «debug», що дозволяє інтерактивно оновлювати параметри, зокрема адреси керувальних серверів. За замовчуванням зловмисний модуль працює як TLS‑сервер і приймає під’єднання операторів.
Конфігурація та обфускація
Конфігураційні дані шифруються та вбудовуються в останній 512‑байтний сегмент ELF, після чого обфускуються операцією XOR із ключем 0x11. Такий простий, але дієвий прийом ускладнює статичний аналіз і вилучення C2‑параметрів без динамічного запуску зразка.
Антианаліз, маскування процесів і стійкість
Щоб знизити помітність, PolarEdge маскує процес під поширені системні імена: igmpproxy, wscd, /sbin/dhcpd, httpd, upnpd, iapp. Додатково бекдор переміщує /usr/bin/wget і /sbin/curl та видаляє /share/CACHEDEV1_DATA/.qpkg/CMS-WS/cgi-bin/library.cgi.bak. Призначення цих дій неочевидне; імовірно, це спроба завадити стандартним адмінопераціям або приховати сліди попередніх інструментів.
Механізм живучості без автозапуску
Автопостійність на рівні автозавантаження не реалізована, однак діє «сторожовий» механізм: батьківський процес виконує fork, а дочірній кожні 30 секунд перевіряє наявність /proc/<parent-pid>. Якщо батьківський процес зник, дочірній перезапускає бекдор через shell‑команду. Це ускладнює точкове завершення без повної санації пристрою.
Ознаки ORB і наслідки для мереж
Інфраструктурні патерни, задокументовані Censys, резонують із Operational Relay Box — мережами ретрансляторів, через які проксіюються керування та корисне навантаження. Для оборони це означає більшу фрагментацію C2, складність блокування по IP і довготривалу приховану присутність на периферійних вузлах, що підвищує ризик зловживання пропускною здатністю та бокових переміщень.
Виявлення і захист: практичні кроки для адміністраторів
1) Закриття уразливостей. Негайно встановіть оновлення прошивок для усунення CVE‑2023‑20118 та інших CVE. Вимкніть або обмежте FTP/TFTP, якщо сервіси не потрібні.
2) Полювання на ознаки компрометації. Шукайте «системні» процеси з нетиповою поведінкою; поява невідомого TLS‑сервера на IoT/NAS; зміну шляхів wget/curl; зникнення очікуваних резервних файлів.
3) Мережевий контроль. Сегментуйте IoT/NAS, обмежте прямий доступ з Інтернету, використовуйте allowlist для адмін‑сервісів. Моніторте вихідні з’єднання та застосовуйте NetFlow/PCAP для виявлення нетипових TLS‑рукостискань і власних протоколів поверх TLS.
PolarEdge ілюструє еволюцію ботнетів для периферійних пристроїв: мінімальний слід у системі, прихований TLS‑канал, гнучка конфігурація та ORB‑подібна інфраструктура. Щоб знизити ризики, поєднуйте своєчасні патчі, мережеву сегментацію, моніторинг аномалій і готовність до реагування. Проведіть аудит пристроїв, перевірте журнали та налаштуйте сповіщення — чим раніше виявите інцидент, тим менша ймовірність, що ваші ресурси стануть вузлом у чужій проксі‑мережі.
