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

Письмо ушло через легитимный канал отправки производителя, корректно прошло проверки SPF, DKIM и DMARC — и оказалось фишингом. Trezor вечером того же дня подтвердила в X, что уведомление отправлено не ею. Инцидент обнажает предел доверия к техническим заголовкам From: совпадение домена больше не гарантирует легитимности.

Маршрут и содержание

По данным The Block, рассылка шла через реальный отправляющий домен Trezor. Целью атаки стал внешний email-провайдер, через которого производитель ведёт транзакционные и сервисные коммуникации. Имя провайдера публично не озвучено. Лендинг атакующих оперативно отозван, Trezor запустила внутреннее расследование. По заверению компании, сами устройства кошелька не пострадали.

Cryptopolitan цитирует получателя, у которого данное письмо прошло все три проверки — SPF, DKIM и DMARC. Содержание письма, по описанию Decrypt: критическая уязвимость микроконтроллеров семейства STM32, затрагивающая примерно каждый четвёртый экземпляр и снижающая энтропию сид-фразы. Утверждение проверяемо ложно, но правдоподобно: реальные сбои энтропии в истории криптовалют уже фиксировались. Атака бьёт по самой болезненной точке самостоятельного хранения — заставляет владельца действовать немедленно, до проверки канала.

Чек-лист получателя — четыре минуты

1. Время отправки. Сверяйте с часовым поясом и графиком прошлых рассылок Trezor. Сообщение в нерабочие часы производителя — стоп-фактор.

2. URL в теле письма. Копируйте, не переходите. Сравнивайте домен с теми, что Trezor использовала раньше. Любой новый поддомен — отказ от действий.

3. dig TXT _dmarc.<отправитель-домен>. Сверяйте политику DMARC. Отсутствие жёсткой директивы (p=reject или p=quarantine) — повод удвоить контроль.

4. dig TXT <селектор>._domainkey.<отправитель-домен>. Сопоставьте DKIM-селектор из заголовка письма с опубликованным в DNS. Несовпадение — признак маршрутизации не через заявленный путь.

При любом сомнении — отказ от действий по письму. Входите в аккаунт Trezor через закладку браузера или ручной ввод адреса.

Расширение зоны риска

Whalesbook сообщает о параллельном инциденте: компрометации рассылки Revolut через спуфинг на уровне email-провайдера. Фишинг через легитимные каналы уже вышел за пределы криптосегмента. Тот же протокол верификации применим к уведомлениям банков, медицинских сервисов и облачных провайдеров — при любых входящих с темой security или wellness, связанных с персональными данными пациента и состоянием здоровья клиники, действуйте по схеме «прямой вход через закладку, проверка домена, отказ от клика по ссылке». После инцидента Trezor любая компания, отправляющая клиентские письма через стороннего ESP, обязана провести аудит точек компрометации, проверить связку DKIM↔ESP и ротировать ключи там, где маршрут выходит за пределы прямого контроля.