Связанные с КНДР хакеры усложнили вредоносную кампанию XCTDH и превратили обычные транзакции Ethereum в канал для поиска управляющих серверов. Новый механизм HashHiding кодирует IP-адрес и порт C2 прямо в адресе получателя перевода, поэтому заражённому компьютеру не нужен домен, смарт-контракт или заранее известный адрес сервера. Для смены инфраструктуры оператору достаточно отправить новую транзакцию.
HashHiding работает необычно просто. Адрес получателя Ethereum занимает 20 байт, а вредонос считывает первые шесть байт как четыре части IPv4-адреса и номер порта. Например, последовательность B5 D6 95 94 превращается в 181.214.149.148, а следующие два байта 01 BB дают порт 443. Остальная часть адреса используется для дополнительного адреса и заполнения. Сам получатель придуман специально для передачи информации, приватного ключа к такому адресу у атакующих нет.
Большинство замеченных переводов не содержали ни одного wei, лишь несколько транзакций передавали 150 wei. Никакого вредоносного кода внутри транзакции тоже нет. Внешне блокчейн видит обычный перевод на очередной Ethereum-адрес, а смысл появляется только после расшифровки первых байтов заражённой программой.
Подобный механизм уже описывали в августе 2026 года под названием NullReceiver. Однако анализ блокчейна показал, что операторы XCTDH начали пользоваться подобной схемой раньше публичного раскрытия. Первый обнаруженный сигнал появился 23 июня. С 23 июня по 21 сентября один управляющий кошелёк отправил 2 655 транзакций, а средний промежуток между сигналами составлял около 49 минут.
За 90 дней злоумышленники четыре раза меняли закодированный C2. Сначала вредонос обращался к адресу 23.27.20.187 через порты 80 и 443, затем инфраструктура переехала на 181.214.149.147:443 и 181.214.149.148:443. Для заражённых машин смена почти незаметна: модуль регулярно просматривает свежие блоки Ethereum, находит транзакцию нужного отправителя, извлекает новый IP и продолжает работу уже с новым сервером.
HashHiding встроили в JavaScript-модуль _Z, который после снятия двух уровней обфускации сокращается примерно до 8,8 КБ рабочего кода. Модуль выбирает один из публичных Ethereum RPC-сервисов, узнаёт номер свежего блока, просматривает транзакции и ищет заданный фрагмент адреса отправителя. После обнаружения подходящей записи код извлекает C2-адрес, запрашивает путь /boot и запускает полученный Node.js-код отдельным скрытым процессом.
Главная проблема для защитников заключается в отказоустойчивости всей схемы. Вредонос одновременно использует три независимых способа найти C2-сервер: жёстко записанный IP-адрес, старую цепочку XCTDH через TRON, Aptos и BNB Smart Chain, а теперь ещё Ethereum. Все каналы работают параллельно, поэтому блокировка одного IP или одного RPC-сервиса не разрывает управление заражённой системой.
Предыдущая версия XCTDH уже использовала блокчейны для доставки вредоносных компонентов. TRON и Aptos служили указателями на транзакции BNB Smart Chain, где в calldata лежал зашифрованный JavaScript. В сентябрьской версии архитектура выросла до четырёх блокчейнов: Ethereum передаёт адрес управляющего сервера, TRON и Aptos помогают находить нужные записи, а BNB Smart Chain хранит вредоносные полезные нагрузки.
В цепочку входит троян удалённого доступа DEV#POPPER.js. Свежая версия выросла примерно до 2 500 строк Node.js-кода и умеет записывать нажатия клавиш, следить за буфером обмена, запускать командную оболочку и выполнять код удалённо. Вторая ветка атаки устанавливает Python 3.13 и 7-Zip, после чего загружает OmniStealer. Стилер охотится за данными браузеров, менеджеров паролей, облачных сервисов и 153 целями, связанными с криптовалютными кошельками.
Начальная точка заражения остаётся знакомой по кампании Contagious Interview. Связанные с КНДР операторы рассылают фальшивые предложения о работе, направляют разработчиков в подготовленные GitHub-репозитории или предлагают установить вредоносные npm-пакеты. После запуска проекта скрытый загрузчик получает дальнейшие компоненты через блокчейн и разворачивает полный набор инструментов для удалённого доступа и кражи данных.
Новый подход отличается от EtherHiding. EtherHiding прячет код или ссылки в данных транзакций и смарт-контрактах, поэтому защитники могут искать характерные обращения к контрактам и необычное содержимое calldata. HashHiding не требует ни контракта, ни поля с полезной нагрузкой. Управляющий адрес скрывается в самом адресе получателя, а новый C2 можно опубликовать без изменения вредоносной программы.
Для обнаружения активности исследователи предлагают отслеживать изменения адресов получателей у сигнального кошелька, запросы eth_getBlockByNumber к публичным Ethereum RPC-сервисам с последующими подключениями к необычным IP-адресам, а также процессы Node.js с характерными параметрами запуска. Главным постоянным индикатором пока остаётся кошелёк 0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891. Смена управляющего IP требует одной новой транзакции, поэтому обычные списки блокировки адресов быстро теряют актуальность.
