Как обнаружить кражу сеанса, если сотрудник уже прошёл MFA
Сотрудник может пройти многофакторную аутентификацию, а злоумышленник впоследствии воспользоваться его уже аутентифицированным сеансом. MFA добавляет к проверке пароля другой фактор подтверждения входа. Однако успешная проверка при входе не доказывает, что каждое последующее действие выполняет тот же человек: активный cookie сеанса может быть украден и использован для доступа.
Сеанс связывает работу пользователя с приложением после аутентификации. Для проверки подозрения на его кражу нужно установить, какие действия связаны с этим сеансом, и сравнить их с обычной активностью сотрудника. В Microsoft Entra и Microsoft 365 одним из ориентиров служит Session ID, идентификатор сеанса: он позволяет сопоставлять события входа с действиями в доступных журналах сервисов.
Отсутствие нового запроса MFA само по себе не указывает на атаку. Уже аутентифицированный сеанс может продолжать легитимную работу без повторной проверки. Подозрение возникает из совокупности событий и их контекста, а возможность проследить эту связь зависит от наличия журналов и нужных полей.
Что даёт украденный сеанс
Пароль, токен и cookie выполняют разные функции. Пароль предъявляют при аутентификации. Токен представляет выданные после неё данные доступа. Cookie сеанса позволяет приложению использовать уже аутентифицированный сеанс при дальнейших обращениях. Для расследования существенна разница между новым входом и использованием доступа, который уже был предоставлен.
При повторном использовании активного cookie злоумышленник получает возможность работать через такой сеанс. Поэтому некоторые проверки MFA, выполненные при исходной аутентификации, не становятся препятствием для последующего использования украденного cookie. Этот механизм нельзя переносить на все виды MFA и любые способы защиты сеансов.
Проверять нужно не только факт успешного входа. Необычное местоположение или признаки другого устройства в сочетании с использованием сеанса дают повод изучить связанную активность. При этом отсутствие новой проверки учётных данных ещё не отличает злоумышленника от сотрудника, который продолжает обычную работу. Для такого различения нужны события сервисов и пользовательский контекст.
Как связать вход и действия по Session ID
Журнал входов показывает события аутентификации, а журналы сервисов позволяют изучить действия с ресурсами. Session ID помогает связать эти части расследования. В Microsoft Entra можно начать с идентификатора сеанса из журнала входов и искать соответствующие события в журналах аудита Exchange Online или активности Microsoft Graph.
Порядок проверки зависит от того, какие данные доступны в вашей среде:
- Найдите событие входа, связанное с подозрением, и проверьте, содержит ли оно Session ID. Сохраните связь идентификатора с исходным событием, чтобы последующая проверка относилась к тому же сеансу.
- Убедитесь, что у вас есть доступ к нужным журналам Microsoft 365 и что их события содержат идентификаторы, позволяющие сопоставление. Нельзя заранее рассчитывать на наличие всех полей в каждом событии.
- Сопоставьте Session ID с доступными событиями Exchange Online или Microsoft Graph. Изучите, какие действия оказались связаны с рассматриваемым сеансом. Проверка должна опираться на найденные события, а не на предположение, что любой доступ пользователя относится к подозрительному входу.
- Сравните связанную активность с обычной работой сотрудника и другими оповещениями. Совпадение идентификатора помогает восстановить связь событий; оценка их легитимности требует отдельной проверки.
Если нужного журнала или идентификатора нет, этот путь расследования остаётся неполным. Пустой результат сопоставления в таком случае не подтверждает безопасность сеанса: для вывода не хватает данных. По той же причине наличие нескольких связанных событий не означает, что удалось увидеть все действия.
Session ID отвечает на вопрос о связи событий. Само поле не устанавливает, кто фактически использовал сеанс и с какой целью. Эти выводы нельзя получить только из совпадения значений в двух журналах.
Какие данные подтверждают подозрение
Связанные события нужно оценить по нескольким признакам. Проверьте приложение, устройство, IP-адрес, местоположение и User Agent. Последнее поле описывает клиентское программное обеспечение, например браузер, с которым связано обращение. Сравните эти свойства с обычной активностью пользователя и изучите связанные оповещения в доступных средствах безопасности. Отдельное отличие даёт вопрос для проверки, но ещё не готовый ответ о захвате.
Для необычной географии найдите возможное нормальное объяснение. Разрешённый корпоративный VPN, через который пользователь подключается к сервисам, может менять наблюдаемый адрес и местоположение входа. Подтверждённая поездка также может объяснять перемещение. В обоих случаях требуется проверить конкретное объяснение: предположение о VPN или поездке не закрывает расследование.
Оценка должна связывать исходный вход, действия сеанса и проверенный контекст сотрудника. Если контекст объясняет наблюдения, это необходимо учесть при оценке подозрения. Если связанные действия и свойства доступа остаются необъяснёнными, оснований для дальнейшей проверки больше. Ни непривычная география, ни отсутствие повторной MFA, ни один Session ID не заменяют эту совокупность данных.
Вывод по результатам проверки
Для обнаружения использования украденного сеанса после MFA полезен следующий результат расследования: вы понимаете, какие события удалось связать, какие действия они показывают и чем они отличаются от подтверждённой обычной работы пользователя. В Entra и Microsoft 365 Session ID помогает перейти от события входа к активности сервисов, а проверка контекста позволяет оценить найденную связь.
Если журналы неполны или объяснение активности не подтверждено, сохраните эту неопределённость в выводе. Успешная исходная MFA не исключает кражу активного cookie, но и подозрительный признак не доказывает её. Следующий шаг определяется тем, чего именно не хватает для оценки: связанных событий, доступных идентификаторов или проверенного объяснения действий сотрудника.
