mail-nation

Управляем почтой: от домена до конверсий

Новость

Взлом email-провайдера Trezor: риски фишинга от доверенных ESP

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

Взлом email-провайдера Trezor: риски фишинга от доверенных ESP

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-фразу на веб-страницах, открытых из писем. Это правило не зависит от бренда кошелька. Проверяйте любые уведомления через независимый канал: прямой ввод адреса сайта, а не переход по ссылке из тела письма.

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