От требований ФСТЭК до реальной атаки: защита конечных устройств на практике

Процесс 1С запускает командную строку. PowerShell загружает архив. В системе появляется новая служба, а затем — туннель для удалённого доступа. По отдельности некоторые из этих событий можно принять за работу администратора. Вместе они складываются в начало атаки.

Для расследования нужно установить, кто запустил процессы, как они связаны, какие файлы появились на устройстве и куда злоумышленник успел перейти. Именно с такими задачами работает EDR — система обнаружения и реагирования на конечных устройствах. На примере Toy Ghouls разберём, как восстановить ход атаки и остановить её развитие. Начнём с требований, которые нужно учитывать при построении защиты.

Приказ ФСТЭК России № 117 вступил в силу 1 марта 2026 года и заменил приказ № 17. Он устанавливает требования к защите информации в государственных информационных системах и иных информационных системах государственных органов, государственных учреждений и государственных унитарных предприятий.

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

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

Шесть мер защиты конечных устройств
Подробный состав мер приведён в методическом документе «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» от 12 апреля 2026 года. Для защиты конечных устройств выделен раздел ЗКУ.

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

Состав обязательных мер зависит от класса защищённости системы и результатов адаптации набора мер. В частности, ЗКУ.5 не входит в базовые наборы и рассматривается при их адаптации и уточнении с учётом угроз.

Для ЗКУ.3 предусмотрено усиление для систем первого и второго классов: на конечных устройствах информационной системы, имеющей доступ к ресурсам интернета, должны обеспечиваться обнаружение атак и реагирование с использованием систем обнаружения вторжений уровня узла и/или средств обнаружения и реагирования на уровне узла. Для ЗКУ.6 соответствующее усиление включает уведомление администратора безопасности о признаках инцидента. Цифры в графе усиления обозначают номера требований, а не классы защищённости.

Поэтому вопрос о внедрении EDR решают применительно к конкретной системе. Одного названия класса продукта недостаточно, чтобы определить его соответствие всем требованиям.

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

До выбора продукта стоит провести инвентаризацию информационных систем и определить применимые требования. Затем — оценить, какие задачи уже решаются существующими средствами защиты, а для каких потребуется EDR.

Для регулируемой инфраструктуры в критерии выбора входят наличие продукта в реестре российского ПО, соответствующий сертификат ФСТЭК и техническая поддержка в России. Проверять нужно конкретную редакцию и  поставку: даже у одного производителя EDR-решения могут различаться по возможностям и применимости. Следующий этап — пилот. Он позволяет оценить решение до полноценного внедрения. После успешного тестирования можно планировать бюджет, развёртывание и ввод в эксплуатацию.

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

Toy Ghouls — финансово мотивированная группировка, атакующая российские организации из разных отраслей. Её узнаваемая деталь — персонаж Лабубу, которого адаптируют под жертву: строитель для строительной компании, нефтяной магнат для нефтяной отрасли, пекарь для общественного питания.

В рассматриваемых атаках первоначальный доступ связан с подрядчиками и компрометацией серверов 1С. Поэтому при расследовании важно учитывать, как внешние специалисты подключаются к инфраструктуре и какие возможности получают через обслуживаемые системы.

Дальнейшая цепочка включает закрепление, создание туннеля, разведку, получение учётных данных и переход на другие узлы. Для этого используются в том числе утилиты администрирования. В разобранном сценарии встречаются NSSM, Localtonet, AD Explorer, NetScan и PAExec. Написание инструментов и их использование группировкой также подтверждаются исследованием Securelist.

Отправной точкой может стать алерт — срабатывание правила обнаружения. Но алерт ещё не означает, что атака подтверждена: он может быть как истинным, так и ложным. Сначала нужно разобраться в обстоятельствах события.

В Kaspersky EDR Expert карточка инцидента собирает сведения о затронутом хосте, важности и приоритете, сработавших правилах, технологиях обнаружения, тактиках и техниках MITRE ATT&CK. Рядом находится список связанных алертов.

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

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

Например, создание службы само по себе не объясняет причину срабатывания. Гораздо больше говорит последовательность: процесс 1С запустил CMD, через него загрузили инструменты, после чего появилась служба, запускающая файл из временного каталога.

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

Загрузка инструментов и закрепление
В начале рассматриваемой цепочки процесс 1С создаёт дочерние процессы CMD. Через них выполняются следующие действия, включая загрузку и распаковку файлов с помощью PowerShell.

Затем используется NSSM — утилита, позволяющая запускать приложения как службы. С её помощью создаётся служба для запуска инструмента туннелирования Localtonet. После установки загруженные архивы удаляются.

Граф процессов связывает эти действия между собой. Аналитик может установить, какой процесс инициировал загрузку, откуда запустился исполняемый файл и каким образом он закрепился на устройстве.

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

Следующий этап — поиск ресурсов и учётных данных. В цепочке появляются действия с чувствительными данными реестра, включая SAM, SECURITY и секреты LSA. Затем доставляются и запускаются AD Explorer и NetScan.

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

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

В хронологии присутствует попытка получения дампа NTDS.dit. Компрометация доменных учётных данных создаёт условия для дальнейшего распространения атаки и развёртывания шифровальщика.

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

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

ИИ-помощник KIRA помогает подготовить такой разбор. В описанной конфигурации он формирует краткое резюме инцидента, список хостов, учётных записей и IP-адресов, хронологию событий и подробное текстовое описание.

Для атаки Toy Ghouls в этой хронологии связываются загрузка инструментов, создание службы, запуск туннеля, действия с учётными данными и попытка выполнения команд на контроллере домена. Аналитик получает исходную картину и может переходить к проверке отдельных эпизодов.

Разбор незнакомой команды
KIRA также используется для объяснения командной строки. Это полезно, когда аналитик не знаком с утилитой или её параметрами.

В примере с NSSM помощник объясняет, что команда создаёт службу, указывает запускаемый исполняемый файл и отмечает его размещение во временном каталоге. Затем разбирает назначение отдельных параметров.

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

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

В Kaspersky Threat Intelligence Portal для этого используются карточки файлов, правила обнаружения, сведения о группировках и исследовательские отчёты.

Проверка логики срабатывания в HuntHub
В хранилище правил HuntHub доступны описание правила, рекомендации, возможные ложные срабатывания и логика обнаружения в формате, похожем на Sigma.

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

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

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

Сведения о группировке и её инструментах
Из правила можно перейти к связанным техникам и карточке группировки. Там собраны её название и псевдонимы, атакуемые отрасли, описание активности, инструменты и сведения об их обнаружении.

Дополнительно доступны используемые уязвимости CVE, карточки отдельных инструментов, дерево тактик, техник и процедур, интерактивные карты и отчёты об атаках. Например, при встрече с незнакомым 1C-Shell или GOST можно отдельно изучить назначение инструмента и вернуться к своему расследованию.

Эта информация помогает проверить, встречалась ли похожая последовательность раньше и какие ещё следы стоит искать.

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

Такой переход использовался и в разборе активности NetScan. Отчёты добавляют сведения о предыдущем применении файла, которые можно сопоставить с событиями на исследуемом хосте.

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

Через LiveShell можно подключиться к узлу, проверить текущий контекст выполнения и посмотреть, что происходит на нём сейчас. В рабочем каталоге атакующих обнаруживаются AD Explorer, Localtonet, NetScan, NSSM и другие инструменты.

Зная имя службы, аналитик может проверить её состояние, остановить и удалить. Список процессов доступен через Tasklist; подозрительные процессы можно завершить.

Из консоли управления предусмотрены и другие действия:

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

После остановки активной фазы собранные материалы передаются на дальнейшее расследование. Важно установить, какие действия уже выполнены и какие узлы могли быть затронуты. Остановка одного процесса сама по себе не даёт ответа на эти вопросы.

Сценарий Toy Ghouls показывает разницу между своевременной реакцией и пропущенным сигналом. Пока атака находится на этапе закрепления и организации удалённого доступа, у команды есть возможность прервать её развитие. Если ранние срабатывания оставить без внимания, следующими этапами становятся разведка, получение учётных данных и переход на контроллер домена.

Где работает модель
Для описанной конфигурации KIRA предусмотрена работа с GigaChat. Также заявлена возможность подключения другой языковой модели — локальной или облачной, с использованием API-ключа. В исходных материалах упомянут и вариант размещения KIRA внутри инфраструктуры заказчика, но его подробная архитектура не раскрыта.

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

Поэтому выбор зависит и от ограничений на передачу сведений, и от доступных ресурсов, и от качества разбора конкретных инцидентов.

Как KIRA связана с мерами защиты
Функции KIRA рассматриваются вместе с EDR. Они помогают при анализе процессов и событий — задачах, связанных с ЗКУ.4 и ЗКУ.6.

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

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

Обновление моделей и использование данных
Универсальная периодичность дообучения KIRA в материалах не указана. Также не раскрыты договорные и технические условия использования данных заказчика при обучении.

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

Получить пароль генерального директора или системного администратора — какой доступ опаснее?
Ответ зависит от цели. Для финансового мошенничества учётная запись директора может оказаться ценнее. Для перемещения по инфраструктуре, доступа к серверам и подготовки массового шифрования — административная.

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

Выбор EDR начинается с состава информационных систем, применимых требований и задач команды ИБ. После этого можно определить нужные функции, проверить условия поставки и перейти к пилоту.

При тестировании полезно пройти весь рабочий сценарий: от срабатывания правила до восстановления последовательности событий, проверки файлов, работы с учётными записями и сбора материалов для расследования. Отдельного внимания требуют доступ к Threat Intelligence и условия использования ИИ-помощника.

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