Google Cloud jako „zaufany nadawca”: nowa fala phishingu uderza w ponad 3 000 organizacji - Security Bez Tabu

Google Cloud jako „zaufany nadawca”: nowa fala phishingu uderza w ponad 3 000 organizacji

Wprowadzenie do problemu / definicja luki

W końcówce grudnia 2025 badacze Check Point opisali kampanię phishingową, która podważa jedno z najczęściej wykorzystywanych założeń w ochronie poczty: „jeśli nadawca jest z zaufanej domeny, to ryzyko jest mniejsze”. Atakujący nie spoofowali domeny, tylko nadużyli legalnej funkcji Google Cloud Application Integration, aby wysyłać maile z prawdziwego adresu w domenie google.com.

W skrócie

  • W ciągu ~14 dni rozesłano 9 394 wiadomości phishingowe do ok. 3 200 organizacji.
  • Maile pochodziły z prawdziwego adresu: noreply-application-integration@google.com.
  • Łańcuch przekierowań prowadził przez zaufane domeny Google (m.in. storage*.google.cloud.com / storage.cloud.google.com → googleusercontent.com), a kończył się na fałszywej stronie logowania Microsoft (kradzież poświadczeń).
  • Google potwierdziło, że to nadużycie narzędzia automatyzacji, nie „włamanie do infrastruktury Google”, oraz że wdrożono blokady dla tej techniki.

Kontekst / historia / powiązania

Ten typ nadużyć wpisuje się w rosnący trend „phishingu na zaufanej infrastrukturze”, gdzie przestępcy:

  1. wykorzystują legalne usługi (chmurowe, SaaS, formularze, hosting plików),
  2. budują wiarygodność na renomie domeny i poprawnych mechanizmach uwierzytelniania poczty,
  3. dopiero na końcu „przełączają” ofiarę na domenę kontrolowaną przez atakującego.

Podobny wzorzec opisał wcześniej Kaspersky: wiadomość wygląda jak oficjalny alert Google (z prawdziwego adresu), a oszustwo kryje się w szczegółach i w tym, dokąd finalnie prowadzą linki (np. legalne subdomeny/usługi typu Google Sites).

Analiza techniczna / szczegóły kampanii

1) Wejście: „prawdziwy” nadawca i treści enterprise

Check Point wskazuje, że kampania wykorzystywała Google Cloud Application Integration i najpewniej zadanie “Send Email”, pozwalające wysyłać powiadomienia z infrastruktury Google (bez kompromitacji samego Google). Treści podszywały się pod rutynowe komunikaty: powiadomienia o poczcie głosowej, udostępnieniu pliku, zmianie uprawnień, dostępie do dokumentu „Q4” itd.

2) Klucz do skuteczności: łańcuch przekierowań przez domeny Google

Mechanizm „3-stopniowej pułapki” wyglądał następująco:

  1. Kliknięcie linku prowadziło do zasobu na storage.cloud.google.com lub storage.google.cloud.com (zaufany host, często przepuszczany przez filtry).
  2. Następnie następowało przekierowanie na googleusercontent.com z fałszywą stroną typu CAPTCHA/„weryfikacja”. Ten etap ma sens ofensywnie: utrudnia automatyczną analizę linków (sandbox, skanery URL) i „odcina” część zabezpieczeń, które nie przechodzą interakcji.
  3. Dopiero po „CAPTCHA” ofiara lądowała na fałszywej stronie logowania Microsoft (credential harvesting).

3) Kogo atakowano najczęściej?

Największy udział miały organizacje w USA, a branżowo: produkcja/przemysł, technologia/SaaS oraz finanse/ubezpieczenia.

Praktyczne konsekwencje / ryzyko

  1. DMARC/SPF/DKIM mogą nie „uratować” – bo wiadomość może przejść jako poprawnie uwierzytelniona i pochodzić z realnej domeny. To zmienia priorytety: rośnie znaczenie analizy zachowania linków, treści i anomalii kontekstowych.
  2. Kradzież poświadczeń Microsoft 365 / Entra ID (wątek „Microsoft login”) to prosta droga do: przejęcia skrzynek, BEC, kradzieży danych, ataków wewnętrznych, dalszego phishingu z zaufanych kont.
  3. „Trusted services abuse” jest trudny proceduralnie: użytkownik widzi google.com w nadawcy i domenach pośrednich, więc ignoruje sygnały ostrzegawcze, a SOC dostaje mniej oczywiste alerty.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC / zespołów bezpieczeństwa poczty

  • Włącz analizę łańcucha przekierowań (URL detonation / follow-redirects): wykrywanie scenariusza „Google host → googleusercontent → zewnętrzna domena logowania”.
  • Polityki ryzyka dla linków do hostingu plików i googleusercontent.com: nie blokować „na ślepo”, ale podnieść scoring, wymusić izolację przeglądarki (RBI) lub dodatkową weryfikację, gdy finalny URL wychodzi poza Google/Microsoft.
  • Reguły detekcji anomalii brandingu: „Google powiadomienie”, które kończy na „Microsoft login”, powinno podnosić ryzyko (mismatch marek i kontekstu).
  • Hunting: korelacja kampanii po tematach „voicemail”, „shared file”, „permissions”, „Q4 file” + obecność etapów CAPTCHA.

Dla adminów Google Cloud / zespołów chmurowych

  • Jeśli zarządzasz GCP: traktuj automatyzacje i integracje jako powierzchnię ataku. Monitoruj nadużycia i reaguj na alerty/ostrzeżenia Google Cloud (m.in. logi nadużyć, diagnostyka, procesy „abuse/misuse”).
  • Ograniczaj uprawnienia (least privilege) do tworzenia/uruchamiania workflowów integracyjnych, a tam gdzie się da – stosuj dodatkowe kontrole (review, approvals, alerting na nietypowe wysyłki).

Dla użytkowników i IT w organizacji

  • Nie loguj się do M365 po wejściu z „powiadomienia Google” – zamiast tego wejdź ręcznie na portal Microsoft/Office i sprawdź powiadomienie w aplikacji (out-of-band).
  • Wymuś phishing-resistant MFA (FIDO2/WebAuthn, passkeys) na kontach krytycznych, bo sama „aplikacyjna MFA” bywa obchodzona przez pośrednie strony logowania.
  • Szkolenia: pokazuj realne przykłady „zaufany nadawca, złośliwy link” – ta kampania jest idealnym case study.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Ten incydent nie opiera się o spoofing – przewaga atakującego to legalny nadawca i legalne domeny na początku ścieżki.
  • W starszych kampaniach „google-phishing” często centrum ataku stanowiła domena łudząco podobna do Google; tutaj „oszustwo” przeniosło się do warstwy automatyzacji i workflowów oraz do końcowego etapu kradzieży poświadczeń.
  • Wspólny mianownik z innymi nadużyciami ekosystemu Google: użytkownik ma widzieć „google.com” i przestać analizować szczegóły (np. różnicę usług/subdomen, lub finalny „skok” na obcą domenę).

Podsumowanie / kluczowe wnioski

Ta kampania jest ważna nie dlatego, że jest „nową techniką phishingu” (phishing jest stary), ale dlatego, że przesuwa ciężar obrony: z weryfikacji nadawcy na analizę kontekstu, łańcucha przekierowań i spójności marki/akcji. Jeśli Twoje procesy nadal traktują „zaufaną domenę” jako główny argument bezpieczeństwa, to jest dobry moment, by to zrewidować.

Źródła / bibliografia

  1. Check Point Blog – opis kampanii, liczby, łańcuch przekierowań, branże i regiony, cytat Google. (Check Point Blog)
  2. TechRadar – streszczenie i dodatkowy kontekst usługi Application Integration. (TechRadar)
  3. Google Cloud Documentation – jak reagować na nadużycia/ostrzeżenia i dobre praktyki monitoringu. (Google Cloud Documentation)
  4. Kaspersky (blog) – kontekst nadużyć usług Google w phishingu i „pułapek” w detalach. (Kaspersky)
  5. Hackread – opis fali phishingu (opracowanie na bazie raportu Check Point). (hackread.com)