Фишинг через трекинговую ссылку: почему письмо прошло почтовый шлюз

Интересный случай из практики: получили фишинговое письмо, которое прошло почтовые фильтры, но было остановлено уже на рабочей станции антивирусом.

Кейс полезный, потому что письмо не выглядело как классический вредонос: не было вложения, не было архива, не было EXE/BAT-файла в письме. Только HTML-уведомление под документ и кнопка для просмотра.

Почему письмо прошло фильтры

Причина не в одном конкретном пропуске, а в комбинации факторов.

Письмо пришло через легитимную инфраструктуру массовой отправки - Amazon SES. Сам по себе Amazon SES не является вредоносным источником, через него ходит много нормальной почты, поэтому блокировать его целиком нельзя.

Вредоносного вложения в письме не было. Почтовый шлюз видел обычное HTML-письмо со ссылкой. BAT-файл скачивался уже после перехода пользователя по ссылке, то есть на этапе SMTP-доставки самого файла в письме не существовало.

Ссылка в письме вела не напрямую на вредоносный файл, а на трекинговый домен. Для модуля проверки ссылок это могло выглядеть как обычная tracking-ссылка, характерная для легитимных рассылок и сервисных уведомлений.

Контент письма тоже был в пределах обычной офисной переписки: document, agreement, notice, review, open online. Такие слова нельзя блокировать сами по себе, иначе будет много ложных срабатываний.

В итоге письмо не задело явные триггеры:

- отправка через легитимный почтовый сервис;
- нет вложения;
- нет прямой ссылки на .bat/.cmd/.exe;
- ссылка сначала ведет на трекинговый домен;
- текст похож на обычное уведомление о документе;
- нет грубых спам-фраз или очевидного вредоноса в теле письма.

Что было в письме

Письмо имитировало уведомление от Adobe / AcrobatOnline. В теме использовался деловой контекст, связанный с agreement / notice. В теле была HTML-кнопка Review Document.

На первый взгляд - обычное уведомление о документе.

После просмотра исходника стало видно, что кнопка ведет на длинную ссылку через трекинговый домен. Внутри этой ссылки был спрятан конечный внешний адрес, закодированный через несколько уровней URL-encoding.

Упрощенная схема:

письмо
  -> кнопка Review Document
  -> tracking URL
  -> цепочка редиректов
  -> внешний сайт
  -> загрузка BAT-файла

Финальная нагрузка не была вложением. Она появлялась только после клика.

Что произошло на рабочей станции

При переходе по ссылке скачивался BAT-файл. На рабочей станции сработал антивирус и заблокировал угрозу с детектом:

Trojan.BAT.Alien.gen

То есть почтовый шлюз не увидел вредоносный файл на этапе доставки, но endpoint-защита остановила его уже на этапе загрузки/активации.

Это хороший пример того, зачем нужна многоуровневая защита: почтовый шлюз, проверка ссылок, web/DNS-фильтрация и антивирус/EDR на рабочей станции должны дополнять друг друга.

Что проверяли при разборе

В ходе расследования проверили:

- заголовки письма;
- From / Return-Path;
- маршрут доставки;
- результаты SPF/DKIM/DMARC;
- наличие вложений;
- HTML-тело письма;
- href у кнопки Review Document;
- цепочку URL-кодирования;
- конечный внешний домен;
- результат перехода по ссылке;
- реакцию антивируса на скачанный файл.

Ключевой вывод: основной риск был не в заголовках и не во вложениях, а в ссылке.

Почему нельзя просто заблокировать один признак

После такого инцидента есть соблазн заблокировать конкретный домен, слово Adobe, Amazon SES или все tracking-ссылки. Это плохой вариант.

Злоумышленник легко поменяет бренд, тему, домен и трекинговый сервис. А блокировка легитимных сервисов приведет к ложным срабатываниям.

Блокировать по отдельности нельзя:

- все письма со словом document;
- все письма со словом agreement;
- все письма с Adobe в тексте;
- весь Amazon SES;
- все tracking-ссылки;
- все HTML-письма с кнопками.

Нужна не блокировка одного слова, а анализ сочетаний.

Что добавили в защиту

Для текущей кампании были выделены IOC: домен конечной загрузки, характерные элементы URL, отправитель, тема и фразы из письма.

Но IOC - это временная мера. Более полезны поведенческие признаки:

- глубоко закодированная ссылка;
- скрытый внешний домен внутри href;
- несколько уровней редиректов;
- документная приманка;
- заявленный бренд не совпадает с конечным доменом;
- отсутствие вложения при обещании открыть документ;
- попытка загрузки исполняемого или скриптового файла после клика.

Для почтового шлюза логика должна быть составной, например:

документная приманка
+
HTML-кнопка
+
глубокое URL-кодирование
+
скрытый внешний домен внутри ссылки
=
карантин / backup / дополнительная проверка

Для рабочих станций отдельно важен контроль запуска файлов из пользовательских каталогов:

Downloads
Desktop
Temp
AppData

И особенно файлов типов:

.bat
.cmd
.ps1
.vbs
.js
.jse
.wsf
.hta
.scr
.lnk

Для обычного офисного пользователя запуск таких файлов из загрузок почти никогда не является нормальным сценарием.

Итог

Письмо прошло фильтры не потому, что было безопасным, а потому что было собрано на границе легитимной офисной переписки и вредоносной активности.

В нем не было вложения. Отправка шла через легитимную инфраструктуру. Ссылка сначала выглядела как tracking URL. Контент был похож на обычное уведомление о документе. Вредоносный BAT-файл появился только после перехода по ссылке.

В данном случае атаку остановил антивирус на рабочей станции. После разбора были добавлены IOC для текущей кампании и подготовлены более аккуратные правила по поведенческим признакам: глубокое кодирование ссылок, скрытые домены внутри href и подозрительная цепочка редиректов к загрузке файла.

Практический вывод простой: отсутствие вложения не делает письмо безопасным. Для современных фишинговых писем все чаще характерна схема:

письмо -> ссылка -> редиректы -> загрузка -> запуск на ПК

И защищаться от нее нужно не одним фильтром, а несколькими уровнями контроля.