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

Теперь, когда организации переходят на Microsoft 365 такими быстрыми темпами, мы видим новый вектор атаки — приложения Azure.

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

После того, как злоумышленник убедит жертву установить вредоносное приложение Azure, он сможет выяснить, к какой организации принадлежит жертва, получить доступ к файлам жертвы, прочитать ее электронные письма, отправить электронные письма от имени жертвы (отлично подходит для внутренней фишинг-атаки) и в целом намного больше.

Что такое приложения Azure?

Microsoft создала службу приложений Azure, чтобы дать пользователям возможность создавать собственные облачные приложения, которые могут вызывать и использовать API-интерфейсы и ресурсы Azure. Это упрощает создание мощных настраиваемых программ, интегрируемых с экосистемой Microsoft 365.

Одним из наиболее распространенных API в Azure является MS Graph API. Этот API позволяет приложениям взаимодействовать с окружением пользователя, а именно: пользователями, группами, документами OneDrive, почтовыми ящиками Exchange Online и чатами.

Подобно тому, как ваш телефон под управлением iOS будет спрашивать вас, можно ли разрешить приложению доступ к вашим контактам или местоположению, Azure попросит предоставить приложению доступ к необходимым ресурсам. Очевидно, злоумышленник может использовать эту возможность, чтобы обманным путем дать приложению доступ к одному или нескольким конфиденциальным облачным ресурсам.

Как устроена атака

Чтобы выполнить эту атаку, у злоумышленника должно быть непосредственно само веб-приложение и тенант Azure для его размещения. После настройки магазина мы можем начинать фишинговую кампанию, используя ссылку для установки приложения Azure:

Ссылка в электронном письме направляет пользователя на контролируемый злоумышленниками веб-сайт (например, myapp.malicious.com), который, в свою очередь, перенаправляет жертву на страницу входа Microsoft. Процесс проверки подлинности полностью обрабатывается Microsoft, поэтому использование многофакторной проверки подлинности не является решением проблемы.

Как только пользователь входит в свой экземпляр O365, для вредоносного приложения будет создан токен, и пользователю будет предложено авторизоваться и предоставить приложению необходимые разрешения. Вот как это выглядит для конечного пользователя (и должно выглядеть очень знакомо, если пользователь ранее устанавливал приложения в SharePoint или Teams):

Вот разрешения MS Graph API, которые запрашиваются злоумышленником в коде нашего приложения:

Как видите, злоумышленник контролирует имя приложения («MicrosoftOffice») и ярлык (мы использовали ярлык OneNote). URL-адрес является действительным URL-адресом Microsoft, сертификат также действителен.

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

Нажав «Accept», жертва предоставляет нашему приложению разрешения от имени своей учетной записи, то есть приложение сможет читать электронные письма жертвы и получать доступ к любым файлам, к которым есть доступ у жертвы.

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

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

Полученные возможности

Эта атака идеальна для следующих активностей:

• Разведка (получение списка учетных записей, групп, объектов в пользовательском тенанте);
• Внутренний фишинг;
• Кража данных с файловых ресурсов и электронной почты.

Чтобы проиллюстрировать мощь нашего приложения Azure, мы создали забавную консоль для отображения ресурсов, к которым мы получили доступ в рамках проверки нашего PoC (proof of Concept):

Раздел «Me» показывает детали попавшейся жертвы:

Раздел «Users» покажет нам вышеуказанные метаданные для каждого отдельного пользователя в организации, включая адрес электронной почты, номер мобильного телефона, должность и многое другое, в зависимости от атрибутов Active Directory организации. Один только этот вызов API может вызвать массовое нарушение политик защиты персональных данных, особенно в рамках GDPR и CCPA.

Раздел «Calendar» показывает нам события календаря жертвы. Мы также можем назначать встречи от её имени, просматривать существующие встречи и даже удалять будущие встречи.

Возможно, наиболее важным разделом в нашем консольном приложении является раздел «RecentFiles», который позволяет нам видеть любой файл, к которому пользователь обращался в OneDrive или SharePoint. Мы также можем загружать или изменять файлы (включая файлы с вредоносными макросами для развития атаки).

ВАЖНО: когда мы получаем доступ к файлу через этот API, Azure создает уникальную ссылку. Эта ссылка доступна любому человеку из любого места, даже если организация не разрешает анонимный обмен ссылками для рядовых пользователей 365.

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

Раздел «Outlook» дает нам полный доступ к электронной почте жертвы. Мы можем видеть получателей любого сообщения, фильтровать их по приоритету, отправлять электронные письма (внутренний фишинг) и многое другое.

Читая электронные письма жертвы, мы можем выявлять круг её коммуникаций и наиболее уязвимые контакты из этого круга, отправлять внутренние фишинговые письма от имени нашей жертвы и таким образом развивать атаку внутри организации. Мы также можем использовать адреса электронной почты жертвы и контактов из её круга, чтобы отфильтровать данные, которые мы находим в 365.

Более того, у Microsoft есть API, предоставляющий информацию об актуальном круге общения жертвы:

Как мы упоминали выше, мы можем изменять файлы пользователя при наличии соответствующих прав. А что, если мы воспользуемся API для модификации файлов?

Один из вариантов — превратить наше вредоносное приложение Azure в программу-вымогатель, которая удаленно шифрует файлы, к которым у жертвы есть доступ на изменение в SharePoint и OneDrive:

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

Другие источники:

• Кевин Митник представил аналогичный метод облачного шифрования, который применим к почтовым ящикам;
• Krebs On Security также написал хороший пост о такой атаке в своем блоге.

Актуальность проблемы. Как насчет отключения всех сторонних приложений?

Microsoft не рекомендует настраивать запрет пользователям на предоставление разрешений приложениям:

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

Как можно обнаружить злоупотребление приложениями Azure?

Простейший способ обнаружить незаконные разрешения — это отслеживать события предоставления доступа в Azure AD и регулярно просматривать ваши «Enterprise Applications» на портале Azure.

Всегда задавайте себе вопросы:

• Знаю ли я это приложение?
• Принадлежит ли оно организации, которую я знаю?

Для заказчиков Varonis: у модуля DatAlert есть модели угроз, которые обнаруживают злонамеренное предоставление разрешений. Также возможно создание собственных правил уведомления о предоставлении доступа приложению Azure.

Как удалить вредоносные приложения?

На портале Azure перейдите в раздел «Enterprise Applications» на вкладке «Azure Active Directory» и удалите приложения. Рядовой пользователь может удалить предоставленные ранее разрешения, перейдя по адресу myapps.microsoft.com, проверив перечисленные там приложения и отменив разрешения по мере необходимости.

Для получения подробных инструкций также смотрите официальные рекомендации Microsoft.

Автор оригинала: ERIC SARAGA.