Фишинг API и взлом Bybit: разбор механизма атаки

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

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

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

Что произошло с биржей Bybit

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

Когда руководители операций открыли Bybit Wallet, запрос на подпись выглядел обычным: сумма и назначение соответствовали ожидаемой операции. Подмена происходила глубже — адрес получателя менялся в момент формирования транзакции. Подтверждение на экране не давало достаточного основания обнаружить подмену, поэтому сначала подписывались несколько переводов, а затем средства массово выводились из холодных кошельков.

Почему связывают атаку с фишингом

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

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

Сходные принципы обмана встречаются и в других схемах: разбор поддельных страниц показывает, как подмена привычного сценария и внешнего вида сайта помогает перехватить доверие пользователя.

Как распознать поддельный интерфейс

Фишинговая страница часто отличается мелочами, которые сложно заметить при hurry: похожим адресом, изменённым логотипом, необычным порядком полей или требованием вставить ключ доступа в форму входа. Защищённое соединение и значок замка сами по себе не подтверждают принадлежность сайта официальной бирже.

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

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

Что показывают цифровые следы

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

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

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

Утечка сессий и токенов доступа

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

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

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

Защита пользователей и администраторов

Пользователям важно закрепить адрес официального сайта, использовать двухфакторную авторизацию и контролировать активные сессии. Ключ API следует создавать только для необходимых операций, ограничивать адресами и сроками действия, а при подозрении на компрометацию немедленно отзывать. Никогда не следует передавать секретную фразу, код подтверждения или приватный ключ постороннему сайту.

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

Сравнение признаков и реакций

Сходные внешние симптомы могут означать принципиально разные события. Например, чужая сессия, необычный адрес получателя и срочное требование подтвердить перевод требуют разных проверок. Сопоставление признаков помогает быстро отделить обычную ошибку пользователя от целенаправленного злоупотребления.

Признак	Возможное объяснение	Проверка	Безопасная реакция
Изменился адрес получателя	Ошибка или подмена транзакции	Сверить адрес в независимом источнике	Отклонить перевод
Сайт выглядит знакомым, но домен отличается	Фишинговая копия	Проверить домен и источник перехода	Не вводить данные
Запрошен ключ API	Попытка получить доступ к торговле	Проверить назначение и лимиты ключа	Отозвать подозрительный ключ
Интерфейс требует срочной подписи	Социальная инженерия	Сверить сумму, адрес и назначение	Остановить операцию
После входа доступна новая функция	Перехват сессии или токена	Проверить историю сессий и устройств	Завершить сессии и сменить пароль
Подозрительные адреса в блокчейне	Возможная атака на кошелёк	Провести трассировку транзакций	Сообщить бирже и в органы

Устойчивость биржи определяется не только выбором поставщика кошелька, но и защитой всего пути от рабочего места разработчика до подписи транзакции. Инцидент с Bybit показал, что доверенный домен, действительная сессия и корректно подписанный код не гарантируют безопасность, если компрометатирован хотя бы один независимый компонент этой цепочки.