Когда в 3 часа ночи прилетает алерт о массовом шифровании файлов - расследовать уже поздно. Шифрование - финальный акт пьесы, которая разыгрывалась в вашей сети дни, а то и недели. За годы разбора инцидентов с LockBit, BlackCat и RansomHub я убедился в одном: единственный способ выиграть у ransomware - ловить атаку на стадии pre-ransomware активности, пока злоумышленник ещё ползает по сети, выгружает учётки и готовит плацдарм. Дальше - конкретные SIEM-правила, Sigma-детекции и запросы, которые я использую в реальной практике threat hunting.
Почему классические IOC не спасают от шифровальщиков
Индикаторы компрометации - хеши файлов, IP-адреса C2-серверов, домены - протухают за часы. Операторы RaaS-платформ (Ransomware-as-a-Service) перекомпилируют билды перед каждой атакой, меняют инфраструктуру и спокойно льют данные через легитимные сервисы. По данным SCILabs, в 2024 году в одном только латиноамериканском регионе действовали минимум 51 вариант ransomware, а топ-5 - RansomHub (17.69%), LockBit 3.0 (17.31%), Akira (8.08%), Arcus Media (7.31%), FunkSec (4.62%) - покрывали лишь 55% атак. Остальные 45% - десятки менее известных штаммов, чьи IOC вы просто не найдёте в фидах.
Поэтому проактивный поиск угроз (threat hunting ransomware) строится не на IOC, а на TTP - тактиках, техниках и процедурах по MITRE ATT&CK. TTP меняются на порядок медленнее. Какой бы штамм ни использовался, оператор всё равно должен:
- Получить учётные данные (Credential Access)
- Переместиться по сети (Lateral Movement)
- Отключить защиту (Defense Evasion)
- Удалить теневые копии (Impact)
- Запустить шифровальщик (Impact)
Каждый из этих этапов оставляет следы в логах. Наша задача - написать правила, которые эти следы ловят.
Pre-ransomware активность: хронология атаки и точки обнаружения
Типичная ransomware-атака от первичного доступа до шифрования занимает от 2 до 14 дней. Это и есть окно для threat hunting. Разберём фазы и MITRE ATT&CK техники, на которых строятся детекции.
Credential dumping и доступ к LSASS Memory
MITRE ATT&CK: LSASS Memory (T1003.001, Credential Access)
Одна из первых задач атакующего после закрепления - стянуть учётные данные доменных пользователей. Классический вектор - дамп процесса lsass.exe. В реальных инцидентах я видел три основных метода: прямой запуск Mimikatz, использование comsvcs.dll через rundll32 и создание минидампа через Task Manager или ProcDump.
Sigma-правило для обнаружения дампа LSASS через comsvcs.dll - один из самых частых паттернов у операторов Cobalt Strike:
YAML:
Код:
title
:
LSASS Memory Dump via Comsvcs.dll
id
:
a49fa4d5
-
11db
-
418c
-
8473
-
1e014a8dd462
status
:
stable
description
:
Detects LSASS memory dump using comsvcs.dll MiniDump export
logsource
:
category
:
process_creation
product
:
windows
detection
:
selection
:
CommandLine|contains|all
:
-
'comsvcs'
-
'MiniDump'
condition
:
selection
level
:
critical
tags
:
-
attack.credential_access
-
attack.t1003.001
SPL-запрос для Splunk, который ловит тот же паттерн плюс другие варианты обращения к lsass:
Код:
Код:
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(CommandLine="*comsvcs*MiniDump*" OR
(CommandLine="*procdump*" CommandLine="*lsass*") OR
(CommandLine="*rundll32*" CommandLine="*comsvcs*" CommandLine="*full*"))
| stats count by Computer, User, CommandLine, ParentCommandLine
| where count > 0
Как отличить от легитимного: в корпоративной среде антивирусные агенты тоже обращаются к lsass.exe - это нормально. Ключевой маркер - ParentProcess. Легитимное обращение идёт от известных security-агентов с цифровой подписью. Если parent - cmd.exe, powershell.exe или вообще неизвестный бинарник - красный флаг.
Lateral movement: RDP, PsExec и WMI
MITRE ATT&CK: Remote Desktop Protocol (T1021.001, Lateral Movement)
После получения учёток злоумышленник начинает ползать по сети. Три классических вектора, которые я наблюдаю практически в каждом ransomware-инциденте:
RDP (T1021.001) - самый простой для обнаружения паттерн. В нормальной среде RDP-подключения идут с ограниченного набора административных станций. Массовые RDP-сессии с одного хоста на кучу серверов за короткое время - верный признак lateral movement.
Код:
Код:
index=wineventlog EventCode=4624 Logon_Type=10
| bin _time span=1h
| stats dc(dest) as unique_targets values(dest) as target_list by src, user, _time
| where unique_targets > 5
| sort -unique_targets
Этот SPL-запрос ищет ситуации, когда один источник подключился по RDP (Logon_Type=10) к более чем 5 уникальным хостам за час. В реальном SOC порог зависит от среды - для сервис-деска 10 подключений в час может быть нормой, для бухгалтера - уже инцидент.
PsExec и SMB-based execution: группы вроде Conti и LockBit активно используют PsExec для деплоя шифровальщика. Детектим создание характерных сервисов:
Код:
Код:
index=wineventlog EventCode=7045
| where ServiceFileName LIKE "%PSEXESVC%" OR ServiceName LIKE "%PSEXE%"
| stats count by Computer, ServiceName, ServiceFileName, _time
WMI remote process creation (T1047, Execution) - ещё один излюбленный метод. KQL-запрос для Microsoft Sentinel:
Код:
Код:
DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName =~ "wmiprvse.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "mshta.exe", "rundll32.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessCommandLine, AccountName
| sort by Timestamp desc
Отключение защиты и уничтожение теневых копий
MITRE ATT&CK: Disable or Modify Tools (T1562.001, Defense Evasion), Inhibit System Recovery (T1490, Impact)
Перед запуском шифровальщика атакующий решает две задачи: вырубить EDR/AV и уничтожить возможность восстановления через теневые копии (VSS). Это критическая точка - если вы поймаете эту активность, до шифрования остаются минуты или часы. Тут уже не до чая. Подробнее о том, как
поведенческие индикаторы шифровальщиков помогают обнаружить атаку до её завершения, - в отдельном разборе.
Sigma-правило для обнаружения удаления теневых копий:
YAML:
Код:
title
:
Shadow Copy Deletion via Vssadmin or WMIC
id
:
c947b146
-
0abc
-
4f87
-
9c64
-
b17e9d7274a2
status
:
stable
description
:
Detects deletion of shadow copies
-
common pre
-
ransomware activity
logsource
:
category
:
process_creation
product
:
windows
detection
:
selection_vssadmin
:
CommandLine|contains|all
:
-
'vssadmin'
-
'delete'
-
'shadows'
selection_wmic
:
CommandLine|contains|all
:
-
'wmic'
-
'shadowcopy'
-
'delete'
selection_powershell
:
CommandLine|contains|all
:
-
'Get-WmiObject'
-
'Win32_ShadowCopy'
-
'Delete'
condition
:
selection_vssadmin or selection_wmic or selection_powershell
level
:
critical
tags
:
-
attack.impact
-
attack.t1490
KQL для Microsoft Defender (адаптировано из документации Microsoft по Advanced Hunting):
Код:
Код:
DeviceProcessEvents
| where Timestamp > ago(1d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete shadows")
or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy"
and ProcessCommandLine has "delete")
| project DeviceId, Timestamp, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessParentFileName
Отключение защитных сервисов через sc.exe (T1562.001) - ещё один классический паттерн. Порог в 10 и более отключаемых сервисов за 5 минут - надёжный индикатор (по данным Microsoft):
Код:
Код:
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName =~ "sc.exe" and ProcessCommandLine has "config"
and ProcessCommandLine has "disabled"
| summarize ScDisableCount = dcount(ProcessCommandLine),
ScDisableList = make_set(ProcessCommandLine)
by DeviceId, bin(Timestamp, 5m)
| where ScDisableCount > 10
Очистка логов и заметание следов
MITRE ATT&CK: Clear Windows Event Logs (T1070.001, Defense Evasion)
Опытные операторы ransomware чистят за собой логи. И в этом их парадокс - сам факт массовой очистки логов это мощнейший индикатор компрометации. Ты пытаешься спрятаться, а вместо этого кричишь «я здесь».
Код:
Код:
index=wineventlog (EventCode=1102 OR EventCode=104)
| stats count by Computer, User, _time
| where count > 3
EventCode 1102 - очистка Security-лога, EventCode 104 - очистка System-лога. Если на одном хосте за короткое время очищены несколько журналов - это почти наверняка инцидент. Легитимные причины массовой очистки логов в production-среде я за всю практику встречал дважды, и оба раза это было задокументированное действие администратора с тикетом в Jira.
Дополнительно стоит мониторить использование wevtutil для очистки:
Код:
Код:
DeviceProcessEvents
| where Timestamp > ago(1d)
| where ProcessCommandLine has "WEVTUTIL" and ProcessCommandLine has "CL"
| summarize LogClearCount = dcount(ProcessCommandLine),
ClearedLogList = make_set(ProcessCommandLine)
by DeviceId, bin(Timestamp, 5m)
| where LogClearCount > 10
SIEM правила для ransomware: корреляция событий
Отдельные детекции - хорошо, но настоящая сила SIEM в корреляции. Один алерт на
Код:
vssadmin delete shadows
может быть false positive. Но если на том же хосте за последние 24 часа были: подозрительное обращение к LSASS, множественные RDP-сессии к другим серверам и отключение сервисов - тут уже не совпадение, а инцидент с высокой confidence.
Корреляционное правило для Splunk
SPL-запрос, который ищет хосты с множественными признаками pre-ransomware активности за последние 24 часа:
Код:
Код:
index=wineventlog earliest=-24h
| eval indicator=case(
EventCode=1 AND (CommandLine LIKE "%comsvcs%MiniDump%" OR
(CommandLine LIKE "%procdump%" AND CommandLine LIKE "%lsass%")),
"credential_dump",
EventCode=4624 AND Logon_Type=10, "rdp_logon",
EventCode=7045 AND ServiceFileName LIKE "%PSEXESVC%", "psexec",
EventCode=1 AND CommandLine LIKE "%vssadmin%delete%shadows%", "vss_delete",
EventCode=1 AND CommandLine LIKE "%sc%config%disabled%", "service_disable",
EventCode=1102 OR EventCode=104, "log_clear",
1=1, "other"
)
| where indicator!="other"
| stats dc(indicator) as indicator_count,
values(indicator) as indicators,
values(CommandLine) as commands
by Computer
| where indicator_count >= 3
| sort -indicator_count
Логика простая: если на одном хосте за 24 часа сработали 3 и более различных индикатора из набора - это приоритетный кейс. Бросай всё и разбирайся.
Sigma-правило для обнаружения массовой остановки процессов
Остановка критических сервисов - финальная подготовка перед шифрованием. Ransomware останавливает SQL Server, Exchange, антивирусы и backup-агенты, чтобы разблокировать файлы для шифрования. Логика тут чисто прикладная: пока SQL Server держит .mdf - зашифровать его не получится.
YAML:
Код:
title
:
Mass Service Stop via Net.exe
-
Pre
-
Ransomware Indicator
id
:
89f4c4ae
-
5fa0
-
4b51
-
b7a2
-
e9847c03d7a1
status
:
experimental
description
:
|
Detects mass stopping of services via net stop command,
commonly observed before ransomware deployment
logsource
:
category
:
process_creation
product
:
windows
detection
:
selection
:
OriginalFileName
:
'net.exe'
CommandLine|contains
:
'stop'
timeframe
:
2m
condition
:
selection
|
count() by Computer
>
10
level
:
high
tags
:
-
attack.impact
-
attack.t1489
Обнаружение Valid Accounts и аномального использования учёток
MITRE ATT&CK: Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion)
Группы типа Medusa активно покупают доступ у Initial Access Brokers (IAB). По данным CISA, IAB-аффилиаты Medusa получают от 100 до 1 миллиона долларов за эксклюзивную работу на группу. Фишинг и незакрытые уязвимости - их хлеб. Результат - легитимные учётные записи в руках атакующего. Понимание того, как
использовать данные об угрозах для проактивной защиты, помогает выстроить контекст вокруг подобных атак.
Вот что стоит искать в SIEM для обнаружения злоупотребления действующими учётными записями:
Код:
Код:
index=wineventlog EventCode=4624 Logon_Type IN (2,10)
| stats earliest(_time) as first_logon, latest(_time) as last_logon,
dc(src) as unique_sources, dc(dest) as unique_destinations,
values(src) as source_list
by user
| where unique_sources > 3 AND unique_destinations > 5
| eval time_range=last_logon-first_logon
| where time_range 20
EventCode 5140 - доступ к сетевой шаре. Если один хост за 10 минут обращается к более чем 20 уникальным шарам - аномалия. Легитимные backup-системы и DFS-серверы создадут тут шум, поэтому добавьте исключения для известных сервисов.
Типичные false positives и как с ними жить
Любое SIEM-правило для ransomware будет генерировать ложные срабатывания. Вот самые частые из моей практики:
ДетекцияТипичный false positiveКак отличитьLSASS dumpАнтивирусный агент сканирует lsassParentProcess = известный AV-процесс с валидной подписьюМассовые RDP-сессииАдминистратор патчит серверыВремя совпадает с maintenance window, учётка из утверждённого спискаУдаление VSSСкрипт ротации бэкаповЗапуск по расписанию через Task Scheduler с известного хостаОтключение сервисовОбновление ПО (инсталлятор останавливает сервис)ParentProcess = msiexec.exe или setup.exe с валидной подписьюОчистка логовРотация логов администраторомДокументир ованная процедура, выполняется с jump-сервера
Главный принцип: не отключайте правило из-за false positives - настройте исключения через whitelist. Каждое исключение документируйте: кто добавил, почему, срок действия. На одном проекте мы нашли в whitelist исключение двухлетней давности, добавленное уволившимся сотрудником, - под него как раз пролез атакующий.
Что делать прямо сейчас
Если у вас сейчас нет программы threat hunting - начните с малого:
- Включите логирование. Минимум: Sysmon с конфигурацией SwiftOnSecurity, PowerShell ScriptBlock Logging, Windows Event Forwarding для EventCode 4624, 4625, 7045, 1102, 5140
- Импортируйте Sigma-правила. Репозиторий SigmaHQ на GitHub содержит сотни правил для ransomware-TTP. Конвертируйте под ваш SIEM
- Запланируйте еженедельный hunt. Выберите одну технику из таблицы выше и проведите hunting за неделю. Начните с T1003.001 (LSASS) - если это есть в вашей сети, всё остальное уже не важно
- Стройте baseline. Первые 2-4 недели уйдут на понимание «нормы» вашей сети. Без baseline утонете в алертах
Ransomware - не стихийное бедствие. Это атака с предсказуемым набором шагов, каждый из которых оставляет следы. Прямо сейчас возьмите SPL-запрос для LSASS из этой статьи и запустите на своих логах за последнюю неделю. Если результат пустой - хорошо, спите спокойно. Если нет - вы знаете, что делать. Для тех, кто хочет выстроить полноценную
домашнюю лабораторию SOC с Wazuh для отработки этих техник - есть подробное пошаговое руководство.
Линейный вид
