Wprowadzenie do problemu / definicja luki
Na początku stycznia 2026 r. opisano kampanię phishingową, która celuje w konta Microsoft 365, ale „sprzedaje się” wiarygodnością infrastruktury Google. najważniejsze jest to, iż nie mówimy o przełamaniu zabezpieczeń Google, tylko o nadużyciu legalnej funkcji automatyzacji w Google Cloud do wysyłania wiadomości z prawdziwego adresu w domenie google.com.
W skrócie
- Atakujący wysyłają wiadomości z legalnego adresu noreply-application-integration@google.com dzięki funkcji Send Email w Google Cloud Application Integration.
- Link w mailu prowadzi najpierw do storage.cloud.google.com (zaufany Google Cloud Storage), potem przez googleusercontent.com z fałszywą weryfikacją CAPTCHA, a na końcu na podrobioną stronę logowania Microsoft 365 na domenie niebędącej domeną Microsoft.
- Skala (z perspektywy telemetryki Check Point): 9 394 maile do ok. 3 200 organizacji w ~14 dni, z istotnym udziałem ofiar w USA oraz w sektorach przemysł/produkcja, technologia/SaaS i finanse.
Kontekst / historia / powiązania
To klasyczny przykład trendu „trusted-platform phishing” (czasem też: workflow-abuse phishing): zamiast fałszować domenę nadawcy, przestępcy pożyczają zaufanie od dużych dostawców (tu: Google Cloud), by ominąć część filtrów i obniżyć czujność użytkownika. Malwarebytes zwraca uwagę, iż podobny schemat nadużyć dotyczy również innych popularnych usług chmurowych i workflow (np. powiadomienia, podpisy elektroniczne).
Równolegle Microsoft opisuje, iż phishing w 2025–2026 coraz częściej „dopina” skuteczność technikami utrudniającymi detekcję (np. routing, omijanie kontroli antyspoofingowych, gotowe platformy PhaaS/AiTM). Ta kampania wpisuje się w tę samą logikę: maksymalnie wiarygodny start i opóźnienie wykrycia.
Analiza techniczna / szczegóły kampanii
1) Wejście: legalny nadawca z google.com
Check Point ustalił, iż kampania wykorzystuje Google Cloud Application Integration i zadanie Send Email do wysyłki wiadomości z adresu noreply-application-integration@google.com. To istotne, bo część organizacji i użytkowników traktuje „google.com” jako sygnał bezpieczeństwa.
W dokumentacji Google Cloud wprost widać, iż Send Email pozwala definiować odbiorców (do 30 adresów na zadanie) oraz treść/temat — funkcja jest w pełni legalna i zaprojektowana do automatycznych notyfikacji.
2) Socjotechnika: „normalne” powiadomienia
Maile naśladują typowe komunikaty firmowe: powiadomienia o poczcie głosowej, udostępnionym pliku, prośbie o dostęp czy zadaniu do wykonania — czyli tematy, przy których kliknięcie linku jest odruchem.
3) Łańcuch przekierowań: zaufane domeny na początku
Mechanika kliknięcia jest wieloetapowa:
- Etap 1: klik w link prowadzący do storage.cloud.google.com (Google Cloud Storage).
- Etap 2: przekierowanie na googleusercontent.com, gdzie użytkownik widzi fałszywą „weryfikację” (CAPTCHA / image-check). Cel: odsiać skanery i sandboxy oraz „uśpić” podejrzenia.
- Etap 3: finał to fałszywa strona logowania Microsoft hostowana na domenie niepowiązanej z Microsoft — wszystkie wpisane dane trafiają do atakujących.
4) Reakcja dostawcy
Zarówno Malwarebytes, jak i Check Point przytaczają stanowisko Google: działania zostały podjęte przeciwko nadużyciu tej funkcji, a aktywność wynikała z nadużycia narzędzia automatyzacji, nie z kompromitacji infrastruktury Google.
Praktyczne konsekwencje / ryzyko
Jeśli użytkownik poda login i hasło do M365 na fałszywej stronie, skutki zwykle obejmują:
- przejęcie skrzynki i próby BEC (Business Email Compromise),
- kradzież danych z SharePoint/OneDrive/Teams,
- eskalację ataku przez reguły skrzynki (ukrywanie korespondencji), forwarding, dalszy phishing „z wewnątrz”.
Dodatkowo kampania jest groźna operacyjnie, bo startuje z bardzo wiarygodnych domen (Google), więc proste reguły reputacyjne i część heurystyk „klik/nie klik” bywają mniej skuteczne.
Rekomendacje operacyjne / co zrobić teraz
Dla zespołów bezpieczeństwa / IT (organizacje)
- Wzmocnij ochronę linków „na klik”
Microsoft rekomenduje mechanizmy weryfikacji URL w momencie kliknięcia (time-of-click) oraz działania post-delivery (np. automatyczne usuwanie wiadomości po nowej intel) w ramach ochrony poczty. To ważne, bo w tego typu kampaniach treść bywa „czysta” na etapie dostarczenia, a adekwatny ładunek ujawnia się dopiero po przekierowaniach. - Detekcja po sygnałach łańcucha (a nie po samym nadawcy)
Rozważ reguły/alerty oparte o kombinacje typu:
- nadawca: noreply-application-integration@google.com + obecność linków do storage.cloud.google.com / googleusercontent.com,
- treści o „voicemail/shared document/permission request” + nietypowe przyciski/CTA,
- nietypowe przekierowania wychodzące do domen spoza Microsoft po „etapie Google”.
- Twarde zasady dostępu do M365
- Wymuś MFA odporne na phishing (FIDO2 / passkeys) tam, gdzie to możliwe.
- Zaostrz Conditional Access (lokalizacja, urządzenia zgodne, ryzykowne logowania).
- Dodatkowo (jeśli nie jest potrzebne w Twojej organizacji): blokuj Device Code Flow – to osobny wektor przejęć M365, ale realnie spotykany i rekomendowany do możliwie szerokiego zablokowania przez Microsoft.
- Playbook po incydencie (gdy ktoś kliknął i wpisał hasło)
- natychmiastowy reset hasła + wymuszenie wylogowania sesji,
- przegląd logów logowania (nowe urządzenia, nietypowe kraje, nietypowe aplikacje),
- audyt reguł skrzynki, przekierowań, aplikacji z dostępem,
- komunikat do użytkowników: jak rozpoznawać „zaufaną domenę na starcie” i gdzie sprawdzać końcowy URL przed wpisaniem danych.
Dla użytkowników
- Nie ufaj nadawcy tylko dlatego, iż jest z „google.com”. W tej kampanii to element przynęty.
- Zanim wpiszesz hasło do M365, sprawdź domenę w pasku adresu (czy to faktycznie domena Microsoft).
Różnice / porównania z innymi przypadkami
- To nie jest spoofing domeny: SPF/DKIM/DMARC mogą wyglądać poprawnie, bo e-mail realnie wychodzi z infrastruktury Google.
- Kampania przypomina inne nowoczesne schematy phishingowe, gdzie „wiarygodność” buduje się po drodze (zaufany hosting/redirect) i dokłada elementy anty-analizy (CAPTCHA) — zamiast od razu kierować ofiarę na podejrzaną domenę.
Podsumowanie / najważniejsze wnioski
Ta kampania pokazuje, iż zaufanie do marki i domeny nadawcy przestaje być wystarczającą heurystyką. Atakujący potrafią legalnie użyć automatyzacji w chmurze do wysyłki z „dobrych” domen, a następnie poprowadzić ofiarę przez zaufane serwisy (Cloud Storage, googleusercontent) aż do fałszywego logowania M365. Obrona musi więc łączyć: ochronę linków na klik, detekcję po łańcuchu przekierowań, twarde polityki dostępu do M365 i szybkie playbooki IR.
Źródła / bibliografia
- Malwarebytes Labs – opis kampanii (6 stycznia 2026) (Malwarebytes)
- Check Point Research (Harmony Email Security) – raport techniczny i statystyki (22 grudnia 2025) (Check Point Blog)
- Google Cloud Docs – Application Integration „Send Email task” (limit odbiorców, konfiguracja) (Google Cloud Documentation)
- Microsoft Security Blog – trendy i mitigacje przeciw phishingowi/AiTM oraz higiena konfiguracji ochrony poczty (6 stycznia 2026) (Microsoft)
- Microsoft Learn – Conditional Access: blokowanie przepływów uwierzytelniania (Device Code Flow) (aktualizacja: 5 grudnia 2025) (Microsoft Learn)
