Обзор и происхождение
GCleaner — семейство вредоносного ПО для Windows, сочетающее функции загрузчика и ботнета: первичная задача — закрепиться на узле, получить конфигурацию и команды с управляющего сервера и доставить вторичную нагрузку. Семейство имеет запись в каталоге Malpedia (win.gcleaner), а индикаторы и образцы продолжают появляться в MalwareBazaar и ThreatFox, что указывает на текущую активность, а не исторический артефакт.
Название обыгрывает легитимные «чистильщики» и оптимизаторы браузеров: жертве предлагается якобы полезная утилита, внутри которой находится загрузчик. Исторические описания семейства упоминают несколько реализаций (в том числе на PureBasic, C++ и .NET) и каналы распространения через вредоносную рекламу, поддельные страницы установки популярного ПО и фишинговые письма с архивами. Целевая среда — пользовательские и корпоративные рабочие станции Windows; для корпоративного сектора опасность определяется вторичной нагрузкой: кража cookie-сессий и учётных данных позволяет обходить MFA через перехват уже установленных сессий и служит точкой входа для дальнейшего перемещения по инфраструктуре.
Функциональные модули
- Загрузчик (loader): первичный PE-файл, помечаемый тегом Loader; получает и запускает вторичную нагрузку с сервера управления.
- C2-коммуникация: обмен с управляющим сервером по сетевым протоколам (в IOC-базах фиксируются пары ip:port категории botnet_cc); точный протокол требует анализа образцов.
- Доставка вторичной нагрузки: по наблюдениям за классом, GCleaner используется как трамплин для кражи данных браузеров и сессий; конкретный состав нагрузки в открытых источниках по свежим образцам не подтверждён.
- Закрепление: для загрузчиков этого класса типично создание задач планировщика или записей автозапуска; для свежих образцов механизм закрепления не подтверждён и требует динамического анализа.
Техники и API
Подтверждённый на семейном уровне минимум: 64-битные PE-исполняемые файлы и сетевое взаимодействие с C2. WinHTTP/WinINet — типовой стек для загрузчиков этого класса, но для конкретных билдов требует проверки; запуск вторичного кода через CreateProcess или инъекцию (Process Hollowing) следует рассматривать как вероятные, но не подтверждённые техники. Для билдов на .NET характерна работа с System.Net и загрузка сборок через Assembly.Load; для PureBasic/C++ — прямые вызовы Windows API. Перечисленные API — гипотезы для охоты, а не установленные факты: статический разбор свежих образцов в рамках текущих данных не выполнялся.
IOC и индикаторы
ThreatFox содержит 11 записей для GCleaner: типы — ip:port (категория botnet_cc, адреса управляющих серверов) и хэши md5/sha1/sha256 (категория payload, сами образцы). Теги: GCleaner, Loader, exe. MalwareBazaar показывает свежий образец с подписью GCleaner; тип файла и метод доставки в метаданных не указаны. Конкретные значения индикаторов в тексте не публикуются — карточки образцов и ссылки на источники добавляются рендерером ниже. Корреляцию адресов C2 с логами прокси/DNS стоит выполнять по этим записям напрямую в ThreatFox.
Обнаружение
- Сетевое: сопоставление исходящих соединений с актуальными ip:port из ThreatFox (botnet_cc); аномальные соединения из процессов «утилит очистки».
- Процессное: запуск исполняемых файлов из пользовательских каталогов (Downloads, Temp, AppData), нетипичные родительские процессы (архиваторы, браузеры, установщики).
- Файловое: YARA-детектирование по семейным правилам GCleaner; побайтовые сигнатуры малоэффективны из-за разнородности реализаций (PureBasic/C++/.NET).
- Поведенческое в EDR: создание закрепления сразу после запуска «утилиты», последующая загрузка и исполнение второй ступени, доступ к хранилищам браузеров.
Защита и снижение риска
- Блокировать запуск исполняемых файлов из пользовательских каталогов политиками AppLocker/WDAC.
- Ограничить установку ПО без прав администратора; применять allowlist вместо свободной установки «оптимизаторов».
- Фильтрация почтовых вложений-архивов и блокировка вредоносной рекламы на периметре.
- EDR-политики на инъекции и запуск неподписанных вторичных ступеней.
- Сокращение срока жизни cookie/токенов сессий и привязка сессий к устройству — снижает ущерб от кражи сессий вторичной нагрузкой.
- Сегментация рабочих станций и мониторинг исходящих соединений к неизвестным ip:port.
Что делать при подозрении на заражение
- Изолировать узел от сети, сохранив телеметрию EDR (процессы, сеть, файлы).
- Зафиксировать активные соединения и сопоставить их с актуальными IOC GCleaner (ip:port из ThreatFox).
- Проверить закрепление: задачи планировщика, Run-ключи, службы, автозагрузка.
- Оценить использование учётных данных: сброс паролей и отзыв сессий/токенов браузеров, доступных с узла; исходить из возможности обхода MFA через украденные cookie.
- Определить вторичную нагрузку и границы перемещения по журналам аутентификации и EDR.
- Удалить подтверждённые артефакты; если целостность системы установить нельзя — переустановить ОС.
- Провести охоту по IOC во всей инфраструктуре, а не только на исходном узле.
Ограничения текущего анализа
Установлено семейное позиционирование (загрузчик/ботнет, запись в Malpedia), наличие свежих образцов и 11 IOC (хэши payload и ip:port C2). Не подтверждены по свежим образцам: точный протокол C2, механизм закрепления, состав вторичной нагрузки, техники инъекции и используемые API — для этого необходим статический разбор и динамический прогон образцов. Методы доставки в метаданных отсутствуют; предположения о фишинге и malvertising опираются на исторические описания семейства, а не на текущие наблюдения. Разнородность реализаций (PureBasic, C++, .NET) требует семейного, а не побайтового детектирования.
Скачать образцы
Скачать образцы можно здесь:
Просмотр скрытого контента доступен зарегистрированным пользователям!
Источники
История обновлений статьи
- 08.10.2026 — Опубликована первая версия материала.
