Crypto drainer: как вредная подпись или approve выводит токены из кошелька

Crypto drainer — это не один конкретный вирус и не обязательно один вредоносный смарт-контракт. Так обычно называют мошенническую связку из фишингового интерфейса, запросов на подпись и механизма, который после полученного разрешения пытается вывести доступные токены или NFT. Ключевой момент: злоумышленнику не всегда нужна seed-фраза. В EVM-сетях достаточно добиться действующего allowance, подписи Permit/Permit2, operator approval для NFT или другой авторизации, которой затем можно воспользоваться по правилам соответствующего контракта.

Поэтому сценарий «я не нажимал Send, но токены ушли» технически возможен без взлома блокчейна. Пользователь сам мог подписать действие, смысл которого в интерфейсе выглядел как claim, mint, verify или login, а экономический эффект оказался разрешением на расходование актива. Если ситуация уже произошла, сначала полезно разделить диагностику и восстановление: эта статья объясняет, какое право мог получить drainer и как его распознать, а отдельный материал о списании токенов без вашего перевода даёт аварийный алгоритм после фактического исходящего движения.

Само подключение кошелька к dApp обычно не равно передаче права распоряжаться токенами. Риск начинается там, где пользователь подтверждает транзакцию, allowance, typed-data подпись или иное действие с экономическим эффектом. Именно поэтому полезно отдельно понимать что именно подписывает криптокошелёк и не оценивать безопасность по одной кнопке Connect.

Материал построен защитно: здесь нет кода drainer, инструкций по автоматическому списанию или способов обхода кошельковых предупреждений. Цель — научиться отличать Connect от approval, approval от Permit, Permit от Permit2, понять границы revoke и определить, когда одного отзыва разрешения достаточно, а когда безопаснее считать весь кошелёк скомпрометированным.

Crypto drainer: что именно происходит и где начинается риск

Увеличить

Drainer — это сценарий кражи, а не обязательный «вирус в кошельке»

Термин drainer описывает результат и инфраструктуру атаки, но не единственный технический объект. В одном случае фишинговый сайт просит обычный ERC‑20 approve на чужой spender; в другом получает EIP‑712 подпись, которую позже использует совместимый контракт; в третьем пользователь подписывает on-chain вызов, который сразу перемещает актив. Поэтому поиск «какой файл заразил MetaMask» часто уводит в сторону. Сначала устанавливают, что было подписано, какой контракт получил полномочия и есть ли признаки компрометации ключей.

Connect Wallet сам по себе обычно не даёт права списать токены

Подключение dApp сообщает сайту публичный адрес и позволяет интерфейсу предлагать запросы кошельку. Это не то же самое, что allowance. Опасность возникает, когда появляется следующий шаг: approve, permit, swap, mint, claim, setApprovalForAll или неизвестный вызов. На практике пользователь может подключиться к вредному сайту и ничего не потерять, если не подписал экономически значимое действие. Но подключение остаётся сигналом остановиться и проверить домен, особенно если сайт сразу начинает генерировать неожиданные запросы.

Почему токены могут уйти без нажатия кнопки Send

ERC‑20 допускает модель, в которой владелец заранее разрешает spender-контракту тратить токен через allowance. После такого разрешения spender может вызвать предусмотренный токеном механизм transferFrom в пределах лимита. Владелец при этом не формирует новый обычный перевод в момент каждого списания. Именно поэтому в истории можно увидеть исходящий Transfer, хотя пользователь помнит только более ранний approve. Для диагностики важна цепочка событий: когда возникло разрешение, кому оно принадлежит и каким вызовом оно было использовано.

Seed-фраза и drainer — разные уровни компрометации

Если злоумышленник получил seed-фразу или приватный ключ, он контролирует сам подписывающий секрет и может создавать новые транзакции от имени владельца. Drainer через allowance или Permit может иметь гораздо более узкое право: например, тратить один конкретный ERC‑20 в заданном объёме. Эти ситуации нельзя лечить одинаково. При раскрытии seed-фразы нужен новый кошелёк; подробно это разобрано в материале о раскрытой seed-фразе. При подозрительном allowance ключ может оставаться секретным, и тогда главная задача — нейтрализовать выданные полномочия.

Почему «подпись сообщения» не означает автоматически безопасное действие

Кошелёк может подписывать не только транзакции, но и сообщения. Часть сообщений действительно используется для входа в сервис и не двигает активы сама по себе. Но структурированная EIP‑712 подпись способна подтверждать условия разрешения, ордера или другого протокольного действия. Даже обычная подпись может иметь значение, если конкретное приложение заранее определило, как её интерпретировать. Поэтому правило «если нет gas, значит безопасно» неверно: отсутствие on-chain комиссии в момент подписи не доказывает отсутствие будущего экономического эффекта.

Почему аппаратный кошелёк не отменяет риск осознанно подписанного разрешения

Hardware wallet защищает приватный ключ от извлечения и даёт доверенный экран для проверки части параметров. Но если владелец сам подтверждает вредное разрешение, устройство корректно подпишет именно его. Аппаратная защита уменьшает риск кражи ключа и подмены данных на host при корректном отображении, но не заменяет понимание spender, token, amount, destination и типа подписи. Поэтому холодное хранение полезно сочетать с отдельным operational-wallet, который взаимодействует с dApp и держит ограниченную сумму.

Drainer не обязан опустошать весь кошелёк одним действием

Полномочия часто ограничены конкретным токеном, коллекцией NFT, сетью, лимитом или сроком. Один вредный approval может затрагивать USDT, но не ETH; operator approval для коллекции NFT не обязательно даёт доступ к ERC‑20; Permit2 может работать только там, где уже существует необходимый базовый approval и подписаны соответствующие условия. Поэтому слово «drain» не должно заставлять пользователя предполагать магический доступ ко всему. Нужно перечислить активы и проверить каждую модель авторизации отдельно.

Момент потери и момент компрометации могут не совпадать

Разрешение может быть подписано сегодня, а использовано позже. С другой стороны, вредная транзакция может исполниться сразу. Это создаёт сложную психологическую ловушку: пользователь вспоминает только последний сайт, хотя опасный allowance был выдан неделю назад. Для расследования строят временную линию из approve/permit, подключения сайта, последующих transferFrom, NFT transfer и других событий. Чем точнее связаны timestamp, chain, spender и asset, тем меньше риск удалить безопасные разрешения и пропустить настоящее.

Drainer и address poisoning различаются по точке воздействия

Address poisoning подменяет выбор получателя: человек сам отправляет актив на похожий адрес. Drainer работает через авторизацию кошелька или контракта. В первом случае история транзакций загрязнена ложным реквизитом; во втором существует право или подписанный вызов, способный перемещать актив. Поэтому правила защиты различаются. Подробный разбор похожих адресов вынесен в статью об address poisoning, а здесь фокус остаётся на approvals и подписях.

Clipboard malware — ещё один отдельный сценарий

При clipboard malware правильный адрес меняется между Copy и Paste на заражённом устройстве. Никакого approve может не быть вообще: пользователь подписывает обычный перевод, но получатель уже подменён. Это отделено от drainer-интента и разобрано в отдельном материале о clipboard malware. Для текущей статьи важно только диагностическое различие: если адрес изменился после вставки, расследуют endpoint; если токены списались через spender, исследуют permissions и подписи.

Approve, allowance и transferFrom: почему легитимная функция становится каналом кражи

Увеличить

ERC‑20 approve не является переводом

Стандартный approve записывает разрешение владельца для spender. Сам по себе он обычно не переводит токены получателю и может выглядеть менее страшно, чем Send. Но экономическое значение серьёзное: после успешного approve выбранный spender получает право инициировать transferFrom в пределах allowance. Безопасность поэтому определяется не только суммой approval-транзакции, а тем, кто указан spender и почему этому адресу вообще нужно право расходования.

Allowance — это состояние, которое переживает закрытие сайта

После подтверждения approve запись остаётся в состоянии токена. Закрытие вкладки, выход из аккаунта, перезагрузка браузера или удаление сайта из Connected Sites её не стирают. Именно поэтому старые approvals могут оставаться годами. Для пользователя полезно воспринимать allowance как отдельное on-chain право, а не как временную веб-сессию. Проверять его нужно независимо от того, доступен ли исходный сайт сегодня.

Spender важнее красивого имени dApp

Кошелёк может показывать бренд или декодированное название, но реальное право получает конкретный spender-address. Его нужно сопоставить с официальной документацией и контрактами приложения. Если адрес неизвестен, полезно применить проверку смарт-контракта: сеть, verified source, proxy, owner/admin roles, история и фактический purpose. Известный логотип интерфейса не доказывает, что запрос сформировал официальный spender.

Unlimited approval — не автоматический скам, но максимальный blast radius

Многие легитимные приложения исторически просили большой или максимальный allowance ради удобства повторных операций. Это не делает каждый Unlimited Approval вредоносным. Проблема в масштабе последствий: если spender злонамерен, скомпрометирован или заменён в фишинговом интерфейсе, доступный лимит может покрывать весь текущий и будущий баланс этого токена. Для разовой операции разумнее ограничивать spending cap суммой, действительно нужной сценарию, если кошелёк и протокол это поддерживают.

Повторный approve может изменить существующий лимит

В ERC‑20 allowance — изменяемое состояние. Новый approve для того же spender способен заменить значение. Поэтому пользователю недостаточно помнить, что «раньше разрешал только небольшую сумму»: нужно читать фактическое текущее значение on-chain. Отдельные токены имеют нестандартное поведение, поэтому интерфейс revoke/approval должен опираться на конкретную реализацию, а не на предположение, что все ERC‑20 абсолютно одинаковы.

Revoke — это изменение allowance, а не возврат украденного

Отзыв разрешения уменьшает или обнуляет право spender использовать оставшийся allowance. Он не отменяет уже подтверждённый Transfer и не возвращает активы. Практический алгоритм и различия между approvals вынесены в отдельную инструкцию по revoke. В аварийной ситуации перед нажатием любых кнопок важно проверить сеть и точный spender: поддельный «revoke-сайт» может сам запросить новое вредное разрешение.

Disconnect и revoke отвечают на разные угрозы

Disconnect прекращает взаимодействие интерфейса dApp с кошельком и убирает сайт из списка подключённых приложений. Revoke меняет on-chain право. После вредного approve одного disconnect недостаточно. И наоборот, revoke конкретного allowance не исправляет заражённое устройство, не меняет скомпрометированную seed-фразу и не отменяет другую подпись в соседней сети. Хороший incident-response всегда начинает с классификации угрозы, а не с универсальной кнопки.

Approval на один токен не равен доступу ко всему портфелю

ERC‑20 allowance привязан к конкретному token contract, owner и spender. Если пользователь дал spender доступ к USDT, это не создаёт автоматически allowance для USDC, WETH или другого токена. Но drainer-страница может последовательно запрашивать несколько разрешений или использовать batching-механизмы, поэтому реальный incident scope определяют по всем событиям кошелька. Нельзя считать остальные активы безопасными только потому, что первый замеченный drain затронул один token.

Approval event полезен, но не заменяет чтение текущего состояния

Событие Approval показывает, что в определённой транзакции было установлено разрешение. Но текущий allowance мог позже измениться, уменьшиться после использования или быть отозван. Поэтому расследование соединяет исторические events и текущее состояние allowance. Это особенно важно после нескольких revoke/approve подряд, когда одна запись в explorer не отвечает на вопрос, что spender может сделать сейчас.

Почему spending cap нужно выбирать до подписи, а не после инцидента

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

Permit, Permit2 и typed-data: почему подпись без gas тоже может создавать право

ERC‑2612 Permit меняет allowance через подпись

ERC‑2612 добавляет к ERC‑20 механизм permit: владелец подписывает структурированное сообщение, после чего совместимый контракт может применить эту подпись и обновить allowance без отдельной approve-транзакции владельца. В спецификации присутствуют owner, spender, value, nonce и deadline. Для безопасности это означает важную вещь: пользователь может не увидеть привычную on-chain approve-транзакцию в момент подписания, хотя подпись имеет экономический смысл и после предъявления способна создать право spender.

Nonce защищает от простого повторного использования одной и той же permit-подписи

Permit включает nonce владельца. После успешного применения корректного permit nonce увеличивается, поэтому та же подпись не должна бесконечно воспроизводиться. Но пользователь не должен превращать этот факт в ложную уверенность. Пока подписанное сообщение ещё действительно и его nonce не использован, оно может оставаться значимым до deadline. Если неизвестная permit-подпись уже выдана, простая проверка текущего allowance не всегда отвечает на вопрос, может ли эта подпись быть предъявлена позже.

Deadline ограничивает срок, но не делает подпись безопасной до истечения

Срок действия полезен как верхняя граница риска. Если deadline короткий, окно злоупотребления меньше. Но до его окончания вредный permit остаётся потенциально исполнимым при выполнении остальных условий. Поэтому правило «подожду, пока истечёт» неприемлемо для значимого баланса, если содержание подписи не установлено. Нужно определить token, spender, nonce, value, domain и поддерживаемый механизм отмены или инвалидирования.

EIP‑712 показывает структуру, но пользователь всё равно должен читать значения

Typed data была создана именно для более понятных структурированных подписей. Кошелёк способен показать domain, тип сообщения и поля вместо непрозрачной строки hex. Однако хороший формат не гарантирует добрый смысл. Фишинговый сайт может сформировать вполне корректную EIP‑712 структуру с чужим spender или слишком большим amount. Поэтому полезно оценивать не только название метода, но и конкретные поля, а также домен и chain context.

Permit2 — не просто «новый Permit»

Permit2 объединяет несколько моделей: allowance-based permissions и signature-based transfers. Важный нюанс — для работы с ERC‑20 пользователь обычно сначала предоставляет базовый token approval контракту Permit2, после чего более узкие разрешения конкретным spender могут управляться через подписи. Отдельный материал о Permit2 разбирает эту архитектуру глубже. Для drainer-диагностики нужно проверять оба слоя: базовый token → Permit2 и последующие подписи/allowances.

SignatureTransfer и AllowanceTransfer несут разные остаточные риски

В Permit2 модель AllowanceTransfer хранит разрешение spender с amount и expiration, тогда как SignatureTransfer рассчитана на подписи для конкретного transfer-сценария и использует nonce/deadline. Это значит, что единая фраза «отозвать Permit2» слишком груба. Инцидент нужно классифицировать: есть ли долгоживущее allowance, была ли одноразовая подпись уже использована, осталась ли действующая authorization и поддерживает ли конкретный инструмент безопасное invalidation.

Подписанное сообщение может не появиться в обычной истории транзакций

До отправки в сеть подпись существует off-chain. Пользователь способен забыть о ней, а кошелёк не обязан показывать её как отдельный block explorer event, потому что блокчейн ещё ничего не записал. Именно поэтому журнал браузера, история dApp, скрин кошелькового окна и домен сайта могут быть важными доказательствами. Когда подпись позже применяется, on-chain будет видно уже действие контракта, но источник разрешения придётся восстанавливать по контексту.

Personal Sign не нужно автоматически считать безвредным

Обычная подпись текста часто служит аутентификацией и не создаёт ERC‑20 allowance сама по себе. Но безопасность определяется тем, что конкретный сервис делает с подписанным сообщением. Пользователю не следует подтверждать произвольные challenge-строки на незнакомом сайте только потому, что кошелёк не показывает gas. Для крупных кошельков хорошее правило — подписывать login-сообщения лишь на заранее проверенных доменах и отдельно анализировать EIP‑712 запросы с token, spender, amount и deadline.

Подпись и транзакция различаются моментом on-chain эффекта

Транзакция оплачивает сетевое исполнение и при включении в блок меняет состояние либо откатывается. Подпись сообщения сама по себе может остаться off-chain до тех пор, пока кто-то не использует её в совместимом контракте. Поэтому отсутствие TxID сразу после подозрительной подписи не доказывает отсутствие риска. При расследовании фиксируют время подписи и отслеживают последующие allowance/transfer события, связанные с тем же token и spender.

Нельзя сводить любой drainer к Permit2

Permit2 заметен в современных EVM-приложениях, но drainer может использовать обычный approve, ERC‑2612 Permit, NFT operator approval, прямую транзакцию или протокол-специфическую подпись. В других сетях модели вообще отличаются. Фокус на одном известном механизме создаёт слепую зону: пользователь проверяет Permit2 и успокаивается, хотя вредное право было выдано непосредственно token contract или NFT operator.

NFT, разные сети и нестандартные токены: где модель ERC‑20 перестаёт работать

SetApprovalForAll способен открыть оператору всю NFT-коллекцию

В ERC‑721 существует отдельная модель operator approval. Функция setApprovalForAll позволяет оператору действовать от имени владельца для NFT коллекции. Поэтому вредный mint-сайт может быть опасен не потому, что «минтит NFT», а потому, что запрос на самом деле меняет operator permission. Пользователь должен проверять collection contract и operator, а после подозрительного взаимодействия — смотреть NFT approvals отдельно от ERC‑20 allowances.

Approval одного NFT и approval всей коллекции — разные масштабы

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

Solana не использует ERC‑20 allowance как универсальную модель

В Solana токены и приложения работают через собственные account/instruction модели. Там могут существовать delegate authorities и подписываемые transaction instructions, но термин approve из EVM нельзя переносить буквально на любой кошелёк. При подозрительной подписи на Solana нужно читать конкретные instructions, account metas, token program и изменения authority. Общий защитный принцип остаётся тем же: минимальные полномочия и понимание того, что подписывается.

TON имеет собственную модель сообщений и контрактных вызовов

В TON нет универсального ERC‑20 approve, поэтому советы «откройте Etherscan Token Approvals» неприменимы. Риск возникает через подписанные сообщения, transfer payloads, jetton interactions и контрактную логику конкретного приложения. Статья использует approve/Permit главным образом для EVM-сценариев и отдельно предупреждает, что в других сетях нужно применять инструменты и документацию соответствующей экосистемы.

Bitcoin UTXO не имеет ERC‑20-style allowance

У Bitcoin другая модель владения: расходуются UTXO по условиям script и подписи. Пользователь не выдаёт ERC‑20 spender allowance, поэтому термин wallet drainer для Bitcoin чаще связан с вредной транзакцией, PSBT, компрометацией ключа или обманом получателя. Универсальная рекомендация «сделайте revoke» здесь технически неверна. Сначала определяется chain и тип подписанного объекта.

Стейблкоин с blacklist и pause добавляет issuer-control, но это не drainer

USDT, USDC и другие активы могут иметь административные функции эмитента. Блокировка адреса, pause или заморозка — другой класс риска. Не нужно объяснять любое исчезновение или недоступность баланса drainer-атакой. Сначала проверяют фактические on-chain Transfer events, token contract, status и интерфейс. Корректная диагностика защищает от ложных выводов и ненужной миграции кошелька.

Fee-on-transfer и нестандартные токены могут искажать ожидание результата

Некоторые токены удерживают комиссию, меняют баланс при transfer или используют proxy/wrapper. Это способно выглядеть как непонятное списание, хотя вредного allowance нет. Если token behavior нестандартно, важно сравнить source code, events и реальный баланс до/после. Для сомнительного актива пригодится материал о том, как проверить токен перед покупкой.

Proxy и upgradeable spender требуют проверки текущей реализации

Даже известный spender-address может быть proxy, чьё поведение определяется текущей implementation. Это не означает, что все upgradeable контракты опасны, но long-lived unlimited approval увеличивает зависимость от будущих upgrades и admin security. Пользователь оценивает не только адрес, но и возможность смены логики, timelock и governance. При ненужном старом разрешении принцип минимизации поверхности риска обычно говорит в пользу revoke.

Cross-chain интерфейс может подписывать несколько действий подряд

Bridge или multi-chain приложение иногда требует approve базового token, затем собственно bridge transaction, а позже действия в destination chain. Фишинговый клон способен использовать сложность маршрута и заставить пользователя подтверждать окна автоматически. Безопасный подход — заранее знать ожидаемое число шагов и назначение каждого. Если интерфейс внезапно запрашивает дополнительный spender или operator, последовательность прекращают и перепроверяют домен/контракты.

Одно имя токена не определяет permission model

USDT в Ethereum, TRON и TON — разные технические представления, а wrapped assets добавляют свои контракты. Нельзя делать incident-response по тикеру: нужно знать сеть, token contract и стандарты конкретной реализации. Это особенно важно, если человек видит списание «USDT» и сразу ищет ERC‑20 approval, хотя актив находился в другой сети с другой моделью разрешений.

Как работает drainer-кампания с точки зрения пользователя: безопасная модель угрозы

Приманка должна объяснить, зачем пользователю срочно подписывать

Фишинговая страница редко пишет «разрешите украсть токены». Она строит правдоподобный сценарий: claim airdrop, mint NFT, восстановление доступа, бонус, миграция токена, проверка eligibility или срочная «верификация кошелька». Для защиты важно оценивать бизнес-смысл запроса. Если бесплатная проверка неожиданно требует права тратить USDT или всей NFT-коллекцией, запрашиваемая возможность не соответствует заявленной цели.

Клон домена использует узнаваемость бренда как shortcut доверия

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

Первый Connect снижает психологический барьер перед вторым подтверждением

После безвредного Connect интерфейс уже выглядит «успешно подключённым», и пользователь легче нажимает следующую кнопку. Именно второй или третий запрос может быть экономически значимым. Поэтому каждое окно кошелька рассматривают как отдельное решение. Предыдущее безопасное подтверждение не делает последующий approve автоматически безопасным.

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

Кнопка на сайте может называться Claim, Verify или Continue. Блокчейн и кошелёк не исполняют текст кнопки; они работают с transaction data или message payload. Поэтому безопасность проверяется по данным в окне кошелька и симуляции, а не по marketing label. Если декодировать запрос невозможно, для крупной суммы разумнее остановиться, чем доверять интерфейсу.

Drainer может стремиться получить не перевод, а долговременное право

Мошеннику иногда выгоднее не просить прямой Send на свой адрес, а получить allowance: такой запрос может казаться стандартной частью DeFi и после подтверждения позволяет использовать право позднее. Это также затрудняет причинную связь: пользователь покинул сайт, а списание произошло спустя время. Отсюда практический вывод — после сомнительного dApp нужно проверять permissions даже если баланс пока не изменился.

Несколько разрешений могут запрашиваться последовательно

Портфель состоит из разных ERC‑20 и NFT, а права обычно раздельны. Поэтому вредный интерфейс может показывать серию окон. Пользователь, привыкший к многошаговым DeFi-операциям, начинает подтверждать их механически. Защита — заранее определить, какой один токен и какая сумма нужны операции. Любой дополнительный approval должен иметь отдельное объяснение.

Transaction simulation полезна, но не является абсолютной гарантией

Современные кошельки могут показывать ожидаемые token transfers и предупреждения. Это сильный барьер, особенно против очевидного drain. Но simulation зависит от текущего state, качества декодирования и известных threat signals. Если сайт неизвестен, предупреждение отсутствует и симуляция выглядит пустой, это не доказывает безопасность. Пользователь всё равно проверяет origin, method, spender, amount и downstream permissions.

Повторный запрос после «ошибки» требует повышенного внимания

Скам-интерфейс может утверждать, что первая подпись не прошла, и предлагать подписать ещё раз. Реальный dApp тоже способен выдавать ошибки, поэтому сам повтор не доказывает мошенничество. Но он создаёт риск серии разных approvals. Перед повтором проверяют TxID/receipt первой операции и выясняют, что именно изменилось. Никогда не компенсируют непонятную ошибку ростом allowance или отключением защитных настроек.

Компрометация официального фронтенда и фишинговый клон — разные incident paths

В одном случае пользователь находится на поддельном домене; в другом проблема может затронуть настоящий интерфейс, его dependency или инфраструктуру. Для пользователя первичная защита одинакова — не подписывать неожиданные права и сверять on-chain параметры. После инцидента различается уведомление: при подозрении на официальный сервис стоит проверить его security announcements и governance, а не только пометить домен как фишинг.

Главное — не угадывать бренд drainer, а установить полномочие

Названия drainer kits быстро меняются, а один и тот же домен может использовать другой backend. Для защиты мало пользы от попытки определить, Angel это, Inferno или другое семейство. Критичны доказуемые факты: какую сеть использовали, что подписал owner, какой spender/operator получил право, какой token затронут, есть ли deadline и какие действия уже произошли on-chain.

Диагностика: как установить, что именно было подписано и какой риск остаётся

Начните с сети, времени и последнего осознанного действия

Расследование проще, если сначала зафиксировать три опорные точки: chain, примерное время и действие, которое пользователь ожидал выполнить. Например: Ethereum, 14:05, claim. Затем сравнивают это ожидание с on-chain событиями и сохранёнными окнами подписи. Без временной линии человек легко смешивает старые approvals, обычные swaps и новый инцидент. Скриншоты кошелька, история браузера и уведомления помогают связать off-chain подпись с последующим использованием.

Найдите TxID всех on-chain операций вокруг инцидента

Транзакции позволяют увидеть target contract, method, events и результат исполнения. Для воспроизводимой проверки полезно использовать инструкцию по TxID. Сохраняют не только подозрительный исходящий Transfer, но и предшествующий approve, setApprovalForAll или contract call. Если операция reverted, фиксируют и её: иногда опасное разрешение было отдельной предыдущей транзакцией и осталось действующим, хотя следующий swap или claim завершился ошибкой.

Approval event показывает момент выдачи разрешения

В EVM token approval обычно оставляет событие Approval. В нём можно связать owner, spender и value. Это полезно для классического approve, но не покрывает все формы подписей до их on-chain применения. Поэтому отсутствие Approval в истории не доказывает, что пользователь не подписал Permit. И наоборот, наличие Approval не доказывает мошенничество: нужно определить, соответствует ли spender ожидаемому протоколу.

Проверьте текущее allowance, а не только историческую транзакцию

После использования allowance мог уменьшиться, а после revoke — стать нулевым. Текущее состояние отвечает на вопрос, что spender может сделать сейчас. История отвечает на вопрос, что происходило раньше. Для incident-response нужны оба слоя. Если текущий allowance нулевой, но токены уже ушли, защита будущего баланса улучшилась, однако прошлую кражу это не отменяет.

Permit-подпись требует отдельного анализа nonce и deadline

Если пользователь сохранил окно typed data, нужно выписать token/domain, owner, spender, value, nonce и deadline. Если подпись неизвестного назначения не была использована, риск может сохраняться до её истечения или invalidation по правилам конкретной реализации. Не следует ограничиваться обычным token approval scanner, потому что off-chain подпись до предъявления может там не отображаться.

Permit2 проверяется на двух уровнях

Сначала выясняют, существует ли базовый ERC‑20 approval от token contract к Permit2. Затем смотрят конкретные Permit2 allowances/signatures: кто spender, какой amount, expiration, nonce и режим использовался. Это защищает от двух противоположных ошибок: пользователь отзывает только dApp spender, но оставляет ненужный широкий базовый approval; либо паникует из-за Permit2 contract approval, хотя все downstream permissions ограничены и понятны.

NFT operator approval ищут отдельно от fungible token allowance

Если инцидент связан с mint, marketplace или NFT claim, проверяют ApprovalForAll и одобрения конкретных tokenId. ERC‑20 scanner может вообще не показать NFT operator rights. Это важно для кошельков, где ценность сосредоточена в коллекциях, а ERC‑20 баланс невелик. После неизвестного setApprovalForAll operator следует рассматривать как отдельную поверхность риска.

Определите, был ли скомпрометирован ключ

Признаки key compromise сильнее, чем факт вредного allowance: неизвестные прямые транзакции с native coin, подписи из среды, которой пользователь не пользовался, изменение поведения сразу в нескольких независимых сетях, раскрытая seed-фраза или установленный stealer. Если злоумышленник способен подписывать новые действия без участия владельца, revoke одного spender не решает проблему. Тогда security boundary переносится на новый кошелёк и чистое устройство.

Сравните проблему с заражением устройства

Drainer через approval может работать при полностью чистом endpoint: пользователь сам подписал вредный запрос. Clipboard malware или seed stealer требуют другого remediation. Если есть признаки вредоносного ПО, пригодится материал о вирусе, крадущем seed-фразу. Важно не устанавливать «антивирус от поддержки» по ссылке из чата — это распространённый способ превратить один инцидент в полный compromise.

Не делайте вывод по одному интерфейсу кошелька

Wallet UI может скрывать внутренние вызовы, агрегировать approvals или по-разному декодировать typed data. Block explorer тоже не всегда удобно показывает семантику. Для значимой суммы используют несколько независимых представлений: кошелёк, explorer, approval scanner и официальную документацию контракта. Разногласие между ними — повод остановиться и анализировать, а не выбирать наиболее успокаивающий экран.

Что делать до списания и после него: порядок защитных действий

Если баланс на месте — прекратите подписывать новые запросы

Первое преимущество пользователя — время. Если подозрительный сайт открыт, но активы ещё на месте, не нужно пытаться «исправить» ситуацию внутри того же интерфейса. Закройте вкладку, отклоните pending wallet prompts и перейдите к независимой проверке permissions. Повторные подписи под видом cancel/recover могут создать дополнительные права.

Disconnect полезен, но выполняется после понимания его границ

Удалить сайт из Connected Apps разумно, чтобы он не продолжал инициировать удобные запросы. Но это не security reset. MetaMask отдельно подчёркивает различие между connection и token allowances. Для общего сценария после подозрительного сайта есть отдельный аварийный чек-лист. Здесь важно помнить: после disconnect всё равно проверяются approvals и подписанные permissions.

Revoke приоритетен для известных активных allowances

Если идентифицирован вредный spender и allowance ещё действует, его отзыв уменьшает future risk. Делать это лучше через проверенный инструмент или непосредственно поддерживаемый explorer/wallet flow. Пользователь должен убедиться в правильной сети и контракте: случайный сайт, рекламирующий «revoke all», способен сам быть фишингом.

Неизвестная Permit-подпись требует осторожнее обычного revoke

Если подпись ещё могла не быть применена, текущий allowance может выглядеть безопасно. Для EIP‑2612/Permit2 оценивают nonce, deadline и механизм invalidation конкретной системы. Если содержание подписи невозможно восстановить, а на адресе большая сумма, консервативный сценарий — перенести активы на новый security boundary, а не полагаться на отсутствие видимого approval.

Перенос остатка нужен не всегда, но иногда это самый надёжный control

Если seed-фраза не раскрыта и вредный allowance точно отозван, новый кошелёк не обязателен автоматически. Но при неизвестной подписи, множестве непонятных действий, подозрении на malware или key compromise перенос снижает неопределённость. Решение принимают по worst-case правам, а не по эмоции. Новый адрес не должен использовать ту же раскрытую seed-фразу.

Порядок revoke и transfer зависит от типа угрозы и времени

Нет универсального совета «всегда сначала revoke» или «всегда сначала transfer». Если spender уже активно расходует ERC‑20, competing transactions и gas dynamics могут иметь значение; если ключ скомпрометирован, злоумышленник видит любые ваши новые действия. Для крупной позиции лучше минимизировать импровизацию и использовать заранее подготовленный incident plan. Статья не обещает, что обычная пользовательская транзакция опередит автоматизированного атакующего.

Если токены уже списаны — фиксируйте доказательства до очистки интерфейса

Сохраните TxID, chain, token contract, spender/operator, recipient, домен, скрин запросов, время и источник ссылки. Эти данные нужны для понимания механизма, обращения к сервисам и последующего анализа. Удаление истории браузера и panic-reinstall до фиксации могут уничтожить полезный контекст. При этом seed-фразу и приватный ключ в доказательный пакет не включают.

Уведомление централизованной площадки имеет смысл, если туда пришли средства

Если on-chain tracing показывает перевод на адрес, который можно уверенно связать с биржей или кастодиальным сервисом, официальный support/compliance channel может принять TxID и данные инцидента. Это не гарантирует заморозку или возврат, но является реальным маршрутом. Нельзя платить посредникам за «связи с биржей» или передавать им recovery phrase.

Recovery scammers используют уже случившуюся потерю как второй этап атаки

После публикации адреса или вопроса в сообществе жертве часто пишут «специалисты по возврату». Они просят seed, подключение кошелька, удалённый доступ или предоплату. Технически подтверждённый блокчейн-перевод нельзя отменить волшебной программой. Любое предложение сначала отправить комиссию или подписать «recovery transaction» нужно считать новой отдельной угрозой.

После инцидента пересмотрите архитектуру, а не только конкретный сайт

Если пользователь просто занесёт домен в чёрный список, следующий клон повторит тот же сценарий. Полезнее изменить систему: отдельный dApp-wallet, spending caps, аппаратный экран, bookmarks, регулярный approval audit, запрет blind signing и лимит суммы на hot wallet. Тогда одна ошибка не приводит к потере всего портфеля.

Как не подписать drainer: превентивная архитектура вместо надежды на внимательность

Разделите хранение и dApp-операции

Самая сильная организационная защита — не подключать основной vault-wallet к экспериментальным dApp. Hot wallet получает ограниченную сумму для конкретной задачи; основной адрес используется для хранения и заранее известных операций. Тогда даже ошибочный approval имеет ограниченный blast radius. Это не заменяет проверку подписи, но снижает последствия человеческой ошибки.

Используйте spending cap, соответствующий операции

Если swap требует 250 USDT, approval на астрономический лимит создаёт больше остаточного риска, чем разрешение около нужной суммы. Не все приложения одинаково поддерживают custom cap, но если опция есть, принцип least privilege разумнее unlimited по умолчанию. После завершения редкой операции ненужное разрешение можно отозвать.

Регулярный approval audit должен быть событием календаря

Старые allowances забываются быстрее, чем банковские подписки. Для активного EVM-пользователя полезно периодически просматривать token approvals и NFT operators во всех используемых сетях. Это особенно важно после тестов новых протоколов, airdrops и миграций. Цель аудита — не обнулить всё бездумно, а понять, какие права всё ещё нужны.

Официальный домен должен открываться из сохранённого доверенного источника

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

Читайте wallet prompt как договор полномочий

Перед подтверждением задайте пять вопросов: какая сеть, какой token/collection, какой spender/operator, какая сумма/срок и почему это необходимо заявленному действию. Если хотя бы один ответ неизвестен, операция ещё не готова к подписи. Такая дисциплина эффективнее попытки запоминать все названия drainer kits.

Симуляция и security alerts — второй слой, а не замена анализа

MetaMask и другие кошельки показывают предупреждения о вредоносных адресах, сайтах или ожидаемых transfer. Это полезный threat-intelligence слой. Но сами провайдеры предупреждают, что сигналы не являются гарантией безопасности. Новый вредный контракт может ещё не иметь репутации. Отсутствие красного баннера означает только отсутствие обнаруженного сигнала.

Аппаратный secure display особенно полезен против host-подмены

Hardware wallet помогает сравнить destination и часть параметров независимо от браузера. Но пользователь всё равно должен читать экран, а не автоматически подтверждать. Подробно модель аппаратной защиты разобрана в материале о Ledger. Устройство не способно понять бизнес-цель операции за человека.

Не смешивайте основной кошелёк с тестовыми airdrop и mint

Spam-token, NFT и случайный claim создают слишком много запросов на подпись. Если неизвестный токен появился сам, лучше не взаимодействовать с его ссылками; отдельный безопасный разбор есть в статье о неизвестном токене и airdrop. Получение объекта на публичный адрес само по себе не требует ответной транзакции.

Проверяйте permissions после обновления или миграции dApp

Протокол может менять router, spender, Permit2 integration или contracts. Новый адрес не обязательно вреден, но пользователь должен понимать изменение. Если dApp внезапно запрашивает другой spender, стоит сверить release notes/официальную документацию. Старая привычка «я этим сервисом пользуюсь год» не подтверждает новый контракт.

Для командных кошельков нужен процесс двухконтрольной подписи

В компании один оператор может подготовить транзакцию, а другой проверить домен, spender, amount и decoded effects. Multisig полезен только если подписанты реально выполняют независимую проверку. Если все подтверждают по одному сообщению в чате, много подписей превращаются в формальность. Для казначейства стоит отдельно фиксировать allowlist протоколов и лимиты approval.

Практические сценарии и контрольный алгоритм перед подписью

Сценарий: поддельный airdrop просит Unlimited Approval

Ожидаемая цель — получить reward. Кошелёк показывает approval на ваш USDT для неизвестного spender и огромного лимита. Экономический смысл не совпадает с заявленной целью: чтобы получить токен, сайту обычно не требуется право расходовать весь ваш другой актив. Решение — отклонить запрос, закрыть домен, проверить, не было ли предыдущих approvals, и открыть официальный канал проекта независимо.

Сценарий: mint NFT запрашивает setApprovalForAll

Пользователь ожидает создать один NFT, но кошелёк показывает operator permission для уже существующей коллекции. Это существенная разница. Перед подписью нужно установить, зачем mint-процессу нужен доступ к другим NFT. Если объяснения нет, запрос отклоняют. После ошибочного подтверждения проверяют operator approvals коллекции, а не только ERC‑20 allowances.

Сценарий: сайт просит typed-data подпись без gas

Отсутствие gas воспринимается как безопасность, но в typed data присутствуют token, spender, amount и deadline. Это типичный момент, когда нужно остановиться и понять, является ли сообщение Permit/Permit2 или протокол-специфической авторизацией. Если домен неизвестен или spender не совпадает с официальным контрактом, подпись не подтверждают.

Сценарий: пользователь уже подписал Permit2, но токены ещё на месте

Паника здесь опасна так же, как бездействие. Нужно определить режим Permit2, базовый token approval, spender, expiration и nonce. Затем использовать поддерживаемые механизмы revoke/invalidation и оценить, остаётся ли подписанная authorization действительной. Если восстановить содержание подписи невозможно, крупный баланс разумно изолировать на новом адресе.

Сценарий: Disconnect сделан, но allowance остаётся

Пользователь считает проблему решённой, потому что сайт исчез из Connected Apps. On-chain scanner показывает прежний allowance. Это нормальное следствие архитектуры: connection и token permission независимы. Пока allowance не отозван или не исчерпан, spender может сохранять право в рамках token contract.

Сценарий: после approve ничего не произошло несколько дней

Отсутствие мгновенного drain не подтверждает безопасность. Вредный spender может ждать поступления большего баланса или действовать позже. Если approval не соответствует осознанной операции, его оценивают по принципу least privilege и обычно отзывают. Особенно опасно продолжать использовать адрес как долгосрочное хранилище, надеясь, что «если за сутки ничего не случилось, значит всё нормально».

Сценарий: токены ушли, но native coin остался

Это может указывать на token-specific allowance, а не полный key compromise. Но вывод предварительный. Нужно проверить, был ли Transfer вызван spender через allowance, есть ли неизвестные прямые транзакции и затронуты ли другие активы. Если только один token использован через известный approval, remediation отличается от утечки seed. Если появляются независимые подписанные действия, уровень угрозы повышается.

Сценарий: seed-фраза вводилась на claim-сайте

Это уже не ограниченный drainer risk. Даже если текущие approvals отозваны, злоумышленник способен восстановить кошелёк и подписывать новые транзакции. Старый адрес нельзя считать безопасным для будущего хранения. Создаётся новая seed-фраза на чистом устройстве, а активы переносятся с учётом сетевых комиссий и риска competing transactions.

Сценарий: кошелёк показывает security warning

Предупреждение нужно воспринимать как причину остановиться, а не как сообщение, которое можно «понять потом». MetaMask прямо указывает, что malicious classification означает высокий риск phishing/wallet-draining activity. Если приложение действительно легитимно, пользователь может вернуться к нему после независимой проверки. Пропущенный reward дешевле потери основного кошелька.

Тридцатисекундный pre-sign чек

Перед любым значимым Web3 подтверждением проверьте: правильный chain; официальный domain; ожидаемый method; известный spender/operator; token/collection; amount или spending cap; expiration/deadline; ожидаемые transfers в simulation; отсутствие seed/private-key запроса. Если интерфейс скрывает критическое поле, лучше остановить операцию и открыть документацию, чем восполнять неизвестность догадкой.

Пятиминутный post-incident чек

Если подпись уже сделана: не подписывать новые prompts; сохранить скрин и домен; проверить TxID; посмотреть current approvals и NFT operators; определить Permit/Permit2; отключить dApp; отозвать подтверждённые опасные права; оценить перенос активов; зафиксировать доказательства. Если выяснилось, что проблема — только harmless Connect, действия можно завершить без бессмысленной миграции всего кошелька.

Authority graph: почему одного списка approvals иногда недостаточно

Для серьёзной проверки полезно нарисовать граф полномочий, а не смотреть только на последнюю транзакцию. В центре находится ваш адрес. От него расходятся ERC‑20 allowances к spender-контрактам, NFT operator approvals, Permit2-разрешения, роли смарт-аккаунта и возможные сессионные ключи конкретного приложения. Каждый слой отвечает на отдельный вопрос: кто способен инициировать действие, какой актив затрагивается, есть ли количественный лимит и как долго действует право. Такой граф особенно полезен после нескольких взаимодействий с DeFi, потому что один и тот же интерфейс может вызвать router, Permit2 и конечный протокол.

Практический аудит начинается с инвентаризации сетей и активов. Для каждой EVM-сети фиксируют token contract, spender/operator, allowance, expiration или иное условие, а затем сопоставляют право с реальным сервисом, которым пользователь собирался пользоваться. Неизвестный spender не объявляют вредоносным только по факту незнакомого адреса: router и proxy тоже выглядят непривычно. Но право без объяснимой бизнес-функции нельзя оставлять «на всякий случай». Если архитектура приложения не позволяет установить, зачем нужен конкретный spender, это достаточная причина не увеличивать экспозицию.

EIP‑712 domain separation: подпись должна относиться к ожидаемому приложению

Typed-data подпись содержит структурированные поля, но безопасность зависит не только от красиво декодированного текста. В EIP‑712 используется domain separator, который связывает сообщение с определённым доменом применения, например contract address и chain context. Для пользователя практический смысл прост: название действия в кошельке не должно заменять проверку verifying contract, chain и параметров сообщения. Если интерфейс обещает обычную авторизацию, а typed data фактически относится к token permit или другому contract domain, запрос нужно отклонить.

Domain separation снижает риск переноса подписи между несовместимыми контекстами, но не превращает вредную подпись в безопасную. Мошеннический сайт способен сформировать полностью корректное EIP‑712 сообщение именно для того контракта, которому хочет выдать полномочие. Поэтому вопрос формулируют не «валидна ли подпись технически», а «ожидал ли я создать это право именно для этого verifying contract, токена, spender и срока». Валидная криптография доказывает авторство сообщения, а не разумность решения.

Nonce и deadline: почему одноразовость не означает безвредность

Permit-подобные схемы используют nonce, чтобы одну и ту же подписанную авторизацию нельзя было бесконечно применять повторно, а deadline ограничивает период её допустимости. Это важные защитные свойства протокола, но они не спасают пользователя, который с первого раза подписал вредное полномочие. Короткий deadline лишь сокращает окно; nonce лишь предотвращает повторное использование уже потреблённой авторизации по тем правилам, которые определяет конкретный контракт.

После подозрительной typed-data подписи полезно сохранить её decoded fields: owner, token, spender, amount, nonce, deadline и verifying contract. Если кошелёк или сервис не показывает эти параметры, нужно искать независимый decoder или документацию, а не подписывать вслепую. Для уже подписанной авторизации важно понять, была ли она опубликована on-chain и существует ли поддерживаемый механизм invalidation. Нельзя автоматически считать обычный ERC‑20 revoke универсальным способом аннулировать любую off-chain подпись.

Permit2: два уровня полномочий нужно проверять отдельно

В Permit2 пользователь может столкнуться с двумя разными слоями. Сначала ERC‑20 token contract может дать базовое разрешение самому Permit2. Затем внутри Permit2 задаются права конкретным spender либо используются signature-transfer механизмы. Поэтому фраза «я отозвал dApp» ничего не говорит о базовом token→Permit2 approval, а фраза «я вижу Permit2» ещё не объясняет, какой конечный spender имел право действовать. Для аудита эти уровни записывают раздельно.

Практически это означает двойную проверку после подозрительного сайта: какие токены одобряли Permit2 как spender на уровне ERC‑20 и какие downstream permissions или подписи были созданы внутри Permit2-механики. Не нужно панически отзывать всё только из-за присутствия Permit2 — он используется легитимными приложениями. Но неограниченное или непонятное право должно иметь документированную причину. Если её нет, принцип least privilege важнее удобства повторного swap.

Revoke race: защитная транзакция сама требует времени на включение в блок

Revoke — это не мгновенная кнопка отмены, а новая on-chain транзакция. Пока она pending, прежнее allowance может оставаться действующим по состоянию сети. Поэтому при активном инциденте нельзя считать проблему решённой в момент нажатия Revoke: нужно дождаться receipt и проверить новое состояние allowance. В стрессовой ситуации также возможна конкуренция нескольких транзакций за порядок исполнения, поэтому remediation-план должен учитывать подтверждение, а не только отправку.

Из этого не следует, что всегда нужно срочно повышать комиссию или пытаться переиграть злоумышленника вручную. Правильная тактика зависит от типа полномочия, состояния сети и ценности оставшихся активов. Главное — не создавать новые approvals, не возвращаться на исходный сайт и контролировать фактический результат защитной операции. Если риск распространяется на ключ, а не только на allowance, одного revoke недостаточно и приоритет смещается к новому кошельку.

Dormant allowance: опасное право может не использоваться сразу

Drainer не обязан списывать токены в ту же секунду, когда получил approval. Allowance может существовать долго и стать опасным позже, когда на адрес поступит новый баланс. Поэтому отсутствие потерь после первой минуты или первого дня не является подтверждением безопасности. Это особенно важно для адресов, которые регулярно получают зарплату, выручку, staking rewards или крупные переводы с биржи.

После инцидента полезно проверить не только текущий balance, но и будущий поток средств. Если адрес фигурирует в автоматических выплатах, whitelist биржи, payroll или личных шаблонах, нужно решить, безопасно ли продолжать его использовать. При ограниченном вредном allowance иногда достаточно revoke и повторной проверки. При неопределённости в подписанных правах или компрометации ключа лучше изменить сам security boundary, иначе новый депозит может стать моментом позднего drain.

Spending cap нужно сравнивать не с балансом, а с назначением операции

Пользователь часто оценивает approval так: «на кошельке только 100 USDT, значит лимит 100 не опасен». Но если завтра баланс станет 10 000 USDT, действующее право может затронуть новую сумму в пределах cap. Поэтому лимит выбирают относительно конкретной операции, а не текущего остатка. Для разового swap право на значительно большую сумму должно иметь объяснимую причину.

Принцип least privilege не означает механически ставить лимит ровно до последней единицы во всех приложениях: некоторые протоколы требуют небольшой технологический запас или используют повторные действия. Но пользователь должен понимать, почему cap больше ожидаемой операции и как долго он нужен. Если dApp просит Unlimited просто ради удобства, это выбор между UX и blast radius, а не обязательное условие безопасности.

Simulation полезна, но не является криптографической гарантией результата

Современные кошельки и security-сервисы могут симулировать транзакцию и показывать предполагаемые token transfers, approvals и изменения NFT. Это сильный защитный слой: неожиданный transfer или approval виден до подписи. Но simulation рассчитывается на конкретном состоянии и конкретной модели декодирования. Состояние может измениться, сложный контракт может зависеть от внешних вызовов, а новый вредный паттерн — ещё не иметь понятной метки.

Поэтому simulation используют как второй источник, а не как разрешение отключить собственную проверку. Совпасть должны domain, contract, method, token, spender/operator, amount и экономический смысл операции. Пустой или неполный preview — не доказательство отсутствия последствий. Если крупная сумма зависит от подписи, которую кошелёк не умеет объяснить, рациональный ответ — остановиться и разобраться, а не считать отсутствие красного предупреждения зелёным светом.

Signature phishing отличается от обычного фишинга пароля

В классическом фишинге злоумышленник пытается получить секрет: пароль, seed или 2FA-код. В signature phishing пользователь может не раскрывать ни одного секрета; он сам применяет приватный ключ для создания действительной подписи. Именно поэтому смена пароля браузера после такой ошибки не отменяет уже созданное on-chain или off-chain полномочие. Нужно анализировать конкретный объект авторизации.

Эта разница меняет incident response. Если украден seed, старый набор ключей больше не доверенный. Если выдан ограниченный token allowance, ключ может оставаться секретным, а remediation сводится к отзыву права и аудиту истории. Если подписан Permit, нужно оценить его nonce/deadline и статус использования. Если неизвестно, что именно подписано, неопределённость сама становится фактором риска и оправдывает более консервативную миграцию ценных активов.

NFT-drainer требует проверки operator approvals, а не только ERC‑20

Пользователь может открыть популярный ERC‑20 approval scanner, увидеть ноль опасных allowances и решить, что всё чисто. Для NFT этого недостаточно. ERC‑721 допускает разрешение на конкретный token ID и operator approval через setApprovalForAll. Вторая модель особенно чувствительна: один operator может получить полномочие оператора распоряжаться NFT владельца, относящимися к указанной коллекции.

После подозрительного mint или marketplace-подписи проверяют NFT approvals отдельно. Важно установить collection contract, operator и текущий статус. Ошибку нельзя диагностировать по тому, что ERC‑20 USDT остались на месте. Drainer-кампания может быть ориентирована только на NFT, а wallet balance в обычных токенах выглядеть неизменным. И наоборот, наличие operator approval легитимному marketplace не делает саму коллекцию скомпрометированной.

Smart account и session keys расширяют модель полномочий

В смарт-аккаунтах и account-abstraction системах могут использоваться дополнительные роли, modules, session keys или policy contracts. Тогда риск нельзя свести к классическому EOA approve. Пользователь может авторизовать ограниченный ключ для определённой функции или установить модуль, который влияет на допустимые операции. Конкретная модель зависит от реализации, поэтому старый чек-лист MetaMask не переносится автоматически на любой smart account.

Практическое правило остаётся тем же: составьте список активных authority, их scope, срок и способ отзыва. Если dApp предлагает «session» или «automation», нужно понять, какие методы разрешены, есть ли spending limit и где хранится ключ. Неизвестный модуль в смарт-аккаунте может быть важнее десятка ERC‑20 allowances. Для крупного капитала такие возможности включают только после чтения официальной документации и теста на малом балансе.

Cross-chain интерфейс не создаёт единого глобального approval

Один и тот же EVM-адрес может использоваться в Ethereum, Arbitrum, Base, BNB Chain и других сетях, но state approvals хранится отдельно в каждой сети. Revoke в Ethereum не очищает разрешение в Arbitrum. Поэтому пользователь, который взаимодействовал с одним мультичейн-интерфейсом, должен проверить все фактически использованные chain IDs, а не только сеть, где сейчас лежит основной баланс.

Это особенно важно после bridge, aggregator или cross-chain dApp. У интерфейса может быть один бренд, но контракты и permissions различаются по сетям. В incident log сохраняют chain, transaction hash, token contract и spender для каждой операции. Формулировка «я отозвал доступ у сервиса» слишком общая, пока не известно, какие on-chain состояния действительно изменились.

Proxy и upgradeability меняют долгосрочный риск allowance

Approval выдаётся адресу spender. Если этот адрес является upgradeable proxy, логика, которая использует allowance, потенциально может меняться в рамках предусмотренной архитектуры. Это не делает любой proxy опасным — многие зрелые протоколы используют upgrades для исправлений. Но долгоживущий unlimited approval к upgradeable системе означает зависимость не только от текущего кода, но и от governance/admin path.

Поэтому для редко используемых приложений разумно отзывать права после операции, даже если сервис легитимен. Пользователь уменьшает не только риск прямого скама сегодня, но и будущий риск компрометации протокола, upgrade authority или интеграции. Если approval нужен постоянно, контролируйте новости безопасности и адрес spender, а не только знакомый бренд интерфейса.

Allowance inventory: периодический аудит лучше памяти пользователя

Человек плохо помнит десятки Web3-взаимодействий. Поэтому полезен отдельный реестр разрешений: сеть, token, spender, cap, дата выдачи, назначение, статус и дата следующего review. Для личного hot wallet это может быть простая таблица; для команды — автоматизированный отчёт с ответственным владельцем. Главное — чтобы каждое долгоживущее право имело объяснимую причину.

При ревизии удаляют approvals к сервисам, которыми больше не пользуются, уменьшают неоправданно широкие caps и отдельно проверяют новые spender после миграций протокола. Такой аудит не гарантирует отсутствие вредных подписей, но резко сокращает поверхность атаки. Если неизвестный permission обнаружен спустя месяцы, его расследуют по transaction hash и дате, а не пытаются вспомнить все посещённые сайты.

Hot wallet, vault wallet и cold storage должны иметь разные полномочия

Самая надёжная защита от drainer — ограничить сумму, которую вообще можно авторизовать с активного Web3-кошелька. Hot wallet используется для dApp и содержит операционный баланс. Отдельный vault/cold wallet хранит основной капитал и не участвует в повседневных claim, mint и экспериментальных интеграциях. Тогда ошибка подписи остаётся локальной и не превращается в потерю всего портфеля.

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

Корпоративный Web3 требует dual control и независимой проверки calldata

Для treasury или операционного кошелька одного внимательного сотрудника недостаточно. Перед значимой подписью второй человек независимо проверяет домен, chain, target contract, method, token, amount и spender/operator. Multisig полезен только тогда, когда участники действительно проводят независимую проверку; механическое подтверждение одним и тем же шаблоном создаёт иллюзию безопасности.

Команда также должна определить emergency process: кто блокирует новые подписи, кто собирает TxID, кто проверяет approvals по сетям, кто решает о миграции активов и где хранятся официальные адреса контрактов. В инциденте эта схема экономит минуты и снижает риск того, что сотрудник в панике подпишет второй вредный запрос под видом revoke или recovery.

Incident reconstruction: важен не только TxID списания, но и TxID создания права

Если токены уже ушли через transferFrom, сам outflow показывает исполнение разрешения, но не обязательно объясняет, когда пользователь его создал. Для полного расследования нужно найти исходный approval transaction либо соответствующую Permit/Permit2 authorization. Это позволяет связать потерю с конкретным доменом, временем и пользовательским действием и понять, какие другие права могли быть выданы в той же сессии.

Собирайте минимум два слоя доказательств: authorization evidence и execution evidence. Для on-chain approve это transaction hash и Approval event; для typed-data — сохранённые decoded fields, подпись, domain и последующая транзакция, которая её использовала; для drain — transfer/transferFrom и адрес получателя. Такой пакет полезнее одного скриншота баланса и позволяет отличить drainer от key compromise или обычного ошибочного перевода.

Не каждое неизвестное списание является drainer

Если токены ушли без ожидаемого Send, возможны разные причины: старый allowance, Permit, смарт-контрактная позиция, автоматическое погашение, bridge/vault withdrawal, liquidation, compromised key или ошибка интерфейса. Ярлык drainer применяют только после установления механизма. Иначе пользователь может отозвать approvals, но оставить активный скомпрометированный ключ, либо наоборот — мигрировать кошелёк из-за легитимного protocol action.

Диагностика начинается с transaction sender, `to`, decoded method, token events и инициатора. Если EOA owner не подписывал текущую транзакцию, но token transfer выполнен spender-контрактом в пределах allowance, это один сценарий. Если исходящую транзакцию подписал сам owner неизвестным ключом, уровень угрозы другой. Если action инициирован protocol contract по правилам позиции, это может быть вообще не кража.

Security alert не заменяет policy: красная метка — стоп, отсутствие метки — не зелёный свет

Wallet security alerts полезны для известных фишинговых доменов, вредных contracts и подозрительных transaction effects. При высокой уверенности кошелёк может показать серьёзное предупреждение, которое нельзя игнорировать ради срочного airdrop. Но новые кампании появляются быстрее списков блокировки, а сложные legitimate contracts могут выглядеть необычно. Поэтому отсутствие предупреждения не подтверждает безопасность.

Рабочая политика должна действовать даже без alerts: официальный домен из независимого источника, проверенный contract, понятный method, разумный cap, минимальный hot-wallet balance и независимая simulation. Alerts добавляют ещё один барьер, но не становятся единственной линией защиты. Если пользователь не способен объяснить создаваемое право одним предложением, подпись откладывают.

Контрольная запись после взаимодействия снижает риск отложенного drain

После каждого нового dApp с существенной суммой полезно зафиксировать, какие approvals или signatures были созданы, и через несколько минут проверить конечное on-chain состояние. Пользователь убеждается, что allowance соответствует ожидаемому лимиту, operator не появился неожиданно, а транзакция не создала дополнительных permissions. Для Permit2 отдельно фиксируют конечного spender и срок.

Такая post-action проверка особенно полезна после интерфейсных обновлений протокола. Даже знакомый сервис может изменить router или permission flow. Если новое поведение отличается от старого, не нужно автоматически считать его атакой, но и слепо переносить прежнее доверие нельзя. Проверяется официальный migration notice и фактический contract address.

Approval zeroing и изменение лимита: что важно проверить после revoke

Для классического ERC‑20 пользователь обычно ожидает, что revoke приведёт allowance к нулю. Но проверка должна смотреть фактическое значение `allowance(owner, spender)` после подтверждения транзакции, а не только статус интерфейса. Некоторые токены имеют нестандартное поведение, а агрегатор разрешений может кешировать данные. Если сумма значительна, прочитайте state напрямую через explorer или надёжный RPC и сохраните block number, на котором проверка выполнена.

Когда задача — не удалить право полностью, а уменьшить cap, принцип тот же: после транзакции сверяют итоговое значение и spender. Не стоит путать успешный transaction receipt с правильной конфигурацией: транзакция может успешно изменить другой allowance, если пользователь выбрал не ту сеть или не тот token contract. В журнале remediation полезно хранить до/после, TxID и проверенный результат.

Replay и chain context: старую подпись нельзя оценивать без домена

Страх перед replay часто формулируется слишком широко: пользователь думает, что любая подпись можно воспроизводить где угодно. Современные permit-схемы обычно включают nonce и domain separation, поэтому область применимости ограничивается правилами конкретного стандарта и реализации. Но оценивать старую подпись по одному визуальному тексту нельзя — нужны verifying contract, chain context, nonce, deadline и то, была ли authorization уже использована.

Для пост-инцидентного анализа это означает: не публикуйте подпись целиком в открытом чате и не передавайте её случайному «помощнику». Сохраните данные локально и используйте проверенный decoder. Вредная, но ещё действительная подпись сама по себе может быть чувствительным объектом. Задача расследования — понять её scope и безопасный способ invalidation, а не распространять authorization между сервисами.

Native coin и ERC‑20: approve не даёт универсальный доступ ко всему кошельку

ERC‑20 allowance относится к конкретному token contract и spender. Разрешение на USDT не является общим правом забрать ETH, USDC, NFT и активы в других сетях. Это важное ограничение помогает диагностике: если после одного approval исчезают независимые типы активов, нужно искать дополнительные permissions, batch-механику либо компрометацию ключа, а не объяснять всё одним allowance.

Одновременно не следует успокаиваться тем, что native coin остался на месте. Drainer может выбирать активы, для которых уже получил права, и не иметь доступа к остальным. Проверка проводится по каждому классу активов: ERC‑20 allowances, NFT operators, Permit2 и прямые owner-signed транзакции. Только после этого можно оценить blast radius.

Approval scanners показывают состояние, но не всегда намерение пользователя

Scanner может корректно показать spender и unlimited allowance, но не знает, почему пользователь его выдал. Легитимный router и вредный контракт технически используют одну и ту же стандартную возможность. Поэтому риск-рейтинг сервиса полезен, однако финальный вывод строится по контексту: официальный ли это contract, соответствует ли дата реальному взаимодействию, нужен ли такой scope и есть ли актуальная документация.

В обратную сторону тоже работает: отсутствие красной метки не делает новый spender безопасным. Новый drainer может не иметь истории. Для неизвестного контракта минимальный набор проверки — verified source или официальный deployment reference, возраст и история сами по себе вторичны. Если официальный проект не подтверждает адрес, не выдавайте право только потому, что explorer не показывает предупреждение.

Финальная сверка authority после инцидента

Remediation считается завершённой не тогда, когда исчезло тревожное окно, а когда пользователь может перечислить оставшиеся полномочия и объяснить каждое из них. Для выбранной сети повторно считывают ERC‑20 allowances, Permit2-права, NFT operators и связанные smart-account permissions; затем сравнивают их с утверждённым списком. Неизвестный остаточный authority возвращает инцидент в статус «не закрыт», даже если баланс пока не изменился.

После проверки фиксируют дату, block number или TxID последних revoke, список сохранённых разрешений и решение по дальнейшему использованию адреса. Если ключ не был раскрыт и все опасные полномочия достоверно отозваны, адрес не обязательно уничтожать. Если scope подписи невозможно восстановить либо есть признаки key compromise, безопасность нельзя доказывать отсутствием новых списаний — активы переводят в новый ключевой контур.

Контрольный вывод записывают до следующего взаимодействия с любым dApp.

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

Crypto drainer опасен не потому, что блокчейн «разрешает хакеру всё», а потому, что Web3 строится на программируемых правах. Approve, Permit, Permit2, NFT operator permissions и contract calls нужны легитимным приложениям, но те же механизмы становятся каналом кражи, если пользователь авторизует чужой spender или непонятное действие. Поэтому основная защита — понимать какое право создаётся, ограничивать его и уметь независимо проверить текущее состояние.

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

Главный практический вывод: Connect, Sign, Approve, Permit и Send — это разные действия. Не подтверждайте их как одну привычную последовательность. Чем яснее пользователь видит границы полномочий, тем меньше шанс, что красивый claim или mint превратит стандартный механизм Web3 в разрешение на потерю активов.