КИБЕРБЕЗОПАСНОСТЬ

Daxin вернулся: в Тайване нашли шпионский rootkit и новый бэкдор

Спустя более 4 лет Daxin снова нашли в сети тайваньского производителя: рядом работал новый бэкдор Stupig, активный еще до входа в Windows.

✍️ Редакция iTech News | 17.07.2026 | ⏱ 5 мин | Источник: The Hacker News
🔐

В сети тайваньского производителя снова нашли бэкдор Daxin — тот самый kernel-mode rootkit, который Symantec подробно описала еще в марте 2022 года, а его активность тогда связывали с целевыми атаками как минимум с 2013-го. На этот раз на зараженной машине работал не только Daxin, но и ранее не описанный бэкдор Stupig, который позволяет выполнять команды с правами SYSTEM прямо с экрана входа в Windows. Для русскоязычных ИБ-команд и IT-руководителей это неприятный, но полезный сигнал: старые шпионские инструменты никуда не делись, а тихо дожидаются, пока кто-то забудет про устаревший софт и «временные» исключения в инфраструктуре.

О находке сообщает The Hacker News со ссылкой на исследование Symantec и Carbon Black Threat Hunter Team. Компрометацию обнаружили в 2026 году на хосте тайваньской «дочки» международного high-tech производителя. На машине одновременно нашли Daxin, известный по файлу srt64.sys, и Stupig, который маскировался под системную библиотеку клавиатурной раскладки: вместо легитимного kbdus.dll в системе присутствовали a.dll или kbdus1.dll. Самое неприятное в этой истории не только в наборе инструментов, но и во временной линии: оба артефакта имели timestamp компиляции начала 2013 года, тогда как телеметрия с зараженного узла начала поступать только 12 мая 2026 года. То есть речь может идти о присутствии в сети, которое оставалось незамеченным до 13 лет.

Stupig выглядит особенно неприятно именно для защитников Windows-инфраструктуры. По данным Broadcom, этот бэкдор использует технику, которую не документировали ни для одного известного семейства вредоносного ПО. Он регистрируется как провайдер раскладки клавиатуры, из-за чего win32k.sys загружает его в процесс winlogon.exe при старте системы. При этом DLL возвращает корректный указатель KBDTABLES, поэтому сама раскладка работает штатно и не вызывает подозрений у администратора, который просто смотрит список загруженных модулей. Дальше начинается самое интересное: если на экране логина ввести имя пользователя, начинающееся со строки stupig, все, что идет после этого префикса, трактуется как команда и выполняется с правами SYSTEM. А если после префикса ничего не ввести, вредонос открывает командную строку с теми же привилегиями прямо до входа пользователя в систему и без стандартного события аудита входа.

Бэкдор Daxin работает иначе, но не менее изобретательно. Это драйвер уровня ядра, который не строит привычный исходящий канал связи с инфраструктурой атакующего. Вместо этого он следит за входящим TCP-трафиком, ищет в нем нужные шаблоны и перехватывает уже существующие легитимные соединения, чтобы прятать внутри них зашифрованный канал управления. Такой подход сильно осложняет жизнь сетевому мониторингу: снаружи все выглядит как нормальная активность, а не как новая подозрительная сессия куда-нибудь на редкий VPS. Дополнительно Daxin поддерживает многозвенную коммуникацию через цепочки зараженных хостов, что позволяет операторам добираться до сегментов, физически отрезанных от интернета. Если говорить по-простому, это инструмент не для массовой криминальной рассылки, а для долгой, терпеливой и дорогой шпионской работы.

Как именно злоумышленники попали в инфраструктуру, исследователи не установили, но у них есть рабочая гипотеза: входной точкой мог стать устаревший портал единого входа Digiwin SSO. По данным исследователей, он использовал давно снятые с поддержки JDK 1.5 и 1.6, причем инсталляции датировались 2009-2011 годами. Для любой корпоративной среды это звучит как учебный пример того, почему «не трогай, оно же работает» плохо сочетается с безопасностью. В реальности такие системы часто живут на стыке legacy, подрядчиков и внутренней бюрократии: бизнесу нужен старый портал, обновлять страшно, переписывать дорого, а потом в сети тихо живет шпионский набор, который умеет прятаться и не шуметь годами.

Отдельный нюанс в том, что прямых пересечений в коде между Daxin и Stupig исследователи не нашли. Формально это не позволяет со стопроцентной уверенностью сказать, что оба инструмента написал один и тот же оператор. Но косвенные признаки выглядят слишком аккуратно, чтобы их игнорировать: совместное присутствие на одном хосте, дополняющие друг друга функции, схожая инженерная дисциплина и одинаково старые timestamps компиляции. Поэтому версия об одном и том же китайско-связанном акторе выглядит логичной, хотя и не окончательной. Важнее другое: операция, которую многие могли считать закрытой страницей после публикации 2022 года, похоже, не завершалась. Она просто ушла в тень, а это для APT-групп почти стандартный режим работы.

Для разработчиков, инфраструктурных инженеров и руководителей здесь несколько практических выводов. Первый: проверка Windows-хостов только на предмет «странных процессов после логина» уже недостаточна, если злоумышленник получает SYSTEM еще на экране входа. Второй: старые Java-рантаймы, legacy SSO и подобные «исторические артефакты» нужно рассматривать как полноценный риск, а не как техдолг на потом. Третий: сетевые правила, заточенные на поиск классических исходящих C2-соединений, легко промахиваются мимо инструментов уровня Daxin, которые встраиваются в уже существующий трафик. Наконец, эта история неплохо ложится в более широкий тренд 2026 года: рядом с публикацией о Daxin исследователи Hunt.io сообщили, что другой подозреваемый китайско-связанный оператор использовал Claude Code и модели DeepSeek для автоматизации вторжений в государственные и финансовые системы в Афганистане, Таиланде, Тайване и США. Ирония в том, что атакующие охотно берут самые новые инструменты, но прекрасно уживаются и с малварью образца 2013 года, если она до сих пор работает.

Главный вопрос теперь не в том, «вернулся» ли бэкдор Daxin, а сколько еще таких наборов лежит в производственных и корпоративных сетях в режиме спячки. История с Тайванем показывает неприятную, но честную вещь: срок жизни шпионского инструмента больше не измеряется одной кампанией или одним CVE. Если у оператора есть терпение, доступ к legacy-системам и привычка не шуметь, то обнаружение через 10-13 лет уже выглядит не аномалией, а новой нормой для зрелого кибершпионажа.

Поделиться: Telegram X LinkedIn