Эта публикация представляет собой сборник различных распространённых сценариев атак на Microsoft Entra ID (ранее известный как Azure Active Directory), а также способов их смягчения или обнаружения.
Эта публикация представляет собой сборник различных распространённых сценариев атак на Microsoft Entra, а также способов их смягчения или обнаружения. Все включённые сценарии, выводы и комментарии основаны на опыте участников, полученном во время симуляций атак, практических занятий и реальных сценариев.
Его следует рассматривать как живой документ, который будет обновляться по мере развития практик и изменений в техниках атак и защиты. Мы приглашаем экспертов по идентификации и безопасности из сообщества к совместной работе над этой публикацией и внесению обновлений, отзывов, комментариев или дополнений.
Во всех главах мы следуем единому принципу структуры. При чтении вы можете рассчитывать на следующее:
В следующих разделах приведено краткое описание каждой главы, которую вы найдёте в «Entra ID Attack & Defense Playbook».
Первоначальная идея создания «Azure AD Attack & Defense Playbook» принадлежит Томасу Наунхайму (Thomas Naunheim). Наш первый звонок в Teams состоялся примерно осенью 2020 года, когда Томас представил эту идею, и она сразу же была принята.
Первая глава была посвящена атаке «Password Spray», где мы уделили большое внимание механизму обнаружения Entra ID Protection (ранее известной как Azure AD Identity Protection) для выявления атак типа «password spray». В ходе работы над первой главой мы поняли, что календарное время на завершение исследования может оказаться значительно больше ожидаемого из-за сложности исследования и различных его аспектов. Определение рамок, как и в любой проектной работе, чрезвычайно важно.
При работе над последними главами нам посчастливилось привлечь к проекту других участников сообщества, таких как Joosua Santasalo, Fabian Bader и Christopher Brumm, в качестве спарринг-партнёров и рецензентов.
Фреймворк MITRE ATT&CK широко используется для сопоставления тактик, техник и процедур (TTP) с действиями злоумышленников и моделирования защиты в организациях по всему миру. В этом плейбуке мы используем фреймворк MITRE ATT&CK v11 во всех главах для сопоставления техник, тактик и процедур (TTP) со сценариями атак. Это поможет синим командам (Blue Teams) выстраивать защиту для соответствующих сценариев.
Вы можете рассчитывать на множество правил обнаружения в отдельных главах, основанных на конкретном сценарии атаки. Поскольку плейбук содержит большое количество правил обнаружения, мы решили создать визуализацию, содержащую все сценарии атак, сопоставленные с TTP. Также учтите, что каждая отдельная глава содержит визуализацию для соответствующего сценария атаки.
Открыть в MITRE ATT&CK Navigator
Соответствующие возможности обнаружения продуктов Microsoft Security (Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, Microsoft Defender for Cloud) будут рассмотрены в части обнаружения сценариев атак. Пользовательские шаблоны правил для Microsoft Sentinel, разработанные для плейбука, также сопоставлены с TTP. Правила обнаружения доступны в виде шаблона правила Microsoft Sentinel (готового к развёртыванию) в формате JSON (ARM Template) здесь.
Открыть в MITRE ATT&CK Navigator
Примечание: мы использовали существующее сопоставление TTP из шаблонов правил Microsoft Sentinel и корреляции инцидентов Microsoft 365. Некоторые средства обнаружения не обеспечивают полного покрытия MITRE ATT&CK и поэтому не включены в эту визуализацию.
Как правило, на одну главу уходило примерно 1–2 месяца календарного времени, поэтому сбор всех четырёх (4) глав и приложения потребовал немалых усилий. За последние два (2) года мы провели исследования по следующим сценариям:
«Атака Password Spray — это атака, при которой множество имён пользователей атакуется с использованием распространённых паролей в единообразном порядке перебора с целью получения несанкционированного доступа».
Глава была первоначально создана в ноябре 2020 года и обновлена в ноябре 2021 года, чтобы включить последние обновления продуктов безопасности с Microsoft Ignite 2021.
Глава содержит краткое описание атаки и инструментов, используемых для имитации атаки типа password spray. В части обнаружения использованы несколько решений безопасности Microsoft, такие как Microsoft Sentinel и Defender for Cloud Apps.
В примечаниях также есть некоторые соображения, касающиеся локальной среды и ADFS, если они всё ещё используются.
Подбор паролей (Password Spray)
«При атаке с незаконным предоставлением согласия (illicit consent grant) злоумышленник создаёт зарегистрированное в Azure приложение, которое запрашивает доступ к таким данным, как контактная информация, электронная почта или документы. Затем злоумышленник обманом заставляет конечного пользователя предоставить этому приложению согласие на доступ к его данным — либо с помощью фишинговой атаки, либо путём внедрения вредоносного кода на доверенный веб-сайт. После предоставления согласия вредоносному приложению оно получает доступ к данным на уровне учётной записи без необходимости использования организационной учётной записи.
Обычные меры по устранению последствий, такие как сброс паролей для скомпрометированных учётных записей или требование многофакторной аутентификации (MFA) для учётных записей, неэффективны против атак этого типа, поскольку эти приложения являются сторонними и внешними по отношению к организации. Эти атаки используют модель взаимодействия, которая предполагает, что сущность, запрашивающая информацию, является автоматизацией, а не человеком».*
Глава содержит описание атаки и объяснение того, почему важно защищать и контролировать действия, связанные с фреймворком согласий Entra ID. В разделе об обнаружении мы использовали следующие решения:
Поскольку тема обширна и сложна, раздел о смягчении последствий содержит инструкции и подробности о том, как уменьшить поверхность атаки в вашей среде.
В следующих двух сценариях атак мы сосредоточили внимание на привилегированных субъектах-службах (service principals) в составе конвейеров выпуска (release pipelines) Azure DevOps (ADO) и (потенциально) ограниченной видимости при аудите.
ADO — обширная тема, и в этой главе рамки ограничены только упомянутыми выше сценариями. Здесь применяется тот же подход:
Работая над этой главой, мы потратили много времени на методы обнаружения, что было непросто главным образом из-за схемы журнала аудита ADO. Тем не менее, упорный труд окупается, и мы смогли достичь поставленной цели и обнаруживать атаки в Microsoft Sentinel.
Глава содержит углублённую информацию о том, как защитить среду Azure DevOps, в разделе о смягчении последствий.
В этой статье мы в основном сосредоточены на следующем сценарии:
Вне рамок находятся повышение привилегий и пути атак с сервера AADC в направлении Active Directory (включая злоупотребление учётной записью коннектора Azure AD DS)
Последняя глава, выпущенная 14 марта 2022 года, полностью посвящена злоупотреблению учётной записью службы синхронизации Microsoft Entra Connect. Если быть точным, учётная запись AAD Connect отвечает за выполнение действий на стороне Azure AD.
Тема и сценарий атаки были чрезвычайно интересны для исследовательской работы, и хотя в прошлом я много работал с Microsoft Entra Connect, должен признать, что за последние два (2) месяца я узнал много нового. Мы сделали несколько интересных находок, которых раньше не замечали.
Если вы дочитали до этого места, рекомендую вам ознакомиться с KQL-запросами для Microsoft Sentinel, которые мы создали в ходе нашей исследовательской работы.
Microsoft представила Windows 11 с требованием использования чипа Trusted Platform Module (TPM). Это значительно расширило возможности использования функций безопасности ОС Windows 11, включая дополнительный уровень защиты для сценариев облачной аутентификации. Первичный маркер обновления (Primary Refresh Token, PRT) и другие соответствующие ключи могут быть надёжно защищены с помощью TPM в Windows 11, а также в Windows 10 и Windows Server версий 2016 и выше. С учётом этого в данной статье мы в основном сосредоточены на следующих сценариях:
Назначение анализатора конфигурации безопасности Entra ID — предоставить решение, которое извлекает конфигурацию безопасности Entra ID из выбранных конечных точек Microsoft Graph API и загружает данные в Log Analytics. Для визуализации данных используется Azure Workbook, а Microsoft Sentinel может использоваться для создания оповещений/инцидентов при обнаружении критического изменения конфигурации.
На следующем рисунке описана архитектура решения EIDSCA, используемые решения и потоки данных:
Эталонная архитектура интеграции EIDSCA в среду Microsoft Sentinel. Данные будут загружаться в то же рабочее пространство, что и Sentinel. Интеграция с выделенным, операционным или существующим рабочим пространством Sentinel зависит от вашей реализации и проекта.
Контроли EIDSCA также используются в Maester, дополнительная информация в документации Maester
Различные маркеры играют решающую роль в облачной аутентификации. Поэтому важно понимать их механику и то, как злоумышленники могут воспользоваться ими, если они попадут не в те руки. Понимание этого может помочь в построении защиты от атак на идентификацию.
Кража маркеров происходит, когда злоумышленник получает доступ к маркерам и компрометирует их. После кражи злоумышленник может воспроизвести украденные маркеры и получить доступ к скомпрометированной учётной записи. В сценарии AiTM злоумышленник может обойти требование MFA, поскольку утверждения MFA уже включены в маркер, и требования аутентификации выполнены. Поэтому злоумышленник получает доступ к среде. Мы подробно расскажем о сценарии, обнаружении и смягчении последствий далее в этой статье.
Чтобы получить дополнительную информацию о маркерах безопасности Entra ID, обратитесь к следующим ресурсам Microsoft Learn:
Глава «Entra ID Attack & Defense Playbook» «Воспроизведение первичного маркера обновления (PRT) и других выданных маркеров с устройства, присоединённого к Azure AD» проливает свет на воспроизведение PRT, маркера доступа и маркера обновления:
В этой главе мы сосредоточены на атаке типа «злоумышленник посередине» (Adversary-in-the-Middle, AiTM), при которой злоумышленник перехватывает сеансовый cookie жертвы и впоследствии воспроизводит его для доступа к службе входа в систему.
Киберпреступники в настоящее время используют фишинговые техники AiTM для обхода защиты многофакторной аутентификации (MFA) в больших масштабах. Эти продвинутые техники демократизируются и распространяются благодаря экономической модели киберпреступности «фишинг-как-услуга» (PhaaS), которая породила множество сервисных предложений с 2021 года.
В настоящее время число PhaaS-платформ с поддержкой AiTM продолжает расти на протяжении 2023–2024 годов: ранее существовавшие сервисы добавляют возможности AiTM на свои платформы, а вновь созданные сервисы изначально включают фишинговые техники AiTM. Хотя традиционные формы фишинга учётных данных по-прежнему существуют, число фишинговых атак AiTM превышает число атак без этой возможности.
Конечная цель фишинга AiTM — кража учётных данных пользователей и сеансовых cookie. Браузеры хранят сеансовые cookie, чтобы пользователи могли получать доступ к сервисам без повторной аутентификации. Фишинг AiTM нацелен на сеансовые cookie и учётные данные, чтобы обойти традиционные средства защиты MFA.
Дополнительная информация о PhaaS:
Каждый современный веб-сервис реализует сеанс работы с пользователем после успешной аутентификации, чтобы пользователю не приходилось проходить аутентификацию на каждой новой странице, которую он посещает. Эта функция сеанса обеспечивается файлом cookie сеанса, который выдается службой аутентификации после первоначальной аутентификации. Файл cookie сеанса служит для веб-сервера доказательством того, что пользователь прошел аутентификацию и поддерживает активный сеанс на веб-сайте.
При фишинговой атаке AiTM злоумышленник перехватывает файл cookie сеанса целевого пользователя, а затем повторно использует его для доступа к службе входа. Поскольку файл cookie демонстрирует, что проверка MFA уже была пройдена (утверждение включено в токен), он удовлетворяет требованию MFA, что позволяет злоумышленнику обойти защиту MFA и получить доступ к скомпрометированной учетной записи пользователя.
При фишинге AiTM через обратный прокси-сервер прокси развертывается между пользователем и легитимным веб-сайтом или приложением, которое пользователь хочет посетить (например, порталы входа Microsoft или LinkedIn). Обратный прокси-сервер пересылает запросы от пользователя к фактическому сервису и перехватывает ответы. Такая настройка позволяет злоумышленнику похищать и перехватывать пароль цели и файл cookie сеанса, который подтверждает их текущий и аутентифицированный сеанс с веб-сайтом.
Среди злоумышленников популярны такие фишинговые наборы, как: EvilGinx, Modlishka, Muraena и «Office 365» (EvilProxy). Эти фишинговые наборы позволяют злоумышленникам проводить фишинговые атаки AiTM с использованием серверов обратного прокси.
Примечание: во многих кампаниях целевым приложением в журналах Entra ID было OfficeHome.
Схема атаки фишинга AiTM через обратный прокси-сервер (исходный рисунок из отчетов Microsoft Defender XDR Threat Intelligence).
Другой метод AiTM называется «фишинг AiTM через синхронное реле». При таком типе атаки цели показывается копия или имитация страницы входа, как и при традиционных фишинговых атаках. Если пользователь вводит свои учетные данные на этой странице, они сохраняются на сервере, контролируемом злоумышленником, где установлен экземпляр фишингового набора, включая его административную панель. По сути, это означает, что данные пользователя похищаются, включая учетные данные для входа, коды двухфакторной аутентификации (MFA) и файлы cookie сеанса.
Серверы ретрансляции обычно предоставляются и контролируются группой субъектов, стоящей за разработкой, и ответственными заинтересованными сторонами платформы PhaaS. Одним из примеров такой группы является Storm-1295, которая стоит за платформой Greatness PhaaS, согласно отчетам Microsoft Threat Intelligence.
Схема фишинга AiTM через синхронное реле (исходный рисунок из отчетов Microsoft Defender XDR Threat Intelligence).
Обновление или новый контент (Pull Request): Как уже упоминалось, мы хотим иметь живой документ, который развивается силами сообщества Entra! Делитесь своими результатами и идеями в рамках этого проекта! Отправьте pull request, чтобы добавить свой контент в этот проект.
Проблемы/Устаревший контент: Функции защиты и инструменты постоянно меняются. Обновите устаревший контент (в рамках pull request) или создайте issue, чтобы указать на него.
Ревьюер: Мы также ищем экспертов, которые хотят рецензировать или обсуждать существующий или новый контент перед публикацией!
Обратная связь: Не стесняйтесь предлагать сценарии атак/защиты, которые могут быть интересны сообществу. Мы добавим их в бэклог и коллекцию идей!
Это проект, управляемый сообществом, а не официальное решение или продукт. Код или любой другой пример запроса предоставляется «КАК ЕСТЬ» без каких-либо гарантий, явных или подразумеваемых, включая, помимо прочего, подразумеваемые гарантии товарной пригодности и/или пригодности для определенной цели. Этот пример не поддерживается ни в рамках какой-либо программы или услуги поддержки. Мы дополнительно отказываемся от всех подразумеваемых гарантий, включая, без ограничений, любые подразумеваемые гарантии товарной пригодности или пригодности для определенной цели. Весь риск, связанный с использованием или производительностью примера и документации, остается на вас. Ни при каких обстоятельствах мы, авторы или кто-либо еще, участвовавшие в создании, производстве или поставке сценария, не несем ответственности за любой ущерб (включая, без ограничений, убытки от потери деловой прибыли, прерывания деловой активности, потери деловой информации или другие финансовые потери), возникший в результате использования или невозможности использования примера или документации, даже если Microsoft была уведомлена о возможности такого ущерба.
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
