Понад протоколи електронної пошти: чому SPF, DKIM і DMARC не захищають від дипфейків

By Mirko Peters · 2026-08-26

Коли йдеться про захист корпоративних поштових скриньок, організації довгий час покладалися на стандартні протоколи автентифікації електронної пошти як на свій основний щит. Якщо ви хоч трохи працювали в ІТ-безпеці, вам відома «священна трійця» захисту пошти: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) і Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Automatically translated with AI from the original post. Read the English original

Коли йдеться про захист корпоративних поштових скриньок, організації довгий час покладалися на стандартні протоколи автентифікації електронної пошти як на свій основний щит. Якщо ви хоч трохи працювали в ІТ-безпеці, вам відома «священна трійця» захисту пошти: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) і Domain-based Message Authentication, Reporting, and Conformance (DMARC). Протягом багатьох років правильне налаштування цих записів дозволяло ефективно блокувати підміну домену, стримувати фішингові листи та переконатися, що повідомлення, які нібито надійшли від вашої організації, справді походять з авторизованої інфраструктури. Але ландшафт кібербезпеки суттєво змінився, і інструменти, на які ми покладалися десятиліттями, опинилися перед безprecedentним сліпим оглядом.

Настала ера штучного інтелекту та синтетичних медіа. Кіберзлочинці вже не обмежуються грубими текстовими фішинговими листами з друкарськими помилками. Натомість вони використовують просунутий генеративний ШІ, щоб проводити складні атаки компрометації ділової електронної пошти (BEC), посилені дипфейками. Ці загрози легко обходять технічні перевірки традиційних протоколів, адже справа вже не лише в тому, хто надіслав лист, — річ у прихованому зловмисному наміrі в змісті, який технічні протоколи просто не здатні прочитати. У цій публікації ми розглянемо, чому ваш поточний стек захисту пошти не справляється з дипфейк-загрозами та що має зробити організація, щоб побудувати справді стійку оборону.

Вступ до безпеки електронної пошти та загроз дипфейків

Щоб зрозуміти всю складність завдання, спершу треба з'ясувати, як зловмисники адаптувалися. Традиційні протоколи безпеки пошти створювалися для простішого інтернету. Їхнє призначення — не дати зловмисникам перехопити ваше доменне ім'я або вставити підроблені заголовки в повідомлення. За правильного впровадження DMARC, SPF і DKIM утворюють надійний контур перевірки, який повідомляє серверам-отримувачам, чи має лист авторизацію та чи зберіг він цілісність. Проте ці протоколи — це перевіряльники інфраструктури, а не арбітри змісту. Вони не читають текст, не слухають прикріплене аудіо й не оцінюють, чи справді людина, яка просить переказ коштів, є тією, за кого себе видає.

Оскільки інструменти штучного інтелекту стали загальнодоступними, поріг входу для створення фотореалістичних синтетичних медіа різко знизився. Зловмисники тепер можуть зібрати публічно доступні відеокліпи, записи конференцій і голосові повідомлення корпоративних керівників, щоб клонувати їхні голоси та зовнішність із приголомшливою точністю. Статистика свідчить про стрімке зростання таких методів. У 2023 році менше 5 відсотків атак компрометації ділової електронної пошти включали технології дипфейків. До 2026 року цей показник зріс до 40 відсотків. Крім того, ФБР повідомило про зростання атак BEC з використанням дипфейків на 25 відсотків рік до року, а загальна кількість інцидентів із дипфейками щорічно зростає більш як на 300 відсотків. Коли зловмисник поєднує бездоганно автентифікований лист із клонованим голосом або дипфейком відео в реальному часі, ваші звичайні фільтри пошти фактично стають практично марними.

Пояснення атак BEC з дипфейками

Що таке BEC із дипфейками

Ви, імовірно, знайомі з традиційною компрометацією ділової електронної пошти, коли шахрай видає себе за постачальника або керівника вищої ланки та просить терміново переказати кошти чи надати конфіденційні дані. BEC із дипфейками бере цей зловмисний сценарій і посилює його штучним інтелектом. Замість того щоб обмежуватися текстовим повідомленням або листом, зловмисники вплітають у ланцюг атаки синтетичне аудіо, відео чи розмовні елементи. Вони можуть відтворити точний ритм мовлення, акцент і мовні особливості вашого генерального директора чи фінансового директора. Ці атаки не намагаються обдурити вас адресою електронної пошти з помилками; натомість вони експлуатують вашу довіру, переконуючи, що ви спілкуєтеся безпосередньо з відомою авторитетною особою голосом або по відео.

Чим BEC із дипфейками відрізняється від традиційних загроз

Ключова відмінність між класичним BEC і сучасним deepfake BEC полягає в засобі обману. Традиційні загрози повністю спираються на маніпуляції з текстом. Якщо ви отримуєте електронний лист від свого керівника з проханням купити подарункові картки або перевести кошти, внутрішній сигнал тривоги може спрацювати, якщо тон здається трохи дивним. Deepfake BEC руйнує такі традиційні механізми виявлення, додаючи реалістичне аудіо або відео. Ви можете отримати телефонний дзвінок, який звучить так само, як ваш менеджер, або приєднатися до швидкої відеонаради, де синтетичний аватар киває в такт і говорить голосом вашого директора. Такий багатоканальний підхід використовує природну схильність людини довіряти та поспішати способами, які текстові фільтри не здатні виявити.

Технологія deepfake змінила загрози BEC, дозволивши зловмисникам переконливіше видавати себе за посадових осіб. Це полегшує їм маніпулювання вами та обхід традиційних фільтрів безпеки.

Ось таблиця з основними відмінностями:

Атаки deepfake BEC можуть маніпулювати вами ефективніше завдяки реалістичному голосу чи відео. Вони використовують терміновість і авторитет, що робить їх небезпечнішими за традиційний фішинг. Внутрішні перевірки безпеки часто не в змозі зупинити такі атаки, що підвищує ризик для вашої організації.

Роль ШІ в deepfake BEC

Штучний інтелект є рушієм цих складних шахрайств. Зловмисники використовують моделі ШІ, щоб збирати корпоративні веб-сайти, профілі в соціальних мережах і записи конференц-дзвінків із результатами роботи компанії, та формувати навчальні дані про ключових співробітників. Вони клонують голоси та стилі письма, щоб їхній початковий фішинговий контакт виглядав автентично. Типова кампанія deepfake BEC відбувається за продуманою послідовністю:

1. Зловмисники збирають OSINT (розвідувальні дані з відкритих джерел) про ваших керівників та корпоративну ієрархію.
2. Вони подають аудіо- та відеозразки в моделі ШІ, щоб створити переконливі голосові клони або відеоматеріали deepfake.
3. Персоналізовані фішингові листи або вступні повідомлення надсилаються цілям, часто проходячи всі технічні перевірки автентифікації.
4. Зловмисники посилюють взаємодію, переходячи до телефонних дзвінків, голосової пошти або відеонарад, щоб підсилити тиск.
5. Кінцева мета досягається, коли жертва переказує кошти або передає облікові дані, вважаючи, що це схвалив керівник.

Великі фінансові установи та підприємства повідомляли про тривожні інциденти шахрайства з клонуванням голосу, які обходили стандартні механізми захисту. В одному відомому випадку співробітник переказав значні кошти після взаємодії з аудіопотоком deepfake. Deepfake BEC є не просто еволюцією фішингу, а принципово новою категорією синтетичного шахрайства.

SPF, DKIM і DMARC: як вони працюють

Огляд SPF

Щоб зрозуміти, чому ці протоколи не справляються з deepfake, спочатку варто розглянути, що вони насправді роблять. SPF, або Sender Policy Framework, перевіряє, чи має поштовий сервер, який передає повідомлення, явний дозвіл надсилати листи від імені певного домену. Коли лист надходить на ваш шлюз, приймаюча система перевіряє DNS-записи домену на наявність запису SPF. Якщо IP-адреса сервера відправника відповідає схваленому списку, повідомлення проходить перевірку SPF. Хоча цей механізм зупиняє базову підміну, коли зловмисники підробляють домен в конверті, він повністю ігнорує видиму адресу «Від кого», яку бачить кінцевий користувач, залишаючи значний простір для соціальної інженерії.

Огляд DKIM

DKIM, або DomainKeys Identified Mail, додає криптографічну перевірку. Він прикріплює цифровий підпис до вихідних листів, який приймаюча поштова система перевіряє за допомогою відкритого ключа, опублікованого в DNS домену. Якщо підпис збігається, у вас є криптографічне підтвердження того, що вміст повідомлення не було змінено під час передачі. Хоча DKIM гарантує цілісність повідомлення, він не може сказати нічого про наміри відправника. Зловмисники часто використовують скомпрометовані легітимні облікові записи електронної пошти, які природно проходять перевірку DKIM, щоб запускати переконливі фішингові кампанії або готувати ґрунт для ескалації deepfake.

Огляд DMARC

DMARC об'єднує SPF і DKIM в єдину систему політик. Він дозволяє власникам доменів задавати серверам-одержувачам інструкції щодо того, як обробляти повідомлення, які не пройшли перевірку SPF або DKIM, а також надає цінні криміналістичні звіти. DMARC захищає видиме поле «From» і ефективно блокує підміну точного домену. Хоча це критично важливий базовий захід для будь-якої організації, DMARC не аналізує семантичний зміст або психологічний намір повідомлення. Зловмисник може легко зареєструвати схожий домен, налаштувати для нього коректні записи SPF, DKIM і DMARC, а потім використати ШІ, щоб створити шахрайство з дипфейками, яке без перешкод пройде крізь ваш шлюз із захистом DMARC.

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

Ось таблиця, що узагальнює основні функції цих протоколів:

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

Що захищають ці протоколи

Важливо чітко розуміти межі автентифікації пошти. SPF, DKIM і DMARC призначені виключно для захисту вашої поштової інфраструктури від видавання себе за іншу особу на транспортному рівні. Вони гарантують, що повідомлення, які нібито надійшли з вашого домену, справді пов'язані з вашими поштовими серверами, а текст не було змінено в дорозі.

Розберемо, що покриває кожен протокол:

• SPF перевіряє, чи надіслано лист з авторизованого сервера, блокуючи неавторизованих відправників, які намагаються використовувати ваше доменне ім'я.
• DKIM додає цифровий підпис, гарантуючи, що текст листа та заголовки не змінювалися з моменту відправлення.
• DMARC реалізує SPF і DKIM на практиці, визначаючи політики карантину або відхилення для листів, що не пройшли перевірку, і надаючи звіти для моніторингу.

Ось таблиця, яка допоможе побачити, від чого захищають ці протоколи:

Головне: жоден із цих протоколів не оцінює змістовне наповнення листа чи вторинні канали зв'язку, якими може скористатися зловмисник. Якщо лист проходить усі технічні перевірки, бо надіслано його з скомпрометованого облікового запису постачальника, а після нього відбувається дзвінок із дипфейком, ваші протоколи автентифікації покажуть повний порядок, тоді як організація зазнає катастрофічного інциденту безпеки.

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

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

Обмеження для BEC із дипфейками

Автентифікація відправника проти перевірки змісту

Основна вразливість, коли покладаються лише на такі протоколи, як DMARC, полягає в прірві між автентифікацією відправника та перевіркою змісту. SPF, DKIM і DMARC перевіряють технічну відповідність, але абсолютно не бачать шкідливого змісту. Зловмисник може успішно пройти автентифікацію листа через схожий або щойно зареєстрований домен, задовольнивши всім вимогам DMARC, тоді як текст повідомлення міститиме ретельно налаштовану соціальну інженерну приманку, створену штучним інтелектом.

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

Ось таблиця з основними обмеженнями:

Ці обмеження показують, чому команди безпеки не можуть дозволити собі самовдоволення. Технічна автентифікація забезпечує належну гігієну доставки пошти, але нічим не допомагає зупинити шахрайство з дипфейками чи компрометацію ділового листування, які походять від автентифікованих джерел.

Чому атаки BEC з дипфейками є успішними

Атаки BEC з дипфейками вдаються, бо експлуатують психологічні слабкості людей і при цьому чисто обходять технічні перешкоди. Коли співробітник отримує лист, який проходить усі перевірки безпеки, а до нього додається голосове повідомлення чи відеозапис, що звучить і виглядає так само, як його керівник, когнітивний захист послаблюється. Крім того, структурні вразливості глобальної маршрутизації пошти, зокрема експлуатації SMTP smuggling, що зачіпають численні публічні та приватні поштові сервіси, історично дозволяли досвідченим зловмисникам повністю обходити шлюзи автентифікації.

Погляньте на показники впевненості керівників і лідерів у сфері безпеки:

• 60% керівників з кібербезпеки не впевнені у своїй здатності протидіяти атакам з дипфейками.
• 38% оцінюють традиційне навчання з обізнаності як помірно ефективне або гірше щодо аудіодипфейків.
• 39% оцінюють навчання як помірно ефективне або гірше щодо відеодипфейків.
• 28% вважають, що фішинг із використанням ШІ все ще перебуває на початковому етапі.
• 25% відносять атаки з аудіодипфейками до ранніх загроз із величезним простором для ескалації.

Ця невпевненість має під собою підстави. Зловмисники поєднують багатоканальний синтетичний медіаконтент із бездоганно автентифікованими листами, створюючи схему обману, яка долає застарілі підходи до безпеки.

Поширені хибні уявлення про безпеку

У ІТ-адмініструванні часто побутує хибна думка, що політика DMARC p=none забезпечує реальний захист. Насправді p=none є лише режимом моніторингу для збору даних звітності; вона нічого не блокує з неавтентифікованою або підробленою поштою. Організаціям необхідно перейти до p=quarantine або p=reject, щоб застосувати захисні межі.

Ще одне поширене хибне уявлення полягає в тому, що транзакційні домени або домени лише для внутрішнього використання не потребують суворої автентифікації. Незахищені домени створюють побічні вразливості, які зловмисники можуть використати. Нарешті, багато адміністраторів вважають, що впровадження DMARC є надто складним, тоді як сучасні засоби розгортання та автоматизовані рекомендації значно спростили відповідність вимогам.

Ось таблиця, яка розвіює поширені міфи:

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

Методи атак BEC з дипфейками

Реальні сценарії

Дипфейк-атаки більше не є теоретичними сценаріями з фантастики. У січні 2024 року міжнародна інженерна компанія Arup стала жертвою вражаючого шахрайства з використанням дипфейків. Зловмисники застосували дипфейки відео та аудіо в режимі реального часу під час віртуальної конференції, щоб видати себе за фінансового директора компанії та інших керівників вищої ланки. Синтетичні аватари та голоси були настільки переконливими, що співробітники фінансового відділу добровільно перерахували 25 мільйонів доларів у кількох транзакціях. Цей показовий випадок довів, що досвідчені зловмисники активно поєднують мультиканальні синтетичні медіа, щоб повністю обходити стандартні процедури корпоративної верифікації та базові практики безпеки.

Техніки дипфейків у BEC

Шахраї значною мірою покладаються на імітацію керівництва вищої ланки, адже ієрархія в організаціях природно спонукає до виконання вказівок. Коли зловмисник успішно копіює голос або зовнішність генерального директора, керівника підрозділу чи фінансового директора, він використовує авторитет проти співробітників нижчої ланки, які працюють із чутливими фінансовими операціями. Ці техніки стабільно призводять до величезних фінансових втрат, адже вони оминають раціональну скептичність.

Кампанії BEC з дипфейками зазвичай поєднують кілька взаємопов'язаних тактик:

• Клонування синтетичного голосу, який використовують у телефонних дзвінках або голосових повідомленнях.
• Маніпуляція відео в режимі реального часу під час віртуальних нарад для імітації присутності керівника.
• Складання листів за допомогою ШІ, які повторюють точний стиль спілкування та лексику цільового керівника.
• Скоординовані мультиканальні атаки, коли автентичний лист миттєво підкріплюється дипфейк-дзвінком.

Людський фактор у BEC з дипфейками

Зрештою, BEC з дипфейками атакує людську психологію, а не технічний код. Зловмисники значною мірою спираються на добре відомі принципи соціальної інженерії, щоб змусити жертв негайно виконати вказівки.

Будьте обережні. BEC з дипфейками це не лише технічна проблема. Вона атакує вашу довіру, ваші звички та ваше бажання допомогти.

Захист від BEC з дипфейками

Навчання співробітників

Оскільки BEC з дипфейками атакує людське сприйняття, навчання співробітників залишається важливою лінією оборони. Проте традиційних тренінгів, які зосереджені лише на виявленні помилок у граматиці чи підозрілих заголовків електронних листів, уже недостатньо. Організаціям варто інвестувати в інтерактивні платформи для симуляції дипфейків, які знайомлять персонал із синтетичними медіа в контрольованому середовищі. Пройшовши під час навчання симуляції дипфейк-відеодзвінків або клонованих голосів синтетичних керівників, співробітники вироблять необхідний automatism: призупинятися, обдумувати та перевіряти незвичні запити, перш ніж діяти.

Розширене виявлення загроз

Технології мають доповнювати людську обізнаність. Сучасні архітектури безпеки включають системи розширеного виявлення загроз на основі штучного інтелекту та машинного навчання. Ці інструменти аналізують поведінкові базові показники в різних каналах зв'язку, щоб позначати аномалії, які стандартні фільтри електронної пошти пропускають.

Верифікація за допомогою окремого каналу

Одна з найпростіших і водночас найефективніших контрзаходів проти BEC з дипфейками — сувура дотримання протоколів верифікації за окремим каналом. Щоразу, коли співробітник отримує термінový або високоризиковий запит, пов'язаний із банківськими переказами, передаванням облікових даних чи обходом політик, незалежно від того, наскільки автентичними виглядають електронний лист, голос або відеодзвінок, він має перевірити запит через незалежний, заздалегідь визначений канал.

• Верифікація за окремим каналом передбачає підтвердження незвичних запитів через другий незалежний канал зв'язку, наприклад, зворотним дзвінком на відомий внутрішній корпоративний номер.
• Користувачі повинні перевіряти чутливі інструкції через два окремих попередньо схвалених канали, щоб скомпрометований основний канал не міг зламати весь цикл перевірки.

Удосконалення політик

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

Порада: Чіткі політики допомагають запобігати фішинговим атакам і атакам з використанням дипфейків. Коли всі знають правила, зменшується кількість помилок і безпека вашої організації зростає.

Рішення Microsoft Entra Verified ID

Як працює Entra Verified ID

Щоб справді вирішити проблему BEC-атак з використанням дипфейків, організаціям потрібно перейти від довіри на основі розпізнавання до криптографічно підтвердженої перевірки на основі доказів. Microsoft Entra Verified ID – це надійне рішення децентралізованої ідентичності, яке дає змогу організаціям криптографічно перевіряти як особу, так і повноваження людей перед наданням доступу або погодженням високоризикових дій.

Entra Verified ID інтегрує механізми візуальної перевірки, зокрема перевірку посвідчення особи з фото, виданого державою, та перевірку присутності живої людини під час онбордингу. Це гарантує, що особа, яка володіє обліковим посвідченням, фізично присутня і перевірена. Поєднуючи атестацію пристрою, поведінкову біометрію та перевірювані облікові посвідчення, ви усуваєте вразливості, пов’язані з довірою лише до знайомого голосу чи обличчя.

Примітка: Entra Verified ID не замінює ваші чинні заходи контролю. Він додає потужний рівень, який спирається на доказовість, а не лише на розпізнавання.

Перевірка повноважень і перевірка особи

Перевірка особи підтверджує, хто є людиною, а перевірка повноважень визначає, чи має ця людина конкретний мандат на виконання високоризикової операції. Entra Verified ID використовує архітектуру «емітент – власник – верифікатор», що дає організаціям точний контроль над випуском і відкликанням облікових посвідчень.

Інтеграція Entra Verified ID з чинним захистом

Щоб упровадити Entra Verified ID, не потрібно відмовлятися від наявних інвестицій у безпеку Microsoft 365. Рішення безперешкодно вписується у вашу стратегію Zero Trust і працює разом із умовними політиками доступу, захистом кінцевих точок та аналітикою розширених загроз. Вимагаючи перевірюване облікове посвідчення для чутливих процесів, зокрема великих фінансових переказів або адміністративних перевизначень, ви нейтралізуєте спроби BEC-атак з дипфейками, адже зловмисник не може підробити криптографічні повноваження.

Порада: Використовуйте Entra Verified ID, щоб підтверджувати і особу, і повноваження. Цей крок допомагає зупиняти BEC-атаки з дипфейками та зберігати безпеку вашої організації.

Самих лише SPF, DKIM і DMARC недостатньо, щоб зупинити BEC-атаки з дипфейками. Ці інструменти не блокують домени, схожі на справжні, та імітацію, створену ШІ.

SPF, DKIM і DMARC не запобігають атакам через домени, схожі на справжні, атакам через «двоюрідні» домени або видаванню себе за іншу особу через безкоштовні поштові сервіси. Ці протоколи покладаються на людське судження, якому можна легко маніпулювати за допомогою контенту, згенерованого ШІ.
Потрібен багаторівневий захист. Почніть з навчання співробітників, управління ризиками та найкращих практик. Додайте розширені рішення, як-от Microsoft Entra Verified ID, для перевірки повноважень.

• У 2024 році BEC-атаки завдали збитків на 2,9 мільярда доларів лише в Сполучених Штатах.
• Середня вартість шахрайства BEC для компаній становить 137 132 $ за один інцидент.
  Використовуйте симуляції фішингу, безперервний моніторинг і регулярне навчання, щоб перевірити свій захист і зберегти безпеку організації.

🎧 Слухайте цей епізод

Хочете практичне пояснення теми Stop Deepfake Business Email Compromise with Verified ID? У цьому епізоді тема розкривається зрозумілою мовою та пояснюється, чому вона важлива для Microsoft 365, Azure, Power Platform, безпеки, ШІ та сучасної роботи.

Слухайте цей епізод, якщо хочете:

• Зрозуміти ключові концепції теми Stop Deepfake Business Email Compromise with Verified ID
• Побачити, як це вписується в ширшу екосистему технологій Microsoft
• Дізнатися, де це може принести практичну користь вашій організації

Вам також можуть сподобатися пов’язані епізоди M365 FM:

• Безпека Service Principal: припиніть використовувати особисті облікові записи
• Зупиніть prompt injection у Microsoft Copilot за допомогою Azure Logic Apps
• Припиніть передавати людське судження Microsoft Copilot
• Зупиніть ентропію витрат Azure: контроль власності та бюджетів
• Як зупинити ШІ-агентів від видалення важливих електронних листів

Відкривайте більше практичних розмов про Microsoft на M365 FM.