Дослідники безпеки Blockaid підрахували, що за перше півріччя 2026 року хакери вкрали з криптопроєктів понад $1 мільярд. Це рекордна сума для такого періоду за всю історію спостережень компанії. Найбільше постраждали мережі Ethereum і Solana, а окремий аналіз для CoinDesk показує, що більшість грошей вивели зовсім не через баги в коді.
Скільки крипторинок втратив від хакерів у першому півріччі 2026?
За даними звіту Blockaid, загальні втрати від зламів, експлойтів і шахрайських схем у криптоіндустрії з січня по червень 2026 року перевищили $1 мільярд. Це найвищий показник за перше півріччя з моменту, як компанія почала вести подібну статистику.
Рекорд не тримається на одному гучному зламі. Сума складається з десятків окремих інцидентів упродовж усіх шести місяців, а не з однієї-двох атак на сотні мільйонів, як бувало раніше. Саме такий розподіл, на думку аналітиків, і робить проблему складнішою, адже точкового рішення проти неї просто не існує. Атаки б'ють у різні місця по всій галузі одночасно.
Окремо аналітична колонка Crypto Long & Short на CoinDesk наводить дещо іншу цифру, близько $972 мільйонів за поточний рік станом на дату публікації. Розбіжність пояснюється різними методиками підрахунку та періодами вибірки. Але порядок цифр збігається. Втрати вимірюються сотнями мільйонів доларів щомісяця, і жодна з двох оцінок не показує ознак сповільнення в другій половині року. Для порівняння, такої суми вистачило б, щоб профінансувати десяток середніх криптостартапів на кілька років уперед.
Чому Ethereum і Solana постраждали найбільше?
Найбільших втрат зазнали проєкти на Ethereum, де сума збитків сягнула $332 мільйони, і на Solana з результатом $326 мільйонів. Разом ці дві мережі забезпечили понад половину всіх збитків, які зафіксувала Blockaid за півріччя.
Пояснення просте. Обидві мережі лишаються домом для найбільшої кількості DeFi-протоколів, мостів між блокчейнами і NFT-майданчиків. Там традиційно концентрується найбільше активів, а отже, і найбільше зловмисників. Чим складніша інфраструктура протоколу, тим більше в ній адміністративних гаманців, оракулів і зовнішніх інтеграцій, а отже і потенційних точок входу для атаки.
Мости між блокчейнами заслуговують на окрему згадку. Вони за визначенням тримають великі резерви токенів по обидва боки з'єднання, і будь-яка помилка в перевірці підписів на такому мості одразу відкриває доступ до мільйонів доларів. Саме мостові протоколи роками лишаються серед найбільш атакованих у галузі.
Інші мережі теж фігурують у звіті, але з набагато меншими сумами. Це не означає, що вони безпечніші за конструкцією. Радше в них менше грошей і менше активних DeFi-протоколів, які взагалі можна атакувати.
Як зловмисники обходять пройдені аудити?
Тут і криється головний висновок звіту. Мітчелл Амадор, засновник платформи для пошуку вразливостей Immunefi, у колонці для CoinDesk написав, що більшість вкрадених цього року коштів пішла не через помилки в коді контрактів, а через ключі, підписантів мультипідписів і голосування в DAO. Immunefi роками проводить bug bounty програми для великих протоколів, тож висновок ґрунтується на практиці, а не на здогадках. Проєкт може пройти повний аудит смартконтракту і все одно втратити кошти, якщо зловмисник дістанеться приватного ключа адміністратора або переконає підписанта підтвердити шкідливу транзакцію.
Простими словами, аудит перевіряє логіку коду, а не людей і процеси навколо нього. Тому фраза "ми пройшли аудит" давно перестала означати "ми в безпеці". Аудитор бачить код таким, яким його написали розробники, але не бачить, хто саме має доступ до адмін-панелі протоколу через рік після запуску, і чи не змінився цей список без належного контролю.
Ще один момент рідко потрапляє в публічні звіти. Багато мультипідписних гаманців формально мають кілька підписантів, але на практиці керуються двома-трьома людьми з однієї команди. Якщо зловмисник компрометує їхні пристрої одночасно, поріг у "3 з 5" підписів перестає щось означати.
Ключі, підписанти і голосування як нова головна мішень
Blockaid і Immunefi окреслюють приблизно однакове коло вразливих точок поза межами коду:
- Приватні ключі: викрадені через фішинг, шкідливе ПЗ або витік із хмарних сервісів
- соціальна інженерія проти підписантів мультипідпису, коли зловмисник видає себе за колегу чи партнера
- маніпуляції голосуванням у DAO, де достатньо тимчасово зібрати контрольний пакет токенів управління
- компрометація фронтенду чи гаманця, через який підписант підтверджує транзакцію, не бачачи її справжнього вмісту
- витік доступів до інфраструктури, серед них хмарні акаунти, CI/CD-системи і приватні репозиторії з ключами розгортання
Жоден із цих векторів не потрапляє у звичайний звіт аудитора смартконтрактів. Команди, які покладаються лише на аудит коду, залишають без захисту саме ту частину системи, куди зараз і б'ють зловмисники. Аналітики Immunefi відзначають, що кількість атак на процеси управління доступом зростає швидше, ніж кількість атак через вразливості в самому коді.
Що це означає для власників криптовалюти?
Для звичайного користувача висновок практичний. Безпека великого протоколу більше не гарантує безпеку конкретного гаманця чи облікового запису. Апаратні гаманці на кшталт Ledger знижують ризик витоку приватного ключа, бо підпис транзакції відбувається на окремому пристрої, а не в браузері чи на комп'ютері, підключеному до мережі.
Для протоколів і команд рекомендації схожі. Варто розділяти підписантів мультипідпису географічно і організаційно, перевіряти запити на підпис поза основним каналом зв'язку, обмежувати права адмін-гаманців у часі. Окремо допомагають інструменти симуляції транзакцій, які показують підписанту, що саме відбудеться до того, як він поставить підпис, а не після. Жоден з цих кроків не замінює аудит коду, але саме вони закривають прогалину, яку аудит принципово не бачить.
Дані Blockaid за перше півріччя показують просту річ. Галузь витрачає мільйони на аудити коду, але втрачає сотні мільйонів через людський фактор і слабкі процеси управління доступом. Поки захист ключів і підписантів не наздожене якість аудитів смартконтрактів, статистика навряд чи зміниться на краще.




Коментарі
Ваша e-mail адреса не оприлюднюватиметься. Обов'язкові поля позначені *