Разработка AI-системы детекции фишинга email URL сообщения

Почему фишинг в письмах обходит почтовые фильтры

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

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

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

Отдельная сложность в том, что техники из MITRE ATT&CK меняются быстрее, чем обновляются статические правила. Закрывается это моделью, которая оценивает письмо, переход по ссылке и содержимое страницы как одну цепочку, а не как три независимые проверки. Разбираем, как это устроено и что даёт почтовой службе и ИБ.

Что даёт детекция фишинга в почтовом трафике

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

Отсюда два измеримых эффекта. Снижение доли пропусков идёт за счёт класса атак, который правила по ключевым словам не различают: письмо без текста, с одной кнопкой и ссылкой на копию корпоративной формы авторизации. Доля ложных срабатываний удерживается на уровне, при котором сотрудник разбирает единицы карантинов в неделю, а не сотни, — иначе защиту начинают обходить стороной. Разметка инцидентов ведётся по MITRE ATT&CK, чтобы тактики атакующих описывались одинаково во всех отчётах.

Единая политика для вложений снимает разрывы между каналами. Один набор правил применяется к личным ящикам, общим адресам, пересылке и мобильным клиентам: макросы, исполняемые файлы и архивы с паролем внутри обрабатываются одинаково. Без этого достаточно отправить документ на общий ящик, у которого правила мягче, и проверка теряет смысл.

Для аналитика это сокращает время реакции на инцидент до минут. Разбор спорного письма идёт по готовой карточке: какие признаки сработали, куда ведут ссылки, что уже раскрыто в песочнице, — вместо ручной выгрузки заголовков и заголовков вложений. Добавьте к этому кнопку «сообщить о подозрительном письме» для сотрудников: часть срабатываний приходит от них раньше, чем от автоматики, и такие обращения сразу попадают в общую очередь разбора.

Подходы к детекции фишинга: правила, модели, гибрид

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

На практике подходы не конкурируют, а выстраиваются в каскад. Ниже — что закрывает каждый вариант, когда его достаточно и где он начинает ошибаться.

Как выбирать вариант

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

Этапы внедрения: от аудита почтового потока до передачи

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

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

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

3. Схема точек контроля. Договариваемся, что блокируется сразу, что уходит в карантин, что только помечается. Здесь же описываем, как сотрудник оспаривает вердикт и куда попадает его обращение.

4. Настройка правил и порогов срабатывания. Балансируем ложные срабатывания и пропуски: отдельные пороги для финансов и руководителей, отдельные — для писем с вложениями и внешними ссылками. Каждому уровню уверенности сопоставлено действие.

5. Проверка на живом трафике. Система работает в режиме наблюдения: письма не блокируются, вердикты пишутся в журнал и сравниваются с решениями администраторов. Расхождения разбираем вручную и правим правила до стабильного результата.

6. Приёмка и передача решения. Отдаём регламенты реагирования, инструкции для службы поддержки, журналы и метрики контроля, порядок дообучения на новых инцидентах. Разбор инцидента и настройку правила команда заказчика выполняет самостоятельно.

Конфигурации, политики и регламенты разбора инцидентов

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

• Конфигурации правил и порогов — значения, при которых письмо доставляется, помечается или уходит в карантин, с пояснением к каждому изменению и порядком отката к предыдущему набору.
• Схема потока писем — путь сообщения от приёма до карантина или доставки, места срабатывания проверок, точки записи в журнал и поведение контура при недоступности отдельного компонента.
• Политики доступа к карантину — кто из сотрудников и с какой ролью просматривает, выпускает и удаляет задержанные письма, ограничения на массовые операции и обязательная фиксация действий.
• Регламент разбора спорных писем — сроки реакции, порядок эскалации на вторую линию, правила выпуска ложных срабатываний и действия при обнаружении пропущенной атаки.
• Инструкции для первой линии — пошаговые сценарии на типовые обращения сотрудников с шаблонами ответов и понятной границей, за которой подключается инженер.
• Документация по конфигурации и изменениям — где лежат параметры, кто согласует правку, журнал с причиной и датой, схема взаимодействия с почтовым шлюзом, каталогом пользователей и системой заявок.
• Набор для проверки качества — размеченная выборка писем и порядок её прогона после каждой правки, чтобы изменение порога не подняло долю ложных срабатываний незаметно.

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

Кейс: как закрыли класс пропущенных писем в почте

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

Замеры до внедрения: доля пропущенных писем этой категории держалась на 6–8% от всех выявленных попыток, а служба безопасности разбирала вручную около сотни инцидентов в неделю — от раскрытия ссылки до разговора с сотрудником, который уже ввёл учётные данные.

Что построили

Ядро — конвейер разбора ссылок: адрес извлекается из тела письма и вложений, раскрывается до конечного, страница открывается в изолированной среде и сравнивается с эталоном формы входа целевого сервиса. Параллельно считаем признаки домена: возраст регистрации, смену провайдера, расхождения в цепочке сертификата, визуальную схожесть с легитимным адресом. Решение встроено в поток доставки через Exchange Online — письмо уходит в карантин до того, как его увидит сотрудник.

Замеры после

Через три месяца наблюдений доля пропущенных писем категории упала до 0,3–0,5%, а поток ручных разборов сократился примерно в пять раз. Долю ложных срабатываний держим ниже 0,1%: каждое правило прогоняется на историческом корпусе писем и включается сначала в режиме наблюдения. Метрики считали одинаково до и после — по одной ручной разметке аналитиков, где доля пропущенных считается как прошедшие письма к сумме прошедших и заблокированных.

Чем отличается детекция фишинга от антиспама?

Антиспам отвечает на вопрос «массовая ли это рассылка», детекция фишинга — на вопрос «вредно ли это конкретному адресату сейчас». Первый оценивает отправителя, объём и однотипность писем, второй — содержимое ссылки и контекст получателя. Отсюда разные наборы признаков и разные пороги срабатывания.

Фильтрация по репутации отправителя работает, пока адрес или домен уже себя проявил. Возраст регистрации, история жалоб, объём отправки и подлинность домена дают сильный сигнал на массовых волнах — и почти нулевой на письме с взломанного ящика подрядчика, отправленном в одном экземпляре.

Анализ содержимого ссылки опирается на её поведение, а не на текст письма. Раскрываем цепочку перенаправлений, сверяем видимый адрес с фактическим, смотрим страницу перехода: форму ввода данных, копию страницы входа, свежий домен без истории, подстановку адреса получателя в параметры.

Оценка контекста адресата закрывает то, чего не видно в самой ссылке: кто отправитель по отношению к получателю, была ли переписка раньше, типична ли просьба. Смена реквизитов, доступ к документу, срочность от знакомого имени — письмо без технических аномалий, которое репутационный фильтр пропустит, а модель контекста пометит.

Поэтому слои не заменяют друг друга: репутация отсекает шум до глубокого анализа, а модель ссылки и адресата добирает единичные целевые письма. Итоговая оценка — риск для конкретного человека, а не «спам или не спам».

Частые технические сомнения перед внедрением

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

Что происходит при пиковой рассылке — выдержит ли шлюз?

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

У нас уже настроен шлюз с антиспамом и правилами. Что с ним будет?

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

Кто обновляет правила и разбирает спорные письма?

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

Обсудим задачу: что подготовить к разговору

Разговор о детекции фишинга быстрее всего выходит на предмет, если у нас перед глазами есть живой трафик заказчика, а не описание «в общих чертах». Готовить техническое задание не нужно — достаточно того, что уже лежит в почтовой инфраструктуре и журналах. Ниже список, который экономит нам первый круг уточнений и сразу переводит обсуждение задачи в инженерную плоскость.

• Примеры писем: 20-50 реальных сообщений в исходном виде — и пропущенных, и задержанных фильтром. Важны оба класса, иначе не настроить порог срабатывания.
• Полные заголовки и исходники, а не скриншоты: видно, подделан ли домен отправителя, как расходится путь доставки, есть ли подмена ссылки в теле.
• Текущая схема потока: на каком узле письмо останавливается — на шлюзе, в почтовом сервере или у внешнего провайдера — и куда уходит вердикт.
• Статистика почты за месяц-два: объём входящих, доля отсечённого, доля ложных срабатываний и жалоб на задержки.
• Перечень прошлых инцидентов: сколько писем дошло, кто открыл ссылку, чем закончилось, что уже поменяли после разбора.
• Требования к карантину: кто разбирает очередь, за какое время, что допустимо удерживать, а какие уведомления задерживать нельзя.
• Ограничения среды: где разрешено обрабатывать данные, какие каналы нельзя выпускать наружу, кто на стороне заказчика принимает спорное решение.

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