TL;DR
Макс Корбридж (@CorbridgeMax) и Том Эллсон (@tde_sec) из Red Team JUMPSEC недавно обнаружили уязвимость в последней версии Microsoft Teams, которая позволяет рассылать вредоносное ПО в любые организации, использующие Microsoft Teams в конфигурации по умолчанию. Это делается путем обхода элементов управления безопасностью на стороне клиента, которые по-умолчанию не позволяют внешним клиентам отправлять файлы (в данном случае вредоносные программы) сотрудникам вашей организации. JUMPSEC представили подробные варианты решения проблемы, а также возможности для обнаружения атаки.
Введение
Внедрить вредоносное ПО в целевые организации становится все сложнее. Многие традиционные типы пейлоадов (.exe, макросы Office и т. д.) в настоящее время тщательно сканируются и активно определяются различными АВ и по-умолчанию блокируются, что приводит к снижению их эффективности. Средства доставки пейлоадов, такие как фишинг, точно также активно исследуются и мониторятся для усложнения вариантов реализации атак, с помощью которых вредоносные программы злоумышленников могут попасть на устройства конечных пользователей. Инструменты для контроля безопасности почты, черные списки IP-адресов, репутация домена, проверка содержимого HTML-кода электронной почты, любые сторонние продукты для контроля безопасности почты, фильтрация URL-адресов и многие другие защиты обычно должны быть нивелированы, чтобы фишинговая кампания достигла почтового ящика цели.
Поэтому злоумышленники, как и ред тим пентестеры ищут новые и возможно упускаемые из виду способы доставки пейлоадов. Одним из таких новых направлений являются Microsoft Teams External Tenants (внешние аккаунты организаций). Организации, работающие с Microsoft Teams (91% списка Fortune 100 согласно этой статье), обычно используют настройки Microsoft Teams по умолчанию, которые позволяют пользователям вне организации связываться с сотрудниками другой организации. Таким образом создается совершенно новый канал для социальной инженерии (а теперь и доставки пейлоадов, как будет объяснено ниже в нашей статье).
Подробности
Microsoft Teams позволяет любому пользователю с учетной записью Microsoft обращаться к «внешним арендаторам» (external tenancies). Здесь под внешним арендатором (аккаунтом) можно понимать любой бизнес или организацию, использующую Microsoft Teams. Каждая из этих организаций имеет собственную аренду (tenancy) Microsoft, и пользователи из одной аренды (tenancy) могут отправлять сообщения пользователям другой аренды (tenancy). При этом рядом с именем появляется баннер «External», как показано на скриншоте ниже.
Внешний баннер для запроса с входящим сообщением
Как человек, посвятивший много времени классической социальной инженерии (фишинг, вишинг, smshing и т. д.), могу уверить вас, что такой баннер ни в коем случае не помешает нашему шоу. По моему опыту, несмотря на то, что подобный баннер (и последующее всплывающее окно) может отпугнуть некоторые цели, по-прежнему остается значительный процент сотрудников, которые будут нажимать на сообщение от внешнего арендатора и потдверждать последующее предупреждение о том, что пользователь является «внешним». Практически это было доказано мной в прошлом месяце - методы, описанные в данной статье, были успешно использованы для первоначального закрепления в среде клиента в рамках взаимодействия с нашими ред тим пентестерами. Эффективность атаки можно повысить, если злоумышленник выдаст себя за известного члена вашей организации и зарегистрирует домен, имитирующий ваш бренд, как это часто делают ред тим пентестеры в рамках своей стратегии.
Когда вы обмениваетесь сообщениями с сотрудниками другой организации, вы не можете отправлять им файлы, в отличие от членов вашей собственной аренды (tenancy). Ниже вы увидите разницу:
Отправка сообщений члену той же организации
Ограничения на отправку сообщений членам другой организации
Пока в этом нет ничего нового. Однако, имея серьезный опыт в использовании социальной инженерии в прошлом, я начал задаваться вопросом, а можно ли обойти эти ограничения для беспрепятственной доставки пейлоадов непосредственно в почтовый ящик цели в рамках нашей ред тим атаки. Я начал искать ответы в Интернете, и статьи, подобные этой, предполагали, что определенные элементы управления безопасностью фактически реализованы на стороне клиента в Microsoft Teams.
Я обсудил этот вопрос с главой службы безопасности JUMPSEC (Том Эллсон), и не более чем через 10 минут мы обошли ограничения безопасности и смогли отправить файлы в целевую организацию. Эксплуатация уязвимости была простой, используя традиционную технику IDOR для переключения внутреннего и внешнего идентификатора получателя в POST-запросе:
/v1/users/ME/conversations/<RECIPIENT_ID>/messages
Пейлоад успешно доставлен в инбокс жертвы!
Когда мы отправляем пейлоад данным способом, фактически он будет размещаться в домене Sharepoint, и цель будет загружать его оттуда. При этом в целевом почтовом ящике он будет отображаться как файл, а не как ссылка.
Выявив проблему, я хотел убедиться, что эта уязвимость будет работать как способ доставки пейлоада в целевую организацию, и не даст сбой по какой-нибудь неизвестной причине при использовании в реальной клиентской среде. В прошлом месяце я опробовал эту уязвимость, чтобы доставить пейлоад (вредоносное ПО) нашей ред тим C2 непосредственно в почтовый ящик таргета и закрепиться в системе в рамках скрытой ред тим стратегии. Это позволило по итогу создать гораздо более простой, надежный и удобный способ доставки пейлоада, чем традиционные фишинговые рассылки.
Почему это так важно?
Настоящая причина, почему я считаю это потенциально эффективным способом доставки пейлоадов злоумышленниками, заключается в том, что данный метод позволяет обойти почти все современные средства защиты от фишинга, упомянутые в введении нашей статьи.
Во-первых, очень просто купить домен, похожий на домен наших таргет-организаций, и зарегистрировать его в M365. Это позволит избежать необходимости использовать домены с историей, веб-сервера, лендинги, капчи, категоризацию доменов и фильтрацию URL-адресов. Это сэкономит огромное количество времени, так как настройка различных частей инфраструктуры, необходимой для убедительной фишинговой кампании, может стоить несколько дней (или больше) работы для нашей ред тим.
Во-вторых, данный метод позволяет избежать заведомо опасного действия по переходу по ссылке в электронном письме, чему сотрудники многих организаций уже были обучены в течение последних лет, что значительно снижает вероятность того, что типичный сотрудник обнаружит это как фишинговую атаку. Пейлоад теперь будет загружаться с доверенного домена Sharepoint и будет поступать в виде файла в папку «Входящие» нашего таргета. Таким образом, пейлоад будет использовать репутацию Sharepoint домена, а не какого-то случайного вредоносного фишингового веб-сайта.
И наконец, если эта уязвимость успешно сочетается с социальной инженерией через Teams, это позволяет невероятно просто выстроить двусторонний разговор с жертвой, подключаться к вызову, делиться экранами и т. д. Для сравнения, классическая социальная инженерия через обычную электронную почту может оказаться неэффективной и диалог может быстро останавиться. При использовании данного метода в реальной атаке мы под предлогом запроса от ИТ-специалиста просили таргет присоединиться к нашему вызову, чтобы обновить какое-то критическое программное обеспечение. Во время вызова эта уязвимость использовалась для доставки пейлоада, и в сочетании с развернутой атакой социальной инженерии цель безоговорочно доверяла ей.
Последствия
Уязвимость затрагивает каждую организацию, использующую Teams с настройками по умолчанию. Таким образом, атака имеет огромный потенциальный охват и может быть использована злоумышленниками для обхода многих традиционных средств защиты от доставки пейлоадов. Подтвердив нашу гипотезу и использовав эту уязвимость для успешной доставки вредоносного ПО, которое скомпрометировало целевую машину в среде клиента, я считаю, что мы успешно продемонстрировали наш метод как находку, которую можно использовать для реальных атак.
Обнаружение атаки и противодействие ей
Мы сообщили об этой уязвимости в Microsoft и получили от них подтверждение, что уязвимость является реальной, но она «не соответствует критерию для немедленного сервисного обслуживания». Я думаю, что такая реакция - это просто позор, но, тем не менее, она была ожидаемой. Собственно поэтому мы, JUMPSEC, решили добавить данный раздел, чтобы помочь организациям, которые могут быть обеспокоены нашим исследованием.
Во-первых, я настоятельно рекомендую вам проверить, есть ли бизнес-необходимость того, чтобы внешние арендаторы (external tenants) имели возможность отправки сообщений вашему персоналу. Очевидно, что многим бизнесам действительно необходимо взаимодействие с другими организациями, поставщиками услуг и т. д. Однако явно это не относится ко всем компаниям, использующим Teams. Если вы в настоящее время не используете Teams для регулярного общения с внешними арендаторами (external tenants), ужесточите политики безопасности и полностью отключите данную опцию. Это можно сделать в Центре администрирования Microsoft Teams > Внешний доступ (Microsoft Teams Admin Center > External Access).
Если вам требуется связь с внешними контрагентами, но существует лишь несколько организаций, с которыми вы регулярно общаетесь, вы можете изменить параметры безопасности, чтобы разрешить связь только с определенными разрешенными доменами. Это было бы хорошим компромиссом для предотвращения рассмотренной в статье атаки, не влияя при этом на ваши бизнес-операции. Это тоже можно сделать в Центре администрирования Microsoft Teams > Внешний доступ (Microsoft Teams Admin Center > External Access).
Если что-то из вышеперечисленного не сработает в вашем уникальном случае, у вас есть несколько вариантов решения проблемы. Во-первых, постарайтесь регулярно обучать персонал возможностям приложений для повышения производительности, таких как Teams, Slack, Sharepoint и т. д. через кампании социальной инженерии. Электронная почта перестала быть единственным критическим каналом с риском компроментации, и все же, по моему личному мнению, при использовании других альтернативных электронной почте каналов проблема злоупотреблением доверием пользователя остается так же актуальной, в связи с богатой историей, связывающей фишинг и электронные письма.
Что касается обнаружения атаки, в настоящее время Microsoft начинает оказывать ограниченную поддержку затронутым клиентам. Несмотря на наличие логов-журналов Teams (полный список см. здесь: https://learn.microsoft.com/en-us/m...it-teams-audit-log-events?view=o365-worldwide) на текущий момент журналы не включает в себя действия с «Внешними арендаторами, обменивающимися сообщениями с вашим персоналом» (External Tenants Messaging your Staff), как и журналы действий «Сотрудник принимает запрос сообщения от внешнего арендатора» (Staff Member Accepts Message Request from External Tenant). Последняя опция логирования была бы еще предпочтительнее, так как она исключила бы оповещения от ранее известных внешних арендаторов (ваших поставщиков услуг и т. д.) и сосредоточилась бы только на новых запросах сообщений. Я обратился в Microsoft с запросом на включение этих опции в журналы для возможности отслеживать более широкое использование Teams для социальной инженерии. Если вы согласны с моим мнением, что данная опция должна быть доступной, поддержите запрос функции: https://feedbackportal.microsoft.com/feedback/idea/16fe3111-4410-ee11-a81c-000d3a7a48db
Хотя это и не идеальное решение, вы можете воспользоваться логами веб-прокси для оповещения или, что более вероятно, для получения некоторой базовой информации о сотрудниках, принимающих внешние запросы сообщений. В регионе EMEA, когда пользователь Teams принимает запрос сообщения от внешнего клиента, он отправляет запрос POST на уникальный URI, который вы можете отслеживать:
/api/mt/emea/beta/userSettings/acceptlist/manage
URI для приема внешних запросов сообщений
В настоящее время основная трудность заключается в том, как с пользой для себя использовать эту информацию - телеметрию с именами пользователей и рассматриваемым сообщением. Однако мониторинг подобных данных даст вам представление о том, насколько распространена эта угроза для вашей организации, и позволит вам своевременно отреагировать на угрозу, используя рекомендации упомянутые выше, с более полным пониманием вопроса.
Выводы
Как член ред тим, регулярно получающий задания закрепиться в целевой организации, я имею уникальный опыт и понимаю серьезность и актуальность рассмотренной угрозы. С более чем 270 миллионами активных пользователей в месяц Teams невероятно распространена во многих таргет организациях. Группа обнаружения и реагирования JUMPSEC (DART) заметила тенденцию к использованию новых методов фишинга и доставки пейлоадов, встречающихся в реальных атаках, которые включают, помимо прочего, использование внешних арендаторов (External Tenants) Teams для социальной инженерии. Злоумышленники постоянно экспериментируют с новыми атаками социальной инженерии, поэтому организациям необходимо оставаться осведомленными об актуальных угроза, чтобы охватить упущенное из виду при построении своих политик безопасности.
Отказ от ответственности
Информация, представленная в данной статье, должна использоваться только в образовательных целях. Автор никоим образом не несет ответственности за любое неправомерное использование предоставленной информации. Любые действия и/или действия, связанные с материалами, содержащимися в этой статье, являются исключительно вашей ответственностью.
Источник
Рабочие инструменты для активной работы
1. https://github.com/sse-secure-systems/TeamsEnum
Перебор пользователей Microsoft Teams. TeamsEnum — это скрипт Python, который позволяет находить существующих пользователей и их онлайн-статус.Он поддерживает несколько механизмов аутентификации и может использоваться с личными или корпоративными учетными записями.
Статья по использованию: https://medium.com/sse-blog/a-fresh-look-at-user-enumeration-in-microsoft-teams-405d614df70a (возможно позже переведу)
2. https://github.com/Octoberfest7/TeamsPhisher
TeamsPhisher — это программа Python3, которая облегчает доставку фишинговых сообщений и вложений пользователям Microsoft Teams, чьи организации разрешают внешние коммуникации.Обычно невозможно отправлять файлы пользователям Teams за пределами организации. Макс Корбридж (@CorbridgeMax) и Том Эллсон (@tde_sec) из JUMPSEC недавно раскрыли способ обойти это ограничение, манипулируя веб-запросами Teams, чтобы изменить получателя сообщения с прикрепленным файлом.
TeamsPhisher использует этот метод в дополнение к некоторым ранее раскрытым Андреа Сантезе (@Medu554).Он также в значительной степени опирается на TeamsEnum, фантастическую работу Бастиана Канбаха (@bka) из SSE, для части аутентификации потока атаки, а также некоторых общих вспомогательных функций.
TeamsPhisher стремится извлечь лучшее из всех этих проектов и создать надежные, настраиваемые и эффективные средства для авторизованных операций Red Team, чтобы использовать Microsoft Teams для сценариев фишинга для доступа.
Пример атаки ручками, без использования TeamPhisher: https://medium.com/@timmylepp/microsoft-teams-idor-exploit-8f3aa7158ce1 (возможно позже переведу)
3. Обратите пристальное внимание на опубликованною мной ранее статью: https://xss.pro/threads/90615/ (Перебор пользователей-сотрудников компаний через OneDrive)
P. S. Пользуйтесь, метод доживает свое, скоро прикроют
Макс Корбридж (@CorbridgeMax) и Том Эллсон (@tde_sec) из Red Team JUMPSEC недавно обнаружили уязвимость в последней версии Microsoft Teams, которая позволяет рассылать вредоносное ПО в любые организации, использующие Microsoft Teams в конфигурации по умолчанию. Это делается путем обхода элементов управления безопасностью на стороне клиента, которые по-умолчанию не позволяют внешним клиентам отправлять файлы (в данном случае вредоносные программы) сотрудникам вашей организации. JUMPSEC представили подробные варианты решения проблемы, а также возможности для обнаружения атаки.
Введение
Внедрить вредоносное ПО в целевые организации становится все сложнее. Многие традиционные типы пейлоадов (.exe, макросы Office и т. д.) в настоящее время тщательно сканируются и активно определяются различными АВ и по-умолчанию блокируются, что приводит к снижению их эффективности. Средства доставки пейлоадов, такие как фишинг, точно также активно исследуются и мониторятся для усложнения вариантов реализации атак, с помощью которых вредоносные программы злоумышленников могут попасть на устройства конечных пользователей. Инструменты для контроля безопасности почты, черные списки IP-адресов, репутация домена, проверка содержимого HTML-кода электронной почты, любые сторонние продукты для контроля безопасности почты, фильтрация URL-адресов и многие другие защиты обычно должны быть нивелированы, чтобы фишинговая кампания достигла почтового ящика цели.
Поэтому злоумышленники, как и ред тим пентестеры ищут новые и возможно упускаемые из виду способы доставки пейлоадов. Одним из таких новых направлений являются Microsoft Teams External Tenants (внешние аккаунты организаций). Организации, работающие с Microsoft Teams (91% списка Fortune 100 согласно этой статье), обычно используют настройки Microsoft Teams по умолчанию, которые позволяют пользователям вне организации связываться с сотрудниками другой организации. Таким образом создается совершенно новый канал для социальной инженерии (а теперь и доставки пейлоадов, как будет объяснено ниже в нашей статье).
Подробности
Microsoft Teams позволяет любому пользователю с учетной записью Microsoft обращаться к «внешним арендаторам» (external tenancies). Здесь под внешним арендатором (аккаунтом) можно понимать любой бизнес или организацию, использующую Microsoft Teams. Каждая из этих организаций имеет собственную аренду (tenancy) Microsoft, и пользователи из одной аренды (tenancy) могут отправлять сообщения пользователям другой аренды (tenancy). При этом рядом с именем появляется баннер «External», как показано на скриншоте ниже.
Внешний баннер для запроса с входящим сообщением
Как человек, посвятивший много времени классической социальной инженерии (фишинг, вишинг, smshing и т. д.), могу уверить вас, что такой баннер ни в коем случае не помешает нашему шоу. По моему опыту, несмотря на то, что подобный баннер (и последующее всплывающее окно) может отпугнуть некоторые цели, по-прежнему остается значительный процент сотрудников, которые будут нажимать на сообщение от внешнего арендатора и потдверждать последующее предупреждение о том, что пользователь является «внешним». Практически это было доказано мной в прошлом месяце - методы, описанные в данной статье, были успешно использованы для первоначального закрепления в среде клиента в рамках взаимодействия с нашими ред тим пентестерами. Эффективность атаки можно повысить, если злоумышленник выдаст себя за известного члена вашей организации и зарегистрирует домен, имитирующий ваш бренд, как это часто делают ред тим пентестеры в рамках своей стратегии.
Когда вы обмениваетесь сообщениями с сотрудниками другой организации, вы не можете отправлять им файлы, в отличие от членов вашей собственной аренды (tenancy). Ниже вы увидите разницу:
Отправка сообщений члену той же организации
Ограничения на отправку сообщений членам другой организации
Пока в этом нет ничего нового. Однако, имея серьезный опыт в использовании социальной инженерии в прошлом, я начал задаваться вопросом, а можно ли обойти эти ограничения для беспрепятственной доставки пейлоадов непосредственно в почтовый ящик цели в рамках нашей ред тим атаки. Я начал искать ответы в Интернете, и статьи, подобные этой, предполагали, что определенные элементы управления безопасностью фактически реализованы на стороне клиента в Microsoft Teams.
Я обсудил этот вопрос с главой службы безопасности JUMPSEC (Том Эллсон), и не более чем через 10 минут мы обошли ограничения безопасности и смогли отправить файлы в целевую организацию. Эксплуатация уязвимости была простой, используя традиционную технику IDOR для переключения внутреннего и внешнего идентификатора получателя в POST-запросе:
/v1/users/ME/conversations/<RECIPIENT_ID>/messages
Пейлоад успешно доставлен в инбокс жертвы!
Когда мы отправляем пейлоад данным способом, фактически он будет размещаться в домене Sharepoint, и цель будет загружать его оттуда. При этом в целевом почтовом ящике он будет отображаться как файл, а не как ссылка.
Выявив проблему, я хотел убедиться, что эта уязвимость будет работать как способ доставки пейлоада в целевую организацию, и не даст сбой по какой-нибудь неизвестной причине при использовании в реальной клиентской среде. В прошлом месяце я опробовал эту уязвимость, чтобы доставить пейлоад (вредоносное ПО) нашей ред тим C2 непосредственно в почтовый ящик таргета и закрепиться в системе в рамках скрытой ред тим стратегии. Это позволило по итогу создать гораздо более простой, надежный и удобный способ доставки пейлоада, чем традиционные фишинговые рассылки.
Почему это так важно?
Настоящая причина, почему я считаю это потенциально эффективным способом доставки пейлоадов злоумышленниками, заключается в том, что данный метод позволяет обойти почти все современные средства защиты от фишинга, упомянутые в введении нашей статьи.
Во-первых, очень просто купить домен, похожий на домен наших таргет-организаций, и зарегистрировать его в M365. Это позволит избежать необходимости использовать домены с историей, веб-сервера, лендинги, капчи, категоризацию доменов и фильтрацию URL-адресов. Это сэкономит огромное количество времени, так как настройка различных частей инфраструктуры, необходимой для убедительной фишинговой кампании, может стоить несколько дней (или больше) работы для нашей ред тим.
Во-вторых, данный метод позволяет избежать заведомо опасного действия по переходу по ссылке в электронном письме, чему сотрудники многих организаций уже были обучены в течение последних лет, что значительно снижает вероятность того, что типичный сотрудник обнаружит это как фишинговую атаку. Пейлоад теперь будет загружаться с доверенного домена Sharepoint и будет поступать в виде файла в папку «Входящие» нашего таргета. Таким образом, пейлоад будет использовать репутацию Sharepoint домена, а не какого-то случайного вредоносного фишингового веб-сайта.
И наконец, если эта уязвимость успешно сочетается с социальной инженерией через Teams, это позволяет невероятно просто выстроить двусторонний разговор с жертвой, подключаться к вызову, делиться экранами и т. д. Для сравнения, классическая социальная инженерия через обычную электронную почту может оказаться неэффективной и диалог может быстро останавиться. При использовании данного метода в реальной атаке мы под предлогом запроса от ИТ-специалиста просили таргет присоединиться к нашему вызову, чтобы обновить какое-то критическое программное обеспечение. Во время вызова эта уязвимость использовалась для доставки пейлоада, и в сочетании с развернутой атакой социальной инженерии цель безоговорочно доверяла ей.
Последствия
Уязвимость затрагивает каждую организацию, использующую Teams с настройками по умолчанию. Таким образом, атака имеет огромный потенциальный охват и может быть использована злоумышленниками для обхода многих традиционных средств защиты от доставки пейлоадов. Подтвердив нашу гипотезу и использовав эту уязвимость для успешной доставки вредоносного ПО, которое скомпрометировало целевую машину в среде клиента, я считаю, что мы успешно продемонстрировали наш метод как находку, которую можно использовать для реальных атак.
Обнаружение атаки и противодействие ей
Мы сообщили об этой уязвимости в Microsoft и получили от них подтверждение, что уязвимость является реальной, но она «не соответствует критерию для немедленного сервисного обслуживания». Я думаю, что такая реакция - это просто позор, но, тем не менее, она была ожидаемой. Собственно поэтому мы, JUMPSEC, решили добавить данный раздел, чтобы помочь организациям, которые могут быть обеспокоены нашим исследованием.
Во-первых, я настоятельно рекомендую вам проверить, есть ли бизнес-необходимость того, чтобы внешние арендаторы (external tenants) имели возможность отправки сообщений вашему персоналу. Очевидно, что многим бизнесам действительно необходимо взаимодействие с другими организациями, поставщиками услуг и т. д. Однако явно это не относится ко всем компаниям, использующим Teams. Если вы в настоящее время не используете Teams для регулярного общения с внешними арендаторами (external tenants), ужесточите политики безопасности и полностью отключите данную опцию. Это можно сделать в Центре администрирования Microsoft Teams > Внешний доступ (Microsoft Teams Admin Center > External Access).
Если вам требуется связь с внешними контрагентами, но существует лишь несколько организаций, с которыми вы регулярно общаетесь, вы можете изменить параметры безопасности, чтобы разрешить связь только с определенными разрешенными доменами. Это было бы хорошим компромиссом для предотвращения рассмотренной в статье атаки, не влияя при этом на ваши бизнес-операции. Это тоже можно сделать в Центре администрирования Microsoft Teams > Внешний доступ (Microsoft Teams Admin Center > External Access).
Если что-то из вышеперечисленного не сработает в вашем уникальном случае, у вас есть несколько вариантов решения проблемы. Во-первых, постарайтесь регулярно обучать персонал возможностям приложений для повышения производительности, таких как Teams, Slack, Sharepoint и т. д. через кампании социальной инженерии. Электронная почта перестала быть единственным критическим каналом с риском компроментации, и все же, по моему личному мнению, при использовании других альтернативных электронной почте каналов проблема злоупотреблением доверием пользователя остается так же актуальной, в связи с богатой историей, связывающей фишинг и электронные письма.
Что касается обнаружения атаки, в настоящее время Microsoft начинает оказывать ограниченную поддержку затронутым клиентам. Несмотря на наличие логов-журналов Teams (полный список см. здесь: https://learn.microsoft.com/en-us/m...it-teams-audit-log-events?view=o365-worldwide) на текущий момент журналы не включает в себя действия с «Внешними арендаторами, обменивающимися сообщениями с вашим персоналом» (External Tenants Messaging your Staff), как и журналы действий «Сотрудник принимает запрос сообщения от внешнего арендатора» (Staff Member Accepts Message Request from External Tenant). Последняя опция логирования была бы еще предпочтительнее, так как она исключила бы оповещения от ранее известных внешних арендаторов (ваших поставщиков услуг и т. д.) и сосредоточилась бы только на новых запросах сообщений. Я обратился в Microsoft с запросом на включение этих опции в журналы для возможности отслеживать более широкое использование Teams для социальной инженерии. Если вы согласны с моим мнением, что данная опция должна быть доступной, поддержите запрос функции: https://feedbackportal.microsoft.com/feedback/idea/16fe3111-4410-ee11-a81c-000d3a7a48db
Хотя это и не идеальное решение, вы можете воспользоваться логами веб-прокси для оповещения или, что более вероятно, для получения некоторой базовой информации о сотрудниках, принимающих внешние запросы сообщений. В регионе EMEA, когда пользователь Teams принимает запрос сообщения от внешнего клиента, он отправляет запрос POST на уникальный URI, который вы можете отслеживать:
/api/mt/emea/beta/userSettings/acceptlist/manage
URI для приема внешних запросов сообщений
В настоящее время основная трудность заключается в том, как с пользой для себя использовать эту информацию - телеметрию с именами пользователей и рассматриваемым сообщением. Однако мониторинг подобных данных даст вам представление о том, насколько распространена эта угроза для вашей организации, и позволит вам своевременно отреагировать на угрозу, используя рекомендации упомянутые выше, с более полным пониманием вопроса.
Выводы
Как член ред тим, регулярно получающий задания закрепиться в целевой организации, я имею уникальный опыт и понимаю серьезность и актуальность рассмотренной угрозы. С более чем 270 миллионами активных пользователей в месяц Teams невероятно распространена во многих таргет организациях. Группа обнаружения и реагирования JUMPSEC (DART) заметила тенденцию к использованию новых методов фишинга и доставки пейлоадов, встречающихся в реальных атаках, которые включают, помимо прочего, использование внешних арендаторов (External Tenants) Teams для социальной инженерии. Злоумышленники постоянно экспериментируют с новыми атаками социальной инженерии, поэтому организациям необходимо оставаться осведомленными об актуальных угроза, чтобы охватить упущенное из виду при построении своих политик безопасности.
Отказ от ответственности
Информация, представленная в данной статье, должна использоваться только в образовательных целях. Автор никоим образом не несет ответственности за любое неправомерное использование предоставленной информации. Любые действия и/или действия, связанные с материалами, содержащимися в этой статье, являются исключительно вашей ответственностью.
Источник
Рабочие инструменты для активной работы
1. https://github.com/sse-secure-systems/TeamsEnum
Перебор пользователей Microsoft Teams. TeamsEnum — это скрипт Python, который позволяет находить существующих пользователей и их онлайн-статус.Он поддерживает несколько механизмов аутентификации и может использоваться с личными или корпоративными учетными записями.
Статья по использованию: https://medium.com/sse-blog/a-fresh-look-at-user-enumeration-in-microsoft-teams-405d614df70a (возможно позже переведу)
2. https://github.com/Octoberfest7/TeamsPhisher
TeamsPhisher — это программа Python3, которая облегчает доставку фишинговых сообщений и вложений пользователям Microsoft Teams, чьи организации разрешают внешние коммуникации.Обычно невозможно отправлять файлы пользователям Teams за пределами организации. Макс Корбридж (@CorbridgeMax) и Том Эллсон (@tde_sec) из JUMPSEC недавно раскрыли способ обойти это ограничение, манипулируя веб-запросами Teams, чтобы изменить получателя сообщения с прикрепленным файлом.
TeamsPhisher использует этот метод в дополнение к некоторым ранее раскрытым Андреа Сантезе (@Medu554).Он также в значительной степени опирается на TeamsEnum, фантастическую работу Бастиана Канбаха (@bka) из SSE, для части аутентификации потока атаки, а также некоторых общих вспомогательных функций.
TeamsPhisher стремится извлечь лучшее из всех этих проектов и создать надежные, настраиваемые и эффективные средства для авторизованных операций Red Team, чтобы использовать Microsoft Teams для сценариев фишинга для доступа.
Пример атаки ручками, без использования TeamPhisher: https://medium.com/@timmylepp/microsoft-teams-idor-exploit-8f3aa7158ce1 (возможно позже переведу)
3. Обратите пристальное внимание на опубликованною мной ранее статью: https://xss.pro/threads/90615/ (Перебор пользователей-сотрудников компаний через OneDrive)
P. S. Пользуйтесь, метод доживает свое, скоро прикроют
Последнее редактирование:
