Злоумышленники атакуют госсектор через фишинг, маскируя вредоносные ссылки под легитимные запросы OAuth

Атака начинается с того, что злоумышленник создает в контролируемом им облачном тенанте (арендованном экземпляре) приложение, использующее OAuth. В настройках этого приложения указывается Redirect URI (URI перенаправления), ведущий на вредоносный домен. После этого жертвам рассылаются фишинговые письма с призывом перейти по ссылке, которая имитирует запрос на авторизацию. Ключевой особенностью атаки является умышленная подстановка в URL параметров, гарантирующих сбой аутентификации, например, невалидной области действия (scope) или директивы "prompt=none", требующей «тихого» (без интерфейса) входа. Когда провайдер идентификации обрабатывает такой запрос, он сталкивается с ошибкой, и, согласно стандарту OAuth, перенаправляет пользователя на указанный в приложении URI, то есть на страницу злоумышленника. При этом сам токен доступа не передается, но цель - доставить жертву на вредоносный ресурс - достигается.

Детальный анализ показал, что кампания состоит из нескольких четких этапов. На первом этапе осуществляется доставка фишинговых писем. Злоумышленники использовали темы, связанные с электронными подписями, социальным обеспечением, финансами или политикой, чтобы побудить получателей к взаимодействию. Ссылки с OAuth-запросами могли быть как в теле письма, так и внутри PDF-вложений. Для усиления доверия в параметр "state", предназначенный для защиты от CSRF-атак, часто кодировался email-адрес жертвы, который затем автоматически подставлялся на фишинговой странице. После редиректа пользователь попадал на платформы для перехвата учетных данных, такие как EvilProxy, либо на страницу загрузки вредоносного файла.

Второй этап - это «тихий» OAuth-зондаж. Специально сформированный URL, содержащий параметры "prompt=none" и заведомо неверный "scope", отправляется провайдеру идентификации. Система пытается провести авторизацию в фоновом режиме, но сталкивается с ошибкой. Этот шаг позволяет атакующему проверить, существует ли учетная запись пользователя, и понять, требуется ли для входа интерактивная аутентификация или многофакторная проверка (MFA). Третий этап - это собственно злонамеренное перенаправление. После ошибки браузер жертвы автоматически отправляется на тот самый вредоносный Redirect URI, который был указан при регистрации приложения. В URL-строку при этом добавляются параметры ошибки (например, "error=interaction_required"), которые дают злоумышленнику дополнительную информацию.

На четвертом и пятом этапах происходит компрометация конечной точки. В одной из наблюдаемых кампаний после редиректа на путь "/download/" автоматически начиналась загрузка ZIP-архива. Внутри архива находился вредоносный ярлык (.LNK), который при открытии запускал PowerShell-скрипт. Этот скрипт проводил разведку на хосте, а затем с помощью легитимной утилиты "tar" извлекал исполняемые файлы, включая "steam_monitor.exe". Используя технику side-loading (подмены DLL), вредоносная библиотека "crashhandler.dll" загружалась в память через легитимный процесс, расшифровывала и выполняла финальную полезную нагрузку, устанавливая соединение с командным сервером (C2) злоумышленника. Это демонстрирует переход от разведки на основе идентификации к полноценному закреплению в системе с целью последующей деятельности, например, вымогательства или ручного управления.

Важно подчеркнуть, что данная атака не использует уязвимости в программном коде. Она злоупотребляет стандартным, предусмотренным спецификациями RFC 6749 и RFC 9700 поведением OAuth. Как отмечается в RFC 9700, сервер авторизации может быть использован как открытый редиректор, если атакующий умышленно провоцирует ошибки. Microsoft уже отключила обнаруженные вредоносные OAuth-приложения в своей инфраструктуре, однако подобная активность требует постоянного мониторинга, так как метод не привязан к конкретной платформе. Для противодействия таким угрозам организациям необходимо ужесточить управление OAuth-приложениями: ограничить возможность пользователей давать согласие приложениям, регулярно проводить аудит выданных разрешений и удалять неиспользуемые или имеющие избыточные права приложения. Критически важным является внедрение политик условного доступа (Conditional Access), которые могут блокировать подозрительные попытки входа, и использование комплексных систем защиты, способных коррелировать события из доменов электронной почты, идентификации и конечных точек для выявления подобных многоэтапных атак исследование Microsoft Threat Intelligence. Таким образом, современные угрозы все чаще атакуют не технологии, а доверительные отношения и стандартное поведение протоколов, что требует от специалистов по безопасности целостного взгляда на инфраструктуру и глубокого понимания принципов работы используемых стандартов.

Microsoft Client Ids

• 9a36eaa2-cf9d-4e50-ad3e-58c9b5c04255
• 89430f84-6c29-43f8-9b23-62871a314417
• 440f4886-2c3a-4269-a78c-088b3b521e02
• c752e1ef-e475-43c0-9b97-9c9832dd3755
• 6755c710-194d-464f-9365-7d89d773b443
• 3cc07cb4-dba8-4051-82cd-93250a43b53b
• 8c659c19-8a90-49b0-a9f1-15aeba3bb449
• bc618bf4-c6d1-4653-8c4d-c6036001b226
• bc618bf4-c6d1-4653-8c4d-c6036001b226
• 6efe57d9-b00a-4091-b861-a16b7368ab11
• f73c6332-4618-4b9d-bcd4-c77726581acd
• 6fae87b3-3a0f-4519-8b56-006ba50f62c4
• 1b6f59dd-45da-4ff7-9b70-36fb780f855b
• 00afba72-9008-454f-bbe6-d24e743fbe73
• 1b6f59dd-45da-4ff7-9b70-36fb780f855b
• a68c61ee-6185-4b36-bc59-1dca946d95cb

URLs

• https://abv-abc3.top/abv2/css/red.html
• https://calltask.im/cpcounting/via-secureplatform/quick/
• https://dynamic-entry.powerappsportals.com/dynamics/
• https://email-services.powerappsportals.com/divisor/
• https://gbm234.powerappsportals.com/auth/
• https://login-web-auth.github.io/red-auth/
• https://memointernals.powerappsportals.com/auth/
• https://mweb-ssm.surge.sh
• https://ouviraparelhosauditivos.com.br/auth/entry.php
• https://ssmapp.github.io/web
• https://ssmview-group.gitlab.io/ssmview
• https://weds101.siriusmarine-sg.com/minerwebmailsecure101/
• https://westsecure.powerappsportals.com/security/