Февраль 2016 года. Дака, Бангладеш. Обычное утро в Центральном банке страны. Сотрудники пьют чай, обсуждают планы на выходные, когда один из топ-менеджеров замечает странность: лоток принтера, который автоматически распечатывает подтверждения переводов от межбанковской системы SWIFT, опустел. Он перезагружает систему, но программа обмена с терминалом SWIFT не реагирует на команды. Начинают разбираться и выясняют: Федеральный резервный банк Нью-Йорка уже направил им запросы о более чем 40 сомнительных переводах на общую сумму 951 миллион долларов.
Кто-то вошёл в систему центробанка и отправил платежные поручения на перевод почти миллиарда долларов. Никаких масок, никаких гранатомётов, никаких вооруженных ограблений. Просто 35 поддельных запросов через SWIFT. 81 миллион долларов успешно ушли на счета в казино на Филиппинах и испарились в неизвестном направлении. Ещё 850 миллионов чудом застряли из-за орфографической ошибки: в одном из поручений слово "foundation" написали как "fandation". Банк-корреспондент Deutsche Bank запросил подтверждение, и афера вскрылась .
Управляющий Банка Бангладеш Атиур Рахман подал в отставку, заявив, что берёт на себя моральную ответственность за то, что немедленно не доложил в Министерство финансов о хищении. Но деньги уже утекли. Часть из них до сих пор не найдена.
Это был не просто взлом. Это был момент, когда банковский мир осознал: священная корова международных финансов - SWIFT - не такая уж священная. И главное - ломали не саму сеть. Ломали банки. Их сотрудников. Их процессы. Их безалаберность.
Эта статья - анатомия того, как уводят деньги из самой защищённой банковской системы планеты. Без конспирологии, без паники, но с жёсткой технической честностью. Разбор реальных кейсов, методы проникновения, инструменты хакеров, и главное - как от этого защищаться, когда регуляторы только чешут в затылке, а SWIFT разводит руками.
Почему это важно сейчас
Прошло почти десять лет с момента атаки на Bangladesh Bank, но проблема никуда не делась. Хакеры не перестали охотиться за банковскими миллиардами - они просто стали умнее, скрытнее и технологичнее. По данным Group-IB, группировка Cobalt, которая начинала с банкоматов и карточного процессинга, успешно переключилась на SWIFT, найдя надёжные каналы для обналичивания крупных сумм. Атаки на украинские банки через Carbanak/Akunak и Buhtrap показали, что традиционные средства защиты - межсетевые экраны и антивирусы - уже недостаточны для эффективного противодействия.
В 2026 году SWIFT ввёл новые жёсткие требования в рамках Customer Security Program (CSP) версии 2026, которые меняют правила игры для тысяч банков по всему миру . Понимание того, как работают эти атаки, становится не просто академическим интересом, а вопросом выживания для любой финансовой организации.
Что вообще такое SWIFT и почему он стал идеальной мишенью для хакеров
SWIFT (Society for Worldwide Interbank Financial Telecommunication) - это не банк и не платежная система. Это просто почтальон. Самый надёжный и быстрый почтальон в мире, но всё же почтальон. Он доставляет сообщения между банками: "Переведи столько-то денег со счёта А на счёт Б". И банки доверяют этим сообщениям настолько, что по ним реально двигают деньги.
Система была создана в 1973 году, когда 239 банков из 15 стран решили, что обмениваться платежными инструкциями через почту и телеграф - это уже не вариант. Транзакций становилось всё больше, ошибки и задержки - обычное дело. К 1977 году система заработала в полную силу, и с тех пор стала стандартом де-факто для международных расчётов.
Сегодня в систему входят более 11 500 финансовых организаций - банки, биржи, клиринговые палаты, инфраструктурные компании и даже крупные корпорации из более чем 200 стран. Через SWIFT ежедневно проходит более 35 миллионов транзакций. Объёмы, которые через неё проходят, измеряются триллионами долларов в день.
Как устроен SWIFT
SWIFT зарегистрирован в Бельгии и подчиняется законам ЕС, но по сути это кооператив, принадлежащий самим банкам-участникам. У него есть региональные департаменты: в США для трансатлантических операций, в Нидерландах для Европы, в Швейцарии резервный .
Чтобы подключиться к SWIFT, банку нужно специальное программное обеспечение. Есть два варианта: либо ставить свой собственный комплекс аппаратных и программных средств (Alliance Access и сопутствующее оборудование), либо подключаться через официального сервис-провайдера. В России до 2018 года таким провайдером была компания Alliance Factors, через которую шла техподдержка многих банков.
Каждый участник системы получает уникальный SWIFT-код (BIC - Bank Identifier Code). Это 8 или 11 символов, в которых зашифровано всё: первые 4 - сокращённое название банка, следующие 2 - код страны, ещё 2 - код города или региона, последние 3 (опционально) - код конкретного филиала.
Как работает передача сообщения
Когда ты делаешь SWIFT-перевод, никакие деньги физически не перемещаются. Твой банк просто отправляет сообщение банку-получателю: "Зачисли столько-то вон той валюты на вот этот счёт". Параллельно происходит межбанковский клиринг - взаиморасчёты между банками, но это уже технические детали, которые пользователя не касаются.
Процесс выглядит так:
- Инициирование. Банк-отправитель создает стандартизированное сообщение SWIFT с инструкциями по платежу. Это сообщение содержит все детали: сумму, валюту, данные получателя. Использование стандартизированного формата гарантирует, что любая система в мире однозначно поймет инструкцию.
- Передача. Сообщение безопасно передается через защищенную сеть SWIFT. Передача происходит практически мгновенно. Сеть SWIFT выступает в роли нейтрального посредника, гарантируя, что сообщение не будет изменено и будет доставлено по правильному адресу.
- Исполнение. Банк-получатель, получив сообщение, подтверждает его и использует свои корреспондентские счета, чтобы зачислить средства конечному бенефициару.
По данным самого SWIFT, 90% сообщений достигают банка-получателя в течение часа. Задержки обычно возникают не в сети SWIFT, а на этапе исполнения платежа - из-за разницы в часовых поясах, проверок или необходимости конвертации валют .
До 2023 года SWIFT использовала стандарт MT (Message Type). Разные виды сообщений маркировались кодами :
- MT101 - сообщение о платежах для корпоративных клиентов
- MT192 - запрос на отмену неисполненного платежа
- MT940 - выписка по счету
Почему это идеальная мишень для хакеров
Раньше в банковском мире работала концепция "безопасность через неизвестность" - мол, кто вообще знает про SWIFT кроме банкиров? После Bangladesh Bank об этом узнали все хакеры мира. Интернет сделал информацию о таких нишевых системах общедоступной, а их уязвимости - открытыми для изучения .
Проблема в другом: SWIFT проектировался в эпоху, когда главной угрозой были технические сбои, а не киберпреступники. Вся безопасность строилась на доверии между участниками и закрытости сети. Но закрытость не помогла, когда хакеры начали атаковать не сеть, а её пользователей - сами банки.
Как отмечает Дмитрий Волков из Group-IB, сама по себе система SWIFT неуязвима. Каких-то явных дыр, которые нужно срочно затыкать, в ней нет. Основная проблема - безопасность непосредственно банка, который эту систему использует . Хакеры получают доступ к компьютерам сотрудников через фишинг, исследуют внутреннюю сеть, находят терминал SWIFT и начинают от его имени слать платежки.
Исследователи BAE Systems, расследовавшие атаку на Bangladesh Bank, подтвердили: хакеры скомпрометировали клиентское ПО Alliance Access. Они использовали кастомный вредонос evtdiag.exe, который подменял данные в локальной базе, удалял записи о транзакциях и блокировал печать подтверждений. Но само ядро SWIFT затронуто не было.
Масштаб угрозы и статистика
После Bangladesh Bank SWIFT признал: угроза устойчива, адаптивна и изощрена, и она здесь, чтобы остаться. Стивен Гилдердейл, глава программы безопасности SWIFT, сообщил, что было зафиксировано значительное число атак, и примерно каждая пятая заканчивалась кражей денег.
Атаки затронули банки по всему миру: эквадорский Banco del Austro (потерял $12 млн), вьетнамский Tien Phong Bank (попытка на €1 млн, отражена), украинские банки (более $10 млн), российский Глобэкс (десятки миллионов рублей). И это только те, кто признался. Украинские чиновники говорили, что взломаны десятки банков, но многие не хотят светиться.
Эксперты FireEye и Symantec связали атаки с группировкой Lazarus, известной по взлому Sony в 2014 году. Код вредоносов, использованных в Bangladesh Bank, имел общие фрагменты с инструментарием Lazarus. То есть за атаками стояли не просто школьники, а профессиональная хакерская группа, возможно связанная с государством.
Разница в масштабах: банкоматы, карточный процессинг, SWIFT
И вот здесь начинается самое интересное. Если при атаке на банкоматы ты ограничен суммой в несколько сотен тысяч долларов (столько физически не унести из одного автомата), при взломе карточного процессинга - парой миллионов (можно поднять лимиты на десятках карт), то SWIFT-атака позволяет вывести из банка практически все средства, которые у него есть.
Дмитрий Волков объясняет: "Когда вы попытаетесь ограбить банк через систему межбанковских переводов, таких лимитов уже нет, вы можете вывести из банка практически все средства, которые у него есть. Пока рекорд, с которым мы сталкивались, - чуть больше полумиллиарда рублей". Но это только на тот момент. Bangladesh Bank показал, что можно увести и миллиард долларов, просто нужно иметь надёжные каналы для отмыва.
Хакеры из группы Cobalt, которая позже атаковала российские банки через SWIFT, долгое время обходили межбанковские переводы именно из-за сложности обналичивания. Но когда они нашли "правильных людей", способных отмыть такие суммы, переключились и на SWIFT.
Урок, который выучили все
После Bangladesh Bank даже JPMorgan Chase и Bank of England урезали количество сотрудников с доступом к платёжным системам. Стало очевидно: традиционные средства защиты - межсетевые экраны и антивирусы - уже недостаточны. Нужны поведенческий анализ, сегментация сети, многофакторная аутентификация для крупных переводов и постоянное обучение сотрудников, потому что фишинг остаётся главным входным билетом для хакеров.
В расследовании Bangladesh Bank выяснилось, что операции SWIFT были изолированы или плохо, или никак. Упоминались 10-долларовые подержанные свитчи, отсутствие файервола между SWIFT-инфраструктурой и всем остальным, включая Интернет. Полиция склонна винить как сам банк, так и представителей международной платежной системы: последние внезапно узнали, что операции SWIFT не защищены, когда уже было поздно.
Разбор атаки на Bangladesh Bank
Самый громкий кейс в истории SWIFT-мошенничества. Разбираем по костям, как хакеры провернули операцию на 81 миллион долларов и почему их не остановили.Шаг 1: Разведка и проникновение
Как именно хакеры залезли в сеть Центробанка Бангладеш - до сих пор предмет споров. Официальное следствие считает, что злоумышленники проникли в компьютерную сеть и взяли под контроль учётные данные для доступа к SWIFT. Версии назывались разные: фишинг, инсайдер, уязвимости в софте. По данным полиции Бангладеш, в деле замешаны сами сотрудники банка - кто-то сознательно подставил системы. У ФБР имеются доказательства того, что, по крайней мере, один из сотрудников Центрального банка Бангладеш был соучастником преступления.
Главное, что хакеры получили доступ к клиентскому программному обеспечению SWIFT - Alliance Access. Это интерфейс, через который банк отправляет и получает сообщения. Дальше началось самое интересное.
Шаг 2: Наблюдение и изучение
Хакеры не стали сразу дёргать миллиарды. Они залегли на дно и несколько месяцев просто наблюдали. Изучали, как печатаются платежные поручения, как они подтверждаются, в каком формате, в какое время суток обычно проходят крупные транзакции. Кто подписывает, кто контролирует, какие лимиты стоят.
Это классическая тактика любой серьёзной APT-группировки: сначала разведка, потом действие. Они не просто хотели украсть деньги - они хотели сделать это незаметно. По данным ISACA, после проникновения в банк хакеры несколько месяцев тщательно изучают его работу и внутренние процессы, после чего используют полномочия легитимных пользователей для создания платежей.
Шаг 3: Вредоносное ПО и уязвимость в Alliance Access
Британская компания BAE Systems, которая занимается информационной безопасностью, обнаружила то, чего никто не ожидал. Хакеры использовали кастомную вредоносную программу evtdiag.exe, написанную специально для этой атаки. Экземпляры вредоносного ПО были загружены в онлайн-репозитории вредоносных программ кем-то из Бангладеш.
Что делал этот вирус:
- Он позволял скрыть следы атаки, изменяя данные в локальной базе, которая отслеживает запросы на транзакции.
- Мог удалять записи об исходящих запросах - то есть в системе банка не оставалось информации о том, что переводы вообще отправлялись.
- Перехватывал входящие сообщения, подтверждающие проведение переводов.
Особенно впечатляет техника обхода проверок: вредоносное ПО производило замену двух байтов в оперативной памяти, соответствующих команде условного перехода, на два байта, содержащие команду, не производящую никаких действий. Эти байты следовали после проведения важной процедуры проверки, например, валидности ключа или результата авторизации. Замена байтов приводила к тому, что работа прикладной программы всегда завершалась с результатом, соответствующим успешному прохождению проверки .
Проще говоря, вирус делал банк слепым. Операторы не видели, что деньги уходят, и не получали подтверждений, что они уже ушли. Именно поэтому лоток принтера с подтверждениями опустел - программа просто не давала принтеру печатать. Вредоносное ПО перехватывало подтверждающие сообщения SWIFT, изменяло их и направляло на печать уже "модифицированные" версии, позволяющие скрыть совершение мошеннических транзакций.
Шаг 4: Отправка поддельных сообщений
В пятницу, 5 февраля 2016 года, хакеры отправили 35 запросов в Федеральный резервный банк Нью-Йорка на перевод почти миллиарда долларов. В каждом поручении стояли правильные подписи, корректные форматы, верные маршруты. Для ФРБ Нью-Йорка это были легитимные запросы от Центробанка Бангладеш.
Атака была проведена накануне уик-энда (в Бангладеш это пятница и суббота), что давало хакерам дополнительное время, пока банк не работал.
Деньги пошли. 81 миллион долларов ушли на счета филиппинских казино и банков. Операции прошли успешно.
Шаг 5: Орфографическая ошибка, которая спасла миллиард
В одном из платежных поручений слово "foundation" было написано как "fandation". Мелочь, опечатка, невнимательность. Но когда этот запрос дошёл до Deutsche Bank - банка-корреспондента, через который шли деньги, - тамошние операторы засомневались. Транзакция была слишком крупной для такой страны, как Шри-Ланка, куда направлялись средства. Они запросили подтверждение у Центробанка Бангладеш .
И тут выяснилось, что никаких переводов банк не заказывал. Операция вскрылась. Оставшиеся 850 миллионов долларов успели заблокировать. Уже переведенные 20 миллионов долларов в Шри-Ланку удалось вернуть .
Шаг 6: Вывод средств и последствия
81 миллион долларов ушли на счета в казино на Филиппинах. Часть денег прокрутили через игорный бизнес, часть обналичили и вывезли. Следы тянулись в разные стороны, но найти и вернуть всё до сих пор не удалось.
На Филиппинах сыграл свою роль китайский Новый год: когда Банк Бангладеш уведомил местный банк RCBC о факте мошенничества, сотрудники филиппинского банка не могли вовремя принять меры из-за праздников. Когда наконец все вышли на работу, кто-то уже снял со счета 58,15 миллиона долларов по подложным документам .
Управляющий Центробанка ушёл в отставку. Система SWIFT получила мощнейший удар по репутации. И главное - стало понятно, что такие атаки могут повториться где угодно. Инструменты, методы и алгоритмы, которые использовались в этом взломе, могли позволить злоумышленникам нанести новый удар в любой точке мира .
Часть 3: SWIFT не взламывали - взламывали банки (Подробная версия)
Ключевой момент, который SWIFT вдалбливает клиентам после 2016 года
После Bangladesh Bank разразилась паника. Журналисты пестрели заголовками про "взлом SWIFT", про "дыры в системе", про то, что международные платежи больше не безопасны. Но SWIFT отбивался и продолжает отбиваться до сих пор: сама сеть чиста. Ни одного взлома центральной инфраструктуры не было и нет.
И это правда. Атаки шли на пользователей - на банки, их сотрудников, их локальные интерфейсы. Хакеры не ломали шифры SWIFT и не проникали в дата-центры. Они просто залезали в компьютеры банковских служащих и оттуда отправляли легитимные запросы.
Техническое подтверждение от разработчиков
Британская компания BAE Systems, которая занимается информационной безопасностью и расследовала взлом, подтвердила: злоумышленники скомпрометировали клиентское программное обеспечение SWIFT, известное как Alliance Access . Они использовали кастомную вредоносную программу evtdiag.exe, которая была специально написана для этой атаки и загружена в онлайн-репозитории вредоносных программ кем-то из Бангладеш.
Сами разработчики SWIFT официально заявили: "Вредоносное ПО не оказывает влияния на сеть SWIFT или основные сервисы обмена сообщениями" . Представитель SWIFT Наташа Детеран пояснила, что ключевая защита от подобных сценариев атак заключается в том, чтобы пользователи внедряли соответствующие меры безопасности в своих локальных средах .
Как объясняют эксперты
Дмитрий Волков из Group-IB (на тот момент руководитель отдела расследований инцидентов) чётко сформулировал основную проблему: безопасность непосредственно банка, который использует SWIFT. Хакеры получают доступ к одному компьютеру через фишинг, исследуют внутреннюю сеть, находят терминал SWIFT и начинают от его имени слать платежки.
Аналитики SentinelOne добавляют важный нюанс: "Организации могут вложить ноль долларов в периферийную защиту, а могут вложить сто тысяч - какой-нибудь злоумышленник всё равно сможет её обойти. Ваше предположение должно заключаться в том, что кто-то именно это и сделал" . То есть подход должен быть не "как не пустить", а "как обнаружить, когда уже пустили".
Масштаб проблемы: статистика атак
После Bangladesh Bank SWIFT начал публиковать статистику, и цифры оказались пугающими. Стивен Гилдердейл, глава программы безопасности SWIFT (Customer Security Programme), сообщил Reuters, что было зафиксировано "значительное число" атак, и примерно каждая пятая заканчивалась кражей денег . В другом интервью он уточнил: "В 80% случаев, о которых нам известно и по которым мы завершили расследования, мошенничество фактически не произошло".
В частном письме клиентам SWIFT признал: "Среды клиентов были скомпрометированы, и впоследствии были предприняты попытки отправить мошеннические платежные поручения. Угроза устойчива, адаптивна и изощренна - и она здесь, чтобы остаться".
Важный нюанс: невозможно точно сказать, увеличивается ли частота атак, потому что раньше SWIFT не отслеживал и не получал от клиентов информацию об инцидентах.
Что объединяет всех жертв
SWIFT провёл анализ и выявил общий знаменатель: у всех жертв были слабости в локальной безопасности, которые атакующие использовали для компрометации локальных сетей и отправки мошеннических сообщений с запросами на перевод денег . Банки различались по размеру и географии, использовали разные методы доступа к SWIFT, но проблема была одна - дырявая защита на местах.
Почему это важно для банков
SWIFT может разводить руками и говорить "мы тут ни при чём", но репутация системы всё равно страдает. Банки теряют доверие, клиенты нервничают, регуляторы усиливают требования. И ответственность за безопасность ложится на сами банки.
При этом у SWIFT нет регуляторных полномочий над своими членами - это кооператив, принадлежащий самим банкам. Поэтому заставить их соблюдать безопасность сложно . Единственный рычаг давления - публичность и репутационные риски. SWIFT начал угрожать, что будет сообщать регуляторам и банкам-партнёрам о нарушениях безопасности, если те не соответствуют требованиям. Как отмечает независимый консультант Шейн Шук, "такой обмен информацией - это то, что ни один банк не хочет видеть без своего прямого одобрения и участия, потому что это может повлиять на доверие рынка".
И самое страшное: хакеры могут вывести из банка практически все средства. Нет лимитов, нет дневных ограничений, как в банкоматах. Если ты получил доступ к терминалу SWIFT, ты можешь увести всё.
Слепая зона: безопасность окружения
В расследовании Bangladesh Bank выяснились шокирующие детали. Компьютеры, подключенные к SWIFT, были связаны с остальной сетью через дешёвые подержанные коммутаторы за 10 долларов без возможности управления и без файерволов . Фактически между SWIFT-инфраструктурой и интернетом не было никакого защитного барьера.
Представители полиции Бангладеш прямо заявили: меры компьютерной безопасности банка были серьёзно недостаточными, отсутствовали даже базовые меры предосторожности, такие как файерволы . В комнате SWIFT на восьмом этаже здания в Дакке стояли четыре сервера, четыре монитора и принтер. Физически помещение было защищено, но правила традиционной IP-маршрутизации означали, что комната была открыта в общую сеть .
При этом полицейские следователи считают, что вина лежит как на банке, так и на SWIFT: "Их обязанностью было указать на это, но мы не нашли никаких доказательств того, что они предупреждали до ограбления", - заявил Мохаммад Шах Алам, глава Института криминалистики полиции Бангладеш .
Эволюция тактик хакеров
В письме клиентам SWIFT предупредил, что хакеры совершенствуют методы компрометации локальных банковских систем. Одна из новых тактик - использование легитимного ПО для удалённого доступа, которое техподдержка применяет для подключения к компьютерам .
Стивен Гилдердейл также отметил, что во всех случаях вторжения были задействованы интерфейсы SWIFT клиентов, а центральная коммуникационная сеть SWIFT не была скомпрометирована.
Выводы для банков
Эта часть истории Bangladesh Bank - самый важный урок для любого финансового учреждения. Нельзя надеяться, что SWIFT защитит сам по себе. Его сеть безопасна, но оканчивается она на твоём сервере. А дальше начинается твоя территория, и защищать её - твоя забота.
Банкам пришлось экстренно пересматривать подходы к безопасности. JPMorgan Chase и Bank of England, например, урезали количество людей с доступом к платёжным системам. Регуляторы по всему миру начали требовать от банков детальных отчётов о защите компьютеров, подключённых к SWIFT.
И главный вывод, который сделали эксперты: традиционные средства защиты - межсетевые экраны и антивирусы - уже недостаточны. Нужны инструменты, которые детектят вредоносное ПО по поведению, а не по сигнатурам, и предполагают, что взлом уже произошёл.
Волна атак после Bangladesh Bank - кто еще пострадал
Bangladesh Bank был не единственным. После него прокатилась волна атак по всему миру. Хакеры поняли, что метод работает, и начали штамповать похожие схемы.Эквадор, Banco del Austro
Ещё до громкого взлома в Бангладеш, в 2015 году, хакеры атаковали эквадорский Banco del Austro. 12 миллионов долларов ушли через поддельные SWIFT-сообщения. Обнаружили поздно, деньги уплыли.
Вьетнам, Tien Phong Bank
2016 год. Попытка увести деньги из вьетнамского банка. Успели остановить, но сам факт показал: атаки становятся массовыми. Транзакции на общую сумму более 1 миллиона евро были приостановлены самим банком.
Украина, несколько банков
10 миллионов долларов ушло через SWIFT из украинского банка. Местные чиновники заявили, что взломаны и другие банки в Украине и России. Международные кибергруппировки Carbanak/Akunak и Buhtrap создали и разместили в открытом интернет-доступе набор инструментов для проникновения в банки и другие финансовые учреждения.
По данным киевского отделения ISACA, традиционные средства защиты - межсетевые экраны и антивирусы - недостаточны для эффективного противодействия подобным кибератакам. На тот момент были скомпрометированы десятки банков (в основном в Украине и России), из которых украдены сотни миллионов долларов.
Россия, Глобэкс
15 декабря 2017 года - первая подтверждённая атака на российский банк через SWIFT. Группировка Cobalt, которая до этого специализировалась на банкоматах и карточном процессинге, переключилась на межбанковские переводы. Увели несколько десятков миллионов рублей. По данным Group-IB, хакеры проникли в сеть банка через вредоносное ПО, которое рассылали фишинговыми письмами несколько недель.
Это была первая успешная атака на SWIFT в России, но далеко не последняя. Эксперты отмечали, что для обналичивания таких сумм нужна целая группа профессионалов с надёжными каналами отмыва денег.
По данным главы программы безопасности SWIFT Стивена Гилдердейла, после Bangladesh Bank было зафиксировано множество атак, и каждая пятая заканчивалась кражей денег. В мае 2016 года SWIFT разослала тысячам своих клиентов уведомления о второй крупной кибератаке на банк, но подробностей не раскрыли.
Глобальный масштаб
Атаки не ограничивались одной страной или регионом. Они показали, что уязвимость универсальна. В апреле 2016 года SWIFT разослала тысячам своих клиентов уведомления, сообщив, что было зафиксировано множество случаев, когда хакеры отправляли фиктивные платежные поручения, имитируя сообщения SWIFT.
Разберём методы, которые использовали злоумышленники в разных атаках.Кейлоггеры и инфостилеры
Первый этап - кража учётных данных сотрудников, имеющих доступ к SWIFT-терминалам. Хакеры засылают вредоносное ПО, которое записывает нажатия клавиш, копирует файлы с паролями, собирает логины.
Фишинг как основной способ проникновения
Основной способ получения доступа в сеть банка - отправка фишингового письма с вредоносным вложением. Если сотрудники банка открывают это вложение, на их компьютер попадает вредоносная программа, которая предоставляет злоумышленнику удалённый доступ .
Атаки становятся всё более сложными. Хакеры изучают адреса электронной почты сотрудников, отвечающих за противодействие отмыванию денег, и отправляют им письма, выполненные как будто на фирменном бланке службы финансового мониторинга. Оформление, адрес, должности - всё очень похоже на настоящие. Сотрудник обязан такое читать, открывает - и получает заразу.
Вредоносное ПО может быть установлено не только через вложения, но и при посещении взломанных сайтов, с которых пользователь автоматически попадает на сервер с набором эксплойтов, или при скачивании модифицированных версий легитимных программ.
Исследование внутренней сети
Получая доступ к одному компьютеру, злоумышленник начинает исследовать внутреннюю сеть банка. С помощью специализированных средств, таких как Mimikatz, перехватываются пароли администраторов домена, и хакеры получают контроль над всеми ПК, подключенными в домен.
Для подобного рода атак они используют уже готовые инструменты. Сами по себе инструменты редко меняются. Отслеживать проникновение этой группы достаточно легко, технические средства, позволяющие эффективно это делать, есть. Но, к сожалению, не все банки их используют.
Длительное наблюдение
Преступники исследуют работу банка и выявляют наиболее ценные рабочие места и серверы. На них устанавливаются программы, которые перехватывают и передают злоумышленникам копии экрана. Этот процесс длится несколько месяцев . Хакеры ожидают оптимального времени для атаки, например, когда на корреспондентских счетах больше денег.
Инсайдеры
Версия для Bangladesh Bank - кто-то из своих помог или сознательно подставил систему. Полностью исключать участие сотрудников нельзя, особенно когда речь о таких суммах. Официальные лица Бангладеш предполагали, что часть вины может лежать на сотрудниках Федерального резервного банка Нью-Йорка, через который осуществлялись мошеннические транзакции.
Атака на бэк-офисы
Хакеры проникают не в сам SWIFT, а в компьютеры, с которых банки подключаются к сети. Им не нужно ломать шифры - им нужно найти терминал Alliance Access и отправить оттуда сообщение.
Удаление следов
В случае с Bangladesh Bank хакеры использовали специальный вирус, который чистил логи и блокировал печать подтверждений. Операторы банка просто не знали, что деньги уходят. Вредоносное ПО мониторило сообщения SWIFT Financial Application на предмет строк, определённых в зашифрованном конфигурационном файле. Когда оно находило совпадение, то идентифицировало соответствующую запись в базе данных и удаляло её.
Использование легитимных инструментов
Хакеры научились использовать софт для удалённого администрирования, чтобы сливаться с обычным трафиком. Они не тащат свои экзешники - они используют то, что уже есть в системе.
Сложность обналичивания
Вывести деньги через SWIFT - полдела. Их ещё надо обналичить и отмыть. Как отмечает Дмитрий Волков, для этого нужна группа профессионалов, которые могут провернуть такие схемы. Именно поэтому хакеры не сразу переключились на SWIFT - долго искали надёжные каналы для вывода крупных сумм.
Когда группировка Cobalt появилась, их основной целью были банкоматы. Они провели большое количество успешных атак в России, на постсоветском пространстве, в том числе в некоторых азиатских странах. После этого переключились на карточный процессинг. Но при этом они всегда старались обходить системы межбанковских переводов из-за сложности обналичивания .
Ответ SWIFT - Customer Security Programme (CSP)
После волны атак SWIFT понял: если так пойдёт дальше, системе конец. Клиенты потеряют доверие, регуляторы начнут душить требованиями, бизнес рухнет. Нужно было что-то делать.Рождение CSP
В 2016 году SWIFT запустил Customer Security Programme (CSP) - программу безопасности клиентов. Это был не просто набор рекомендаций, а жёсткие обязательные требования для всех участников. Банки больше не могли отмазываться "у нас всё хорошо". Главная цель - усиление безопасности глобального финансового сообщества .
Структура требований
CSP определяет Customer Security Control Framework (CSCF) - набор controls (элементов контроля), разделённых по целям и принципам безопасности. На текущий момент это 32 контроли, разбитые на три группы: обязательные и рекомендательные. Для финансовых институтов CSP становится всё более важным в рамках программ риска и комплаенса, создавая добавленную стоимость, выходящую за рамки простого соблюдения требований .
Контроли делятся по типу архитектуры банка (A1-B) - в зависимости от того, как именно банк подключён к SWIFT и насколько использует внешнюю инфраструктуру.
Ключевые изменения CSP версии 2026
Версия 2026 года вносит серьёзные изменения, которые затронут тысячи банков :
- Контроль 2.4 "Back Office Data Flow Security" становится обязательным (ранее был рекомендательным). Потоки данных между back office и SWIFT Secure Zone должны быть защищены сквозным шифрованием с использованием сильных алгоритмов .
- Customer Client Connectors (CCC) становятся обязательными для многих контролей. Сюда входят клиенты передачи файлов, middleware, API-эндпоинты, API-подключения treasury/ERP. Эти CCC-компоненты становятся обязательными для контроля 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1, 6.4 .
- Изменение архитектурного типа с B на A4. Компании, использующие API, middleware или file transfer client для отправки платежей, теперь классифицируются как тип A4 вместо B. Это добавляет 8 новых контролей в scope (4 обязательных, 4 рекомендательных) .
Все операторы SWIFT обязаны ежегодно проводить независимую оценку соответствия обязательным контролям. Оценка может быть:
- Внутренней - проводится силами второй или третьей линии защиты банка (комплаенс, риск-менеджмент, внутренний аудит) при условии независимости от первой линии.
- Внешней - проводится независимой организацией с опытом в кибербезопасности.
Роль сертифицированных асессоров (Certified Assessors)
SWIFT ввела программу сертификации асессоров для повышения квалификации независимых оценщиков и стандартизации качества по всему миру . Certified Assessors должны пройти интенсивное обучение, иметь соответствующие сертификаты (ISO 27001 Lead Auditor, CISA) и сдать строгие экзамены SWIFT.
Преимущества работы с Certified Assessor :
- Признанная экспертиза
- Фокус на безопасности
- Доступ к экспертным круглым столам и рабочим группам
Оценка охватывает :
- Технические и организационные процессы обеспечения защиты информации
- Уровень осведомлённости сотрудников в области ИБ
- Соответствие архитектуры и инфраструктуры требованиям
- Оценку документов (руководства, документация)
- Проведение интервью (пользователи и администраторы)
- Анализ соответствия целевого состояния и проверку через сравнение "цель-факт"
Последствия несоответствия
Если банк не соответствует требованиям и не проходит оценку, SWIFT может его отключить от сети. Это крайняя мера, но она работает. Все участники видят статус compliance друг друга - публичность стимулирует.
Пример: российский Москоммерцбанк проходил такую оценку через "ДиалогНауку" в 2026 году и подтвердил выполнение всех обязательных контролей.
Эволюция требований
CSP постоянно обновляется. Как отмечают эксперты, киберугрозы эволюционируют быстро, и программа будет развиваться дальше: появляться новые контроли, рекомендательные переходить в обязательные. То, что вчера было опцией, завтра станет жёстким требованием.
Технологии защиты - LAU, шифрование и контроль подлинности
Требования CSP - это хорошо, но нужны конкретные технические решения. Главная защита на уровне банка - контроль целостности сообщений SWIFT. SWIFT официально рекомендует и сделал обязательным использование технологии локальной аутентификации (LAU).Как работает LAU
LAU (Local Authentication) - это механизм, позволяющий банку подписывать исходящие сообщения и проверять подлинность входящих. Используется HMAC-SHA256 - ключ хэширования, известный только банку и терминалу SWIFT .
Процесс выглядит так:
- Сообщение подписывается ключом перед отправкой.
- На входе сообщение проверяется на подлинность.
- Если в сообщение вмешаться при передаче между источником и получателем, контрольная сумма не сойдётся, указывая на нарушение целостности .
- Все операции происходят в бесфайловом режиме - никаких промежуточных файлов, которые можно перехватить или подменить .
Внедрение в АБС
Российские разработчики уже встроили LAU в свои автоматизированные банковские системы. Например :
- Продукт "Защита сообщений SWIFT" для системы Diasoft FA# Beans от компании "Диасофт"
- ЦФТ-Банк от компании ЦФТ
Многофакторная аутентификация и контроль доступа
LAU - это не единственная защита. В требованиях CSP также есть жёсткие правила доступа:
- Принцип наименьших привилегий. Никаких лишних доступов. Только те, кому реально нужно, и только на то время, когда нужно.
- Многофакторная аутентификация (контроль 4.2). Для крупных переводов - отдельное подтверждение, желательно из другого канала.
- Разделение ролей. Один человек не может создать, подписать и отправить платёж.
Контроль 2.4A "Back Office Data Flow Security" требует обеспечения конфиденциальности, целостности и аутентичности данных, которыми обмениваются системы back office и локальные или внешние компоненты инфраструктуры SWIFT. Проще говоря, это о защите коммуникаций между SWIFT и твоим бэк-офисом с помощью сильных алгоритмов шифрования .
Customer Client Connectors (CCC)
Введённые в 2025 году CCC будут массово расширены в 2026. Это включает клиентов передачи файлов, middleware, API-эндпоинты, API-подключения treasury/ERP. Для многих компаний, ранее классифицированных как тип B, это означает переход в тип A4 и необходимость соответствия дополнительным контролям .
Технический мониторинг
Технологии идут дальше. Внедрение мгновенных платежей требует новых подходов к мониторингу. Необходимы автоматизированные инструменты, желательно на базе AI, для выявления аномалий в реальном времени. Когда на обработку платежа есть меньше трёх секунд, человек просто не успеет среагировать.
Организационные меры
Технологии без процессов - мёртвый груз. Можно поставить самую крутую LAU, но если сотрудник открывает фишинговые письма и вводит пароли на левых сайтах, никакая криптография не спасёт. Анализ атак на SWIFT показал три главных урока.Урок 1: Разделение доступа (принцип наименьших привилегий)
Нельзя давать всем сотрудникам доступ к SWIFT-терминалам. Только тем, кому реально нужно. И даже им - только на то время, когда нужно. После Bangladesh Bank многие банки пересмотрели свои политики. JPMorgan Chase и Bank of England, например, урезали количество людей с доступом к платёжным системам.
В CSP это закреплено жёсткими требованиями. Аудит проверяет, кто имеет доступ, как он предоставляется, как отзывается, есть ли лишние учётки.
Урок 2: Многофакторная аутентификация для крупных переводов
Вход по логину-паролю - это прошлый век. Для транзакций выше определённого порога нужно отдельное подтверждение из другого канала. Апп-токен, SMS, аппаратный ключ, второй согласующий - всё что угодно, лишь бы злоумышленник не мог отправить миллиард одной левой.
Урок 3: Обучение сотрудников
Большинство атак начинается с фишинга. Хакеры изучают структуру банка, находят ответственных за платежи и шлют им письма, которые выглядят как официальные запросы. Сотрудники должны знать, как выглядят такие письма, что делать, если что-то пошло не так, куда сообщать о подозрениях.
В CSP это control 7.2 "Security Training and Awareness". Требуется не просто провести лекцию раз в год, а регулярно тестировать сотрудников, проверять их осведомлённость и фиксировать результаты.
Павел Луцик из компании КРОК подчёркивает важность гибкого выстраивания процессов управления информационной безопасностью, включая процессы повышения осведомлённости конечных пользователей в вопросах безопасности и реагирования на инциденты .
Урок 4: Мониторинг аномалий
Если бухгалтер, который обычно переводит тысячи, вдруг отправляет миллионы - система должна орать благим матом и блокировать транзакцию до ручного подтверждения. Это не rocket science, но многие банки до сих пор не используют поведенческий анализ.
Комплекс технических средств должен включать межсетевые экраны нового поколения, антивирусы, антиспам-решения, средства анализа защищенности, регулярное обновление и анализ на уязвимости используемого ПО, а также "песочницы" и анализаторы сетевых аномалий для сигнализации о подозрительных активностях .
Урок 5: Управление инцидентами и отчётность
У многих банков проблемы с управлением инцидентами. Когда происходит атака, они теряют время на то, чтобы понять, что делать. В Европе с января 2025 года действует DORA (Digital Operational Resilience Act), требующая жёстких сроков отчётности о серьёзных инцидентах. Банки, работающие с EU, должны соответствовать.
Урок 6: Управление рисками третьих сторон (TPRM)
Многие банки отдают обработку платежей на аутсорсинг - SWIFT Service Bureau. Это создаёт слепые зоны. В 2024 году глобальный сбой CrowdStrike показал: банки, которые пользовались услугами таких бюро, обнаружили, что их платежи встали, хотя они сами CrowdStrike не использовали. Зависимость от третьих сторон - это риск, который надо контролировать.
SWIFT сделал контроль 2.8 "Outsourced Critical Activity Protection" обязательным для всех архитектур в 2024 году. Требуется проводить аудит вендоров, проверять их безопасность, особенно в свете роста supply chain атак.
Урок 7: Сегментация сети
Расследование Bangladesh Bank показало, что компьютеры, подключенные к SWIFT, не были должным образом сегментированы от остальной сети. Они были связаны через дешёвые коммутаторы без управления и без файервола . Правильная сегментация могла бы ограничить возможности хакеров по перемещению внутри сети.
Урок 8: Борьба с вредоносным ПО
Традиционные антивирусные программы могут быть недейственны, если преступное ПО было только скомпилировано (атака класса APT или ZERO-DAY), упаковано или закриптовано специальной программой-пакером . Необходимы более продвинутые средства защиты, включая поведенческий анализ.
SWIFT в России
До 2018 года у SWIFT в России была уникальная схема: техническая поддержка шла не напрямую, а через компанию-посредника Alliance Factors. И это создавало серьёзные риски.В чём была проблема
Alliance Factors имела доступ ко всей конфиденциальной информации российских банков - IP-адреса, данные критической инфраструктуры, логи соединений. При этом на сайте SWIFT не было никакой информации об Alliance Factors, и никто не знал, как они обращаются с данными.
После атаки на Bangladesh Bank опасения только усилились. Банки сами попросили убрать посредника, потому что непонятно было, насколько безопасно хранение данных и кто вообще контролирует эту компанию.
Что изменилось
С 2018 года российские банки перешли на прямое взаимодействие со SWIFT. Техническая поддержка теперь идёт напрямую, без третьей стороны. Это повысило прозрачность и снизило риски утечек.
Текущая ситуация
Сейчас российские банки, как и все участники SWIFT, обязаны проходить ежегодную оценку CSP. Есть сертифицированные провайдеры, которые это делают - например, "ДиалогНаука" и дочерняя структура ФБК. Москоммерцбанк в 2026 году подтвердил соответствие всем требованиям.
В условиях санкций и геополитической напряжённости значение SWIFT для России только выросло. Система остаётся ключевым каналом межбанковских коммуникаций, и вопросы безопасности данных выходят на первый план.
Если вы отвечаете за безопасность в банке и ещё не поседели - вот что нужно проверить немедленно. Это не просто список, а руководство к действию.
1. Выполнены ли требования CSP версии 2026?
Проверьте, все ли обязательные контроли закрыты. Если нет - аудит покажет, и SWIFT может отключить. Нанимайте сертифицированных провайдеров - Certified Assessors из официальной директории SWIFT. Учитывайте изменения архитектуры: если вы используете API, middleware или file transfer client, вы теперь тип A4, а не B, и должны соответствовать 8 новым контролям.
2. Внедрена ли LAU-аутентификация?
Сообщения должны подписываться и проверяться на подлинность с использованием HMAC-SHA256. Без этого любое поддельное сообщение может пройти. Если ваша АБС не поддерживает LAU - срочно обновляйте или ищите обходные пути.
3. Защищены ли back office потоки данных?
Контроль 2.4A становится обязательным в 2026. Убедитесь, что все потоки данных между back office и SWIFT Secure Zone защищены сильными алгоритмами шифрования .
4. Кто имеет доступ к SWIFT-терминалам?
Проведите ревизию. Уберите лишних. Введите двухфакторку (контроль 4.2). Проверьте, не висят ли учётки уволенных сотрудников. Разделите роли: создание платежа, подписание, отправка - разные люди.
5. Есть ли мониторинг аномальных транзакций?
Система должна бить тревогу на нестандартные переводы. Поведенческий анализ - не роскошь, а необходимость. Для мгновенных платежей нужен AI-мониторинг в реальном времени.
6. Учат ли сотрудников безопасности?
Не раз в год для галочки, а постоянно, с тестированием на фишинг. Проверяйте, открывают ли ваши бухгалтеры письма от "службы мониторинга". Если открывают - учите заново.
7. Проводились ли пентесты SWIFT-инфраструктуры?
Имитация реальной атаки на интерфейсы и терминалы. Пусть ваши red team попробуют пробиться. Лучше они найдут дыру, чем хакеры.
8. Есть ли резервный канал подтверждения?
Крупные переводы должны подтверждаться по телефону, через отдельное защищённое соединение или вторым лицом. Никаких "одной левой".
9. Как у вас с управлением инцидентами?
Есть ли план реагирования? Протестирован ли он? Знают ли сотрудники, кому звонить при подозрении на взлом? В европейских банках это обязательное требование.
10. Кто ваши третьи стороны?
Проверьте вендоров, аутсорсеров, сервис-бюро. Если они падают, падаете и вы. Требуйте от них отчёты, проводите аудиты. SWIFT требует контроля 2.8 "Outsourced Critical Activity Protection" - выполняйте.
11. Соответствует ли ваша архитектура современным требованиям?
Внедрение мгновенных платежей требует новых RTO, новых сценариев фрода, новых технических решений. Если вы всё ещё надеетесь на ручную проверку, вы проиграете.
12. Проверьте обновления Alliance Access
SWIFT выпускает обновления для клиентского ПО. Убедитесь, что они установлены. После Bangladesh Bank было выпущено специальное обновление для выявления попыток уничтожения следов .
Заключение
Атаки на SWIFT показали одну простую вещь: даже самая защищённая сеть в мире бесполезна, если у тебя гнилые процессы внутри. Хакеры не ломали SWIFT - они ломали банки. Их сотрудников, их политики, их безалаберность.Bangladesh Bank стал моментом истины. Если бы не дурацкая опечатка в слове "foundation", ушёл бы весь миллиард. И никто бы ничего не понял до понедельника. Это был звонок для всей финансовой индустрии.
После 2016 года система стала безопаснее. SWIFT ввёл обязательные требования CSP, банки начали проходить аудит, появились технологии LAU и другие защиты. Но война не закончена. Хакеры эволюционируют - используют софт удалённого администрирования, инсайдеров, новые методы обхода. Управление рисками третьих сторон становится критичным. Реагирование на инциденты - обязательным.
Версия CSP 2026 года ужесточает требования, особенно для банков, использующих API и middleware. Тысячи финансовых организаций по всему миру будут вынуждены пересмотреть свою архитектуру и перейти с типа B на A4. Те, кто не успеет или не захочет, рискуют быть отключёнными от сети.
Борьба с кибератаками в финансовом секторе похожа на борьбу с биологическими вирусами - появляется новый вирус, медицина разрабатывает вакцину, вирус мутирует, появляются новые штаммы, и процесс повторяется. Это бесконечный процесс, по крайней мере пока у банков есть деньги. И защититься раз и навсегда невозможно. Но можно быть готовым к любому развитию событий и оперативному реагированию, имея арсенал организационно-технических средств.
Главный урок
Каждый банк теперь сам отвечает за то, чтобы его "окошко" в SWIFT не стало дверью для грабителей. И выбор простой: либо вы вкладываетесь в безопасность сейчас, либо ваши деньги уходят в казино на другом конце света.
История Bangladesh Bank - это не про орфографическую ошибку. Это про то, что система безопасности должна работать до того, как кто-то ошибётся в слове "foundation". Потому что в следующий раз ошибки может и не быть.
