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

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

Что произошло: одно письмо — и два месяца тишины перед атакой

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

Хронология такая: 16 июля 2025 года сотрудник открыл вложение из письма — так в систему попал загрузчик MATCHBOIL, который развернул бэкдор MATCHWOK. Уже на следующий день, 17 июля, на заражённой машине закрепилась ранее неизвестная специалистам ESET программа MythicRatatoskr. Следующие недели атакующие потратили на изучение инфраструктуры и копирование вредоносного модуля на другие машины через протокол OpenSSH SFTP, а на нескольких узлах развернули SOCKS5-прокси для скрытого перемещения по сети. Финал наступил 17 сентября 2025 года: с помощью штатной утилиты Microsoft SDelete и групповых политик Active Directory атакующие одновременно запустили удаление файлов на множестве компьютеров домена.

ДатаСобытие
16 июля 2025Открыто вредоносное вложение, установлены загрузчик MATCHBOIL и бэкдор MATCHWOK
17 июля 2025На машине закрепляется MythicRatatoskr — ранее неизвестная ESET программа
Июль–сентябрь 2025Разведка сети, распространение через OpenSSH SFTP, развёртывание SOCKS5-прокси
17 сентября 2025Через групповые политики Active Directory и утилиту SDelete запущено массовое удаление файлов

Как вредонос два месяца оставался незамеченным в сети

Главная техническая находка ESET — способ связи MythicRatatoskr с атакующими. Вместо классического управляющего сервера, доступного напрямую из интернета, программа подключалась к децентрализованной IPv6-сети Yggdrasil с шифрованием трафика. В коде зашит список из 32 общедоступных узлов этой сети, из которых заражённая машина случайно выбирала три для связи — отследить и заблокировать единую точку управления в такой схеме почти невозможно.

При каждом запуске программа генерировала новый криптографический ключ и, соответственно, новый IPv6-адрес, а итоговое соединение с управляющим узлом шло по HTTPS через стандартный 443-й порт — трафик не выделялся на фоне обычной работы сотрудников. Вредонос закреплялся в системе как служба Windows под именем «ieupdate», некоторые сборки маскировались под системные компоненты, а часть образцов выжидала десять минут перед выходом на связь — простой, но эффективный приём против систем, анализирующих поведение процессов сразу после запуска.

Почему это прежде всего урок про контроль действий администраторов

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

Техническая деталь важнее любой экзотики с Yggdrasil: чтобы одновременно удалить файлы на десятках машин, атакующим нужны были права на изменение групповых политик домена. Это и есть контроль действий администраторов в чистом виде — кто-то получил возможность управлять настройками, которые применяются сразу ко всей инфраструктуре. Если бы изменения групповых политик и действия привилегированных учётных записей логировались и анализировались в реальном времени, массовую команду на удаление заметили бы не в момент атаки, а гораздо раньше — ещё на этапе разведки или первых подозрительных подключений по OpenSSH.

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

Что такое контроль действий администраторов и зачем он нужен бизнесу

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

Разница с контролем обычных пользователей — в масштабе последствий. Рядовой сотрудник своими правами способен повредить или раскрыть собственные данные либо данные своего отдела. Администратор домена или сервера способен одной командой изменить настройки, применяемые сразу ко всей инфраструктуре, — именно так в разобранном выше случае групповые политики Active Directory стали инструментом для одновременного удаления файлов на десятках машин. Поэтому для бизнеса контроль действий администраторов — это не вопрос недоверия к конкретным сотрудникам, а способ ограничить масштаб ущерба от компрометации привилегированной учётной записи, независимо от того, кто её использует — сам администратор, инсайдер или внешний злоумышленник, получивший доступ через фишинг.

Привилегированные пользователи и риск внутреннего нарушителя

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

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

Методы и инструменты контроля: PAM, PUM/PIM, DLP и SIEM

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

  • PAM (Privileged Access Management) — управление привилегированным доступом: выдача, временное повышение и отзыв прав, хранение и ротация паролей, запись сессий администраторов.
  • PUM/PIM (Privileged User/Identity Management) — управление учётными записями и цифровыми идентификаторами привилегированных пользователей; на практике функции PUM/PIM часто входят в состав PAM-систем как их часть.
  • DLP (Data Loss Prevention) — контроль перемещения данных: копирования на внешние носители, отправки по почте, выгрузки через облачные сервисы; защищает не от того, кто получил доступ, а от того, куда уходят данные.
  • SIEM (Security Information and Event Management) — система сбора и корреляции событий со всей инфраструктуры, включая журналы PAM; позволяет увидеть связь между, казалось бы, разрозненными событиями — например, подключением по SSH на одном сервере и изменением групповой политики на другом.

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

Как работает PAM-система: архитектура и принцип действия

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

Принцип работы в том, что администратор физически не знает действующий пароль от целевой системы — PAM подставляет его автоматически и может менять после каждого использования. Это разрушает саму возможность тихо скопировать общий пароль администратора и использовать его с другой машины, как это происходит при распространении атаки внутри домена. Многие PAM-решения дополнительно поддерживают модель выдачи прав «по требованию и на ограниченное время» (just-in-time access): повышенные права действуют только на время конкретной задачи, а не постоянно, что сокращает окно, в течение которого скомпрометированная учётная запись может быть использована.

Управление учётными записями и паролями привилегированных пользователей

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

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

Запись и воспроизведение сессий администраторов

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

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

Аудит действий и расследование инцидентов

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

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

Правовые основания контроля действий сотрудников

Мониторинг действий сотрудников, в том числе администраторов, на корпоративных системах пересекается с законодательством о персональных данных. Поскольку в журналах и записях сессий фиксируются действия конкретных людей, такой мониторинг должен быть оформлен как обработка персональных данных работника в соответствии с 152-ФЗ «О персональных данных»: сотрудников необходимо заранее уведомить о контроле их действий на рабочих системах и закрепить это во внутренних документах компании — локальных нормативных актах, трудовом договоре или отдельной политике информационной безопасности, с которой сотрудник знакомится при приёме на работу.

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

Как выбрать PAM-систему: критерии и модели развёртывания

Выбор конкретного решения зависит от масштаба инфраструктуры и типа компании. Для организации с десятком серверов и несколькими администраторами достаточно базового набора функций — сейфа паролей и записи сессий. Для крупной компании с распределённой инфраструктурой, подрядчиками на удалённом обслуживании и требованиями регуляторов важны дополнительные параметры: поддержка всех используемых протоколов и платформ (Windows RDP, Linux SSH, сетевое оборудование, облачные консоли управления), интеграция с уже используемыми SIEM и DLP-системами, модель выдачи прав «по требованию» и отказоустойчивость самой PAM-системы — она становится критичным компонентом инфраструктуры, и её собственный отказ не должен блокировать работу администраторов.

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

КритерийЛокальное размещение (on-premise)Облачное (SaaS)Гибридное
Где хранятся пароли, журналы и записи сессийВ инфраструктуре компанииВ инфраструктуре провайдера решенияКритичные данные — локально, управление — из облака
Кто обслуживает инфраструктуру PAMИТ-служба компанииПоставщик решенияРаспределено между сторонами
Применимость для объектов КИИ и других регулируемых системКак правило, подходит без ограниченийТребует отдельной проверки на соответствие отраслевым требованиямПодходит при локальном хранении критичных данных
Типичный профиль заказчикаКрупные компании с собственной ИТ-службой и строгими требованиями к размещению данныхКомпании без выделенной ИТ-службы для обслуживания PAMКомпании, у которых часть систем критична, а часть — нет

Что контроль действий администраторов даёт бизнесу

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

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

📢 Следим за изменениями в законах и сервисах для бизнеса каждый день. Канал «Контур-Центр» в Telegram — чтобы новости приходили к вам сами.

Оставьте заявку на подключение

Менеджер свяжется с вами и поможет с выбором сервисов и услуг