Почему «замочек» в адресной строке больше ничего не гарантирует.

Письмо с просьбой «подписать документ» или «подтвердить учетную запись» может вести не на поддельный сайт, а на вполне настоящий адрес Microsoft или Google. Именно на этом доверии и сыграли злоумышленники, которые научились использовать механизм перенаправления в протоколе OAuth для фишинга и доставки вредоносных программ.
Специалисты Microsoft зафиксировали кампании против государственных структур и организаций общественного сектора. Атаки строились вокруг штатной функции OAuth, которая позволяет службе аутентификации перенаправлять пользователя на указанный адрес при определенных условиях, например при ошибке входа. Злоумышленники не взламывали учетные записи и не похищали токены доступа. Вместо этого использовали поведение протокола по правилам, но в своих интересах.
Схема начиналась с создания вредоносного приложения в инфраструктуре злоумышленника. В настройках указывали адрес перенаправления на подконтрольный домен, где размещали фишинговую страницу или файл с вредоносной нагрузкой. Затем жертве отправляли письмо со ссылкой, которая выглядела как обычный запрос на вход через систему аутентификации, например через Microsoft Entra ID или учетные записи Google.
В ссылку намеренно добавляли некорректные параметры, например несуществующую область доступа и режим «без отображения интерфейса». Такая комбинация гарантированно вызывала ошибку входа. По правилам OAuth служба аутентификации в этом случае перенаправляет браузер на заранее указанный адрес вместе с описанием ошибки. В результате пользователь сначала видел легитимный домен Microsoft или Google, а затем автоматически попадал на сайт злоумышленника.
В письмах использовали привычные темы: электронная подпись, документы на проверку, уведомления из кадровой службы, приглашения на встречу в Teams, сброс пароля или сообщения о проблемах с социальными выплатами. Иногда ссылку прятали в PDF-файле без текста в теле письма. В ряде случаев адрес электронной почты жертвы передавали в параметре state, кодировали в виде обычной строки, в шестнадцатеричном виде или через Base64, чтобы затем автоматически подставить адрес на фишинговой странице и повысить доверие.
После перенаправления часть кампаний вела на классические фишинговые панели вроде EvilProxy, которые перехватывают учетные данные и файлы сеансов. В других случаях атака переходила к заражению устройства. Пользователь попадал на страницу вида /download/XXXX, откуда автоматически скачивался архив ZIP.
Внутри архива находился ярлык LNK и вспомогательные файлы. При открытии ярлык запускал PowerShell, который собирал сведения о системе с помощью команд вроде ipconfig и tasklist, затем распаковывал исполняемый файл steam_monitor.exe и библиотеку crashhandler.dll. Легитимный файл запускался и подгружал вредоносную библиотеку по схеме подмены DLL. Библиотека расшифровывала дополнительный компонент и устанавливала соединение с управляющим сервером. Дальше злоумышленники могли закрепиться в системе и перейти к ручному управлению.
Microsoft сообщила, что защитные механизмы Microsoft Defender фиксировали подозрительную активность на уровне почты, учетных записей и конечных устройств. Обнаруженные вредоносные приложения OAuth в Entra ID отключили, однако аналогичная активность продолжается, поэтому компания рекомендует внимательно контролировать выдачу согласий на приложения, регулярно проверять права доступа и удалять неиспользуемые или избыточные интеграции.
В основе атак лежит не уязвимость в программном обеспечении, а особенности стандарта OAuth, описанные в RFC 6749 и более поздних документах. Протокол допускает перенаправление при ошибках аутентификации. Злоумышленники намеренно вызывают такие ошибки и используют доверие к доменам крупных поставщиков аутентификации, чтобы обойти фильтры и незаметно привести пользователя на вредоносный ресурс. На фоне усиления защиты от кражи паролей и обхода многофакторной аутентификации атаки все чаще нацеливаются на доверительные механизмы и поведение самих протоколов.