Группировка UNC4899, связанная с Северной Кореей, провернула в 2025 году одну из самых изощренных краж в криптоиндустрии. Всё началось с того, что разработчик перекинул файл с личного устройства на рабочий ноутбук. Закончилось — выводом нескольких миллионов долларов в цифровых активах. Детали атаки раскрыты в отчёте Google Cloud под названием H1 2026 Cloud Threat Horizons, материалы которого были переданы изданию The Hacker News.
UNC4899 известна и под другими именами: Jade Sleet, PUKCHONG, Slow Pisces, TraderTraitor. Google Cloud с умеренной степенью уверенности атрибутирует эту группировку как государственного актора КНДР. Целью стала неназванная криптовалютная организация. Схема атаки примечательна тем, что в ней переплелись социальная инженерия, злоупотребление облачными сервисами и так называемая техника Living-off-the-Cloud (LOTC) — когда атакующие используют легитимную инфраструктуру жертвы, чтобы оставаться незамеченными.
Первый этап выглядел почти буднично. Злоумышленники убедили разработчика скачать вредоносный архив, замаскированный под совместный open-source проект. Разработчик загрузил файл на личное устройство, а потом через AirDrop отправил его на корпоративную рабочую станцию. Именно этот момент — переброс данных с личного девайса на рабочий — оказался критическим. Никакой корпоративный периметр защиты здесь не сработал.
Дальше разработчик открыл архив в IDE с AI-ассистентом. Внутри оказался вредоносный код на Python, который при запуске породил бинарный файл, маскирующийся под утилиту командной строки Kubernetes. Этот бинарник связался с доменом, контролируемым атакующими, и фактически превратил рабочую машину в бэкдор. Злоумышленники получили плацдарм внутри корпоративной сети.
С рабочей станции группировка UNC4899 перешла в облачную среду Google Cloud, воспользовавшись сохранёнными на машине аутентифицированными сессиями и доступными учётными данными. Они обнаружили бастионный хост и модифицировали его политику многофакторной аутентификации (MFA), обойдя дополнительный уровень защиты. После этого хакеры начали изучать среду Kubernetes, перемещаясь между подами.
Для закрепления в системе атакующие изменили конфигурации развёртывания Kubernetes так, чтобы при создании каждого нового пода автоматически выполнялась bash-команда, подгружающая бэкдор. Это типичный пример LOTC — злоумышленники не ставили какое-то экзотическое ПО, а использовали штатные механизмы оркестрации контейнеров. Обнаружить такое гораздо сложнее, чем стандартное вредоносное ПО.
Затем UNC4899 добралась до CI/CD-платформы жертвы. Хакеры модифицировали привязанные к ней ресурсы Kubernetes, чтобы инжектировать команды, выводящие токены сервисных аккаунтов в системные логи. Из логов был извлечён высокопривилегированный токен CI/CD-аккаунта. С ним атакующие продвинулись к поду, управляющему сетевыми политиками и балансировкой нагрузки. Этот под работал в привилегированном режиме — и хакеры сумели «сбежать» из контейнера, развернув ещё один постоянный бэкдор уже на уровне инфраструктуры.
Финальная фаза была направлена на деньги. Злоумышленники нашли рабочую нагрузку, управляющую данными клиентов: идентификаторами пользователей, настройками безопасности аккаунтов и информацией о криптокошельках. Статические учётные данные для базы хранились прямо в переменных окружения пода — без какого-либо секретного хранилища. Хакеры извлекли эти креденшелы и подключились к продакшн-базе данных через Cloud SQL Auth Proxy.
Получив доступ к базе, UNC4899 выполнила SQL-команды для модификации наиболее ценных пользовательских аккаунтов: сбросила пароли и обновила MFA-сиды. После этого атакующие вошли в скомпрометированные аккаунты и вывели несколько миллионов долларов в цифровых активах. Вся цепочка — от вредоносного архива до кражи денег — прошла через слабые места, которые по отдельности могли бы казаться незначительными.
Google Cloud в своём отчёте дал конкретные рекомендации для снижения масштаба подобных инцидентов. Среди них: внедрение контекстно-зависимых контролей доступа, обязательное использование фишинг-устойчивой MFA, развёртывание только доверенных образов контейнеров, изоляция скомпрометированных узлов от внешних хостов, мониторинг неожиданных процессов в контейнерах. Отдельно подчёркивается необходимость полноценного управления секретами — никаких статических кредов в переменных окружения.
Ещё одна рекомендация касается того самого AirDrop. Google Cloud советует жёстко ограничить или полностью запретить P2P-передачу файлов, включая AirDrop и Bluetooth, на корпоративных устройствах. Так же следует ограничить подключение неуправляемых внешних носителей и обеспечить строгую изоляцию внутри облачных сред выполнения. Вся история с UNC4899 показывает: граница между личным и рабочим устройством сотрудника может стоить компании миллионы.
Изображение носит иллюстративный характер
UNC4899 известна и под другими именами: Jade Sleet, PUKCHONG, Slow Pisces, TraderTraitor. Google Cloud с умеренной степенью уверенности атрибутирует эту группировку как государственного актора КНДР. Целью стала неназванная криптовалютная организация. Схема атаки примечательна тем, что в ней переплелись социальная инженерия, злоупотребление облачными сервисами и так называемая техника Living-off-the-Cloud (LOTC) — когда атакующие используют легитимную инфраструктуру жертвы, чтобы оставаться незамеченными.
Первый этап выглядел почти буднично. Злоумышленники убедили разработчика скачать вредоносный архив, замаскированный под совместный open-source проект. Разработчик загрузил файл на личное устройство, а потом через AirDrop отправил его на корпоративную рабочую станцию. Именно этот момент — переброс данных с личного девайса на рабочий — оказался критическим. Никакой корпоративный периметр защиты здесь не сработал.
Дальше разработчик открыл архив в IDE с AI-ассистентом. Внутри оказался вредоносный код на Python, который при запуске породил бинарный файл, маскирующийся под утилиту командной строки Kubernetes. Этот бинарник связался с доменом, контролируемым атакующими, и фактически превратил рабочую машину в бэкдор. Злоумышленники получили плацдарм внутри корпоративной сети.
С рабочей станции группировка UNC4899 перешла в облачную среду Google Cloud, воспользовавшись сохранёнными на машине аутентифицированными сессиями и доступными учётными данными. Они обнаружили бастионный хост и модифицировали его политику многофакторной аутентификации (MFA), обойдя дополнительный уровень защиты. После этого хакеры начали изучать среду Kubernetes, перемещаясь между подами.
Для закрепления в системе атакующие изменили конфигурации развёртывания Kubernetes так, чтобы при создании каждого нового пода автоматически выполнялась bash-команда, подгружающая бэкдор. Это типичный пример LOTC — злоумышленники не ставили какое-то экзотическое ПО, а использовали штатные механизмы оркестрации контейнеров. Обнаружить такое гораздо сложнее, чем стандартное вредоносное ПО.
Затем UNC4899 добралась до CI/CD-платформы жертвы. Хакеры модифицировали привязанные к ней ресурсы Kubernetes, чтобы инжектировать команды, выводящие токены сервисных аккаунтов в системные логи. Из логов был извлечён высокопривилегированный токен CI/CD-аккаунта. С ним атакующие продвинулись к поду, управляющему сетевыми политиками и балансировкой нагрузки. Этот под работал в привилегированном режиме — и хакеры сумели «сбежать» из контейнера, развернув ещё один постоянный бэкдор уже на уровне инфраструктуры.
Финальная фаза была направлена на деньги. Злоумышленники нашли рабочую нагрузку, управляющую данными клиентов: идентификаторами пользователей, настройками безопасности аккаунтов и информацией о криптокошельках. Статические учётные данные для базы хранились прямо в переменных окружения пода — без какого-либо секретного хранилища. Хакеры извлекли эти креденшелы и подключились к продакшн-базе данных через Cloud SQL Auth Proxy.
Получив доступ к базе, UNC4899 выполнила SQL-команды для модификации наиболее ценных пользовательских аккаунтов: сбросила пароли и обновила MFA-сиды. После этого атакующие вошли в скомпрометированные аккаунты и вывели несколько миллионов долларов в цифровых активах. Вся цепочка — от вредоносного архива до кражи денег — прошла через слабые места, которые по отдельности могли бы казаться незначительными.
Google Cloud в своём отчёте дал конкретные рекомендации для снижения масштаба подобных инцидентов. Среди них: внедрение контекстно-зависимых контролей доступа, обязательное использование фишинг-устойчивой MFA, развёртывание только доверенных образов контейнеров, изоляция скомпрометированных узлов от внешних хостов, мониторинг неожиданных процессов в контейнерах. Отдельно подчёркивается необходимость полноценного управления секретами — никаких статических кредов в переменных окружения.
Ещё одна рекомендация касается того самого AirDrop. Google Cloud советует жёстко ограничить или полностью запретить P2P-передачу файлов, включая AirDrop и Bluetooth, на корпоративных устройствах. Так же следует ограничить подключение неуправляемых внешних носителей и обеспечить строгую изоляцию внутри облачных сред выполнения. Вся история с UNC4899 показывает: граница между личным и рабочим устройством сотрудника может стоить компании миллионы.
