Ищем lateral movement нейросетью, обученной на синтетических данных
Можно ли обучить детектор атак, не показывая ему ни одной настоящей атаки? На первый взгляд задача выглядит противоречиво: если нейросеть должна обнаруживать боковое перемещение злоумышленника по инфраструктуре, ей вроде бы необходимо заранее увидеть примеры такого поведения. Однако эксперимент с полностью синтетическими данными показал, что это не обязательное условие.
Я сгенерировал корпоративную сеть, описал историю входов пользователей и устройств, добавил сценарий атаки, а затем обучил классификаторы только на полученных искусственных событиях. В обучающей выборке не было ни одной реальной строки. После этого модели проверили на журналах аутентификации Лос-Аламосской национальной лаборатории объёмом около 1,65 млрд событий. В данных присутствовали размеченные эпизоды учений красной команды.
Результат оказался неожиданно практичным. Набор из шести небольших сетей, каждая примерно на 4000 параметров, распределил около 3,6 млн временных окон по уровню подозрительности. В первых 23 позициях оказалось 16 настоящих атак и семь ложных срабатываний. Для сравнения: простой пороговый счётчик должен был бы породить примерно 161 тысячу ложных тревог, чтобы добраться до шестнадцатого реального эпизода.
Что такое lateral movement
Боковое перемещение - это этап атаки, на котором злоумышленник уже получил первоначальный доступ и начинает двигаться внутри сети. Он пытается использовать украденные учётные данные, найти привилегированные системы, подключиться к серверам и постепенно расширить контроль над инфраструктурой.
Такой сценарий не обязательно выглядит как взлом в привычном смысле. Пароли могут не подбираться, вредоносный файл может не запускаться, а соединения будут проходить через штатные протоколы и легитимные учётные записи. С точки зрения отдельных событий пользователь просто вошёл на другой компьютер. Подозрительным становится не одно действие, а последовательность связей.
Именно поэтому обнаружение lateral movement сложно формализовать. Организация может насчитывать тысячи машин и десятки тысяч пользователей. Обычные сотрудники регулярно подключаются к нескольким серверам, администраторы - к сотням систем, а автоматические службы создают большое количество повторяющихся соединений. Детектору нужно отличать необычную, но легальную активность от цепочки действий атакующего.
Почему имя пользователя почти бесполезно
Наивная модель может запомнить, какие учётные записи чаще участвуют в атаках. Но это быстро приводит к ошибке. Имя аккаунта само по себе не содержит достаточного сигнала: атакующий может использовать скомпрометированную учётную запись обычного сотрудника, а легитимный администратор способен выполнять действия, похожие на поведение злоумышленника.
Гораздо информативнее вопрос, с какого устройства и на какое устройство происходит вход. Если учётная запись неожиданно появляется на машине, с которой прежде не связывалась, это уже признак изменения поведения. Главный сигнал - не личность пользователя, а новизна связи в контексте конкретного окружения.
Для каждого окна времени можно оценивать, насколько привычны связи "пользователь - компьютер", "компьютер - компьютер" и "учётная запись - сервис". Новая связь не доказывает атаку, но позволяет расставить приоритеты для аналитика.
Синтетический корпоративный мир
Вся искусственная среда описывалась конфигурацией примерно на 135 строк. В ней задавались пользователи, рабочие станции, серверы, типичные маршруты входов, частота событий и сценарий бокового перемещения.
Генератор создавал не просто случайную таблицу. Он моделировал историю поведения: кто обычно работает с конкретной машиной, какие устройства взаимодействуют друг с другом, какие соединения возникают регулярно, а какие появляются только во время атаки. Это принципиально важнее, чем обычная подстановка выдуманных имён в готовый шаблон.
Для повышения устойчивости были созданы шесть разных виртуальных миров. Каждый из них имел собственную структуру сети и собственные параметры активности. На каждом мире обучалась отдельная небольшая модель. Такой подход снижает зависимость от одного конкретного набора допущений.
Экспериментальная проверка
Перед запуском на настоящих данных был проведён "экзамен" на отложенных синтетических наборах. Это правило оказалось одним из самых полезных: сначала модель должна пройти проверку на данных, которые не использовались при обучении, и лишь затем её можно выпускать на реальную инфраструктуру.
Без такого этапа легко принять запоминание генератора за обобщение. Модель может прекрасно распознавать особенности конкретного искусственного мира, но полностью потеряться при изменении схемы сети. Отложенный тест четыре раза показал отрицательный результат и заставил пересмотреть генератор и признаки.
Одной из самых дорогих ошибок оказался неправильный способ подсчёта связей. Простое количество соединений оказалось уязвимым к топологии сети: устройство, через которое проходит много легитимного трафика, автоматически выглядело подозрительным. После этого основной акцент перенесли на новизну и редкость конкретных связей.
Первый результат на реальных журналах
После обучения на шести синтетических мирах модели применили к журналам Лос-Аламосской лаборатории. События группировались во временные окна, после чего каждому окну присваивалась оценка подозрительности.
В верхней части списка оказались реальные эпизоды красной команды. Это не означает, что синтетические данные полностью воспроизвели конкретную инфраструктуру лаборатории. Модели не знали её имён, организационной структуры и точных рабочих процессов. Они уловили более общий принцип: атакующий создаёт необычные связи между учётными записями и системами.
По показателю AUC результат попал в диапазон ряда исследовательских работ, обучавшихся на размеченных реальных данных. Однако прямое сравнение некорректно: отличаются наборы признаков, правила разметки, размеры выборок и сценарии атак. Кроме того, AUC плохо отражает работу аналитика, которому важнее первые десятки результатов, а не среднее качество на всём диапазоне порогов.
Почему AUC может вводить в заблуждение
В задачах кибербезопасности положительных событий крайне мало. Детектор способен показывать высокий AUC, одновременно создавая огромное количество ложных тревог в верхней части списка. Для операционного применения важнее precision at top-k, среднее число ложных срабатываний до обнаружения атаки и доля реальных инцидентов среди первых результатов.
Иными словами, специалисту не нужен абстрактно хороший классификатор. Ему нужен список, который можно просмотреть за рабочую смену. Если среди первых 20 строк находятся 16 атак, система полезна даже при несовершенной общей метрике.
Проблема "ножниц опоры"
Для выявления новизны нужна опора - представление о том, какие связи считаются обычными. Но если строить её на текущем потоке данных, сама атака начинает загрязнять эталон. Повторяющиеся действия злоумышленника постепенно превращаются в "норму", и детектор теряет чувствительность.
Возникает компромисс. Замороженная опора защищена от отравления, но со временем устаревает: пользователи меняют рабочие места, появляются новые серверы и легитимные маршруты. Динамическая опора адаптируется к инфраструктуре, однако рискует включить атаку в нормальный профиль.
Практическим решением может стать раздельное обновление базовой модели и оперативного слоя, а также карантин для новых связей. Связи, появившиеся во время подозрительной активности, не должны автоматически попадать в эталон поведения.
Контрольный прогон и пересмотр вывода
В одном из экспериментов казалось, что шесть сетей дают устойчивое преимущество благодаря разнообразию миров. Но контрольный прогон показал: часть улучшения объяснялась не ансамблем как таковым, а конкретными настройками генерации.
Это стало важным напоминанием: красивое объяснение результата необходимо проверять дополнительными экспериментами. В работе с синтетическими данными особенно легко принять свойства генератора за свойства реального мира.
Показательный пример - разреженная сеть. В корпоративной инфраструктуре далеко не каждый пользователь связан с каждым компьютером. Поэтому модели, которые учитывают редкость и внезапное появление связей, часто оказываются полезнее, чем универсальные архитектуры с большим числом параметров.
Микропетля для развития генератора
Самый ценный результат эксперимента - не одна цифра качества, а короткий цикл улучшения:
1. модель ошибается на конкретной машине;
2. анализ показывает, какого явления нет в синтетическом мире;
3. в конфигурацию добавляются одна-две строки;
4. генератор создаёт более реалистичные сценарии;
5. ошибка уменьшается при повторной проверке.
Так синтетические данные превращаются не в замену реальности, а в инструмент диагностики. Ошибка модели помогает понять, каких закономерностей не хватает в описании среды.
Можно ли внедрять такой подход
Синтетическая модель не должна единолично блокировать учётные записи или завершать сетевые сессии. Её разумнее использовать как механизм приоритизации: она сортирует окна событий, чтобы аналитик начинал проверку с наиболее подозрительных.
Перед внедрением потребуются калибровка на конкретной инфраструктуре, контроль дрейфа поведения, оценка количества тревог и регулярные проверки на новых сценариях атак. Важно также сохранять объяснимость: специалист должен видеть, какая новая связь или изменение маршрута повлияло на оценку.
Метод особенно полезен там, где мало размеченных инцидентов, действуют ограничения на использование реальных журналов или требуется быстро подготовить тестовую среду. При этом синтетический генератор нужно развивать вместе с системой обнаружения, а не считать готовым раз и навсегда.
Что не сработало
Не дали ожидаемого эффекта попытки опираться на одни только имена учётных записей, грубые счётчики входов и слишком простые признаки общей активности устройства. Неудачным оказался и подход, при котором модель обучалась на одном-единственном искусственном мире.
Проблемы возникали, когда генератор создавал слишком "чистые" данные. Реальная инфраструктура содержит шум, сезонность, редкие административные операции, смену ролей и неполные журналы. Если не моделировать эти особенности, детектор учится отличать синтетику от реальности, а не атаку от нормальной работы.
Пять практических правил
1. Сначала проверять модель на отложенных синтетических данных, затем - на реальных журналах.
2. Оценивать не только AUC, но и качество первых результатов в списке.
3. Искать новизну связей, а не доверять имени пользователя или числу событий.
4. Не позволять подозрительной активности незаметно отравлять эталон поведения.
5. Использовать ошибки детектора для расширения генератора и уточнения сценариев.
Главный вывод эксперимента состоит не в том, что настоящие данные больше не нужны. Синтетика не отменяет реальность и не гарантирует чудесного качества. Но правильно построенный искусственный мир способен передать общую структуру поведения атаки, помочь обучить компактную модель и показать, где именно не хватает знаний о среде.
В случае lateral movement этого оказалось достаточно, чтобы превратить миллиарды событий в небольшой список, пригодный для ручной проверки. А главное - появилась воспроизводимая методика, в которой генератор, модель и реальные журналы образуют замкнутый цикл улучшения.