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

  • 🚨 Ещё можно успеть на курс «OSINT: технология боевой разведки» от Академии Кодебай

    🔍 Изучите методы разведки с использованием открытых источников (OSINT) для проведения успешных атак.
    🛠️ Освойте ключевые инструменты, такие как Maltego, TheHarvester и другие.
    🧪 Пройдите практические лабораторные работы, имитирующие реальную разведку.
    🧠 Развивайте навыки, которые помогут вам стать экспертом в области информационной безопасности.

    Запись открыта до 23 мая Подробнее о курсе ...

Microsoft Entra sign-in log activity(реагирование на session hijacking)

Samr

New member
01.01.2023
2
0
Привет всем! Заметил, что в последнее время происходит много атак по вектору session hijacking в Microsoft. Мне стало интересно, и я начал анализировать логи, которые фиксируются в sign-in logs, когда кто-то заходит под куки другого пользователя. Ломал голову, как можно эффективно обнаружить такие атаки в крупной компании, чтобы правило работало с минимальным количеством ложных срабатываний, но так и не смог придумать решение. Возможно, у кого-то есть идеи или полезные статьи на эту тему? Буду признателен за любую помощь!
 
Привет! Session hijacking в Microsoft – это больной вопрос, особенно когда речь идет о больших объемах логов в крупных компаниях. Понимаю твою задачу: хочется создать правила, которые сразу дают точное попадание, но не шумят ложными срабатываниями, особенно когда вся сессия может казаться легитимной.

Вот несколько идей, как можно подойти к этой задаче:

1. Анализ геолокации и IP-адресов:​

Если пользователь вдруг резко перемещается по миру, это сразу вызывает подозрения. Например, если он заходит из Лондона, а через 10 минут – из Нью-Йорка, скорее всего, это признак атаки. В больших компаниях подобные сценарии особенно полезны.

Что сделать:​

  • Настроить мониторинг аномалий на основе геолокации.
  • Сравнивать время между сессиями и разницу в геолокации.
  • Исключить VPN-подключения, которые могут замаскировать реальную геолокацию.

2. Уровень привилегий сессии:​

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

Что сделать:​

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

3. Анализ User-Agent:​

Если сессия пользователя начинается на Chrome с macOS, а затем переключается на Firefox с Windows в течение короткого времени, это явный индикатор того, что кто-то мог захватить сессию.

Что сделать:​

  • Внедрить отслеживание всех изменений User-Agent для каждой сессии.
  • Сравнивать их с типичными для этого пользователя паттернами.

4. Анализ cookie-based аутентификации:​

Если куки действительны слишком долго или используются из разных мест, это тоже может быть тревожным сигналом. В Microsoft ты можешь внедрить алерты на основе анализа cookie-атрибутов.

Что сделать:​

  • Анализировать время жизни cookies и выявлять слишком длинные сессии.
  • Настроить автологин сессий после определенных временных интервалов или после изменения IP-адреса.

5. Интеграция с SIEM и ML-алгоритмы:​

Для минимизации ложных срабатываний можно интегрировать данные из sign-in logs с системой безопасности, которая использует machine learning для выявления аномалий. Такие системы учатся на паттернах поведения пользователей и помогают отличить легитимное поведение от подозрительного.

Что сделать:​

  • Настроить интеграцию с SIEM (например, Splunk, QRadar или Azure Sentinel) для корреляции данных из различных источников.
  • Использовать ML-алгоритмы для обнаружения аномалий на основе поведения пользователя.

6. Дополнительная двухфакторная аутентификация (2FA):​

Хотя это не поможет в обнаружении hijacking в логи, это один из лучших способов предотвращения атак на этапе захвата сессии. Если видишь подозрительную активность, можно требовать дополнительного подтверждения.

ChatGPT
 
Привет! Session hijacking в Microsoft – это больной вопрос, особенно когда речь идет о больших объемах логов в крупных компаниях. Понимаю твою задачу: хочется создать правила, которые сразу дают точное попадание, но не шумят ложными срабатываниями, особенно когда вся сессия может казаться легитимной.

Вот несколько идей, как можно подойти к этой задаче:

1. Анализ геолокации и IP-адресов:​

Если пользователь вдруг резко перемещается по миру, это сразу вызывает подозрения. Например, если он заходит из Лондона, а через 10 минут – из Нью-Йорка, скорее всего, это признак атаки. В больших компаниях подобные сценарии особенно полезны.

Что сделать:​

  • Настроить мониторинг аномалий на основе геолокации.
  • Сравнивать время между сессиями и разницу в геолокации.
  • Исключить VPN-подключения, которые могут замаскировать реальную геолокацию.

2. Уровень привилегий сессии:​

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

Что сделать:​

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

3. Анализ User-Agent:​

Если сессия пользователя начинается на Chrome с macOS, а затем переключается на Firefox с Windows в течение короткого времени, это явный индикатор того, что кто-то мог захватить сессию.

Что сделать:​

  • Внедрить отслеживание всех изменений User-Agent для каждой сессии.
  • Сравнивать их с типичными для этого пользователя паттернами.

4. Анализ cookie-based аутентификации:​

Если куки действительны слишком долго или используются из разных мест, это тоже может быть тревожным сигналом. В Microsoft ты можешь внедрить алерты на основе анализа cookie-атрибутов.

Что сделать:​

  • Анализировать время жизни cookies и выявлять слишком длинные сессии.
  • Настроить автологин сессий после определенных временных интервалов или после изменения IP-адреса.

5. Интеграция с SIEM и ML-алгоритмы:​

Для минимизации ложных срабатываний можно интегрировать данные из sign-in logs с системой безопасности, которая использует machine learning для выявления аномалий. Такие системы учатся на паттернах поведения пользователей и помогают отличить легитимное поведение от подозрительного.

Что сделать:​

  • Настроить интеграцию с SIEM (например, Splunk, QRadar или Azure Sentinel) для корреляции данных из различных источников.
  • Использовать ML-алгоритмы для обнаружения аномалий на основе поведения пользователя.

6. Дополнительная двухфакторная аутентификация (2FA):​

Хотя это не поможет в обнаружении hijacking в логи, это один из лучших способов предотвращения атак на этапе захвата сессии. Если видишь подозрительную активность, можно требовать дополнительного подтверждения.

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

Давай попробуем развернуть тему с точки зрения того, что может быть уловлено:

1. Отсутствие новой аутентификации при смене клиента или контекста:​

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

Признаки:​

  • User-Agent или IP-адрес изменились, но не было нового запроса на аутентификацию.
  • В логе отсутствует MFA (если настроена двухфакторка) или запрос токена обновления.
Это может указывать на захват сессии через куки без повторной аутентификации пользователя.

2. Аномалии в токенах доступа:​

В некоторых случаях можно уловить аномалии, связанные с токенами OAuth или SAML, которые не должны быть использованы повторно. Если куки с токенами были скомпрометированы, злоумышленник может пытаться использовать устаревший или украденный токен без повторной валидации.

Признаки:​

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

3. Отсутствие или подделка заголовков (Headers):​

Если злоумышленник перехватывает сессию через сеть (например, через XSS или MITM), можно увидеть нестандартное поведение в заголовках HTTP-запросов. Например, если не совпадает заголовок реферера или отсутствуют заголовки с данными аутентификации, но сессия продолжается.

Признаки:​

  • Недостаток заголовков (например, рефереров) или их подделка.
  • Аномальные значения в Cookies — если структура куки меняется, это может быть признаком вмешательства.

4. Паттерны поведения пользователя:​

Пожалуй, один из самых тонких моментов. Если сессия внезапно переходит в аномальное поведение, которое не характерно для этого пользователя — например, скачивание большого объема данных, доступ к новым ресурсам или использование привилегий, — это может быть сигналом к захвату сессии.

Признаки:​

  • Смена типа запросов в рамках одной сессии: от простого чтения данных до массового скачивания.
  • Использование привилегий, которые не использовались ранее в этой сессии или которые нетипичны для пользователя.

5. Аномалии в механизмах продления сессии (Refresh tokens):​

Если кто-то захватывает сессию и использует украденный токен, это может быть видно в логах как неожиданное продление сессии. Например, система видит продление токена без сопутствующего запроса на обновление.

Признаки:​

  • Использование устаревшего токена для продления сессии.
  • Аномальные запросы на продление сессии с нового IP-адреса или устройства.

Как это зафиксировать:​

  • Логи аутентификации (например, Azure AD sign-in logs): отфильтровать запросы, где не было явного входа в систему, но произошло действие в рамках сессии.
  • Логи токенов (OAuth или SAML): найти запросы, где токен использовался повторно без обновления или выдачи нового.
  • Журнал HTTP-запросов: просмотреть аномалии в заголовках или отсутствие ключевых заголовков.
Если говорить о технических решениях, то большинство SIEM-систем могут отслеживать такие аномалии. Например, в Azure Sentinel можно настроить анализ корреляции токенов, IP-адресов и поведения пользователей. Также можно использовать машинное обучение для выявления аномалий в паттернах доступа.

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

ChatGPT


P.s какой общий был вопрос - такой общий и ответ. Придираться не к чему, стандарт на стандарт.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Курс AD