Руководство по расследованию фишинга

В этой статье демонстрируется фишинговый сборник схем. Это часть руководства по сборнику схем реагирования на инциденты в дисциплине "Операции безопасности" (SecOps).

Это руководство предназначено для всех специалистов, отвечающих за создание или выполнение планов реагирования на инциденты, включая аналитиков SecOps, специалистов по реагированию на инциденты, администраторов удостоверений личности и специалистов по ИТ-операциям.

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

Рекомендации в этой статье описывают, что следует изучить и почему. Примеры конкретного продукта (например, Microsoft Defender XDR или Microsoft Sentinel) предоставляются в качестве эталонных реализаций.

Перед началом работы

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

Area Требование Сведения
Сведения об учетной записи Наличие по крайней мере одного идентификатора для подозреваемого целевого пользователя Идентификаторы могут быть: имя участника-пользователя (UPN), адрес электронной почты или имя пользователя или псевдоним.

Эти сведения необходимы для сопоставления действий с электронной почтой, входов в систему и последующих действий.
Аудит и ведение журнала Microsoft 365 Аудит почтовых ящиков должен быть включен в организации, чтобы обеспечить запись доступа к почтовым ящикам и действий. Убедитесь, что аудит почтовых ящиков включен по умолчанию, выполнив следующую команду в PowerShell Exchange Online: Get-OrganizationConfig | Format-List AuditDisable/.

Значение False указывает, что аудит почтовых ящиков включен для всех почтовых ящиков.
Аудит и ведение журнала Microsoft 365 Журналы трассировки сообщений необходимы для определения исходного фишингового сообщения, состояния доставки, всех получателей и сведений о маршрутизации сообщения. Трассировка сообщений доступна в Exchange Admin Center и на портале Microsoft Defender (Электронная почта и совместная работа > Трассировка сообщений Exchange).

Чтобы эффективно работать с данными трассировки сообщений, следователи должны иметь возможность получать и интерпретировать значения идентификатора сообщения, полученные из необработанных заголовков электронной почты.
Аудит и ведение журнала Microsoft 365 Единые журналы аудита необходимы для проверки действий пользователей и администраторов во всех службах Microsoft 365. Убедитесь, что следователи могут выполнять поиск в едином журнале аудита, чтобы просмотреть такие действия, как доступ к почтовому ящику, действия элементов почты, административные изменения и события, связанные с входом.
Журналы Microsoft Entra Microsoft Entra ID журналы входа и аудита хранятся в течение ограниченного периода (30 или 90 дней в зависимости от лицензирования). Для поддержки расследований, исторического анализа и проверки после инцидента экспортируйте журналы в долгосрочный репозиторий, например Microsoft Sentinel, Azure Monitor или сторонний SIEM.
Разрешения Убедитесь, что у следователей достаточно разрешений для доступа к необходимым данным без чрезмерного доступа к учетным записям. Microsoft Entra ID: минимально рекомендуемая роль — Читатель сведений о безопасности.

Портал Defender и портал соответствия требованиям Microsoft: Читатель сведений о безопасности.

Эти роли предоставляют доступ только для чтения к электронной почте, оповещениям и данным аудита.
Видимость конечной точки Microsoft Defender для конечной точки (средство защиты для конечных точек) Если установлен Defender для конечной точки, используйте его для:

— проверьте, взаимодействуют ли пользователи с фишинговым содержимым.
— выявление выполнения пейлоада.
— Сопоставляйте активность конечных точек с почтовыми событиями.
Оборудование Система с поддержкой PowerShell.
Программное обеспечение. Эти модули PowerShell часто используются во время фишинговых исследований Пакет SDK PowerShell для Microsoft Graph
модуль PowerShell Exchange Online
модуль PowerShell для реагирования на инциденты Microsoft Entra

Убедитесь, что все модули установлены и хранятся в актуальном состоянии.

Рабочий процесс

Рабочий процесс исследования фишинга следует следующим высоким уровням:

  1. Определите и подтвердите фишинговое сообщение.
  2. Область влияния и затронутых пользователей.
  3. Оцените взаимодействие пользователей и раскрытие учетных данных.
  4. Определите последующее действие.
  5. Локализуйте угрозу и предотвратите её повторение

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

Что проверить

Используйте этот контрольный список как критерий контроля качества в ходе расследования.

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

Шаги для исследования

Шаг 1. Определение фишингового сообщения

  1. Получите предположительно фишинговое электронное письмо.

  2. Извлеките идентификатор сообщения из заголовков электронной почты.

  3. Используйте трассировку сообщений для определения:

    • Когда сообщение было получено
    • Какие пользователи получили его
    • Были ли доставлены, заблокированы или помещены в карантин

Шаг 2. Определите круг затронутых пользователей

  1. Определение всех получателей сообщения
  2. Проверьте, удалось ли сообщению обойти фильтры
  3. Определение того, были ли отправлены аналогичные сообщения с помощью вариантов одной кампании

Шаг 3. Оценка взаимодействия с пользователем

  1. Для каждого затронутого пользователя определите, является ли он:

    • Открытие сообщения электронной почты
    • Нажатые ссылки
    • Открытые вложения
    • Отправленные учетные данные

    Сопоставляйте действия электронной почты со следующими параметрами:

    • журналы входа Microsoft Entra
    • Журналы аудита
    • Активность конечной точки (если доступно)

Шаг 4. Определение следующего действия

  1. Если учетные данные могли быть скомпрометированы, проверьте наличие:

    • Подозрительные входы
    • Атака распылением паролей или методом перебора
    • Предоставление согласия OAuth
    • Злоупотребление токенами
    • Необычная активность почтового ящика или совместной деятельности

  2. Если вложения были открыты, проверьте, выполняется ли какая-либо вредоносная программа на конечных точках.

Шаг 5. Локализуйте и устраните

На основе результатов:

  1. Удалите фишинговые сообщения из всех почтовых ящиков. Отключите или сбросьте.
  2. скомпрометированные учетные записи.
  3. Отозвать активные сеансы и токены.
  4. Блокировать вредоносных отправителей, доменов и URL-адресов.
  5. Изоляция или исправление затронутых конечных точек.

Шаг 6. Восстановление

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

Действия восстановления могут включать:

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

Дальнейшие действия

Узнайте больше о дисциплине SecOps.

  • Last updated on