Badacze zajmujący się bezpieczeństwem ujawnili szczegóły kampanii phishingowej, w której napastnicy podszywają się pod legalne wiadomości generowane przez Google, wykorzystując do tego usługę Application Integration w Google Cloud. Zamiast polegać na klasycznym spoofingu, przestępcy nadużywają mechanizmu automatycznych powiadomień, dzięki czemu wiadomości są wysyłane z autentycznego adresu należącego do Google, co zwiększa ich szansę trafienia do skrzynek odbiorczych i utrudnia wykrycie.
Według firmy Check Point atakujący używali adresu „noreply-application-integration@google[.]com”, co pozwalało ominąć tradycyjne filtry antyspamowe i mechanizmy weryfikacji nadawcy, takie jak SPF i DMARC. Wiadomości przypominały rutynowe powiadomienia korporacyjne — alerty o poczcie głosowej, prośby o dostęp do plików lub nadanie uprawnień — a ich styl i formatowanie były zgodne z typowymi komunikatami Google, co dodatkowo zwiększało wiarygodność i skłaniało odbiorców do kliknięcia zawartych linków.
W 14-dniowym okresie obserwowanym w grudniu 2025 r. kampania objęła 9 394 wiadomości phishingowych skierowanych do około 3 200 klientów. Ofiary znajdowały się w Stanach Zjednoczonych, regionie Azji i Pacyfiku, Europie, Kanadzie oraz Ameryce Łacińskiej. Analiza Check Point wskazuje, że głównymi celami byli przedstawiciele sektorów takich jak przemysł wytwórczy, technologie, finanse, usługi profesjonalne i handel detaliczny, choć ataki dotykały również mediów, edukacji, ochrony zdrowia, energetyki, administracji publicznej, turystyki i transportu — branże, które często korzystają z automatycznych powiadomień i współdzielonych dokumentów.
Rdzeń ataku stanowiło nadużycie zadania „Send Email” w Application Integration, które umożliwia wysyłanie niestandardowych powiadomień e-mail w ramach integracji. Dokumentacja Google ogranicza liczbę odbiorców tego zadania do maksymalnie 30 adresów, jednak fakt, że wiadomości można skierować na dowolne adresy e-mail, pozwolił napastnikom wykorzystywać tę legalną funkcję do rozsyłania phishingu z domen należących do Google, skutecznie omijając zabezpieczenia oparte na autentyczności domeny.
Atak miał charakter wieloetapowy. Po kliknięciu linku w wiadomości użytkownik był najpierw przekierowywany do zasobu przechowywanego pod storage.cloud.google[.]com — także części zaufanej infrastruktury Google — a następnie do treści serwowanej z googleusercontent[.]com. Tam ofiara widziała fałszywą walidację opartą na CAPTCHA lub obrazkowej weryfikacji, co pełniło dwojaką rolę: blokowało automatyczne skanery i narzędzia bezpieczeństwa przed analizą infrastruktury ataku oraz pozwalało rzeczywistym użytkownikom przejść dalej. Po pomyślnej „walidacji” ofiara trafiała na podrobioną stronę logowania Microsoft, hostowaną na domenie niezwiązanej z Microsoftem, gdzie wprowadzone dane logowania były przechwytywane przez napastników.
W odpowiedzi na ustalenia Google zablokowało wykorzystywaną funkcję powiadomień e-mail w Application Integration i zadeklarowało podjęcie dodatkowych kroków zapobiegawczych, aby ograniczyć dalsze nadużycia tej usługi.
Aktualizacja
Uzupełniające analizy opublikowały firmy xorlab i Ravenmail, które potwierdziły, że kampania miała na celu głównie wyłudzanie poświadczeń. xorlab wskazał dodatkowe techniki stosowane przez napastników: phishing zgody OAuth oraz hostowanie fałszywych stron logowania w zasobnikach Amazon Web Services S3. W jednej z wariantów ataku ofiary były socjotechnicznie nakłaniane do udzielenia zgody dla złośliwej aplikacji Azure AD, co pozwalało napastnikom uzyskać dostęp do zasobów chmurowych — subskrypcji Azure, maszyn wirtualnych, magazynów i baz danych — na mocy delegowanych uprawnień, które utrzymywały się dzięki tokenom dostępu i odświeżania.
Jak podkreślają badacze, każdy etap kampanii wykorzystywał zaufaną infrastrukturę — Google, Microsoft i AWS — co czyniło atak trudnym do wykrycia lub zablokowania w jednym punkcie. Niezależnie od miejsca wejścia ofiary ostatecznie trafiały na stronę logowania Microsoft 365, co sugeruje, że głównym celem napastników były poświadczenia M365.
Ten przypadek pokazuje, że legalne funkcje automatyzacji i integracji chmurowych mogą zostać przekształcone w kanały rozprzestrzeniania phishingu na dużą skalę. Atak wykorzystał zarówno zaufanie do komunikatów pochodzących z domen producenta usług chmurowych, jak i wieloetapowe przekierowania przez zaufane serwisy, aby zmniejszyć podejrzliwość użytkowników i utrudnić działania obronne. Sektorom, które regularnie korzystają z automatycznych powiadomień i współdzielonych dokumentów, grozi zwiększona podatność na tego rodzaju kampanie.»