К основному содержанию
T TON Adoption
← Словарь
NODE/03 · Term

Утечка сид-фразы

Ситуация, когда seed-фраза кошелька становится известна третьему лицу — добровольно (фейковый сайт, social engineering) или через malware/облачную синхронизацию. Приводит к компрометации всех адресов, выведенных из этой фразы.

Синонимы: seed leak, кража сида, утечка ключей, mnemonic compromise

Утечка сид-фразы — самый разрушительный тип компрометации в самокастодиальном кошельке. Знание 24 слов даёт полное и неотменяемое право подписи от имени всех адресов, производных из этой фразы, во всех версиях wallet-контрактов. Это не «рискованная ситуация» — это уже состоявшаяся потеря, в которой счёт идёт на минуты до того, как drainer выгребет содержимое.

Типичные сценарии

  • Фейковый «recover wallet». Жертве приходит сообщение в Telegram о «проблеме с кошельком» со ссылкой на сайт, который требует ввести seed «для восстановления». Это самый массовый вектор. Реальные кошельки никогда не запрашивают seed онлайн.
  • Скриншот в облаке. Пользователь сделал фото листа с фразой, оно автоматически синхронизировалось в iCloud / Google Photos / Яндекс Диск. Дальше любой компромат облачного аккаунта или его частичный шеринг — путь к сиду.
  • Текстовый файл и буфер обмена. Сид сохранён в .txt на рабочем столе, отправлен самому себе в Telegram «Saved Messages» или просто скопирован — и попал в clipboard-шпион malware.
  • Кейлоггер. Заражённая клавиатура или браузерное расширение перехватывает ввод, когда жертва вводит сид в кошелёк после переустановки.
  • Social engineering. Фейковый «саппорт» Tonkeeper в Telegram просит «проверить sequence слов» — и пользователь надиктовывает их. Сюда же — фейковые опросы и AMA.
  • Бумажный бэкап в чужой видимости. Гость дома, родственник, ремонт квартиры — реальные кейсы, особенно при крупных балансах.
  • Облачные парольные менеджеры без шифрования сторонами. При плохо настроенной мастер-парольной защите менеджер становится единой точкой отказа.

Что происходит после утечки

Окно реакции — минуты, в крупных кейсах — секунды:

  1. Атакующий сразу деривирует адреса всех версий wallet-контрактов (v3R2, v4R2, v5R1, highload-варианты) и проверяет балансы.
  2. Если на адресах есть TON, jetton-ы, NFT — drainer запускает batch-перевод всего на свой адрес.
  3. NFT обычно уходят на отдельный адрес, чтобы быстро перепродать на популярных маркетплейсах.
  4. Стейкинг-позиции (stTON, tsTON, hTON) уводят как обычные jetton-ы — пул не различает легитимного владельца и атакующего.

Отзыв сид-фразы невозможен. На блокчейне нет «сменить пароль». Любая транзакция, подписанная утечкой, валидна.

Что делать сразу при подозрении на утечку

Если сид мог попасть в чужие руки, но средства ещё на месте:

  1. Немедленно создать новый кошелёк на чистом устройстве, желательно с другой машины и нового сида.
  2. Перевести все ликвидные активы туда: TON, jetton-ы, LST, USDT.
  3. NFT и стейкинг-позиции переводить во вторую очередь — они уходят медленнее, но обычно это часть приоритета.
  4. Не пытаться «перетерпеть», надеясь что атакующий не нашёл ваш сид. Если сид ушёл, переход — единственный надёжный шаг.

Иногда бывает успех: drainer не настроен на TON или адрес не сразу попал в его пул. Но рассчитывать на это нельзя.

Профилактика

  • Hardware-кошелёк. Seed физически не покидает устройство; даже если хост заражён, подпись требует подтверждения на экране Ledger.
  • Multisig. Утечка одного из ключей не даёт перевода без подписей остальных. Подходит для крупных балансов и DAO-казн.
  • Раздельный hot/cold-сетап. Малый дневной баланс на горячем кошельке, основной запас — на cold/hardware.
  • Никаких онлайн-копий сида. Только бумажный или металлический бэкап, без съёмки и без облачной синхронизации.
  • Проверка домена при подключении. Реальная защита TON Connect — пользователь видит домен, но это работает только если пользователь читает то, что подписывает.
  • Отдельный кошелёк для рискованных подписаний. Mini-apps, эирдропы, новые контракты — лучше пускать через адрес с минимальным балансом.

Утечка сида редко происходит как одно событие — это обычно цепочка маленьких компромиссов: облако + старый бэкап + одна неосторожная подпись на скам-сайте. Сильная гигиена ключей не убирает риск полностью, но переводит его из «вопрос времени» в реальную аномалию.

См. также