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

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

Технология защиты от спуфингом в 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).

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

  

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

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

  

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

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

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

  

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

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

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

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

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

    From: chris@contoso.com
    To: michelle@contoso.com
    

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

    From: laura@marketing.fabrikam.com
    To: julia@engineering.fabrikam.com
    

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

    From: cindy@tailspintoys.com
    To: steve@wingtiptoys.com
    

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

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

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

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

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

  From: chris@contoso.com
  To: 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.

Как работают вердикты спуфинга разведки

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

Уровни оценки:

1. Составная проверка подлинности: проверяет SPF, DKIM и DMARC и объединяет результаты в один вердикт. Дополнительные сведения см. в разделе Составная проверка подлинности.
2. Аналитика спуфинга. Оценивает законность отправителя на основе шаблонов потока почты и журнала инфраструктуры отправителей. Дополнительные сведения см. в статье Аналитика спуфинга.
3. Политика защиты от фишинга. Определяет окончательное действие для сообщений, которые помечают как подозрительные. Дополнительные сведения см. в статье Параметры фишинга в политиках защиты от фишинга.

Поток принятия решений:

• Составная проверка подлинности проходит > сообщение доставляется нормально.
• Составная проверка подлинности завершается ошибкой > Спуфинга аналитика оценивает отправителя:
  • Спуфинговая аналитика идентифицирует отправителя как допустимое > сообщение.
  • Спуфинговая аналитика помечает отправителя как подозрительное > действие политики защиты от фишинга (перемещение в папку "Нежелательная Email" или карантин сообщения).

Партнерские сообщения, помеченные как поддельные

Бизнес-партнеры часто отправляют сообщения через службы сторонних поставщиков, что создает несоответствие проверки подлинности, которое активирует обнаружение подделок.

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

• Из заголовка: sender@fabrikam.com
• MAIL FROM (отправитель конверта):bounces@adatum.com
• Домен подписи DKIM: adatum.com

Результаты проверки подлинности:

• SPF проходит для adatum.com (домен отправителя конверта).
• DKIM передает adatum.com (домен подписи).
• Сбой DMARC, так как ни SPF, ни DKIM не соответствуют домену заголовка From (fabrikam.com).
• Вердикт: compauth=fail → сообщение помечено как подделаемое.

Распространенные причины этого несоответствия:

• Email маркетинговые службы (например, Marketo, HubSpot или Mailchimp).
• Облачные шлюзы электронной почты (например, Proofpoint или Mimecast).
• Email служб ретрансляции или общих платформ размещения.

Пользователи могут увидеть подделанный баннер предупреждения в Outlook, символ "?" рядом с именем отправителя или сообщение, доставленное в папку "Нежелательная Email".

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

Долгосрочное решение. Попросите партнера исправить проверку подлинности электронной почты:

• Настройте подписывание DKIM с помощью собственного домена.
• Добавьте службу сторонних поставщиков в запись SPF.
• Используйте поддомен для сообщений службы (например, marketing.fabrikam.com) с правильным выравниванием SPF и DKIM.

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

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

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

From: "Gabriela Laureano" <glaureano@contoso.com>
To: Birdwatcher's Discussion List <birdwatchers@fabrikam.com>
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 (glaureano@contoso.com), но тег добавляется в строку темы, а нижний колонтитул добавляется в нижнюю часть сообщения. Этот тип изменения распространен в списках рассылки и может привести к ложноположительным срабатываниям для спуфингов.

From: "Gabriela Laureano" <glaureano@contoso.com>
To: Birdwatcher's Discussion List <birdwatchers@fabrikam.com>
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.

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