Хакерська група Velvet Ant, яку пов’язують із державними інтересами Китаю, продемонструвала вражаючий рівень прихованості, залишаючись непоміченою в інфраструктурі жертви протягом майже десятиліття. Замість використання класичних методів закріплення в системі, таких як планувальник завдань cron, системні служби systemd або веб-шелли, зловмисники інтегрували свій бекдор безпосередньо у механізми автентифікації операційної системи Linux. Мова йде про компрометацію системи підключуваних модулів автентифікації PAM та демона OpenSSH, які відповідають за авторизацію користувачів у системі.

Група Velvet Ant відома своїми складними кібершпигунськими кампаніями, спрямованими на великі підприємства та державні установи по всьому світу. Під час інциденту, який досліджували фахівці з безпеки компанії Sygnia, з’ясувалося, що стандартні антивіруси та рішення класу EDR не фіксували присутність атакуючих. Це стало можливим завдяки тому, що шкідливий код функціонував усередині легітимних процесів авторизації користувачів, не створюючи підозрілих побічних процесів чи аномальних мережевих з’єднань, які могли б викликати тривогу у захисників інфраструктури.

Технічна реалізація цього бекдору базується на модифікації компонентів PAM (Pluggable Authentication Modules). Цей фреймворк є основою для перевірки облікових даних у сучасних дистрибутивах Linux. Модифікувавши стандартну бібліотеку автентифікації (наприклад, pam_unix.so або додавши сторонній шкідливий модуль у конфігураційний ланцюжок автентифікації), хакери отримують можливість перехоплювати паролі користувачів у відкритому вигляді безпосередньо під час їхнього введення. Крім того, такий підхід дозволяє прописати так званий «майстер-пароль» (master password). Цей пароль підходитиме до будь-якого облікового запису в системі (навіть до root), незалежно від встановлених політик безпеки чи реальних паролів користувачів. Схожим чином модифікація бінарного файлу sshd дозволяє обходити автентифікацію за ключами або записувати паролі легітимних адміністраторів у прихований файл на диску.

Традиційні підходи до ліквідації наслідків інцидентів (remediation) часто виявляються абсолютно неефективними проти таких методів. Зазвичай адміністратори під час очищення інфраструктури шукають підозрілі скрипти в каталогах автозавантаження, модифіковані конфігураційні файли або нові облікові записи. Оскільки бекдор Velvet Ant знаходився безпосередньо всередині легітимних системних бібліотек, звичайне перезавантаження сервера чи видалення тимчасових файлів не давали жодного результату. Більше того, навіть оновлення операційної системи не завжди усувало проблему, якщо зловмисники зберігали доступ до інфраструктури керування конфігураціями (наприклад, Ansible, Puppet) або мали можливість повторно інфікувати систему через інші скомпрометовані вузли мережі.

Виявлення подібних загроз додатково ускладнюється тим, що системи моніторингу часто створюють базову лінію безпеки (baseline) вже після того, як система була скомпрометована. Якщо шкідливий модуль PAM або модифікований OpenSSH з’явилися на сервері кілька років тому, системи контролю цілісності файлів (FIM), встановлені пізніше, вважатимуть ці файли легітимними за замовчуванням. Це підкреслює критичну потребу у регулярній незалежній перевірці цілісності операційної системи із використанням довірених зовнішніх джерел та офіційних сховищ пакетів.

Ця атака є класичним прикладом високопрофесійного цільового шпигунства, де надійність та тривалість доступу є головним пріоритетом для зловмисників. Вона демонструє, що захист серверної інфраструктури Linux не може обмежуватися лише регулярним встановленням патчів безпеки та моніторингом мережевого трафіку. Захисникам необхідно впроваджувати глибокі перевірки системних компонентів та процесів автентифікації, які є фундаментом безпеки всієї системи.

Що це означає на практиці

  • Контроль цілісності файлів (FIM). Впроваджуйте інструменти контролю цілісності (наприклад, Wazuh, Samhain або Tripwire) для відстеження будь-яких змін у системних каталогах, де зберігаються модулі PAM (/lib/security/ або /lib64/security/) та виконувані файли сервісів, таких як /usr/sbin/sshd. Дуже важливо формувати еталонні зліпки (baselines) на гарантовано чистих системах одразу після їхнього розгортання з довірених образів.
  • Верифікація за допомогою пакетних менеджерів. Налаштуйте періодичні автоматичні перевірки відповідності встановлених бінарних файлів та бібліотек оригінальним контрольним сумам з офіційних репозиторіїв ОС. Для систем на базі Debian/Ubuntu використовуйте команду debsums -s (потрібно попередньо встановити пакет debsums), а для Red Hat/CentOS/AlmaLinux — rpm -Va. Будь-які розбіжності у контрольних сумах системних бібліотек мають негайно розслідуватися як інцидент високого пріоритету.
  • Аналіз конфігурацій PAM та OpenSSH. Регулярно проводьте аудит конфігураційних файлів у /etc/pam.d/ для виявлення невідомих або сторонніх модулів, які можуть бути підключені у ланцюжки автентифікації (особливо з параметрами auth, account, password, session). Також перевіряйте параметри демона SSH у /etc/ssh/sshd_config, звертаючи увагу на нетипові налаштування, такі як використання нестандартних шляхів для AuthorizedKeysFile або підключення сторонніх підсистем.
  • Централізоване логування та кореляція подій. Налаштуйте миттєве відправлення журналів авторизації (/var/log/auth.log or /var/log/secure) на ізольований сервер збору логів (SIEM). Зловмисники, які отримують права root, зазвичай намагаються зачистити сліди у локальних логах. Наявність копії логів на зовнішньому сервері допоможе виявити аномальні входи, використання master-паролів або несанкціоновані зміни в системі у реальному часі.