PCPJack — новий фреймворк крадіжки облікових даних, націлений на відкриті хмарні сервіси (Docker, Kubernetes, Redis, MongoDB, RayML, вразливі веб‑застосунки), який не лише масово викрадає доступи до хмарних, контейнерних, розробницьких, офісних і фінансових сервісів, але й цілеспрямовано видаляє артефакти, пов’язані з угрупованням TeamPCP, фактично «виселяючи» конкурентів зі скомпрометованих середовищ; власникам хмарної інфраструктури вже зараз необхідно проінвентаризувати відкриті сервіси, жорстко обмежити доступ до метаданих інстансів і перевірити системи на наявність слідів автоматичних інсталяційних скриптів та інструмента Sliver.

Технічні деталі PCPJack

У опублікованому аналізі описано завершений, модульний набір інструментів, що працює в кілька етапів і орієнтований на хмарну інфраструктуру.

Початковий доступ і підготовка середовища

Атака запускається зі bootstrap shell‑скрипту, який:

• підготовлює середовище виконання та конфігурує хост для подальших завантажень;
• завантажує наступну стадію інструментів (включно з шістьма Python‑скриптами);
• намагається інфікувати й власну інфраструктуру зловмисника (що вказує на риси «черв’яка»);
• виявляє та зупиняє процеси, а також видаляє артефакти, пов’язані з TeamPCP;
• установлює Python, забезпечує механізм постійності;
• запускає оркестраційний Python‑скрипт і потім видаляє сам себе, мінімізуючи сліди.

Цілі для поширення — відкриті та/або неправильно сконфігуровані:

• хмарні сервіси та інстанси;
• середовища Docker і Kubernetes;
• сервіси зберігання даних Redis, MongoDB;
• платформа RayML і вразливі веб‑застосунки.

Оркестрація і використання Common Crawl

Ключова особливість: оркестратор черв’я отримує список цілей не зі власного сканера, а з parquet‑файлів, що завантажуються безпосередньо з публічного датасета Common Crawl. Це дає змогу:

• масштабувати кампанію за рахунок готових масових списків доменів і URL;
• перекласти частину «роботи з обходу» інтернету на легітимний проєкт;
• замаскувати логіку вибору цілей під звичайну роботу з відкритими даними.

Така схема добре узгоджується з технікою T1595 (Active Scanning), але з опорою на зовнішні джерела розвідданих.

Викрадення облікових даних і метрики успіху

Фреймворк системно збирає:

• системну інформацію з жертви;
• облікові дані хмарних, контейнерних, розробницьких, офісних і фінансових сервісів;
• окремі «успішні» події, включно зі спеціальним полем «PCP replaced», що передається на керівний сервер (C2) і відображає, чи вдалося витіснити TeamPCP з цього хоста.

Сама модель поведінки відповідає технікам MITRE ATT&CK T1552 (Unsecured Credentials) і T1555 (Credentials from Password Stores): систематичний обхід джерел секретів у хмарі та контейнерах.

Додатковий скрипт check.sh і Sliver

На інфраструктурі оператора виявлено додатковий shell‑скрипт check.sh, який:

• визначає архітектуру CPU та завантажує відповідний бінарний файл Sliver — відомого багатоплатформеного фреймворку командно‑контрольної інфраструктури, вихідний код якого доступний у репозиторії Sliver на GitHub;
• сканує Instance Metadata Service (IMDS) у хмарі;
• обходить service account’и Kubernetes;
• аналізує середовища Docker у пошуках конфігурацій і токенів.

Мета — вилучення облікових даних і токенів, пов’язаних із:

• Anthropic, OpenAI, Google API;
• Digital Ocean, Grafana Cloud, HashiCorp Vault;
• Discord, OnePassword та іншими сервісами.

Усі знайдені секрети передаються на зовнішній сервер керування та зберігання викрадених даних.

INDICATORS OF COMPROMISE (IOC) у початковому звіті не наведено, тому виявлення наразі спирається на поведінкові ознаки й артефакти (скрипти bootstrap/check.sh, мережеву взаємодію Sliver, звернення до Common Crawl).

Контекст загроз і зв’язок із TeamPCP

Дослідники відзначають суттєве перетинання цілей PCPJack з попереднім угрупованням TeamPCP, яке активно експлуатувало вразливості (включно з React2Shell) і помилки конфігурації в хмарних сервісах для побудови розподіленої мережі хостів для подальшої крадіжки даних та інших дій після проникнення.

Ключові відмінності PCPJack від TeamPCP:

• відсутність майнінгу криптовалюти — на відміну від попередньої кампанії, новий фреймворк явно видаляє функції майнерів, які раніше використовувала TeamPCP;
• фокус на крадіжку й монетизацію облікових даних через шахрайство, спам, вимагання або перепродаж доступу, а не на прямий майнінг;
• антиконкурентна поведінка: явне видалення процесів і артефактів TeamPCP та збір телеметрії «PCP replaced», що показує, що мета — не просто масове зараження, а заміщення конкуруючої інфраструктури.

Дослідники припускають, що схожість кодової бази й тактик може вказувати на можливий зв’язок з колишнім учасником TeamPCP, але це лишається оціночним судженням: підтвердженої технічної атрибуції немає.

Оцінка впливу та профіль ризику

Найвразливішими виглядають організації, які:

• експлуатують публічно доступні Docker/Kubernetes/Redis/MongoDB без жорстких політик автентифікації та мережевої сегментації;
• використовують Instance Metadata Service за замовчуванням без обмежень і проксі‑шарів;
• зберігають чутливі токени (API‑ключі до Anthropic, OpenAI, Google API, Grafana Cloud, Digital Ocean, HashiCorp Vault тощо) у змінних середовища, конфігураційних файлах контейнерів або service account’ах Kubernetes;
• мають довготривалі або необмежені в часі токени доступу без ротації.

Потенційні наслідки у разі успішної атаки:

• компрометація ланцюга постачання та розробницьких процесів — доступ до репозиторіїв, CI/CD, секретів у Vault і менеджерах паролів;
• компрометація даних клієнтів через доступи до баз даних, панелей моніторингу та систем зберігання;
• вторинне зловживання обліковими даними: розсилання спаму, атаки на треті сторони, вимагання, шахрайство з фінансовими сервісами;
• репутаційні та регуляторні ризики, якщо через украдені ключі атакують зовнішніх клієнтів або партнерів.

Окремо варто звернути увагу на глибину доступу, яку дає крадіжка токенів до провайдерів на кшталт Anthropic чи OpenAI: неконтрольоване використання потужностей, крадіжка внутрішніх промптів і конфігурацій, можливі зловживання даними, що надсилаються в моделі.

Практичні рекомендації із захисту

1. Скорочення поверхні атаки в хмарі та контейнерах

• Провести інвентаризацію всіх публічно доступних сервісів (Docker API, Kubernetes API, Redis, MongoDB, RayML, адміністративні інтерфейси веб‑застосунків).
• Вимкнути анонімний і «за замовчуванням» доступ, закрити непотрібні порти на рівні хмарних брандмауерів і security group.
• Жорстко обмежити доступ до Kubernetes API та Docker‑сокета лише через автентифіковані канали.

2. Захист Instance Metadata Service і service account’ів

• Обмежити доступ до IMDS (наприклад, лише з довірених сервісів/sidecar‑проксі), мінімізувати використання метаданих для отримання довготривалих токенів.
• Перевірити права service account’ів Kubernetes, прибрати надмірні привілеї, застосовувати принцип найменших привілеїв.
• Налаштувати мережеві політики в кластері, щоб контейнери не могли довільно звертатися до IMDS і Kubernetes API.

3. Управління секретами й токенами

• Винести API‑ключі (Anthropic, OpenAI, Google API, Digital Ocean, Grafana Cloud, HashiCorp Vault, OnePassword тощо) зі змінних середовища та статичних конфігурацій у спеціалізовані сховища секретів.
• Увімкнути ротацію токенів, особливо для високопривілейованих і необмежених у часі ключів.
• Упровадити моніторинг аномального використання ключів у провайдерів (стрибки запитів, нові географії, нетипові сценарії).

4. Виявлення PCPJack і пов’язаних активностей

• Пошукати в журналах і файлових системах сліди запуску невідомих shell‑скриптів, особливо з поведінкою «завантаження Python, встановлення persistence, самовидалення».
• Відстежувати на мережевому рівні:
  • нестандартні звернення до Common Crawl (завантаження parquet‑файлів із великими списками доменів);
  • підключення й трафік, характерні для Sliver (C2‑шаблони, взаємний TLS, нетипові домени керування).
• Використовувати відомі детектори Sliver та орієнтовані на MITRE правила (наприклад, за техніками T1105 (Ingress Tool Transfer) і T1552/T1555) у SIEM та IDS/IPS.

5. Реакція та пріоритезація

• Високий пріоритет (строк — дні, а не тижні): закриття відкритих Docker/Kubernetes/Redis/MongoDB/IMDS, ревізія токенів і ключів до перелічених сервісів, перевірка на наявність Sliver і підозрілих shell‑скриптів.
• У разі виявлення компрометації:
  • негайно відкликати й ротувати всі потенційно скомпрометовані ключі та токени;
  • розгорнути наново найбільш уражені інстанси з довірених образів із новою базою секретів;
  • провести ретроспективний аналіз логів для виявлення дій, учинених із використанням украдених облікових даних.

Ключовий висновок: PCPJack демонструє зміщення фокуса від грубого майнінгу до більш прибуткової й менш помітної монетизації через крадіжку хмарних та API‑облікових даних, тому найближчим часом пріоритетом для команд безпеки має стати закриття відкритих точок Docker/Kubernetes/IMDS, негайна ревізія та ротація токенів до хмарних і AI‑сервісів, а також упровадження поведінкового моніторингу для виявлення аномальних звернень до метаданих і запуску Sliver.