Защита от спуфингом для облачных почтовых ящиков

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

Технология защиты от спуфингов в Microsoft 365 специально проверяет подделку заголовка From в тексте сообщения (также известного как адрес, от адреса или отправителя P2), так как 5322.From почтовые клиенты отображают значение заголовка From в качестве отправителя сообщения. Если microsoft 365 имеет высокую достоверность, заголовок From подделается, сообщение определяется как спуфинг.

Во встроенных функциях безопасности для всех облачных почтовых ящиков доступны следующие технологии защиты от спуфингов:

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

  Microsoft 365 анализирует и блокирует сообщения на основе сочетания стандартных методов проверки подлинности электронной почты и методов репутации отправителя.

  

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

• Разрешить или заблокировать подделанных отправителей в списке разрешенных и заблокированных клиентов. При переопределении вердикта в аналитике спуфинга спуфинг становится записью разрешения или блокировки вручную, которая отображается только на вкладке Подделанные отправители на странице Списки разрешений и блокировок клиента по адресу https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem. Вы также можете вручную создавать разрешенные или блокировать записи для поддельных отправителей, прежде чем подделательная аналитика обнаружит их. Дополнительные сведения см. в разделе Подделанные отправители в списке разрешенных и заблокированных клиентов.

• Политики защиты от фишинга. Во встроенных функциях безопасности для всех облачных почтовых ящиков и в Microsoft Defender для Office 365 политики защиты от фишинга содержат следующие параметры защиты от спуфингов:

  • Включите или отключите аналитику спуфинга.
  • Включите или отключите индикаторы не прошедших проверку подлинности отправителей в Outlook.
  • Определение действия для заблокированных поддельных отправителей.

  Дополнительные сведения см. в статье Параметры фишинга в политиках защиты от фишинга.

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

• Отчет об обнаружении подделки. Для получения дополнительной информации см. статью Отчет об обнаружении подделки.

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

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

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

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

  Следующее сообщение является примером фишинга, в котором используется поддельный отправитель [email protected]:

  

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

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

  

  Сообщение выглядит законным, но отправитель подделан.

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

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

  

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

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

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

• Спуфинг внутри организации: также известен как спуфинг самому себе. Например,

  • Отправитель и получатель находятся в одном домене:

    From: [email protected]
    To: [email protected]
    

  • Отправитель и получатель находятся в поддоменах одного домена:

    From: [email protected]
    To: [email protected]
    

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

    From: [email protected]
    To: [email protected]
    

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

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

  X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.11

  • reason=6xx обозначает подделку внутри Организации.
  • SFTY — уровень безопасности сообщения.
    • 9 указывает на фишинг.
    • .11 обозначает подделку внутри Организации.

• Междоменная спуфинг: домены отправителя и получателя отличаются и не имеют отношения друг к другу (также известные как внешние домены). Например,

  From: [email protected]
  To: [email protected]
  

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

  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.

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

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

Например, Габриэла Лауреано ([email protected]) заинтересована в наблюдениях за птицами, поэтому она присоединяется к списку [email protected]рассылки и отправляет в список следующее сообщение:

From: "Gabriela Laureano" <[email protected]>
To: Birdwatcher's Discussion List <[email protected]>
Subject: Great viewing of blue jays at the top of Mt. Rainier this week

Anyone want to check out the viewing this week from Mt. Rainier?

Сервер списка рассылки принимает сообщение, изменяет его содержимое и передает его членам списка. Воспроизводимое сообщение имеет тот же адрес From ([email protected]), но тег добавляется в строку темы, а нижний колонтитул добавляется в нижнюю часть сообщения. Этот тип изменения распространен в списках рассылки и может привести к ложноположительным срабатываниям для спуфингов.

From: "Gabriela Laureano" <[email protected]>
To: Birdwatcher's Discussion List <[email protected]>
Subject: [BIRDWATCHERS] Great viewing of blue jays at the top of Mt. Rainier this week

Anyone want to check out the viewing this week from Mt. Rainier?

This message was sent to the Birdwatchers Discussion List. You can unsubscribe at any time.

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

• Ваша организация владеет списком рассылки:

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

• Ваша организация не владеет списком рассылки:

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

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

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

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

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

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