Управление привилегированным доступом: зачем оно нужно после атаки Fire Ant

Как хакеры Fire Ant охотились на пароли администраторов

Тема управления привилегированным доступом вновь вышла на первый план в профессиональном сообществе ИБ после публикации компанией Sygnia отчёта о кампании кибершпионской группы Fire Ant. Эту группировку, которую специалисты соотносят с китайским кластером UNC3886, начиная с июля 2025 года фиксировали по атакам на гипервизоры VMware ESXi и vCenter. Сейчас же в фокусе внимания злоумышленников оказалась доверенная сетевая инфраструктура: маршрутизаторы Cisco IOS XR, серверы аутентификации TACACS+, а также управляющие Linux-хосты.

На скомпрометированных устройствах специалисты выявили работающий GRE-туннель, нигде не зафиксированный документально, — то есть существовавший вне поля зрения штатных администраторов. На маршрутизаторах Cisco работала кастомная вредоносная программа, написанная под IOS XR: она фильтровала журналы событий и подменяла вывод команды show, скрывая тем самым чужую активность от инженеров, проверяющих оборудование. Помимо этого, с заражённых устройств выгружались дампы сетевого трафика в формате PCAP, которые пересылались на внешние FTP-серверы, принадлежащие атакующим.

TacTap, руткиты и зачистка следов: технические детали атаки

Наиболее тревожная часть отчёта касается серверов TACACS+, обеспечивающих аутентификацию сетевых администраторов. Для кражи паролей группировка Fire Ant задействовала не встречавшийся ранее инструмент — TacTap. Эта утилита-инжектор встраивала вредоносную библиотеку непосредственно в работающий процесс демона аутентификации tac_plus и перехватывала системные вызовы accept и accept4. То есть вредоносный код не ограничивался пассивным прослушиванием сетевого трафика (именно так работали более простые инструменты вроде LOOKOVER), а перехватывал пароль администратора прямо в момент прохождения проверки подлинности, внутри самого процесса. Полученные данные записывались в файл /var/log/.tacplus.acct и маскировались однобайтовым XOR-ключом 0xEF.

На управляющих Linux-хостах атакующие развернули бэкдор BridgeAgent, замаскированный под легитимный агент мониторинга Zabbix — то есть под обычный системный процесс. Для долгосрочного закрепления в инфраструктуре использовались руткиты Medusa и REPTILE, а также самописные SSH-бэкдоры. После получения доступа злоумышленники методично зачищали следы своего присутствия: отключали журналирование событий и меняли временные метки файлов, усложняя тем самым установление реальной даты взлома в ходе расследования.

Почему удар именно по привилегированному доступу — худший сценарий

Компрометация пароля обычного сотрудника даёт злоумышленнику доступ лишь к одной учётной записи. Пароль же администратора, полученный через взлом TACACS-сервера, открывает контроль сразу над всей сетевой инфраструктурой — маршрутизаторами, коммутаторами, серверами доступа. Именно поэтому привилегированные аккаунты администраторов остаются главной целью для атакующих и одновременно наиболее уязвимым звеном до тех пор, пока их защита не выделена в отдельный контур, отличный от обычных учётных записей.

Кампания Fire Ant показывает и ещё один приём: как атакующие лишали администраторов достоверной картины происходящего на устройстве. Подделка вывода команды show вкупе с отключением логов приводила к тому, что штатные средства диагностики переставали отражать реальное состояние оборудования. Конкретные названия пострадавших организаций исследователи не называют, но указывают, что среди жертв — компании с критически значимой инфраструктурой, а сам метод внедрения кода в демон аутентификации ранее публично никем не описывался.

Кого касается эта угроза в российских компаниях

Было бы неверно считать это исключительно проблемой владельцев оборудования Cisco IOS XR. Протокол TACACS+ и его аналог RADIUS широко применяются как решения централизованной аутентификации: с их помощью многим организациям предоставляют администраторам доступ к сетевому оборудованию, серверам и системам управления. Под угрозой оказывается практически любая компания, в которой привилегированные учётные записи штатных администраторов, подрядчиков и ИТ-аутсорсеров не обособлены от общей инфраструктуры и не контролируются отдельно.

Риск особенно велик там, где системные администраторы годами используют одни и те же пароли для доступа к десяткам устройств, а сессии по SSH и RDP никак не фиксируются и впоследствии не анализируются. В такой ситуации взлом всего одной привилегированной учётной записи открывает злоумышленнику путь во всю сеть целиком — именно так и развивалась описанная кампания.

Управление привилегированным доступом (PAM) как ответ на подобные атаки

PAM, то есть управление привилегированным доступом, представляет собой самостоятельный класс защиты, ориентированный на учётные записи администраторов, подрядчиков и сервисных аккаунтов с расширенными правами. От стандартного разграничения прав PAM-система отличается тем, что хранит пароли администраторов в защищённом хранилище — не в конфигурационных файлах и не в памяти сотрудников, — и фиксирует каждое привилегированное подключение отдельно от основного трафика сети.

Именно в этом состоит ключевое отличие: если данные о привилегированных подключениях и сами учётные данные вынесены за пределы устройства — в PAM-систему, к которой у злоумышленника нет доступа, — то подделка вывода команды show или отключение локальных логов на взломанном маршрутизаторе теряют для него всякий смысл.

Что такое PAM и какие учётные записи он защищает

PAM (Privileged Access Management) — это комплекс технических решений и организационных мер для защиты, контроля и фиксации действий учётных записей с расширенными полномочиями: системных администраторов, инженеров баз данных, DevOps-специалистов, а также сервисных и технических аккаунтов. Обладатель привилегированной учётной записи, в отличие от рядового сотрудника, получает доступ не к одному рабочему месту, а сразу к серверам, сетевому оборудованию, базам данных и настройкам системы защиты. Поэтому кража пароля администратора — как произошло с TACACS-серверами в кампании Fire Ant — обходится организации в разы дороже утраты обычного пароля.

К привилегированным учётным записям обычно относят:

• Root- и administrator-аккаунты — дают полный контроль над операционной системой, сетевым устройством или гипервизором.
• Учётные записи администраторов баз данных (DBA) — обеспечивают доступ к конфиденциальным данным и структуре их хранения.
• Сервисные и технические учётные записи — используются приложениями, скриптами и интеграциями без участия человека при входе, но при этом часто обладают весьма широкими полномочиями.
• Учётные записи подрядчиков и ИТ-аутсорсеров — временные привилегированные права, выдаваемые за пределы периметра организации.
• Аварийные (break-glass) учётные записи — резервный канал доступа на случай отказа основной системы аутентификации.

Принцип работы PAM прост: у сотрудника нет прямого доступа к паролю привилегированной учётной записи. Пароли хранятся в защищённом хранилище (vault) и обновляются автоматически, подключение к серверу или устройству проходит через выделенный шлюз, а сам доступ выдаётся только после дополнительной проверки — как правило, многофакторной аутентификации. Вся сессия при этом протоколируется и сохраняется для дальнейшего анализа вне зависимости от журналов устройства.

Основные функции PAM-системы

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

• Хранение и ротация паролей. Учётные данные привилегированных аккаунтов помещаются в зашифрованное хранилище и меняются автоматически — по расписанию или сразу после каждого использования, — так что администратору больше не нужно держать их в конфигурационных файлах, скриптах или в памяти.
• Брокеринг сессий. Подключение по SSH, RDP или через веб-консоль проходит через выделенный шлюз: пользователь оказывается в целевой системе, но сам пароль ему не раскрывается.
• Многофакторная аутентификация перед выдачей доступа. Дополнительная проверка личности снижает шанс того, что один лишь похищенный или подобранный пароль позволит злоумышленнику получить привилегированный доступ.
• Запись и мониторинг сессий. Действия администратора фиксируются полностью — вплоть до видеозаписи сессии и журнала введённых команд, — причём эти данные хранятся отдельно от устройства, поэтому подмена локальных логов на сервере ничего скрыть не даёт.
• Just-in-time (временный) доступ. Права выдаются на ограниченный срок под конкретную задачу и автоматически отзываются по её завершении, вместо того чтобы оставаться активными бессрочно.
• Управление жизненным циклом учётной записи. Оперативное обнаружение новых привилегированных аккаунтов в инфраструктуре, регулярный пересмотр выданных прав, а также быстрый отзыв доступа при увольнении сотрудника или завершении работ подрядчика.
• Аудит и отчётность. Журналы привилегированных подключений формируются в формате, пригодном как для внутреннего расследования инцидентов, так и для проверок регуляторов.

PAM, PIM, PUM и IAM: в чём разница

В материалах о защите доступа часто встречаются четыре похожих термина, которые разные производители трактуют неодинаково. Общий принцип таков: IAM отвечает за управление доступом всех сотрудников организации целиком, а PAM, PIM и PUM представляют собой более узкие категории, сфокусированные на пользователях с расширенными полномочиями.

На практике из этих четырёх понятий PAM оказывается наиболее широким по охвату: зрелое PAM-решение обычно вбирает в себя и функции PIM — временную активацию ролей, — и функции PUM — управление самими привилегированными аккаунтами, — тогда как за прочие, непривилегированные учётные записи по-прежнему отвечает IAM.

Zero Trust и just-in-time доступ: от постоянных прав к временным

При классическом подходе администратор получает права один раз и затем пользуется ими без временных ограничений, из-за чего такая учётная запись превращается в постоянную мишень: взломав её единожды, злоумышленник сохраняет доступ на неопределённый срок. Именно так действовала Fire Ant, месяцами оставаясь незамеченной внутри скомпрометированной инфраструктуры. Концепция Zero Trust строится на противоположном принципе — «не доверяй ни одному запросу по умолчанию, даже если он поступает изнутри периметра» — и требует отдельной проверки каждого обращения к ресурсу вне зависимости от его источника.

Применительно к привилегированному доступу Zero Trust реализуется через принцип минимальных постоянных привилегий (least standing privilege) и just-in-time-доступ: права на администрирование конкретной системы выдаются не навсегда, а на ограниченный срок под определённую задачу — например, на несколько часов для планового обслуживания сервера, — и снимаются автоматически по истечении этого срока или завершении сессии. Такой подход сокращает так называемое «окно атаки»: даже если пароль или сессия администратора будут скомпрометированы, злоумышленник не получит постоянного доступа, а сам запрос прав вне обычного графика станет для службы ИБ заметным тревожным сигналом.

Какие риски закрывает PAM

При отсутствии выделенного контроля привилегированного доступа организации обычно сталкиваются с одним и тем же набором угроз — проявляются они по-разному, но приводят к схожему результату: утрате контроля над инфраструктурой и невозможности доверять собственным журналам событий:

• Компрометация учётных данных администратора извне. Наглядный пример — кампания Fire Ant: перехватив пароль на сервере аутентификации TACACS+, злоумышленники получили доступ сразу к множеству сетевых устройств.
• Атаки через подрядчиков и цепочку поставок. Удалённый привилегированный доступ, который предоставляют внешнему ИТ-подрядчику для обслуживания систем, — давно известный вектор атаки: взлом инструмента или учётной записи такого подрядчика открывает злоумышленнику инфраструктуру сразу всех его клиентов. По похожей схеме в 2020 году была реализована атака на цепочку поставок через продукт SolarWinds Orion.
• Инсайдерские угрозы. Сотрудник с расширенными полномочиями может намеренно или по неосторожности скопировать, изменить либо удалить важные данные — без независимой фиксации сессий подобные действия трудно обнаружить и ещё труднее впоследствии доказать.
• Разрастание привилегий («privilege creep»). С течением времени у сотрудников накапливаются права, давно не нужные для текущих задач, но так и не отозванные, — и каждое такое забытое право расширяет поверхность для потенциальной атаки.

Критерии выбора PAM-решения

При выборе PAM-системы стоит оценивать не только формальный список функций, но и то, насколько органично решение впишется в реальную инфраструктуру организации:

• Поддержка протоколов и каналов доступа, используемых в компании, — SSH, RDP, веб-консоли, VPN, ActiveSync, TACACS+/RADIUS.
• Запись сессий с возможностью текстового поиска по введённым командам, а не только сплошная видеофиксация.
• Способность интегрироваться с уже развёрнутой многофакторной аутентификацией и действующей системой управления учётными записями.
• Поддержка just-in-time доступа и временной выдачи прав, а не только статичное хранение паролей.
• Отказоустойчивость хранилища паролей — оно не должно становиться единой точкой отказа для доступа ко всей инфраструктуре.
• Наличие решения в реестре отечественного ПО Минцифры — важно для госорганов, субъектов КИИ и организаций, обязанных соблюдать требования импортозамещения.
• Действующие сертификаты и разрешительная документация ФСТЭК России у производителя — когда этого требует класс защищаемой информационной системы.
• Возможность постепенного внедрения без остановки текущих рабочих процессов: решение не должно заставлять администраторов отказываться от привычных инструментов подключения.
• Наличие русскоязычной технической поддержки и документации.

Обзор рынка PAM-решений и импортозамещение

До 2022 года на российском рынке преобладали зарубежные PAM-платформы, часть из которых впоследствии прекратила официальную поддержку и выпуск обновлений в России. Это стало стимулом для перехода на отечественные разработки — прежде всего для организаций госсектора и субъектов критической информационной инфраструктуры: часть таких решений уже включена в реестр российского ПО Минцифры, что важно при закупках по 44-ФЗ и 223-ФЗ, а также при выполнении требований импортозамещения на объектах КИИ.

При сравнении конкретных продуктов имеет смысл опираться не на маркетинговые описания, а на перечисленные выше критерии: поддерживаемые протоколы, глубину записи сессий, наличие just-in-time доступа и сертификатов ФСТЭК. В экосистеме Контур.Эгиды эту задачу решает отдельный PAM-модуль, работающий в связке с многофакторной аутентификацией Контур.ID, — благодаря чему в рамках одного решения закрываются сразу три задачи: хранение паролей администраторов, контроль их сессий и вход с дополнительной проверкой.

Этапы внедрения PAM в организации

Внедрение PAM практически никогда не проходит одномоментно: резкое ограничение привычного доступа администраторов без предварительной подготовки почти неизбежно вызывает сопротивление персонала и риск сбоев в работе. Поэтому на практике такой проект выстраивают поэтапно:

1. Инвентаризация (discovery). Выявляются все привилегированные учётные записи в инфраструктуре — включая забытые, сервисные и записи подрядчиков, о которых порой не помнят даже сами администраторы.
2. Приоритизация систем. Определяются наиболее критичные контуры — объекты КИИ, системы с персональными данными, финансовые системы, — и внедрение начинается именно с них.
3. Пилотный запуск. PAM-решение разворачивают на ограниченном сегменте инфраструктуры, чтобы отработать процессы и убедиться, что оно не мешает текущей работе администраторов.
4. Перенос паролей в защищённое хранилище. Учётные данные привилегированных аккаунтов удаляются из конфигураций, скриптов и памяти сотрудников и переводятся на автоматическую ротацию.
5. Настройка брокеринга и записи сессий. Подключения администраторов перенаправляются через шлюз PAM-системы с включённым журналированием.
6. Включение MFA и just-in-time доступа. Постоянные права заменяются выдачей доступа под конкретную задачу, а вход дополнительно защищается многофакторной аутентификацией.
7. Обучение администраторов и подрядчиков новому порядку подключения к системам.
8. Полный охват инфраструктуры — перевод оставшихся систем на работу через PAM.
9. Регулярный пересмотр прав. Периодическая проверка того, кому и для каких целей выдан привилегированный доступ, с отзывом уже неактуальных полномочий.

PAM и требования регуляторов

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

• 152-ФЗ «О персональных данных». Обязывает контролировать доступ к информационным системам, обрабатывающим персональные данные, — включая доступ администраторов этих систем.
• 187-ФЗ «О безопасности критической информационной инфраструктуры». Обязывает субъектов КИИ применять меры защиты от несанкционированного доступа, в том числе контролировать действия привилегированных пользователей на значимых объектах.
• Приказы ФСТЭК России — в частности №17 для государственных информационных систем, №21 для систем с персональными данными и №239 для значимых объектов КИИ — устанавливают требования к идентификации, аутентификации и управлению доступом, которым должны соответствовать применяемые средства защиты.
• ГОСТ Р 57580.1-2017 — стандарт Банка России по защите информации для финансовых организаций, включающий отдельные требования к управлению доступом привилегированных пользователей.

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

Что сделать прямо сейчас: чек-лист для ИБ и ИТ-отделов

• Провести инвентаризацию всех привилегированных учётных записей — администраторов, подрядчиков, сервисных аккаунтов — и отказаться от одинаковых паролей сразу для нескольких устройств.
• Исключить пароли администраторов из конфигураций и скриптов, перенеся их в защищённое хранилище учётных данных.
• Включить многофакторную аутентификацию отдельно для входа с правами администратора — на серверы, сетевое оборудование, ActiveSync и VPN.
• Наладить журналирование привилегированных SSH- и RDP-сессий независимо от логов самого устройства, чтобы исключить возможность их подмены изнутри.
• Регулярно проверять конфигурации сетевого оборудования на предмет недокументированных туннелей и правил маршрутизации.
• Регулярно менять пароли привилегированных учётных записей и оперативно отзывать доступ подрядчиков по завершении работ.

Частые вопросы

Что такое TACACS+ и почему хакеры охотятся на пароли администраторов?

TACACS+ — протокол централизованной аутентификации, через который администраторы получают доступ к сетевому оборудованию. Взломав такой сервер, злоумышленник получает пароли сразу ко множеству устройств, а не к единственному аккаунту.

Как понять, что учётная запись администратора скомпрометирована?

По данным Sygnia, злоумышленники подменяли вывод диагностических команд и отключали журналирование, из-за чего стандартная проверка устройства порой не показывала ничего подозрительного. Надёжнее опираться на независимый журнал привилегированных сессий, который ведётся отдельно от самого устройства.

Чем PAM-система отличается от обычного разграничения прав доступа?

Стандартное разграничение прав определяет, что именно позволено делать сотруднику. PAM-система идёт дальше: держит пароли администраторов отдельно от устройств, пропускает SSH- и RDP-подключения через выделенный шлюз и фиксирует действия независимо от журналов самой системы.

Чем PAM отличается от IAM, PIM и PUM?

IAM отвечает за управление доступом всех сотрудников организации в целом, а PAM, PIM и PUM — более узкие направления для учётных записей с расширенными полномочиями. PIM обычно отвечает за временное предоставление привилегированных ролей, PUM — за управление самими такими пользователями, а PAM на практике объединяет обе эти функции наряду с хранением паролей и записью сессий.

Что такое just-in-time доступ в PAM?

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

Нужно ли внедрять управление привилегированным доступом небольшой компании?

Даже в небольшой компании учётные записи администраторов открывают доступ ко всей инфраструктуре и потому нередко становятся точкой входа при целевых атаках: риск зависит не от размера бизнеса, а от числа критичных систем, управление которыми ведётся через привилегированный доступ.

Сколько времени занимает внедрение PAM-системы?

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

Как защититься, если в компании используется TACACS+ или RADIUS?

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

Вывод

Кампания Fire Ant показала: чем изощрённее становятся способы заметания следов на самих устройствах, тем менее надёжно полагаться исключительно на логи оборудования. PAM выводит контроль администраторских паролей и сессий на отдельный уровень, не зависящий от скомпрометированного устройства, — туда, где злоумышленник не способен ни подделать журнал, ни изменить конфигурацию.

В экосистеме Контур.Эгиды за эту задачу отвечает отдельный PAM-модуль: он хранит пароли администраторов в защищённом хранилище, пропускает привилегированные SSH- и RDP-подключения через выделенный шлюз и фиксирует действия администраторов независимо от логов самих устройств. В сочетании с многофакторной аутентификацией Контур.ID при входе под привилегированной учётной записью это закрывает именно тот сценарий, который использовала Fire Ant, — хищение пароля администратора и скрытую работу под чужим именем.