Тестовое задание SOC-аналитик L2 — разбираю реальный кейс и показываю разницу с L1

За последний год я провёл двенадцать собеседований на позицию SOC-аналитика второй линии. Восемь кандидатов пришли с первой линии — уверены, что готовы к повышению. Четверо завалились на тестовом задании. Не потому что не знали теорию. Потому что разбирали инцидент так, как привыкли на L1: увидели алерт, проверили IP, написали «заблокировано», закрыли тикет. Тестовое задание SOC-аналитика L2 проверяет другое — способность построить цепочку атаки и объяснить, что произошло до и после алерта. Ниже — конкретный кейс, ответ уровня L1, ожидаемый ответ L2 и упражнения для подготовки.

Что проверяет тестовое задание SOC-аналитика L2

Тестовое задание для L1 и L2 может начинаться с одного и того же алерта из SIEM (Security Information and Event Management — система, которая собирает логи со всей инфраструктуры и ищет подозрительные паттерны). Разница — в глубине, на которую кандидат копает.

Первая линия (L1) — триаж: первичная сортировка алертов. Увидел оповещение, проверил базовые индикаторы, решил — ложное срабатывание или эскалация наверх. Хороший L1 делает это быстро и точно.

Вторая линия (L2) — расследование. L2 берёт эскалированный алерт и разворачивает его в полную картину: что произошло до, что после, какие хосты затронуты, каким путём атакующий двигался по сети. Результат работы L2 — не тикет «заблокировано», а таймлайн инцидента с оценкой масштаба и рекомендациями по сдерживанию.

Самая частая причина отказа кандидатам на SOC L2 — неспособность провести walk-through расследование. Показать ход мысли от алерта до заключения, а не перечислить определения из учебника.

Вот конкретный кейс из тестового задания. Разберём его шаг за шагом.

Разбор тестового задания SOC L2 — от алерта до таймлайна

Исходные данные — что получает кандидат

Кандидату выдают лог алерта и набор связанных событий. Легенда задания:

Пятница, 17:42 MSK. SIEM сгенерировал алерт: «PowerShell — подозрительная кодированная команда» на хосте WKS-FIN-012 (рабочая станция финансового отдела). Источник — событие Windows Event ID 4688 (создание нового процесса) с командной строкой, содержащей флаг -EncodedCommand. За 30 минут до алерта — событие 4624 (успешный вход) на том же хосте, тип входа 10 (RDP — удалённый рабочий стол). IP источника входа: 10.15.3.47 (внутренний, принадлежит VPN-пулу). Учётная запись: d.petrov (рядовой сотрудник, без админ-прав).

Дополнительные данные: — Выгрузка событий с хоста WKS-FIN-012 за последние 2 часа (Event ID 4624, 4625, 4688, 4672) — Логи VPN-шлюза: d.petrov подключился к VPN в 17:08 с IP 185.47.XX.XX (геолокация — страна, не совпадающая с расположением офиса) — Логи прокси: с WKS-FIN-012 в 17:48 зафиксирован HTTP POST на внешний домен, не входящий в корпоративный white-лист

Задание: опиши ход расследования, построй таймлайн и предложи меры реагирования.

Ответ уровня L1 — формальный и неполный

Типичный ответ кандидата, который мыслит как первая линия:

«PowerShell с -EncodedCommand — подозрительно. Проверил IP 185.47.XX.XX на VirusTotal — чистый. Учётная запись d.petrov — рядовой сотрудник. Рекомендация: заблокировать учётную запись, переустановить рабочую станцию. Эскалировать на L2.»

Что здесь не так:

• Нет таймлайна. События не выстроены хронологически, связь между VPN-входом, RDP и PowerShell не установлена
• «Эскалировать на L2» — но кандидат претендует на L2. Задание проверяет, умеет ли он быть тем, на кого эскалируют
• VirusTotal по IP — формальная проверка без анализа контекста. Почему d.petrov зашёл по VPN из другой страны в пятницу вечером? Этот вопрос даже не задан
• Нет попытки декодировать -EncodedCommand — значит, неизвестно, что именно выполнялось
• Нет оценки масштаба: затронут только этот хост или атакующий уже на других машинах?

Такой ответ закрывает тикет, но не расследует инцидент. Для L1 — допустимо. Для L2 — отказ.

Разбор инцидента на уровне SOC L2 — строим таймлайн

Вот что ожидает интервьюер от кандидата на вторую линию.

Шаг 1. Хронология событий.

Теперь по каждому событию — маппинг на MITRE ATT&CK (открытая база тактик и техник атак; каждой технике присвоен T-код — например, T1059.001 означает «Command and Scripting Interpreter: PowerShell»):

Initial Access (17:08): T1078 (Valid Accounts) — атакующий использует легитимные украденные учётные данные для VPN-подключения. VPN-вход из нетипичной локации указывает, что credentials получены ранее — через фишинг, утечку или infostealer.

Lateral Movement (17:12): T1021.001 (Remote Services: RDP) — после получения доступа в сеть через VPN атакующий подключается по RDP к рабочей станции WKS-FIN-012 с внутреннего IP. Между VPN-входом и RDP-сессией — 4 минуты. За это время атакующий должен был определить целевой хост (discovery/enumeration), но эти события в предоставленных логах не отражены.

Execution (17:42): T1059.001 (PowerShell) — событие 4688 с запуском powershell.exe -EncodedCommand. Флаг -EncodedCommand означает, что команда закодирована в Base64. Стандартный приём обфускации — скрыть содержимое от быстрого визуального анализа в логах.

Возможная Exfiltration (T1041) или Command & Control (T1071): HTTP POST на внешний домен через 6 минут после PowerShell — может быть эксфильтрацией данных (T1041 — Exfiltration Over C2 Channel) или C2-коммуникацией (T1071 — Application Layer Protocol). Точнее определить можно после анализа содержимого запроса.

Шаг 2. Оценка масштаба.

L2-аналитик не останавливается на одном хосте. Три вопроса, на которые нужно ответить:

1. Есть ли другие RDP-сессии с IP 10.15.3.47 на другие хосты? Если да — атакующий уже перемещается по сети (lateral movement — движение от одного хоста к следующему после первоначальной компрометации)
2. Есть ли событие 4672 (назначение специальных привилегий) — попытка повышения прав
3. Были ли другие VPN-подключения d.petrov ранее с того же внешнего IP — определить, первый ли это заход или атакующий работает давно

Пример поискового запроса в SIEM (синтаксис Splunk SPL) для проверки латерального движения:

index=wineventlog EventCode=4624 LogonType=10 Source_Network_Address="10.15.3.47"
| stats count by dest_host, Account_Name, _time
| sort -_time

Запрос ищет все события успешного входа по RDP с того же внутреннего IP. Имя поля зависит от используемого Splunk Add-on: при CIM-нормализации через Authentication datamodel поле может называться src_ip, в raw-логах — Source_Network_Address. Если в результатах кроме WKS-FIN-012 появляются другие хосты — масштаб инцидента шире, чем один алерт.

Шаг 3. Содержимое PowerShell-команды.

Кандидат L2 обязан попытаться декодировать -EncodedCommand. Операция стандартная:

[System.Text.Encoding]::Unicode.GetString(
  [System.Convert]::FromBase64String('<закодированная_строка>')
)

Результат покажет, что именно запускалось: загрузка payload, сбор информации о системе или запуск чего-то вроде Mimikatz для дампа учётных данных. Если после декодирования Base64 текст выглядит как бинарные данные — вероятно, применено дополнительное сжатие (GZip), и нужен шаг декомпрессии через System.IO.Compression.GzipStream. Без декодирования невозможно определить severity инцидента, а без severity — невозможно принять решение о реагировании.

Шаг 4. Рекомендации по сдерживанию.

• Немедленно: отключить VPN-сессию d.petrov, сбросить пароль, отозвать все активные токены
• Краткосрочно: изолировать WKS-FIN-012 от сети через EDR (Endpoint Detection and Response — агент на рабочей станции, который детектирует и блокирует подозрительную активность), но НЕ выключать — нужно сохранить оперативную память для форензики
• Параллельно: связаться с реальным d.petrov через альтернативный канал (телефонный звонок, не корпоративный мессенджер) — подтвердить, что это не его активность
• После подтверждения: передать артефакты (дамп памяти, образ диска, логи) на L3/IR-команду с готовым таймлайном

Обязанности SOC-аналитика L2 — разница с L1 на конкретных задачах

SIEM-запросы и корреляция событий

Тестовое задание SOC L2 всегда проверяет, умеет ли кандидат работать с SIEM не как с поисковиком, а как с инструментом корреляции. Разница на практике:

• L1 ищет одно событие: «покажи мне алерт по IP 185.47.XX.XX»
• L2 строит цепочку: «покажи ВСЕ действия d.petrov за два часа по ВСЕМ источникам — Windows-логи, VPN, прокси, DNS»

Ключевые Windows Event ID, которые L2-аналитик использует ежедневно:

L1 обычно знает 4624 и 4625. L2 должен по Event ID 4688 восстановить дерево процессов: какой родительский процесс запустил PowerShell, с какими аргументами, от имени какого пользователя. Вопрос «пройдись по расследованию подозрительного входа» — один из самых частых на собеседованиях SOC всех уровней. Именно глубина ответа отличает L1-кандидата от L2.

Навыки SOC-аналитика второй линии — маппинг на MITRE ATT&CK

Один из вопросов, который я задаю после тестового: «Замаппь свой таймлайн на MITRE ATT&CK». L1 обычно слышал про фреймворк, но не использовал на практике. L2 делает это автоматически — не ради галочки, а потому что маппинг решает конкретные задачи:

Для эскалации в SOC: фраза «вижу T1078 → T1059.001 → возможно T1041» передаёт L3-аналитику всю суть за три секунды. Вместо абзаца текста — три T-кода, и коллега уже понимает цепочку.

Для оценки покрытия: если в таймлайне появилась техника, на которую нет детектирующего правила — это gap, который нужно закрыть. Для T1059.001 (PowerShell) в репозитории SigmaHQ (открытый формат детектирующих правил, конвертируемых под любую SIEM) доступны десятки правил (github.com/SigmaHQ/sigma) — от обнаружения закодированных команд до подозрительных download-cradle. Часть правил помечена как deprecated, так что актуальный список стоит проверять непосредственно в репозитории.

Для прогноза следующих шагов: MITRE ATT&CK показывает типичные техники после каждой тактики. После Execution жди Persistence и Lateral Movement — можно начать проактивный поиск, не дожидаясь нового алерта.

Как подготовиться к собеседованию SOC L2

Практический блок — делай раз, делай два, делай три

Три упражнения, которые можно выполнить дома. Каждое занимает 30–60 минут и прокачивает конкретный навык из тестового задания.

Делай раз: научись читать Event ID 4688 с аргументами командной строки.

Понадобится: Windows 10/11, права администратора.

Включи аудит создания процессов: gpedit.msc → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → включи «Success». Там же включи параметр «Include command line in process creation events».

Открой PowerShell и выполни любую команду — например, Get-Process. Затем в Event Viewer (eventvwr.msc) открой Windows Logs → Security, найди свежее событие 4688. Смотри на поля: «New Process Name» (путь к exe), «Creator Process Name» (родительский процесс), «Process Command Line» (полная строка с аргументами).

Ожидаемый результат: ты видишь полную командную строку, включая аргументы. Именно это SIEM парсит при генерации алерта на подозрительный PowerShell. Если в поле «Process Command Line» пусто — аудит включён некорректно, перепроверь настройку.

Делай два: построй таймлайн из сырых логов.

Понадобится: доступ к Event Viewer на той же машине.

Экспортируй лог Security за последний час: Event Viewer → Windows Logs → Security → Save All Events As → выбери CSV. Открой файл в Excel или Google Sheets. Отфильтруй по Event ID: 4624, 4625, 4688, 4672. Отсортируй по времени.

Попробуй «прочитать историю»: кто входил, какие процессы запускались, были ли назначения привилегий. Ожидаемый результат: ты видишь хронологию действий на хосте и можешь объяснить, что происходило, в трёх предложениях. Без этого навыка тестовое задание SOC L2 не пройти.

Делай три: замаппь таймлайн на MITRE ATT&CK.

Понадобится: доступ к интернету, сайт attack.mitre.org.

Возьми таймлайн из предыдущего шага. Для каждого подозрительного события открой MITRE ATT&CK Navigator (navigator.mitre.org) и найди соответствующую технику. Запиши тактику и T-код.

Ожидаемый результат: таблица вида «событие → T-код → тактика», которую можно приложить к тикету. Попробуй по ATT&CK Navigator определить, какие техники обычно следуют за теми, что ты нашёл — это и есть threat hunting (проактивный поиск угроз по гипотезам, а не реагирование на алерты), базовый навык второй линии.

Кандидаты с L1 часто думают, что переход на L2 — вопрос количества знаний. Выучить MITRE наизусть, пройти ещё одну сертификацию, прочитать ещё десять writeup’ов. На практике разница между первой и второй линией — в способе мышления. L1 отвечает на вопрос «этот алерт — true positive или false positive?». L2 отвечает на вопрос «что произошло?». Когнитивные задачи принципиально разные.

Я видел кандидатов без единой сертификации, которые на тестовом строили безупречные таймлайны — потому что полгода ковырялись в домашней лабе и разбирали цепочки атак на собственной инфраструктуре. И видел обладателей трёх сертификатов, которые не могли объяснить, зачем атакующему Event ID 4672 после успешного 4624.

Мой прогноз: в ближайший год требования к L2 продолжат расти. AI-инструменты уже забирают рутинный триаж у первой линии — Microsoft Sentinel с Security Copilot, CrowdStrike с Charlotte AI делают первичную фильтрацию за аналитика. Первая линия будет сжиматься, а L2 станет фактическим входным уровнем для тех, кто хочет остаться в SOC. На собеседовании будут ждать не пересказ определений, а демонстрацию расследования: таймлайн, T-коды, конкретные запросы к SIEM. Если хочется пройти базу системно, а не собирать из YouTube-обрывков — на codeby.school есть трек IB Basics, который закрывает фундамент за пару месяцев без академического тона.