Haker ukradł 500 000 USDC, a bot MEV zabrał mu 75% – przestroga z DeFi

Kilka godzin później haker próbował zamienić skradzione stablecoiny na ETH za pośrednictwem zdecentralizowanej giełdy. Wtedy właśnie cały plan runął – nie przez exploit protokołu, ale przez brak ustawienia ochrony przed poślizgiem cenowym (slippage protection). Zautomatyzowany bot MEV wykrył oczekującą transakcję w publicznym mempoolu i przeprowadził klasyczny atak sandwich: kupił ETH tuż przed transakcją hakera (podbijając cenę), pozwolił, by zakup hakera zrealizował się po zawyżonej cenie, a następnie natychmiast sprzedał swoje ETH z zyskiem .

Bot wyciągnął około 371 000 dolarów ze skradzionych środków, płacąc około 3,5 ETH w opłatach gazowych, by zapewnić sobie pierwszeństwo w kolejkowaniu transakcji. Haker wyszedł z zaledwie około 67 WETH (~129 000 dolarów) – stratą netto wynoszącą ponad 74% łupu .

Jak działa atak sandwich MEV

Atak sandwich to forma wykorzystania maksymalnej wartości wydobywalnej (MEV), polegająca na manipulacji kolejnością transakcji w publicznym mempoolu blockchaina. Oto jak bot przeprowadził atak :

1. Monitorowanie mempoolu: Boty MEV skanują publiczny mempool w poszukiwaniu dużych, oczekujących transakcji swap z niską tolerancją na poślizg.
2. Front-running: Bot dostrzega transakcję hakera (kupno ETH za USDC) i natychmiast składa własne zlecenie kupna ETH przed transakcją hakera.
3. Ofiara wypełnia środek: Transakcja hakera realizuje się po wyższej cenie, otrzymując mniej ETH za tę samą ilość USDC.
4. Back-running: Bot natychmiast sprzedaje swoje ETH po zakończeniu transakcji hakera, zarabiając na różnicy cenowej.

W tym przypadku haker użył Uniswap V4 bez ustawienia limitu poślizgu, dając botowi niemal nieograniczone pole do manipulacji ceną wykonania w całej partii transakcji .

Co to ujawnia o bezpieczeństwie DeFi

• Boty MEV działają jak bezstronni oportunści. Nie rozróżniają legalnych traderów od przestępców. Każda transakcja widoczna w publicznym mempoolu ze słabymi ustawieniami poślizgu jest celem, niezależnie od tego, kto ją wysłał .
• Ochrona przed poślizgiem to warunek konieczny. Haker ustawił swap bez ciasnego limitu poślizgu, pozwalając botowi manipulować ceną wykonania w wielu blokach. Mały limit poślizgu zapobiegłby większości strat .
• Przejrzystość DeFi mieczem obosiecznym. Ten sam otwarty mempool, który umożliwia handel bez zezwolenia na DEX-ach, sprawia też, że duże i źle skonfigurowane transakcje są łatwym celem dla botów .
• Phishing wciąż najczęstszym wektorem ataku. Początkowa kradzież polegała na przejęciu portfela, a nie na exploicie protokołu. Bezpieczeństwo po stronie użytkownika – zezwolenia, podpisy i higiena portfela – pozostaje najsłabszym ogniwem .

Kluczowe wnioski dla użytkowników

1. Zawsze ustawiaj ciasny limit poślizgu – zazwyczaj 0,5–1% dla dużych swapów na płynnych parach. Nigdy nie używaj ustawienia "auto" lub nieskończonego poślizgu .
2. Korzystaj z zabezpieczonych przed MEV punktów końcowych RPC lub prywatnych mempooli (np. Flashbots Protect, BloxRoute), aby trzymać transakcje poza publicznym mempoolem .
3. Regularnie odwołuj nieużywane zezwolenia tokenów. Ofiara podpisała phishingową transakcję, która pozwoliła hakerowi bezpośrednio opróżnić jej USDC .
4. Najpierw testuj duże swopy małymi kwotami – szczególnie po uzyskaniu kontroli nad środkami z podejrzanego źródła.
5. Pamiętaj, że przejrzystość blockchaina może się zemścić – posiadanie kluczy prywatnych nie gwarantuje bezpiecznego wykonania, jeśli transakcja jest publicznie widoczna i źle skonfigurowana .

To zdarzenie jest surowym przypomnieniem, że w DeFi techniczne zaawansowanie ma znaczenie na każdym kroku – nawet przestępcy mogą przegrać z lepiej zautomatyzowanymi przeciwnikami, gdy ignorują podstawową higienę transakcyjną.