Статья Threat hunting ransomware: обнаружение pre-ransomware активности в корпоративной сети через SIEM-правила и IOC

Когда в 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 меняются на порядок медленнее. Какой бы штамм ни использовался, оператор всё равно должен:

1. Получить учётные данные (Credential Access)
2. Переместиться по сети (Lateral Movement)
3. Отключить защиту (Defense Evasion)
4. Удалить теневые копии (Impact)
5. Запустить шифровальщик (Impact)

Каждый из этих этапов оставляет следы в логах. Наша задача - написать правила, которые эти следы ловят.

Pre-ransomware активность: хронология атаки и точки обнаружения​

Типичная ransomware-атака от первичного доступа до шифрования занимает от 2 до 14 дней. Это и есть окно для threat hunting. Разберём фазы и MITRE ATT&CK техники, на которых строятся детекции.

Credential dumping и доступ к LSASS Memory​

MITRE ATT&CK:

Ссылка скрыта от гостей

Одна из первых задач атакующего после закрепления - стянуть учётные данные доменных пользователей. Классический вектор - дамп процесса lsass.exe. В реальных инцидентах я видел три основных метода: прямой запуск Mimikatz, использование comsvcs.dll через rundll32 и создание минидампа через Task Manager или ProcDump.

Sigma-правило для обнаружения дампа LSASS через comsvcs.dll - один из самых частых паттернов у операторов Cobalt Strike:

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),

Ссылка скрыта от гостей

Перед запуском шифровальщика атакующий решает две задачи: вырубить EDR/AV и уничтожить возможность восстановления через теневые копии (VSS). Это критическая точка - если вы поймаете эту активность, до шифрования остаются минуты или часы. Тут уже не до чая. Подробнее о том, как поведенческие индикаторы шифровальщиков помогают обнаружить атаку до её завершения, - в отдельном разборе.

Sigma-правило для обнаружения удаления теневых копий:

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:

Ссылка скрыта от гостей

Опытные операторы 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 - зашифровать его не получится.

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:

Ссылка скрыта от гостей

/ 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 < 86400
| sort -unique_destinations

Ищем учётные записи, которые за 24 часа аутентифицируются с более чем 3 источников на более чем 5 целевых хостов. Для сервисных учёток это может быть нормой - поэтому baseline и whitelist известных сервисных аккаунтов тут критичны. Без них утонете в шуме.

Пошаговый процесс threat hunting: делай раз, делай два, делай три​

Делай раз: формирование гипотезы и baseline​

Threat hunting начинается не с запроса в SIEM, а с гипотезы.

Гипотеза: «В нашей сети может присутствовать злоумышленник, использующий скомпрометированные учётные данные для lateral movement через RDP.»

Основание: За последний месяц в отрасли зафиксированы атаки RansomHub с использованием IAB, которые продавали VPN-доступ к сетям аналогичных компаний.

Перед запуском охотничьих запросов соберите baseline:

• Какие учётные записи регулярно используют RDP?
• С каких хостов и на какие?
• В какое время суток?
• Какие сервисные аккаунты создают процессы на удалённых машинах?

Без baseline любой запрос утонет в false positives. Лично у меня первые две недели в новом SOC уходили исключительно на сбор «нормы» - и это нормально.

Делай два: запуск охотничьих запросов по MITRE ATT&CK матрице​

Последовательно проходим по каждой фазе kill chain:

Фаза	Техника MITRE ATT&CK	Что ищем	Приоритет
Initial Access	Valid Accounts (T1078)	Аномальные логоны, логоны в нерабочее время	Средний
Credential Access	LSASS Memory (T1003.001)	Обращения к lsass.exe, дампы памяти	Критический
Discovery	File and Directory Discovery (T1083)	Массовый перебор файловых шар (net view, dir)	Средний
Lateral Movement	RDP (T1021.001)	Множественные RDP-сессии с одного хоста	Высокий
Defense Evasion	Disable or Modify Tools (T1562.001)	Отключение AV/EDR-сервисов	Критический
Defense Evasion	Clear Windows Event Logs (T1070.001)	Массовая очистка журналов	Критический
Impact	Inhibit System Recovery (T1490)	Удаление теневых копий, отключение System Restore	Критический
Impact	Data Encrypted for Impact (T1486)	Массовое переименование файлов (на этом этапе уже поздно)	Критический

Запускайте запросы от Credential Access вниз. Если вы нашли credential dump - не ждите, пока дойдёте до T1486. Эскалируйте немедленно.

Делай три: триаж и эскалация​

Каждый результат охоты проходит через триаж:

1. Контекст хоста. Рабочая станция бухгалтера или jump-сервер администратора? PsExec на jump-сервере - возможно, норма. PsExec на компьютере HR - нет.
2. Контекст пользователя. Учётная запись в AD - какие группы, какие права? Если учётка из Domain Admins выполняет vssadmin delete shadows - немедленная эскалация, без раздумий.
3. Временной контекст. Активность в 3 ночи в компании, где никто не работает 24/7 - красный флаг.
4. Корреляция. Один индикатор - подозрение. Два на одном хосте - расследование. Три - инцидент.

При подтверждении pre-ransomware активности: немедленная изоляция хоста на уровне сети (не выключайте - потеряете volatile-данные в RAM), блокировка скомпрометированных учёток, уведомление IR-команды.

Инструменты для проактивного поиска угроз в корпоративной сети​

Для полноценного threat hunting ransomware нужен стек из нескольких компонентов:

SIEM - ядро всего. Splunk Enterprise Security, Microsoft Sentinel, Elastic SIEM - все поддерживают описанные выше запросы. Sigma-правила конвертируются под любую платформу через sigmac/pySigma.

EDR - источник телеметрии с endpoints. CrowdStrike Falcon, Microsoft Defender for Endpoint, Carbon Black - дают видимость процессов, командных строк и сетевых соединений на каждом хосте. Без EDR вы слепы на конечных точках - SIEM покажет только то, что Windows Event Log соизволил записать.

Open-source инструменты для усиления:

• APT-Hunter - анализ Windows Event Logs с маппингом на MITRE ATT&CK, хорош для ретроспективного анализа
• YARA - кастомные правила для обнаружения ransomware-бинарников и инструментов атакующего
• Zeek (бывший Bro) - анализ сетевого трафика, обнаружение аномальных SMB-сессий и DNS-запросов к C2
• MISP - платформа обмена IOC и threat intelligence между организациями, по данным hunt.io входит в топ открытых платформ для threat hunting

Обнаружение ransomware TTPs: от Discovery до Impact​

Отдельно про фазу Discovery (T1083, File and Directory Discovery). Перед шифрованием оператор ransomware проводит разведку файловых ресурсов - ему нужно понять, где лежит самое ценное. Выражается это в массовых обращениях к сетевым шарам:

index=wineventlog EventCode=5140
| bin _time span=10m
| stats dc(ShareName) as unique_shares, values(ShareName) as shares
    by IpAddress, SubjectUserName, _time
| where unique_shares > 20

EventCode 5140 - доступ к сетевой шаре. Если один хост за 10 минут обращается к более чем 20 уникальным шарам - аномалия. Легитимные backup-системы и DFS-серверы создадут тут шум, поэтому добавьте исключения для известных сервисов.

Типичные false positives и как с ними жить​

Любое SIEM-правило для ransomware будет генерировать ложные срабатывания. Вот самые частые из моей практики:

Детекция	Типичный false positive	Как отличить
LSASS dump	Антивирусный агент сканирует lsass	ParentProcess = известный AV-процесс с валидной подписью
Массовые RDP-сессии	Администратор патчит серверы	Время совпадает с maintenance window, учётка из утверждённого списка
Удаление VSS	Скрипт ротации бэкапов	Запуск по расписанию через Task Scheduler с известного хоста
Отключение сервисов	Обновление ПО (инсталлятор останавливает сервис)	ParentProcess = msiexec.exe или setup.exe с валидной подписью
Очистка логов	Ротация логов администратором	Документированная процедура, выполняется с jump-сервера

Главный принцип: не отключайте правило из-за false positives - настройте исключения через whitelist. Каждое исключение документируйте: кто добавил, почему, срок действия. На одном проекте мы нашли в whitelist исключение двухлетней давности, добавленное уволившимся сотрудником, - под него как раз пролез атакующий.

Что делать прямо сейчас​

Если у вас сейчас нет программы threat hunting - начните с малого:

1. Включите логирование. Минимум: Sysmon с конфигурацией SwiftOnSecurity, PowerShell ScriptBlock Logging, Windows Event Forwarding для EventCode 4624, 4625, 7045, 1102, 5140
2. Импортируйте Sigma-правила. Репозиторий SigmaHQ на GitHub содержит сотни правил для ransomware-TTP. Конвертируйте под ваш SIEM
3. Запланируйте еженедельный hunt. Выберите одну технику из таблицы выше и проведите hunting за неделю. Начните с T1003.001 (LSASS) - если это есть в вашей сети, всё остальное уже не важно
4. Стройте baseline. Первые 2-4 недели уйдут на понимание «нормы» вашей сети. Без baseline утонете в алертах

Ransomware - не стихийное бедствие. Это атака с предсказуемым набором шагов, каждый из которых оставляет следы. Прямо сейчас возьмите SPL-запрос для LSASS из этой статьи и запустите на своих логах за последнюю неделю. Если результат пустой - хорошо, спите спокойно. Если нет - вы знаете, что делать. Для тех, кто хочет выстроить полноценную домашнюю лабораторию SOC с Wazuh для отработки этих техник - есть подробное пошаговое руководство.