Operation CloudFire: фішинг через Google Календар викрадав сесії в обхід багатофакторної автентифікації

З середини серпня 2026 року фішингова кампанія викрадає активні сесії Google у корпоративних користувачів. Її побудували так, щоб усі сигнали, на які зазвичай спираються системи захисту під час перевірки посилань, показували: загрози немає. Кампанію виявила компанія Material Security, що розробляє засоби захисту для Google Workspace і Microsoft 365. Її команда дослідження загроз провела операцію Operation CloudFire, у межах якої заблокувала сотні доменів зловмисників.

Приманка: запрошення від знайомих відправників

Повідомлення надходять як запрошення Google Календаря — іноді в прихованій копії (BCC), а часто від організації, з якою одержувач уже листувався. Приводи буденні: сповіщення про голосове повідомлення, запити на подання комерційних пропозицій (RFP) чи інформації (RFI), судові повістки, нагадування про прострочені платежі.

Більшість посилань веде на ресурси самого Google. Типова схема — власний переадресатор Google (/url), у параметрі якого прихована справжня адреса призначення. В інших хвилях для цього використовували share.google та посилання на файли в Google Drive, а в одному з варіантів — сповіщення про транзакції Intuit.

Тож у момент перевірки повідомлення домен, сертифікат і репутація посилання щоразу виглядають легітимними та довіреними.

Пастка: справжня сторінка входу Google за зворотним проксі

Зловмисник розміщує зворотний проксі (reverse proxy) перед справжньою сторінкою входу Google. Жертва вводить пароль, отримує справжній запит на підтвердження і схвалює його — а оператор атаки в цей час спостерігає за сесією в реальному часі.

Сервер миттєво пересилає Google коди з SMS, коди із застосунків-автентифікаторів, підтвердження входу з вибором числа (Tap Yes) і навіть відновлення доступу через телефон. Тож жоден другий фактор не заважає перехопити сесію. Такі атаки називають «зловмисник посередині» (adversary-in-the-middle, AiTM).

В основі кампанії — фреймворк Nyasher. За даними Material Security, він публічно відомий з лютого, коли в його JavaScript-коді виявили жорстко прописаний ключ.

Чому системи захисту мовчать

Репутаційні системи відповідають на питання про власника ресурсу: хто зареєстрував домен, що ще на ньому розміщувалося і чи надходили на нього скарги. Кампанію збудували так, щоб відповіді на ці питання завжди були безневинними. Вона має три рівні.

Перший — переадресатор Google. Другий — перевірка Cloudflare Turnstile, яка в деяких збірках є справжнім віджетом, що завантажується з інфраструктури самої Cloudflare. Третій — сторінка для викрадення пароля, яка не існує як статичний сайт, тож сканувати немає чого.

Її формує JavaScript у браузері вже після того, як відвідувач пройде перевірку. Тому пошуковому роботу нічого завантажувати, а журналу проксі-сервера — нічого фіксувати. Наскільки відомо Material Security, до публікації дослідження ці сторінки ніхто не сканував.

Одноразова інфраструктура

Інфраструктуру кампанії від початку розрахували на швидку заміну. На першому етапі зловмисники використовували численні домени-приманки в кількох реєстраторів, більшість із яких зареєстрували лише за кілька днів до атаки. Сервери для приймання викрадених даних готували за 1–20 днів до хвилі розсилки, яку вони обслуговували.

Один wildcard-сертифікат випустили за 46 хвилин до реєстрації домену, який він покриває. Блокування будь-якого окремого елемента обходиться операторові в кілька доларів і пів дня роботи.

Наслідки: далеко за межами поштової скриньки

Коли результатом атаки стає викрадена сесія, а не пароль, сліди зʼявляються в журналах аудиту Google Workspace. Активна сесія Google відкриває доступ до пошти й Google Drive та дає змогу надавати OAuth-доступ від імені жертви — тож масштаб шкоди не обмежується поштою.

Командам безпеки варто поставити собі два питання: хто переглядає ці журнали і як швидко можна відреагувати на виявлене? Не менш важливо, чи здатна команда протягом години завершити сесії, відкликати OAuth-дозволи та скинути облікові дані скомпрометованого акаунта. Багатьом організаціям це не під силу, а зловмисник з активною сесією за годину встигає зробити чимало.

Як кампанію відстежували

Material Security стежила за кампанією від самого початку, фіксуючи кожен новий варіант: зловмисники постійно змінювали приманки, проміжні перевірки, сервери для приймання даних, а також тактики, теми й тексти повідомлень, щоб обійти статичні правила, моделі машинного навчання та агентні системи на основі ШІ. За словами компанії, після запуску відповідних механізмів виявлення вона блокує понад 99% шкідливих повідомлень цієї кампанії, а частка повідомлень, класифікацію яких довелося змінювати, становить 0,01%. Ці показники наводить сама компанія, незалежно їх не перевірено.

Ключовий висновок дослідників: жоден окремий сигнал не дає змоги впевнено розпізнати таку атаку. Репутаційний аналіз її не помітив би, як і аналіз посилань, адже перший перехід веде на адресу Google, а кінцевої сторінки не існує, доки її не збере браузер. Тому Material оцінює одночасно технічні ознаки, ймовірний намір повідомлення, справжній кінцевий пункт посилань та історію взаємодії з відправником. Система, побудована навколо одного сигналу, успадковує його сліпі зони — а оператор цієї кампанії доклав чимало зусиль, щоб їх вивчити.

Має значення й те, де саме відбувається аналіз. Шлюзи, що перевіряють пошту під час доставки, погано пристосовані до запрошень у календарі, а саме так надходила більша частина повідомлень кампанії. Тому запрошення в календарі варто розглядати як окремий вектор атаки.

Operation CloudFire: удар по інфраструктурі

Наприкінці вересня в Material Security дійшли висновку, що самого лише налаштування правил, перенавчання моделей та оновлення агентів недостатньо: виявлення захищає клієнтів, але не заважає операторові готувати наступну хвилю. Тож команда дослідження загроз запустила Operation CloudFire — операцію проти самої інфраструктури зловмисників.

Дослідники аналізували адреси проміжних сторінок і серверної частини просто під час розсилки та повідомляли про них через систему скарг Cloudflare. Команда Cloudflare перевіряла підроблену проміжну сторінку та проксійовану сторінку входу Google за нею, після чого показувала на цих адресах власне попередження про фішинг.

Це дало подвійний ефект. По-перше, інфраструктура зловмисників ставала непридатною: кожен проміжний вузол і сервер приймання даних доводилося заново реєструвати, перенаправляти й отримувати для нього новий сертифікат, перш ніж відновити розсилку. По-друге, виграли всі користувачі інтернету: будь-хто, хто переходив за заблокованим посиланням, бачив попередження замість форми входу — незалежно від того, чи був він клієнтом Material.

Масштаб за один місяць

Дані охоплюють лише клієнтів, які погодилися ділитися ними з Material Security, тож реальні масштаби більші. За місяць Operation CloudFire компанія зафіксувала:

• 68 676 заблокованих повідомлень кампанії;
• 2 112 проаналізованих унікальних шкідливих URL-адрес;
• 897 заблокованих унікальних доменів;
• 8 570 унікальних скомпрометованих адрес відправників на 6 354 кореневих доменах;
• графік розсилки, що відповідав робочим годинам у США.

Кількість відправників пояснює, звідки в кампанії така переконливість. Кожна скомпрометована адреса належала акаунту, який зловмисник контролював ще до відправлення першого запрошення, і з кожного з них запрошення надходили, серед іншого, на збережені контакти власника.

Одержувачі бачили знайоме імʼя або домен, у домену була чиста історія, а повідомлення надходило у правдоподібний час. Репутаційні системи не мали підстав для тривоги — тож кожен рівень захисту, що оцінює власника та історію ресурсу, видавав заспокійливий результат.

Кампанія завершилася? Не зовсім

Тематика фішингу змістилася: замість запрошень у календарі зловмисники почали надсилати запрошення до спільного доступу до файлів і документів у Google Drive. Помітного зростання інших приманок чи тактик Material не фіксує, а активність угруповання, схоже, розпорошилася. Кампанія виглядає завершеною.

Утім, це констатація поточного стану, а не остаточний висновок. Відновити інфраструктуру дешево, фреймворк публічно відомий з лютого, а разом із робочим кодом для Google оператор розгорнув і незавершену гілку для Microsoft 365.

Вона містить шлях до таблиці стилів, другий модуль запуску і рядок заголовка, який після декодування перетворюється на запит входу Microsoft. Жоден із цих шляхів поки не працює, а щоб додати новий бренд, достатньо підкласти файл — змінювати код не потрібно.

Тобто наступний етап уже підготовлено, але ще не запущено. У Material вважають зміну тематики не згортанням кампанії, а черговою ітерацією й очікують, що наступна хвиля виглядатиме так само — лише під іншим брендом. Повний технічний розбір з індикаторами компрометації та хронологією атак компанія оприлюднила в окремому звіті.

Як захиститися

Знайомий відправник і посилання, що починається з google.com, у цій кампанії були саме прикриттям, а не ознакою безпеки. Тому головне правило — не вводити пароль від акаунта Google після переходу із запрошення чи листа.

• Відкривати сторінку входу самостійно. Якщо запрошення чи сповіщення вимагає увійти в акаунт, краще закрити його й перейти на сайт Google через закладку або вручну набрану адресу.
• Перевіряти адресний рядок. Сторінка входу Google розміщується на домені accounts.google.com. Якщо форма входу відкрилася на будь-якій іншій адресі — це фішинг, навіть коли сторінка виглядає бездоганно.
• Переходити на ключі доступу (passkeys) або апаратні ключі безпеки. Вони працюють за стандартом FIDO і, як наголошує Google, стійкі до фішингу: ключ привʼязаний до справжньої адреси сайту, тож підроблена сторінка не зможе ним скористатися — на відміну від кодів із SMS чи застосунків-автентифікаторів.
• Не покладатися лише на фільтр відомих відправників. Режим «Лише якщо відправник відомий» відсікає більшість календарного спаму, але від цієї кампанії не рятує: запрошення надходили зі зламаних акаунтів знайомих контактів. Надійніше — додавати події в календар лише після відповіді на лист із запрошенням.
• Діяти негайно, якщо пароль уже введено. Слід змінити пароль, завершити сеанси на всіх пристроях і перевірити сторонні застосунки, яким надано доступ до акаунта, у розділі «Безпека» налаштувань Google.

Адміністраторам Google Workspace дослідники радять насамперед переконатися, що журнали аудиту хтось регулярно переглядає, і відпрацювати сценарій реагування: команда має бути здатна протягом години завершити активні сесії, відкликати OAuth-дозволи та скинути облікові дані скомпрометованого акаунта. Запрошення в календарі варто включити до периметра, який перевіряють засоби захисту пошти, — інакше вони залишаються сліпою зоною.