China-нexus группа Velvet Ant почти 10 лет жила не на обычных серверах, а в самом механизме входа в Linux. Об этом сообщила Sygnia: злоумышленники подменили компоненты PAM и OpenSSH, которые решают, кого пускать в систему, и использовали их для кражи логинов, паролей и команд администраторов.

Что произошло

По данным исследователей, следы активности тянутся как минимум с 2016 года. Вместо того чтобы ставить заметный вредоносный код, атакующие меняли доверенные программы авторизации — те самые, которые отвечают за проверку учетных данных при входе в Linux.

Такой подход сильно осложняет поиск. Сканеры обычно ищут отдельные вредоносные файлы и подозрительные процессы, а тут злоумышленник работает внутри штатного механизма входа. На экране администратора все выглядит как обычная сессия, а не как атака.

Как это было сделано

Sygnia пишет, что Velvet Ant подменяла модули PAM на нескольких машинах. Часть версий открывала вход по секретному паролю, другие — тихо записывали реальные имена пользователей и пароли в момент авторизации.

Отдельно исследователи нашли изменения в OpenSSH. Эти компоненты не просто пускали в систему, но и фиксировали учетные данные, а также каждую команду, которую вводил пользователь. У одного из вариантов был скрытый переключатель, который позволял выключить запись, если это нужно атакующему.

Чтобы добраться до изолированного сегмента без прямого доступа в интернет, группа сначала закреплялась на системах, доступных снаружи. Затем она использовала интернет-видимый веб-сервер как промежуточное звено и передавала через него команды глубже в сеть.

Логика атаки напоминает недавние истории с инфраструктурными целями, когда злоумышленники прячутся в доверенных узлах, а не в очевидном вредоносе. Похожим образом Google подала в суд на smishing-сеть с Gemini и фейковыми сайтами показывала, как важны контроль цепочки доступа и проверка точек входа, а не только блокировка внешних угроз.

Кого затронуло и чем это опасно

Под ударом оказалась изолированная корпоративная сеть, где прямого доступа в интернет не было. Это как раз тот случай, когда обычная смена пароля не спасает: если систему проверки логина уже контролирует атакующий, новые учетные данные тоже могут утечь.

Именно поэтому инцидент опасен не только кражей паролей. Захват компонента входа дает длительный и почти незаметный доступ, а значит — возможность читать команды, подстраивать маршруты атаки и сохранять присутствие даже после частичной зачистки.

Velvet Ant, судя по отчету, действует именно так и раньше. В 2024 году Sygnia уже связывала эту группу с превращением интернет-доступных F5 BIG-IP в внутренние командные узлы. Позже исследователи также сообщили об использовании уязвимости в Cisco NX-OS для установки закладки на коммутаторы. Похожая логика прослеживается и в истории с CISA потребовала срочно закрыть дыру в Ivanti Sentry: атакующие любят узлы, которым доверяют по умолчанию.

Что делать сейчас

Главный вывод для администраторов прост: здесь мало просто ставить патчи. Нужно проверять целостность систем входа, сравнивать PAM и OpenSSH с заведомо чистыми копиями и следить за изменениями ключевых файлов.

Сначала — поиск и удаление закладки, потом — сброс паролей. Иначе новые учетные данные уйдут туда же, куда ушли старые.

Если сеть изолирована, а доступ идет через промежуточные узлы, отдельно проверьте эти точки. Любой наружный сервер, через который идут команды, может стать мостом в глубь инфраструктуры.

Для тех, кто работает из поездок, кафе и аэропортов, отдельный риск — перехват трафика в открытых сетях. В таких сценариях пригодится защита канала в поездках и командировках, если речь идет о передаче чувствительных данных и входе в корпоративные сервисы.

Практический чек-лист

  • Проверьте контрольные суммы и версии PAM и OpenSSH на серверах, где важен вход по паролю.
  • Сверьте системные бинарники с эталонными копиями из доверенного источника.
  • Посмотрите логи на необычные изменения в файлах авторизации и ключах SSH.
  • Сначала удалите подозрительную подмену, потом меняйте пароли и ключи доступа.
  • Проверьте все внешние серверы, через которые ходят команды в изолированные сегменты.
  • Настройте оповещения на любое изменение файлов входа и конфигурации SSH.
  • Если сотрудники подключаются из поездок или отелей, ограничьте вход в корпоративные системы через небезопасные сети.
Поделиться: