Группировка PCPJack скомпрометировала 230 серверов в AWS, Google Cloud и Microsoft Azure и собрала из них скрытую SMTP-сеть для пересылки почты. Для русскоязычных команд, которые держат продовые сервисы в публичных облаках, история неприятная по простой причине: злоумышленникам уже мало просто закрепиться на машине, теперь им нужен стабильный конвейер, который быстро проверяет, может ли узел отправлять письма наружу, и сразу включает его в рабочую схему.
Об этом сообщает The Hacker News со ссылкой на Hunt.io. Исследователи нашли на управляющем сервере с адресом 213.136.80[.]73 два открытых каталога без какой-либо аутентификации. Внутри лежали исходники, собранные бинарники, логи развертывания, сканеры, инструменты эксплуатации и живая конфигурация Sliver. Иначе говоря, не просто следы кампании, а почти готовая инструкция по тому, как эта скрытая SMTP-сеть собиралась и поддерживалась в рабочем состоянии.
Схема была довольно приземленной и потому опасной. На стороне жертвы бинарник маскировали под скрытый файл и закрепляли как /var/tmp/.xs. Дальше задействовались Sliver, туннелирование через Chisel и набор прокси-бинарников под разные Linux-архитектуры, включая AMD64, ARM64 и x86. Скрипты отбирали Linux-beacon'ы, которые выходили на связь за последние десять минут, и назначали каждому SOCKS5-порт. Порт вычислялся детерминированно из MD5-хеша UUID конкретного beacon'а и укладывался в диапазон 10000-14999. Практический смысл очевиден: оператору не нужен отдельный реестр портов, и один и тот же узел получает один и тот же порт при каждом запуске.
Ключевая деталь всей операции не в самих туннелях, а в фильтре полезности. Hunt.io пишет, что деплойер запускал проверку доступности smtp.gmail[.]com:587. Если хост не мог выйти на этот адрес и порт, его просто отбрасывали с нулевым кодом завершения, без дальнейшей возни. Для атакующих это был не взлом ради взлома, а отбор инфраструктуры под конкретную задачу. Узлы, не способные работать как почтовый ретранслятор, им были не нужны. Скрипты обрабатывали beacon'ы пачками по 50, с паузой в 25 минут после загрузки и еще в 15 минут после выполнения команд, чтобы дождаться машин с редкими check-in. В более поздних версиях логика стала еще жестче: из скриптов убрали и SMTP-гейт, и пакетную обработку, что похоже на попытку ускорить цикл разворачивания.
Отдельно показателен уровень автоматизации. На C2-сервере крутился фоновый Python-скрипт chisel_verifier.py, который каждые 60 секунд перечислял активные туннели через ss -tlnp, проверял новые порты на SMTP-функциональность и вычищал из пула мертвые или нерабочие каналы. Рабочие прокси обогащались метаданными: внешний IP, страна и ASN подтягивались через api.ipify[.]org и ip-api[.]com. После этого списки синхронизировались каждые пять минут по SCP на отдельный downstream-сервер 38.242.204[.]245. На момент анализа он уже был недоступен, но сам процесс выглядел как вполне зрелый сервис снабжения: компрометация, проверка, каталогизация, выдача потребителю.
PCPJack впервые засветился только в апреле 2026 года, когда SentinelOne описала фреймворк для кражи учетных данных из облачных сервисов. Тогда же исследователи обратили внимание на интересную особенность: вредоносный набор PCPJack пытался завершать процессы и убирать артефакты, связанные с TeamPCP, другой заметной группой, фигурировавшей в атаках на цепочки поставок ПО. Из нынешнего отчета Hunt.io не следует, что между ними есть прямая организационная связь, но контекст важен: вокруг облачной инфраструктуры уже идет не только охота за доступами, но и борьба за то, кто именно будет использовать скомпрометированный сервер. Для владельца инстанса разницы немного. Если машина уже захвачена, она может стать и точкой кражи секретов, и промежуточным узлом для почтовых кампаний.
Что это значит для разработчиков и бизнеса на практике? Во-первых, облачный сервер теперь надо оценивать не только как риск утечки данных, но и как риск «тихого сервиса» для чужих операций. Если инстанс внезапно может ходить наружу на SMTP-порты, держит странные SOCKS5-слушатели в диапазоне 10000-14999, тащит в /var/tmp скрытые бинарники или поднимает нетипичные cron/systemd-артефакты, это уже не «подозрительная мелочь», а повод разбирать хост по косточкам. Во-вторых, злоумышленники явно ставят на Linux-окружения в облаках и рассчитывают на то, что редкие beacon check-in, временные файлы и сетевые туннели растворятся в обычном шуме эксплуатации. Для SRE, DevOps и security-команд вывод неприятный, но полезный: мониторинг egress-трафика, контроль неожиданных SMTP-соединений и инвентаризация persistence-механизмов на хостах становятся базовой гигиеной, а не опцией для параноиков.
Сам Hunt.io прямо пишет, что конечная цель кампании пока неясна: это мог быть спам, фишинг или любая другая массовая почтовая активность. Но главное здесь даже не сценарий монетизации. Гораздо важнее, что облачные компрометации все чаще превращаются в модульные конвейеры, где зараженный сервер оценивают по его прикладной ценности для следующего этапа. Если этот подход закрепится, облачная безопасность придется перестраивать вокруг вопроса не только «кто вошел», но и «для какой функции этот хост уже перепрофилировали».