Взлом email-провайдера Trezor: риски фишинга от доверенных ESP
10 сентября производитель аппаратных кошельков Trezor раскрыл компрометацию стороннего провайдера email-рассылок.

Trezor Warns of Phishing Emails After Third-Party Email Provider Breach
По данным BleepingComputer, атакующие получили возможность отправлять фишинговые письма от имени компании с темой «Critical Security Alert: STM32 Entropy Vulnerability». Для администраторов почтовой инфраструктуры это прямой сигнал: скомпрометирован не аккаунт и не хост, а канал доставки — ESP, через который идёт транзакционная и маркетинговая почта.
Механика инцидента
Trezor указал в официальном канале: «a third-party email provider was compromised». Содержание письма имитирует уведомление о критической уязвимости прошивки STM32 и побуждает получателя перейти по ссылке. Использованный домен заблокирован, расследование продолжается.
Ключевое: письмо уходит с авторизованного ESP, проходит SPF и, вероятно, DKIM, но Trezor его не отправлял. Это не подделка envelope-from — это злоупотребление легитимной учётной записью. Компания не раскрыла число получателей и состав утечки.
Масштаб и связанные инциденты
Это второй инцидент с Trezor за несколько недель. В августе компрометация логистического партнёра ShipMonk затронула, по уточнённым данным, порядка 80 000 клиентов: имена, email, телефоны, адреса доставки. Утёкшие базы уже используются в таргетированном фишинге.
BitBox сообщил 10 сентября, что его провайдер рассылок, по предварительным данным, также скомпрометирован. Ранее SafePal раскрыл несанкционированный доступ к данным заказов около 40 000 клиентов. Несколько компаний из Bitcoin-инфраструктуры, по всей видимости, обслуживаются у одного ESP. Точечная атака на одного провайдера превращается в мультибрендовую рассылку.
Что проверить на инфраструктуре
Проверьте SPF домена отправителя: в механизме include — только авторизованные ESP. Запросите у провайдера журнал отправленных кампаний за последние 72 часа, сверьте с логом собственного MTA. PTR-записи и IP-репутация отправителя проверяются через postmaster-инструменты Gmail и Microsoft.
Усильте DMARC-политику: переведите с p=none на p=quarantine или p=reject, если домен не используется для неконтролируемых сторонних рассылок. Заголовок «Critical Security Alert: STM32 Entropy Vulnerability» добавьте в правила фильтрации как индикатор компрометации. Блокируйте переходы по внешним ссылкам в письмах с темами «security alert», «account suspended», «unauthorized login» на уровне MTA — до клиента.
Не вводите seed-фразу на веб-страницах, открытых из писем. Это правило не зависит от бренда кошелька. Проверяйте любые уведомления через независимый канал: прямой ввод адреса сайта, а не переход по ссылке из тела письма.
Канал доставки почты — часть периметра безопасности. Его компрометация выходит за рамки одного бренда и снижает ценность любой криптографической защиты, если пользователь привык доверять заголовку письма. Подготовка к распознаванию подобных сценариев теперь включается даже в школьные программы — как меняются школьные учебники и цифровые инструменты, вопрос цифровой гигиены закрепляется на уровне обязательных модулей. Технической защиты на стороне сервера недостаточно — требуется базовая тренировка получателя.