Крупнейшие взломы криптовалютных платёжных систем и уязвимости, лежащие в их основе

Ваша платёжная система существует для перемещения денег — именно поэтому горячие кошельки, процессы подписания и привилегии администратора являются прямыми целями для злоумышленников. Как показывают приведённые ниже случаи, поверхность атаки вышла за рамки ошибок смарт-контрактов и переместилась на инфраструктуру подписания, ключи и людей, которые ими управляют.

Именно такая закономерность прослеживается в трёх крупнейших инцидентах, связанных с криптоплатежами, в 2025 году. Мы подробно проанализировали цепочки атак, и каждая из них соответствует отдельному вектору: атака на цепочку поставок инфраструктуры подписания, утечка ключа администратора и компрометация сотрудников операционного отдела с помощью социальной инженерии. Ниже мы разбираем, что произошло в каждом случае, что это говорит о направлении, в котором движутся взломы криптоплатёжных систем, а затем опускаемся на уровень ниже — к контрактному уровню, на котором выполняются эти платежи: где смарт-контракты реально появляются в платёжной системе, чем отличаются два ведущих стейблкоина с точки зрения того, кто может заморозить или выпустить ваши средства, и что нужно самостоятельно развёрнутому платёжному контракту до и после запуска.

Bybit, 1,5 млрд долларов: когда инструмент подписания становится вектором атаки

В феврале 2025 года Bybit пережил крупнейший единичный инцидент в сфере безопасности за всю историю криптовалют, потеряв около 1,5 млрд долларов (401 347 ETH).

Злоумышленники не эксплуатировали ни одной уязвимости в собственных контрактах Bybit — они скомпрометировали интерфейс стороннего инструмента Safe{Wallet}, которому доверяли подписанты. Они внедрили вредоносный JavaScript в код фронтенда Safe{Wallet} — стороннего инструмента управления мультиподписями, которым пользовался Bybit. Когда подписанты Bybit увидели в веб-интерфейсе Safe{Wallet} то, что выглядело как обычный «внутренний перевод», и подписали его, они на самом деле подписывали операцию delegatecall, которая заменяла слот 0 прокси контракта мультиподписи на реализацию, контролируемую злоумышленником. После подписания злоумышленники опустошили весь кошелёк в течение нескольких минут.

Для успеха атаки необходимо было одновременно провалиться четырём защитным механизмам:

• Безопасность конечных точек — веб-интерфейс подписантов предоставлялся третьей стороной без независимой верификации.
• Верификация транзакций — слепое подписание означало, что подписанты не могли отличить обычный перевод от delegatecall на экране.
• Дизайн контракта — привилегия на обновление прокси не имела защиты посредством таймлока.
• Операционная изоляция — среда подписания не была физически изолирована от повседневной офисной среды.

Последний пункт заслуживает особого внимания: даже хорошо финансируемая биржа может потерять 1,5 млрд долларов, когда одновременно дают сбой несколько уровней защиты — безопасность конечных точек, верификация транзакций, дизайн контракта и операционная изоляция. Более подробный анализ защиты самой среды подписания см. в материале об управлении ключами и инфраструктуре подписания.

UPCX, 70 млн долларов: один утёкший ключ администратора — полный контроль

В 2025 году платёжный протокол UPCX потерял около 70 млн долларов из-за утечки приватного ключа администратора.

В этом случае злоумышленнику не нужно было никого обманывать. Он просто получил приватный ключ ProxyAdmin, воспользовался функцией обновления контракта для замены реализации на вредоносную версию, а затем вызвал withdrawByAdmin для вывода всех средств.

Урок прост и жесток: утечка ключа в сочетании с привилегией на обновление контракта означает полный контроль. Именно поэтому управление ключом ProxyAdmin должно строиться на MPC или мультиподписи — никогда на единственном держателе, — а обновления контракта требуют таймлока (например, задержки в 48 часов), дающего команде окно для выявления аномалий до вступления обновления в силу. Подробнее о том, как выстроить подобную систему управления ключами, рассказывается в другом материале этой серии.

MoonPay, 250 000 долларов: когда злоумышленники обходят код стороной

Не каждый взлом криптоплатёжной системы затрагивает контракт или систему ключей. Согласно материалам конфискационного дела Министерства юстиции США 2025 года, генеральный директор и финансовый директор криптоплатёжной компании MoonPay лишились около 250 000 долларов в USDT из-за одного фишингового письма.

Злоумышленник выдал себя за известную персону и использовал тайпсквоттинг для подделки адреса отправителя — заменив заглавную «I» на строчную «l», что практически незаметно в шрифте без засечек, — и убедил руководителей MoonPay перевести USDT на подконтрольный ему адрес. Никакой технической уязвимости здесь не было, система ключей не была затронута. Это была чистая социальная инженерия.

Впоследствии Tether заморозил около 40 000 долларов из похищенных средств, тогда как остальное ушло за рубеж и стало объектом преследования со стороны Министерства юстиции.

Несколько моментов заслуживают особого внимания:

• Социальная инженерия не делает различий — даже технически искушённые руководители ведущей платёжной компании могут на неё попасться.
• Всегда верифицируйте адрес получателя независимым способом перед отправкой — никогда не полагайтесь только на адрес, указанный в письме. Сочетайте верификацию адреса, белые списки и период охлаждения для крупных сумм.
• Возможность заморозки стейблкоина помогла частично вернуть средства после инцидента, однако удалось возместить лишь малую долю. Профилактика лучше постфактумной заморозки.

Закономерность: три вектора атаки, один урок

Выстроив эти три случая в ряд, можно выявить закономерность — каждый представляет отдельную точку отказа, однако у каждой есть чётко определённая защита:

Поверхность атаки сместилась: речь идёт уже не только об ошибках смарт-контрактов — теперь это инфраструктура подписания, ключи администратора и окружающий их операционный персонал. Если вы отвечаете за криптоплатёжную систему, практический вывод таков: защищайте все три составляющие — инструменты подписания, ключи администратора и операционный персонал — как отдельные поверхности атаки, каждая со своими средствами контроля.

Вместе с тем привилегии контракта фигурировали в двух из трёх рассмотренных случаев: незащищённое таймлоком обновление прокси стало одним из четырёх факторов провала Bybit, а ключ ProxyAdmin в UPCX и вовсе являлся единственным вектором атаки. Поэтому стоит опуститься на уровень ниже: из чего состоит контрактный уровень платёжной системы и что ему необходимо.

Где смарт-контракты реально появляются в платёжных системах

Если вы создаёте криптоплатёжный продукт, легко предположить, что безопасность смарт-контрактов означает сложность уровня DeFi: дюжина взаимодействующих протоколов, переплетение экономических допущений и огромная поверхность атаки для защиты. Однако платёжные компании обычно живут в иных реалиях. По сравнению с DeFi, где сценарий может предполагать взаимодействие десятков контрактов в рамках сложной экономической модели, логика платёжных контрактов, как правило, значительно прямолинейнее. От меньшей к большей сложности варианты использования концентрируются в четырёх областях.

Контракты стейблкоинов — используются практически всеми компаниями. USDC и USDT сами по себе являются смарт-контрактами с административными функциями: mint, burn, blacklist и pause. Вы — пользователь этих контрактов, а не их разработчик, — однако вам всё равно необходимо понимать их модель разрешений и возможность заморозки, о чём мы поговорим далее.

Контрактная мультиподпись и абстракция аккаунта — уровень кошелька и управления. Контрактные мультиподписи, такие как Safe, управляют средствами и привилегиями контракта и находятся в основе уровня кошелька. Абстракция аккаунта (ERC-4337) также начала проникать в платёжные сценарии: она обеспечивает безгазовые платежи (paymaster покрывает газ, чтобы пользователю не нужно было держать нативный токен), корпоративные лимиты расходов и сессионные ключи.

Автоматическое распределение, условный выпуск средств и кросс-чейн расчёты — категория, которая активно масштабируется прямо сейчас. Именно здесь «программируемые деньги» оправдывают своё название. Commerce Payments Protocol от Coinbase и Shopify выполняет on-chain разбивку поступлений в режиме реального времени: при фиксации контракт атомарно направляет комиссию на feeReceiver, а остаток — продавцу, причём единственную авторизацию можно разбить на несколько фиксаций по разным ставкам для разных получателей — например, зафиксировать 1 000 USDC двумя частями, перечисляя комиссии разным получателям и направляя остаток продавцу. Тот же протокол переносит on-chain привычный для карточных сетей процесс авторизации/фиксации: контракт-эскроу удерживает средства после авторизации покупателем, что позволяет продавцу впоследствии выполнить фиксацию или возврат. На стороне расчётов CCTP от Circle использует нативный механизм сжигания и выпуска для кросс-чейн перевода USDC и может инициировать последующие действия контракта по прибытии, объединяя кросс-чейн перемещение и автоматические расчёты в единую цепочку.

Автоматическое получение дохода и управление казначейством — всё ещё на раннем этапе. Речь идёт о размещении незадействованных резервов в низкорисковых DeFi-протоколах для получения дохода или автоматизации движения казначейских средств с помощью контрактов. Большинство платёжных компаний пока не освоили это на практике, и тому есть веское основание: это вводит зависимости от внешних протоколов, что расширяет поверхность атаки.

Сегодня большинство платёжных компаний остаются в первых двух категориях, третья только начинает масштабироваться, а четвёртая всё ещё находится на раннем этапе. Чем проще использование, тем меньше поверхность атаки — поэтому добавляйте сложность контрактов лишь по мере необходимости для бизнеса, а не ради самой «программируемости».

Модель разрешений за каждым стейблкоином, с которым вы работаете

Как пользователь стейблкоина, вам необходимо понимать модель разрешений, заложенную в сам контракт. Два ведущих стейблкоина придерживаются противоположных подходов.

USDC (Circle) использует модель разделения полномочий: masterMinter управляет лимитами эмитентов, pauser может приостановить контракт, blacklister управляет чёрным списком, а owner управляет назначением ролей. Каждая роль независима и не пересекается с другими по привилегиям (см. исходный код контракта Circle stablecoin-evm).

USDT (Tether) использует модель единственного владельца: один адрес-владелец единовременно держит все привилегии — mint, pause и addBlackList. Дизайн проще, но более концентрирован.

Ни одна из моделей не является безоговорочно лучшей — у каждой свои компромиссы. Разделение полномочий USDC обеспечивает большую безопасность, однако сложнее в эксплуатации, тогда как концентрированная модель USDT эффективнее, но в большей мере зависит от безопасности единственного адреса-владельца. Это различие не чисто академическое: оно напрямую влияет на ваш риск заморозки в случае, если эмитент стейблкоина когда-либо будет вынужден принять меры в отношении ваших средств.

Защита контрактов, которые вы разрабатываете самостоятельно

Если вы разворачиваете собственные контракты для приёма платежей, расчётов, распределения или эскроу, вам необходим профессиональный аудит платёжного контракта перед развёртыванием и ряд встроенных механизмов безопасности.

До развёртывания проведите независимый аудит сторонней компании по безопасности, а также автоматическое статическое и динамическое сканирование. Убедитесь, что проверка специально охватывает управление разрешениями, потоки средств, реентрабельность и переполнение при вычислении коэффициентов разбивки — риски, специфичные для платёжных систем, а не только общие ошибки контрактов.

В процессе работы применяются четыре механизма:

• Таймлок — задержка (например, 48 часов) на обновления контракта и изменения параметров, дающая команде и сообществу окно для выявления проблем до их вступления в силу.
• Автоматический выключатель — автоматически приостанавливает операции контракта при обнаружении аномалии.
• Разделение ролей — разработчик, специалист по обновлению, специалист по приостановке и администратор используют разные ключи, чтобы ни одна учётная запись не контролировала всё.
• Обновляемый паттерн прокси — прозрачный прокси или UUPS, с обновлениями, защищёнными таймлоком плюс мультиподписью.

После развёртывания немедленный отзыв расширенных привилегий разработчика является ключевой мерой против инсайдерских угроз — это прямой урок инцидента с UPCX, описанного выше: передайте привилегии admin и owner контракту мультиподписи, защитите ключ ProxyAdmin мультиподписью плюс таймлоком, регулярно проверяйте состояние разрешений контракта, чтобы убедиться в отсутствии остаточных привилегий разработчика, и следите за тем, чтобы каждое изменение on-chain разрешений генерировало лог событий для мониторинга и аудита.

Всё это не заменяет сам аудит — это то, что не даёт чистому аудиту со временем превратиться в немониторируемый контракт с избыточными привилегиями после запуска.

Защищайте четыре поверхности и держите четвёртую как можно меньше

Три из поверхностей, которые обнажили инциденты 2025 года, являются операционными: ваши инструменты подписания, ключи администратора и операционный персонал. Четвёртая — контрактный уровень, и здесь цель иная: не соответствовать сложности DeFi, а соответствовать реальному применению: понимать модель разрешений стейблкоинов, с которыми вы работаете, держать собственные контракты настолько простыми, насколько позволяет бизнес, и воспринимать аудит как первый день постоянной практики соблюдения порядка разрешений, а не как финишную черту.

О том, где каждая из этих поверхностей располагается в системе в целом, читайте в нашем разборе шестиуровневой платёжной архитектуры. Для полного разбора того, как эти средства контроля сочетаются друг с другом, скачайте полный плейбук (PDF), а для мониторинга в реальном времени, способного автоматически блокировать атаки на этапе мемпула, ознакомьтесь с мониторингом on-chain безопасности.

FAQ

Каким был крупнейший взлом криптоплатёжной системы в 2025 году? Bybit, в феврале 2025 года, потерявший около 1,5 млрд долларов (401 347 ETH) после того, как злоумышленники скомпрометировали код фронтенда стороннего инструмента мультиподписи Safe{Wallet} и обманом заставили подписантов одобрить вредоносный delegatecall.

Как произошёл взлом UPCX? Злоумышленник получил приватный ключ ProxyAdmin компании UPCX, воспользовался функцией обновления контракта для замены реализации на вредоносную и вызвал withdrawByAdmin для вывода около 70 млн долларов.

Был ли инцидент с MoonPay эксплойтом смарт-контракта? Нет. Инцидент с MoonPay, в ходе которого генеральный директор и финансовый директор лишились около 250 000 долларов в USDT, не предполагал никакой технической уязвимости. Это была чистая социальная инженерия с использованием поддельного адреса отправителя с тайпсквоттингом.

Что общего у Bybit, UPCX и MoonPay? Каждая атака была направлена на отдельный уровень платёжной системы — инструмент подписания, ключ администратора и операционный персонал, — что свидетельствует о том, что главная угроза переместилась от ошибок смарт-контрактов к инфраструктуре подписания, ключам и операционной деятельности.

В чём разница между моделями разрешений USDC и USDT? USDC (Circle) использует модель разделения полномочий с независимыми ролями masterMinter, pauser, blacklister и owner. USDT (Tether) использует модель единственного владельца, где один адрес единовременно держит все привилегии — mint, pause и addBlackList.

Какие механизмы безопасности должен иметь самостоятельно развёрнутый платёжный контракт? До развёртывания: независимый сторонний аудит плюс автоматическое сканирование с прицельной проверкой управления разрешениями, потоков средств, реентрабельности и переполнения при вычислении коэффициентов разбивки. В процессе работы: таймлок на обновления, автоматический выключатель, разделение ролей по ключам и обновляемый паттерн прокси, защищённый таймлоком плюс мультиподписью.

Почему отзыв привилегий разработчика после развёртывания так важен? Это ключевая мера против инсайдерских угроз, и это прямой урок случая с UPCX. Передача привилегий admin и owner контракту мультиподписи и регулярная проверка состояния разрешений для подтверждения отсутствия остаточных привилегий разработчика позволяют закрыть эту брешь.