Защита от фишинга: почему растет число успешных атак

По данным Positive Technologies, 63% успешных атак заканчиваются утечкой конфиденциальных данных. Пока вендоры продают «военный уровень шифрования», а CISO отчитываются о полном покрытии MFA, злоумышленники штампуют фишинг через Phishing-as-a-Service и обходят двухфакторную аутентификацию с помощью AitM-прокси в реальном времени.

Классическая защита от фишинга строилась на двух китах: почтовых фильтрах SPF/DKIM/DMARC и обучении пользователей. Оба механизма по-прежнему нужны, но они рассчитаны прежде всего на тактики, которые были характерны несколько лет назад. Сейчас фишинг приходит с легитимных сервисов, от взломанных корпоративных аккаунтов, с корректной грамматикой и правдоподобным контекстом. Иногда письмо не содержит очевидно вредоносной ссылки: оно ведет на настоящий документ в Google Drive или страницу совместной работы, где уже начинается следующий этап атаки.

По мировым оценкам, ежедневно рассылается около 3,4 млрд фишинговых писем. Adversary-in-the-Middle обходит часть сценариев двухфакторной аутентификации в реальном времени. Phishing-as-a-Service превратил атаку в конвейер с подпиской, а генеративные модели помогают делать сообщения персональными и убедительными. Поэтому вопрос сегодня звучит не так: включена ли у компании MFA? Вопрос в другом: какие именно сценарии она закрывает и что произойдет после того, как сотрудник все-таки перейдет по ссылке.

Главное по теме: что изменилось в фишинге

Анатомия современной атаки

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

По оценкам аналитиков, 60–70% фишинговых кампаний 2025 года работают на платформах Phishing-as-a-Service. Злоумышленник покупает готовый набор инструментов, получает панель управления, шаблоны под конкретные бренды, обфусцированный хостинг и иногда техническую поддержку. Для запуска кампании больше не требуется самостоятельно разрабатывать фишинговую страницу, настраивать сбор учетных данных и разбираться с обходом базовых фильтров.

Фишинг стал не столько ремеслом, сколько сервисной моделью: готовая инфраструктура снижает порог входа и ускоряет повторение атаки.

Следующий слой — использование легитимных сервисов. Злоумышленники взламывают аккаунты в Google Docs, Microsoft 365, Notion, Slack и других инструментах совместной работы, а затем рассылают сообщения от имени настоящего пользователя. SPF и DKIM в такой ситуации могут пройти проверку, домен имеет нормальную репутацию, TLS-сертификат настоящий, а ссылка ведет на легитимную платформу.

По данным Acronis, 31% атак во втором полугодии 2025 года пришлось на платформы совместной работы против 12% годом ранее. Это рост почти в три раза. Почтовый фильтр, который в основном оценивает репутацию домена и технические признаки сообщения, видит корректную инфраструктуру. Аномалия находится в контексте: адресат раньше не общался с этим отправителем, просьба не соответствует обычному рабочему процессу, документ появился в необычное время, а дальнейшее действие требует срочно войти в аккаунт.

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

Это не означает, что ИИ самостоятельно проводит сложную атаку без участия человека. Но он заметно ускоряет подготовку: помогает создавать варианты сообщений, адаптировать их под разные отделы и поддерживать единый тон переписки. Сигнал «письмо написано странно» перестает быть надежным. Иногда он вообще отсутствует.

Почему фишинг работает

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

На эффективность атаки влияют несколько факторов:

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

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

Как это работает: MFA под давлением

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

Сценарий AitM

В атаке Adversary-in-the-Middle пользователь переходит по фишинговой ссылке и попадает не на полностью поддельную страницу, а на прокси-узел злоумышленника. Этот узел в реальном времени передает запросы между пользователем и настоящим сервисом, например Microsoft 365.

Сценарий выглядит следующим образом:

1. Пользователь открывает ссылку из письма и видит привычную форму входа.

2. Вводит логин и пароль на странице, которая визуально имитирует настоящий сервис.

3. Прокси передает данные на легитимный сайт.

4. Настоящий сайт запрашивает второй фактор.

5. Пользователь вводит код или подтверждает push-уведомление.

6. Прокси передает подтверждение дальше и получает действующую сессию.

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

По приведенным оценкам, около 15% атак по краже учетных данных используют методы типа Adversary-in-the-Middle. Это не означает, что каждая такая атака обходится одинаково или что остальные методы MFA бесполезны. Но показатель хорошо демонстрирует направление: злоумышленники атакуют не только пароль, но и сам процесс аутентификации.

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

Почему FIDO2 и WebAuthn устойчивее

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

В корпоративной среде такой подход может быть реализован через аппаратные ключи, Windows Hello, Touch ID, совместимые Android-механизмы и passkeys. Аппаратные ключи особенно уместны для привилегированных учетных записей: администраторов, сотрудников с доступом к платежным системам, DevOps-команд и руководителей, чьи аккаунты часто используются для дальнейшего перемещения внутри инфраструктуры.

Массовый переход сложнее, чем установка переключателя в панели администратора. Нужно продумать восстановление доступа, замену устройства, резервные методы, поддержку сотрудников и совместимость с корпоративными приложениями. Но это уже задача внедрения, а не аргумент против технологии.

SMS и TOTP могут оставаться переходным вариантом или использоваться там, где фишинг-устойчивый метод пока недоступен. Ошибка начинается в тот момент, когда переходный вариант объявляют конечной архитектурой на неопределенный срок.

Практические детали: какие способы защиты работают

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

Фишинг-устойчивая аутентификация

FIDO2/WebAuthn стоит рассматривать как основной метод MFA для привилегированных аккаунтов. Для остальных пользователей можно использовать встроенные платформенные аутентификаторы и passkeys, если они поддерживаются используемыми сервисами.

SMS и TOTP не нужно отключать хаотично: резкий отказ от привычного метода может привести к блокировкам и появлению неформальных обходов. Но у организации должен быть понятный план миграции, список исключений и процедура восстановления доступа. Иначе «временный» SMS-код будет использоваться годами.

DMARC с жесткой политикой

DMARC с policy=reject помогает защитить домен от подделки отправителя. Это не закрывает сценарий со взломанным легитимным аккаунтом, зато отсекает заметный пласт атак, основанных на простой подмене адреса.

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

DMARC не заменяет поведенческий анализ и защиту конечных устройств. Это один из слоев, который снижает вероятность доставки части сообщений, но не распознает письмо от реально скомпрометированного отправителя.

Поведенческий анализ почты

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

Дополнительными сигналами могут быть:

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

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

Изоляция браузера

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

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

Менеджер паролей

Корпоративный менеджер паролей с централизованным управлением снижает риск повторного использования учетных данных и помогает пользователю не вводить пароль на неправильном домене. Менеджер, корректно привязанный к адресу сайта, не должен автоматически подставлять пароль на похожем, но чужом домене.

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

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

Мониторинг утечек

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

При подтвержденной утечке недостаточно просто попросить пользователя сменить пароль. Нужно проверить активные сессии, токены, правила пересылки почты, подключенные приложения и резервные методы восстановления. Если аккаунт не переведен на фишинг-устойчивый MFA, смена пароля может оказаться лишь временной мерой.

Разделение почтовых доменов

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

Это не универсальное решение и не замена DMARC. Кроме того, пользователи должны понимать логику маркировки, иначе предупреждения быстро превратятся в привычный визуальный шум. Любой защитный механизм теряет смысл, если сотрудники видят предупреждение в каждом втором письме и перестают его читать.

На что обратить внимание в корпоративной архитектуре

Не все начинается с почты

ENISA фиксирует: 60% кибератак в Европе начинаются с фишинга, тогда как на эксплуатацию уязвимостей приходится 21,3%. Эти показатели не отменяют важность патч-менеджмента и защиты конечных устройств. Они показывают другое: даже хорошо настроенный периметр не спасает, если пользователь сам передает атакующему действующую сессию или доступ к облачному сервису.

Защита от фишинга должна учитывать весь путь атаки:

1. Доставка. Фильтры проверяют отправителя, домен, вложения, ссылки и репутацию инфраструктуры.

2. Переход. Браузерная изоляция, безопасный DNS и анализ URL снижают риск выполнения вредоносного содержимого.

3. Ввод данных. Менеджер паролей и фишинг-устойчивая аутентификация уменьшают вероятность передачи секрета на чужом домене.

4. Получение доступа. Системы управления идентификацией проверяют устройство, контекст и риск сессии.

5. Развитие атаки. Принцип наименьших привилегий ограничивает ущерб от захваченного аккаунта.

6. Реагирование. Команда быстро отзывает сессии, блокирует учетную запись и проверяет связанные системы.

Если закрыт только первый этап, организация защищается от старого фишинга, но оставляет свободными следующие шаги.

Минимальные привилегии важнее красивого отчета

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

По данным SpyCloud, 35% атак шифровальщиков в 2025 году начинались с фишинга против 25% годом ранее. Это означает рост на 10 процентных пунктов, или на 40% относительно прежнего значения. Разница между абсолютным и относительным ростом здесь принципиальна: 10 процентных пунктов описывают изменение самой доли, а 40% — насколько эта доля увеличилась относительно исходного уровня.

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

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

Обучение должно измерять реакцию

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

Полезно разбирать реальные сценарии:

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

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

Практическая политика защиты

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

1. FIDO2/WebAuthn для привилегированных аккаунтов. Для остальных пользователей — доступные фишинг-устойчивые методы и понятный план миграции с SMS и TOTP.

2. DMARC с policy=reject на основном домене после проверки легитимных отправителей и поддоменов.

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

4. Изоляция браузера для пользователей, которые регулярно работают с внешними документами и ссылками.

5. Централизованный менеджер паролей с контролем доменов, отзывом доступа и запретом на неуправляемое хранение корпоративных секретов.

6. Мониторинг утечек учетных данных с процедурой ротации паролей, отзывом сессий и проверкой подключенных приложений.

7. Разделение внутренних и внешних почтовых потоков, чтобы сообщения с нетипичным происхождением можно было обрабатывать строже.

8. Принцип наименьших привилегий с регулярным аудитом ролей и удалением неиспользуемых доступов.

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

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

11. Запрет на использование личных почтовых ящиков для корпоративных задач. Неконтролируемый канал означает отсутствие нормальной телеметрии и процедур восстановления.

12. Проверка критичных операций по независимому каналу. Изменение реквизитов, выдача доступа и крупные платежи не должны подтверждаться только ответом на письмо.

Итоги

Защита от фишинга в 2025–2026 году — это не покупка антивируса и не формальное включение 2FA. Фишинг изменился: он использует легитимные сервисы, взломанные аккаунты, готовые криминальные платформы, перехват сессий и персонализированный контент. Поэтому старая модель «фильтр плюс обучение» больше не может быть единственным рубежом.

Эффективность защиты от фишинга определяется не количеством установленных продуктов, а тем, как они соединены в систему. DMARC снижает риск подделки отправителя, поведенческий анализ помогает заметить аномальный контекст, изоляция ограничивает последствия перехода по ссылке, менеджер паролей уменьшает вероятность ввода секрета на чужом домене, а FIDO2/WebAuthn закрывает наиболее опасный сценарий с перехватом аутентификации.

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