Phishing bez własnej domeny: podwyżka przez Safe Links i Google

Po rozwinięciu linku badacze zobaczyli cztery kolejne hosty: Outlook Safe Links, przekierowanie Google Meet, drugi mechanizm przekierowania Google i dopiero na końcu host należący do niezależnej firmy. Według IRONSCALES w całym łańcuchu nie było domeny zarejestrowanej przez napastnika.

To nie znaczy, że Microsoft Safe Links albo Google zostały przejęte. W tym przypadku legalne mechanizmy przekierowań stały się kolejnymi warstwami pomiędzy wiadomością a końcowym hostem. Dla użytkownika najważniejsze pytanie brzmi więc nie tylko „czy rozpoznaję domenę?”, ale również dokąd prowadzi cały proces i dlaczego właśnie teraz mam podać dane.

Co dokładnie wydarzyło się w tym przypadku

Według IRONSCALES celem był dyrektor sprzedaży w firmie z branży spożywczej. Wiadomość wyglądała jak wewnętrzna informacja dotycząca podwyżki i zawierała pojedynczy przycisk prowadzący do „portalu”.

Przynęta była krótka. Temat i treść wykorzystywały nazwę pracodawcy oraz dane odbiorcy, aby stworzyć wrażenie kontynuacji wcześniejszej rozmowy. Sama wiadomość została wysłana z prawdziwej skrzynki należącej do niezwiązanej z odbiorcą kancelarii.

Najciekawsza część zaczynała się po kliknięciu. Zamiast przejścia bezpośrednio na świeżą domenę phishingową użytkownik trafiał przez kilka rozpoznawalnych elementów infrastruktury.

Cztery etapy pożyczonej reputacji

IRONSCALES rozwinął przycisk do czterech kolejnych warstw:

1. Outlook Safe Links — adres został przepisany przez mechanizm ochronny Microsoftu.
2. Google Meet linkredirect — legalny mechanizm przekierowania na adres podany w parametrze.
3. Google /url — kolejny mechanizm przekierowania na innej domenie Google.
4. Host niezależnej firmy — końcowy adres wykorzystywał nazwę autodiscover w subdomenie i ścieżce.

W praktyce oznaczało to, że szybki rzut oka na log proxy albo widoczny początek adresu mógł pokazać kolejno Microsoft i Google. Łańcuch nie wymagał świeżej domeny zarejestrowanej przez napastnika, ponieważ kolejne warstwy korzystały z usług i hostów należących do innych podmiotów.

Taki mechanizm jest szerszym wariantem problemu, który opisujemy w materiale Browser trust abuse: jak phishing wykorzystuje zaufanie do przeglądarki. Tam właścicielem tematu jest zaufanie do znanego interfejsu i procesu. W tym przypadku punkt ciężkości leży na łańcuchu przekierowań i reputacji kolejnych hostów.

Dlaczego Safe Links nie jest dowodem problemu

Safe Links jest funkcją Microsoft Defender for Office 365. Microsoft opisuje ją jako mechanizm, który może przepisywać adresy URL w wiadomościach, skanować je oraz sprawdzać ponownie w momencie kliknięcia.

Dlatego obecność adresu safelinks.protection.outlook.com w wiadomości nie jest sygnałem, że usługa została przejęta. To normalny element ochrony w środowiskach, w których Safe Links jest aktywny.

Jednocześnie taki prefiks nie powinien być traktowany jako końcowy werdykt bezpieczeństwa. Użytkownik nadal przechodzi do adresu docelowego. Jeżeli za pierwszym przekierowaniem znajdują się kolejne warstwy, ich rola i końcowy cel muszą być ocenione osobno.

Podobną zasadę PHISHLY opisuje przy phishingu wykorzystującym Amazon S3: legalna infrastruktura dostawcy mówi, kto obsługuje daną usługę, ale nie potwierdza intencji całego procesu.

Co robiły przekierowania Google

Drugi i trzeci etap korzystały z infrastruktury Google. IRONSCALES wskazuje meet.google.com/linkredirect oraz przekierowanie typu google.*/url.

To również nie oznacza kompromitacji Google. Usługi przekierowujące przyjmują adres docelowy i kierują do niego użytkownika. Problem pojawia się wtedy, gdy z takich legalnych funkcji powstaje wieloetapowa ścieżka, która oddala końcowy cel od linku widocznego w wiadomości.

Niezależnie od tego konkretnego incydentu Mimecast opisał w sierpniu 2026 kilka rodzin przekierowań Google nadużywanych w phishingu i spamie, w tym właśnie google.*/url oraz meet.google.com/linkredirect.

Dla użytkownika praktyczny wniosek jest prosty: domena Google może być pośrednikiem, a nie miejscem, w którym kończy się proces.

Stary host i ścieżka autodiscover

Końcowy host należał do brytyjskiej firmy produkcyjnej, której domena miała około 15 lat i nadal służyła normalnej działalności. To usuwa kolejny popularny sygnał ostrzegawczy: świeży wiek domeny.

Subdomena i początek ścieżki używały nazwy autodiscover, kojarzonej z mechanizmem automatycznej konfiguracji poczty Microsoft. W kontekście informacji o wynagrodzeniu taka nazwa nie miała biznesowego uzasadnienia, ale na pierwszy rzut oka mogła wyglądać jak techniczny element infrastruktury.

IRONSCALES podkreśla, że materiał potwierdza nadużycie hosta, ale nie pozwala rozstrzygnąć, czy domena firmy została przejęta. To istotna granica: nieznany sposób uzyskania dostępu nie powinien być zamieniany w pewne twierdzenie o kompromitacji.

Odbiorca był zakodowany w adresie

Ścieżka końcowa zawierała również wartość przypisaną do konkretnego odbiorcy. Adres e-mail został zapisany przy użyciu kodowania base64, czyli sposobu przedstawiania danych jako ciągu znaków; base64 nie jest szyfrowaniem. Następnie zakodowany ciąg został rozdzielony separatorami na kilka fragmentów.

Taki zabieg może utrudnić proste reguły szukające jawnego adresu e-mail albo jednego ciągłego bloku base64. Daje też stronie docelowej informację, który odbiorca kliknął link.

Nie ma potrzeby reprodukować prawdziwej wartości. Wystarcza sama obserwacja, że adres URL może zawierać spersonalizowany identyfikator nawet wtedy, gdy nie jest on czytelny wprost.

Co znaczy „clean” w takim łańcuchu

Według IRONSCALES wszystkie wyodrębnione linki otrzymały od skanerów wynik „clean” (czysty) albo „not applicable” (nie dotyczy). Taki wynik opisuje ocenę konkretnych hostów i adresów w danym momencie. Nie jest gwarancją, że cały proces biznesowy uruchomiony przez wiadomość jest prawidłowy.

Właśnie dlatego nie należy budować szkolenia wokół reguły „zielony skaner = bezpieczny link”. Dobre zabezpieczenia techniczne są potrzebne, ale pracownik powinien nadal rozumieć kontekst:

• czy oczekiwał informacji o podwyżce;
• czy organizacja normalnie kieruje do portalu kadrowego z wiadomości e-mail;
• dlaczego link przechodzi przez kilka niezwiązanych usług;
• jaki adres znajduje się w pasku przeglądarki przed podaniem danych;
• czy informację można potwierdzić niezależnym kanałem.

Podobną granicę omawiamy w materiale 67% phishingu przechodzi DMARC. Zaufanie pod presją: poprawny sygnał techniczny potwierdza określoną właściwość, ale nie zastępuje oceny intencji wiadomości.

Dlaczego zgłoszenie wiadomości miało znaczenie

W tym przypadku wiadomość zgłosił sam odbiorca, a analityk potwierdził phishing. To ważny element scenariusza szkoleniowego, ponieważ pokazuje rolę człowieka po dostarczeniu wiadomości, która nie daje prostego sygnału w rodzaju świeżej, losowej domeny.

Program security awareness powinien więc mierzyć nie tylko kliknięcia. Liczy się również:

• czy pracownik potrafi przerwać proces przed podaniem danych;
• czy potrafi wrócić do znanego portalu kadrowego bez używania linku z wiadomości;
• czy zgłasza podejrzany komunikat;
• jak szybko zgłoszenie trafia do zespołu, który może sprawdzić podobne wiadomości u innych odbiorców.

Organizacje mogą ćwiczyć takie zachowania w ramach programu security awareness, zamiast ograniczać symulacje do rozpoznawania literówek i świeżych domen.

Wniosek

Ten przypadek nie pokazuje „phishingu, który złamał Microsoft i Google”. Pokazuje coś bardziej użytecznego dla obrony: napastnik może zbudować wiarygodną ścieżkę bez własnej domeny, wykorzystując legalne mechanizmy przekierowań i host należący do innej organizacji.

Dlatego znajoma domena na jednym etapie nie kończy weryfikacji. Przed wpisaniem danych trzeba sprawdzić końcowy adres, kontekst prośby i to, czy proces został uruchomiony oczekiwaną drogą. Jeśli wiadomość o podwyżce przychodzi niespodziewanie, bezpieczniej otworzyć portal kadrowy znaną ścieżką i potwierdzić informację niezależnie.