Вредоносные OAuth-приложения позволяют атакующим добраться до данных Google Workspace без кражи пароля и без эксплуатации уязвимости в коде. Достаточно убедить сотрудника выдать приложению нужные разрешения, и привычная логика защиты вокруг логина и MFA начинает заметно проседать.
23 сентября 2026 года BleepingComputer проведёт вебинар с Material Security о том, как такие атаки проходят в реальных компаниях, сообщает BleepingComputer. В разборе участвуют Раджан Капур, вице-президент по безопасности Material Security, и Рик Фицджеральд, президент Fireside Consulting LLC. Они обещают разобрать две атаки на среды Google Workspace, где злоумышленники сочетали социальную инженерию и вредоносные OAuth-приложения.
Схема неприятна тем, что она не выглядит как классический взлом. Пользователь не обязательно вводит пароль на фишинговой странице и не обязательно передаёт одноразовый код. Он может думать, что подключает полезный сервис, отвечает на рабочий запрос или авторизует знакомое приложение. На практике он выдаёт стороннему приложению доступ к данным и сервисам Google Workspace в пределах одобренных разрешений.
OAuth изначально решает нормальную инженерную задачу: дать приложению доступ к почте, календарю, файлам или другим сервисам без передачи пароля. Для корпоративной среды это удобно: интеграции быстрее запускаются, SaaS-инструменты легче подключаются, пользователям не приходится пересылать секреты между системами. Но та же модель превращается в точку входа, если сотрудник может самостоятельно одобрить слишком широкие разрешения, а служба безопасности не видит, какие приложения уже получили доступ.
Главный сдвиг здесь в том, что пароль перестаёт быть центром атаки. Компания может включить MFA, ужесточить требования к паролям, настроить SSO и всё равно пропустить инцидент, если контроль приложений живёт отдельно или вообще отсутствует. Злоумышленнику не нужно ломать дверь, если можно попросить пользователя официально открыть боковой вход через окно согласия OAuth.
На вебинаре обещают разобрать не только сам момент авторизации, но и первые часы после компрометации. Это важная часть истории: именно тогда команда безопасности должна понять, какое приложение получило доступ, кто его одобрил, какие разрешения были выданы и какие данные могли быть затронуты. В быстрорастущих компаниях этот этап часто осложняется тем, что SaaS-ландшафт растёт быстрее процессов контроля. Вчера у команды было пять интеграций, сегодня их пятьдесят, а инвентаризация всё ещё ведётся по памяти в чате.
Для разработчиков и администраторов Google Workspace вывод достаточно практичный: нужно смотреть не только на учётные записи, но и на приложения, которым эти учётные записи доверяют. В зоне внимания должны быть список подключённых OAuth-приложений, объём выданных разрешений, право пользователей самостоятельно одобрять доступ, журналы активности и процедура быстрого отзыва токенов. Особенно опасны разрешения, которые дают доступ к почте, файлам, контактам и административным данным: именно там обычно лежит всё, ради чего атакующий вообще пришёл.
Для бизнеса эта история про баланс между скоростью и контролем. Fast-growing-команды любят подключать новые инструменты без долгих согласований: CRM, аналитику, расширения для почты, автоматизацию календарей, плагины для продаж и рекрутинга. Это понятно. Но каждый такой сервис становится частью периметра, даже если он не проходит через закупки, юристов и службу ИБ. Когда приложение просит доступ к корпоративным данным, это уже не личный выбор сотрудника, а изменение модели риска для всей организации.
Вредоносные OAuth-приложения особенно неприятны для компаний с ограниченными ресурсами безопасности. Им трудно построить идеальную программу защиты с нуля, но можно начать с вещей, которые дают быстрый эффект: ограничить самостоятельное одобрение чувствительных разрешений, включить проверку сторонних приложений, регулярно чистить старые интеграции, настроить алерты на подозрительные OAuth-согласия и заранее прописать, кто отзывает доступ при инциденте. Это не героическая кибермагия, а скучная гигиена, которая внезапно становится очень дорогой, если её нет.
Тренд выглядит очевидно: атаки всё чаще идут не через грубый взлом пароля, а через доверие между облачными сервисами. Чем больше компания живёт внутри SaaS-экосистемы, тем важнее понимать, кто и на каких основаниях имеет доступ к данным. Вопрос для IT-команд уже не только в том, насколько хорошо защищён вход в Google Workspace, а в том, сколько приложений вошли туда вместе с пользователями и кто вообще это заметил.