Инструменты и методы, лежащие в основе атак программ-вымогателей Anubis

Не удалось прогрузить медиа

От CitrixBleed 2 до Cloudflared: инструменты и методы, лежащие в основе атак программ-вымогателей Anubis​

Ключевые выводы​

• С начала 2026 года Arctic Wolf расследует взломы программ-вымогателей Anubis, связанные как с использованием действительных VPN-учетных данных, так и с использованием CitrixBleed 2 (CVE-2025-5777), расширяя известные методы первичного доступа, связанные с этим брендом вымогателей.
• Хотя тактики различаются между аффилированными компаниями, общие закономерности в ремесле проявились благодаря использованию легитимных инструментов удалённого управления и мониторинга (RMM), доступа к учетным данным и практических процедур использования клавиатуры для горизонтального перемещения.
• Аффилиаты Anubis неоднократно злоупотребляли легитимными инструментами удалённого доступа и администрирования, включая ScreenConnect, Zoho Assist, MeshAgent, Remotely, UltraVNC и Total Software Deployment, чтобы интегрироваться в обычную ИТ-активность, сохраняя при этом контроль над системами жертв.
• Многочисленные вторжения показали, что злоумышленники нацеливались на высокоценную инфраструктуру, такую как серверы Microsoft Remote Desktop Services, контроллеры доменов, гипервизоры, системы рядом с резервным копированием и устройства сетевого хранения (NAS), что увеличивало операционное воздействие и сложность восстановления.
• В некоторых случаях злоумышленники пытались установить альтернативные исходящие пути доступа с помощью таких инструментов, как cloudflared, аутентифицированные прокси и туннелирование SOCKS на основе SSH.

Краткое содержание​

В течение 2026 года Arctic Wolf расследовала несколько вторжений программ-вымогателей Anubis. Хотя методы взаимодействия со злоумышленниками различаются между вторжениями, выявятся ключевые темы: злоупотребление инфраструктурой VPN, слияние с легальной деятельностью с помощью решений удалённого мониторинга и управления (RMM), а также использование других легитимных бинарных файлов на устройствах жертвы.

Публичные отчёты в основном сосредоточены на модели вымогателей как услуге (RaaS), партнерской программе и загрузке шифровщиков. В этой исследовательской публикации мы предоставляем новое понимание методов первичного доступа в случаях с вымогателями Anubis, включая эксплуатацию CitrixBleed 2 (CVE-2025-5777). Мы также сообщаем о скрытном использовании инструментов RMM для слияния с легальной деятельностью, а также о различных других техниках обхода от мер безопасности в условиях жертв. Понимание этих поведений даёт защитникам возможности для раннего выявления и сдерживания.

Поскольку Anubis работает как группа RaaS, этот отчёт следует рассматривать как сборник профессиональных практик на уровне аффилиата, наблюдаемых при нескольких вторжениях, а не как поведение одного единого оператора.

Предыстория​

Anubis публично отслеживается как RaaS-операция с партнерской монетизацией, кражей данных, шифрованием и опциональной функцией деструктивного стирания. Название Anubis появилось в конце 2024 года как ребрендинг операции вымогателей Sphinx, что связано с изменением расширения зашифрованного файла с .sphinx на .anubis. Новая операция с вымогателями была официально объявлена на подпольном форуме RAMP (Ransomware and Advanced Malware Protection) 23 февраля 2025 года. С тех пор Anubis эволюционировала из одной версии вымогателей в многоплатформенную, мульти-аффилированную экосистему, заявив до 83 жертв на сайте утечки данных.

Вторжения, рассмотренные для этой публикации, показывают, как злоумышленники, связанные с Anubis, используют практическое сочетание коммерческих инструментов, нативной функции Windows и товарного мастерства для перехода от доступа к воздействию. В результате деятельность может напоминать законное управление в изоляции, но становится более характерной, если рассматривать её как цепочку связанных поведенческих проявлений.

Не удалось прогрузить медиа

Технические детали​

Начальные паттерны доступа​

В всех вторжениях, рассмотренных в этой исследовательской публикации, первоначальный доступ обычно делится на две категории: действительное использование учетных данных VPN и эксплуатация удалённых уязвимостей, таких как CitrixBleed 2 (CVE-2025-5777).

CitrixBleed 2 — это уязвимость раскрытия памяти предварительной аутентификации, которая может раскрывать материалы сессии с затронутых устройств NetScaler, создавая риск захвата сессии и обхода многофакторной аутентификации (MFA) при получении действительных токенов сессии. В случаях эксплуатации эта активность, как правило, также происходила с публичных IP-адресов, связанных с VPS-хостинг-провайдерами.


В приведённом выше примере лог-линии IP исходного IP-адреса злоумышленника — 45.227.254[.]25 отличается от значения Client_ip, которое было широкополосным IP-адресом, с которого была изначально создана сессия. Различие между этими двумя полями не всегда подтверждает злонамеренность, так как ожидается, что они будут расходиться при переключении пользователя между сетевыми провайдерами (например, сотовый оператор на Wi-Fi или наоборот). Однако эта активность всё ещё вызывает подозрения, поскольку легальная VPN-активность чаще всего исходит от провайдеров широкополосного доступа (как это было с исходным значением Client_ip), а не от VPS-хостингов.

Помимо эксплуатации CitrixBleed 2, были зафиксированы действительные входы в VPN Cisco AnyConnect с нескольких хостинговых ASN, включая AS20473 — The Constant Company и AS55286 — ServerMania. За злонамеренной аутентификациями VPN следовала активность входа с использованием RDP и SMB, что приводило к доступу к учетным данным, созданию сервиса PsExec, развертыванию RMM и, в конечном итоге, к вызову инструментов облачной передачи для эвакуации.

В подгруппе вторжений, связанных с действительными VPN-учетными данными, источник этих данных не удалось окончательно установить с имеющимися доказательствами. Возможные источники включают предварительное скомпрометирование инфраструктуры удалённого доступа, покупку у брокеров первичного доступа (IAB), подбор учетных данных или другие операции по краже учетных данных.

Боковое перемещение через RDP и PsExec​

Протокол удалённого рабочего стола (RDP) был распространённым механизмом для горизонтального перемещения клавиатуры между рассмотренными вторжениями. Выделялась закономерность не только в использовании RDP, но и в использовании RDP из необычных исходных систем или VPN-клиентов в инфраструктуру, которая обычно не получает интерактивных входов в легальных рабочих процессах.

В отличие от обычного доступа к рабочей станциям, злоумышленники часто использовали RDP между клиентскими подсетями VPN и серверами, размещающими сервисы удалённого рабочего стола, сервисы, связанные с Citrix, файловые серверы, контроллеры доменов, гипервизоры и резервную инфраструктуру.

Существующие серверы Windows в некоторых случаях использовались как точки перехода RDP к другим серверам в скомпрометированных средах. Назначения RDP для этих прыжковых хостов включали файловую/информационную инфраструктуру, серверы баз данных, резервные серверы и контроллеры доменов. В некоторых случаях серверы Hyper-V служили отправной точкой для злоумышленников в течение нескольких дней. При вторжениях программ-вымогателей серверы гипервизоров часто подвергаются ранней целью для получения доступа к учетным данным, поскольку виртуальные диски контроллера домена могут раскрывать учетные данные, если злоумышленники получают доступ к ним через базовое хранилище виртуальной машины (VM).

Помимо RDP, PsExec также использовался для боковых перемещений при множественных интрузиях Анубиса. Обычно создание PSEXESVC.exe сервисов появлялось в том же окне активности, что и подозрительный удалённый доступ, перемещение SMB или RDP, развертывание RMM и инсценировка программ-вымогателей.

Злоупотребление инструментами RMM​

Одним из самых отличительных операционных паттернов, наблюдаемых при вторжениях Анубиса, является внедрение легитимных инструментов RMM для постоянного доступа. К этим решениям относились ScreenConnect, Zoho Assist, MeshAgent, Remotely, Total Software Deployment, UltraVNC и mRemoteNG. Установка этих инструментов на целевые устройства предоставляет злоумышленникам интерактивный доступ, передачу файлов, удалённое выполнение и сохранение на основе сервиса, а также интеграцию с программным обеспечением, широко используемым ИТ-командами.

Zoho Assist обычно появлялся в нескольких системах в одной среде, с артефактами в пути неприсмотренного агента ZohoMeeting, а установщик был идентифицирован как ZN.MSI. Компоненты включали sessionaudit.exe, agent_ui.exe, zmagent.exe, toolsmanager.exe и связанные с ними бинарные сервисы Zoho Assist.

ScreenConnect также появился как злоупотребленное решение RMM, взаимодействующее с ретрансляторной инфраструктурой relay.promotds[.]Мы. В одном случае установщик ScreenConnect был загружен с https[:]//azuremicrosoft[.]us/Bin/ScreenConnect[.]ClientSetup.msi — доменное имя, созданное под архитектуру Microsoft Azure. Артефакты ScreenConnect появились вместе с созданием сервиса PsExec, staging Anubis encryptor под C:\Users\Default\AppData\ и компонентами браузера S3 под тем же профилем пользователя.

MeshAgent был развернут под именами файлов, включая mvtcs.exe и sysagent.exe, с соответствующими артефактами конфигурации и базы данных, такими как mvtcs.msh, mvtcs.db и mvtcs.log. В одном из вторжений устойчивость была усилена запланированной задачей MeshUserTask, а активность MeshAgent появилась вместе с cloudflared, SSH-туннелированием и развертыванием программ-вымогателей Anubis в системах Windows и Linux.

Remotely Desktop устанавливался на нескольких хостах Windows Server и отображался как Remotely_Desktop.dll, с соответствующими C2-связями с 45.76.79[.]92.

Полное развертывание программного обеспечения использовалось в качестве административного механизма развертывания, включая создание Total Software Deployment Audit Service и выполнение tniwinagent.exe из %SystemRoot%\TNIWINAGENT\. В том же кластере активности аффилированные лица использовали этот инструмент для передачи агентов между несколькими хостами, создавая телеметрию установки сервисов, которая выделялась наряду с логотипами SMB, активностью RDP и позднее выполнением программ-вымогателей.

Туннелирование и прокси-инфраструктура​

cloudflared — это клиент туннеля Cloudflare, который может использоваться для создания исходящих туннелей от внутреннего хоста к инфраструктуре, управляемой Cloudflare.

В некоторых случаях злоумышленники были замечены при установке и попытках установить туннели в пострадавшие среды с помощью туннеля Cloudflare (cloudflared) на устройствах с сетевым хранением (NAS) или серверах Windows. Артефакты Windows cloudflared.exe бинар находились в каталоге C:\Windows, а каталог /usr/local/etc/cloudflred использовался на устройствах Synology NAS.

В одном из вторжений, связанных с NAS-устройством Synology, злоумышленник вошёл в DiskStation Manager с помощью скомпрометированной доменной учётной записи, создал выделенную учетную запись локального администратора на устройстве NAS, предоставив ему широкие привилегии, включая доступ к DiskStation Manager, SMB, SFTP, FTP, File Station и rsync. Тот же аккаунт затем использовался для установления SFTP-соединения с целью передачи нескольких мегабайт файлов на NAS-устройство. Последующие сессии SSH устанавливались из внутреннего устройства, за которыми следовал sudo su для получения корневой оболочки. Хотя точные имена файлов из передачи SFTP не были зафиксированы, через несколько минут была выполнена команда cloudflared, ссылавшаяся на cert.pem и config.yml.

Из корневой оболочки актор инсценировал инструменты удалённого доступа и работал с /usr/local/etc/cloudflared для настройки Cloudflare Tunnel. Команды показывают создание именованного туннеля, повторное выполнение с помощью HTTP/2 и попытки фонового запуска с помощью nohup. Захваченный выход показывал метаданные запуска туннеля, включая идентификатор туннеля и идентификатор соединителя, а также повторяющиеся сбои при TLS-рукопожатии и проверке сертификатов. Доступные логи не подтверждают, что был успешно создан пригодный туннель Cloudflare.

Злоумышленник протестировал несколько путей выхода. Они попытались запустить cloudflared, перенаправляя коммуникации через аутентифицированный HTTP-прокси, размещённый на AS44477 — Stark Industries Solutions Ltd, и протестировали прокси с помощью curl. После попыток туннеля Cloudflare актор настроил динамическое пересылку на основе SSH через инфраструктуру VPS, размещённую на AS399629 – Bl Networks. История команд Shell показывала ED25519 генерацию ключей, этапы установки открытого ключа, команды проверки и создание локального прокси SOCKS на версии 127.0.0[.]1:1080 с использованием ssh -D. Хотя прокси SOCKS был отделен от аутентифицированного HTTP-прокси, используемого в Cloudflared, оба служили одной и той же практической цели: маршрутизации исходящего трафика с NAS через инфраструктуру, контролируемую злоумышленниками или доступную для атакующих.

В течение дня после настройки этих выходных путей злоумышленник вернулся на NAS и запустил шифрователь Linux Anubis против томов NAS, а также шифровал активы на базе Windows по всей среде.

Доступ к учётным данным​

Использование Mimikatz на серверах Windows часто наблюдалось между несколькими вторжениями и обычно осуществлялось в таких местах, как C:\Users\Public\Videos\mimikatz.exe, C:\Users\Public\mimikatz.exe и C:\x64\mimikatz.exe.

Кроме того, извлечение учетных данных браузера осуществлялось через имена файлов, такие как Chrome Passwords.csv и Microsoft Edge Passwords.csv. Эти артефакты с именами файлов соответствуют активности экспорта паролей из сохранённых браузеров через Google Chrome и Microsoft Edge вручную, а не прямого извлечения материалов для входа в Windows из памяти. Экспорт паролей браузера может открывать VPN, облако, SaaS, административный портал или личные учетные данные, поддерживающие последующий доступ и рабочие процессы вымогательства.

Доступ к базе данных Active Directory ntds.dit также наблюдался через логи Windows Extensible Storage Engine, что подтверждается созданием нового файла базы данных под C:\audit\Active Directory\ntds.dit в репрезентативном вторжении. В течение минуты после сохранения этой копии базы данных в файловую систему архив под названием Active Directory.zip также сохранялся на рабочем столе. Такой тип доступа позволяет офлайн-извлекать данные доменных учетных данных, предоставляя злоумышленникам с вымогателями путь к более широкой компрометации аккаунтов даже при прерывании отдельных интерактивных сессий. Менее чем через час после извлечения ntds.dit по всей среде началось шифрование с помощью программ-вымогателей.

Облачное хранилище и инструменты для эвакуации​

Несколько вторжений включали внедрение инструментов, широко используемых для передачи или эксфильтрации данных, включая S3 Browser, rclone, s5cmd, WinSCP и PuTTY.

В одном из вторжений появились артефакты браузера S3 вместе с активностью ScreenConnect и staging шифроустройства Anubis. Имеющиеся данные показывают, что в нескольких случаях злоумышленники устанавливали программное обеспечение через установщик s3browser-13-1-1.exe после загрузки установщика в пользовательскую папку «Загрузки». Исполняемые файлы браузера S3 находились в нескольких каталогах:

C:\Program Files\S3 Browser
C:\Users\Default\AppData\Local\S3 Browser

Другие случаи включали артефакты rclone и s5cmd. Эти утилиты часто используются для большого объёма взаимодействия с облачными сервисами хранения и могут быть привлекательны для партнеров-вымогателей, поскольку они эффективны, скриптируемы и совместимы с несколькими серверами хранения. В рассмотренных вторжениях Anubis эти инструменты встречались наряду с другими действиями предварительного шифрования, включая развертывание RMM, доступ к учетным данным и вмешательство в инструменты безопасности.

Уклонение от защиты​

Злоумышленники в вторжениях вымогателей Anubis пытались ослабить защитную видимость и усложнить анализ после инцидента. Эти методы включали отключение защиты Windows Defender в реальном времени, активность SophosUninstall, артефакты, связанные с PCHunter, а также очистку или манипуляцию логами на нескольких системах.

Уклонение варьировалось в зависимости от вторжений. В некоторых случаях вмешательство в защиту конечных точек проявлялось в основном как прямое отключение или попытка удаления инструментов безопасности. В других случаях очистка журналов повлияла на видимость ключевых источников событий Windows, включая System, PowerShell, Task Scheduler, AppLocker и Defender. По крайней мере в одном вторжении шифратор Anubis был удалён после выполнения, что снизило доступность артефактов полезной нагрузки на диске для дальнейшего анализа. Эти действия свидетельствуют о попытке затруднить способность защитников документировать злонамеренную деятельность на протяжении всего инцидента.

Развертывание программ-вымогателей Anubis​

Развертывание программ-вымогателей Anubis на Windows и Linux генерирует зашифрованные файлы с расширением .anubis и заметки с выкупом под названием RESTORE FILES.html. Обнаружения Microsoft Defender включали Ransom:Win64/Anubis.A.

В Windows имена файлов шифрователей включали такие имена, как win.exe, wmi.exe, s.exe, {REDACTED_6_DIGIT_NUMBER}_win64_encrypt.exe. Шифраторы Linux использовались по схеме названия {REDACTED_6_DIGIT_NUMBER}_encrypt_x86_64.

Эти шифрующие бинарные файлы отображались в различных каталогах файловой системы, включая следующие:

C:\Apps
C:\PerfLogs
C:\Users\REDACTED\Desktop
C:\Users\REDACTED\AppData
C:\Users\REDACTED\AppData\Local
C:\Users\
Public C:\Windows\Temp_netscan

Не удалось прогрузить медиа

Рисунок 2: Публикации жертв утечки сайта Анубиса, отслеживаемые по месяцам

Заключение​

Вторжения Anubis, рассмотренные Arctic Wolf, показывают операцию вымогателя, которой не требуется новый набор инструментов для серьёзного воздействия. Многие из самых заметных проявлений поведения были менее значимыми, если рассматривать их отдельно. Их значимость заключалась в том, как злоумышленники объединяли их в повторяемый путь от первоначального доступа к вымогательству.

Самый важный защитный паттерн — это не какой-либо один индикатор или инструмент, а последовательность действий: подозрительный удалённый доступ → необычное перемещение RDP или SMB → несанкционированное развертывание RMM → доступ к учетным данным → вмешательство в контроль безопасности → инструменты эвакуации → поэтапное выполнение программы-вымогателей. Организации, способные обнаружить и нарушить эту цепочку до шифрования, лучше подходят для сдерживания операций с Anubis и подобными программами-вымогателями.

Поэтому Anubis следует понимать не только как программу-вымогатель. Это аффилированная экосистема, которая использует гибкие, практичные методы для превращения общих административных путей в инфраструктуру вымогательства. Лучшие возможности для сбоев появляются до шифрования, когда аномалии аутентификации, развертывание RMM, доступ к учетным данным и инструменты эксфильтрации начинают концентрироваться вокруг одних и тех же хостов и аккаунтов.