Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 375 z 487

Autor: Wojciech Ciemski

Nike bada możliwy incydent bezpieczeństwa. WorldLeaks grozi publikacją danych – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

W tego typu sprawach kluczowe jest rozróżnienie: nie zawsze mamy potwierdzone naruszenie (data breach), nawet jeśli grupa przestępcza publikuje wpis na swoim „leak site”. Coraz częściej obserwujemy model wymuszeń oparty wyłącznie o kradzież danych i groźbę ich upublicznienia (bez szyfrowania systemów). Taki „hack & leak” bywa dla ofiary trudniejszy: kopie zapasowe nie rozwiązują problemu, bo presja wynika z ryzyka reputacyjnego, prawnego i konkurencyjnego.

W przypadku Nike publicznie wiadomo przede wszystkim tyle, że firma prowadzi dochodzenie po tym, jak WorldLeaks ogłosił ją jako ofiarę i uruchomił licznik do publikacji danych.

W skrócie

  • 22 stycznia 2026: Nike zostało wymienione jako ofiara na torowym serwisie wyciekowym grupy WorldLeaks; wpis zawierał odliczanie do ujawnienia danych.
  • 24 stycznia 2026: według opisu w mediach branżowych licznik wskazywał publikację na ten dzień, o ile nie dojdzie do zapłaty/porozumienia.
  • Nike potwierdziło, że „bada potencjalny incydent cyberbezpieczeństwa” i „aktywnie ocenia sytuację”.
  • Na moment publikacji informacji grupa nie podała (publicznie) skali ani rodzaju rzekomo wykradzionych danych.

Kontekst / historia / powiązania

WorldLeaks to marka, która jest szeroko opisywana jako pivot/rebrand Hunters International – grupy znanej z działań ransomware, która w 2025 r. ogłaszała zamknięcie operacji i „morfowanie” w kierunku czystej eksfiltracji i szantażu danymi.

Z perspektywy „ekosystemu” to ważne, bo oznacza przejście od klasycznego „zablokuję ci systemy” do „zabiorę ci dane i zrobię z nich broń”. Profile threat-intel wskazują, że WorldLeaks funkcjonuje w modelu Extortion-as-a-Service (platforma/portale do negocjacji i publikacji), a infrastruktura bywa rozbudowana o elementy typowo „PR-owe” dla przestępców (np. kanały ułatwiające nagłośnienie wycieku).

Analiza techniczna / szczegóły incydentu

Co wiemy technicznie o zdarzeniu Nike?

Publicznie nie ma (na ten moment) raportu technicznego: brak IOC, brak potwierdzonego wektora wejścia, brak wskazanych systemów czy usług. Mamy natomiast klasyczny wzorzec dla grup nastawionych na wymuszenie: wpis na leak site + deadline.

Jak zwykle wygląda łańcuch ataku w modelu WorldLeaks

W profilach operacyjnych tej grupy (i podobnych) powtarzają się następujące drogi uzyskania dostępu:

  • skompromitowane konta (valid accounts),
  • zewnętrzne usługi zdalne (external remote services) i braki w MFA,
  • phishing,
  • eksploatacja aplikacji wystawionych do Internetu.

Po wejściu do środowiska priorytetem jest odszukanie wartościowych repozytoriów (projekty, dokumenty prawne/HR, dane partnerów, IP) i eksfiltracja – często „cicho”, bez natychmiastowego szyfrowania. To spójne z trendem, w którym przestępcy redukują „hałas” operacyjny, bo presję na ofiarę buduje groźba ujawnienia danych.

Praktyczne konsekwencje / ryzyko

W scenariuszu, w którym doszło do realnej eksfiltracji, ryzyka zwykle układają się w 4 warstwach:

  1. Ryzyko prawne i regulacyjne – obowiązki notyfikacyjne (w zależności od jurysdykcji i kategorii danych), pozwy zbiorowe, audyty.
  2. Ryzyko konkurencyjne – wyciek IP (projekty, roadmapy, umowy, dane dot. łańcucha dostaw).
  3. Ryzyko dla osób – jeśli w paczce są dane pracowników/klientów, rośnie ryzyko phishingu, podszyć i fraudów.
  4. Ryzyko wtórnej kompromitacji – wykradzione sekrety (tokeny, klucze, hasła w dokumentach) mogą otwierać drogę do kolejnych ataków.

Istotne: nawet jeśli firma szybko „posprząta” dostęp napastnika, wyciek może nastąpić później, bo dźwignią jest już sama kopia danych poza organizacją.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny, bezpieczny schemat działań (zbieżny z podejściem NIST do reagowania na incydenty: przygotowanie → detekcja/analiza → ograniczenie/usunięcie skutków → odtworzenie → wnioski).

0–24h: ogranicz straty i zabezpiecz dowody

  • Zamroź ryzyko eksfiltracji: ogranicz egress (proxy/firewall), włącz reguły na duże transfery, sprawdź nietypowe kanały (SFTP, Rclone, chmury prywatne).
  • Oceń tożsamość: wymuś reset haseł, rotację tokenów/kluczy, przegląd kont uprzywilejowanych; natychmiastowe MFA wszędzie, gdzie to możliwe.
  • Zabezpiecz dowody: kopie logów (IdP, VPN, EDR, CASB, M365/Google), snapshoty krytycznych hostów – zanim zmiany utrudnią analizę.
  • Ustaw „war room”: jedna ścieżka decyzyjna (SecOps/IR + Legal + PR + zarząd).

24–72h: odpowiedz „pod wyciek”, nie tylko „pod włamanie”

  • Ustal zakres danych: które repozytoria i wolumeny mogły wyjść (DLP, SIEM, logi pobrań, audyty dostępu).
  • Przygotuj komunikację: szablony dla klientów/partnerów/pracowników; scenariusze na publikację fragmentów danych.
  • Wzmocnij monitoring: obserwuj wzmożony spear-phishing (na podstawie tematów i nazw projektów, jeśli wyciek dotyczy dokumentów).
  • Wnioski i hardening: zamknij wektor wejścia (tożsamość, exposed services, podatności), a potem dopiero „poleruj” środowisko.

Uwaga praktyczna: w modelu „hack & leak” krytyczne jest traktowanie sprawy jako incydentu naruszenia poufności, a nie wyłącznie „nieautoryzowanego dostępu”. To inne priorytety i inny zestaw interesariuszy.

Różnice / porównania z innymi przypadkami

Klasyczny ransomware (szyfrowanie) uderza w dostępność i ciągłość działania.
Czysta eksfiltracja i szantaż uderza w poufność, reputację i ryzyko prawne – a przez to potrafi być bardziej „długodystansowa”.

WorldLeaks jest często opisywany jako przykład tej ewolucji: formalnie „odchodzenie od szyfrowania”, nacisk na wykradanie danych i publikacje na leak site.

Podsumowanie / kluczowe wnioski

  • Nike potwierdziło, że bada potencjalny incydent, po wpisie grupy WorldLeaks z odliczaniem do publikacji.
  • Brak twardych danych technicznych oznacza, że na tym etapie należy unikać spekulacji o wektorze wejścia – ale model wymuszenia (deadline + leak site) jest czytelny.
  • Dla organizacji najważniejsze są działania „pod wyciek”: ograniczenie eksfiltracji, kontrola tożsamości, ochrona dowodów i gotowość komunikacyjno-prawna (NIST IR).

Źródła / bibliografia

  1. SecurityWeek – Nike Probing Potential Security Incident as Hackers Threaten to Leak Data (24.01.2026). (SecurityWeek)
  2. SecurityWeek – Hunters International Shuts Down… as It Morphs Into World Leaks (07.07.2025). (SecurityWeek)
  3. Halcyon – Threat Actor Profile: World Leaks (informacje o rebrandzie, infrastrukturze, afiliacjach). (Halcyon)
  4. Blackpoint Cyber – Threat Profile: World Leaks Ransomware (wektory wejścia, mapowania ATT&CK, model data extortion). (Blackpoint)
  5. NIST – SP 800-61r3 (Incident Response Recommendations…) (04.2025, publikacja/wersja robocza – rekomendacje IR). (NIST Publications)

Under Armour bada incydent: wyciek danych (72,7 mln rekordów) i ryzyko ukierunkowanego phishingu

Wprowadzenie do problemu / definicja luki

Under Armour potwierdził, że analizuje zgłoszenia dotyczące nieautoryzowanego dostępu do danych klientów, po tym jak w sieci pojawiła się paczka rekordów przypisywana firmie. Kluczowe jest to, że w dostępnych doniesieniach chodzi przede wszystkim o dane identyfikacyjne i profilowe (np. e-mail, imię i nazwisko, data urodzenia, płeć, lokalizacja, informacje o zakupach), a nie o dane płatnicze czy hasła.

W skrócie

  • Skala: ok. 72,7 mln kont / adresów e-mail (wg Have I Been Pwned).
  • Czas: incydent miał wystąpić w listopadzie 2025, a dane zostały upublicznione w styczniu 2026 i dodane do HIBP 21 stycznia 2026.
  • Atrybucja: w tle pojawia się Everest (ransomware) oraz wątek próby wymuszenia okupu.
  • Stanowisko firmy: Under Armour twierdzi, że nie ma dowodów, by incydent dotknął UA.com, systemów płatności lub systemów przechowywania haseł.

Kontekst / historia / powiązania

Z perspektywy krajobrazu zagrożeń to klasyczny scenariusz „ransomware + wyciek danych”: grupa ogłasza ofiarę, próbuje wymusić okup, a po braku płatności publikuje dane na forach/„leak site”. W przypadku Under Armour taka narracja pojawia się w odniesieniu do Everest, który miał wskazywać na przejęcie dużej paczki danych (rzędu setek GB).

Warto też pamiętać, że to nie pierwszy głośny incydent w ekosystemie Under Armour: w 2018 r. ujawniono naruszenie dotyczące MyFitnessPal (wówczas mowa była o ogromnej bazie kont).

Analiza techniczna / szczegóły incydentu

Co wiemy na podstawie wiarygodnych źródeł:

  • HIBP opisuje zestaw danych zawierający m.in. adresy e-mail, imiona i nazwiska, daty urodzenia, płeć, lokalizację geograficzną oraz informacje o zakupach.
  • TechCrunch informuje, że w próbce danych znajdowały się rekordy zakupowe oraz „sporo” adresów e-mail należących do pracowników Under Armour (co zwiększa ryzyko ataków ukierunkowanych na firmę).
  • BankInfoSecurity i The Register wiążą publikację danych z Everest, który miał wcześniej umieścić Under Armour na swoim „leak site” w ramach presji po rzekomej próbie extortion.
  • Under Armour komunikuje, że na tym etapie brak dowodów na kompromitację systemów płatniczych i haseł.

Czego nie wiemy (a co ma znaczenie operacyjne):

  • Nie ma publicznie potwierdzonego technicznego opisu wektora wejścia (brak IOCs/TTPs po stronie ofiary), czasu utrzymania dostępu, ani pewnego potwierdzenia pełnego zakresu danych ponad to, co trafiło do analiz HIBP i mediów.

Praktyczne konsekwencje / ryzyko

Nawet jeśli hasła i dane płatnicze nie zostały przejęte, zestaw typu „e-mail + dane profilowe + historia zakupów” jest wyjątkowo użyteczny dla przestępców:

  1. Spear phishing / brand impersonation
    Atakujący mogą tworzyć bardzo wiarygodne wiadomości „od Under Armour” (np. zwrot, rabat, „problem z dostawą”), dopasowane do zakupów/oferty.
  2. Ataki na konta w innych serwisach (credential stuffing pośredni)
    Nawet bez haseł, sama wiedza o e-mailu + danych identyfikacyjnych ułatwia odzyskiwanie kont, socjotechnikę lub dopasowanie ofiar do innych wycieków.
  3. Ryzyko dla firmy (B2E/BEC, pretexting na pracowników)
    Jeśli w paczce są e-maile pracowników, rośnie ryzyko: fałszywych faktur, przejęć skrzynek, „pilnych” próśb od rzekomych przełożonych itp.

Rekomendacje operacyjne / co zrobić teraz

Dla klientów/użytkowników

  • Sprawdź swój e-mail w HIBP i włącz powiadomienia o kolejnych naruszeniach.
  • Zmień hasła tam, gdzie były powiązane (zwłaszcza jeśli stosowałeś/aś to samo hasło w wielu serwisach) i przejdź na unikalne hasła z menedżera.
  • Włącz MFA wszędzie, gdzie to możliwe (aplikacja uwierzytelniająca > SMS).
  • Uważaj na maile/SMS-y o „zwrotach”, „kuponach” i „problemach z płatnością” – weryfikuj linki i nie podawaj danych na stronach z wiadomości.

Dla zespołów bezpieczeństwa i IT (jeśli masz wpływ organizacyjny)

  • Podnieś czujność antyphishingową (banery „external”, sandboxing URL, ochrona przed look-alike domains).
  • Upewnij się, że domena organizacji ma DMARC/DKIM/SPF w trybie egzekwowania (p=reject/quarantine) – to ogranicza podszywanie się w kampaniach.
  • Wdróż/zweryfikuj procesy rapid takedown (phishing pages) i komunikacji kryzysowej.

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

  • 2018 (MyFitnessPal): tam doniesienia dotyczyły bardzo dużej bazy kont i (historycznie) w takich incydentach często istotnym elementem są hasła (choćby hashe).
  • 2025/2026 (obecny incydent): z dostępnych informacji wynika, że kluczowa wartość dla atakujących to dane profilowe i zakupowe, a Under Armour podkreśla brak dowodów na kompromitację systemów haseł i płatności.

Podsumowanie / kluczowe wnioski

  • Incydent – według HIBP i mediów – może dotyczyć ok. 72,7 mln rekordów, obejmujących e-mail i dane profilowo-zakupowe.
  • Nawet bez haseł to paliwo dla bardzo skutecznego phishingu i oszustw „na Under Armour”.
  • Najrozsądniejsze działania „tu i teraz” to: sprawdzenie HIBP, zmiana haseł (jeśli były współdzielone), MFA oraz ostrożność wobec wiadomości o zwrotach/rabatach.

Źródła / bibliografia

  1. Associated Press (przedruk m.in. w SecurityWeek): informacje o dochodzeniu i stanowisku firmy (AP News)
  2. TechCrunch: próbka danych, kontekst publikacji na forum, cytaty rzecznika (TechCrunch)
  3. Have I Been Pwned: karta incydentu (zakres danych, liczba kont, daty) (Have I Been Pwned)
  4. BankInfoSecurity: powiązanie z Everest, narracja o extortion/leaku (bankinfosecurity.com)
  5. The Register: chronologia (publikacja 18 stycznia 2026), dodatkowe twierdzenia Everest (theregister.com)

CVE-2026-24061: krytyczne obejście uwierzytelnienia w GNU InetUtils telnetd daje zdalny dostęp root

Wprowadzenie do problemu / definicja luki

CVE-2026-24061 to krytyczna podatność typu authentication bypass w serwerze GNU InetUtils telnetd, która pozwala atakującemu zalogować się zdalnie bez hasła, uzyskując uprawnienia dowolnego użytkownika – w praktyce najczęściej root. Problem dotyczy mechanizmu uruchamiania /usr/bin/login przez telnetd i błędnego traktowania danych kontrolowanych przez klienta jako „bezpiecznych” argumentów wywołania.

W skrócie

  • CVE: CVE-2026-24061 (MITRE/NVD), klasa błędu: CWE-88 (argument injection).
  • Dotyczy: GNU InetUtils 1.9.3–2.7 (luka obecna od 2015 r.).
  • Skutek: obejście uwierzytelnienia i uzyskanie dostępu (często jako root).
  • Status: obserwowano aktywne próby wykorzystania krótko po ujawnieniu.
  • Naprawa: BleepingComputer wskazuje, że problem został załatany w GNU InetUtils 2.8; dodatkowo zalecane są mitigacje (wyłączenie Telnet/port 23).

Kontekst / historia / powiązania

Podatność została publicznie opisana 20 stycznia 2026 r. przez maintenera/kontrybutora GNU InetUtils, Simona Josefssona, wraz z historią wskazującą na commit z 19 marca 2015 r., który wprowadził ryzykowną ścieżkę przetwarzania danych.

Choć Telnet jest protokołem legacy, nadal bywa spotykany w środowiskach przemysłowych/OT i w urządzeniach „z długim cyklem życia”, gdzie modernizacja bywa kosztowna lub operacyjnie trudna. To właśnie tam takie „stare” podatności potrafią mieć nieproporcjonalnie wysoki wpływ.

Analiza techniczna / szczegóły luki

Sedno problemu: telnetd uruchamia /usr/bin/login (zwykle działający z wysokimi uprawnieniami), przekazując do niego wartość zmiennej środowiskowej USER, którą w tym przypadku może dostarczyć klient Telnet. Brak właściwej sanitacji powoduje, że odpowiednio spreparowana wartość USER zostaje potraktowana jako parametr dla login(1), co umożliwia obejście standardowego procesu logowania.

To klasyczny przypadek argument injection (CWE-88): dane, które powinny być „czystą wartością”, trafiają do kontekstu, gdzie znaki/ciągi mają znaczenie składniowe dla programu wywoływanego.

Dodatkowy, praktyczny aspekt ryzyka opisany w analizie SafeBreach: błąd ma charakter „oldschoolowy”, jest prosty do automatyzacji, a badacze pokazali root cause oraz mechanikę negocjacji Telnet/ustawiania środowiska w kontekście procesu usługi.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyko to pełne przejęcie hosta (root) przy ekspozycji telnetd na sieć nieufną. W praktyce przekłada się to na:

  • kradzież danych i tajemnic (odczyt plików, konfiguracji, kluczy),
  • modyfikację konfiguracji i backdooryzację (np. trwałość poprzez klucze SSH),
  • uruchamianie złośliwego kodu, skanowanie sieci wewnętrznej, ruch boczny.

W obserwacjach telemetrycznych przytoczonych przez BleepingComputer (na bazie danych firmy monitorującej zagrożenia) próby ataków obejmowały automatyczne działania post-exploitation (rekonesans, próby persystencji i wdrożenia malware), przy czym część prób miała się nie powieść ze względu na braki w środowisku ofiar. To ważny sygnał: łańcuchy ataków będą optymalizowane, gdy tylko atakujący zidentyfikują „działające” kombinacje.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję Telnet (port 23)
    • Sprawdź, czy cokolwiek nasłuchuje na TCP/23 oraz czy usługa to faktycznie GNU InetUtils telnetd (nie każdy telnetd jest tym samym).
  2. Zaktualizuj / załatkaj
    • Jeśli używasz GNU InetUtils w zakresie wersji podatnych (1.9.3–2.7), priorytetem jest przejście na wydanie zawierające poprawkę (w doniesieniach: 2.8).
  3. Mitigacje, gdy patchowanie jest trudne (OT/legacy)
    • Wyłącz Telnet, jeśli to możliwe.
    • Jeśli Telnet jest „nie do ruszenia”: nie wystawiaj go do Internetu, ogranicz dostęp segmentacją, ACL na firewallu, oraz używaj kontrolowanego dostępu typu VPN / ZTNA.
  4. Detekcja i monitoring
    • Podnieś poziom monitoringu połączeń do telnetd (nietypowe źródła, skoki liczby sesji, nowe geolokalizacje).
    • Koreluj logi uwierzytelnienia i uruchamiania sesji (szczególnie „logowania”, które nie powinny przechodzić normalnej ścieżki).
  5. Hardening
    • Traktuj Telnet jako techniczny dług: planowo migruj na SSH lub dedykowane mechanizmy z silnym uwierzytelnianiem i szyfrowaniem.

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

CVE-2026-24061 jest dobrym przykładem podatności, które wracają w różnych formach od lat:

  • „Zaufane dane” przekazane do uprzywilejowanego procesu (tu: login(1) uruchamiany przez usługę),
  • błędy granicy zaufania: coś, co wygląda jak „zmienna środowiskowa”, w praktyce jest danymi z sieci,
  • argument injection zamiast klasycznego command injection — skutki mogą być równie krytyczne, gdy wywoływany komponent ma funkcje „pomijania” zabezpieczeń.

W odróżnieniu od wielu nowoczesnych podatności, tutaj nie ma skomplikowanej kryptografii czy deserializacji: to „prosty błąd kleju” między usługą a narzędziem systemowym — dlatego bywa tak łatwy do masowej automatyzacji.

Podsumowanie / kluczowe wnioski

  • CVE-2026-24061 umożliwia zdalne obejście logowania w GNU InetUtils telnetd przez błąd argument injection związany z przekazaniem kontrolowanej przez klienta wartości do login(1).
  • Podatność dotyczy wersji 1.9.3–2.7 i jest związana z kodem obecnym od 2015 r.; opisy wskazują na poprawkę w 2.8.
  • Mimo „legacy” charakteru Telnet, realne środowiska (zwłaszcza OT/embedded) nadal mogą być narażone, a próby wykorzystania były obserwowane wkrótce po ujawnieniu.
  • Priorytetem jest wyłączenie Telnet / ograniczenie dostępu / szybkie aktualizacje oraz podniesienie monitoringu.

Źródła / bibliografia

  1. BleepingComputer — „Hackers exploit critical telnetd auth bypass flaw to get root” (23.01.2026). (BleepingComputer)
  2. oss-security (seclists.org) — „GNU InetUtils Security Advisory: remote authentication by-pass in telnetd” (20.01.2026). (seclists.org)
  3. NVD/NIST — rekord CVE-2026-24061 (publikacja 21.01.2026). (NVD)
  4. SafeBreach Labs — „Root Cause Analysis & PoC… CVE-2026-24061” (22.01.2026). (SafeBreach)
  5. Centre for Cybersecurity Belgium (CCB) — advisory i zalecenia dot. telnetd auth bypass. (ccb.belgium.be)

MaliciousCorgi: złośliwe „AI assistants” w VS Code Marketplace wykradają kod i sekrety deweloperów

Wprowadzenie do problemu / definicja luki

Ekosystem rozszerzeń do Visual Studio Code (VS Code) jest jednym z najszybszych wektorów „supply chain” w środowiskach developerskich: instalujesz wtyczkę, a ona uruchamia się z uprawnieniami porównywalnymi do samego edytora (czyli potencjalnie: pliki, sieć, procesy, ustawienia). Microsoft wprost podkreśla, że extension host ma te same uprawnienia co VS Code, więc rozszerzenie może robić niemal wszystko, co potrafi edytor.

Na tym tle pojawił się przypadek kampanii nazwanej MaliciousCorgi: dwie bardzo popularne wtyczki „AI coding assistant” z oficjalnego VS Code Marketplace miały realną funkcjonalność… i jednocześnie potajemnie eksfiltrowały zawartość plików oraz profilowały użytkowników.

W skrócie

  • Zidentyfikowano dwie wtyczki z łączną liczbą instalacji ok. 1,5 mln, reklamowane jako asystenci AI.
  • Według analizy Koi Security, rozszerzenia działały „zgodnie z obietnicą”, ale równolegle uruchamiały ukryte kanały zbierania danych bez jasnej zgody użytkownika.
  • Mechanika obejmowała m.in. wysyłkę całych plików po ich otwarciu, zrzuty zmian przy edycji oraz zdalnie sterowane „mass harvesting” do 50 plików z workspace.
  • W webview osadzono niewidoczny (0-pixel) iframe ładujący komercyjne SDK analityczne (profilowanie).
  • IOCs (wg Koi): identyfikatory rozszerzeń whensunset.chatgpt-china, zhukunpeng.chat-moss oraz domena aihao123.cn.
  • Microsoft zadeklarował, że bada zgłoszenie (aktualizacja w artykule z 24 stycznia 2026).

Kontekst / historia / powiązania

Wtyczki do VS Code są szczególnie „socjotechniczne”: popularność, oceny i obietnica zwiększenia produktywności (zwłaszcza „AI”) skutecznie obniżają czujność. W MaliciousCorgi dodatkowym problemem była skala instalacji i to, że rozszerzenia faktycznie dostarczały oczekiwane funkcje, co utrudniało szybkie wykrycie przez użytkowników.

Ten przypadek wpisuje się w szerszy trend nadużyć marketplace’ów dla deweloperów (rozszerzenia, paczki, pluginy). Przykładowo pod koniec 2025 r. opisywano inne kampanie złośliwych rozszerzeń VS Code, które podszywały się pod motywy lub narzędzia AI i kradły dane.

Analiza techniczna / szczegóły luki

1) Które rozszerzenia?

Według BleepingComputer/Koi chodzi o:

  • ChatGPT – 中文版 (publisher: WhenSunset, ok. 1,34–1,35 mln instalacji)
  • ChatMoss (CodeMoss) (publisher: zhukunpeng, ok. 150 tys. instalacji)

2) Trzy kanały wycieku danych (wg Koi)

Kanał 1: Real-time file monitoring

  • Po samym otwarciu pliku rozszerzenie czyta jego całą zawartość, koduje Base64 i wysyła dalej (przez webview/ukryty mechanizm śledzący).
  • Dodatkowo przechwytuje każdą zmianę (eventy edycji).

Kanał 2: Server-controlled mass harvesting

  • Serwer może zdalnie wywołać komendę zbierającą pliki z workspace (bez interakcji użytkownika).
  • W opisie Koi pojawia się pole jumpUrl w odpowiedzi serwera, parsowane jako JSON; gdy serwer zwróci "type":"getFilesList", uruchamia się zbiórka do 50 plików i wysyłka.

Kanał 3: Profilowanie użytkownika

  • Webview zawiera niewidoczny iframe 0 px, który ładuje cztery komercyjne SDK analityczne: Zhuge.io, GrowingIO, TalkingData i Baidu Analytics.
  • Celem nie jest „telemetria edytora”, tylko budowanie profilu (fingerprinting, zachowania, metadane aktywności).

3) Infrastruktura i IOCs

Koi podaje wprost identyfikatory rozszerzeń oraz domenę powiązaną z kampanią:

  • whensunset.chatgpt-china
  • zhukunpeng.chat-moss
  • domena: aihao123.cn

Praktyczne konsekwencje / ryzyko

Najbardziej dotkliwy element MaliciousCorgi to kradzież całych plików i workspace, a więc:

  • kod źródłowy (w tym nieopublikowane funkcje, algorytmy, logika biznesowa),
  • konfiguracje środowiskowe,
  • sekrety: .env, klucze API, tokeny, hasła do baz, pliki typu credentials.json, klucze SSH (jeśli trzymane w repo lub workspace),
  • dane o użytkowniku i organizacji (profilowanie + potencjalne targetowanie kolejnych etapów ataku).

W praktyce oznacza to ryzyka: utraty IP, przejęć usług w chmurze (dzięki kluczom), kompromitacji pipeline CI/CD, a nawet kolejnych włamań „lateral movement”, jeśli skradzione sekrety są współdzielone między środowiskami.

Rekomendacje operacyjne / co zrobić teraz

Dla pojedynczych deweloperów

  1. Sprawdź zainstalowane rozszerzenia i usuń podejrzane pozycje (szczególnie te wskazane w IOC).
  2. Zrotuj sekrety: klucze API, tokeny, hasła, klucze SSH, credentials do chmury (priorytet dla tych, które mogły trafić do workspace).
  3. Przejrzyj logi ruchu wychodzącego (DNS/HTTP) pod kątem aihao123.cn oraz nietypowych połączeń wykonywanych podczas pracy w VS Code.
  4. Jeśli pracujesz na repo firmowym: poinformuj SecOps/IR i potraktuj to jako potencjalny incydent wycieku kodu.

Dla zespołów i organizacji

  1. Polityka allowlist/denylist dla rozszerzeń (MDM/Intune/konfiguracja VS Code) + wymuszanie zatwierdzonych publisherów. (Microsoft udostępnia mechanizmy oceny zaufania wydawcy, m.in. Verified Publisher i dialog zaufania).
  2. Egress control dla stacji developerskich (proxy, DNS filtering), alertowanie na nowe domeny i nietypowy ruch z procesu VS Code / extension host.
  3. Proces zgłaszania i takedownu: jeśli wykryjesz złośliwe rozszerzenie, przygotuj raport z identyfikatorem, opisem zachowań i IOC — to przyspiesza reakcję zespołu Marketplace (Checkmarx opisuje praktykę „thorough report” i szybkie usuwanie po weryfikacji).
  4. W przypadku podejrzenia wycieku: uruchom IR playbook dla kradzieży sekretów (rotacje, przegląd uprawnień, sprawdzenie nietypowych logowań do chmury/VCS).

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

  • „Normalny” asystent AI zwykle wysyła ograniczony kontekst (np. fragment wokół kursora) w celu podpowiedzi. MaliciousCorgi przekracza tę granicę: eksfiltruje całe pliki po otwarciu i potrafi zdalnie zainicjować zrzut wielu plików z workspace.
  • W odróżnieniu od kampanii stricte malware/stealer (np. opisywanych w 2025 r.), tu „przynętą” jest działająca funkcja AI, a mechanizmy są ukryte w tle, co poprawia „retencję” ofiar i utrudnia wykrycie.
  • Profilowanie przez komercyjne SDK w iframe (Zhuge/GrowingIO/TalkingData/Baidu) to podejście bliższe ekosystemowi marketing/trackingu niż klasycznemu malware — ale w kontekście IDE jest równie groźne, bo wspiera selekcję celów i timing eksfiltracji.

Podsumowanie / kluczowe wnioski

MaliciousCorgi to bardzo czytelny sygnał ostrzegawczy dla zespołów developerskich: „działa i ma dobre oceny” nie oznacza „jest bezpieczne”, a rozszerzenia VS Code mają realną moc (pliki + sieć) porównywalną do samego edytora.

Jeśli w organizacji dopuszczacie narzędzia AI w IDE, potrzebujecie minimum: allowlisty rozszerzeń, kontroli ruchu wychodzącego, procesu audytu publisherów oraz szybkiej procedury rotacji sekretów po incydencie.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu, lista rozszerzeń, 3 mechanizmy zbierania danych, stanowisko Microsoft (23–24 stycznia 2026). (BleepingComputer)
  2. Koi Security – analiza kampanii MaliciousCorgi (22 stycznia 2026), kanały 1–3, IOCs. (koi.ai)
  3. Microsoft VS Code Docs – Extension runtime security (model uprawnień, zaufanie do publisherów, zabezpieczenia Marketplace). (Visual Studio Code)
  4. Checkmarx – praktyka zgłaszania i zdejmowania złośliwych rozszerzeń z Marketplace (proces i oczekiwania raportowe). (Checkmarx)
  5. The Hacker News – kontekst wcześniejszych złośliwych rozszerzeń VS Code atakujących deweloperów (grudzień 2025). (The Hacker News)

Cyberatak na Staatliche Kunstsammlungen Dresden (SKD): co wiemy o incydencie i jak ograniczać skutki podobnych ataków

Wprowadzenie do problemu / definicja luki

Staatliche Kunstsammlungen Dresden (SKD) – jeden z najstarszych i najbardziej rozpoznawalnych europejskich „parasoli” muzealnych – padł ofiarą ukierunkowanego cyberataku, który zakłócił działanie znacznej części infrastruktury cyfrowej instytucji. Kluczowa informacja z perspektywy bezpieczeństwa fizycznego: systemy bezpieczeństwa (ochrony) oraz bezpieczeństwo budynkowe nie zostały naruszone, a muzea pozostały otwarte dla zwiedzających.

W praktyce jest to modelowy przykład incydentu, w którym atakujący koncentruje się na warstwie IT i usługach cyfrowych (łączność, sprzedaż, obsługa odwiedzających), a organizacja musi jednocześnie:

  • utrzymać ciągłość podstawowych działań,
  • odciąć/izolować środowisko,
  • uruchomić forensykę i przywracanie usług,
  • prowadzić komunikację kryzysową – często przy ograniczonej dostępności kanałów kontaktu.

W skrócie

  • Atak wykryto 21 stycznia 2026; dotknął „szerokich części” infrastruktury cyfrowej SKD.
  • Silnie ograniczona była osiągalność telefoniczna i cyfrowa; niedostępne m.in. sklep online i obsługa odwiedzających.
  • SKD poinformowało, że muzea i wystawy działają, ale występują ograniczenia, m.in. brak płatności kartą i brak e-commerce.
  • Powołano wewnętrzny sztab kryzysowy, a do prac włączono specjalistów IT oraz usługodawców IT-forensics; działania koordynowano z policją i regionalnymi organami ścigania.
  • Na moment publikacji komunikatów nie podano publicznie wektora ataku, skali naruszenia danych ani sprawców.

Kontekst / historia / powiązania

SKD to sieć obejmująca liczne muzea i instytucje w Dreźnie, a także zasoby, które są „krytyczne” reputacyjnie (z perspektywy dziedzictwa kulturowego). Właśnie takie organizacje – nawet jeśli nie są typowym celem „high-tech” – bywają atrakcyjne dla atakujących, bo:

  • mają rozległą powierzchnię ataku (strony www, systemy biletowe, POS, Wi-Fi dla gości, dostawcy),
  • często działają w modelu rozproszonym (wiele lokalizacji),
  • łączą środowiska IT/OT (monitoring, kontrola dostępu, systemy budynkowe) – choć w tym przypadku podkreślono, że systemy bezpieczeństwa nie zostały naruszone.

W komunikatach SKD i instytucji publicznych akcentowano przede wszystkim ciągłość działania muzeów oraz odseparowanie incydentu od systemów ochrony.

Analiza techniczna / szczegóły luki

Co jest potwierdzone

Z publicznie dostępnych informacji wynika, że skutki dotyczyły głównie usług cyfrowych i kanałów obsługi:

  • niedostępny sklep online,
  • niedostępna obsługa odwiedzających,
  • ograniczona łączność (telefoniczna/cyfrowa),
  • ograniczenia w płatnościach (w komunikacie SKD: brak płatności kartą).

Ponadto uruchomiono klasyczny zestaw działań IR:

  • sztab kryzysowy,
  • specjaliści IT i zewnętrzna forensyka,
  • współpraca z policją, LKA oraz wątek prokuratorski (weryfikacja przejęcia postępowania).

Co jest prawdopodobne (ale niepotwierdzone)

Ponieważ nie podano wektora ataku ani typu incydentu, można jedynie wskazać najczęstsze scenariusze dla zakłóceń tego typu – z wyraźnym zastrzeżeniem, że to hipotezy operacyjne:

  1. Ransomware / wiper w warstwie serwerowej
    Typowy efekt to zatrzymanie usług (e-commerce, CRM, system biletowy), problemy z domeną/SSO, konieczność izolacji segmentów sieci i czasochłonne odtwarzanie.
  2. Atak na tożsamość (Identity) i usługi katalogowe
    Kompromitacja kont uprzywilejowanych, ADFS/Entra/Okta (w zależności od architektury) lub AD może zablokować usługi w wielu lokalizacjach jednocześnie.
  3. Atak łańcucha dostaw (dostawca IT / integrator / MSP)
    W instytucjach kultury część systemów bywa utrzymywana przez podmioty zewnętrzne; incydent u dostawcy może przełożyć się na kilka usług naraz.
  4. DDoS + awarie operacyjne
    Sam DDoS rzadziej powoduje tak szerokie ograniczenia (np. brak płatności kartą), ale w połączeniu z działaniami obronnymi (np. odcięcie łączy) może wywołać podobny efekt.

Warto zauważyć, że SKD podkreśliło sprawność systemów bezpieczeństwa fizycznego – co sugeruje sensowną segmentację lub niezależność tych systemów od dotkniętej części IT (albo przynajmniej brak symptomów naruszenia w tym obszarze).

Praktyczne konsekwencje / ryzyko

Nawet jeśli nie doszło do naruszenia systemów ochrony, incydent tej klasy generuje kilka realnych ryzyk:

  • Ryzyko operacyjne i finansowe: utrata sprzedaży online, spadek konwersji, koszty obsługi manualnej (kasy, wsparcie na miejscu), koszty forensyki i odtwarzania.
  • Ryzyko reputacyjne: instytucje dziedzictwa kulturowego są markami zaufania; nawet „tylko” przestój usług potrafi wywołać szeroki oddźwięk medialny.
  • Ryzyko dla danych: systemy sprzedaży i obsługi odwiedzających zwykle przetwarzają dane osobowe (np. e-mail, historia zakupów, faktury). Publicznie nie potwierdzono eksfiltracji, ale to standardowy wektor presji w kampaniach ransomware.
  • Ryzyko wtórne: phishing „pod incydent” (fałszywe maile o zwrocie środków, ponownej płatności, „aktualizacji” biletów), szczególnie gdy komunikacja organizacji jest ograniczona.

Rekomendacje operacyjne / co zrobić teraz

Poniższe zalecenia są uniwersalne dla instytucji kultury, muzeów i organizacji rozproszonych (wiele lokalizacji), które chcą ograniczyć skutki podobnych incydentów:

  1. Zamrożenie tożsamości uprzywilejowanej
  • natychmiastowy przegląd kont admin, rotacja haseł/kluczy, unieważnienie sesji,
  • wymuszenie MFA (preferencyjnie phishing-resistant) dla kont uprzywilejowanych,
  • odcięcie nieużywanych kont serwisowych.
  1. Segmentacja i „circuit breakers” dla usług krytycznych
  • osobne segmenty dla: POS/płatności, biletowania, e-commerce, sieci gościnnej, zasobów biurowych,
  • testowane procedury szybkiego odcięcia segmentu bez „zabijania” całości.
  1. Kopie zapasowe odporne na ransomware
  • zasada 3-2-1 + kopia offline/immutable,
  • regularne testy odtwarzania (RTO/RPO) dla biletowania, POS i serwisów www.
  1. Telemetria i gotowość do forensyki
  • centralne logowanie (SIEM/XDR), retencja logów (co najmniej 30–90 dni),
  • inwentaryzacja zasobów (CMDB) – kluczowa, gdy trzeba szybko izolować systemy.
  1. Runbook dla „trybu manualnego”
  • procedury sprzedaży i weryfikacji biletów offline,
  • komunikaty dla kas i ochrony (co robić, gdy POS/karty nie działają),
  • alternatywne kanały informacyjne (strona awaryjna, komunikaty na socialach, infolinia zewnętrzna).
  1. Komunikacja kryzysowa
  • jedna, aktualizowana strona statusowa (nawet minimalistyczna),
  • krótkie, konkretne komunikaty: co działa / co nie działa / jak kupić bilet / jak płacić,
  • ostrzeżenia przed phishingiem „pod incydent”.

W przypadku SKD część tych elementów widać już w praktyce: instytucja informuje o ograniczeniach dostępności, o dostępności biletów na miejscu oraz o braku płatności kartą.

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

Ten incydent wyróżnia się dwoma aspektami, które warto traktować jako dobre praktyki (o ile wynikają z rzeczywistej architektury, a nie tylko ze szczęścia):

  • Rozdzielenie bezpieczeństwa fizycznego od IT biznesowego: SKD podkreśla, że systemy bezpieczeństwa pozostały nienaruszone i w pełni sprawne. To sygnał, że segmentacja lub niezależność systemów ochrony była wystarczająca, by utrzymać ciągłość funkcji krytycznych.
  • Ciągłość działania dla odwiedzających: muzea pozostały otwarte, a organizacja przeszła na tryb obsługi z ograniczeniami (np. brak kart, brak online). To ważna lekcja: nawet przy poważnym incydencie IT można utrzymać „core service”, jeśli wcześniej zaplanuje się tryb offline.

Podsumowanie / kluczowe wnioski

Cyberatak na SKD pokazuje, że instytucje kultury są realnym celem i że skuteczny atak nie musi oznaczać zagrożenia fizycznego, by sparaliżować operacje. Na dziś publicznie wiemy przede wszystkim o zakłóceniach infrastruktury cyfrowej, wyłączeniu usług online, ograniczeniach płatności oraz o uruchomieniu formalnych działań IR z udziałem organów ścigania i forensyki.

Najważniejsza lekcja dla podobnych organizacji: inwestycje w segmentację, kopie odporne na ransomware, gotowość do pracy offline i zarządzanie tożsamością często decydują o tym, czy incydent kończy się „tylko” utrudnieniami, czy pełnym paraliżem na tygodnie.

Źródła / bibliografia

  1. Komunikat/press release (Saksonia): „Cyberangriff auf Staatliche Kunstsammlungen Dresden” – medienservice.sachsen.de (medienservice.sachsen.de)
  2. Komunikat SKD na stronie muzeum (ograniczona dostępność usług, brak płatności kartą) – skd.museum (skd.museum)
  3. Recorded Future News / The Record: „Cyberattack disrupts digital systems at renowned Dresden museum network” (The Record from Recorded Future)
  4. Deutschlandfunk Kultur: informacja o skutkach i ograniczeniach usług (Deutschlandfunk Kultur)
  5. ARTnews: informacja o incydencie i wpływie na działalność (ArtNews)

CISA ostrzega: aktywnie wykorzystywana luka LFI w Zimbra Collaboration (CVE-2025-68645)

Wprowadzenie do problemu / definicja luki

Zimbra Collaboration Suite (ZCS) to popularna platforma pocztowo-kolaboracyjna wdrażana w środowiskach on-prem i hybrydowych. Gdy podatność dotyczy webmaila, ryzyko rośnie wykładniczo: interfejs jest zwykle wystawiony do Internetu, a atakujący mogą automatyzować skanowanie i selekcję celów.

W styczniu 2026 r. organizacje zostały ostrzeżone o aktywnym wykorzystywaniu luki CVE-2025-68645. To Local File Inclusion (LFI) w Webmail Classic UI Zimbry, która – w sprzyjających warunkach – pozwala zdalnie i bez uwierzytelnienia wymuszać dołączanie plików z katalogu WebRoot do odpowiedzi aplikacji.

W skrócie

  • CVE: CVE-2025-68645
  • Typ: Local File Inclusion (LFI)
  • Komponent: Zimbra Collaboration (ZCS) 10.0 / 10.1, Webmail Classic UI, endpoint /h/rest
  • Przyczyna: nieprawidłowa obsługa parametrów żądania w RestFilter servlet
  • Wykorzystanie w praktyce: obserwowane kampanie „intelligence-driven”, a wolumen prób rośnie
  • Wersje z poprawką: Zimbra wskazuje naprawę w 10.1.13 oraz 10.0.18
  • Kontekst KEV: CISA dodała tę lukę do katalogu KEV, a media podają termin działań dla agencji federalnych USA do 12 lutego 2026

Kontekst / historia / powiązania

SecurityWeek opisuje, że po dodaniu CVE-2025-68645 do KEV CISA (bez ujawniania szczegółów ataków), dodatkowe światło rzuciły obserwacje z ekosystemu CrowdSec: nadużycia mają być selektywne, ukierunkowane i „wywiadowo” dobierające cele, a zainteresowanie luką rośnie.

To ważne, bo Zimbra ma długą historię incydentów i podatności wykorzystywanych „na masę” po upublicznieniu PoC. W tym przypadku obraz jest inny: najpierw precyzyjne kampanie, potem coraz więcej prób (co zwykle bywa wstępem do szerszego „sprayowania” Internetu).

Analiza techniczna / szczegóły luki

Według opisu w NVD, podatność polega na tym, że RestFilter servlet niewłaściwie obsługuje parametry dostarczone przez użytkownika. Atakujący może wysłać spreparowane żądanie na /h/rest, wpływając na wewnętrzny mechanizm dispatchingu i doprowadzając do włączenia (include) dowolnych plików z WebRoot do odpowiedzi.

Kluczowe konsekwencje techniczne LFI w webmailu:

  • umożliwia ujawnianie zasobów aplikacji (pliki statyczne, szablony, fragmenty konfiguracji zależnie od układu WebRoot),
  • bywa używana jako etap rozpoznania (odczyt plików, identyfikacja wersji, ścieżek, komponentów),
  • może wspierać łańcuch ataku (np. dobór kolejnej podatności lub payloadu), nawet jeśli sama w sobie nie jest RCE.

Zimbra wskazuje, że problem został „zaadresowany” jako unauthenticated LFI w RestFilter i poprawiony w gałęziach wydań 10.1.13 oraz 10.0.18.

Praktyczne konsekwencje / ryzyko

Dla zespołów SOC/IR i właścicieli usług pocztowych liczą się trzy scenariusze ryzyka:

  1. Eksfiltracja danych pośrednich
    Nawet jeśli ogranicza się do WebRoot, atakujący może pozyskać elementy przydatne do dalszej kompromitacji (mapowanie aplikacji, zasobów, wersji, niestandardowych wdrożeń).
  2. Przygotowanie kolejnego etapu ataku
    Ukierunkowane kampanie często zaczynają się od błędu, który „tylko” zwiększa widoczność systemu. CrowdSec sugeruje, że wybór celów nie jest losowy, co pasuje do działań nastawionych na wartość informacji.
  3. Ryzyko operacyjne: poczta jako „high value asset”
    Poczta to dostęp do komunikacji, resetów haseł, przepływu dokumentów i danych wrażliwych. Dlatego nawet podatności bez natychmiastowego RCE traktuje się jako krytyczne w praktyce, zwłaszcza gdy dotykają komponentów wystawionych na Internet.

Rekomendacje operacyjne / co zrobić teraz

1) Patch natychmiast (priorytet P0)
Zaplanuj aktualizację do wydań zawierających poprawkę: ZCS 10.1.13 lub 10.0.18 (zależnie od Twojej linii produktowej).

2) Ogranicz ekspozycję webmaila, jeśli to możliwe

  • Jeśli masz możliwość: ogranicz dostęp do Classic UI (np. wyłącznie przez VPN / reverse proxy z MFA).
  • Rozważ politykę „deny by default” dla nietypowych ścieżek i parametrów na WAF (szczególnie wokół /h/rest).

3) Monitoring i detekcja (szybkie wygrane dla SOC)
Bez wchodzenia w IoC specyficzne dla kampanii (brak publicznych detali od CISA):

  • ustaw alerty na nietypowe żądania do /h/rest (skoki wolumenu, anomalie geolokalizacji, nietypowe parametry),
  • koreluj z błędami aplikacji (nagłe wzrosty 4xx/5xx),
  • przejrzyj logi reverse proxy/WAF pod kątem prób odczytu zasobów „poza typowym ruchem webmaila”.

4) Przygotuj plan IR dla systemów pocztowych
Jeżeli Zimbra jest krytyczna biznesowo: przygotuj playbook (izolacja hosta, rotacja sekretów/kluczy, przegląd kont uprzywilejowanych, weryfikacja reguł przekierowań poczty).

5) Traktuj sprawę jako „exploited in the wild”
Dodanie do KEV jest w praktyce sygnałem, że łatka nie jest „na później”. Media raportują termin działań dla agencji federalnych USA do 12 lutego 2026, co dobrze oddaje oczekiwany poziom pilności również poza administracją.

Różnice / porównania z innymi przypadkami

Warto odróżnić CVE-2025-68645 od wcześniejszych problemów wokół /h/rest:

  • Zimbra notowała już przypadek LFI w /h/rest, ale wymagający ważnego tokenu auth (czyli „authorized attacker”) – to inna klasa ryzyka, bo wymaga wcześniejszego dostępu.
  • CVE-2025-68645 jest opisane jako unauthenticated i dlatego znacznie bardziej niebezpieczne operacyjnie: zwiększa prawdopodobieństwo szerokiej ekspozycji i automatycznych kampanii.

Podsumowanie / kluczowe wnioski

  • CVE-2025-68645 to unauthenticated LFI w Zimbra ZCS 10.0/10.1, związane z obsługą parametrów w RestFilter i endpointem /h/rest.
  • Wykorzystanie jest obserwowane w środowiskach rzeczywistych, a dane telemetryczne sugerują wzrost aktywności i selektywny dobór celów.
  • Zimbra wskazuje, że poprawka jest dostępna w 10.1.13 i 10.0.18 — patch powinien być traktowany jako pilny.
  • Dla obrony liczą się: szybka aktualizacja, ograniczenie ekspozycji Classic UI oraz monitoring żądań do /h/rest.

Źródła / bibliografia

  1. SecurityWeek – informacja o ostrzeżeniu i aktywnym wykorzystaniu CVE-2025-68645 (SecurityWeek)
  2. NVD – opis techniczny CVE-2025-68645 (NVD)
  3. Zimbra Wiki – Zimbra Security Advisories (wskazanie wersji z poprawką) (wiki.zimbra.com)
  4. CrowdSec CTI – obserwacje dot. selektywnego wykorzystania i wzrostu prób (app.crowdsec.net)
  5. The Hacker News – kontekst KEV i termin 12 lutego 2026 dla FCEB (The Hacker News)

Phisherzy nadużywają SharePoint w nowej kampanii AiTM/BEC wymierzonej w sektor energii

Wprowadzenie do problemu / definicja luki

Microsoft i niezależne redakcje branżowe opisują świeżą kampanię phishingową typu Adversary-in-the-Middle (AiTM), która płynnie przechodzi w Business Email Compromise (BEC). Kluczowy wyróżnik: atakujący nie “łamią” SharePoint, tylko nadużywają zaufanego mechanizmu udostępniania plików w SharePoint/OneDrive do dostarczenia przynęty i zwiększenia wiarygodności wiadomości.

AiTM to model, w którym ofiara trafia na stronę pośredniczącą w logowaniu: dane logowania są przekazywane dalej do prawdziwego IdP, a napastnik próbuje przechwycić cookie/sesję. Efekt uboczny jest krytyczny: reset hasła może nie wystarczyć, jeśli napastnik utrzyma aktywną sesję lub “podkręci” MFA.

W skrócie

  • Wejście: e-mail wysłany z przejętego konta zaufanej organizacji (scenariusz “trusted vendor”).
  • Przynęta: temat i styl udostępnienia dokumentu + link SharePoint wymagający uwierzytelnienia.
  • Po kompromitacji: tworzenie reguł skrzynki (Inbox rules) kasujących przychodzące wiadomości i oznaczających je jako przeczytane.
  • Eskalacja: wysyłka ponad 600 kolejnych phishing maili do kontaktów ofiary (wewnętrznych i zewnętrznych).
  • Remediacja: poza resetem hasła konieczne bywa unieważnienie sesji/cookies i usunięcie złośliwych reguł skrzynki oraz weryfikacja zmian MFA.

Kontekst / historia / powiązania

To kolejny przykład trendu “living-off-trusted-services”: chmurowe platformy współpracy (SharePoint/OneDrive) są powszechne w organizacjach, więc link do “dokumentu” wygląda normalnie i częściej omija podejścia oparte wyłącznie o reputację domen i analizę treści e-maila.

Ważne jest też odróżnienie tej kampanii od głośnych incydentów z 2025 r. dotyczących eksploatacji luk w SharePoint Server on-prem – tam wektorem były podatności serwera, tu wektorem jest socjotechnika + przejęte tożsamości + nadużycie legalnej usługi.

Analiza techniczna / szczegóły luki

Microsoft opisuje wieloetapowy łańcuch ataku, który warto mapować do TTP:

  1. Initial Access: “trusted vendor compromise”
    Wiadomość startowa przychodzi z konta należącego do zaufanej organizacji (prawdopodobnie wcześniej przejętego). Przynęta udaje standardowy workflow udostępnienia dokumentu w SharePoint.
  2. Click → przekierowania → strona logowania AiTM
    Użytkownik klika w link SharePoint, trafia na stronę podszywającą się pod logowanie Microsoft, co ma umożliwić przechwycenie sesji (AiTM). Microsoft zaznacza, że nie zawsze ma pełną widoczność “za landing page”, ale koreluje późniejsze logowania i wzorce IP.
  3. Post-compromise: reguły skrzynki jako “stealth & persistence”
    Po zalogowaniu atakujący tworzy regułę Inbox rule: usuń wszystko przychodzące + oznacz jako przeczytane. To prosta, ale zabójczo skuteczna technika na utrzymanie operacji w ukryciu (ofiara “nie widzi” maili ostrzegawczych, odpowiedzi ofiar phishingu, notyfikacji bezpieczeństwa itd.).
  4. Rozszerzenie zasięgu: phishing z zaufanego, realnego konta
    W analizowanym przypadku napastnicy wysłali >600 e-maili do kontaktów ofiary (w tym list dystrybucyjnych), bazując na ostatnich wątkach z jej skrzynki. To pozwala dobrać treść “w kontekst” i zwiększa konwersję.
  5. BEC: aktywne “zarządzanie” skrzynką
    Atakujący monitoruje odpowiedzi (np. undelivered i autorespondery), usuwa je, a w razie pytań o autentyczność – potrafi odpisać “potwierdzając”, po czym ślady znikają z mailboxa.
  6. IoC / tropy łowieckie (z raportu Microsoft)
    W przykładach “hunting queries” pojawiają się m.in. temat wiadomości “NEW PROPOSAL – NDA” oraz wskazane prefiksy IP używane przy podejrzanych logowaniach (m.in. 178.130.46.* i 193.36.221.*).

Przykładowe zapytania (KQL) inspirowane treścią raportu Microsoft:

// AHQ#1 – Phishing campaign (temat przynęty)
EmailEvents
| where Subject has "NEW PROPOSAL – NDA"

// AHQ#2 – Sign-in activity ze wskazanych prefiksów IP
AADSignInEventsBeta
| where Timestamp >= ago(7d)
| where IPAddress startswith "178.130.46." or IPAddress startswith "193.36.221."

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: AiTM może skutkować przejęciem sesji i obejściem części mechanizmów MFA (zwłaszcza tych podatnych na przejęcie sesji).
  • Ciche BEC: reguły skrzynki kasujące/ukrywające pocztę drastycznie obniżają szansę wykrycia i wydłużają “dwell time”.
  • Szybka propagacja: phishing z prawdziwego konta pracownika (z historią korespondencji) potrafi przeskoczyć filtry i zarażać kolejne skrzynki w łańcuchu.
  • Ryzyko operacyjne dla energetyki: nawet jeśli kampania startuje od IT/biura, konsekwencje (kradzież danych, fałszywe zlecenia płatnicze, dostęp do systemów powiązanych) są typowe dla BEC i mogą eskalować do zakłóceń procesów.

Rekomendacje operacyjne / co zrobić teraz

  1. Traktuj to jako incydent tożsamości + poczty, nie tylko “phishing”
    • Reset hasła to za mało w AiTM: unieważnij aktywne sesje/cookies i sprawdź, czy nie manipulowano metodami MFA.
    • Przejrzyj i usuń podejrzane Inbox rules (delete + mark as read, forward, move to RSS/Archive itd.).
  2. Wymuś polityki, które utrudniają przejęcie sesji
    • Włącz/zaostrz Conditional Access (ryzyko logowania, lokalizacja, stan urządzenia, wymaganie compliant device).
    • Rozważ phishing-resistant MFA (np. FIDO2 / CBA) i podejście passwordless tam, gdzie to możliwe.
    • Włącz mechanizmy typu Continuous Access Evaluation tam, gdzie środowisko na to pozwala.
  3. Zabezpieczenia poczty i detekcje
    • Uruchom polowania: tematy, nietypowe logowania, tworzenie reguł, masowa wysyłka do list dystrybucyjnych.
    • Skonfiguruj alerty na: nowe/zmienione reguły skrzynki, nietypowe forwarding, anomalie MailItemsAccessed, logowania z VPS/anonymizerów. (Microsoft wskazuje gotowe szablony analityczne dla Sentinel/Defender).
  4. Procesy i higiena współpracy z dostawcami
    • Zweryfikuj kanały wymiany dokumentów z partnerami (np. “tylko zatwierdzone tenanty”, podpisy DKIM/DMARC, dodatkowa walidacja przy “pilnych NDA/proposal”).
    • Szkol użytkowników: “SharePoint link ≠ gwarancja bezpieczeństwa” – szczególnie gdy e-mail wymusza logowanie lub wygląda “zbyt normalnie”.

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

  • Ta kampania (2026): nadużycie legalnego SharePoint jako elementu socjotechniki + przejęcie tożsamości + AiTM/BEC. Nie wymaga podatności SharePoint.
  • Incydenty SharePoint on-prem (2025): wektor oparty o eksploatację luk w SharePoint Server (CISA publikowała ostrzeżenia i guidance), z ryzykiem szerokiego przejęcia serwerów i kluczy/auth.

W praktyce oznacza to, że nawet organizacje “w pełni załatane” po 2025 r. nadal pozostają podatne na ten scenariusz, bo atak idzie przez ludzi i sesje, a nie przez CVE.

Podsumowanie / kluczowe wnioski

  • Zaufane platformy współpracy są coraz częściej używane jako maskowanie dla phishingu – SharePoint link bywa “konikiem trojańskim” wiarygodności.
  • AiTM wymusza zmianę myślenia o remediacji: reset hasła nie kończy incydentu, jeśli nie zamkniesz sesji i nie posprzątasz skrzynki (reguły!).
  • Największe ryzyko w tej kampanii to szybka ekspansja: phishing z realnego konta ofiary + BEC “na autopilocie” poprzez reguły kasowania/ukrywania poczty.

Źródła / bibliografia

  1. Microsoft Security Blog (Microsoft Defender Security Research Team) – opis łańcucha ataku, mitigacje i hunting queries. (Microsoft)
  2. SecurityWeek – streszczenie kampanii i kluczowe elementy BEC (600+ maili, reguły skrzynki). (SecurityWeek)
  3. Help Net Security – dodatkowe szczegóły operacyjne (temat maila, IP) i rekomendacje remediacyjne. (Help Net Security)
  4. CISA – kontekst historyczny ostrzeżeń dot. SharePoint (dla porównania “nadużycie usługi” vs “eksploatacja podatności”). (cisa.gov)