Угруповання 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-адрес на рівні мережевих правил.
