SystemBC: Windows-ботнет с SOCKS5-проксированием и удалённым управлением — технический профиль

Семейство: SystemBC
Класс: ботнет-вредонос
Раздел: Ботнеты
Основание публикации: свежие наблюдения не старше 5 дней
Первое наблюдение в текущем наборе: 24.08.2026 03:45
Последнее наблюдение в текущем наборе: 24.08.2026 03:45
Образцов в пакете: 1; IOC: 1

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

Что делает

SystemBC — семейство вредоносного ПО для Windows, функционирующее как ботнет-клиент с возможностями удалённого управления и проксирования сетевого трафика. Основная роль заражённого хоста в инфраструктуре SystemBC — предоставление оператору SOCKS5-прокси-туннеля, через который маршрутизируется произвольный TCP-трафик. Это позволяет скрывать реальный источник атак, обходить сетевые ограничения и использовать скомпрометированную машину как транзитный узел.

Типичный функциональный набор семейства включает:

• SOCKS5-прокси: перенаправление входящих TCP-соединений через заражённый хост; оператор получает возможность анонимизировать трафик последующих этапов атаки.
  
• Удалённое управление: выполнение команд, запуск процессов, работа с файловой системой (чтение, запись, удаление, перечисление каталогов).
  
• Сбор информации о системе: имя хоста, версия ОС, права текущего пользователя, список процессов и сетевых интерфейсов.
  
• Загрузка и исполнение дополнительных модулей: SystemBC нередко выступает как промежуточный этап перед развёртыванием более специализированной нагрузки (стилеры, шифровальщики, RAT).
  

Связь с управляющим сервером осуществляется по TCP, как правило, на нестандартных портах. Протокол обмена проприетарный; в ряде версий применяется простое XOR- или RC4-шифрование канала. Закрепление обычно реализуется через ключи автозагрузки реестра Windows или планировщик задач, хотя конкретный механизм зависит от варианта и способа доставки.

Семейство активно с конца 2010-х годов и неоднократно наблюдалось в кампаниях наряду с другими ботнетами и лоадерами. В базе Malpedia оно классифицируется как win.systembc.

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

Образец 1

Единственный доступный в текущем пакете образец зарегистрирован с сигнатурой «SystemBC». Metadata крайне скудна:

• Формат файла, MIME-тип, архитектура и размер не указаны в записи.
  
• Способ доставки (delivery_method) отсутствует.
  
• Теги, YARA-правила, vendor intelligence и дополнительные поля file_information пусты.
  
• Intelligence-блок не содержит сведений о связанных кампаниях или акторах.
  
• Временная метка первого наблюдения относится к августу 2026 года; данных о повторных наблюдениях нет.
  

Из сводки IOC известно, что для данного образца зафиксирована одна запись типа «ip:port» с категорией активности botnet_cc — то есть адрес управляющего сервера ботнета. Это подтверждает, что образец действительно устанавливает соединение с C2-инфраструктурой SystemBC и функционирует как клиент ботнета.

Наблюдения:

1. Сигнатура «SystemBC» присвоена на уровне MalwareBazaar, что указывает на автоматическое или ручное распознавание принадлежности к семейству, однако без дополнительных YARA-совпадений или vendor-вердиктов механизм детектирования остаётся непрозрачным.
   
2. Отсутствие данных об архитектуре и формате не позволяет утверждать, является ли образец PE-исполняемым файлом, DLL, скриптом-обёрткой или документом с макросом. Для SystemBC исторически характерны 32- и 64-битные PE-файлы, но для данного конкретного образца это не подтверждено.
   
3. Единственный IOC-тип (ip:port, botnet_cc) согласуется с ожидаемой моделью поведения: клиент устанавливает исходящее TCP-соединение с фиксированным адресом и портом C2.
   
4. Отсутствие тегов и delivery_method означает, что вектор первоначального заражения для этого экземпляра не задокументирован.
   
5. Связь с записью в Malpedia (win.systembc) подтверждена на уровне ThreatFox, однако сама страница не содержит дополнительных поведенческих деталей, применимых к данному образцу.
   

В сравнении с другими образцами пакета: иных образцов нет, поэтому дифференциальный анализ не применим.

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

Для текущего образца способ доставки не указан в metadata. Конкретный вектор заражения подтвердить невозможно.

На уровне семейства SystemBC исторически наблюдался в следующих каналах (общесемейные сведения, не привязанные к данному образцу):

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

Без дополнительных тегов или source-данных для рассматриваемого образца нельзя утверждать, какой из перечисленных каналов был использован.

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

1. Сетевой мониторинг: исходящие TCP-соединения на нестандартные порты с длительным временем жизни и периодическим обменом небольшими пакетами (keep-alive / туннелирование). Паттерн SOCKS5-прокси на стороне клиента может проявляться как серия соединений к одному удалённому адресу с последующим перенаправлением трафика.
   
2. EDR / Sysmon: создание процесса, который инициирует исходящее TCP-соединение и при этом не соответствует известному приложению; подозрительные дочерние процессы, запущенные из временных каталогов (%TEMP%, %APPDATA%).
   
3. Реестр и автозагрузка: проверка ключей Run/RunOnce, записей планировщика задач на предмет запуска неизвестных исполняемых файлов из нестандартных путей.
   
4. Поведенческие признаки проксирования: хост начинает ретранслировать трафик между внешними адресами, не характерный для его обычной роли; аномальный объём исходящих соединений к множеству различных назначений через один процесс.
   
5. YARA / сигнатурное детектирование: в текущем пакете YARA-правила не приведены, однако публичные наборы (Malpedia, community-правила) содержат сигнатуры по строкам протокола и характерным API-вызовам (WSAStartup, connect, CreateProcessA/W, WriteFile в сочетании с сетевыми функциями).
   
6. Анализ памяти процесса: при отсутствии файла на диске (fileless-варианты или удаление после запуска) поиск в памяти паттернов SOCKS5-рукопожатия и структур конфигурации C2.
   
7. ThreatFox / IOC-подписка: регулярная сверка сетевых логов с актуальными записями botnet_cc для SystemBC.
   

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

1. Изоляция хоста: немедленно отключить сетевой интерфейс или поместить машину в изолированный VLAN. Учитывая роль SOCKS5-прокси, заражённый хост может использоваться для туннелирования атак на внутреннюю инфраструктуру — изоляция критична.
   
2. Сохранение телеметрии: зафиксировать дамп памяти подозрительного процесса, сетевые сессии (netstat / EDR-логи), снимок реестра и планировщика задач до каких-либо изменений.
   
3. Определение scope: проверить, какие учётные данные были доступны на хосте, какие внутренние ресурсы он мог проксировать. Просмотреть логи аутентификации на предмет использования сессий с данного хоста для бокового перемещения.
   
4. Поиск закрепления: обследовать ключи автозагрузки, службы, планировщик задач, WMI-подписки на предмет персистентности SystemBC или сопутствующей нагрузки.
   
5. Проверка вторичных payload: SystemBC часто предшествует развёртыванию стилеров или шифровальщиков. Убедиться, что на хосте нет дополнительных вредоносных модулей.
   
6. Ротация секретов: если хост имел доступ к учётным данным, токенам, ключам — инициировать их замену. Особенно критично при подтверждённом проксировании трафика.
   
7. Удаление артефактов или переустановка: при подтверждённой целостности образа и полном понимании механизма закрепления допустимо точечное удаление. В противном случае предпочтительна переустановка ОС из доверенного образа.
   
8. Критерий возврата: хост возвращается в продуктивную сеть только после подтверждения отсутствия исходящих соединений на известные C2-порты, чистоты автозагрузки и успешного прохождения EDR-сканирования.
   

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

1. Контроль исходящих соединений: ограничить на периметре и хостовом файрволе исходящий TCP на нестандартные порты; разрешить только необходимые бизнес-процессы. Это напрямую затрудняет установку SOCKS5-туннеля.
   
2. Мониторинг аномального проксирования: внедрить правила в SIEM/EDR, детектирующие процесс, который одновременно принимает и перенаправляет TCP-соединения к множеству внешних адресов.
   
3. Ограничение прав автозагрузки: использовать AppLocker / WDAC для контроля исполняемых файлов в пользовательских каталогах (%TEMP%, %APPDATA%), откуда часто запускаются компоненты SystemBC.
   
4. Своевременное применение IOC-баз: подписка на ThreatFox и аналогичные фиды с автоматической блокировкой записей botnet_cc на уровне NGFW или DNS-фильтрации.
   
5. Сегментация сети: разделение пользовательских и серверных сегментов снижает ценность хоста как транзитного узла для бокового перемещения.
   
6. Обучение и фильтрация почты: поскольку семейство может доставляться через фишинг, актуальны песочницы для вложений и запрет исполняемых файлов в почте.
   
7. Регулярный аудит планировщика и служб: автоматизированная проверка на появление новых записей автозапуска с нестандартными путями.
   

Скачать образцы​

Скачать образцы можно здесь:

Источники​

1. MalwareBazaar — SystemBC
   
2. ThreatFox — IOC SystemBC
   
3. Malpedia — SystemBC
   

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

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