Четыре инцидента за двое суток: рынок потерял более $385 тыс
13.03.2026 | CoinKyt Company

За двое суток, 11–12 марта 2026 года, в сетях Ethereum и BNB Smart Chain были зафиксированы четыре инцидента с совокупным ущербом свыше $385k. Каждый из них отражает отдельный класс уязвимостей: фишинговый approve, reentrancy, логическая ошибка в механике burn и рассинхрон в обработке meta-транзакций.

 

DBXen — ~$147k


Ход инцидента


Атака проводилась одновременно в двух сетях — Ethereum и BNB Smart Chain.


TX Ethereum: 0x914a5af790e55b8ea140a79da931fc037cb4c4457704d184ad21f54fb808bc37


TX BSC: 0xe66e54586827d6a9e1c75bd1ea42fa60891ad341909d29ec896253ee2365d366


Злоумышленник использовал механизм meta-транзакций через trusted forwarder. Он вызвал burnBatch() таким образом, что контракт записал данные частично для его реального адреса, а частично — для адреса forwarder. После этого вызовы claimFees() и claimRewards() позволили ему вывести из протокола значительно больше средств, чем ему причиталось.


Почему это стало возможным


Контракт по-разному определял отправителя в одной и той же логике. В gasWrapper() учёт burn шёл по _msgSender() — то есть по реальному пользователю. В burnBatch() в xen.burn() передавался msg.sender — то есть адрес forwarder. Затем onTokenBurned() обновлял lastActiveCycle уже для forwarder.


Из-за этого рассинхрона updateStats() ошибочно считал, что у атакующего есть необработанные burn-операции из прошлого цикла, и начислял ему лишние комиссии и награды. Контракт работал штатно — он просто считал некорректные данные.


Детали расследования: движение средств


Ethereum:
~65 ETH поступили на адрес 0x63150aC8E35c6C685E93eE4D7d5cB8EAfb2F016B и сразу переброшены через мост Stargate в Stable Chain. Далее средства распределились по пяти сетям: Arbitrum, Base, Optimism, Soneium, Linea. Небольшая часть сразу ушла в Railgun. Средства из пяти сетей впоследствии консолидировались на адресе 0x731A4C2D0469179eA9b1d295BEa4fE9901dE4dB1 в сети Ethereum и также направлены в Railgun.


BSC:
~24.72 BNB поступили на адрес 0xE92fA2a5feF535479A91Ab9ED90B26256ff276f1, затем переведены в Ethereum через мост Across Protocol. На стороне Ethereum средства вышли на адресе 0x5a70d17c5B261b5A3E91bF7a7E7cdc3D4bE1B6C7 и направлены в Tornado Cash.

 

Фишинг PAXG — ~$54.2k


Ход инцидента


TX: 0x356ae847c245e22398ead54bce1253403b351e3d16c6402c8006272b34e26fe0


Жертва выдала неограниченный approve на токен PAXG контракту 0xAec7e5460f6f7B5F72601b781a2561B6cB107440. Вслед за этим адрес 0xAfb2423F447D3e16931164C9970B9741aAb1723E инициировал multicall, который использовал уже выданное разрешение и выполнил три последовательных transferFrom с кошелька жертвы.


Похищенные PAXG распределены по трём адресам:


- 0x6fE314fD4CF845f35fc461eD98e2FB8d9356B566


- 0xf1A50bbebA19a85dB20432c6c201aa89604dfd2B


- 0x1b4e4AC5f5E2eDf843F79123c52C3a2589AC1589


Почему это стало возможным


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


Детали расследования: движение средств


Все похищенные PAXG были обменяны на ETH. На момент расследования полученные ETH, а также другие ранее накопленные средства, остаются на указанных адресах без движения.

 

AM/BSC-USD — ~$131.6k


Ход инцидента


TX: 0xd0d13179645985eae599c029574e866d79b286fbea395b66504f87f31629f859


Злоумышленник в одной транзакции привлёк крупную ликвидность через PancakeSwap V3, Moolah и Venus. Затем серией операций он искусственно исказил резервы пула AM/BSC-USD: сначала создал отложенное сжигание AM, вывел почти весь AM из пула на нулевой адрес, после чего мелкими продажами довёл резерв AM почти до нуля. Когда цена в пуле стала искусственно завышенной, продал остаток AM и вывел средства. Финальный перевод на адрес атакующего составил 131,572.53 BSC-USD.


Почему это стало возможным


Проблема — в логике токена AM. В функции _update переводы на address(0) обрабатываются через ранний return, поэтому стандартные проверки buy/sell для них не применяются. На sell-пути контракт сначала сжигал накопленный toBurnAmount прямо из баланса пула и вызывал sync(), и лишь затем учитывал текущую продажу. Это позволило атакующему сначала почти опустошить AM-резерв пула, а затем продать AM по искусственно завышенной цене.


Детали расследования: движение средств


Средства поступили на адрес 0x0B9a1391269e95162bfreC8785E663258C209333B. Оттуда 31,573 BSC-USD ушли на адрес 0x858dE7d92c19bf02f73c4Cbb73d285Ad0b50F28E, остальные ~100k BSC-USD остаются на балансе на момент расследования.

Средства с адреса 0x858dE7d92...F28E направлены в протокол приватности Railgun.

 


WUKONG Staking — ~57 BNB


Ход инцидента


TX 1: 0x79467533d4d1f332df846dc78c16fe319cd1d3a1a0f01545b4cdd7a2d3a71d22


TX 2: 0x97e2b875552e4e82d058a775c7dd14198d15df869260235dbaf6577e5e3b13cc


Злоумышленник использовал уязвимость в контракте WUKONG Staking и несколько раз повторно вызвал функцию вывода средств в рамках одной атаки. Контракт отдал больше BNB, чем должен был.


Почему это стало возможным


Причина — reentrancy. Контракт успевал отправить BNB наружу до того, как полностью обновлял внутреннее состояние. Атакующий входил в функцию вывода повторно до завершения первого вызова, каждый раз получая средства заново.


Reentrancy — одна из наиболее известных уязвимостей в смарт-контрактах. Её предотвращение стандартно решается паттерном checks-effects-interactions или использованием ReentrancyGuard.


Детали расследования: движение средств


Все похищенные средства переведены в сеть Solana через мост Li.Fi. Далее средства направлены в протокол приватности Privacy Cash.

 

Заключение


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


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


Команда КоинКит продолжает мониторинг адресов, связанных с инцидентами.