Дрейнеры и вредные разрешения: защита криптокошелька

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

У крипты есть неприятная особенность: подтверждение в кошельке может выглядеть как безобидное «Connect», «Verify» или «Claim», а юридически и технически давать контракту право распоряжаться токенами. Отменить уже исполненный перевод обычно нельзя. Но во многих сценариях можно успеть перекрыть дальнейшее списание.

Что такое дрейнер и почему он не просит seed-фразу?

Дрейнер, или wallet drainer, это набор сайта и смарт-контрактов, созданный для вывода активов после действий владельца кошелька. Злоумышленник может украсть токены через выданное разрешение, подпись permit, вредную сделку с NFT или прямой перевод, который ты подтвердил сам.

Классический сценарий выглядит просто. В Telegram, X, Discord или рекламе появляется ссылка на «аирдроп», ранний доступ к токену, компенсацию, mint или выгодный обмен. Сайт копирует дизайн известного проекта. Ты подключаешь кошелёк. Затем он просит «подтвердить владение», «активировать награду» или «заплатить только gas». В окне кошелька часто нет понятного описания конечного результата.

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

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

Чем больше операций ты делаешь в DeFi, NFT и мемкоинах, тем полезнее разделять задачи. Основной капитал держать отдельно, а для новых dApp использовать небольшой рабочий кошелёк. Базовую логику хранения разобрали в статье «Криптокошелёк простыми словами: виды и хранение».

Что именно может попросить сайт: connect, транзакцию или подпись?

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

Действие	Что обычно происходит	Есть комиссия сейчас	Возможный риск
Connect wallet	dApp получает публичный адрес и запрашивает сеть	Нет	Трекинг адреса, дальнейшие запросы
Transfer	Активы отправляются на другой адрес	Да	Прямая необратимая потеря
Approve	Контракт получает лимит на списание токена	Да	Будущее списание токенов в пределах лимита
SetApprovalForAll	Оператор получает доступ к NFT коллекции	Да	Передача или продажа NFT оператором
Sign message	Подписывается сообщение вне сети	Обычно нет	Permit, ордер или авторизация могут быть использованы позднее
Permit / Permit2	Подпись создаёт или расширяет право расходования	Обычно нет в момент подписи	Списание может инициировать третья сторона

Надпись «бесплатно» не означает «безопасно». Подпись может дать третьей стороне возможность позднее отправить permit в сеть и установить allowance, поэтому проверяй её параметры так же внимательно, как транзакцию.

Ещё одна ловушка: кошелёк может показать технические данные, имя неизвестного контракта или предупреждение «blind signing». Не нажимай Confirm только из-за утверждения сайта, что без него действие не сработает. Непонятный запрос на кошельке с существенным балансом лучше отклонить.

Что такое approval и почему unlimited опаснее обычного?

Approval, или allowance, это разрешение одному адресу, обычно смарт-контракту, тратить указанный ERC-20 токен с твоего кошелька. Контракт не получает приватный ключ, но может вызвать transferFrom и списать сумму в пределах выданного лимита.

Стандарт ERC-20 разделяет эти действия. Функция approve(spender, amount) задаёт лимит для адреса-получателя разрешения, а transferFrom позволяет ему расходовать токены от имени владельца. Это описано в документации OpenZeppelin для ERC-20.

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

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

Это не значит, что каждое unlimited-разрешение обязательно приведёт к краже. Многие популярные протоколы используют его для удобства и экономии на повторных подтверждениях. Но удобство не равно необходимости.

Нормальный вопрос перед подтверждением: «Почему этому контракту нужно право на весь мой баланс, если я меняю 100 USDC?» Если точный лимит доступен, выбирай сумму сделки с небольшим запасом на комиссию или проскальзывание, а не максимум.

Риск разрешений связан и с тем, как ты выбираешь активы для взаимодействия. Перед новым обменом полезно проверить сам токен и его контракт: вот отдельный алгоритм, как проверить токен на скам.

Чем permit и Permit2 отличаются от обычного approve?

Permit позволяет выдать разрешение подписью, без отдельной on-chain транзакции от владельца в момент подтверждения. Эта механика удобна, но делает фразу «я ничего не отправлял, только подписал» недостаточной защитой.

В стандарте EIP-2612 подпись permit может установить allowance для spender. После этого третья сторона отправляет транзакцию в сеть и передаёт подпись контракту. Владельцу токенов не обязательно держать нативную монету для gas в момент выдачи подписи.

В твоём кошельке это может выглядеть как Sign, а не Confirm transaction. Комиссии сейчас нет. Но подпись содержит параметры: токен, владелец, spender, лимит, nonce, дедлайн и данные сети. Если ты не понимаешь хотя бы spender и сумму, не подтверждай запрос.

Permit2 это отдельный контрактный слой от Uniswap для управления разрешениями и передачами токенов. В официальном обзоре Permit2 указано, что он объединяет механики allowance и signature-based transfers. В реальных интерфейсах это может означать две ступени доступа: разрешение токена контракту Permit2 и затем разрешение конкретному spender через Permit2.

Здесь легко сделать опасный вывод: «я уже отозвал approval у обменника, значит всё чисто». Не всегда. Подписанный EIP-2612 permit может ещё не отображаться как allowance: любой адрес может передать подпись в permit до дедлайна. Отзыв найденных approvals сам по себе такую подпись не отменяет. Нужно смотреть, какое именно разрешение выдано: непосредственно контракту dApp, Permit2 или NFT-оператору. Проверка должна охватывать все типы разрешений, которые показывает выбранный инструмент.

Никогда не подписывай permit только потому, что сайт обещает «gasless mint» или «проверку кошелька». У нормального приложения должны быть понятны домен, сеть, адрес контракта, актив и цель действия. Если этого нет, покинь страницу.

Какие разрешения особенно опасны для NFT?

Для NFT особую осторожность требует setApprovalForAll. В стандарте ERC-721 эта операция разрешает оператору управлять всеми NFT владельца в данном контракте, а авторизованный оператор может вызвать transferFrom или safeTransferFrom.

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

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

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

Практика для владельца NFT простая:

1. Не листи NFT по ссылке из личного сообщения, комментария или внезапной рекламы.
2. Открывай маркетплейс из сохранённой закладки или вручную введённого домена.
3. Перед SetApprovalForAll сверяй адрес оператора с официальной документацией площадки.
4. После разовой работы с малоизвестным сервисом отзывай доступ.
5. Ценные NFT держи на адресе, который не подключается к экспериментальным сайтам.

Как распознать фальшивый dApp до подключения кошелька?

Фальшивый dApp редко выглядит как очевидный вирус. Чаще он копирует логотип, тексты и палитру настоящего протокола. Защита начинается в момент, когда ты впервые видишь ссылку, ещё до окна подписи.

Проверь домен посимвольно. Замены вроде rn вместо m, лишний дефис, другая зона, переставленные буквы и поддомен перед настоящим названием часто рассчитаны на спешку. Адрес app.project.example и project.example.evil-site визуально похожи, но второе имя принадлежит evil-site.

Не переходи к dApp через поисковую рекламу, даже если название совпадает. Рекламные объявления, сообщения от «админов», ответы в комментариях и приглашения в Discord могут вести на клон. Безопаснее найти официальный сайт в документации проекта, его верифицированном профиле или собственных закладках.

Сигналы риска лучше оценивать вместе:

• обещание гарантированной доходности, крупного аирдропа или «компенсации только сегодня»;
• давление по времени: таймер, угроза потерять место, просьба действовать до листинга;
• неожиданный запрос на подпись после подключения;
• непонятная сеть или предложение переключиться на неизвестный RPC;
• запрос на unlimited approval для действия, которому он не нужен;
• «blind signing» без объяснения, что именно будет подписано;
• просьба раскрыть seed-фразу, приватный ключ или файл восстановления;
• техническая поддержка пишет первой и присылает ссылку для «валидации».

Seed-фразу нормальный кошелёк, биржа, маркетплейс и служба поддержки не запрашивают для помощи. Тот, кто её получил, получает полный контроль над адресами этого кошелька. Здесь revoke уже не решает проблему.

Эти же признаки полезны, когда ты проверяешь человека, продающего «доступ к стратегии» или «закрытый mint». Принцип проверки источника разобран в статье «Как проверить трейдера на мошенничество перед копированием».

Как читать окно кошелька перед подтверждением?

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

Перед Approve проверь токен и расходующий адрес. У известного токена есть конкретный контракт в конкретной сети. Название и тикер не доказывают подлинность: мошенник может создать токен с названием USDT, USDC или ETH. Адрес контракта нужно брать из официального источника проекта или блокчейн-эксплорера.

Перед Transfer проверь адрес назначения и сумму. Перевод не даёт времени «разобраться потом». Сверяй начало и конец адреса, а при крупной сумме делай тестовый перевод с небольшой величиной.

Перед Sign выясни, что за формат подписи. Читаемая SIWE-подпись для входа на сайт и непонятные структурированные данные не равны по риску. Структурированная подпись EIP-712 может быть нормальной, но должна содержать ожидаемые параметры. Если кошелёк показывает непонятный набор полей, ищи официальное описание действия или не подписывай.

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

Как проверить approvals и сделать revoke?

Для EVM-сетей проверка approvals начинается с выбора правильной сети. Разрешение в Ethereum не отображает разрешение в Base, Arbitrum, BNB Chain или Polygon, хотя адрес кошелька может быть тем же. Просматривать нужно все сети, где ты совершал действия.

Ethereum.org рекомендует проверять доступ контрактов через инструменты вроде Etherscan, Blockscout и Revoke.cash, а затем подтверждать отдельную транзакцию отзыва. В их руководстве по отзыву token access отдельно сказано: отключение кошелька от сайта не отменяет уже выданный allowance.

Безопасный порядок такой:

1. Открой инструмент вручную из закладки или введи проверенный адрес. Не переходи на «revoke-сервис» из рекламного объявления.
2. Сначала вставь публичный адрес кошелька в поиск. Подключение кошелька нужно только когда решишь отправить revoke-транзакцию.
3. Выбери сеть и просмотри ERC-20, NFT и, если сервис показывает, Permit2-разрешения.
4. Отсортируй список от новых к старым, если подозрение связано с недавним сайтом.
5. Для каждого разрешения проверь токен, spender, лимит и дату. Неизвестный контракт или unlimited allowance к нему требуют приоритета.
6. Нажми Revoke либо установи лимит в ноль. В кошельке появится транзакция, за неё платится обычная комиссия сети.
7. Дождись подтверждения в блокчейне, обнови страницу и убедись, что лимит стал нулевым или запись исчезла из активных.

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

Не делай revoke наугад по каждому адресу, если не понимаешь последствий для своей позиции. Отзыв разрешения обычно не закрывает позицию в lending или staking, но может помешать последующему выводу, обмену или управлению до нового approval. Официальное руководство Ethereum.org отмечает, что отмена разрешения сама по себе не прекращает позицию, но для будущего взаимодействия с протоколом может понадобиться новый доступ.

Сколько стоит revoke: учебный расчёт

Revoke не бывает бесплатным на EVM-сетях, потому что это транзакция, меняющая запись allowance в контракте токена. Точная цена зависит от сети, загруженности и кошелька, поэтому её нужно смотреть в окне подтверждения, а не брать из статьи.

Вот условный расчёт, не прогноз комиссии. Допустим, кошелёк показывает для отзыва лимита расход 50 000 gas, а цена gas в Ethereum в момент отправки равна 8 gwei.

1. Расход в ETH: 50 000 × 8 gwei.
2. Один gwei равен 0,000000001 ETH.
3. Получаем 0,0004 ETH.
4. Если для примера принять цену ETH $2 500, комиссия составит около $1.

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

Если у тебя на кошельке USDC на $30, а комиссия сети на несколько действий высока, не стоит из этого делать вывод «лучше ничего не делать». Сначала отзови самый опасный свежий unlimited approval, переведи остаток токенов в безопасное место при реальной угрозе и дождись более подходящей комиссии для уборки остальных разрешений. Но не откладывай, если вредный spender уже известен или списания начались.

Что делать сразу после подозрительной подписи?

Если ты подписал непонятное сообщение или подтвердил suspicious approval, действуй быстро и по порядку. Не спорь с мошенником, не возвращайся на его сайт и не устанавливай «программу для отмены транзакции».

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

Порядок для подозрительного approval или permit:

1. Отключи сайт в кошельке и закрой страницу. Это не отменит доступ, но остановит новые запросы.
2. Запиши адрес кошелька, сеть, время, хеш уже подтверждённой транзакции и URL сайта. Скриншоты полезны для обращения в поддержку и анализа.
3. Через проверенный approval checker посмотри новые разрешения в этой сети.
4. Отзови неизвестные и подозрительные approvals. Начинай с токенов с наибольшим балансом и unlimited-лимитов.
5. Если ты только подписал неподтверждённый EIP-2612 permit, срочно проверь параметры подписи и действуй по официальной инструкции конкретного токена. По EIP-2612 такая подпись может быть передана в permit до дедлайна при совпадении nonce; простой ERC-20 revoke сам по себе не меняет nonce EIP-2612.
6. Проверь историю транзакций в блокчейн-эксплорере: не появились ли переводы, approvals, Permit2 или действия с NFT.
7. Если адрес уже выводит активы, переведи оставшиеся активы на новый кошелёк, который не связан со старой seed-фразой. Сделай это до того, как атакующий успеет воспользоваться разрешением.
8. Проверь другие сети с тем же адресом и связанные адреса, если применял тот же seed в нескольких кошельках.
9. Обнови пароли бирж и включи двухфакторную аутентификацию, если ты вводил их на подозрительном сайте.

Ethereum.org в памятке о скамах рекомендует при подозрении на компрометацию перевести остаток средств на новый защищённый кошелёк, отозвать token approvals, сменить связанные пароли и включить 2FA.

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

Почему revoke не всегда спасает?

Revoke останавливает только будущие списания, зависящие от конкретного разрешения. Он не отменяет подтверждённый перевод, не возвращает украденные активы, не делает старую seed-фразу безопасной и не всегда нейтрализует уже подписанный ордер.

Если токены уже ушли, отменить это средствами блокчейна обычно нельзя. Не верь «агентам по возврату крипты», которые требуют предоплату или seed-фразу. Вторичный обман после кражи распространён именно потому, что пострадавший хочет быстро вернуть средства.

Есть и технические ограничения. У одного адреса могут быть разные разрешения для разных токенов и сетей. Отозвав доступ к USDC у одного spender, ты не отменяешь разрешение для WETH, NFT или Permit2. Отзыв обычного ERC-20 approval также не заменяет проверку открытых ордеров на площадках.

В Solana модель другая: там действия обычно связаны с конкретными транзакциями, программами, token accounts и делегатами, а не повторяют буквально ERC-20 allowance. Но принцип тот же: смотри, что именно подписываешь. В официальном описании off-chain message signing Solana указано, что офчейн-сообщения предназначены для подтверждения владения кошельком и отделены от транзакций специальным форматом. Однако сайт всё равно может использовать подпись в собственной логике, поэтому неизвестные запросы не стоит подтверждать автоматически.

Как организовать кошельки, чтобы одна ошибка не стоила всего баланса?

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

Можно использовать простую схему из трёх уровней:

Уровень	Что хранить	Как использовать
Хранилище	Долгосрочный капитал, ценные NFT	Не подключать к новым dApp, минимум операций
Рабочий кошелёк	Средства для знакомых протоколов	Использовать для обменов и проверенных сервисов
Экспериментальный кошелёк	Небольшая сумма для новых dApp	Считать расходным, регулярно чистить approvals

Сумму на экспериментальном кошельке выбирай так, чтобы её потеря не нарушила финансовый план. Похожий подход к ограничению риска описан в статье «Риск-менеджмент в трейдинге простыми словами». Так ты ограничиваешь ущерб, если ошибёшься с сайтом, подписью или контрактом.

Для трейдинга полезно отделять on-chain-эксперименты от средств, используемых на централизованных площадках. Если ты выдаёшь API-ключи биржи, это отдельный контур риска: ключу не нужны разрешения на вывод, если задача ограничивается просмотром баланса или торговлей. Подробный разбор есть в статье «API-ключи биржи: как выдать доступ и не потерять средства».

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

Какие ошибки повторяются чаще всего?

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

Вот ошибки, которые стоит исключить из процесса:

1. Хранить весь баланс на одном адресе и подключать его к каждому новому dApp.
2. Подтверждать unlimited approval, когда доступен точный лимит.
3. Считать, что Connect wallet равен безопасному действию и дальше можно не читать запросы.
4. Считать подпись без gas безвредной.
5. Переходить на DeFi-сайт по рекламе, ссылке из личного сообщения или поисковой выдаче без сверки домена.
6. Игнорировать предупреждение кошелька, потому что сайт обещает награду.
7. Отключать кошелёк от сайта вместо revoke и считать, что доступ закрыт.
8. Вводить seed-фразу в форму «для синхронизации», «валидации» или «восстановления».
9. Устанавливать расширения кошелька по ссылке из чата вместо официального магазина.
10. Платить «возвратчикам средств», которые обещают отменить блокчейн-перевод.

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

Какой чек-лист использовать перед каждой подписью?

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

1. Я открыл сайт из своей закладки, официальной документации или проверенного профиля?
2. Домен совпадает с официальным полностью, включая окончание и отсутствие лишних символов?
3. Мне понятна цель действия без слов «вроде бы» и «наверное»?
4. Я проверил сеть в кошельке?
5. Я вижу, какой токен, NFT или сумму затрагивает запрос?
6. Я знаю адрес spender или оператора и могу сверить его с официальным источником?
7. Это точный лимит, а не unlimited approval?
8. Если это подпись, я понимаю, что это не permit, Permit2, ордер или разрешение на NFT?
9. На этом адресе лежит только та сумма, которой я готов рискнуть для этого действия?
10. Если мне предлагают срочность, могу ли я отложить действие на 15 минут и перепроверить всё заново?

Если хотя бы на один вопрос ответ «нет», нажми Reject. Вернуться к нормальному сервису можно в любой момент. Настоящий протокол не должен требовать отключения критического мышления.

Как действовать дальше без постоянной тревоги?

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

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

Веди короткий журнал: дата, dApp, сеть, токен, выданный лимит и цель. Он помогает через несколько месяцев понять, почему конкретный approval ещё существует. Такой подход хорошо сочетается с привычкой фиксировать решения, о которой мы писали в материале «Дневник криптотрейдера: как вести и какие данные записывать».

Главное правило можно сформулировать так: кошелёк не знает, был ли сайт настоящим. Он знает только, что ты подтвердил запрос. Твоя защита начинается до клика Confirm. Revoke нужен для экстренной остановки уже выданного доступа.

Источники

1. Ethereum.org: How to revoke smart contract access to your crypto funds
2. Ethereum.org: Scam help & reporting
3. OpenZeppelin: ERC-20 documentation
4. Ethereum Improvement Proposal 2612: Permit Extension for EIP-20 Signed Approvals
5. Ledger: How Ledger hardware wallets work
6. Ethereum Improvement Proposal 721: Non-Fungible Token Standard
7. Uniswap: Permit2 overview
8. Revoke.cash: How to revoke token approvals and permissions
9. Solana documentation: Off-chain message signing