Статья Пентест банковских приложений: от тестирования ДБО до detection-правил SOC

Четверг, 14:30. На пентесте интернет-банка - 800 тысяч клиентов-физлиц, Java-бэкенд с REST API - перехватываем запрос к GET /api/v2/accounts/{id}/statements и подменяем идентификатор счёта. В ответ приходит полная выписка чужого клиента: ФИО, номера счетов, суммы последних 50 операций. Классическая BOLA из OWASP API Security Top 10 (API1:2023). На эксплуатацию ушло 12 минут. SIEM банка за это время не выдал ни одного алерта. По данным Positive Technologies, в 7 из 8 протестированных банков внешний пентестер проникал из интернета в локальную сеть, а для полного контроля над инфраструктурой внутреннему атакующему хватало в среднем двух дней. По данным IBM и Financier Worldwide, средняя стоимость утечки в финансовом секторе в 2024 году - $6.08 млн, выше среднемирового уровня.

Статья для тех, кто на стороне защиты: SOC-аналитиков, security-инженеров, ответственных за detection в банках. Каждый атакующий вектор здесь идёт с блоком детекции - что корреляционные правила должны ловить и какие аномалии выдают пентестера (или реального атакующего) в вашей инфраструктуре.

Три поверхности атаки на ДБО и точки детекции​

Пентест банковских приложений - три отдельных скоупа с разными инструментами, TTP и точками детекции:

Поверхность	MITRE ATT&CK	Что ломают	Что SOC должен видеть
Веб-ДБО (интернет-банк)	Exploit Public-Facing Application (T1190), Brute Force (T1110)	IDOR, SQLi, business logic, session management	Аномальные паттерны доступа к API, перебор идентификаторов
Мобильный банк (iOS/Android)	Adversary-in-the-Middle (T1557), Input Capture (T1056)	SSL pinning bypass, небезопасное хранение токенов, реверс APK	Запросы без ожидаемых mobile fingerprints, нетипичные User-Agent
API платёжных систем	Steal Web Session Cookie (T1539), Financial Theft (T1657), Data Manipulation (T1565)	BOLA, race condition, JWT-атаки	Всплески запросов к транзакционным эндпоинтам, аномалии в JWT

Для Blue Team тут принципиальный момент: атака на ДБО - почти всегда цепочка. Никто не начинает с эксплуатации race condition в переводах. Сначала - разведка API (поиск shadow-эндпоинтов), затем обход аутентификации или повышение привилегий, и только потом удар по бизнес-логике. Если SIEM ловит только финальный шаг - вы опоздали.

Выбор вектора атаки​

Условие	Приоритетный вектор	Инструменты
Внешний пентест, скоуп = веб-ДБО	IDOR в API, business logic переводов	Burp Suite, Postman
Внешний пентест, скоуп = мобильный клиент	SSL pinning bypass, затем анализ API через прокси	Frida, objection, MobSF
Grey box, учётка клиента	Горизонтальная эскалация через IDOR, проверка JWT	Burp Suite, jwt_tool
Grey box, учётка оператора / инсайдер	Вертикальная эскалация, доступ к admin-панелям, эксфильтрация данных клиентов	Burp Suite, sqlmap на внутренних API

Последняя строка - сценарий инсайдерской угрозы, который банки обожают выкидывать из scope пентеста. А зря. Скомпрометированная учётка оператора ДБО или легитимный хост во внутренней сети - один из самых опасных векторов, потому что действия идут от доверенного источника. Без отдельных detection-правил для привилегированных операторских сессий SOC этот вектор не увидит.

Тестирование на проникновение ДБО: бизнес-логика и аутентификация​

Веб-интерфейс ДБО - самая широкая поверхность атаки на дистанционное банковское обслуживание. Здесь сосредоточены аутентифицированные потоки: логин, просмотр баланса, переводы, управление шаблонами, подтверждение операций через SMS/push.

IDOR в транзакционных API. Подмена идентификатора счёта или перевода в запросе - Broken Object Level Authorization из OWASP API Security Top 10. В банковском контексте импакт критичен: доступ к чужим выпискам, отмена чужих платежей, просмотр шаблонов переводов с реквизитами контрагентов. На практике IDOR встречается часто - разработчики полагаются на серверную сессию и не проверяют, принадлежит ли объект конкретному пользователю.

Ограничение: IDOR через прямой перебор работает только при предсказуемых идентификаторах (инкрементальные integer ID). Если банк использует UUID v4 - прямой перебор нереалистичен. Но UUID утекает через другие эндпоинты: историю операций, Referrer-заголовки, ответы со списками.

Обход бизнес-логики переводов. Манипуляция суммой перевода между этапами подтверждения, race condition при параллельной отправке нескольких переводов до списания средств (Unrestricted Access to Sensitive Business Flows, API6:2023). На одном проекте мы отправили 10 параллельных POST /api/v2/transfers на перевод по 50 000 рублей при балансе 50 000 - прошло 3 из 10, баланс ушёл в минус на 100 000.

Ограничение race condition: работает только при оптимистичной блокировке или отсутствии блокировки строки баланса при транзакции. Банки с двухфазным коммитом и пессимистичными блокировками на уровне СУБД к этой атаке устойчивы.

Перехват сессий и обход MFA. Подмена параметров SMS-кода, фишинг через подмену redirect_uri в OAuth2-потоке, кража сессионных куки через XSS (Steal Web Session Cookie, T1539). Согласно OWASP A01:2021 (Broken Access Control), 94% приложений содержали ту или иную форму нарушения контроля доступа.

Что SOC должен видеть при тестировании интернет-банкинга​

• IDOR-паттерн: один session_id обращается к ресурсам с разными account_id за короткий период. Правило: более 5 уникальных account_id в запросах от одной сессии за 60 секунд.
• Race condition: множественные идентичные POST /transfers с одного IP/сессии за 1-2 секунды. Нормальный клиент не шлёт 10 одинаковых переводов за секунду.
• MFA-brute: запросы к /otp/verify с разными кодами от одной сессии - перебор OTP. Порог: более 3 неудачных попыток за 5 минут (Brute Force, T1110).
• Вертикальная эскалация: обращения к admin-эндпоинтам из сессий с ролью «клиент». Тривиальное правило - но в половине банков его нет.

Пентест мобильного банка: SSL pinning, хранение токенов и реверс​

Мобильный клиент - та же API-поверхность, но с дополнительным слоем: клиентский код, который можно декомпилировать, модифицировать и запускать в контролируемой среде.

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

• ОС: macOS или Linux для Frida; рутованный Android-устройство или эмулятор (Genymotion, AVD с Google APIs x86)
• RAM: минимум 8 ГБ для эмулятора + Burp Suite одновременно
• Инструменты: Frida (стабильный релиз), objection, MobSF, jadx, Burp Suite Professional
• Для iOS: jailbroken-устройство или Corellium (облачный вариант, от $99/мес)

Что ломают при тестировании безопасности мобильного банкинга​

SSL pinning bypass - первый шаг. Без него не перехватить трафик между приложением и API. Стандартный подход: objection explore с командой android sslpinning disable. На практике банковские приложения ТОП-20 используют кастомные реализации pinning (OkHttp CertificatePinner, кастомный TrustManager), которые objection автоматически не снимает. Приходится писать Frida-хуки под конкретную реализацию, декомпилировав APK через jadx и найдя нужный класс.

Ограничение: на Android 13+ с аппаратным attestation (Play Integrity API) и на iOS с runtime-детектом jailbreak (iXGuard, Arxan) обход pinning усложняется существенно. Часть банков детектирует Frida по артефактам в памяти процесса - характерным строкам и открытым портам. Тогда нужен Frida с патченным server-бинарником или альтернативный подход через r2frida.

Небезопасное хранение данных. Проверка SharedPreferences (Android) и Keychain (iOS) на наличие токенов в открытом виде. Стандарт OWASP MASVS-AUTH требует хранения аутентификационных токенов в защищённом хранилище (Android Keystore, iOS Keychain с kSecAttrAccessibleWhenUnlockedThisDeviceOnly). На практике refresh_token в SharedPreferences без шифрования - распространённая находка. Иногда в логах обнаруживаются PAN-номера карт (прямое нарушение PCI DSS).

Реверс APK/IPA. Декомпиляция через jadx для поиска захардкоженных API-ключей, секретов, отладочных эндпоинтов. MobSF автоматизирует статический анализ и генерирует отчёт с маппингом на OWASP MASVS.

Что SOC должен видеть​

• Запросы без ожидаемых fingerprints: мобильный клиент шлёт характерные заголовки (X-App-Version, X-Device-ID, кастомные HMAC-подписи тела запроса). Запрос к мобильному API без этих заголовков - признак перехвата через прокси после SSL pinning bypass. Требование OWASP MASVS-NETWORK - TLS и certificate pinning - если нарушено, SOC увидит характерные аномалии.
• Нетипичный User-Agent: если мобильное API получает запросы с python-requests/2.28 или Java/1.8 вместо легитимного UA приложения - это атакующий или автоматизированный сканер.
• Геоаномалии: один device_id авторизуется из разных городов за 30 минут - для физического устройства это невозможно.

Безопасность API платёжных систем: BOLA, race condition и JWT​

API платёжных систем - ядро атаки с точки зрения импакта. Здесь эндпоинты переводов, подтверждения платежей, выписок. Оценка безопасности платёжных API строится вокруг OWASP API Security Top 10 (2023).

API1:2023 - Broken Object Level Authorization. Подмена идентификатора в запросах к /payments/{id}, /accounts/{id}/balance. Если сервер не проверяет принадлежность payment_id к текущей сессии - данные чужих платежей доступны.

API2:2023 - Broken Authentication. JWT-токены с алгоритмом alg:none (сервер принимает неподписанный токен), слабые секреты HS256 (подбираются через jwt_tool за минуты), отсутствие проверки exp. На реальном проекте встретили HS256 с секретом secret - три минуты от перехвата токена до полного контроля над сессией (Forge Web Credentials, T1606). Секрет secret. В 2024 году. В продакшене банка.

API4:2023 - Unrestricted Resource Consumption. Отсутствие rate limiting на эндпоинтах переводов позволяет автоматизировать массовый перебор идентификаторов или положить сервис тяжёлыми запросами к формированию выписок за длительный период.

Financial Theft (T1657) как итоговый impact цепочки: если промежуточные контроли обойдены, атакующий инициирует переводы на подконтрольные счета. По данным Positive Technologies, в трёх проектах из исследования такая возможность была продемонстрирована.

Что SOC должен видеть​

• JWT-аномалии: запросы с alg:none в заголовке JWT или с алгоритмом, отличным от ожидаемого (например, HS256 вместо RS256). Правило: парсить JWT в WAF или API Gateway и алертить на несоответствие.
• API enumeration: последовательные запросы с инкрементальными ID (.../payments/1001, .../payments/1002, ..., .../payments/1500) - характерный паттерн BOLA-эксплуатации.
• Аномальные объёмы транзакций: всплеск POST /transfers от одного пользователя. Baseline: нормальный клиент - 2-5 переводов в день, не 50 за минуту.

Detection-чеклист для SOC: корреляционные правила при пентесте финтех приложений​

Сводная таблица корреляционных правил, которые должны работать в SIEM банка - и во время пентеста, и при реальной атаке:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

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