Autor: Wojciech Ciemski

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. Kluczowe jest to, że 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ę, że podobny schemat nadużyć dotyczy również innych popularnych usług chmurowych i workflow (np. powiadomienia, podpisy elektroniczne).

Równolegle Microsoft opisuje, że 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ł, że 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ć, że 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)

1. 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 właściwy ładunek ujawnia się dopiero po przekierowaniach.
2. 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”.

3. 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.

4. 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, że 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 / kluczowe wnioski

Ta kampania pokazuje, że 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

1. Malwarebytes Labs – opis kampanii (6 stycznia 2026) (Malwarebytes)
2. Check Point Research (Harmony Email Security) – raport techniczny i statystyki (22 grudnia 2025) (Check Point Blog)
3. Google Cloud Docs – Application Integration „Send Email task” (limit odbiorców, konfiguracja) (Google Cloud Documentation)
4. Microsoft Security Blog – trendy i mitigacje przeciw phishingowi/AiTM oraz higiena konfiguracji ochrony poczty (6 stycznia 2026) (Microsoft)
5. Microsoft Learn – Conditional Access: blokowanie przepływów uwierzytelniania (Device Code Flow) (aktualizacja: 5 grudnia 2025) (Microsoft Learn)

Wprowadzenie do problemu / definicja luki

Ledger poinformował część klientów o ekspozycji danych osobowych wynikającej nie z włamania do infrastruktury Ledger, lecz z incydentu u zewnętrznego dostawcy usług e-commerce i rozliczeń – Global-e (działającego m.in. jako Merchant of Record). W praktyce to klasyczny przykład naruszenia bezpieczeństwa w łańcuchu dostaw (third-party / supply-chain data breach): atakujący uzyskuje dostęp do systemów partnera przetwarzającego dane zamówień, a skutki uderzają w klientów marki korzystającej z tego partnera.

Warto podkreślić od razu: według komunikatów cytowanych przez media, nie doszło do kompromitacji seed phrase (24 słów), kluczy prywatnych ani środków on-chain. To jednak nie znaczy, że ryzyko jest pomijalne – wycieki danych kontaktowych w ekosystemie krypto niemal zawsze napędzają phishing i ukierunkowane oszustwa.

W skrócie

• Incydent dotyczy systemów chmurowych Global-e, które przechowują dane zamówień dla wielu marek (Ledger nie jest jedyną).
• Ujawnione dane to przede wszystkim dane kontaktowe i dane zamówienia (w zależności od źródła: imię i nazwisko, adres, e-mail, telefon oraz szczegóły zamówienia typu numer zamówienia/produkt/cena).
• Brak dowodów na wyciek danych płatniczych oraz „sekretów” portfela (24 słowa / klucze).
• Global-e deklaruje, że po wykryciu aktywności zagrożenia odizolowało i zabezpieczyło dotknięte systemy oraz prowadzi notyfikacje potencjalnie poszkodowanych i regulatorów.

Kontekst / historia / powiązania

Global-e to platforma obsługująca procesy typowe dla sprzedaży międzynarodowej: checkout, podatki/cła, lokalizację i przetwarzanie zamówień. Taki model wymaga utrzymywania zestawu danych o kliencie i zamówieniu (PII + order data), często w wielu jurysdykcjach. BleepingComputer wskazuje, że z usług Global-e korzysta wiele znanych marek, co sugeruje potencjalnie szerszy zasięg incydentu niż tylko klienci Ledger.

Dla Ledger to dodatkowo temat wrażliwy reputacyjnie, bo firma już wcześniej mierzyła się z problemami związanymi z wyciekami danych klientów w 2020 r. (m.in. w kontekście e-commerce/marketingu oraz ekosystemu dostawców). Media zwracają uwagę, że takie zdarzenia historycznie przekładały się na wzrost kampanii phishingowych wymierzonych w użytkowników.

Analiza techniczna / szczegóły luki

Z udostępnionych informacji wynika, że:

1. Punkt wejścia był po stronie Global-e, a nie w systemach Ledger. Ledger wprost podkreśla, że jego platforma oraz hardware/software pozostają bezpieczne.
2. Naruszenie dotyczyło dostępu do danych zamówień przechowywanych w systemach informacyjnych Global-e (w tym w środowisku chmurowym).
3. Zakres skopiowanych danych – według relacji SiliconANGLE cytującej treść komunikacji Global-e – obejmuje PII i order details, m.in. imię i nazwisko, adres pocztowy, e-mail, numer telefonu oraz szczegóły zamówienia (np. numer zamówienia, produkt, cena).
4. Jednocześnie podkreślono, że nie naruszono danych płatniczych ani poświadczeń kont (co jest spójne z tym, że Global-e jako partner MoR przetwarza checkout, ale nie ma dostępu do 24-wyrazowej frazy odzyskiwania ani sekretów portfela).

W praktyce ten profil zdarzenia pasuje do scenariusza: nieautoryzowany dostęp → eksfiltracja danych referencyjnych (PII/order) → monetyzacja przez socjotechnikę. Nawet bez dostępu do środków, atakujący może „przeskoczyć” zabezpieczenia kryptograficzne, atakując człowieka.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla klientów Ledger po takim wycieku to:

• Phishing i podszywanie się pod Ledger/Global-e: mając imię, e-mail/telefon i kontekst zakupowy (np. „kupiłeś model X”), przestępcy mogą tworzyć bardzo wiarygodne wiadomości o „weryfikacji portfela”, „koniecznej aktualizacji” czy „odblokowaniu wysyłki”. Ledger ostrzega przed kampaniami mającymi wyłudzać 24 słowa.
• SIM swapping / przejęcia kanałów komunikacji: numer telefonu w rękach atakujących zwiększa ryzyko ataków na operatora i resetów haseł tam, gdzie SMS jest drugim składnikiem.
• Ryzyko doxingu i ataków ukierunkowanych: adres pocztowy + „sygnał, że ktoś posiada krypto” bywa wykorzystywany do prób wymuszeń, nękania, a w skrajnych przypadkach do przestępstw z użyciem przemocy (tzw. „wrench attacks”). W historii branży takie korelacje zdarzały się po wyciekach PII. (To ryzyko nie jest dowodem konkretnego działania w tym incydencie, ale jest racjonalną konsekwencją tego typu danych.)
• Wtórne oszustwa logistyczno-podatkowe: jeśli wyciek obejmuje szczegóły zamówienia, możliwe są fałszywe „dopłaty do cła”, „potwierdzenia dostawy” lub linki do rzekomych firm kurierskich.

Kluczowe: brak kompromitacji seed phrase nie eliminuje zagrożenia – zmienia jedynie wektor ataku z technicznego na socjotechniczny.

Rekomendacje operacyjne / co zrobić teraz

Dla klientów (użytkowników końcowych)

1. Nigdy nie podawaj 24 słów (seed phrase) – nikomu, nigdy, w żadnym formularzu. Ledger akcentuje to w komunikacji.
2. Traktuj każdy kontakt „w sprawie bezpieczeństwa portfela” jako podejrzany, zwłaszcza jeśli zawiera linki, presję czasu lub prośbę o „weryfikację”.
3. Weryfikuj domeny i kanały: wchodź na strony ręcznie (zakładka), nie z linku w mailu/SMS.
4. Uodpornij reset haseł: gdzie się da, używaj aplikacji TOTP lub kluczy U2F/FIDO2 zamiast SMS.
5. Segmentuj tożsamość (jeśli możesz): osobny e-mail/alias do zakupów sprzętu krypto, ograniczenie ujawniania numeru telefonu, a w przyszłości – minimalizacja danych w zamówieniach.
6. Uważaj na „dopłaty do wysyłki/cła” i fałszywe trackingi – to popularny wzorzec po wyciekach order data.

Dla organizacji (sprzedaż online / partnerzy MoR)

1. Vendor Risk Management: wymagaj od partnerów (MoR/PSP/fulfillment) jasnych standardów: logowanie zdarzeń, MFA, segmentacja, szyfrowanie danych spoczynkowych, cykliczne testy i raportowanie incydentów.
2. Data minimization: przechowuj u partnera tylko to, co konieczne; rozważ skracanie retencji danych zamówień i pseudonimizację identyfikatorów.
3. Gotowe playbooki komunikacji: po wycieku PII liczą się godziny – predefiniowane szablony ostrzeżeń anty-phishing, landing pages z FAQ, jednoznaczne reguły „czego nigdy nie prosimy podać”.
4. Monitorowanie nadużyć: wzmożone monitorowanie brand-phishingu (look-alike domains), kampanii SMS, reklam sponsorowanych podszywających się pod support.

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

2026 (Global-e) vs wcześniejsze wycieki wokół Ledger (2020):

• W 2026 mówimy o incydencie u dostawcy obsługującego checkout i dane zamówień, czyli klasyczny „third-party breach”.
• W przekazie medialnym przewija się podobny zakres PII (kontakt + adres) i ta sama konsekwencja: wzrost ryzyka phishingu.
• Różnica praktyczna jest taka, że nawet jeśli rdzeń produktu (self-custody) nie został naruszony, to dla użytkownika końcowego skutki często „wyglądają” podobnie: rośnie liczba przekonujących ataków socjotechnicznych, bo atakujący ma kontekst zakupowy i dane kontaktowe.

Wniosek: w firmach security-first reputacja zależy nie tylko od kryptografii i twardych zabezpieczeń produktu, ale również od higieny danych klientów w całym łańcuchu dostaw.

Podsumowanie / kluczowe wnioski

• Incydent dotyczy Global-e, a Ledger podkreśla, że jego systemy i bezpieczeństwo portfeli nie zostały naruszone.
• Najbardziej wrażliwy element to PII + dane zamówień, które znacząco zwiększają skuteczność phishingu i oszustw „podszywających się pod support”.
• Najlepsza obrona po takim wycieku to: zero zaufania do wiadomości przychodzących, twarda zasada „nigdy 24 słów”, weryfikacja kanałów i wzmocnienie MFA.
• Dla organizacji: to kolejny argument, że ryzyko vendorów musi być zarządzane jak ryzyko własnej infrastruktury.

Źródła / bibliografia

1. BleepingComputer – „Ledger customers impacted by third-party Global-e data breach” (05.01.2026). BleepingComputer
2. SiliconANGLE – „Ledger confirms leak of customer data from third-party Global-e hack” (05.01.2026). SiliconANGLE
3. PYMNTS – „Crypto Wallet Ledger Suffers Breach Tied to Payment Processor” (05.01.2026). PYMNTS.com