Защита от спуфинга в EOP

Статья
03/10/2024
Применяется к:

✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

Совет

Знаете ли вы, что можете бесплатно опробовать функции в Microsoft Defender XDR для Office 365 плана 2? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

В организациях Microsoft 365 с почтовыми ящиками в Exchange Online и в автономных организациях Exchange Online Protection (EOP) без почтовых ящиков Exchange Online служба EOP включает функции для защиты организации от поддельных отправителей.

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

В EOP доступны следующие технологии против спуфинга:

Проверка подлинности электронной почты: неотъемлемой частью любых усилий по борьбе со спуфингом является использование аутентификации электронной почты (также известной как проверка электронной почты) записями SPF, DKIM и DMARC в DNS. Вы можете настроить эти записи для своих доменов, чтобы почтовые системы назначения могли проверять достоверность сообщений, которые, как утверждают, были отправлены в ваших доменах. Для входящих сообщений Microsoft 365 требует проверки подлинности электронной почты для доменов отправителей. Дополнительные сведения см. в статье Поверка подлинности электронной почты в Microsoft 365.

EOP анализирует и блокирует сообщения на основе сочетания стандартных методов проверки подлинности электронной почты и методов репутации отправителя.
Аналитика спуфинга. Проверьте обнаруженные подделанные сообщения от отправителей во внутренних и внешних доменах за последние семь дней. Дополнительные сведения см. в статье Аналитика спуфинга в EOP.
Разрешить или заблокировать подделанных отправителей в списке разрешенных и заблокированных клиентов. При переопределении вердикта в аналитике спуфинга спуфинг становится записью разрешения или блокировки вручную, которая отображается только на вкладке "Подделанные отправители" на странице Списки клиента разрешено или заблокировано.https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem Вы также можете вручную создать разрешающие или заблокированные записи для поддельных отправителей до того, как они будут обнаружены с помощью спуфинга. Дополнительные сведения см. в разделе Подделанные отправители в списке разрешенных и заблокированных клиентов.
Политики защиты от фишинга. В EOP и Microsoft Defender для Office 365 политики защиты от фишинга содержат следующие параметры защиты от спуфинга:
- Включите или отключите аналитику спуфинга.
- Включите или отключите индикаторы не прошедших проверку подлинности отправителей в Outlook.
- Определение действия для заблокированных поддельных отправителей.
Дополнительные сведения см. в статье Параметры фишинга в политиках защиты от фишинга.

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

Defender для Office 365 организации также могут использовать обнаружение в режиме реального времени (план 1) или Обозреватель угроз (план 2) для просмотра сведений о попытках фишинга. Дополнительные сведения см. в статье Исследование угроз Microsoft 365 и реагирование на них.

Совет

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

Как спуфинг используется при фишинговых атаках

Подделанные отправители в сообщениях имеют следующие негативные последствия для пользователей:

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

Следующее сообщение является примером фишинга, в котором используется поддельный отправитель msoutlook94@service.outlook.com:

Это сообщение не пришло с service.outlook.com, но злоумышленник подделал поле заголовка От, чтобы оно выглядело так, как оно было. Отправитель попытался обмануть получателя, чтобы выбрать ссылку на изменение пароля и предоставить свои учетные данные.

Следующее сообщение является примером BEC, который использует поддельный почтовый домен contoso.com:

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

Следующее сообщение является примером сообщения о сбросе реального пароля из учетной записи Microsoft Security:

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

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

Корпорация Майкрософт различает два разных типа подделанных отправителей в сообщениях:

Спуфинг внутри организации: также известен как спуфинг самому себе. Например,
- Отправитель и получатель находятся в одном домене:
  
  От: chris@contoso.com
  Кому: michelle@contoso.com
- Отправитель и получатель находятся в поддоменах одного домена:
  
  От: laura@marketing.fabrikam.com
  Кому: julia@engineering.fabrikam.com
- Отправитель и получатель находятся в разных доменах, принадлежащих одной организации (то есть оба домена настроены как принятые домены в одной организации):
  
  От: отправитель @ microsoft.com
  Кому: получатель @ поисковой системой bing.com
  
  Пробелы используются в адресах электронной почты, чтобы предотвратить сбор спамботов.
Сообщения, которые не проходят составную аутентификацию из-за подделки внутри организации, содержат следующие значения заголовка:

Authentication-Results: ... compauth=fail reason=6xx

X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.11
- reason=6xx обозначает подделку внутри Организации.
- SFTY — уровень безопасности сообщения. 9 указывает на фишинг, .11 указывает на подделывание внутри организации.
Междоменная спуфинг: домены отправителя и получателя отличаются и не имеют отношения друг к другу (также известные как внешние домены). Например:

От: chris@contoso.com
Кому: michelle@tailspintoys.com

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

Authentication-Results: ... compauth=fail reason=000/001

X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.22
- reason=000 указывает, что сообщение не прошло явную проверку подлинности электронной почты. reason=001 означает, что сообщение не прошло неявную проверку подлинности электронной почты.
- SFTY — уровень безопасности сообщения. 9 указывает на фишинг, .22 указывает на спуфингой между доменами.
Дополнительные сведения о результатах проверки подлинности и compauth значениях см. в разделе Поля заголовков сообщений authentication-results.

Проблемы с защитой от спуфинга

Известно, что списки рассылки (также известные как списки обсуждений) имеют проблемы с защитой от спуфингов из-за способа их пересылки и изменения.

Например, Габриэла Лауреано (glaureano@contoso.com) заинтересована в наблюдения за птицами, присоединяется к списку birdwatchers@fabrikam.comрассылки и отправляет в список следующее сообщение:

От: "Марта Артемьева" <glaureano@contoso.com>
Кому: Список обсуждений наблюдателей за птицами <birdwatchers@fabrikam.com>
Тема: Прекрасный вид голубой сойки на вершине горы Рейнир на этой неделе
Кто-нибудь хочет посмотреть птицу на этой неделе на горе Рейнир?

Сервер списка рассылки принимает сообщение, изменяет его содержимое и передает его членам списка. Воспроизводимое сообщение имеет тот же адрес From (glaureano@contoso.com), но тег добавляется в строку темы, а нижний колонтитул добавляется в нижнюю часть сообщения. Этот тип изменений распространен в списках рассылки и может привести к ложным срабатываниям при подделке.

От: "Марта Артемьева" <glaureano@contoso.com>
Кому: Список обсуждений наблюдателей за птицами <birdwatchers@fabrikam.com>
Тема: [BIRDWATCHERS] Прекрасный вид голубой сойки на вершине горы Рейнир на этой неделе
Кто-нибудь хочет посмотреть птицу на этой неделе на горе Рейнир?
Это сообщение было отправлено в список обсуждения для любителей птиц Birdwatchers. Вы можете отменить подписку в любое время.

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

Ваша организация владеет списком рассылки:
- Проверьте FAQ на DMARC.org: У меня есть список рассылки, и я хочу взаимодействовать с DMARC, что мне делать?.
- Прочтите инструкции в этом сообщении: Совет операторам списков рассылки по взаимодействию с DMARC во избежание сбоев.
- Рассмотрите возможность установки обновлений на сервере списков рассылки для поддержки ARC. Дополнительные сведения см. в статье http://arc-spec.org.
Ваша организация не владеет списком рассылки:
- Попросите сопровождающего списка рассылки настроить аутентификацию электронной почты для домена, с которого пересылается список рассылки. Владельцы, скорее всего, будут действовать, если достаточное количество участников попросит их настроить проверку подлинности по электронной почте. Хотя корпорация Майкрософт также работает с владельцами доменов в отношении необходимости публикации требуемых записей, лучше всего работает то, когда отдельные пользователи просят делать это.
- Создайте правила папки "Входящие" в почтовом клиенте для перемещения сообщений в папку "Входящие".
- Используйте список разрешенных и заблокированных клиентов, чтобы создать допустимую запись для списка рассылки, чтобы считать его допустимым. Дополнительные сведения см. в разделе Создание разрешенных записей для подделанных отправителей.

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

Соображения по поводу защиты от спуфинга

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

Отправители в отдельных пользователях (или администраторах) Безопасные отправители перечисляют обходные части стека фильтрации, включая защиту от подделки. Подробнее см. в статье Надежные отправители в Outlook.

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