Южнокорейские власти раскрыли кампанию, в которой заражение шло не через вложение в письме, а через обычный визит на легитимный сайт. Уязвимость в AnySign4PC позволяла установить бэкдор на Windows-машины с уязвимой версией компонента для электронной подписи, причем пользователю не нужно было ничего подтверждать или скачивать вручную.
Для русскоязычной IT-аудитории вывод здесь неприятно знакомый: локальные «обязательные» модули безопасности при банках, госуслугах и работе с сертификатами давно стали такой же поверхностью атаки, как браузер, VPN-клиент или почтовый агент.
Что нашли KISA и исследователи
О кампании сообщили KISA, Национальная разведслужба Южной Кореи, Национальное полицейское агентство и Financial Security Institute. В разборе также участвовали AhnLab, S2W, ENKI Whitehat и Plainbit. По данным корейских уведомлений, под угрозой оказались версии AnySign4PC до 1.1.4.6 включительно. В качестве исправления указывали ветку 1.1.5.x, а организациям и пользователям рекомендовали обновиться до актуального релиза и удалить старые установки.
Ключевой момент в том, что AnySign4PC — не экзотическая утилита, а массовый компонент, который ставят при работе с финансовыми и государственными сервисами. Поэтому речь идет не о редком баге «для лаборатории», а об уязвимости в ПО, встроенном в повседневные бизнес-процессы.
Как работала watering hole-атака
Сценарий был типичным для watering hole. Сначала атакующие использовали целевой фишинг под видом резюме, вакансий, инвестиционных материалов и опросов, а затем компрометировали сайты, куда жертвы действительно могли зайти. AhnLab писала о 15 легитимных сайтах, которые использовали как площадки для заражения, а также о следах связанной активности в 72 организациях в 2026 году. Это не значит, что подтверждены 72 полные компрометации: речь именно о выявленных индикаторах атаки.
По данным ENKI Whitehat, активность началась еще во второй половине 2025 года, то есть до публичного июньского предупреждения 2026 года. В одной из описанных цепочек четыре PNG-файла использовались для обмена ключами, проверки версии AnySign4PC, доставки нужного эксплойта и сигнала об успешном выполнении. Вредоносный код общался с локальным компонентом через WebSocket, вызывал переполнение буфера и запускал shellcode, после чего закреплялся в легитимных процессах Windows.
Какие инструменты ставили после взлома
На скомпрометированные машины устанавливали как минимум два семейства вредоносного ПО: Struggle, который AhnLab связывает с SIGNBT 3.0, и Brandoor, вариант бэкдора COPPERHEDGE. Их набор функций вполне ожидаем для шпионской операции: удаленное выполнение команд, кража файлов, разведка внутри сети, внедрение в процессы и доставка следующих стадий атаки.
Plainbit в отдельном форензическом разборе восстановила один из эпизодов почти по шагам. Злоумышленники изучили внешнюю инфраструктуру цели, взломали ее сайт, установили web shell и внедрили JavaScript в обычную новостную страницу. Когда пользователь открывал ее, уязвимый компонент создавал вредоносную DLL без заметного для человека окна загрузки. Затем бэкдор расшифровывал следующую стадию в памяти, внедрял код в svchost.exe и получал параметры командного сервера из реестра Windows. После первоначального доступа в ход шли Mimikatz, RDP и другие утилиты для кражи учетных данных и перемещения по сети.
Пересечение с атаками Gunra
AhnLab отдельно указала на технические пересечения с мартовской атакой 2026 года, где использовался шифровальщик Gunra. Исследователи нашли общий скомпрометированный медицинский сайт, ту же начальную уязвимость, одинаковые имена файлов net.tmp и inet.tmp, совпадающий SSH fingerprint и один и тот же адрес обратного туннеля 176.65.128[.]26. В обеих цепочках фигурировал домен jshosting[.]me, а вредоносные файлы перед удалением переименовывались в случайные четырехсимвольные имена.
Но из этого не следует автоматический вывод, что шпионаж и ransomware-атаки вела одна и та же группа. Исследователи осторожнее: это может быть общий брокер начального доступа, совместно используемая инфраструктура или обмен инструментами между разными операторами.
Что это значит для компаний
Практический вывод простой: проверять нужно не только браузеры, почту и EDR, но и весь локальный middleware вокруг сертификатов, банковских сервисов и электронной подписи. История с AnySign4PC показала, что «доверенный сайт» и «легитимный процесс Windows» сами по себе уже ничего не гарантируют, если рядом стоит уязвимый модуль, который браузер может дергать почти как API.
Для компаний в России и СНГ это особенно актуально: похожие клиентские компоненты до сих пор живут в корпоративных кабинетах, банковских интерфейсах и системах документооборота. Охотиться в таких случаях лучше не только за файлами, которые атакующий может быстро стереть, а за поведением: подозрительная загрузка DLL легитимными процессами, запуск PE-файлов только в памяти, нестандартные ветки реестра со служебными параметрами и неожиданные SSH-туннели наружу.
Следующий логичный шаг для ИБ-команд — инвентаризация таких модулей и их версий: пока они остаются обязательной частью критичных сценариев, они будут удобной точкой входа для следующей атаки.
Источник: The Hacker News, уведомления KISA и материалы AhnLab.