Статья Threat hunting в банке: IOC, SIEM-правила и поиск APT-активности в финансовой сети

Четверг, 14:23. SIEM выдаёт алерт средней критичности: Sysmon Event ID 10 фиксирует обращение к lsass.exe с хоста из SWIFT-сегмента. Процесс-инициатор - svhost.exe, не svchost.exe. Одна лишняя буква «v» в имени. Кто-то не очень старался с маскировкой - или, наоборот, рассчитывал, что SOC не заметит.

Медианное время нахождения атакующего в сети до обнаружения - 11 дней (исторический минимум по Mandiant M-Trends 2025). При этом 57% организаций узнают о компрометации от внешней стороны, а не от собственного SOC. В банковском контексте «внешняя сторона» - это ЦБ РФ или FinCERT, и к этому моменту разговор уже не про инцидент, а про регуляторные последствия вплоть до отзыва лицензии.

Этот материал - о том, как выстроить threat hunting в финансовой организации так, чтобы находить атакующего раньше регулятора.

Ландшафт угроз: кто атакует банки и какими TTPs​

По данным BI.ZONE Threat Intelligence, на российскую финансовую отрасль нацелены более 60 группировок, каждая со своим набором TTPs. На долю финансового сектора приходится порядка 11% всех кибератак в России за девять месяцев 2025 года. Глобально не легче: согласно hunt.io, доля ransomware-атак в финансовом секторе выросла до 65% в 2024 году - почти вдвое по сравнению с 34% в 2021. А за последние два десятилетия около 20% всех зарегистрированных киберинцидентов затронули финансовые учреждения и принесли прямых убытков на $12 млрд.

Четыре тренда, которые определяют направление проактивного поиска угроз в финансовом секторе:

Credential-based атаки доминируют. Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation) - основной метод закрепления в банковской инфраструктуре. Атакующие не ломают периметр - они входят через ворота с легитимными ключами. CrowdStrike Global Threat Report 2025 фиксирует рост активности China-nexus группировок на 150% год к году, и значительная часть этой активности связана именно с кражей и повторным использованием валидных учёток.

Living off the Land. APT-группы, нацеленные на банки, массово используют встроенные системные утилиты: PowerShell (T1059.001), WMI, cmd.exe (T1059.003). По данным Huntress, APT-группы задействуют легитимные системные инструменты во вредоносных целях - антивирус такую активность не детектирует, потому что формально ничего вредоносного не запускается. Всё «штатно».

Supply chain как вектор входа. Как отмечают в BI.ZONE, злоумышленники всё чаще атакуют менее защищённых подрядчиков банков, а не сами банки напрямую. Это смещает фокус threat hunting с периметра на мониторинг VPN-сессий подрядчиков и сервисных учёток.

GenAI ускоряет Spearphishing. По данным IBM X-Force Threat Intelligence Index 2025, генерация фишинговых писем с помощью GenAI быстрее в 11,4 раза при сопоставимом качестве. Для банковского SOC это означает кратный рост объёма Spearphishing Attachment (T1566.001), где каждое письмо стилизовано под легитимное обращение контрагента. Раньше ломаный русский в фишинге выдавал атакующего - сейчас этот фильтр мёртв.

Гипотезы для threat hunting в банковской инфраструктуре​

Threat hunting начинается не с SIEM-правил - он начинается с гипотез. Гипотеза - это предположение о наличии конкретной TTPs в инфраструктуре, которое можно подтвердить или опровергнуть данными из телеметрии. Без гипотезы threat hunter превращается в аналитика, просматривающего алерты, а это уже не охота за угрозами, а реактивный мониторинг. Разница - как между снайпером и охранником на проходной.

Kill chain финансовых APT по MITRE ATT&CK​

Для банковской сети типичная цепочка целевой атаки выглядит так:

Этап	Техника MITRE ATT&CK	Где искать в банке
Initial Access	Spearphishing Attachment (T1566.001)	Почтовый шлюз, sandbox-логи, Sysmon EID 1 из temp-директорий
Execution	PowerShell (T1059.001)	Script Block Logging EID 4104, Sysmon EID 1
Credential Access	LSASS Memory (T1003.001)	Sysmon EID 10 (ProcessAccess к lsass.exe)
Credential Access	Golden Ticket (T1558.001)	EID 4769 без соответствующего 4768 в окне TGT lifetime, аномальный TicketEncryptionType (0x17 RC4 в AES-среде), TGT lifetime > политики домена
Lateral Movement	Pass the Hash (T1550.002)	Logon Type 3 с NTLM в Kerberos-среде, EID 4624
Command and Control	Web Protocols (T1071.001)	Beaconing-паттерны, DNS к DGA-подобным доменам
Defense Evasion	Indicator Removal: Clear Windows Event Logs (T1070.001)	EID 1102, пустые промежутки в логах

Для банка критична привязка к бизнес-контексту: SWIFT-терминалы, АБС (автоматизированная банковская система), процессинговые серверы - это хосты, которые требуют отдельных baseline и повышенного внимания при поиске APT-активности в сети.

Decision tree: с чего начинать охоту за угрозами в SIEM

1. Есть свежий threat intelligence о кампании на финансовый сектор - формулируем гипотезу на основе конкретных IOC и TTPs из фида
2. Нет актуального TI - начинаем с credential access (T1003.001): проверяем все обращения к lsass.exe за последние 30 дней
3. Credential access чист - переходим к lateral movement: ищем аномальные Logon Type 3 между сегментами (рабочие станции → серверный сегмент)
4. Lateral movement чист - проверяем C2: DNS-запросы к DGA-подобным доменам, HTTP-beaconing с фиксированными интервалами

Этот decision tree - отправная точка, не истина в последней инстанции. В крупном банке с десятками тысяч хостов каждый шаг генерирует тысячи событий, и без предварительного baseline работа превращается в хождение по минному полю ложных срабатываний.

SIEM-правила для обнаружения APT-активности в банке​

Требования к окружению​

Перед внедрением корреляционных правил убедитесь, что инфраструктура готова:

🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.

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

• SIEM: Splunk Enterprise 9.x+ или Elastic SIEM 8.11+ (примеры ниже на SPL и KQL соответственно)
• Логи эндпоинтов: Sysmon v15+ с конфигурацией SwiftOnSecurity или аналогичной, Script Block Logging включён через GPO
• Сетевые логи: NetFlow/IPFIX с пограничных маршрутизаторов, DNS-логи (query + response)
• Минимальные права: аккаунт threat hunter с read-only доступом ко всем индексам
• Baseline: минимум 30 дней «чистых» данных для построения поведенческих профилей
• RAM / хранилище: для Elastic - от 32 ГБ RAM на data node при объёме 500 ГБ/сутки логов; для Splunk - аналогичные требования к search heads

Без Sysmon и Script Block Logging половина описанных детекций нерабочая. Это не рекомендация - это минимальный порог входа для threat hunting в Windows-среде банка. Если у вас нет Sysmon - дальше можно не читать, пока не поставите.

Credential access и lateral movement​

Основная гипотеза: «атакующий получил доступ к учётным данным и перемещается по сети». Два ключевых detection:

Обращение к LSASS (T1003.001). SPL-запрос для Splunk:

index=sysmon EventCode=10 TargetImage="*\\lsass.exe"
  GrantedAccess IN ("0x1010","0x1410","0x143a","0x1438","0x40","0x1FFFFF","0x101010")
| where NOT match(SourceImage,"(?i)(csrss|services|svchost|wininit|wmiprvse)\.exe$")
| stats count by SourceImage, Computer, User
| where count < 5

Запрос ищет все обращения к lsass.exe от процессов вне стандартного whitelist. Порог count < 5 отсекает легитимные сканеры (антивирус, DLP-агент), которые обращаются к lsass массово. В банковской среде whitelist придётся расширить: клиенты АБС, агенты DLP (InfoWatch, Solar Dozor и аналоги), процессинговые модули - все они могут легитимно взаимодействовать с lsass. Без тюнинга под конкретный банк правило выдаст десятки false positives в первый же день. Я видел, как SOC-аналитик после такого «внедрения» получал 300 алертов за смену и просто переставал на них смотреть.

Pass the Hash (T1550.002). KQL-запрос для Elastic - ищет NTLM-аутентификацию там, где должен работать Kerberos (косвенный индикатор lateral movement, требующий корреляции с baseline):

event.code: "4624" and winlog.event_data.LogonType: (3 or "3")
  and winlog.event_data.AuthenticationPackageName: "NTLM"
  and winlog.event_data.LogonProcessName: "NtLmSsp"
  and winlog.event_data.KeyLength: (0 or "0")
  and not source.ip: ("127.0.0.1" or "::1")

Нюанс: значения LogonType и KeyLength могут индексироваться как числа или строки в зависимости от маппинга (ECS vs raw winlog) - проверьте формат в своём индексе. Legacy-системы (терминалы старых банкоматов на Windows Embedded, устаревшие версии АБС) часто используют NTLM легитимно. Перед выводом в production постройте baseline NTLM-трафика и исключите известные legacy-хосты. В крупном банке с 200+ банкоматами SOC утонет в false positives без этого шага.

C2 и заметание следов​

Beaconing detection (T1071.001). Логика: агрегируйте HTTP-запросы по парам src_ip → dst_ip за 24 часа, рассчитайте стандартное отклонение интервалов между запросами. Если коэффициент вариации интервалов CV (σ/mean) < 0.1 при количестве запросов > 50 - вероятный beaconing. Абсолютный порог σ неэффективен: современные C2-фреймворки (Cobalt Strike, Sliver) используют jitter 20–50%, что повышает σ, но сохраняет низкий CV. Для детекта jittered beacons применяют спектральный анализ (FFT) - см. методологию RITA / Active Countermeasures. В Splunk базовый вариант реализуется через timechart span=1s count by dest_ip с последующим расчётом eventstats stdev(count) as sd, mean(count) as avg | eval cv=sd/avg.

Отдельная головная боль - банковские приложения (клиент-банк, мобильный банкинг) генерируют регулярные heartbeat-запросы. Их нужно исключить на этапе базовой фильтрации, иначе каждый сервер мобильного приложения будет фигурировать как C2-канал. На практике в одном банке из-за этого первый месяц beaconing-правило выдавало топ-10 «подозрительных» хостов, и все десять были серверами push-уведомлений.

Очистка логов (T1070.001). Событие Windows Event ID 1102 - очистка журнала Security - должно генерировать алерт максимальной критичности в любом банковском SOC. В штатном режиме Security-лог не очищается никогда. Одна строка index=wineventlog EventCode=1102 - и это реально рабочий detection. Единственный сценарий false positive - плановое обслуживание, зафиксированное в change management и исключённое по временному окну. Если EID 1102 прилетел вне окна - бросайте всё и разбирайтесь.

IOC и IOA: индикаторы компрометации в банковской инфраструктуре​

Разница между IOC (Indicator of Compromise) и IOA (Indicator of Attack) в контексте мониторинга угроз в банке - принципиальная. IOC - хеш файла, IP-адрес C2, домен. Они устаревают за часы: атакующий пересобрал бинарь - и хеш уже другой. IOA - поведение: последовательность действий, указывающая на атаку независимо от конкретных артефактов. IOA живут столько, сколько живёт TTPs.

Сетевой уровень:

• DNS-запросы к доменам с Shannon entropy (log2) > 4.0 при длине >12 символов и отсутствии в Tranco/Alexa top-1M (DGA-подобные)
• HTTPS-соединения на нестандартных портах (не 443) из SWIFT-зоны
• SMB-трафик между хостами, которые исторически не обменивались данными (тут без baseline вообще никак)

Хостовый уровень:

• Создание процессов из %TEMP%, %APPDATA%\Local\Temp - типичный IOA для post-exploitation
• Sysmon EID 11 (FileCreate) с расширениями .ps1, .bat, .vbs в пользовательских директориях
• Запуск cmd.exe или powershell.exe от имени сервисной учётной записи АБС - тут стоит насторожиться, потому что сервисная учётка АБС не должна запускать интерактивные шеллы

Специфика банка:

• Обращения к серверам процессинга или SWIFT-шлюзам с хостов, не входящих в разрешённый ACL
• Аномальные транзакции в нерабочее время (корреляция SIEM с бизнес-логикой банка)
• Изменения в конфигурации маршрутизации SWIFT-сообщений

Threat intelligence для финансового сектора нужно обогащать отраслевыми фидами: FinCERT в России, FS-ISAC глобально. Как отмечает Олег Скулкин из BI.ZONE Threat Intelligence, у каждой из 60+ группировок, нацеленных на финансы, свой почерк - generic-фиды покрывают от силы 30% индикаторов. Остальные 70% - это то, что отличает банковский threat hunting от «threat hunting по учебнику».

Insider threat и скомпрометированные легитимные аккаунты​

Техника Valid Accounts (T1078) - головная боль банковского SOC. Когда атакующий использует скомпрометированную учётную запись сотрудника, все его действия выглядят легитимно для стандартных корреляционных правил SIEM. Правило сработает на mimikatz, но не сработает на человека, который залогинился с правильным паролем.

Три категории insider threat в банковской среде по классификации Huntress:

• Malicious insiders - сотрудники, намеренно крадущие данные для личной выгоды
• Compromised insiders - учётные записи, захваченные внешним атакующим
• Negligent insiders - случайные утечки через небрежность

Для обнаружения compromised insiders работает только поведенческая аналитика:

1. Временные аномалии: сотрудник бухгалтерии, который десять лет логинился с 9:00 до 18:00, вдруг начинает работать в 3:00 - это повод для гипотезы, а не для увольнения
2. Географические аномалии: VPN-сессия из нетипичной локации при наличии активной сессии с рабочего места (impossible travel). Классика: одна сессия из Москвы, вторая из Амстердама, разница - 20 минут
3. Аномалии доступа: обращение к ресурсам, не связанным с должностными обязанностями - особенно к серверам с финансовой отчётностью

В Elastic SIEM это реализуется через ML-based anomaly detection с custom jobs на Logon Events (модуль Security, версия 8.11+). В Splunk - через UBA-модуль с baseline минимум 90 дней. Для IBM QRadar - через Risk Scoring с привязкой к HR-данным (должность, отдел, грейд доступа). Каждый из этих подходов требует интеграции с кадровой системой банка - без информации о том, кто чем должен заниматься, любая поведенческая аналитика слепа. А попробуйте получить выгрузку из SAP HR в банке - отдельное приключение.

Отдельная боль - сервисные учётные записи. В типичном банке их сотни: от интеграции АБС с процессингом до автоматических сверок с ЦБ. Каждая - потенциальный вектор для T1078, и стандартный мониторинг «кто логинился во внеурочное время» к ним неприменим, потому что они работают 24/7. Для сервисных учёток нужен отдельный baseline: откуда логинятся, к каким ресурсам обращаются, какой объём данных перемещают. Любое отклонение - повод копнуть.

Detection-чеклист для SOC финансовой организации​

Готовый чеклист - можно включать в отчёт по аудиту или передавать в SOC как есть:

Категория	Detection	Источник данных	Критичность
Credential Access	Обращение к lsass.exe от нетипичных процессов	Sysmon EID 10	Высокая
Credential Access	TGS-REQ (EID 4769) без предшествующего AS-REQ, аномальный TicketEncryptionType 0x17 RC4 в AES-среде, TGT lifetime > политики домена (Golden Ticket)	Windows EID 4769/4768	Высокая
Lateral Movement	NTLM Logon Type 3 в Kerberos-среде	Windows EID 4624	Средняя
Lateral Movement	SMB между нетипичными парами хостов	NetFlow + baseline	Средняя
Execution	Encoded/obfuscated PowerShell	Script Block Logging EID 4104	Высокая
Defense Evasion	Очистка Security-лога	Windows EID 1102	Критическая
C2	Beaconing (CV < 0.1, count > 50)	HTTP/DNS-логи	Высокая
C2	DNS к DGA-подобным доменам (энтропия > 4.0 + длина >12)	DNS-логи	Средняя
Insider	Логин в нетипичное время (±3σ от baseline)	EID 4624 + ML	Средняя
Insider	Одновременные сессии из разных локаций	VPN + EID 4624	Высокая
SWIFT	Обращение к SWIFT-шлюзу с хоста вне ACL	Firewall + ACL	Критическая
SWIFT	Изменение конфигурации маршрутизации	Audit trail Alliance	Критическая

Каждый detection из таблицы должен пройти цикл: создание правила → тюнинг baseline (минимум 30 дней) → вывод в production (для UBA-модулей - не менее 90 дней). Развёртывание всех правил одновременно без тюнинга гарантированно парализует SOC. На практике правило по NTLM без исключений legacy-систем даёт 200+ алертов в сутки в крупном банке. Аналитики начинают игнорировать - и пропускают настоящий инцидент.

Три года в банковском SOC сформировали одно убеждение: большинство финансовых организаций фокусируется на периметре и реактивном мониторинге. Threat hunting как выделенный процесс - не строка в регламенте для ЦБ, а человек, который каждый день формулирует гипотезы и проверяет их на данных - существует в единичных банках. При этом 70% атак в 2024 году, по данным IBM X-Force, пришлись на критическую инфраструктуру, а в атаках на SWIFT-терминалы в 2015-2016 годах одного скомпрометированного хоста хватило, чтобы нарушить работу финансовых транзакций глобально (hunt.io).

Проблема не в SIEM - Splunk Enterprise 9.x, Elastic 8.11, QRadar умеют всё, что описано выше. Проблема в дефиците людей, которые одновременно понимают MITRE ATT&CK, пишут SPL-запросы и знают, как выглядит легитимный SWIFT-трафик в два часа ночи. Вакансии Threat Hunter в крупных банках от 220 тысяч рублей до вычетов - и они висят месяцами, потому что рынок пуст. Пока банки ждут идеального кандидата, атакующие работают с тем, что есть - а у них есть 11 дней dwell time, и они тратят их с пользой. По свежим кампаниям на финансовый сектор на codeby.net разбираем IOC и detection на регулярной основе - если выстраиваете аналогичный процесс, стоит заглянуть.