КиберЩит
1398 дней до обнаружения: почему SOC пропустил скрытую атаку
📋 Кратко
Злоумышленники сохраняли доступ к сети госучреждения минимум 1398 дней. Анализ показывает активность с апреля 2022 года, расширение присутствия с февраля 2026 года и применение скрытых инструментов. Разбираем, какие факты подтверждены, где заканчивается реконструкция и почему отсутствие тревог не означает отсутствие следов.
1398 дней — это срок между ранней подтверждённой активностью и обнаружением инцидента. Именно столько злоумышленники находились во внутренней сети одного государственного учреждения. Они не устраивали заметный сбой каждый день. Вместо этого группа сохраняла доступ и расширяла присутствие.
В 2026 году специалисты PT ESC IR обнаружили новую APT-группировку StingyBasilisk. Анализ показал активность минимум с апреля 2022 года. Исходный вектор заражения установить не удалось.
🔍 Что означает срок в 1398 дней
Длительное присутствие называют скрытым пребыванием в инфраструктуре. Злоумышленник уже получил доступ, но ещё не вызвал событие, которое заметит защита. Он может изучать сеть, менять точки закрепления и выбирать время для дальнейших действий.
В этом случае специалисты установили активность группы как минимум с апреля 2022 года. Саму группировку обнаружили в 2026 году во время расследования инцидента. Поэтому срок 1398 дней означает время до обнаружения, а не точную дату первоначального взлома.
Эта разница важна для расследования. Нельзя автоматически считать апрель 2022 года днём проникновения. Это самая ранняя подтверждённая точка активности, которую удалось восстановить.
Факты, реконструкция и предположения
Фактами остаются обнаружение StingyBasilisk в 2026 году и активность минимум с апреля 2022 года. Также подтверждено расширение зоны присутствия с февраля 2026 года. Зафиксированы именованные каналы Windows, SMB и планировщик заданий.
Реконструкция связывает эти события в одну длительную кампанию. Однако она не отвечает на все вопросы. Например, исходный вектор заражения установить не удалось.
Что сделать сейчас: в отчёте об инциденте разделите даты на подтверждённые, предполагаемые и неизвестные. Не называйте дату первого проникновения без доказательства.
📋 Как развивалась атака по доступным данным
Самая ранняя подтверждённая активность относится к апрелю 2022 года. На этом этапе группа уже действовала в инфраструктуре или оставила следы, которые позднее удалось найти. Данных о точном способе входа недостаточно.
Затем злоумышленники сохраняли скрытый доступ к внутренней сети. Они маскировали вредоносные инструменты под средства защиты, которыми пользовалась сама организация. Такой подход усложняет отделение опасного кода от легитимных компонентов.
С февраля 2026 года группа начала активно расширять зону присутствия. Внутреннее перемещение проходило через SMB (протокол обмена файлами и удалённого доступа Windows). Удалённый запуск выполнялся через планировщик заданий Windows.
В 2026 году команда реагирования обнаружила группировку во время расследования. После этого специалисты нашли разветвлённую сеть агентов и восстановили более ранние эпизоды активности.
Что сделать сейчас: составьте временную шкалу по узлам. Для каждой записи укажите систему, дату, источник журнала и уровень уверенности.
🧩 Почему обычный мониторинг мог не сработать
Первая причина — инструменты группы выглядели как часть привычной защиты. Если средство контроля не проверяет происхождение компонента, оно видит знакомое имя или путь. Содержание и поведение при этом остаются без внимания.
Вторая причина — код некоторых модулей не сохранялся на диске. SilentCOM, TediousLoader и CunningDoor запускали вредоносный код прямо в оперативной памяти заражённого компьютера. Такой след сложнее найти после перезагрузки.
Третья причина — действия распределялись по разным системам. Один агент мог запускаться через службу, другой — через планировщик. Связь между событиями появляется только после корреляции данных от нескольких узлов.
Четвёртая причина — перемещение выглядело как обычная административная работа. SMB и планировщик заданий применяются в легитимных сценариях. Сам по себе факт их использования не доказывает атаку.
Отсутствие тревоги не равно отсутствию следа
Средство защиты может не сформировать оповещение. При этом журнал входа, запуск задания или изменение компонента уже остаются в системе. Если журнал быстро удаляется, расследование теряет важную часть картины.
Другой вариант — тревога появляется, но тонет среди обычных событий. Администраторы регулярно используют удалённый запуск и служебные каналы. Без контекста система не отличает редкую атаку от привычной операции.
Что сделать сейчас: проверьте, какие события собираются с серверов. Отдельно оцените запуск заданий, изменения служб, SMB-доступ и работу средств защиты.
🛠️ Какие техники применяла StingyBasilisk
Группа использовала несколько инструментов. SilentCOM, TediousLoader и CunningDoor представляли собой программные модули. Они запускали код в оперативной памяти заражённого устройства.
Агенты управлялись через именованные каналы Windows. Это механизм обмена данными между процессами. В легитимной работе он нужен приложениям и службам, поэтому один такой канал не является доказательством компрометации.
Для закрепления применялись COM Hijacking и Time Providers. Первый подход подменяет ссылки на легитимные COM-компоненты Windows. Второй регистрирует библиотеку как поставщика времени службы W32Time.
Каждая техника требует своего набора наблюдений. Для COM Hijacking важны изменения ссылок и записей конфигурации. Для Time Providers — новые или неожиданные параметры службы времени. Для памяти — подозрительные процессы и связи между ними.
Почему название инструмента недостаточно
Название файла не доказывает его назначение. Легитимный компонент может иметь похожее имя. Вредоносный модуль может выглядеть как средство защиты.
Надёжнее сопоставлять несколько признаков. Нужны время запуска, родительский процесс, учётная запись, сетевые соединения и изменения конфигурации. Один слабый сигнал редко даёт уверенный вывод.
Что сделать сейчас: добавьте в правила контроля изменения COM-компонентов и поставщиков времени. Для каждого события сохраняйте пользователя, процесс, узел и точное время.
📊 Какие данные нужны для расследования
Для восстановления такой кампании одного журнала недостаточно. Нужны данные с конечных устройств, серверов, средств защиты и сети. Их следует связывать по времени, учётным записям и именам узлов.
В рассмотренной выборке расследований специалисты использовали более 150 тысяч записей из более чем 50 источников. В 91,9% проектов заказчики передавали сведения, собранные утилитой PT Dumper. Эти данные дополняли журналы средств защиты и приложений, образцы вредоносного ПО и сетевой трафик.
Масштаб сбора зависел от проекта. В 30,7% случаев анализ охватывал более 100 узлов. В 6,1% случаев специалисты изучали более 1000 узлов.
Эти цифры показывают важный принцип. Длительную атаку нельзя надёжно проверить по одному серверу. Компрометация может проявляться через связь между несколькими устройствами.
Минимальный набор источников
- журналы входа и смены учётных записей;
- события запуска процессов и служб;
- изменения заданий планировщика;
- изменения COM-компонентов и поставщиков времени;
- данные о SMB-соединениях между узлами;
- события средств защиты и сетевые соединения;
- образы памяти при подозрении на запуск кода без файла.
Список не заменяет полноценную схему сбора. Он помогает найти пробелы до следующего инцидента. Особое внимание нужно уделить сроку хранения и защите самих журналов.
Что сделать сейчас: составьте карту источников. Для каждого журнала укажите владельца, срок хранения, полноту и возможность поиска за прошлый период.
🎯 Где именно SOC мог пропустить сигнал
SOC (центр мониторинга безопасности) работает не только с технологиями. Аналитик получает уже отфильтрованные события. Если правило слишком узкое, часть активности не попадает в очередь.
В этом случае подозрительные действия могли выглядеть привычно. SMB-подключение похоже на работу администратора. Планировщик заданий используется для обслуживания. Именованный канал может принадлежать обычной программе.
Проблема появляется при отсутствии связки. Новое задание на одном узле, редкий SMB-доступ на втором и изменение службы на третьем узле могут быть частями одной цепочки. По отдельности эти события не всегда вызывают тревогу.
Дополнительный риск создаёт короткое хранение журналов. Если организация ищет следы через несколько лет, старые данные могут отсутствовать. Тогда расследование показывает только поздние этапы кампании.
Типовые пробелы контроля
- неучтённые серверы и рабочие станции;
- неполный сбор событий с конечных устройств;
- отсутствие контроля оперативной памяти;
- разные часовые зоны и неверное время на узлах;
- ложные срабатывания без пересмотра правил;
- отсутствие связи между сетевыми и системными событиями;
- слишком широкие права административных учётных записей.
Это не доказанные причины именно данного пропуска. Это проверяемые гипотезы для разбора работы SOC. Их нельзя подменять утверждением о конкретной ошибке без журналов и материалов расследования.
Что сделать сейчас: возьмите десять старых тревог и проверьте их продолжение. Ищите связанные действия на других узлах, а не только закрывайте исходное событие.
🔐 Как проверить закрепление и перемещение
Проверку нужно начинать с критичных узлов. В первую очередь важны контроллеры домена, централизованные средства управления и другие ресурсы с широкими правами. Именно через них скрытая активность может быстро расшириться.
Для закрепления проверьте изменения служб, заданий, COM-ссылок и поставщиков времени. Сравните конфигурацию с известным эталоном. Отдельно ищите изменения, которые появились без плановой заявки.
Для перемещения проверьте цепочки SMB-соединений. Сопоставьте их с рабочими обязанностями пользователей и администраторов. Редкое соединение между узлами не доказывает атаку, но требует объяснения.
Для удалённого запуска изучите планировщик заданий. Смотрите не только имя задания. Важны создатель, время появления, команда, учётная запись и узел назначения.
Безопасные признаки для поиска
- новые учётные записи или неожиданные изменения прав;
- запуск служб вне окна обслуживания;
- задания планировщика с редким владельцем;
- изменение COM-регистрации без заявки;
- новый поставщик времени для службы W32Time;
- редкие SMB-соединения между рабочими станциями;
- запуск процессов из оперативной памяти без понятного файла;
- связи с инструментами, которые маскируются под защитное ПО.
Такой поиск не требует заранее знать все имена вредоносных модулей. Он опирается на поведение и контекст. Это повышает шанс найти неизвестный компонент.
Что сделать сейчас: выберите критичные узлы и сравните их текущую конфигурацию с утверждённым эталоном. Все необъяснимые изменения передайте на проверку.
🚨 Почему раннее обнаружение меняет последствия
Длительный доступ даёт злоумышленнику время для разведки. Он может изучать структуру сети, искать интересующие системы и проверять способы управления. При этом внешних признаков может быть мало.
С февраля 2026 года StingyBasilisk начала активно расширять присутствие. Этот факт показывает, что спокойный период не обязательно означает прекращение кампании. Группа могла перейти к другой фазе без заметного сбоя.
В выборке расследований 54,1% атак нарушили бизнес-процессы. Причинами становились шифрование, уничтожение данных или остановка критичного сервиса. Эти последствия заметны, но они появляются не в каждой кампании.
Известные признаки APT-группировок обнаружили у 49,3% организаций из той же выборки. Это не означает, что каждая атака имеет узнаваемую метку. Поведенческий поиск остаётся важным даже при отсутствии готового индикатора.
Что сделать сейчас: установите отдельный процесс ретроспективного поиска. Проверяйте старые события после каждой новой находки, а не только текущий день.
🧭 Как проводить расследование без ложной уверенности
Расследование начинается с сохранения данных. Нельзя сразу очищать заражённые узлы. Сначала зафиксируйте состояние памяти, журналы, сетевые сведения и конфигурацию.
Следующий шаг — построение временной шкалы. В неё входят первоначальный подтверждённый след, закрепление, перемещение, сбор данных и обнаружение. Если этап не подтверждён, его отмечают как неизвестный.
Далее специалисты проверяют соседние узлы. Нужно искать похожие задания, службы, COM-изменения и связи SMB. Отдельно сравнивают события на заражённых и контрольных системах.
После этого формируют гипотезы. Например, один агент мог обеспечивать запуск, а другой — управление. Но гипотеза становится выводом только после проверки артефактами.
Что нельзя утверждать без доказательств
- точную дату первоначального проникновения;
- личность оператора или заказчика атаки;
- объём похищенных данных;
- непрерывную активность в течение всех 1398 дней;
- причину пропуска конкретным правилом SOC;
- эксплуатацию уязвимости без подтверждения версии и события.
Такой подход защищает отчёт от преувеличений. Он также помогает руководству понять, какие действия доказаны, а какие требуют дополнительных данных.
Что сделать сейчас: заведите таблицу доказательств. Для каждого вывода укажите источник, время, систему и уровень уверенности.
✅ Как снизить риск повторного пропуска
Начните с инвентаризации. Организация должна знать все узлы, средства защиты и критичные системы. Без полного списка невозможно проверить покрытие мониторинга.
Затем оцените обновление ОС и программного обеспечения. В общей выборке устаревшие ОС и ПО стали причиной успеха атак в 30% случаев. Это не объясняет именно кампанию StingyBasilisk, но показывает устойчивый базовый риск.
Проверьте многофакторную аутентификацию. Её отсутствие указали среди причин успеха атак в 25% случаев. Отдельно проверьте административные учётные записи и их права.
Оцените сегментацию сети. Слабая сегментация стала фактором успеха в 24% случаев. Она не заменяет обнаружение, но ограничивает перемещение между узлами.
После изменений проведите проверку на следы прошлой активности. Ретроспективный анализ нужен даже тогда, когда организация ещё не зафиксировала инцидент. В выборке 20% проектов составлял именно такой анализ.
- уточнить перечень всех узлов;
- проверить сбор журналов и срок хранения;
- включить контроль заданий и служб;
- проверить COM-компоненты и поставщиков времени;
- сопоставить SMB-соединения с ролями пользователей;
- провести поиск старых событий по критичным узлам;
- обновить правила корреляции для связанных действий.
Защита от многолетнего присутствия не строится вокруг одного продукта. Она требует видимости, контекста и регулярной проверки старых данных. Чем раньше SOC связывает слабые сигналы, тем меньше времени остаётся для скрытого расширения.
Что сделать сейчас: назначьте владельца каждого пункта списка и зафиксируйте срок проверки. Невыполненная рекомендация не снижает риск.
📚 Читайте также
- Галлюцинации ИИ в SOC: как проверять тревоги перед реакцией
- Оценка эффективности SOC: ключевые метрики и KPI для руководителя
- Боты захватывают облачный трафик: методы обнаружения и защиты в 2026
- Приказ ФСТЭК №117: новые требования безопасности IT-инфраструктуры — 2026
- Кибербезопасность для операторов промышленных систем: обучение персонала 2026
📖 Термины
EDR · SOC · Threat Hunting · Индикаторы компрометации (IoC) · Инцидент-реагирование