51 секунда - рекордное время lateral movement после initial access, зафиксированное CrowdStrike в Global Threat Report 2025. Среднее по инцидентам - 62 минуты, год назад было 84. На одном из последних threat hunting-проектов я разбирал case, где beacon Cobalt Strike прожил в сети больше недели. SIEM работал, полный набор корреляционных правил - на месте. Но ни одно не сработало. Beacon использовал jitter 40%, HTTPS к легитимному CDN, размер пакетов не выбивался из нормы. Выдала его аномальная периодичность соединений, которую вытащила модель Isolation Forest из Zeek-логов.
Эта история повторяется в каждом втором проекте. Сигнатурные правила ловят известные паттерны. Атакующие уже давно нашли способ работать за пределами известного.
Почему сигнатурные правила пропускают lateral movement и C2-трафик
Под «lateral movement» понимается совокупность методов, используемых хакерами для последовательного продвижения внутри сети с целью поиска ключевых данных и активов, являющихся конечными целями их кампаний.По данным CrowdStrike, 79% атак в 2024 году прошли без malware - атакующие живут на земле (living off the land): PsExec, WMI, PowerShell Remoting, RDP. IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием действительных учётных данных на 71% год к году. Медианное время нахождения злоумышленника в сети до обнаружения - 11 дней (Mandiant M-Trends 2025). Исторический минимум, но для lateral movement даже несколько часов - это полная компрометация домена. Если говорить коротко: хакеры больше не пишут вирусы, а сидят в сети под видом обычных сотрудников неделями, пока не украдут всё ценное.
Почему сигнатурный подход буксует?:
Легитимные инструменты вместо malware. Volt Typhoon (Chinese state-sponsored, 2023–2024) при проникновении в критическую инфраструктуру США использовала Valid Accounts (T1078) и встроенные утилиты ОС, а для initial access - эксплуатацию уязвимостей edge-устройств (CISA AA24-038A). Корреляционное правило на PowerShell не сработает, если PowerShell - штатный инструмент администраторов. Вот и вся проблема.
Credential abuse как основа перемещения. BlackCat/ALPHV при атаке на Change Healthcare в феврале 2024 использовал украденные учётные данные для Remote Services (T1021). Типичные для группировки TTPs: OS Credential Dumping (T1003) → распространение ransomware через PsExec → Data Encrypted for Impact (T1486). Результат - выплата, по неподтверждённым данным СМИ, предположительно около 22 миллионов долларов. Каждый отдельный шаг выглядел как легитимная активность администратора.
Типичная цепочка: Exploit Public-Facing Application (T1190) или фишинг, затем Mimikatz + PsExec для lateral movement, шифрование. Сигнатурные правила на каждый этап по отдельности существуют - но в совокупности создают шум из сотен false positives, в которых тонет реальная атака.
Машинное обучение для обнаружения угроз решает другую задачу: не «совпадает ли паттерн с известной сигнатурой?», а «нормально ли это поведение для этого хоста, пользователя, сегмента сети в это время?».
Признаки lateral movement в сети: feature engineering для ML
Feature engineering - этап, от которого зависит 80% качества модели. Алгоритм вторичен: Isolation Forest на правильных признаках обнаружит lateral movement, а нейросеть на мусорных - нет.
Windows Event Log: ядро признакового пространства
Основной источник данных для обнаружения бокового перемещения в сети - Windows Event Log, обогащённый Sysmon. Ключевые event ID и что из них вытаскивать:Event 4624 (Logon, Type 3 - Network Logon). Каждый lateral movement через SMB, WMI, PsExec генерирует Type 3. Признаки для ML:
- Частота логонов между парой (source_host → target_host) за скользящее окно (час, день)
- Флаг «новая пара» - хосты никогда ранее не взаимодействовали по Type 3
- Время суток - логон в 3:00 от сервисной учётки, которая обычно активна с 09:00 до 18:00
- Количество уникальных target_host для одного source за период (fan-out)
Event 4688 (Process Creation, требуется расширенная политика аудита). Командная строка запуска процесса - критичный признак.
PsExec, wmic /node, powershell -ep bypass -c Invoke-Command - всё фиксируется здесь. Из Sysmon Event 1 извлекаются parent-child цепочки процессов: cmd.exe → powershell.exe → net.exe - типичный паттерн разведки после получения доступа (T1059.003 → T1059.001 → Account/Network Discovery: T1087/T1016).Events 5140/5145 (Network Share Access). Доступ к административным шарам ADMIN$, C$, IPC$ - прямой индикатор Remote Services (T1021). Признаки: доступ к ADMIN$ с хоста, который никогда раньше к нему не обращался.
Модуль BAD в MaxPatrol SIEM 8.0 использует набор ML-моделей, разбитых по типам: process activity, network process activity, access process to local pipe, network share access, network pipe access - и строит risk score на основе комбинации их вердиктов. BAD работает как second opinion: присваивает уровень риска и выдаёт альтернативное мнение, чтобы оператор быстрее принял решение.
Сетевые признаки: поведенческий анализ трафика
Для NTA-систем (PT NAD, Zeek, Suricata) набор признаков другой:- Communication graph features. Строится граф «хост → хост» по сетевым соединениям. Новые рёбра (ранее не наблюдавшиеся пары), всплески степени вершины (один хост внезапно стучится к десятку других), аномальный PageRank - всё это сигналы lateral movement
- Протокольные аномалии. SMB-трафик к хосту, который не файловый сервер. RDP-сессии с сервера к рабочей станции (обычно наоборот). WinRM-соединения от хостов, где PowerShell Remoting не используется штатно
- Объёмные метрики. Соотношение upload/download для пары хостов, средний размер пакетов, количество сессий за период. Для каждого сегмента baseline строится за 2–4 недели, отклонения скорятся
win_security_remote_powershell_session.yml ловит удалённые PowerShell-сессии (T1059) - один из сигналов lateral movement через WinRM. В контексте ML такое правило - не финальный детект, а feature: бинарный признак «обнаружена удалённая PowerShell-сессия» для модели, которая агрегирует десятки подобных сигналов.Обнаружение C2 трафика ML: beacon-анализ и evasion
Обнаружение C2 трафика с помощью ML требует отдельного признакового пространства: здесь работают не столько логи аутентификации, сколько временные ряды сетевых соединений.
Beacon feature extraction: интервалы, jitter, размеры пакетов
C2-агент (Cobalt Strike Beacon, Sliver implant, Havoc demon) периодически обращается к серверу за командами. Даже при sleep 60s + jitter 40% паттерн остаётся статистически отличимым от человеческого трафика. Вот что вытаскиваем:Модель обучается на всём трафике и выделяет destination с аномально регулярным паттерном обращений.
contamination=0.01 - ожидание, что 1% трафика аномальный. Параметр подбирается под конкретную инфраструктуру, дефолт тут просто для старта.Evasion: как C2-фреймворки уходят от ML-детектирования
Атакующие знают про beacon-анализ. Современные C2 предлагают механизмы обхода, и про каждый стоит знать:High jitter. Cobalt Strike позволяет задать jitter до 100%. При sleep 60s и jitter 50% интервал между check-in варьируется от 30 до 90 секунд. При jitter 90% паттерн почти неотличим от случайного. Но coefficient of variation всё равно ниже, чем у реального пользовательского трафика - потому что человек не генерирует запросы с 2 до 6 утра.
Domain fronting и CDN tunneling. Трафик идёт к легитимному домену (cloudfront.net, azureedge.net), реальный destination - C2. JA3/JA3S-fingerprint совпадает с браузерным. Для ML это означает: нельзя полагаться на destination-based features, нужны temporal и volumetric.
Traffic shaping. Sliver и Havoc умеют подстраивать размер пакетов под профиль легитимного приложения. Cobalt Strike Malleable C2 позволяет задать произвольный HTTP-профиль. Следствие: признаки на основе packet size теряют дискриминирующую способность, если атакующий потратил время на профилирование жертвы.
Вывод для feature engineering: одна группа признаков не работает. Нужна комбинация: temporal + volumetric + graph + host-based. Атакующий может обмануть timing-анализ, но одновременно обмануть timing + graph anomaly + host process tree - задача на порядок сложнее.
Модели машинного обучения для обнаружения угроз: выбор алгоритма под сценарий
Алгоритм выбирается под задачу и данные, а не наоборот. Вот decision table, которым я пользуюсь в реальных проектах:| Сценарий | Алгоритм | Тип обучения | Данные | Когда работает |
|---|---|---|---|---|
| Beacon-детекция | Isolation Forest | Unsupervised | Zeek conn.log, NetFlow | Без размеченных данных, подходит для cold start |
| Аномальные аутентификации (LM) | One-Class SVM / Autoencoder | Unsupervised | Windows Event 4624, 4648 | Когда есть стабильный baseline 2–4 недели |
| Классификация LOTL-команд | Random Forest, Gradient Boosting | Supervised | Sysmon Event 1, командные строки | Нужны размеченные данные (Atomic Red Team, purple team) |
| Граф-аномалии | Community Detection, PageRank delta | Unsupervised | Communication graph (хост→хост) | Выявляет новые пути, работает на large-scale сетях |
| Мультимодальное детектирование | Stacking (IF + RF + graph score) | Ensemble | Все вышеперечисленные | Максимальная точность, но сложнее в поддержке |
Supervised vs unsupervised - выбор, который определяет всё. Для lateral movement detection SIEM-средами unsupervised предпочтительнее: разметка атак в production-логах - дорого и неполно. Supervised модели хороши, когда есть данные purple team / Atomic Red Team (в репозитории доступны тесты для T1003 OS Credential Dumping: Gsecdump, NPPSpy, дамп svchost.exe). Прогнали тесты - получили размеченные события - обучили классификатор.
Isolation Forest я использую как первый этаж: вычисляет метрики для всех пар хост→хост, аномальные передаются на второй этаж - Random Forest с фичами из командных строк и process tree (требует размеченных данных, например из Atomic Red Team). Не требует нормализации, устойчив к выбросам, обучается быстро. Для первичного скоринга - самое то.
Autoencoder - вариант для тех, у кого GPU и данные для обучения. Reconstruction error как anomaly score хорошо работает для высокоразмерных данных (десятки признаков одновременно). Но для SOC-команды без ML-инженера - избыточная сложность. Я бы не рекомендовал начинать с него.
Интеграция ML с SIEM системами: практический pipeline
Требования к окружению
- SIEM: MaxPatrol SIEM 8.0+ (встроенный BAD) / Elastic 8.x с ML-jobs / Splunk Enterprise с MLTK
- ML-pipeline: Python 3.10+, scikit-learn 1.3+, pandas, numpy
- Источники логов: Windows Event Forwarding (WEF) или Sysmon, Zeek / Suricata
- Hardware для обучения: 16 ГБ RAM минимум для датасетов до 10M событий, 32 ГБ рекомендуется
- OS: Ubuntu 22.04 / Windows Server 2019+ для сбора и пересылки логов
Pipeline: от логов до алерта
Архитектура ML-обогащённого детектирования:- Сбор - Windows Event Forwarding / Sysmon → SIEM (нормализация, обогащение)
- Feature extraction - scheduled job: раз в час агрегирует признаки по парам хост→хост, user→host
- Scoring - ML-модель присваивает anomaly score каждой паре
- Корреляция - score > threshold + срабатывание Sigma-правила = инцидент с повышенным приоритетом
- Feedback loop - false positives размечаются аналитиком и уходят в retrain
Для Elastic или Splunk pipeline строится руками. Пример KQL-запроса для Microsoft Sentinel - ищем аномальный fan-out по Type 3 логонам:
Код:
SecurityEvent
| where EventID == 4624 and LogonType == "3"
| where IpAddress !in ('-', '::1', '127.0.0.1')
| summarize logon_count = count(),
unique_targets = dcount(Computer),
first_seen = min(TimeGenerated)
by TargetUserName, IpAddress
| where unique_targets > 5 and first_seen > ago(24h)
| order by unique_targets desc> 5 - стартовый. В SOC с 500 хостами администратор может штатно аутентифицироваться на 15–20 серверах - порог поднимается. Но учётная запись рядового пользователя на 6 хостах за сутки - уже аномалия.Для детектирования командного трафика C2 через anomaly detection lateral movement в Elastic создаются ML-jobs на основе метрик сетевого потока: rare destination IP + unusual connection frequency + anomalous packet sizes. Elastic ML использует unsupervised anomaly detection с автоматическим построением baseline - ближайший аналог Isolation Forest, но без прямого контроля над feature engineering.
В Splunk MLTK можно загрузить собственную модель scikit-learn через
fit и apply SPL-команды. Это даёт полный контроль: обучаете модель на исторических данных, деплоите как saved search, результат - новое поле anomaly_score в каждом событии. Из трёх вариантов - максимальная гибкость, но и стоимость лицензии на объём данных соответствующая.Что ML-модель не поймает: ограничения и слепые зоны
False positives в реальной инфраструктуре. В корпоративной сети с Active Directory доменные контроллеры, SCCM-серверы, системы мониторинга штатно генерируют паттерны, неотличимые от lateral movement: массовые Type 3 логоны, обращения к ADMIN$, запуск WMI-запросов. Без качественного baseline (минимум 2–4 недели спокойной работы) модель утонет в false positives. MaxPatrol SIEM BAD решает это комбинацией ML-вердиктов и корреляционных правил - одно событие интерпретируется двумя методами, оператор видит оба мнения.
Adversarial ML. Атакующие, знающие про ML-детекцию, адаптируют поведение. Модель обучена на частоте обращений - атакующий снижает частоту. Модель ловит graph anomaly - атакующий работает через уже существующие коммуникационные пути (compromised admin workstation → серверы, с которыми она и так взаимодействует). Защита - мультимодальность: комбинация temporal, volumetric, graph и endpoint-признаков. Обмануть все одновременно - задача совсем другого уровня.
Drift. Инфраструктура меняется: новые серверы, миграция приложений, смена штатного расписания. Модель деградирует - сроки зависят от темпа изменений в конкретной среде. Автоматический retrain с валидацией - обязательный компонент pipeline. Без него через пару месяцев получите либо поток false positives, либо пропуски.
Вендор-специфика. MaxPatrol SIEM 8.0 с BAD даёт ML из коробки, но привязывает к экосистеме Positive Technologies. Elastic 8.x с ML-jobs проще кастомизировать, но feature engineering - ваша забота. Splunk MLTK даёт максимальную гибкость (загрузка sklearn-моделей), но стоимость лицензии на объём данных отсекает средние компании. Выбор определяется не «какой алгоритм лучше», а какой pipeline команда способна поддерживать.
D3FEND описывает контрмеры для тактик lateral movement: Access Modeling (D3-AM) и Domain Account Monitoring (D3-DAM) для Valid Accounts (T1078), Protocol Metadata Anomaly Detection (D3-PMAD) для сетевых аномалий. Полезная таксономия для маппинга «что мы покрываем, а что нет». Но между D3FEND-категорией и рабочей моделью в production - месяцы feature engineering и настройки.
Ознакомиться со списком: MITRE D3FEND Knowledge Graph
Формула на бумаге понятна: собрал признаки, обучил Isolation Forest, задеплоил в SIEM. Но decay модели по-настоящему ощущается только когда сам прогоняешь на живых данных. Готовый стенд с CTF-задачами по анализу трафика и threat hunting есть на HackerLab.pro - там в категориях forensics и network можно разобрать PCAP-дампы с реальными паттернами C2 и lateral movement.
Главная проблема внедрения ML в detection engineering - не алгоритмы. Scikit-learn и Isolation Forest доступны любому аналитику с базовым Python. Проблема - в системном мышлении. Я вижу SOC-команды, которые покупают платформу с ML-модулем, включают его и ждут, что «машинное обучение всё обнаружит». Через месяц - 200 алертов в день, из которых 195 мусорные. Модуль выключают, возвращаются к ручным правилам.
Это не провал технологии, это провал процесса. ML работает, когда инженер понимает, какие признаки важны для конкретной инфраструктуры, строит baseline на чистых данных, калибрует пороги и регулярно переобучает модель. В ближайшие год-два разрыв между «SOC с ML-инженером в штате» и «SOC без него» будет расти. Группировки типа Volt Typhoon работают исключительно через LOTL - сигнатурный подход против них мёртв. Качественный поведенческий анализ сетевого трафика и хостовых логов требует не подписки на вендорский модуль, а трёх-четырёх месяцев грязной работы с данными. Те команды, которые эту работу сделают, будут ловить beacon за часы, а не за 11 дней.
Последнее редактирование модератором:
