Массовый фишинг через взломанные аккаунты Google Workspace: как обходят защиту

Атакующие не подделывают отправителя — они отправляют вредоносные письма с настоящих доменов учебных заведений и организаций, прошедших DKIM и имеющих чистую репутацию. Фильтры и SEG пропускают сообщение в primary inbox, потому что домен, подпись и история отправителя совпадают с подлинной инфраструктурой.

Вектор и масштаб

Источник сообщает о более чем 450 скомпрометированных доменах учебного сектора, задействованных в кампании. Сценарий повторяется и в коммерческих структурах: берётся валидный ящик Google Workspace, из него инициируется цепочка писем с запросами на смену платёжных реквизитов, обновление учётных данных, согласование счетов и ревью документов. Маршрут доставки фишинга дополнительно зафиксирован в отдельной волне с луром «New Audio MSG»: ссылка Play Audio уводит через AWS click tracking и промежуточные redirect-узлы на страницу, имитирующую Google Workspace или Google Voice. Адрес получателя передаётся в Base64 во фрагменте URL и подставляется в фишинговую форму — это видно по логам переходов и заголовкам Location в цепочке 30x.

Что ломается в стандартных проверках

SPF, DKIM и DMARC на скомпрометированном домене валидны. PTR, MX, репутация IP — в норме. Это и есть основная угроза: аутентификация не даёт оснований для карантина. Сигнал, который раньше считался достаточным, теперь бесполезен против учётной записи, находящейся под управлением атакующего. Аналогичный приём — эксплуатация доверенной облачной инфраструктуры как промежуточного звена — встречается и за пределами почтового стека: злоумышленники опираются на репутацию публичных сервисов, включая платформы хранения и self-storage сервисы уровня Clutter, чтобы первый хоп выглядел безобидно и не вызывал подозрений у фильтров и пользователей.

Что настроить и проверить

Отключите у Google Workspace разрешение на отправку через нестандартные клиенты и регионы: Admin Console → Apps → Google Workspace → Gmail → User settings → POP and IMAP access. Принудительно включите 2FA и переведите администраторов на аппаратные ключи. Ограничьте forwarding на внешние домены и автоматические правила обработки входящих — компрометация часто выражается именно в скрытом создании фильтра, перенаправляющего копии писем наружу.

Проверьте журнал аудита Admin Console → Reports → Audit log на события Login, Token issuance, Gmail setting change, OAuth grant за последние 30 дней. Отфильтруйте входы по нетипичным ASN, IP вне рабочего региона, одновременные сессии из разных стран. Сопоставьте URL clicks из писем с новыми login attempts в тех же mailbox'ах — связка «переход по ссылке в письме → вход в аккаунт из другого гео» является надёжным индикатором.

В DMARC-политике переведите домен на p=reject с rua= и ruf= для получения агрегированных отчётов и forensic. Включите BIMI при достижении стабильного reject — это закроет атаки через графический бренд. На SEG добавьте правило по эвристике: письмо, прошедшее SPF/DKIM/DMARC, но содержащее redirect-цепочку на AWS-домены или иные click-tracking платформы, помещать в карантин или помечать предупреждением banner.

Проведите тренировку на phishing-simulation сценарий: запрос на изменение платёжных реквизитов, обновление direct deposit, ссылка на «голосовое сообщение». Зафиксируйте в runbook порядок действий при компрометации ящика: revoke tokens, reset password, block OAuth apps, rotate service account keys, восстановить правила inbox и forwarding.

Если в течение последних 30 дней фиксировались входы с нетипичных IP или аномальный объём исходящих писем с ящиков вашего домена в Workspace — относитесь к этому как к инциденту. Лур «New Audio MSG» и redirect-цепочки с Base64-адресом во фрагменте URL сейчас в активной ротации, и они будут проходить стандартные проверки аутентификации до тех пор, пока учётная запись отправителя остаётся валидной.