На проверке Анализ логов для SOC: поиск индикаторов компрометации руками и через SIEM

[Сергей Попов]

Понедельник, 9:15 утра. На дашборде SIEM висит непросмотренный алерт: сетевой вход (Logon Type 3) под учёткой admin_backup в 02:15 по Москве. Аутентификация - NTLM, не Kerberos. Повышенные привилегии выданы сразу после логина. За восемь минут до успешного входа - пять неудачных попыток с того же хоста. Выглядит как банальный brute-force с результатом. Но admin_backup - сервисная учётка для резервного копирования, она не логинится интерактивно вообще. Никогда. В baseline этого нет.

Разбор алерта затронул три источника логов и занял четыре часа. Ниже - пошаговый ход расследования: что проверять руками, какие запросы писать в SIEM и как отличить true positive от шума.

IOC и IOA: что именно ищет аналитик в логах​

Прежде чем открывать Event Viewer или строить SPL-запрос, стоит определиться: мы ищем след уже произошедшей компрометации (IOC) или ловим атаку в процессе (IOA)?

Индикаторы компрометации (IOC) - артефакты после вторжения: хеш вредоносного файла, IP-адрес C2-сервера, ключ реестра для persistence. В сценарии с валидными учётными данными классические IOC бесполезны - атакующий использует легитимные credentials и файловых следов не оставляет.

Индикаторы атаки (IOA) - поведенческие паттерны: серия неудачных входов за минуту, сетевой логин сервисной учётки в нерабочие часы, запуск cmd.exe из-под процесса Word (T1059.003 - Windows Command Shell). IOA ловят атаку в процессе, IOC подтверждают её постфактум.

Pyramid of Pain, предложенная Дэвидом Бьянко (описана, в частности, в документации Splunk), хорошо объясняет разницу: чем выше по пирамиде (от хешей к TTPs), тем больнее атакующему менять свои индикаторы. Хеш файла - перекомпилировал бинарь, готово. IP-адрес C2 - минута через CDN. А вот TTPs (тактики и техники из MITRE ATT&CK) изменить радикально сложнее: придётся перестроить всю цепочку атаки. Поэтому IOA-подход, сфокусированный на поведении, а не на статических артефактах, бьёт точнее - особенно когда credential-based атаки растут на 71% год к году (IBM X-Force Threat Intelligence Index 2025).

По данным Mandiant M-Trends 2024 Special Report (цитируется hunt.io), глобальная медиана dwell time - от проникновения до обнаружения - сократилась с 16 дней в 2022 до 10 в 2023. Прогресс есть. Но 10 дней - это всё ещё огромное окно для атакующего, который уже внутри.

Выявление угроз в логах вручную: три источника для 80% кейсов​

Предусловия и ограничения​

Методы ниже рассчитаны на Windows 10/11 и Server 2016+ с включённым расширенным аудитом (Advanced Audit Policy), Linux-системы с rsyslog или systemd-journald и актуальной конфигурацией auth.log. Если аудит не настроен (Event ID 4624/4625 не логируются) - ни ручной анализ, ни SIEM не помогут. Первый шаг всегда - проверка политики: auditpol /get /category:* на Windows, cat /etc/rsyslog.conf на Linux. Без этого всё дальнейшее - работа вслепую. Это прямо соответствует OWASP A09:2021 (Security Logging and Monitoring Failures): нет логов - нет детекта.

Windows Event Log - ключевые Event ID для расследования инцидентов​

В среде Active Directory Windows Security Log - основной источник. Четыре Event ID покрывают начальный триаж:

• 4624 (успешный вход) - Logon Type определяет вектор: 2 = интерактивный, 3 = сетевой (SMB, WMI, PsExec), 10 = RDP. Поле AuthenticationPackageName показывает, NTLM (потенциально pass-the-hash) или Kerberos.
• 4625 (неудачный вход) - серия из 5+ событий за минуту с одного Source Network Address = brute-force. Одна-две попытки на учётку с перебором разных TargetUserName = password spray.
• 4672 (назначение специальных привилегий) - если всплывает сразу после 4624, а учётка не в списке ожидаемых администраторов - красный флаг.
• 4688 (создание процесса) - с включённым Command Line Logging показывает, что именно запустил атакующий после входа: whoami, net group "Domain Admins", cmdkey (последний входит в каталог LOLBAS как инструмент для работы с credentials, привязанный к T1078).

Для ручного анализа в PowerShell - когда SIEM недоступен или нужно верифицировать алерт прямо на хосте:

Get-WinEvent -FilterHashtable @{
  LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-24)
} | Where-Object {
  $_.Properties[8].Value -eq 3 -and
  $_.Properties[14].Value -eq 'NTLM'
} | Select-Object TimeCreated,
  @{N='User';E={$_.Properties[5].Value}},
  @{N='SourceIP';E={$_.Properties[18].Value}}
# ВАЖНО: индексы Properties[] (8, 14 и др.) зависят от версии и сборки Windows.
# Перед использованием ОБЯЗАТЕЛЬНО проверьте реальную раскладку полей через $Event.ToXml()
# и скорректируйте индексы - в вашей среде они могут отличаться.

Запрос вытащит все сетевые NTLM-входы за последние 24 часа - именно то, что сопровождает lateral movement через Valid Accounts (T1078).

Поиск IOC в логах Linux: grep-конвейер для быстрого триажа​

На Linux-серверах auth.log (или /var/log/secure на RHEL/CentOS) - первое место для проверки. Три конвейера, которые я запускаю при любом подозрении:

Топ-10 IP по brute-force (GNU grep, стандартный для Ubuntu/Debian/RHEL; \b - GNU-расширение, не входит в POSIX ERE): grep "Failed password" /var/log/auth.log | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq -c | sort -rn | head -10.

Успешный вход после серии неудач (паттерн «взлом состоялся»): grep -E "Failed password|Accepted" /var/log/auth.log | grep -B5 "Accepted" - контекст из пяти строк перед каждым успешным входом покажет, была ли перед ним серия отказов.

Нетипичные sudo-команды: grep "sudo:" /var/log/auth.log | grep "COMMAND" | grep -vE "(systemctl|service|apt-get|yum)" | tail -20 - всё, что выходит за рамки типового администрирования.

Если auth.log ротирован или очищен, а journalctl --since "24 hours ago" --unit sshd тоже пуст - это само по себе IOC. Атакующие нередко чистят логи после закрепления (Defense Evasion по MITRE ATT&CK). Пустой лог - не отсутствие событий, а след того, кто их стёр.

Мониторинг событий безопасности на периметре: веб-логи​

Nginx access.log и IIS-логи - вторая линия, когда подозрение касается начального вектора через веб. Ключевые паттерны:

• Массовые 404 с одного IP - фаззинг или directory enumeration. В nginx (при дефолтном log_format combined; при кастомном формате номер поля проверяйте через head -1 access.log): awk '$9 == 404 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -5.
• 200 OK на чувствительных путях (/admin, /api/v1/users) - потенциальный несанкционированный доступ.
• Подозрительные User-Agent - строки sqlmap, nikto, dirsearch. Но профессиональный атакующий подделает UA под обычный Chrome - полагаться только на это нельзя.

Формат IIS отличается от nginx: IP сервера идёт первым, IP клиента - дальше по строке. Путаница между ними при ручном разборе - распространённая ошибка. Видел, как аналитик двадцать минут разбирал «атаку» с 127.0.0.1, потому что перепутал колонки.

Корреляция событий в SIEM: от алерта до расследования инцидентов ИБ​

Ручной разбор хорош для верификации, но расследование lateral movement требует корреляции событий из разных источников. Тут без SIEM никуда.

Сценарий: threat hunting в SOC при lateral movement через Valid Accounts​

Бизнес-логика атаки: злоумышленник получил действительные учётные данные (фишинг, дамп из утёкшей базы, Kerberoasting) и использует их для перемещения по сети. Финальная цель - файловый сервер с конфиденциальными данными или контроллер домена. Никакого malware, никаких хешей для детекта - только легитимные credentials. Именно поэтому этот сценарий так тяжело ловить: каждое отдельное событие выглядит нормально.

Цепочка событий, которую ищем в SIEM:

1. Initial Access: Event ID 4625 (серия неудачных входов) → 4624 (Type 3, NTLM) с нетипичного Source IP в нерабочие часы.
2. Privilege Escalation: Event ID 4672 (назначение привилегий) → 4688 (запуск whoami, net group "Domain Admins", cmdkey).
3. Lateral Movement: Event ID 4624 (Type 3) на соседних хостах с тем же TargetUserName, но с нового Source IP - хоста, скомпрометированного на предыдущем шаге.

В SPL (Splunk) базовый запрос для обнаружения NTLM-логинов сервисных учёток в нерабочие часы:

index=wineventlog EventCode=4624 Logon_Type=3
  Authentication_Package=NTLM
  Account_Name IN ("admin_backup","svc_*","sql_*")
| where date_hour < 7 OR date_hour > 20
| stats count by Account_Name, Source_Network_Address, _time
| where count > 1

Для KQL (Elastic/Kibana) эквивалент строится через event.code: "4624" AND winlog.event_data.LogonType: "3" AND winlog.event_data.AuthenticationPackageName: "NTLM" с фильтром по @timestamp.

Sigma-правила корреляции как стартовая точка​

Sigma - универсальный формат detection-правил, который конвертируется в SPL, KQL, запросы MaxPatrol SIEM и других платформ. В репозитории SigmaHQ по тегу T1078 (Valid Accounts) доступно 11 правил, включая azure_ad_account_signin_outside_hours.yml (детект входа в нерабочее время) и azure_ad_user_added_to_admin_role.yml (добавление пользователя в административную роль). По тегу T1098 (Account Manipulation) - 45 правил, среди которых win_security_account_manipulation.yml для Windows.

Sigma-правила - не готовый к продакшену детект, а отправная точка. Каждое нужно адаптировать: добавить исключения для легитимных сервисных учёток, скорректировать временные окна под график организации, протестировать на false positive rate. На практике Sigma-правило без тюнинга генерирует такой поток ложных срабатываний, что L1-аналитики начинают закрывать алерты не глядя. А реальный инцидент тонет в этом шуме.

Detection-чеклист при подозрении на компрометацию​

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

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

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

Защитные меры: D3FEND countermeasures для анализа логов SIEM​

MITRE D3FEND предлагает конкретные защитные техники, привязанные к ATT&CK. Для Valid Accounts (T1078):

• D3-LAM (Local Account Monitoring) - мониторинг локальных учёток. На практике: алерт на любой интерактивный логин под локальной учёткой на доменной машине.
• D3-AL (Account Locking) - блокировка после N неудачных попыток. Стандартная GPO-политика. Проблема в том, что при password spray атакующий делает 1-2 попытки на учётку и не превышает порог. Так что блокировка - необходимый минимум, но не панацея.
• D3-AM (Access Modeling) - построение модели нормального доступа (baseline). Без baseline любой алерт превращается в шум: аналитик не знает, что «нормально» для этой учётки, и либо закрывает всё подряд, либо эскалирует всё подряд.

Для Account Manipulation (T1098):

• D3-DUC (Decoy User Credential) - приманки. Honey-аккаунты в AD, которые никто не должен использовать. Создаёте учётку admin_exchange2, добавляете в привилегированную группу, но не используете нигде. Любой Event ID 4624 с этим TargetUserName - гарантированный true positive с нулевым false positive rate. Ноль. Вот это я называю чистый детект.
• D3-CCSA (Credential Compromise Scope Analysis) - оценка масштаба компрометации. Когда подтвердили компрометацию одной учётки, проверяете, где ещё она использовалась: Kerberos ticket delegation, saved credentials, RDP-сессии.

Тот алерт с понедельника, с которого всё началось, оказался true positive. Учётка admin_backup была скомпрометирована через фишинговое письмо неделей ранее. Атакующий выжидал выходные, чтобы провести разведку без риска попасть под взгляд дежурного аналитика. Lateral movement остановили на третьем хосте - корреляционное правило связало NTLM-логин в нерабочие часы с последующим запуском net group "Domain Admins" через Event ID 4688. Без этого правила инцидент обнаружили бы утром, когда атакующий уже дошёл бы до контроллера домена.

Вывод, который подтверждается каждым разбором: одиночный лог не значит ничего. Event ID 4624 сам по себе - информационное событие, их тысячи в минуту. Только корреляция (4625 → 4624 + NTLM + нерабочие часы + 4672 + 4688 с reconnaissance-командами) превращает шум в сигнал.

Анализ логов для SOC - не про конкретный инструмент. Splunk, Elastic, MaxPatrol SIEM - каждый решает задачу, если аналитик умеет строить гипотезу и проверять её последовательно. Sigma-правила дают стартовую точку, но без тюнинга под среду - исключения сервисных учёток, временные окна, baseline нормального поведения - они генерируют сотни алертов, которые L1 закрывает как false positive, пока реальный инцидент тонет в потоке.

Honey-аккаунты решают эту проблему для credential-based атак - ноль false positives. Часто слышу возражение: «лишняя нагрузка» и «AD и так сложный». Между тем именно эта техника дала бы чистый алерт в кейсе с admin_backup без единого корреляционного правила. Если интересно, как другие команды выстраивают detection-логику под lateral movement и тюнят Sigma-правила под свой стек, - на codeby.net ведётся тред с разбором свежих кейсов и адаптацией правил под разные SIEM.