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

https://forum.antichat.xyz/attachmen...3160cc2d73.png

Когда в 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 для отработки этих техник - есть подробное пошаговое руководство.