Revenge RAT: Windows-троян удалённого доступа с модульной архитектурой и TCP-каналом C2

Семейство: Revenge RAT
Класс: RAT / средство удалённого управления
Раздел: RAT
Основание публикации: свежие наблюдения не старше 5 дней
Первое наблюдение в текущем наборе: 24.08.2026 05:15
Последнее наблюдение в текущем наборе: 24.08.2026 05:15
Образцов в пакете: 0; IOC: 1

Поведение, распространение и защита​


Что делает

Revenge RAT — семейство вредоносных программ удалённого доступа (Remote Access Trojan), ориентированное на платформу Windows. Инструмент распространяется по модели «RAT-as-a-service» и доступен широкому кругу операторов, что обусловливает его длительное присутствие в телеметрии SOC и threat-intelligence-площадок. В базе Malpedia семейство зарегистрировано как win.revenge_rat.

Функциональная модель строится вокруг постоянного канала управления между заражённым хостом и сервером оператора. Типичный набор возможностей семейства включает:

  • Удалённое управление рабочим столом: просмотр экрана в реальном времени, эмуляция клавиатуры и мыши.
  • Перехват нажатий клавиш (кейлоггер) с буферизацией и периодической отправкой на C2.
  • Доступ к веб-камере и микрофону целевого хоста.
  • Файловый менеджер: загрузка, выгрузка, удаление, запуск произвольных файлов.
  • Кража учётных данных из браузеров, FTP-клиентов и мессенджеров.
  • Управление процессами и службами, редактирование реестра.
  • Развёртывание дополнительной нагрузки (downloader-функция).

Коммуникация с C2-сервером осуществляется по протоколу TCP. В свежей телеметрии ThreatFox зафиксирован активный сетевой индикатор типа ip:port с категорией botnet_cc и тегом RevengeRAT, что подтверждает эксплуатацию выделенного TCP-канала для командного управления. Конкретные адреса в данный профиль не включаются.

Реализация семейства исторически связана с платформой .NET (C#), что определяет характерные артефакты: наличие метаданных CLR в PE-файле, использование пространств имён System.Net.Sockets, Microsoft.Win32 и аналогичных. Для затруднения статического анализа операторы нередко применяют обфускацию IL-кода и упаковку сторонними протекторами.

Закрепление на хосте типично выполняется через ключи автозагрузки реестра (HKCU\Software\Microsoft\Windows\CurrentVersion\Run и HKLM-аналог), помещение копии в каталог автозагрузки или создание задачи планировщика. Конкретный механизм в текущем пакете доказательств не подтверждён отдельным образцом.

Антианалитические приёмы, характерные для семейства: проверка признаков виртуальной среды (наименования драйверов, MAC-префиксы адаптеров, объём оперативной памяти), обнаружение отладчиков и песочниц по времени отклика или списку процессов. Уровень реализации этих проверок варьируется от сборки к сборке.

Технический разбор образцов

В текущем пакете доказательств технические образцы отсутствуют (technical_samples пуст). Разбор на уровне отдельного файла — формат, архитектура, размер, сигнатура, YARA-срабатывания, vendor-вердикты — не приводится, поскольку ни один экземпляр не передан для анализа. Подблоки «Образец 1», «Образец 2» и т. д. не формируются.

Единственный доступный артефакт — сетевой индикатор типа ip:port, зарегистрированный ThreatFox в категории botnet_cc и помеченный тегом RevengeRAT. Он подтверждает, что инфраструктура командного управления семейства активна и отслеживается, но не позволяет сделать вывод о конкретной сборке, способе доставки или точном наборе модулей в текущей кампании.

При появлении образцов в будущих обновлениях данный раздел будет дополнен постраничным разбором каждого файла.

Как распространяется

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

Типичные для семейства каналы распространения (family-level, высокая уверенность по совокупности открытых отчётов):

  • Вложения в фишинговых электронных письмах: исполняемые файлы, замаскированные под документы, или архивы с LNK/JS-обёртками.
  • Загрузка через поддельные страницы «обновлений» или «кряков» программного обеспечения.
  • Распространение через мессенджеры и файлообменные сервисы в виде архивов.
  • Эксплуатация уже скомпрометированных хостов для бокового перемещения в локальной сети.

Конкретный канал для зафиксированного C2-индикатора не определён.

Как обнаружить

  1. Сетевой мониторинг. Выявление исходящих TCP-соединений на нестандартные порты с характерным паттерном: периодические короткие сессии с фиксированным интервалом (heartbeat), отсутствие TLS или использование самоподписанных сертификатов. Корреляция с фидами ThreatFox по категории botnet_cc и тегу RevengeRAT.
  2. EDR / Sysmon. Контроль создания процессов из пользовательских каталогов (%AppData%, %LocalAppData%, %Temp%), особенно если родительский процесс — почтовый клиент или браузер. Обращение внимания на запуск .NET-сборок из нетипичных путей.
  3. Файловая активность. Появление исполняемых PE-файлов в каталогах автозагрузки и %AppData% с недавней датой создания; проверка на наличие ресурсов .NET (манифест, ссылки на mscorlib).
  4. Реестр. Мониторинг записей в HKCU/HKLM...\Run, ключах Winlogon\Shell, а также в разделах планировщика задач на предмет новых значений, указывающих на недавно созданные исполняемые файлы.
  5. Поведенческие признаки. Одновременный доступ одного процесса к API веб-камеры (DirectShow / Media Foundation), перехват клавиатуры через SetWindowsHookEx(WH_KEYBOARD_LL) и чтение файлов браузерных профилей (Login Data, Cookies) из %LocalAppData%.
  6. YARA / статические правила. Правила, ориентированные на строковые маркеры .NET-сборок Revenge RAT: характерные имена классов, mutex-строки, embedded-ресурсы с конфигурацией C2. Конкретные названия правил в текущем пакете не представлены; при появлении образцов следует сверяться с базой Malpedia (win.revenge_rat).
  7. Аномалии процессов. Процесс с именем, имитирующим системный (svchost, explorer, runtimebroker), но запущенный из пользовательского каталога и не имеющий корректной цифровой подписи Microsoft.
  8. Анализ памяти. При подозрении на упакованный .NET-образец — дамп процесса и поиск в нём строк конфигурации (адрес C2, порт, идентификатор кампании) после JIT-компиляции.

Что делать при заражении

  1. Изоляция хоста. Немедленно отключить сетевой адаптер или заблокировать порт на коммутаторе. Не выключать питание: оперативная память может содержать расшифрованную конфигурацию и активные сессии.
  2. Сохранение телеметрии. Зафиксировать дамп памяти подозрительного процесса, список сетевых соединений, журнал событий Windows (Security, Sysmon, PowerShell), снимок файловой системы затронутых каталогов.
  3. Оценка удалённого управления. Исходить из того, что оператор имел полный интерактивный доступ: проверить журнал запущенных команд, созданные файлы, изменения реестра и учётных записей за период компрометации.
  4. Проверка закрепления и вторичной нагрузки. Просканировать ключи автозагрузки, планировщик задач, каталоги %AppData% и %ProgramData% на предмет дополнительных исполняемых файлов, скриптов или DLL. Убедиться, что не загружен второй этап (loader/dropper).
  5. Ротация секретов. Если подтверждён или вероятен доступ к браузерным профилям, FTP-клиентам, мессенджерам или корпоративным учётным данным — немедленно сменить пароли, отозвать токены и сессионные cookie.
  6. Проверка бокового перемещения. Проанализировать журналы аутентификации (Event ID 4624/4625) на других хостах сегмента, поискать следы использования украденных учётных данных.
  7. Удаление артефактов или переустановка. Если целостность системы можно подтвердить (известен полный набор изменений, нет руткит-компонентов), допустимо точечное удаление. В противном случае — переустановка ОС из доверенного образа с восстановлением данных из чистых резервных копий.
  8. Пост-инцидентный мониторинг. В течение 2–4 недель усилить контроль за хостом и сегментом: алерты на повторное появление аналогичных сетевых паттернов, новые записи автозагрузки, нетипичные исходящие соединения.

Как снизить риск

  • Фильтрация вложений и загрузок. Блокировать исполняемые файлы (.exe, .scr, .bat, .js, .vbs) и архивы с ними на уровне почтового шлюза и веб-прокси; применять sandboxing для вложений.
  • Ограничение .NET-исполнения из пользовательских каталогов. Через AppLocker или WDAC запретить запуск неподписанных .NET-сборок из %AppData%, %Temp%, %LocalAppData%.
  • Контроль исходящих соединений. Ограничить исходящий TCP-трафик белым списком портов и протоколов; блокировать прямые исходящие соединения на произвольные порты для рабочих станций.
  • Защита браузерных хранилищ. Использовать менеджеры паролей с мастер-паролем и аппаратным ключом вместо встроенного хранения браузеров; ограничить доступ к файлам Login Data и Cookies политиками DLP.
  • Отключение неиспользуемых устройств. На рабочих станциях, где веб-камера и микрофон не требуются, отключить их на уровне драйвера или групповой политики, чтобы снизить ценность RAT-модулей захвата.
  • Обучение пользователей. Целевые фишинг-симуляции с акцентом на вложения и ссылки, имитирующие документы и обновления ПО; чёткая процедура сообщения в SOC.
  • Регулярное обновление threat-intelligence. Подписка на фиды ThreatFox и аналогичные источники по тегу RevengeRAT; автоматическое обогащение SIEM/EDR индикаторами категории botnet_cc.
  • Сегментация и минимальные привилегии. Ограничить права локального администратора на рабочих станциях; изолировать критические серверы в отдельные VLAN с контролем межсегментного трафика.

Источники​


  1. ThreatFox — IOC Revenge RAT
  2. Malpedia — Revenge RAT

История обновлений статьи​


  • 25.08.2026 — Опубликована первая версия материала.
 
Назад
Верх Низ