Tag: Phishing

Wprowadzenie do problemu / definicja luki

7 grudnia 2025 r. Coupang opublikował odświeżone zawiadomienie dla klientów w sprawie głośnego incydentu bezpieczeństwa, podkreślając brak „nowego” naruszenia oraz ostrzegając przed wtórnymi oszustwami (phishing, podszywanie się). To follow-up do pierwszego komunikatu z 29 listopada. Celem jest zminimalizowanie szkód wynikających z wycieku danych dotyczącego ponad 33 mln kont klientów w Korei Południowej.

W skrócie

• Skala: ok. 33,7 mln kont klientów.
• Zakres danych: imię i nazwisko, e-mail, numer telefonu, adres dostawy, wybrane informacje o zamówieniach; bez haseł i danych płatniczych.
• Okres naruszenia: od 24 czerwca 2025 r. do wykrycia 18 listopada 2025 r. (niezauważone przez ~5 miesięcy).
• Nowe zawiadomienie (7 grudnia): brak nowych wycieków; uwagi dot. prewencji phishingu.
• Wstępne ustalenia śledczych: możliwy wektor związany z kluczem kryptograficznym i wątek „insidera” (były pracownik).
• Na dziś: policja sygnalizuje brak potwierdzonych szkód wtórnych, ale ryzyko oszustw pozostaje.

Kontekst / historia / powiązania

Coupang – największa platforma e-commerce w Korei – wykrył nietypowy dostęp 18 listopada i poinformował organy w ciągu 48 godzin. Skala incydentu została szybko skorygowana do dziesiątek milionów kont, co regulatorzy i rząd uznali za największy wyciek od ponad dekady, inicjując śledztwa i zapowiadając ostrzejsze sankcje za zaniedbania w ochronie danych.

Analiza techniczna / szczegóły luki

Na podstawie dotychczasowych komunikatów i doniesień:

• Wektor dostępu: śledztwo wskazuje na użycie skradzionego prywatnego klucza (kontekst kryptograficzny) oraz możliwy udział osoby z uprawnieniami wewnętrznymi (były inżynier). To zwiększa prawdopodobieństwo scenariusza insider-enabled lub post-employment key misuse.
• Środowisko ataku: ruch wychodzący/połączenia z zagranicznych serwerów od końca czerwca; luka była długotrwale nieujawniona.
• Zakres danych: dane identyfikacyjne i kontaktowe oraz część metadanych zamówień; brak dowodów na kompromitację haseł i tokenów płatniczych – ważne dla oceny ryzyka przejęć kont i fraudów finansowych.

Praktyczne konsekwencje / ryzyko

• Phishing i vishing celowane w użytkowników na podstawie prawdziwych danych (imię, adres, historia zakupów), w tym fałszywe „zwroty/zwroty środków”, dopłaty do dostawy czy linki do „aktualizacji hasła”.
• Smishing (SMS) z użyciem numerów telefonów i wzmianki o realnych zamówieniach („Rocket Delivery”).
• Ryzyko kradzieży tożsamości niefinansowej (np. weryfikacje adresowe, podszywanie się przy odbiorze przesyłek).
• Ryzyko reputacyjne i regulacyjne dla organizacji – w Korei rozważane są ostrzejsze kary finansowe i odszkodowawcze.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników Coupang:

1. Ignoruj i zgłaszaj wszystkie wiadomości o „dopłatach/zwrotach” prowadzące poza oficjalną domenę/aplikację. Nie klikaj skróconych linków w SMS-ach.
2. Zmiana hasła i włączenie 2FA dla kont Coupang i powiązanych e-maili – mimo braku dowodów na wyciek haseł to dobry compensating control.
3. Przegląd historii zamówień i metod płatności; ustaw alerty transakcyjne w banku/kartach.
4. Filtry anty-smishingowe u operatora/na urządzeniu; zgłaszaj podejrzane SMS-y/maile zgodnie z lokalnymi wytycznymi (w Korei: KISA).
5. Uważaj na „potwierdzanie danych” przez telefon – Coupang nie prosi o hasła/OTP przez SMS/telefon.

Dla organizacji (wnioski kontrolne):

• Zarządzanie kluczami i tajemnicami: regularna rotacja, HSM/KMS, zasada 4 oczu, monitoring użycia kluczy i break-glass accounts. (Wnioski z hipotezy użycia skradzionego klucza).
• Zasada najmniejszych uprawnień + offboarding: natychmiastowe i automatyczne unieważnianie dostępów (IAM), szczególnie po odejściu pracownika.
• Ujawnianie i detekcja: detekcje anomalii egress, eBPF/EDR w środowiskach serwerowych, bazy IOC dla ruchu do TTP „overseas exfil”.
• Ćwiczenia „assume breach” i testy phishingowe dopasowane do realnych scenariuszy logistyczno-płatniczych e-commerce.

Różnice / porównania z innymi przypadkami

• Skala: według rządu i mediów głównego nurtu to największy wyciek w Korei od lat, porównywalny z głośnymi incydentami z początku lat 2010., ale w innym ekosystemie technologicznym (aplikacje mobilne, dostawy on-demand).
• Charakter wektora: raportowane wątki „insider/stolen key” odróżniają ten incydent od klasycznych ataków wyłącznie sieciowych czy błędów konfiguracyjnych w chmurze.
• Dane płatnicze/hasła: brak oznak kompromitacji – to istotna różnica względem wielu wycieków retail, gdzie dochodzi do przejęć kart/credential stuffing.

Podsumowanie / kluczowe wnioski

• 7 grudnia Coupang nie ogłosił nowego incydentu, a jedynie przypomniał zasady bezpieczeństwa i ostrzegł przed phishingiem.
• Wyciek obejmuje 33,7 mln kont; dane kontaktowe i adresowe, bez haseł i kart. Okno ataku: 24.06–18.11.2025.
• Wstępne tropy śledcze wskazują na nadużycie klucza i możliwy wątek insiderski – organizacje powinny zrewidować własne praktyki KMS/IAM.
• Na dziś policja nie wykazała szkód wtórnych, ale ryzyko oszustw pozostaje wysokie – użytkownicy powinni wzmocnić higienę cyfrową.

Źródła / bibliografia

• Korea JoongAng Daily – „Coupang issues new notice to customers regarding data breach” (7 grudnia 2025). (Korea Joongang Daily)
• KBS World – „Coupang Recaps Data Breach on Website, Issues Guidance for Customers” (7 grudnia 2025). (KBS World)
• Reuters – „Top South Korean e-commerce firm Coupang apologises over massive data breach” (29 listopada 2025). (Reuters)
• Reuters – „South Korea’s Lee calls for tougher penalties after Coupang data breach” (2 grudnia 2025). (Reuters)
• TechCrunch – „Korea’s Coupang says data breach exposed nearly 34M customers’ personal information” (1 grudnia 2025). (TechCrunch)
• (uzupełniająco) BankInfoSecurity – przegląd ustaleń o dacie rozpoczęcia incydentu i skali. (bankinfosecurity.asia)

Wprowadzenie do problemu / definicja luki

27 listopada 2025 r. południowokoreańska giełda kryptowalut Upbit doświadczyła szybkiego drenażu środków z gorących portfeli (hot wallets) opartych o ekosystem Solany. Według danych nadzoru finansowego FSS, upublicznionych przez posła Kang Min-kuka, w zaledwie 54 minuty (04:42–05:36 KST) przetransferowano do zewnętrznych adresów ok. 104–106 mld sztuk tokenów o łącznej wartości ~44,5 mld KRW (~30 mln USD).

W skrócie

• Skala i tempo: ~104,06 mld tokenów w 54 minuty (średnio ~32 mln tokenów/sek.).
• Największe straty wartościowo: SOL (~18,99 mld KRW), dalej PENGU i TRUMP; wolumenowo dominował memcoin BONK (99,1% liczby tokenów).
• Reakcja i zgłoszenia: Upbit wstrzymał wpłaty/wypłaty Solany o 05:27, a wszystkie aktywa o 08:55; formalne zgłoszenie do FSS o 10:58 (ponad 6 h od detekcji).
• Tło regulacyjne: luki prawne utrudniają nałożenie dotkliwych sankcji; rząd rozważa wzmocnienie odpowiedzialności giełd po incydencie.
• Atrybucja (wstępna): władze rozważają wątek grupy Lazarus (KRLD).

Kontekst / historia / powiązania

Upbit to największa giełda w Korei (ok. 70% rynku). Dzień ataku zbiegł się z ogłoszeniem przejęcia operatora giełdy (Dunamu) przez Naver Financial w transakcji akcyjnej wartej ~10,3 mld USD, co wzmocniło presję reputacyjną na spółkę. Część polityków zasugerowała, że opóźnienie zgłoszenia incydentu mogło mieć związek z konferencją ogłaszającą fuzję.

W 2019 r. Upbit utracił już 342 tys. ETH w ataku na hot wallet. Obecny incydent wpisuje się w długą serię uderzeń w giełdy w regionie, często z przypisywaniem ich grupie Lazarus.

Analiza techniczna / szczegóły luki

Wektor i przebieg: nie ma jeszcze publicznej, pełnej analizy łańcucha kompromitacji. Pewne jest, że transfery dotyczyły ekosystemu Solany i objęły wiele tokenów (SOL, BONK, PENGU, TRUMP i in.). Szybkość i rozproszenie wypływów wskazują na automatyzację i wcześniejsze przygotowanie ścieżek odpływu (pre-staged addresses, skrypty).

Skład aktywów skradzionych:

• Wolumenowo: ~103,12 mld BONK (99,1% liczby tokenów), ale o niskiej wartości nominalnej.
• Wartościowo: SOL ~18,99 mld KRW (42,7% wartości), dalej PENGU ~3,85 mld KRW i TRUMP ~2,92 mld KRW.
• Suma: ~44,5 mld KRW (ok. 30,2 mln USD).

Czas reakcji i ograniczanie szkód:

• 05:00 – zebranie sztabu kryzysowego (18 min od detekcji),
• 05:27 – wstrzymanie wpłat/wypłat dla aktywów Solany,
• 08:55 – stop dla wszystkich aktywów.
  Upbit podkreśla, że >80% aktywów klientów było w cold walletach i giełda pokryła straty z własnych rezerw.

Zgłoszenia do instytucji: pierwszy kontakt z FSS o 10:58, kolejne: KISA 11:57, policja 13:16, FSC 15:00; publiczny komunikat na stronie o 12:33. To okno czasowe stało się osią krytyki.

Praktyczne konsekwencje / ryzyko

• Ryzyko wtórne dla klientów: phishing i oszustwa podszywające się pod działania „odzyskiwania środków”, wymianę adresów depozytowych czy „weryfikacje KYC”. (Upbit zapowiedział rotację adresów depozytowych po incydencie).
• Ryzyko systemowe dla płynności rynku KRW-crypto: czasowe wstrzymania wpłat/wypłat i zmiany adresów depozytowych chwilowo obniżają płynność i zawężają dostęp do on/off-rampów, co historycznie przekładało się na szersze spready i spadek udziału rynkowego giełdy. (Wynika to z obserwacji branżowych po podobnych incydentach).
• Ryzyko regulacyjne: brak jasnych podstaw prawnych dla sankcji po incydentach u dostawców VASP w Korei; rząd deklaruje zaostrzenie odpowiedzialności odszkodowawczej giełd.
• Ryzyko geopolityczne: jeżeli potwierdzi się udział Lazarusa, spodziewane są wzmożone kontrole AML i monitoring trasowania środków (mixery/bridge’e na Solanie i poza nią).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa giełd i custodianów:

1. Segmentacja i ograniczenie uprawnień hot walleti: minimalny float operacyjny; natychmiastowe limity dzienne/na adres; polityki „circuit breaker” po anomalii wolumenu.
2. Silniejsze klucze i HSM: multisig z niezależnymi domenami zaufania; rotacja kluczy po incydencie i po zmianach personelu; klucze powiernicze w HSM z politykami M-of-N, time-locki.
3. Monitorowanie w czasie rzeczywistym (L2/L3): detekcja anomalii na łańcuchu (velocity, entropy adresów), automatyczne playbooki izolacji.
4. Kontrole zmian i „two-person rule”: zwłaszcza dla listy adresów zaufanych i generowania adresów depozytowych.
5. Table-topy i bug-bounty pod kątem Solany: w tym symulacje szybkich drenaży i ataków na token programy SPL.

Dla użytkowników Upbit i innych giełd:

• Wygeneruj nowe adresy depozytowe – giełda je rotuje po włamaniu. Nie wysyłaj nic na stare adresy.
• Włącz 2FA/Passkeys i stosuj unikalne hasła; uważaj na SMS-y/e-maile o „odzyskaniu środków”.
• Przechowuj długoterminowe środki w cold walletach; hot wallet na bieżące potrzeby.
• Weryfikuj komunikaty tylko w oficjalnych kanałach (strona/notice giełdy).

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

• 2019 vs 2025: w obu przypadkach uderzono w hot wallety Upbit, ale w 2025 r. atak był znacznie szybszy i wielo-tokenowy w ekosystemie Solany, co zwiększyło presję detekcji w czasie rzeczywistym. Atrybucja wstępna ponownie kieruje się ku Lazarusowi.
• Inne giełdy 2025: rynek widział rekordowe kradzieże, ale rzadko o tak dużej liczbie sztuk tokenów w tak krótkim oknie czasowym; przypadek Upbit podkreśla specyfikę ryzyka przy memcoinach (duże wolumeny, niska wartość jednostkowa) i tokenach SPL.

Podsumowanie / kluczowe wnioski

• Szybkość zabija: 54 minuty wystarczyły na transfer ponad 100 mld sztuk tokenów – playbooki automatycznej izolacji muszą działać w sekundach, nie w godzinach.
• Hot wallet to nie skarbiec: minimalny float, surowe limity i niezależne sygnatury to konieczność.
• Transparentność i compliance: linia czasowa zgłoszeń ma znaczenie – opóźnienia generują ryzyko regulacyjne i reputacyjne.
• Ekosystem Solany wymaga precyzyjnej telemetrii przepływów SPL i automatycznego „rate limiting” wypłat.
• Użytkownicy: rotacja adresów i higiena operacyjna (2FA, cold storage) są krytyczne.

Źródła / bibliografia

1. Korea JoongAng Daily: „Upbit lost more than 100 billion crypto coins in less than an hour in November data breach” (linia czasowa, struktura aktywów, zgłoszenia). (Korea Joongang Daily)
2. KBS World: „Over 100 Billion Coins Stolen in 54 Minutes in Upbit Hack” (dane FSS, kwoty i czasy). (KBS World)
3. Reuters: „South Korea suspects North Korea behind hack of crypto exchange Upbit – Yonhap” (wstępna atrybucja do Lazarus). (Reuters)
4. The Korea Times: „Gov’t moves to strengthen crypto exchanges’ liability after Upbit hacking” (kierunek zmian regulacyjnych). (The Korea Times)
5. CCN: „Upbit Deletes All Deposit Addresses After Hack — Here’s What You Need to Do” (rotacja adresów depozytowych). (CCN.com)

Wprowadzenie do problemu / definicja luki

Barts Health NHS Trust (jeden z największych operatorów szpitali w Anglii) poinformował o kradzieży plików z bazy danych po ataku grupy Cl0p, która wykorzystała podatność typu zero-day w Oracle E-Business Suite (EBS). Skasowane dane dotyczą m.in. faktur z wieloletniego okresu i ujawniają imiona, nazwiska oraz adresy osób, które płaciły za leczenie lub usługi. Incydent nie dotknął elektronicznej dokumentacji medycznej ani systemów klinicznych. Zdarzenie miało miejsce w sierpniu 2025 r., a pliki pojawiły się w serwisie wyciekowym Cl0p w listopadzie 2025 r.. 5 grudnia 2025 r. Barts potwierdził sprawę publicznie.

W skrócie

• Wektor wejścia: zero-day w Oracle E-Business Suite, CVE-2025-61882 (RCE bez uwierzytelnienia przez HTTP).
• Skutek: kradzież plików z bazy (faktury, dane osób płacących, część byłych pracowników i dostawców).
• Zakres: dotyczy także plików księgowych usług świadczonych od kwietnia 2024 r. dla Barking, Havering and Redbridge University Hospitals NHS Trust (BHRUT), który opublikował osobny komunikat.
• Status techniczny: Oracle wydał pilny alert bezpieczeństwa i poprawki dla EBS 12.2.3–12.2.14.
• Atrybucja i kampania: skoordynowana fala kradzieży i wymuszeń na organizacjach z EBS, analizowana przez Google/Mandiant.

Kontekst / historia / powiązania

Według BleepingComputer, kampania Cl0p celowała globalnie w środowiska Oracle EBS, a lista potwierdzonych ofiar obejmuje m.in. instytucje akademickie i przedsiębiorstwa. W przypadku Barts Health atak wykryto dopiero po publikacji na „leak site” Cl0p; organizacja zapowiedziała uzyskanie sądowego zakazu dalszego rozpowszechniania danych.

Równolegle BHRUT potwierdził, że incydent obejmuje również jego dane, ponieważ kontrakt na system finansowy i Oracle obsługuje dla niego Barts Health. BHRUT podkreśla, że systemy kliniczne i nowy EPR nie zostały naruszone.

Analiza techniczna / szczegóły luki

Oracle opisał CVE-2025-61882 jako zdalnie wykorzystywaną RCE bez uwierzytelnienia w komponencie Oracle Concurrent Processing / BI Publisher Integration, możliwą do wyzwolenia przez HTTP. Luka dotyczy wersji 12.2.3–12.2.14 i posiada bazowy wynik CVSS 9.8. Oracle opublikował wskaźniki kompromitacji (IOCs) oraz zalecił niezwłoczne łatanie.

Analiza Google Threat Intelligence/Mandiant wskazuje, że aktor powiązany z marką CL0P eksploatował łańcuch(y) podatności w EBS co najmniej od 9 sierpnia 2025 r., a wcześniej (lipiec) obserwowano podejrzane próby. Opisano m.in. wektory obejmujące UiServlet i SyncServlet oraz nadużycie XDO Template Manager do osadzenia złośliwych szablonów XSL w bazie EBS, prowadzących do wykonania kodu (implanty Java: GOLDVEIN.JAVA / SAGEGIFT / SAGELEAF / SAGEWAVE).

Praktyczne konsekwencje / ryzyko

• Ryzyko dla osób: dane adresowe i rozliczeniowe mogą zostać użyte do ataków socjotechnicznych (phishing, vishing, próby wyłudzeń), mimo że same pliki nie dają bezpośredniego dostępu do kont. Barts podkreśla ostrożność wobec niezamówionych próśb o płatność/dane.
• Ryzyko dla organizacji: masowa eksploatacja publicznie dostępnych aplikacji ERP redukuje konieczność poruszania się po sieci ofiary—sprzyja cichej eksfiltracji danych i falowym kampaniom wymuszeń.
• Ryzyko prawne/regulacyjne: incydent zgłoszono do ICO; Barts i BHRUT współpracują z NCSC oraz organami ścigania.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IT/bezpieczeństwa korzystających z Oracle EBS:

1. Natychmiast zastosuj poprawki Oracle (Alert dla CVE-2025-61882 i późniejsze poprawki dla EBS), w tym wymagane pre-rekwizyty CPU.
2. Zapoluj na artefakty w bazie EBS: przeszukaj tabele XDO_TEMPLATES_B oraz XDO_LOBS pod kątem nieznanych/malicious szablonów (prefiks TMP/DEF, typ XSL-TEXT/XML) i anomalii w TemplatePreviewPG.
3. Ogranicz ruch wychodzący z serwerów EBS — zablokuj niepotrzebne połączenia do Internetu (utrudnia to pobieranie 2. etapu i eksfiltrację).
4. Monitoruj wzorce HTTP do UiServlet / SyncServlet oraz IOC z alertu Oracle (adresy IP, ciągi poleceń, sumy SHA256).
5. Twarde segmentowanie i kopie zapasowe aplikacji ERP; osobne konta serwisowe i rotacja haseł/kluczy używanych przez EBS. (zalecenie ogólne)

Dla działów ryzyka/zgodności:

• Ocena DPIA/ryzyka RODO dla procesów finansowych powiązanych z EBS; przygotowanie szablonów komunikacji do osób, których dane mogły zostać naruszone, i kanału wsparcia (FAQ, hotline). (zalecenie ogólne)

Dla osób, których dane mogły zostać ujawnione:

• Weryfikuj żądania płatności/aktualizacji danych tylko przez znane kanały; zachowaj czujność wobec prób socjotechniki, zgodnie z komunikatami Barts/BHRUT.

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

Kampania wokół Oracle EBS wpisuje się w taktykę znaną z wcześniejszych akcji Cl0p/FIN11 przeciwko MFT (Accellion FTA, GoAnywhere, MOVEit): masowa eksploatacja zero-day aplikacji brzegowych, szybka eksfiltracja, a ekspozycja ofiar i wymuszenia następują po tygodniach. W porównaniu z incydentami MFT, komponenty EBS (np. BI Publisher/XDO) dają inny zestaw wektorów RCE (XSL, servlet’y) i wymagają specyficznych polowań na artefakty w bazie.

Podsumowanie / kluczowe wnioski

• Incydent w Barts Health NHS i BHRUT to element szerszej fali wymuszeń na użytkownikach Oracle EBS; wektorem był CVE-2025-61882 (RCE, CVSS 9.8). Szybkie łatanie i detekcja artefaktów XDO w bazie są krytyczne.
• Dane kliniczne nie zostały dotknięte, lecz ryzyko socjotechniki wobec pacjentów/pracowników jest realne.
• Organizacje z EBS powinny przyjąć model „assume breach” i przeprowadzić threat hunting wg wskazówek Oracle/Mandiant.

Źródła / bibliografia

1. BleepingComputer — Barts Health NHS discloses data breach after Oracle zero-day hack (05.12.2025). (BleepingComputer)
2. Barts Health NHS — Cl0p cyberattack update (05.12.2025). (Barts Health NHS Trust)
3. BHR University Hospitals NHS Trust — Data incident (05.12.2025). (BHR Hospitals)
4. Oracle — Security Alert Advisory – CVE-2025-61882 (Oracle E-Business Suite) (10.2025). (Oracle)
5. Google Cloud / Mandiant — Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign (09–10.2025). (Google Cloud)

Wprowadzenie do problemu / definicja luki

Francuska organizacja Reporterzy bez Granic (RSF) została niedawno celem precyzyjnej kampanii spear-phishingowej przypisanej aktorowi Callisto/ColdRiver (znanemu także jako Star Blizzard) – grupie od lat łączonej przez rządy państw zachodnich z rosyjską FSB (Centrum 18). Atak rozpoczął się od wiadomości e-mail z fałszywą tożsamością zaufanego kontaktu i doprowadzał do złośliwego łańcucha przekierowań zakończonego zestawem phishingowym (AiTM) naśladującym logowanie do ProtonMail i zdolnym do przechwycenia haseł oraz 2FA. Incydent jako pierwszy nagłośnił Recorded Future News na podstawie analizy Sekoia.io.

W skrócie

• Cel: minimum dwa podmioty, w tym RSF; ukierunkowane na kradzież poświadczeń ProtonMail.
• Wejście: spear-phishing z podszyciem się pod zaufaną osobę, czasem “zapomniany załącznik” lub pozorny PDF (w istocie ZIP lub “zaszyfrowany” PDF z linkiem).
• Wykonanie: przekierowania przez skompromitowane strony → kit AiTM z prefill e-maila, wymuszeniem fokusu na polu hasła i relay 2FA.
• Atrybucja: Star Blizzard/Callisto/ColdRiver – aktor “niemal na pewno” podporządkowany FSB (Centrum 18) według NCSC/CISA.
• Kontekst: RSF od 14 sierpnia 2025 r. na liście “organizacji niepożądanych” w Rosji.

Kontekst / historia / powiązania

Star Blizzard (Callisto/ColdRiver) jest znany z wieloletnich kampanii wywiadowczych przeciwko NGO, rządom i podmiotom wspierającym Ukrainę. Wspólne doradztwa NCSC/CISA z grudnia 2023 r. opisują dojrzałe łańcuchy spear-phishingowe oraz konsekwentny dobór celów wysokiej wartości. RSF z kolei wspiera dziennikarzy pod presją (m.in. rosyjskich), co czyni tę organizację logicznym celem operacji wpływu i rozpoznania. Dodatkowo, RSF została formalnie uznana w Rosji za “niepożądaną” – co podnosi prawdopodobieństwo motywacji politycznej ataku.

Analiza techniczna / szczegóły luki

Wejście socjotechniczne.
Operator użył adresu ProtonMail stylizowanego na zaufaną osobę i wysłał e-mail po francusku z prawidłową sygnaturą. Warianty obejmowały:

• Wiadomość bez załącznika (“proszę o opinię”), aby skłonić ofiarę do poproszenia o ponowne wysłanie dokumentu.
• Fałszywy PDF (w praktyce ZIP z rozszerzeniem .pdf) albo “zaszyfrowany PDF” z instrukcją otwarcia w ProtonDrive. Po kliknięciu ofiara trafiała przez kompromitowany serwer na docelowy kit phishingowy.

Kit AiTM i mechanika kradzieży.
Zestaw phishingowy (hostowany m.in. na account.simpleasip[.]org) imituje stronę logowania ProtonMail i:

• Automatycznie wypełnia pole e-mail ofiary.
• Wymusza kursor na polu hasła (skrypt JS przywraca fokus co 250 ms) zwiększając szansę wpisania hasła.
• Pośredniczy w 2FA (Adversary-in-the-Middle), prezentując prawdziwe okna CAPTCHA/2FA, a po udanym logowaniu widoczna jest aktywność z adresów proxy (np. 196.44.117[.]196).
• Część JS ma tę samą nazwę pliku co oryginał Proton, ale jest spatchowana, by wstrzykiwać własne callbacki (np. ownershipSubmitCallback).

Infrastruktura i IOCs.
SEKOIA wskazuje PHP-owe redirectory na skompromitowanych WordPressach oraz charakterystyczny wzorzec parametrów (utm_refferer). Lista obserwowanych domen obejmuje m.in. proton-decrypt[.]com, onlineviewdoc[.]com, documentsec[.]com i kilkadziesiąt innych; część została sinkholowana przez MSTIC. (Pełna lista w raporcie SEKOIA).

Praktyczne konsekwencje / ryzyko

• Ryzyko kompromitacji skrzynek e-mail i tożsamości w NGO, redakcjach i think-tankach – wprost uderzające w bezpieczeństwo źródeł i ciągłość działań defensywnych/advocacy.
• Ominięcie 2FA przez AiTM podnosi skuteczność ataków wobec zespołów, które polegały wyłącznie na TOTP/SMS.
• Dalsza eskalacja: pivot do chmur, M365/Google Workspace, wyciek korespondencji, operacje informacyjne oparte na wykradzionych materiałach.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT Sec (od razu):

1. Zablokuj i monitoruj IOCs oraz wzorce z raportu SEKOIA (domeny, ścieżki PHP, IP/ASN proxy). Wdróż HTTP request filtering dla znanych ścieżek redirectorów WP (/wp-content/plugins/*/*.php).
2. Wymuś FIDO2/WebAuthn dla poczty i krytycznych aplikacji (rezyliencja na AiTM lepsza niż TOTP/SMS).
3. Włącz Continuous Access Evaluation / token binding i Conditional Access (m.in. blokada niezarządzanych przeglądarek, wymóg MFA phishing-resistant).
4. DMARC/DKIM/SPF – ścisłe polityki i SPF flattening; monitoruj spoofing domen partnerów.
5. Egress DNS/HTTP e-tags: wykrywaj nietypowe domeny “living-off-the-land” (np. *viewdoc*, *proton* + słowa “decrypt”, “account”, “drive”).
6. Instrumentacja przeglądarek: reguły na focus() loop i różnice w ładunkach JS względem oryginalnych zasobów dostawcy (np. hash statycznego public-index.*.js Proton vs. serwis atakującego).

Dla użytkowników wysoko-ryzykownych (dział PR/advocacy, redaktorzy, badacze):

• Nie odpowiadaj na “zapomniane załączniki”; nie otwieraj PDF z prośbą o logowanie do zewnętrznego serwisu.
• Zawsze weryfikuj nadawcę innym kanałem (telefon, szyfrowany komunikator).
• Używaj kluczy bezpieczeństwa (FIDO2) i profile’ów przeglądarki “wysokiego ryzyka” z izolacją.
• Zgłaszaj podejrzane Proton/Drive linki – Proton szybko blokuje konta operatorów, co potwierdziło przerwanie łańcucha w tym incydencie.

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

Star Blizzard w 2024/2025 testował też nietypowe wektory socjotechniczne (np. zaproszenia do grup WhatsApp). Obecna kampania wobec RSF wraca do dojrzałego, “klasycznego” spear-phishingu z AiTM i redirectorami – technicznie bardziej zbliżona do opisów w doradztwach NCSC/CISA niż do eksperymentalnych wektorów z początku 2025 r.

Podsumowanie / kluczowe wnioski

• Atak na RSF wykorzystuje prosty, lecz dopracowany łańcuch socjotechniczny i kit AiTM – zdolny do obejścia 2FA.
• Atrybucja do Star Blizzard/Callisto jest spójna z wcześniejszymi TTP i potwierdzonym profilem celów.
• Organizacje medialne i prawoczłowiecze (zwłaszcza związane z Rosją/Ukrainą) powinny pilnie wdrożyć FIDO2, hardening przeglądarek, oraz ścisłe kontrole e-mail.

Źródła / bibliografia

1. Recorded Future News – Phishing attempt against Reporters Without Borders attributed to Russia-linked group (4 grudnia 2025). (The Record from Recorded Future)
2. Sekoia.io – French NGO Reporters Without Borders targeted by Calisto in recent campaign (3 grudnia 2025) – analiza TTP, AiTM, IOCs. (Sekoia.io Blog)
3. UK NCSC – Star Blizzard continues spear-phishing campaigns (7 grudnia 2023) – atrybucja do FSB/Centrum 18. (NCSC)
4. CISA – AA23-341A: Russia-based Star Blizzard spear-phishing (7 grudnia 2023) – TTP, sektorowe cele. (cisa.gov)
5. RSF – RSF listed as “undesirable organisation” in Russia (14 sierpnia 2025). (Reporters Without Borders)