RatonRAT: Windows-ботнет с IP-адресным C2-управлением — профиль семейства и подходы к детектированию

Семейство: RatonRAT
Класс: ботнет-вредонос
Раздел: Ботнеты
Основание публикации: свежие наблюдения не старше 5 дней
Первое наблюдение в текущем наборе: 26.08.2026 15:06
Последнее наблюдение в текущем наборе: 26.08.2026 15:06
Образцов в пакете: 0; IOC: 11

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

Что делает

RatonRAT — семейство вредоносного программного обеспечения, классифицируемое как удалённый троян (RAT) с ботнет-функциональностью, ориентированное на платформу Windows. В каталоге Malpedia семейство зарегистрировано под идентификатором win.raton_rat, что подтверждает целевую ОС и класс угрозы. По данным ThreatFox, актуальная инфраструктура семейства используется в роли botnet C&C — серверов командного управления ботнетом.

Управляющая инфраструктура RatonRAT строится на прямых IP-соединениях: все зафиксированные индикаторы имеют тип ip:port, без обязательного использования доменных имён. Заражённый хост устанавливает сессию непосредственно на IP-адрес и порт C2-сервера, минуя DNS-разрешение. Такой подход упрощает развёртывание инфраструктуры для оператора и одновременно затрудняет блокировку на уровне DNS-фильтрации. Транспортный протокол (TCP или UDP) на уровне имеющихся метаданных не специфицирован.

Конкретный набор функциональных модулей (перехват экрана, файловый менеджер, загрузка дополнительных payload, кейлоггер и т. п.), язык реализации, применяемый packer или протектор, а также механизмы закрепления в системе на текущий момент не подтверждены доступными образцами или curated-профилем. Семейство находится в активной фазе: за недавний период зафиксировано 11 C2-индикаторов, что указывает на работающую и обновляемую инфраструктуру.

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

В текущем пакете доказательств технические образцы отсутствуют (0 samples). Ни одного файла, скрипта или бинарного артефакта для построчного разбора не предоставлено. Все доступные сведения ограничены метаданными IOC из ThreatFox (11 записей типа ip:port, категория botnet_cc, тег RatonRAT) и справочной записью Malpedia.

В связи с этим разбор конкретных артефактов — формата файла, архитектуры, сигнатур, YARA-совпадений, vendor-вердиктов, способов доставки — не приводится. При появлении образцов в публичных репозиториях или песочницах данный раздел будет дополнен поэлементным анализом с отдельными подблоками для каждого sample.

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

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

Для семейства RAT/ботнет-класса в целом типичны следующие векторы начального доступа, однако их применимость именно к RatonRAT без sample-level подтверждения остаётся гипотезой: фишинговые вложения и ссылки, эксплуатация уязвимостей в публичных сервисах, загрузка через дропперы или другие вредоносные семейства, компрометация удалённого доступа (RDP, VNC). До появления конкретных образцов или отчётов с разбором цепочки заражения эти каналы следует рассматривать как потенциальные, а не подтверждённые.

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

1. Сетевой мониторинг исходящих соединений. Ключевой индикатор RatonRAT — прямые сессии на нестандартные порты внешних IP-адресов без предшествующего DNS-запроса. В SIEM/EDR стоит настроить алерты на исходящие соединения к IP, не входящим в белые списки корпоративных сервисов, особенно на портах, не характерных для легитимного трафика.
   
2. Корреляция с базами IOC. Регулярная сверка журналов прокси, файрвола и NetFlow с актуальными списками ThreatFox по тегу RatonRAT. Поскольку инфраструктура ротируется, автоматическая подписка на фиды критична для своевременной блокировки новых адресов.
   
3. Анализ процессов и их сетевой активности. В EDR-телеметрии обращать внимание на процессы, инициирующие длительные исходящие соединения без привязки к известным приложениям. Подозрительно, если процесс создан из временных каталогов (%TEMP%, %APPDATA%) и при этом устанавливает raw-socket-соединение.
   
4. Отсутствие DNS-обращения перед соединением. Легитимные приложения почти всегда выполняют DNS-lookup. Соединение сразу на IP-адрес, зафиксированное в логах DNS-сервера как «запрос не поступал», но присутствующее в NetFlow, — поведенческий маркер, характерный для данного семейства.
   
5. Проверка YARA-репозиториев Malpedia. При появлении бинарных образцов применять правила из Malpedia (win.raton_rat). На текущий момент публичные YARA-правила в пакете evidence не зафиксированы, однако их наличие в репозитории следует проверять при обновлении сигнатурной базы.
   
6. Мониторинг автозагрузки и планировщика. Для RAT-класса стандартно создание записей в Run/RunOnce, службах Windows или заданиях планировщика. Аудит этих точек через Sysmon (Event ID 12, 13, 14) или Autoruns позволяет выявить закрепление даже без знания конкретного имени файла.
   
7. Выявление beacon-паттернов. Ботнет-агенты часто используют периодические короткие сессии через фиксированные интервалы. Обнаружение регулярных исходящих пакетов одинакового размера на один и тот же внешний IP — дополнительный сигнал для расследования.
   

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

1. Изоляция хоста. Немедленно отключить заражённую машину от сети (физически или через порт на коммутаторе), чтобы прервать сессию с C2 и предотвратить возможное боковое перемещение. Не выключать питание — это уничтожит волатильную память.
   
2. Сохранение телеметрии. Зафиксировать дамп оперативной памяти, текущие сетевые соединения, список процессов, содержимое автозагрузки и планировщика. Собрать логи EDR, Sysmon, Windows Event Log за период предполагаемой активности.
   
3. Оценка компрометации учётных данных. RatonRAT как RAT-семейство потенциально предоставляет оператору интерактивный доступ к сессии. Необходимо предположить, что все учётные данные, вводившиеся на хосте (пароли, токены, сессии браузеров), могли быть скомпрометированы. Инициировать ротацию паролей и отзыв токенов для всех сервисов, к которым обращались с данной машины.
   
4. Проверка закрепления и вторичной нагрузки. Просканировать хост на предмет дополнительных payload, загруженных через C2-канал: новые исполняемые файлы во временных каталогах, неизвестные службы, модифицированные ярлыки. Удалить подтверждённые артефакты.
   
5. Анализ бокового перемещения. Проверить журналы аутентификации (Event ID 4624, 4625, 4672) на предмет использования учётных записей скомпрометированного хоста для доступа к другим машинам и серверам в сети.
   
6. Блокировка C2-инфраструктуры на периметре. Внести выявленные IP-адреса и порты в правила блокировки файрвола/IPS. Обновить подписки на фиды ThreatFox для получения новых индикаторов семейства.
   
7. Принятие решения о восстановлении. Если целостность ОС не может быть подтверждена (обнаружены rootkit-компоненты, модификация системных бинарных файлов, неизвестные драйверы), наиболее надёжный вариант — полная переустановка Windows с доверенного образа. Если артефакты ограничены пользовательским уровнем, допустима точечная очистка с последующим усиленным мониторингом в течение 14–30 дней.
   
8. Документирование и эскалация. Зафиксировать инцидент во внутренней системе учёта, передать телеметрию в SOC/DFIR-команду для ретроспективного поиска по другим хостам.
   

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

1. Контроль исходящих соединений на периметре. Настроить файрвол в режиме default-deny для исходящего трафика: разрешать только известные порты и направления. Это напрямую противодействует модели C2 через raw IP:port, используемой RatonRAT.
   
2. Подписка на актуальные IOC-фиды. Интегрировать ThreatFox и аналогичные источники индикаторов в SIEM/IPS для автоматической блокировки новых C2-адресов семейства. Учитывая активную ротацию инфраструктуры, обновление должно быть не реже раза в сутки.
   
3. Сегментация сети и ограничение горизонтального доступа. Минимизировать количество хостов, доступных с рабочей станции по RDP/SMB/WinRM. В случае компрометации одного узла это ограничивает возможности оператора ботнета по перемещению.
   
4. Запрет исполнения из пользовательских каталогов. Политики AppLocker или WDAC, блокирующие запуск исполняемых файлов из %TEMP%, %APPDATA%, %LOCALAPPDATA% и каталогов загрузок, снижают вероятность успешного закрепления типичных RAT-дропперов.
   
5. Мониторинг DNS-аномалий. Внедрить логирование и алертинг на исходящие соединения без предшествующего DNS-запроса. Для RatonRAT с его IP-адресной моделью C2 это один из наиболее специфичных сетевых маркеров.
   
6. Регулярный аудит точек автозагрузки. Автоматизированная проверка Run/RunOnce, служб, заданий планировщика и WMI-подписок на рабочих станциях и серверах. Изменения в этих точках без соответствующего change-request — повод для расследования.
   
7. Контроль вложений и ссылок. Поскольку конкретный вектор доставки RatonRAT не подтверждён, базовая гигиена — не открывать вложения и ссылки из непрошенных писем, не запускать исполняемые файлы из ненадёжных источников — остаётся универсальной мерой против RAT-семейств.
   

Источники​

1. ThreatFox — IOC RatonRAT
   
2. Malpedia — RatonRAT
   

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

• 26.08.2026 — Опубликована первая версия материала.