CurlBack RAT: Windows-бэкдор с HTTP-каналом управления — технический профиль и детектирование

Семейство: CurlBack RAT
Класс: RAT / средство удалённого управления
Раздел: RAT
Основание публикации: свежие наблюдения не старше 5 дней
Первое наблюдение в текущем наборе: 04.09.2026 20:02
Последнее наблюдение в текущем наборе: 04.09.2026 20:02
Образцов в пакете: 0; IOC: 3

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

Что делает

CurlBack RAT — семейство вредоносного программного обеспечения класса Remote Access Trojan, ориентированное на платформу Windows и зарегистрированное в энциклопедии Malpedia под идентификатором win.curlback. Название семейства указывает на вероятное использование HTTP-клиентской функциональности (библиотеки для формирования HTTP-запросов, совместимые с libcurl, или штатные средства Windows) для организации канала связи с управляющим сервером. Подобный подход характерен для RAT, стремящихся маскировать C2-трафик под легитимные веб-запросы.

Как RAT, семейство предполагает предоставление оператору удалённого контроля над заражённым хостом: выполнение произвольных команд, загрузка и выгрузка файлов, сбор системной информации. Конкретный набор модулей (перехват ввода, захват экрана, работа с браузерами, манипуляции с файловой системой) для текущих образцов не подтверждён доступными evidence, поэтому перечислять их как реализованные функции без оговорок некорректно.

По данным ThreatFox, свежие записи классифицированы как payload — то есть речь идёт о непосредственно исполняемой нагрузке, а не о дроппере или документе-приманке. Обнаруженные артефакты представляют собой финальную стадию цепочки заражения, способную сразу устанавливать сессию с C2.

Антианалитические техники, конкретные методы закрепления и целевые приложения для CurlBack RAT в открытых источниках на текущий момент детально не раскрыты. Развёрнутое содержимое страницы Malpedia в данном пакете evidence не передано, поэтому атрибуция конкретных API или техник невозможна.

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

В текущем пакете evidence технические образцы (technical_samples) отсутствуют. Три записи в ThreatFox представлены исключительно хэш-идентификаторами полезной нагрузки без сопроводительных метаданных: без данных об архитектуре, размере, формате файла, способе доставки, YARA-совпадениях или вердиктах антивирусных движков.

Индивидуальный разбор по образцам не приводится. Доступные наблюдения на уровне IOC-записей:

• Все три записи имеют тип IOC «sha256_hash» и категорию «payload», что указывает на исполняемые тела вредоноса, а не на сетевые индикаторы или хэши документов-приманок.
  
• Записи поступили из одного источника (ThreatFox), без перекрёстной верификации через YARA-правила или vendor intelligence в рамках данного пакета.
  
• Malpedia содержит страницу семейства (win.curlback), однако развёрнутое описание с этой страницы в текущем evidence отсутствует.
  

При появлении образцов с file_information, тегами или результатами песочницы данный раздел будет дополнен поформатным разбором.

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

Для текущих трёх IOC-записей способ доставки не указан. Нет подтверждений того, распространяется ли CurlBack RAT через фишинговые вложения, эксплойт-киты, вредоносные обновления, supply-chain-компрометацию или иной вектор.

На уровне семейства, исходя из классификации как RAT-payload, типичными каналами для аналогичных Windows-бэкдоров являются: целевой фишинг с вложенным исполняемым файлом или архивом, загрузка второй стадии через компрометированный легитимный процесс, доставка через другие вредоносные семейства-лоадеры. Привязывать какой-либо из этих каналов именно к CurlBack RAT без подтверждающих данных нельзя.

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

При отсутствии детальных sandbox-отчётов детектирование строится на эвристических и поведенческих признаках, характерных для HTTP-based RAT на Windows:

1. Сетевой мониторинг. Обращайте внимание на исходящие HTTP/HTTPS-запросы от нестандартных процессов, особенно если тело запроса содержит закодированные данные (Base64, XOR) или заголовки User-Agent не соответствуют заявленному клиенту. Для RAT, использующих HTTP-библиотеки, характерны запросы с минимальным набором заголовков или нестандартным порядком полей.
   
2. EDR / Sysmon. Фиксируйте создание процессов, инициирующих сетевые соединения сразу после запуска без предварительного взаимодействия с пользователем. Обращайте внимание на дочерние процессы, порождённые из временных каталогов (%TEMP%, %APPDATA%\Local\Temp) или из каталогов загрузок.
   
3. Импорт библиотек. При статическом анализе подозрительных PE-файлов ищите ссылки на winhttp.dll, wininet.dll, urlmon.dll или сторонние HTTP-библиотеки в сочетании с API для создания процессов (CreateProcessA/W, ShellExecuteEx) и работы с реестром (RegSetValueEx). Само по себе наличие этих импортов не является признаком вредоносности, но в комбинации с отсутствием цифровой подписи и нестандартным путём запуска повышает подозрительность.
   
4. YARA / сигнатуры. Публичные YARA-правила для CurlBack RAT в данном пакете не представлены. При появлении правил в Malpedia или репозиториях сообщества их следует включить в пайплайн сканирования.
   
5. Поведение в песочнице. Если образец попадает в sandbox, ожидайте попытку установки исходящего соединения в первые секунды исполнения, возможную проверку окружения (запросы к WMI, перечисление процессов, проверка имени пользователя или домена) перед активацией основной логики.
   
6. Контроль хэш-индикаторов. Известные хэши payload-артефактов (доступны в ThreatFox) следует загрузить в SIEM/EDR-блэклисты для ретроспективного поиска по журналу запусков процессов.
   
7. Аномалии DNS. Для RAT с HTTP-каналом характерно разрешение одного или небольшого числа доменов, не связанных с легитимной активностью пользователя. Мониторинг новых DNS-запросов от ранее не наблюдавшихся процессов помогает выявить такую активность.
   

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

Поскольку CurlBack RAT относится к классу удалённого управления, при подтверждении компрометации необходимо исходить из того, что злоумышленник мог получить интерактивный доступ к хосту:

1. Изоляция. Немедленно отключите заражённый хост от сети (физически или через порт-секьюрити на коммутаторе). Не выключайте питание — это уничтожит волатильную память и активные сетевые сессии.
   
2. Сохранение телеметрии. Зафиксируйте дамп оперативной памяти, список активных процессов с сетевыми соединениями, содержимое временных каталогов и автозагрузки до начала очистных действий.
   
3. Оценка периметра учётных данных. Если хост использовался для аутентификации в корпоративных сервисах, исходите из компрометации всех сессий и паролей, вводившихся на данной машине. Инициируйте принудительную ротацию секретов для затронутых учётных записей.
   
4. Проверка закрепления и бокового перемещения. Просканируйте реестр (Run, RunOnce, Services, Scheduled Tasks), каталоги автозагрузки и WMI-подписки на предмет посторонних записей. Проверьте журналы аутентификации (Event ID 4624/4625) на предмет использования учётных данных скомпрометированного хоста для доступа к другим системам.
   
5. Поиск вторичной нагрузки. RAT часто используется как платформа для доставки дополнительных модулей. Проверьте наличие недавно созданных исполняемых файлов, DLL или скриптов в пользовательских и системных каталогах, не соответствующих известному ПО.
   
6. Удаление артефактов или переустановка. Если целостность системы не может быть подтверждена (обнаружены руткит-механизмы, модификация системных DLL, неизвестные службы), предпочтительна полная переустановка ОС из доверенного образа. В противном случае удалите подтверждённые файлы, ключи реестра и запланированные задачи, после чего проведите повторное полное сканирование.
   
7. Критерий возврата. Хост возвращается в сеть только после: подтверждения отсутствия известных хэш-индикаторов, отсутствия аномальных исходящих соединений в течение минимум 48 часов мониторинга, успешной ротации всех локальных и доменных секретов, которые могли быть доступны на данной машине.
   

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

1. Контроль исходящего трафика. Ограничьте исходящие HTTP/HTTPS-соединения на периметре списком разрешённых категорий и доменов. Для рабочих станций, не требующих прямого доступа в интернет, используйте прокси с инспекцией. Это снижает ценность HTTP-канала RAT.
   
2. Политика запуска исполняемых файлов. Применяйте AppLocker или WDAC для запрета запуска PE-файлов из пользовательских каталогов (%TEMP%, %APPDATA%, Downloads). Большинство RAT-payload не имеют валидной цифровой подписи и не требуют привилегий для первичного запуска.
   
3. Мониторинг IOC из открытых баз. Регулярно импортируйте хэш-индикаторы из ThreatFox и аналогичных источников в EDR/SIEM для ретроспективного и превентивного блокирования.
   
4. Сегментация и минимальные привилегии. Ограничьте права локальных пользователей до стандартных (без администратора). Сегментируйте сеть так, чтобы компрометация одной рабочей станции не давала прямого доступа к файловым серверам и контроллерам домена.
   
5. Обучение по фишингу. Если вектор доставки будет подтверждён как фишинговый, усильте фильтрацию вложений на почтовом шлюзе (блокировка исполняемых файлов, архивов с паролем) и проводите регулярные тренировки для пользователей.
   
6. Обновление детектов при появлении новых данных. Следите за обновлениями Malpedia (win.curlback) и YARA-репозиториев: при публикации правил или sandbox-отчётов оперативно включайте их в пайплайн обнаружения.
   

Источники​

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

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

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