Группировка PCPJack, по данным исследователей компании Hunt.io, скомпрометировала около 230 облачных серверов на платформах Amazon Web Services, Google Cloud и Microsoft Azure, превратив их в скрытую сеть SMTP-прокси для ретрансляции электронной почты. Скомпрометированные бизнес-серверы в США, Европе и Азии, как сообщается, были тихо переоборудованы в SMTP-ретрансляторы, а списки верифицированных прокси синхронизировались с внешним сервером каждые пять минут. Организациям, использующим облачную инфраструктуру на базе Linux, следует проверить свои серверы на наличие индикаторов компрометации, описанных ниже.
Как была обнаружена инфраструктура
Операция была раскрыта после того, как злоумышленник оставил два открытых каталога на командном сервере (213.136.80[.]73) без какой-либо аутентификации. Внутри исследователи обнаружили исходный код, скомпилированные бинарные файлы, журналы развёртывания, сканеры, эксплуатационный инструментарий и активную конфигурацию фреймворка Sliver. По словам Hunt.io, инфраструктура продолжала функционировать на момент обнаружения.
Техническая архитектура атаки
Инструментарий развёртывания
В открытых каталогах находился набор инструментов для развёртывания SMTP-прокси, интегрированный со Sliver — фреймворком для управления скомпрометированными системами. Помимо этого, были обнаружены бинарные файлы Chisel для туннелирования и проксирования, собранные под основные архитектуры Linux: AMD64, ARM64 и x86. На стороне жертвы бинарный файл размещался как скрытый файл с точкой в начале имени и закреплялся по пути /var/tmp/.xs.
Управление маяками и маршрутизация
Скрипты развёртывания загружали конфигурацию клиента Sliver C2 и отфильтровывали маяки (beacons) на Linux-системах, которые отметились в течение последних десяти минут. Каждый маяк получал порт SOCKS5-прокси, детерминированно вычисляемый из MD5-хеша его Sliver UUID и отображаемый в диапазон 10000–14999. Такой подход гарантировал, что один и тот же маяк всегда получает один и тот же порт, устраняя необходимость в централизованном реестре портов.
Маяки обрабатывались пакетами по 50 штук с паузой в 25 минут после загрузки файлов и 15 минут после отправки команд на выполнение — это компенсировало задержки при обратной связи маяков с медленным интервалом.
Контроль качества SMTP-ретрансляции
Ключевым элементом конвейера служил «шлюз качества» SMTP — скрипт проверял возможность исходящего подключения к smtp.gmail[.]com:587. Хосты, не прошедшие проверку, пропускались. Как отметили исследователи, это определяло саму цель операции: хосты, неспособные ретранслировать почту, не представляли ценности для этого конвейера.
Примечательно, что в последующих версиях скриптов SMTP-шлюз и логика пакетной обработки были удалены, что может свидетельствовать об эволюции тактики или расширении целей операции.
Верификация и обогащение данных
На командном сервере работал Python-демон chisel_verifier.py, который каждые 60 секунд перечислял активные туннельные порты Chisel через команду ss -tlnp, тестировал каждый новый порт на SMTP-совместимость и удалял из пула нерабочие или потерянные туннели.
Верифицированные прокси обогащались метаданными — IP-адрес выхода, страна и ASN — через сервисы api.ipify[.]org и ip-api[.]com. Готовые списки прокси синхронизировались каждые пять минут по протоколу SCP на отдельный сервер (38.242.204[.]245), который на момент публикации отчёта был недоступен.
Диагностический скрипт выбирал пять активных маяков и проверял на каждом из них:
- Наличие бинарных файлов Chisel по известным путям
- Запущенный процесс Chisel
- Свободное дисковое пространство
- Доступность порта 9000 на C2-сервере
- Наличие артефактов закрепления — записи cron или службы systemd
Контекст угрозы и атрибуция
Hunt.io охарактеризовала кампанию как оппортунистическую. Результат в 230 узлов — это наблюдаемый итог операции, однако исследователи отмечают, что по восстановленным файлам невозможно определить, действует ли один оператор, итеративно совершенствующий инструменты, или несколько субъектов, разделяющих общую инфраструктуру.
Конечная цель операции остаётся неясной. Однако, как подчеркнули исследователи, верифицированный список прокси синхронизировался каждые пять минут с внешним сервером, и кто-то его потреблял — будь то для спама, фишинга или иных целей, инфраструктура для массовой доставки email была полностью функциональна.
Важно учитывать: атрибуция активности группировке PCPJack основана на данных единственного исследовательского источника и не подтверждена независимо. Облачные провайдеры не выпускали официальных уведомлений по данному инциденту.
Оценка воздействия
Наибольшему риску подвержены организации, эксплуатирующие Linux-серверы в облачных средах AWS, Google Cloud и Azure, особенно с недостаточно защищённым исходящим SMTP-трафиком. Скомпрометированные серверы использовались для ретрансляции почты от имени легитимных бизнес-доменов, что потенциально подрывает репутацию отправителя, приводит к попаданию в чёрные списки и создаёт юридические риски для владельцев инфраструктуры.
Практические рекомендации
- Проверьте наличие артефактов: выполните поиск скрытого файла по пути
/var/tmp/.xsна всех Linux-серверах в облачной инфраструктуре - Проверьте механизмы закрепления: проанализируйте записи crontab и службы systemd на наличие неизвестных задач
- Аудит исходящих SMTP-соединений: заблокируйте или ограничьте исходящий трафик на порт 587 для серверов, которым не требуется отправка почты
- Мониторинг сетевых соединений: проверьте наличие подключений к IP-адресам
213.136.80[.]73и38.242.204[.]245в журналах сетевого оборудования - Обнаружение туннелей: выявите процессы Chisel и необычные SOCKS5-прокси в диапазоне портов 10000–14999 командой
ss -tlnp - Ограничьте поверхность атаки: убедитесь, что серверы не имеют открытых каталогов и что доступ к управляющим интерфейсам защищён аутентификацией
Обнаруженная Hunt.io операция демонстрирует конкретную модель монетизации облачных компрометаций — превращение захваченных серверов в инфраструктуру доставки email, пригодную для спама или фишинга в промышленных масштабах. Приоритетное действие для команд безопасности — немедленная проверка Linux-серверов в облаке на наличие файла /var/tmp/.xs, неавторизованных процессов Chisel и аномального исходящего SMTP-трафика на порт 587, а также блокировка указанных IP-адресов на уровне сетевых правил.
