Чому фішинг у листах обходить поштові фільтри
Класичний поштовий фільтр перевіряє лист у момент доставки: репутацію домену відправника, посилання, типи вкладень.
Фішинг у листах виграє в цієї схеми тим, що на момент перевірки виглядає чистим — посилання веде на давно відомий сайт, а підміна посилання редиректом спрацьовує вже після переходу, поза вікном перевірки.
З вкладеннями та формами входу логіка та сама. Документ із макросом розкриває навантаження на робочій машині, коли шлюз уже пропустив файл за типом і розширенням.
Фішингові вкладення та форми входу на підробленій сторінці забирають дані на боці користувача — поштова служба про другий сценарій взагалі нічого не знає.
Ціна обходу поштового фільтра — не лише інциденти, що відбулися. Неоднозначні листи йдуть у ручний розбір ІБ, а хибні спрацьовування на легітимних розсилках ламають роботу підрозділів: співробітники перестають довіряти позначкам і переходять за посиланнями без розбору.
Окрема складність у тому, що техніки з MITRE ATT&CK змінюються швидше, ніж оновлюються статичні правила. Закривається це моделлю, яка оцінює лист, перехід за посиланням і вміст сторінки як один ланцюжок, а не як три незалежні перевірки. Розбираємо, як це влаштовано і що дає поштовій службі та ІБ.
Що дає детекція фішингу в поштовому трафіку
Детекція фішингу в поштовому трафіку працює не одним класифікатором, а набором незалежних перевірок.
Посилання з листа розкривається в ізольованому середовищі, домен звіряється з історією відправлень, а розбіжність між видимим текстом посилання та реальною адресою переводить лист у карантин.
Вердикт збирається з кількох сигналів, тому підроблена сторінка входу ловиться й тоді, коли відправник ще не потрапив до жодного списку блокувань.
Звідси два вимірювані ефекти. Зниження частки пропусків відбувається за рахунок класу атак, який правила за ключовими словами не розрізняють: лист без тексту, з однією кнопкою та посиланням на копію корпоративної форми авторизації.
Частка хибних спрацьовувань утримується на рівні, за якого співробітник розбирає одиниці карантинів на тиждень, а не сотні, — інакше захист починають обходити стороною. Розмітка інцидентів ведеться за MITRE ATT&CK, щоб тактики атакуючих описувалися однаково в усіх звітах.
Єдина політика для вкладень знімає розриви між каналами. Один набір правил застосовується до особистих скриньок, загальних адрес, пересилання та мобільних клієнтів: макроси, виконувані файли та архіви з паролем усередині обробляються однаково.
Без цього достатньо надіслати документ на загальну скриньку, у якої правила м'якші, і перевірка втрачає сенс.
Для аналітика це скорочує час реакції на інцидент до хвилин. Розбір спірного листа відбувається за готовою карткою: які ознаки спрацювали, куди ведуть посилання, що вже розкрито в пісочниці, — замість ручного вивантаження заголовків і вкладень.
Додайте до цього кнопку «повідомити про підозрілий лист» для співробітників: частина спрацьовувань надходить від них раніше, ніж від автоматики, і такі звернення одразу потрапляють до загальної черги розбору.
Підходи до детекції фішингу: правила, моделі, гібрид
Жоден спосіб детекції не дає одразу високої повноти та низької частки хибних спрацьовувань: сигнатури ловлять відоме, модель — варіації, поведінковий аналіз — те, що пройшло статичні фільтри.
Вибір визначається потоком листів і ціною помилки: пропущений фішинг і заблокований лист клієнта коштують по-різному.
На практиці підходи не конкурують, а вибудовуються в каскад. Нижче — що закриває кожен варіант, коли його достатньо і де він починає помилятися.
Як вибирати варіант
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Сигнатури та списки блокування | Відомі кампанії та повторювані домени, потрібен миттєвий вердикт | Ловлять лише побачене раніше, списки швидко застарівають |
| Правила за відправником і заголовками | Перевірка справжності домену, розбіжності в ланцюжку доставки, підміна імені | Обходяться коректним налаштуванням у відправника, багато хибних спрацьовувань |
| Модель на ознаках листа й посилання | Нові кампанії без сигнатури: текст, верстка, вік домену, розбіжність адреси та тексту посилання | Потрібна розмітка й перенавчання на дрейф, на виході ймовірність, а не вердикт |
| Поведінковий аналіз переходу за посиланням | Посилання відкрито в ізольованому середовищі: редиректи, форми, запит облікових даних | Дорожче за затримкою, не масштабується на весь потік |
| Гібридна схема зі спірними листами | Великий потік і висока ціна помилки: очевидне вирішує автоматика | Потрібен канал розбору й повернення вердиктів у навчальну вибірку |
Каскад будується від дешевих перевірок до дорогих: спочатку заголовки й репутація відправника, потім модель, потім ізольоване відкриття посилання. Листи, на яких оцінки розходяться, не блокуються мовчки — вони йдуть на розбір, а вердикт повертається в навчальну вибірку.
Етапи впровадження: від аудиту поштового потоку до передачі
Порядок робіт фіксований: кожен крок спирається на артефакт попереднього, і перестановка етапів ламає калібрування.
Пропустіть розмітку інцидентів або перевірку на живому трафіку — система буде впевнено закривати очевидні масові розсилки й мовчати на цільових листах із підробленим доменом відправника.
-
Аудит поштового потоку та джерел листів. Рахуємо обсяг листування, частку зовнішніх відправників, вкладень і посилань, збираємо перелік поштових шлюзів і груп одержувачів. На виході — карта потоку й точки, де контроль ставиться без розриву доставки.
-
Розмітка архіву інцидентів. З карантину й скарг співробітників збираємо корпус: підтверджений фішинг, легітимні розсилки, спірні випадки. Спірні листи — головне джерело хибних блокувань, тому їх розбираємо окремо.
-
Схема точок контролю. Домовляємося, що блокується одразу, що йде в карантин, що лише позначається. Тут же описуємо, як співробітник оспорює вердикт і куди потрапляє його звернення.
-
Налаштування правил і порогів спрацьовування. Балансуємо хибні спрацьовування й пропуски: окремі пороги для фінансів і керівників, окремі — для листів із вкладеннями та зовнішніми посиланнями. Кожному рівню впевненості зіставлено дію.
-
Перевірка на живому трафіку. Система працює в режимі спостереження: листи не блокуються, вердикти пишуться в журнал і порівнюються з рішеннями адміністраторів. Розбіжності розбираємо вручну й правимо правила до стабільного результату.
-
Приймання та передача рішення. Віддаємо регламенти реагування, інструкції для служби підтримки, журнали й метрики контролю, порядок донавчання на нових інцидентах. Розбір інциденту й налаштування правила команда замовника виконує самостійно.
Конфігурації, політики та регламенти розбору інцидентів
Комплект залишається в замовника у вигляді робочих артефактів, а не звіту: правила й пороги лежать у конфігураційному файлі під контролем версій, політики доступу — в поштовій системі, регламенти — в базі знань.
Такий набір дозволяє правити чутливість детекції власними силами, передати супровід іншій команді й пройти внутрішній аудит без пошуку авторів рішення.
- Конфігурації правил і порогів — значення, за яких лист доставляється, позначається або йде в карантин, з поясненням до кожної зміни та порядком відкату до попереднього набору.
- Схема потоку листів — шлях повідомлення від приймання до карантину або доставки, місця спрацьовування перевірок, точки запису в журнал і поведінка контуру за недоступності окремого компонента.
- Політики доступу до карантину — хто зі співробітників і з якою роллю переглядає, випускає та видаляє затримані листи, обмеження на масові операції й обов'язкова фіксація дій.
- Регламент розбору спірних листів — строки реакції, порядок ескалації на другу лінію, правила випуску хибних спрацьовувань і дії при виявленні пропущеної атаки.
- Інструкції для першої лінії — покрокові сценарії на типові звернення співробітників із шаблонами відповідей і зрозумілою межею, за якою підключається інженер.
- Документація з конфігурації та змін — де лежать параметри, хто погоджує правку, журнал із причиною та датою, схема взаємодії з поштовим шлюзом, каталогом користувачів і системою заявок.
- Набір для перевірки якості — розмічена вибірка листів і порядок її прогону після кожної правки, щоб зміна порогу не підняла частку хибних спрацьовувань непомітно.
Кожен пункт перевіряється на прийманні: ми показуємо, як внести зміну, як переконатися в її ефекті та як повернутися назад.
Кейс: як закрили клас пропущених листів у пошті
Поштова служба з десятками тисяч скриньок прийшла з конкретним збоєм: листи з посиланнями на підроблені сторінки входу проходили фільтри й доставлялися.
Підписи відправника, списки блокувань і статичні правила відсікали масові розсилки, але не листи, зібрані під конкретну організацію — з особистим зверненням і адресою, зареєстрованою за пару днів до відправлення.
Заміри до впровадження: частка пропущених листів цієї категорії трималася на 6–8% від усіх виявлених спроб, а служба безпеки розбирала вручну близько сотні інцидентів на тиждень — від розкриття посилання до розмови зі співробітником, який уже ввів облікові дані.
Що побудували
Ядро — конвеєр розбору посилань: адреса витягується з тіла листа та вкладень, розкривається до кінцевого, сторінка відкривається в ізольованому середовищі й порівнюється з еталоном форми входу цільового сервісу.
Паралельно рахуємо ознаки домену: вік реєстрації, зміну провайдера, розбіжності в ланцюжку сертифіката, візуальну схожість із легітимною адресою. Рішення вбудовано в потік доставки через Exchange Online — лист іде в карантин до того, як його побачить співробітник.
Заміри після
Через три місяці спостережень частка пропущених листів категорії впала до 0,3–0,5%, а потік ручних розборів скоротився приблизно в п'ять разів.
Частку хибних спрацьовувань тримаємо нижче 0,1%: кожне правило проганяється на історичному корпусі листів і вмикається спочатку в режимі спостереження.
Метрики рахували однаково до і після — за однією ручною розміткою аналітиків, де частка пропущених вважається як листи, що пройшли, до суми тих, що пройшли, і заблокованих.
Чим відрізняється детекція фішингу від антиспаму?
Антиспам відповідає на питання «чи це масова розсилка», детекція фішингу — на питання «чи шкідливо це конкретному адресату зараз». Перший оцінює відправника, обсяг і однотипність листів, другий — вміст посилання й контекст одержувача. Звідси різні набори ознак і різні пороги спрацьовування.
Фільтрація за репутацією відправника працює, поки адреса або домен уже себе проявив.
Вік реєстрації, історія скарг, обсяг відправлення й справжність домену дають сильний сигнал на масових хвилях — і майже нульовий на листі зі зламаної скриньки підрядника, надісланому в одному екземплярі.
Аналіз вмісту посилання спирається на її поведінку, а не на текст листа.
Розкриваємо ланцюжок перенаправлень, звіряємо видиму адресу з фактичною, дивимося сторінку переходу: форму введення даних, копію сторінки входу, свіжий домен без історії, підстановку адреси одержувача в параметри.
Оцінка контексту адресата закриває те, чого не видно в самому посиланні: хто відправник по відношенню до одержувача, чи було листування раніше, чи типова просьба.
Зміна реквізитів, доступ до документа, терміновість від знайомого імені — лист без технічних аномалій, який репутаційний фільтр пропустить, а модель контексту позначить.
Тому шари не замінюють один одного: репутація відсікає шум до глибокого аналізу, а модель посилання й адресата добирає поодинокі цільові листи. Підсумкова оцінка — ризик для конкретної людини, а не «спам чи не спам».
Часті технічні сумніви перед впровадженням
Перед впровадженням замовники ставлять один і той самий набір питань: наскільки чутливі пороги детекції, що буде при піковій розсилці й чи не доведеться ламати вже працюючий поштовий шлюз. Усі вони про одне — як система поводиться на вашому трафіку, а не на демонстраційному наборі.
Як налаштовується точність і що з хибними спрацьовуваннями на розсилках?
Поріг спрацьовування — параметр, а не константа. На старті проганяємо вашу історію листування й підбираємо межу так, щоб частка хибних спрацьовувань на легітимних розсилках укладалася в задану вами межу.
Сервісні повідомлення, рахунки та дайджести вносимо в білий список за відправником і доменом — навіть при схожій структурі листа модель їх не блокує, а спірні позначає й відправляє в карантин, а не видаляє.
Що відбувається при піковій розсилці — чи витримає шлюз?
Перевірка йде окремим потоком, а не на шляху доставки: шлюз не чекає вердикту моделі, щоб віддати лист одержувачу. При піку черга розтягується й розбір іде із затримкою, але вхідний трафік має пріоритет, а відкладені листи не губляться. Синхронну перевірку ми свідомо не ставимо — саме вона кладе шлюз на масових розсилках.
У нас уже налаштований шлюз з антиспамом і правилами. Що з ним буде?
Наявні правила, білі списки та маршрути залишаються на місці. Модуль підключається як додатковий шар і вміє працювати в двох режимах: розмітка листів без блокування, коли рішення приймає ваша поточна логіка, або карантин для того, що вище порогу. При вимкненні конфігурація повертається до початкового стану.
Хто оновлює правила й розбирає спірні листи?
Оновлення правил беремо на себе: нові шаблони фішингу та зміни в поведінці відправників потрапляють у модель регулярно, без вашої участі.
Спірні листи розбирає виділений аналітик — кожен отримує вердикт і коротке пояснення, за яким ваша служба підтримки може відповісти користувачеві. Прикордонні випадки розбираємо разом із вашим адміністратором.
Обговоримо задачу: що підготувати до розмови
Розмова про детекцію фішингу найшвидше виходить на предмет, якщо в нас перед очима є живий трафік замовника, а не опис «у загальних рисах». Готувати технічне завдання не потрібно — достатньо того, що вже лежить у поштовій інфраструктурі та журналах.
Нижче список, який економить нам перше коло уточнень і одразу переводить обговорення задачі в інженерну площину.
- Приклади листів: 20-50 реальних повідомлень у вихідному вигляді — і пропущених, і затриманих фільтром. Важливі обидва класи, інакше не налаштувати поріг спрацьовування.
- Повні заголовки та джерельні файли, а не скриншоти: видно, чи підроблено домен відправника, як розходиться шлях доставки, чи є підміна посилання в тілі.
- Поточна схема потоку: на якому вузлі лист зупиняється — на шлюзі, в поштовому сервері чи в зовнішнього провайдера — і куди йде вердикт.
- Статистика пошти за місяць-два: обсяг вхідних, частка відсіченого, частка хибних спрацьовувань і скарг на затримки.
- Перелік минулих інцидентів: скільки листів дійшло, хто відкрив посилання, чим закінчилося, що вже змінили після розбору.
- Вимоги до карантину: хто розбирає чергу, за який час, що допустимо утримувати, а які повідомлення затримувати не можна.
- Обмеження середовища: де дозволено обробляти дані, які канали не можна випускати назовні, хто на боці замовника приймає спірне рішення.
Опишіть задачу у вільній формі та додайте те, що є — повернемося з оцінкою та планом впровадження: етапи, склад робіт, що змінюється в поточному потоці пошти й за якими метриками рахуємо результат.
