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

Atak ransomware sparaliżował cukrownie Mackay Sugar w Australii

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki ransomware coraz częściej wykraczają poza tradycyjne środowiska biurowe i uderzają w przedsiębiorstwa przemysłowe, gdzie skutki incydentu obejmują nie tylko systemy informatyczne, ale również procesy operacyjne. Najnowszy przypadek dotyczący australijskiego producenta Mackay Sugar pokazuje, że cyberatak może przełożyć się bezpośrednio na ograniczenie produkcji, logistykę dostaw oraz funkcjonowanie całego łańcucha wartości.

W tym modelu zagrożenia celem przestępców jest nie tylko zaszyfrowanie danych, ale także wywarcie presji biznesowej poprzez zakłócenie pracy zakładów i wymuszenie szybkich decyzji po stronie ofiary.

W skrócie

  • Mackay Sugar poinformował o incydencie cyberbezpieczeństwa 10 czerwca 2026 roku.
  • Atak wpłynął na pracę dwóch z trzech zakładów przetwarzających trzcinę cukrową w stanie Queensland.
  • Firma czasowo wyłączyła część operacji i uruchomiła działania awaryjne.
  • W jednym z młynów wznowiono ograniczoną, manualną działalność.
  • Z incydentem wiązana jest grupa ransomware The Gentlemen, znana także jako Storm-2697.
  • Na moment publikacji nie potwierdzono publicznie wycieku danych, a proces odbudowy kluczowych systemów nadal trwał.

Kontekst / historia

Mackay Sugar należy do najważniejszych podmiotów australijskiego sektora cukrowniczego i jest uznawany za drugiego największego producenta surowego cukru w kraju. W praktyce oznacza to, że nawet krótkotrwałe zakłócenie środowiska cyfrowego może mieć wpływ na plantatorów, transport, harmonogram zbiorów oraz samo przetwarzanie surowca.

Pierwsze publiczne informacje o incydencie pojawiły się 10 czerwca 2026 roku, kiedy firma potwierdziła reakcję na zdarzenie wpływające na część operacji. W kolejnych aktualizacjach spółka informowała o stopniowym przywracaniu środowiska wspierającego dostawy trzciny, zbiory oraz pracę zakładów. Dwa dni po pierwszym komunikacie przedsiębiorstwo przekazało, że udało się uruchomić ograniczone, ręczne kruszenie trzciny w jednym z zakładów, co wskazuje na wdrożenie procedur awaryjnych mających utrzymać minimalną ciągłość działania.

Analiza techniczna

Z technicznego punktu widzenia incydent wpisuje się w schemat ransomware wymierzonego w przedsiębiorstwo produkcyjne. Publicznie dostępne informacje wskazują, że skutki ataku objęły systemy wspierające procesy biznesowe, dostawy oraz logistykę operacyjną. Nie ma jednak pewności, czy napastnicy uzyskali bezpośredni dostęp do systemów przemysłowych OT, czy też przestój był pośrednim skutkiem kompromitacji warstwy IT.

To rozróżnienie ma istotne znaczenie dla oceny ryzyka. W wielu organizacjach środowiska IT i OT są formalnie rozdzielone, ale pozostają powiązane przez systemy planowania produkcji, harmonogramowania dostaw, utrzymania ruchu, zdalnego dostępu dostawców oraz wymiany danych procesowych. W efekcie atak na warstwę IT może sparaliżować działalność operacyjną nawet bez bezpośredniego zaszyfrowania serwerów SCADA, stacji inżynierskich czy sterowników PLC.

Grupa The Gentlemen, śledzona pod oznaczeniem Storm-2697, jest kojarzona z działaniami obejmującymi zarówno szyfrowanie danych, jak i eksfiltrację informacji w celu zwiększenia presji na ofiarę. Dodatkowo analitycy zwracali uwagę na cechy złośliwego oprogramowania tej grupy związane z przemieszczaniem się lateralnym w sposób przypominający działanie robaka sieciowego. W środowiskach o słabej segmentacji, współdzielonych kontach uprzywilejowanych i niekontrolowanych połączeniach między IT a OT może to znacząco zwiększać tempo rozprzestrzeniania się incydentu.

Fakt uruchomienia ograniczonych procesów manualnych sugeruje, że organizacja przełączyła część działalności na tryb awaryjny. To typowe działanie w zakładach przemysłowych, ale zwykle oznacza niższą wydajność, większe obciążenie personelu i wyższe ryzyko błędów operacyjnych.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem incydentu jest zakłócenie ciągłości działania. W sektorze przemysłowym ransomware szybko przekłada się na przestoje, opóźnienia dostaw, problemy z planowaniem pracy i wzrost kosztów operacyjnych. W przypadku przetwarzania trzciny cukrowej ma to szczególne znaczenie, ponieważ terminowość odbioru i obróbki surowca wpływa na efektywność całego sezonu.

Ryzyko należy rozpatrywać w kilku warstwach. Pierwsza dotyczy dostępności systemów, ponieważ utrata narzędzi wspierających logistykę i dostawy może być równie dotkliwa jak bezpośrednie wyłączenie produkcji. Druga warstwa obejmuje integralność danych operacyjnych, harmonogramów i konfiguracji, które po incydencie muszą zostać zweryfikowane przed wznowieniem normalnej pracy. Trzecia odnosi się do poufności informacji, ponieważ brak publicznego potwierdzenia wycieku nie oznacza, że nie doszło do wcześniejszej eksfiltracji danych biznesowych, kontraktowych lub technicznych.

W środowiskach OT dochodzi także ryzyko wtórne. Nawet jeśli systemy sterowania nie zostały bezpośrednio naruszone, organizacja może zdecydować o kontrolowanym zatrzymaniu procesów ze względów bezpieczeństwa. Takie podejście ogranicza prawdopodobieństwo pracy przy niepełnej widoczności operacyjnej lub na błędnych danych wejściowych.

Rekomendacje

Incydent w Mackay Sugar stanowi mocny sygnał ostrzegawczy dla organizacji przemysłowych, które powinny wzmacniać odporność całego ekosystemu produkcyjnego, a nie wyłącznie klasycznej warstwy IT.

  • wdrożenie ścisłej segmentacji między sieciami IT i OT oraz ograniczenie komunikacji do kontrolowanych kanałów;
  • eliminacja współdzielonych kont uprzywilejowanych i egzekwowanie MFA dla dostępu zdalnego, administracyjnego oraz po stronie dostawców;
  • utrzymywanie kopii zapasowych offline i regularne testowanie procedur odtworzeniowych, także dla konfiguracji systemów przemysłowych;
  • monitorowanie ruchu bocznego, nietypowych prób uwierzytelniania, masowego szyfrowania plików oraz podejrzanych transferów danych;
  • mapowanie zależności między systemami biznesowymi i operacyjnymi w celu identyfikacji pojedynczych punktów awarii;
  • przygotowanie oraz ćwiczenie scenariuszy przejścia na operacje manualne i bezpiecznego restartu produkcji;
  • opracowanie playbooków incident response dla środowisk mieszanych IT/OT z udziałem SOC, utrzymania ruchu i zespołów operacyjnych;
  • walidacja integralności systemów przed pełnym wznowieniem pracy, a nie wyłącznie przywrócenie ich dostępności.

Warto również uwzględnić scenariusz podwójnego wymuszenia, w którym atakujący nie tylko szyfrują zasoby, ale również grożą ujawnieniem skradzionych danych. Reakcja organizacji powinna więc obejmować zarówno odtworzenie techniczne, jak i ocenę wpływu regulacyjnego, kontraktowego oraz reputacyjnego.

Podsumowanie

Atak ransomware na Mackay Sugar pokazuje, że zagrożenia cybernetyczne dla sektora przemysłowego mają dziś wymiar bezpośrednio operacyjny. Nawet jeśli napastnicy nie przejęli kontroli nad systemami sterowania, kompromitacja zaplecza IT mogła wystarczyć do wstrzymania części produkcji, zaburzenia logistyki i uruchomienia mniej wydajnych procedur ręcznych.

Z perspektywy obrony kluczowe pozostają segmentacja środowisk, odporność na lateral movement, skuteczne kopie zapasowe oraz gotowość do bezpiecznego utrzymania lub wznowienia operacji w złożonych środowiskach IT i OT.

Źródła

Sniper Dz atakuje użytkowników MENA przez fałszywe oferty na Facebooku i nadużycia powiadomień przeglądarki

Cybersecurity news

Wprowadzenie do problemu / definicja

Kampanie oszustw internetowych coraz częściej odchodzą od prostych schematów opartych wyłącznie na złośliwym oprogramowaniu lub klasycznych stronach phishingowych. Coraz większą rolę odgrywają legalne funkcje przeglądarek, zaufane platformy pośredniczące oraz precyzyjnie zaplanowana inżynieria społeczna. Taki model działania pozwala cyberprzestępcom obniżyć wykrywalność i zwiększyć skuteczność ataku.

Jednym z przykładów tego trendu jest aktywność powiązana z platformą Sniper Dz, wykorzystywaną w kampaniach wymierzonych w użytkowników z regionu Bliskiego Wschodu i Afryki Północnej. Ataki łączyły fałszywe oferty publikowane w mediach społecznościowych, nadużycia powiadomień push oraz mechanizmy monetyzacji ruchu i danych ofiar.

W skrócie

Badacze bezpieczeństwa opisali kampanie, w których fałszywe konta na Facebooku podszywały się pod polityków, osoby publiczne i zaufane organizacje. Przynęty obejmowały rzekome darmowe pakiety internetu mobilnego, rekompensaty finansowe oraz programy dopłat państwowych.

Po kliknięciu użytkownik nie trafiał bezpośrednio na stronę oszustwa, lecz przechodził przez wieloetapowy łańcuch przekierowań. Celem było zarówno wyłudzenie danych, jak i dalsza monetyzacja ofiary poprzez premium SMS, połączenia o podwyższonej opłacie, fałszywe inwestycje oraz długotrwałe nadużywanie powiadomień przeglądarki.

Kontekst / historia

Opisany schemat wpisuje się w szerszy rozwój modelu phishing-as-a-service, w którym operatorzy udostępniają gotową infrastrukturę do prowadzenia kampanii oszustw. Dzięki temu mniej zaawansowani przestępcy mogą korzystać z gotowych szablonów, mechanizmów przekierowań, paneli zarządzania i elementów analitycznych bez konieczności samodzielnego budowania zaplecza technicznego.

W przypadku Sniper Dz istotne jest to, że działalność nie ograniczała się do samego phishingu. Platforma miała umożliwiać wieloetapową monetyzację użytkownika, od wymuszenia zgody na powiadomienia push po kierowanie ofiary do kolejnych scenariuszy fraudowych. Dodatkowo kampanie były lokalizowane pod konkretne kraje, operatorów telekomunikacyjnych i grupy odbiorców, co zwiększało ich wiarygodność.

Analiza techniczna

Łańcuch ataku rozpoczynał się od postów publikowanych na Facebooku. Treści były stylizowane na legalne komunikaty promocyjne lub społeczne i zachęcały do szybkiego działania. Użytkownik miał odebrać rzekomą korzyść, ale po kliknięciu linku trafiał najpierw do usług pośredniczących typu „link in bio”, które utrudniają wykrywanie i blokowanie kampanii.

Następnie ofiara widziała komunikat nakłaniający do kliknięcia przycisku „Allow”, przedstawianego jako konieczny etap weryfikacji lub kontynuowania procesu. W praktyce oznaczało to nadanie stronie uprawnień do wysyłania powiadomień web push. Tego typu zgoda otwiera atakującym drogę do dalszego przesyłania fałszywych alertów i przekierowań nawet po opuszczeniu pierwotnej witryny.

W analizowanej infrastrukturze istotną rolę odgrywał klucz publiczny VAPID, wykorzystywany do identyfikacji usługi odpowiedzialnej za dostarczanie powiadomień. Powtarzalność tego samego klucza w różnych kampaniach może wskazywać na współdzieloną infrastrukturę i stanowić cenny artefakt analityczny pozwalający łączyć pozornie niezależne operacje.

Operatorzy stosowali także techniki manipulujące zachowaniem przeglądarki. Jedną z nich było przechwytywanie działania przycisku „Wstecz” poprzez wstrzykiwanie wielu stanów historii, co utrudniało użytkownikowi szybkie opuszczenie strony. Drugą był tab-under, czyli otwarcie nowej karty przy jednoczesnym cichym przekierowaniu aktywnej karty do kolejnego etapu oszustwa.

Po zapisaniu ofiary do systemu powiadomień następował etap właściwej monetyzacji. System dystrybucji ruchu dobierał dalszy scenariusz na podstawie lokalizacji, typu urządzenia i operatora komórkowego. Dzięki temu użytkownik mógł zostać skierowany do usług premium SMS, płatnych połączeń lub fałszywych ofert inwestycyjnych.

Konsekwencje / ryzyko

Ryzyko związane z tego typu kampanią ma charakter wielowarstwowy. W najbardziej oczywistym scenariuszu ofiara może utracić dane logowania, informacje osobowe lub inne wrażliwe dane, jeśli końcowy etap zawiera formularze phishingowe. Jednak nawet bez klasycznego malware skutki finansowe mogą być bardzo realne.

Użytkownik może zostać nieświadomie zapisany do płatnych usług, obciążony kosztami połączeń o podwyższonej opłacie albo wciągnięty w kolejne oszustwa inwestycyjne. Dodatkowo nadużycia powiadomień push mogą prowadzić do uporczywego nękania fałszywymi alertami i ponownymi próbami przekierowań.

Z punktu widzenia obrony szczególnie groźne jest to, że kampania wykorzystuje legalne mechanizmy przeglądarki oraz renomowane usługi pośredniczące. Taki model obniża skuteczność klasycznych narzędzi antymalware, które koncentrują się głównie na wykrywaniu złośliwych plików i znanych wskaźników kompromitacji.

Na ryzyko narażone są również marki, operatorzy telekomunikacyjni i instytucje publiczne, pod które podszywają się oszuści. Fałszywe promocje i rzekome dopłaty mogą osłabiać zaufanie odbiorców do prawdziwych kanałów komunikacji i generować wymierne straty reputacyjne.

Rekomendacje

Organizacje powinny rozwijać monitoring nadużyć marki w mediach społecznościowych oraz wdrażać szybkie procedury reagowania na fałszywe konta, reklamy i strony pośredniczące. Warto również analizować infrastrukturę web push, korelować klucze VAPID, domeny pośrednie oraz wzorce przekierowań.

Po stronie użytkowników podstawą jest ostrożność wobec ofert obiecujących natychmiastowe korzyści finansowe, darmowy internet czy świadczenia socjalne. Szczególną czujność należy zachować wobec stron, które wymagają kliknięcia „Allow” bez jasnego i uzasadnionego celu.

  • Nie akceptować powiadomień przeglądarki na nieznanych lub podejrzanych stronach.
  • Regularnie przeglądać listę witryn posiadających zgodę na wysyłanie powiadomień i usuwać nieznane wpisy.
  • Blokować znane wzorce złośliwych przekierowań i domen pośrednich.
  • Monitorować nietypowe żądania zgód na powiadomienia push.
  • Edukować użytkowników w zakresie oszustw wykorzystujących legalne funkcje przeglądarki.
  • Analizować zdarzenia związane z manipulacją historią przeglądarki oraz techniką tab-under.
  • Stosować filtrację DNS i proxy do identyfikacji łańcuchów przekierowań charakterystycznych dla fraudów afiliacyjnych i phishingowych.

W środowiskach korporacyjnych pomocne może być również ograniczenie możliwości nadawania uprawnień do powiadomień wyłącznie dla zatwierdzonych domen. Takie podejście zmniejsza ryzyko trwałego nadużywania przeglądarki jako kanału dalszych oszustw.

Podsumowanie

Kampania powiązana ze Sniper Dz pokazuje, że współczesne oszustwa internetowe coraz skuteczniej wykorzystują nie tylko socjotechnikę, ale też legalne elementy ekosystemu webowego. Zamiast infekować urządzenia tradycyjnym malware, atakujący prowadzą ofiarę przez złożony łańcuch przekierowań, nadużyć powiadomień i mechanizmów monetyzacji.

Dla zespołów bezpieczeństwa oznacza to konieczność szerszego spojrzenia na zagrożenia webowe. Ochrona musi obejmować nie tylko pliki i klasyczne wskaźniki kompromitacji, lecz także analizę zachowań przeglądarki, infrastruktury powiadomień push, usług pośredniczących i wzorców oszustw afiliacyjnych.

Źródła

  1. https://thehackernews.com/2026/06/sniper-dz-scams-target-mena-users-via.html
  2. https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/
  3. https://www.group-ib.com/

Północnokoreańscy atakujący wykorzystują VS Code i GitHub do infekowania programistów

Cybersecurity news

Wprowadzenie do problemu / definicja

Kampanie wymierzone w programistów coraz częściej łączą socjotechnikę z nadużyciem zaufanych narzędzi deweloperskich. W opisywanym scenariuszu repozytoria GitHub, projekty otwierane w Visual Studio Code oraz złośliwe rozszerzenia VS Code stają się nośnikiem malware służącego do kradzieży poświadczeń, danych systemowych i informacji związanych z portfelami kryptowalutowymi.

To przykład ataku na łańcuch narzędzi programistycznych, w którym nie trzeba już nakłaniać ofiary do uruchamiania oczywistego pliku wykonywalnego. Wystarczy, że programista sklonuje repozytorium i otworzy projekt w swoim codziennym środowisku pracy.

W skrócie

  • Badacze powiązali dwie kampanie z aktywnością zbliżoną do północnokoreańskiego klastra Contagious Interview.
  • Jedna z operacji, śledzona jako UNK_DeadDrop, wykorzystywała wiadomości o tematyce rekrutacyjnej i próśb o code review.
  • Ofiary były kierowane do kontrolowanych przez napastników repozytoriów GitHub.
  • Po otwarciu projektu w VS Code lub Cursor uruchamiał się wieloetapowy łańcuch infekcji dla Windows, macOS i Linuksa.
  • Celem ataków była przede wszystkim kradzież poświadczeń, danych z przeglądarek oraz informacji z portfeli kryptowalutowych.
  • Równolegle wykryto złośliwe rozszerzenia VS Code podszywające się pod narzędzia dla Jupyter Notebook i wykorzystujące usługi Microsoftu jako kanał komunikacji.

Kontekst / historia

Fałszywe procesy rekrutacyjne od lat pozostają jednym z ulubionych sposobów działania grup powiązywanych z Koreą Północną. Atakujący podszywają się pod rekruterów, firmy technologiczne lub partnerów biznesowych, a następnie proszą programistów o wykonanie zadania technicznego, analizę kodu albo ocenę rzekomego projektu open source.

Obecna fala aktywności pokazuje jednak wyraźne dojrzewanie tego modelu. Zamiast ograniczać się do prostych skryptów lub zainfekowanych archiwów, napastnicy wykorzystują naturalny workflow dewelopera: GitHub, edytor kodu, rozszerzenia i zaufane usługi chmurowe. W przypadku kampanii UNK_DeadDrop działania miały objąć setki wiadomości wysłanych do osób pracujących w niemal stu organizacjach, głównie z sektorów finansów, kryptowalut, edukacji i technologii.

Analiza techniczna

Łańcuch ataku zaczynał się od wiadomości e-mail zawierającej odnośnik do repozytorium GitHub, które wyglądało jak zadanie rekrutacyjne, projekt testowy albo narzędzie związane z kryptowalutami. Po sklonowaniu repozytorium i otwarciu katalogu w edytorze kodu uruchamiał się mechanizm automatycznego wykonania oparty na funkcjach środowiska deweloperskiego.

Jednym z kluczowych elementów była technika runOn: folderOpen, pozwalająca na wykonanie określonych działań już w momencie otwarcia folderu projektu. Dzięki temu użytkownik nie musiał ręcznie startować podejrzanego skryptu, ponieważ złośliwa aktywność była ukryta w zwykłym procesie pracy z kodem.

Na macOS i Linuksie wykorzystywano skrypty powłoki, natomiast na Windows skrypt VBScript. Ich zadaniem było pobranie i instalacja złośliwego rozszerzenia VS Code w formacie VSIX. Taki implant mógł następnie komunikować się z serwerem dowodzenia, wykonywać polecenia, zbierać dane z hosta i przekazywać je operatorom.

W środowiskach unixowych łańcuch prowadził dodatkowo do użycia zmodyfikowanego frameworka napisanego w Go, służącego do kradzieży danych. W niektórych przypadkach ofiara widziała także fałszywe okno bezpieczeństwa z prośbą o podanie hasła systemowego, co mogło zwiększać poziom dostępu uzyskanego przez napastników.

Na Windows obserwowano model bardziej dyskretny operacyjnie. Malware wykonywał jednorazową kradzież danych, kompresował zebrane informacje, przesyłał je do infrastruktury atakującego, a następnie usuwał ślady i kończył działanie. Taki schemat ograniczał widoczność ataku i mógł utrudniać wykrycie przez rozwiązania EDR.

Drugim ważnym wątkiem były złośliwe rozszerzenia VS Code opublikowane jako pozornie użyteczne dodatki dla Jupyter Notebook. Według analiz posiadały one wieloetapowy backdoor, w którym SharePoint pełnił rolę magazynu poleceń, rejestru ofiar i kanału eksfiltracji, a komunikacja była realizowana przez Microsoft Graph API. To podejście jest niebezpieczne, ponieważ ruch do legalnych usług chmurowych często nie wzbudza podejrzeń i bywa domyślnie dozwolony w środowiskach firmowych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takich kampanii jest przesunięcie punktu ciężkości ataku z klasycznego endpointu na narzędzia developerskie i cały proces wytwarzania oprogramowania. Skutki mogą być znacznie szersze niż pojedyncza infekcja stacji roboczej.

  • kradzież poświadczeń użytkownika, tokenów dostępu, kluczy SSH i danych sesyjnych,
  • pozyskanie danych z przeglądarek oraz aplikacji i rozszerzeń portfeli kryptowalutowych,
  • kompromitacja lokalnych środowisk deweloperskich i narzędzi CI/CD,
  • ryzyko modyfikacji kodu źródłowego, zależności i konfiguracji projektów,
  • możliwość przeprowadzenia dalszego ataku na łańcuch dostaw oprogramowania.

Szczególnie groźne jest wykorzystywanie usług takich jak GitHub, VS Code Marketplace, SharePoint czy Microsoft Graph API. Są one powszechnie używane w biznesie, dlatego ruch do nich często nie jest blokowany, co daje napastnikom wygodną osłonę operacyjną.

Rekomendacje

Organizacje powinny traktować IDE, rozszerzenia edytorów, marketplace’y i zewnętrzne repozytoria kodu jako elementy powierzchni ataku wysokiego ryzyka. Ochrona musi obejmować zarówno technologię, jak i procedury pracy programistów.

  • ograniczyć lub monitorować automatyczne uruchamianie zadań i skryptów przy otwieraniu projektu w IDE,
  • wprowadzić listy dozwolonych rozszerzeń oraz centralną kontrolę plików VSIX,
  • blokować samodzielną instalację niezweryfikowanych dodatków z marketplace i spoza niego,
  • monitorować procesy potomne uruchamiane przez VS Code, Cursor i podobne narzędzia,
  • stosować EDR z detekcją nietypowych skryptów, archiwizacji danych i komunikacji do usług chmurowych,
  • chronić sekrety przy użyciu menedżerów poświadczeń, MFA i krótkiego czasu życia tokenów,
  • szkolić programistów, aby każde zewnętrzne repozytorium traktowali jako potencjalnie niebezpieczne,
  • analizować zadania rekrutacyjne i projekty testowe w środowiskach odizolowanych przed otwarciem ich lokalnie.

Podsumowanie

Opisana aktywność pokazuje, że narzędzia programistyczne stały się pełnoprawnym wektorem dostarczania malware. Atakujący wykorzystują zaufane elementy codziennego workflow deweloperów, aby ukryć złośliwe działania w pozornie rutynowych czynnościach, takich jak klonowanie repozytorium, otwarcie projektu czy instalacja rozszerzenia.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona musi obejmować nie tylko infrastrukturę, kod i pipeline’y CI/CD, lecz także same IDE, dodatki oraz nawyki pracy programistów. W przeciwnym razie pojedyncze otwarcie niewinnie wyglądającego projektu może doprowadzić do kradzieży poświadczeń, utraty środków kryptowalutowych i kompromitacji łańcucha dostaw oprogramowania.

Źródła

  1. North Korean Hackers Are Turning Developer Tools Into Malware Delivery Channels — https://thehackernews.com/2026/06/north-korean-hackers-are-turning.html
  2. North Korea-linked threat cluster targets developers through GitHub and coding tools — https://www.intelligentciso.com/2026/06/08/north-korea-linked-threat-cluster-targets-developers-through-github-and-coding-tools/
  3. Suspected North Korean actors use fake coding assignments to steal crypto — https://www.scworld.com/news/suspected-north-korean-actors-use-fake-coding-assignments-to-steal-crypto
  4. North Korean hackers are at it again — phishing scheme targets hundreds of workers to try and steal crypto and more — https://www.techradar.com/pro/security/north-korean-hackers-are-at-it-again-phishing-scheme-targets-hundreds-of-workers-to-try-and-steal-crypto-and-more
  5. VS Code Extensions Smuggle Lazarus Backdoor in SharePoint — https://aiweekly.co/alerts/vs-code-extensions-smuggle-lazarus-backdoor-in-sharepoint

152 rozszerzenia Chrome z tapetami powiązane z adware i fałszowaniem ruchu

Cybersecurity news

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili szeroko zakrojoną kampanię obejmującą 152 rozszerzenia Google Chrome oferujące tapety i animowane tła dla nowych kart. Choć tego rodzaju dodatki zwykle uchodzą za nieszkodliwe, analiza wskazuje, że część z nich wykazywała cechy typowe dla adware, nadmiernego zbierania danych telemetrycznych oraz mechanizmów służących do sztucznego generowania i fałszowania źródeł ruchu.

To kolejny przykład, że nawet pozornie proste rozszerzenia personalizujące przeglądarkę mogą stać się narzędziem monetyzacji kosztem prywatności użytkownika i przejrzystości ekosystemu reklamowego.

W skrócie

Zidentyfikowany klaster obejmował 152 rozszerzenia opublikowane przez 38 różnych kont wydawców i powiązane z trzema wspólnymi zapleczami infrastrukturalnymi. Łącznie dodatki miały osiągnąć około 105 tysięcy instalacji.

  • rozszerzenia udawały narzędzia do personalizacji nowych kart,
  • część z nich deklarowała brak zbierania danych mimo odmiennych zapisów w politykach prywatności,
  • badacze wykryli logikę uruchamiania spreparowanych adresów URL podczas instalacji i odinstalowania,
  • mechanizmy te mogły służyć do symulowania legalnego ruchu pochodzącego z wyszukiwarek.

Kontekst / historia

Rynek rozszerzeń przeglądarkowych od lat pozostaje atrakcyjnym wektorem nadużyć. Dodatki oferujące tapety, motywy, widżety i funkcje nowej karty często proszą o szerokie uprawnienia, a jednocześnie nie wzbudzają dużej podejrzliwości użytkowników. Taki model sprzyja kampaniom nastawionym na reklamę, śledzenie aktywności i manipulowanie ruchem afiliacyjnym.

W opisywanym przypadku zebrane artefakty wskazują na skoordynowaną, finansowo motywowaną operację. Wykorzystanie wielu kont wydawców oraz wspólnych elementów zaplecza sugeruje, że nie chodziło o pojedynczy incydent, lecz o dobrze zorganizowaną kampanię rozproszoną na wiele pozornie niezależnych pakietów.

Analiza techniczna

Jednym z najważniejszych elementów technicznych kampanii było rozproszenie jej na dużą liczbę rozszerzeń. Taka strategia utrudnia wykrywanie na podstawie reputacji i pozwala dłużej utrzymywać obecność w sklepie, nawet jeśli część dodatków zostanie usunięta. Rozszerzenia były promowane jako atrakcyjne wizualnie dodatki związane z popularnymi markami, postaciami i motywami kulturowymi, co zwiększało ich szanse na instalację.

Badacze zwrócili uwagę na rozbieżność między informacjami prezentowanymi w Chrome Web Store a treścią polityk prywatności. Z punktu widzenia bezpieczeństwa i zgodności to istotny sygnał ostrzegawczy, ponieważ użytkownik podejmuje decyzję instalacyjną na podstawie deklaracji widocznych w sklepie. Jeśli rozszerzenie twierdzi, że nie gromadzi danych, a dokumentacja prywatności wspomina o rejestrowaniu adresów IP, dostawcy internetu, liczby kliknięć czy danych referencyjnych, pojawia się realny problem przejrzystości.

Szczególnie niepokojący okazał się kod JavaScript obsługujący zdarzenia instalacji i odinstalowania. Część rozszerzeń zawierała na sztywno zdefiniowane adresy URL uruchamiane właśnie w tych momentach. W przypadku instalacji stosowano parametry UTM sugerujące organiczne wejście z wyszukiwarki, co mogło nadawać sztucznie wygenerowanemu otwarciu karty pozory legalnego ruchu marketingowego.

Jeszcze dalej szedł mechanizm aktywowany przy odinstalowaniu, w którym użyto formatu przekierowania przypominającego kliknięcia pochodzące z wyników wyszukiwania. Taki model może wspierać fałszowanie atrybucji, zawyżanie efektywności kampanii reklamowych oraz generowanie mylących sygnałów w systemach analitycznych i antyfraudowych.

Dodatkowym elementem ryzyka była obecność uśpionej funkcji pozwalającej na enumerację i usuwanie baz IndexedDB po uruchomieniu service workera. Nawet jeśli funkcja nie była aktywnie wykorzystywana od razu, sama jej obecność zwiększa zagrożenie późniejszą zmianą zachowania rozszerzenia, sabotażem danych lokalnych lub wdrożeniem bardziej inwazyjnych funkcji w przyszłych aktualizacjach.

Konsekwencje / ryzyko

Dla użytkowników indywidualnych podstawowe ryzyko obejmuje utratę prywatności, ekspozycję na nadmiarowe śledzenie i obniżenie bezpieczeństwa przeglądarki. Nawet jeśli rozszerzenie nie pełni roli klasycznego malware, może działać jak potencjalnie niechciany program przetwarzający więcej danych, niż użytkownik świadomie zaakceptował.

Z perspektywy organizacji problem jest poważniejszy. Rozszerzenia działające na stacjach roboczych mogą zwiększać powierzchnię ataku, wpływać na integralność sesji webowych, inicjować nieautoryzowane połączenia sieciowe i zaburzać monitoring ruchu. Jeśli ich zadaniem jest dodatkowo generowanie sztucznego ruchu i zniekształcanie źródeł wejść, skutki mogą objąć także analitykę marketingową, systemy antyfraudowe i ocenę reputacji środowiska.

Nie można też pomijać ryzyka ewolucji takich kampanii. Rozszerzenie, które dziś zbiera telemetrię lub wspiera adware, jutro może zostać zaktualizowane o bardziej agresywne funkcje, takie jak przechwytywanie treści stron, manipulowanie wynikami wyszukiwania, przekierowania czy integracja z kolejnymi etapami łańcucha monetyzacji.

Rekomendacje

Organizacje powinny przeprowadzić przegląd zainstalowanych rozszerzeń Chrome, szczególnie tych związanych z nową kartą, tapetami i motywami. Weryfikacja powinna objąć identyfikatory rozszerzeń, zakres uprawnień, aktywność sieciową oraz ewentualne powiązania z zewnętrzną infrastrukturą.

W środowiskach firmowych warto wdrożyć politykę allowlist dla rozszerzeń oraz centralne zarządzanie instalacjami z użyciem mechanizmów administracyjnych przeglądarki. Dodatki bez uzasadnienia biznesowego powinny być blokowane, a ich zachowanie monitorowane pod kątem anomalii.

  • sprawdzaj rozszerzenia deklarujące prostą funkcję wizualną, ale żądające szerokich uprawnień,
  • analizuj rozbieżności między opisem w sklepie a polityką prywatności,
  • monitoruj komunikację z nietypowymi domenami backendowymi,
  • zwracaj uwagę na otwieranie kart i przekierowania bez działania użytkownika,
  • kontroluj aktualizacje rozszerzeń zmieniające zakres uprawnień lub profil ruchu sieciowego.

Użytkownicy końcowi powinni ograniczyć liczbę dodatków do niezbędnego minimum, regularnie przeglądać listę zainstalowanych rozszerzeń i usuwać te, których już nie używają. Przed instalacją warto także sprawdzić reputację wydawcy, opinie, liczbę instalacji oraz rzeczywiście wymagane uprawnienia.

Podsumowanie

Przypadek 152 rozszerzeń Chrome podszywających się pod nieszkodliwe dodatki z tapetami pokazuje, że personalizacja przeglądarki może zostać wykorzystana jako nośnik adware, telemetrii i oszustw atrybucyjnych. Największe zagrożenie nie wynika wyłącznie z samego zbierania danych, lecz z połączenia wielu elementów: rozproszonej publikacji, niespójnych deklaracji prywatności, mechanizmów sztucznego generowania ruchu oraz obecności funkcji, które mogą zostać aktywowane bardziej agresywnie w przyszłości.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że rozszerzenia przeglądarkowe należy traktować jak pełnoprawny komponent ryzyka w architekturze endpointów i regularnie uwzględniać je w procesach kontroli bezpieczeństwa.

Źródła

  1. 152 Chrome Wallpaper Extensions with 105K Installs Linked to Adware and Fake Traffic — https://thehackernews.com/2026/06/152-chrome-wallpaper-extensions-with.html
  2. Socket Research — https://socket.dev

Naruszenie danych Infinite Campus objęło 137 tys. kont pracowników szkół

Cybersecurity news

Wprowadzenie do problemu / definicja

Infinite Campus, dostawca systemów informacji uczniowskiej dla szkół K–12 w Stanach Zjednoczonych, ujawnił incydent bezpieczeństwa związany z naruszeniem danych przechowywanych w środowisku Salesforce. Zdarzenie nie dotyczyło głównej bazy systemu SIS, lecz powiązanej platformy SaaS, w której znajdowały się informacje kontaktowe i organizacyjne personelu szkolnego.

To ważny przykład współczesnego ryzyka związanego z ekosystemem usług chmurowych. Atakujący coraz częściej omijają najlepiej chronione systemy podstawowe i koncentrują się na narzędziach CRM, helpdesk oraz integracjach biznesowych, które zawierają cenne dane operacyjne.

W skrócie

  • Naruszenie objęło około 137 100 unikalnych kont pracowników szkół.
  • Źródłem wycieku było środowisko Salesforce używane przez Infinite Campus.
  • Ujawnione dane obejmowały m.in. imiona i nazwiska, adresy e-mail, numery telefonów, adresy fizyczne, nazwy pracodawców, stanowiska, nazwy użytkowników i zgłoszenia wsparcia.
  • Incydent przypisano grupie ShinyHunters, znanej z ataków na konta i integracje oparte na Salesforce.
  • Największe ryzyko dotyczy dalszych kampanii phishingowych, podszywania się pod personel oraz rekonesansu przed kolejnymi atakami.

Kontekst / historia

Infinite Campus obsługuje tysiące okręgów szkolnych i przetwarza dane związane z funkcjonowaniem placówek edukacyjnych, co czyni firmę atrakcyjnym celem dla grup cyberprzestępczych. Już sam dostęp do danych kontaktowych personelu może mieć dużą wartość operacyjną, nawet jeśli atakujący nie uzyskali dostępu do centralnych systemów obsługujących dane uczniów.

Informacje o incydencie pojawiły się w marcu 2026 roku, kiedy firma poinformowała klientów o naruszeniu. W czerwcu 2026 roku dodatkowa analiza opublikowanych danych wskazała, że skala wycieku była większa i objęła 137 100 unikalnych kont. Zdarzenie wpisuje się w szerszy trend ataków na platformy CRM i środowiska SaaS, w których przechowywane są dane kontaktowe, rekordy wsparcia oraz informacje o strukturach organizacyjnych.

Analiza techniczna

Najistotniejszym elementem incydentu jest wektor dostępu. Celem ataku nie był główny system produkcyjny, lecz środowisko Salesforce zawierające relacje biznesowe, rekordy kontaktów oraz historię zgłoszeń. Tego typu platformy są szczególnie atrakcyjne dla napastników, ponieważ pozwalają szybko pozyskać dane przydatne w rekonesansie i dalszych operacjach socjotechnicznych.

W podobnych przypadkach kompromitacja może wynikać z przejęcia tożsamości użytkownika uprzywilejowanego, nadużycia tokenów aplikacyjnych, wykorzystania słabo zabezpieczonych integracji lub przejęcia aktywnej sesji. Po uzyskaniu dostępu przestępcy mogą eksportować rekordy CRM, kopiować tickety wsparcia, pobierać załączniki oraz budować mapę organizacji na podstawie stanowisk, domen, numerów telefonów i zależności pomiędzy pracownikami.

Szczególnie istotne jest ujawnienie zgłoszeń supportowych. Takie dane często zawierają dodatkowy kontekst techniczny, na przykład identyfikatory kont, opisy problemów, informacje o konfiguracji, dane administratorów czy elementy procedur związanych z resetem dostępu. Nawet jeśli nie doszło do kompromitacji głównej bazy klientów, tak pozyskane informacje mogą znacząco ułatwić kolejne etapy ataku.

Incydent pokazuje również, że pozornie mało wrażliwe dane katalogowe po agregacji stają się bardzo wartościowym zasobem. Zestawienie imienia i nazwiska, stanowiska, organizacji, adresu e-mail i numeru telefonu wystarcza do przygotowania wiarygodnych wiadomości spear phishingowych lub prób podszywania się pod dział IT.

Konsekwencje / ryzyko

Bezpośrednim skutkiem naruszenia jest ekspozycja danych identyfikacyjnych i kontaktowych pracowników szkół. Taka baza może zostać wykorzystana do ukierunkowanych kampanii phishingowych, vishingu, oszustw SMS oraz prób wyłudzenia danych logowania. Im bardziej szczegółowy profil ofiary, tym większa skuteczność ataku.

Ryzyko nie ogranicza się do prostego spamu. Dane z CRM i systemów wsparcia umożliwiają rekonesans przed atakami na szkoły, dostawców usług edukacyjnych i partnerów technologicznych. Napastnicy mogą zidentyfikować osoby odpowiedzialne za administrację, finanse, wdrożenia lub wsparcie techniczne, a następnie skierować do nich precyzyjne próby oszustwa lub przejęcia kont.

Dodatkowym zagrożeniem jest możliwość obchodzenia procedur helpdesk. Jeśli ujawnione informacje zawierają schematy nazw użytkowników, dane kontaktowe i szczegóły zgłoszeń, mogą one posłużyć do fałszywych próśb o reset hasła, zmianę danych konta lub eskalację dostępu. W sektorze edukacyjnym, który często dysponuje ograniczonymi zasobami bezpieczeństwa, takie incydenty mogą mieć długotrwałe skutki operacyjne.

Rekomendacje

Organizacje korzystające z Salesforce, CRM i innych usług SaaS powinny traktować je jak systemy krytyczne. Oznacza to wdrożenie silnego uwierzytelniania wieloskładnikowego odpornego na phishing, ograniczenie liczby kont uprzywilejowanych oraz regularny przegląd uprawnień użytkowników i kont integracyjnych.

Kluczowe jest również monitorowanie anomalii związanych z eksportem danych i dostępem do rekordów. Szczególną uwagę należy zwrócić na:

  • masowe pobieranie danych z CRM,
  • nietypowe logowania z nowych lokalizacji lub urządzeń,
  • tworzenie i użycie nowych tokenów API,
  • nagłe zmiany uprawnień,
  • dostęp do dużej liczby zgłoszeń wsparcia w krótkim czasie.

W przypadku wycieku ticketów wsparcia należy przeprowadzić dodatkową ocenę ryzyka pod kątem informacji operacyjnych zawartych w zgłoszeniach. Może to oznaczać reset wybranych poświadczeń, aktualizację procedur weryfikacji tożsamości w helpdesku oraz poinformowanie pracowników o spodziewanych kampaniach podszywania się pod dział IT i dostawców.

Dobrą praktyką pozostaje także minimalizacja danych przechowywanych w systemach CRM, stosowanie polityk retencji oraz klasyfikacja informacji przetwarzanych w usługach SaaS. Środowiska zewnętrzne powinny podlegać takim samym wymaganiom bezpieczeństwa jak systemy podstawowe.

Podsumowanie

Incydent w Infinite Campus potwierdza, że poważne naruszenie danych nie musi obejmować głównego systemu produkcyjnego, aby stworzyć realne zagrożenie dla organizacji i ich użytkowników. Wyciek danych z platformy Salesforce ujawnił informacje o ponad 137 tysiącach kont pracowników szkół, co stwarza dogodne warunki do dalszych ataków socjotechnicznych.

Dla sektora edukacyjnego to wyraźny sygnał, że bezpieczeństwo platform SaaS, narzędzi CRM i systemów wsparcia powinno być traktowane priorytetowo. Ochrona tożsamości, monitoring aktywności, ograniczanie ekspozycji danych oraz dojrzałe procedury reagowania pozostają kluczowe w ograniczaniu skutków podobnych incydentów.

Źródła

  1. https://www.bleepingcomputer.com/news/security/infinite-campus-data-breach-affects-137-000-school-staff-accounts/
  2. https://www.infinitecampus.com/
  3. https://haveibeenpwned.com/

Cisco łata krytyczną lukę zero-day w Catalyst SD-WAN Manager

Cybersecurity news

Wprowadzenie do problemu / definicja

Cisco opublikowało poprawki bezpieczeństwa dla krytycznej podatności w Cisco Catalyst SD-WAN Manager, wcześniej znanym jako SD-WAN vManage. Luka dotyczy interfejsu webowego centralnej platformy zarządzającej środowiskami SD-WAN i według producenta była już wykorzystywana w rzeczywistych atakach jako zero-day.

Problem ma szczególne znaczenie operacyjne, ponieważ umożliwia uwierzytelnionemu napastnikowi z niskimi uprawnieniami doprowadzenie do eskalacji uprawnień do poziomu root. W praktyce oznacza to możliwość pełnego przejęcia kontroli nad systemem zarządzającym infrastrukturą sieciową.

W skrócie

Podatność została oznaczona jako CVE-2026-20262 i wynika z niewystarczającej walidacji danych wejściowych podczas przesyłania plików do podatnego punktu API. Skuteczny atak pozwala tworzyć lub nadpisywać pliki w systemie, co następnie może zostać wykorzystane do uzyskania najwyższych uprawnień.

  • dotyczy Cisco Catalyst SD-WAN Manager,
  • umożliwia zapis lub nadpisanie plików w systemie,
  • prowadzi do eskalacji uprawnień do root,
  • była aktywnie wykorzystywana przed publikacją poprawek,
  • wymaga pilnego wdrożenia aktualizacji i analizy logów.

Kontekst / historia

Cisco Catalyst SD-WAN Manager jest centralnym komponentem administracyjnym wykorzystywanym do zarządzania rozległymi wdrożeniami SD-WAN, często obejmującymi setki lub tysiące urządzeń. Z tego powodu każda luka w tej warstwie ma wysoki priorytet z perspektywy ciągłości działania i bezpieczeństwa sieci.

Incydent wpisuje się w szerszy trend wzmożonego zainteresowania cyberprzestępców oraz zaawansowanych grup APT systemami zarządzania siecią. Tego typu platformy są atrakcyjnym celem, ponieważ ich kompromitacja może otworzyć drogę do manipulowania politykami ruchu, dostępu do danych administracyjnych oraz dalszego poruszania się po środowisku ofiary.

Analiza techniczna

Źródłem problemu jest nieprawidłowa walidacja danych dostarczanych przez użytkownika podczas procesu uploadu plików. Odpowiednio spreparowane żądanie HTTP skierowane do podatnego endpointu API może doprowadzić do utworzenia lub nadpisania plików w systemie plików hosta zarządzającego.

Mechanizm ten jest wyjątkowo niebezpieczny, ponieważ możliwość zapisu plików stanowi częsty etap pośredni prowadzący do pełnego przejęcia systemu. Napastnik może wykorzystać tę ścieżkę do umieszczenia artefaktów aplikacyjnych, komponentów wykonywalnych lub elementów pozwalających utrwalić dostęp i podnieść uprawnienia do poziomu root.

Problem obejmował różne typy wdrożeń, w tym środowiska lokalne, instancje chmurowe oraz warianty przeznaczone dla sektora publicznego. To istotne, ponieważ wskazuje na szeroki zakres ekspozycji i brak ograniczenia podatności do jednej niszowej konfiguracji.

Cisco udostępniło poprawki dla kilku gałęzi oprogramowania. Organizacje korzystające z linii 20.9, 20.12, 20.15, 20.18 oraz 26.1 powinny zweryfikować, czy ich instancje zostały zaktualizowane do wersji naprawionych. Producent zalecił również przegląd logów usług vmanage-server, vmanage-appserver i serviceproxy-access pod kątem podejrzanych uploadów, w tym plików takich jak index.jsp oraz archiwów .war.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-20262 należy ocenić jako wysokie. Przejęcie systemu zarządzania SD-WAN oznacza potencjalny dostęp do jednego z najważniejszych komponentów administracyjnych infrastruktury sieciowej, odpowiedzialnego za polityki, segmentację, konfigurację i widoczność działania urządzeń.

W najgorszym scenariuszu napastnik może nie tylko przejąć sam serwer, ale również wykorzystać go jako punkt wyjścia do dalszych działań w środowisku.

  • modyfikacja konfiguracji infrastruktury SD-WAN,
  • wprowadzanie złośliwych zmian w politykach ruchu,
  • dostęp do danych administracyjnych i sekretów systemowych,
  • ruch boczny do kolejnych segmentów środowiska,
  • utrudnianie wykrycia incydentu przez ingerencję w logi,
  • utrwalenie dostępu w krytycznej warstwie zarządzającej.

Szczególnie alarmujący jest fakt aktywnego wykorzystania luki jako zero-day. Oznacza to, że organizacje nie mogą traktować tego problemu wyłącznie jako teoretycznej podatności po publikacji advisory, lecz powinny zakładać realne ryzyko wcześniejszej kompromitacji.

Rekomendacje

Najważniejszym działaniem jest natychmiastowe wdrożenie poprawek bezpieczeństwa opublikowanych przez Cisco. Jeżeli aktualizacja nie może zostać przeprowadzona od razu, konieczne jest czasowe ograniczenie ekspozycji panelu administracyjnego, choć nie zastępuje to pełnej remediacji.

  • przeprowadzić pełną inwentaryzację instancji Cisco Catalyst SD-WAN Manager,
  • potwierdzić wersje oprogramowania i zgodność z listą wersji naprawionych,
  • przeanalizować logi vmanage-server, vmanage-appserver i serviceproxy-access,
  • szukać nieautoryzowanych plików, w tym index.jsp i archiwów .war,
  • ograniczyć dostęp administracyjny wyłącznie do zaufanych segmentów,
  • wymusić silne uwierzytelnianie dla kont uprzywilejowanych,
  • zweryfikować integralność systemu plików i konfiguracji po aktualizacji,
  • dodać reguły detekcji w SIEM, IDS i EDR,
  • przygotować procedurę reagowania na incydent w przypadku wykrycia śladów naruszenia.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto dodatkowo przeprowadzić przegląd ostatnich zmian konfiguracyjnych oraz rozważyć rotację poświadczeń, jeśli istnieje podejrzenie, że kontroler mógł zostać naruszony.

Podsumowanie

CVE-2026-20262 to poważna luka w ekosystemie Cisco SD-WAN, umożliwiająca zapis plików i eskalację uprawnień do root w centralnym systemie zarządzania. Ze względu na potwierdzone wykorzystanie jako zero-day sprawa powinna być traktowana priorytetowo przez zespoły bezpieczeństwa, administratorów sieci i operatorów infrastruktury krytycznej.

W praktyce oznacza to konieczność nie tylko szybkiego wdrożenia aktualizacji, ale również aktywnego poszukiwania śladów kompromitacji. W przypadku platform zarządzających siecią czas reakcji bezpośrednio wpływa na skalę ryzyka dla całego środowiska.

Źródła

  1. Cisco fixes SD-WAN vManage flaw exploited in zero-day attacks — https://www.bleepingcomputer.com/news/security/cisco-fixes-sd-wan-vmanage-flaw-exploited-in-zero-day-attacks/
  2. Cisco Security Advisory: Cisco Catalyst SD-WAN Manager Arbitrary File Upload Vulnerability — https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vman-fileupl-7j1R9xZv
  3. NVD: CVE-2026-20262 — https://nvd.nist.gov/vuln/detail/CVE-2026-20262

Krytyczna luka w Microsoft 365 Copilot umożliwiała jednoklikowy wyciek danych

Cybersecurity news

Wprowadzenie do problemu / definicja

Microsoft 365 Copilot to asystent oparty na sztucznej inteligencji, który łączy dane z poczty, kalendarza, dokumentów i zasobów organizacyjnych w ramach ekosystemu Microsoft 365. W czerwcu 2026 roku ujawniono jednak poważną podatność oznaczoną jako CVE-2026-42824, która mogła umożliwić wyprowadzenie wrażliwych informacji po zaledwie jednym kliknięciu użytkownika w odpowiednio przygotowany link.

Problem był szczególnie groźny, ponieważ nie wymagał przejęcia konta ofiary ani klasycznego obejścia mechanizmów logowania. Atak wykorzystywał sposób, w jaki Copilot interpretował parametry wejściowe, renderował odpowiedzi oraz współpracował z mechanizmami bezpieczeństwa przeglądarki.

W skrócie

Luka określana jako SearchLeak łączyła kilka słabości w jeden skuteczny łańcuch ataku. Napastnik mógł osadzić w parametrze zapytania instrukcję dla Copilota, doprowadzić do wykonania złośliwego elementu HTML przed zakończeniem sanitacji treści, a następnie wykorzystać dozwolony mechanizm pośredniczący do obejścia ograniczeń polityki CSP.

  • atak rozpoczynał się od kliknięcia w link prowadzący do zaufanej domeny,
  • Copilot interpretował parametr URL nie tylko jako wyszukiwanie, ale także jako polecenie,
  • odpowiedź modelu mogła wywołać żądanie sieciowe przed pełnym oczyszczeniem treści,
  • w efekcie możliwy był wyciek tematów wiadomości, danych kalendarzowych, treści dokumentów, a w niektórych przypadkach także kodów MFA i linków resetu hasła.

Microsoft wdrożył już poprawkę po stronie usługi, ale sam incydent pokazuje skalę ryzyka związanego z integracją AI z danymi korporacyjnymi.

Kontekst / historia

SearchLeak wpisuje się w rosnącą grupę podatności charakterystycznych dla systemów generatywnej AI, w których klasyczne błędy aplikacyjne łączą się z nowymi wektorami ataku, takimi jak prompt injection. To ważna zmiana, ponieważ wcześniej podobne problemy analizowano głównie w kontekście aplikacji webowych, a dziś coraz częściej występują one w narzędziach AI działających na uprzywilejowanych danych biznesowych.

W przypadku Microsoft 365 Copilot znaczenie luki wynikało z jego dostępu do środowiska użytkownika. Narzędzie działa w kontekście zalogowanej osoby i może odczytywać zasoby dostępne z poziomu Exchange Online, SharePoint czy OneDrive. Oznacza to, że skuteczny atak nie musiał łamać zabezpieczeń tenantu, lecz jedynie wykorzystać uprawnienia już posiadane przez ofiarę.

Analiza techniczna

Łańcuch ataku składał się z trzech kluczowych etapów. Pierwszym była podatność typu Parameter-to-Prompt Injection. Parametr q w adresie URL wyszukiwania Copilota mógł zostać użyty nie tylko jako zwykłe zapytanie, ale również jako instrukcja kierowana do modelu. Dzięki temu atakujący mógł nakłonić system do wyszukania określonych informacji, takich jak tematy wiadomości, kody bezpieczeństwa czy fragmenty dokumentów.

Drugim elementem był problem z renderowaniem odpowiedzi. Sanitacja generowanej treści następowała zbyt późno względem strumieniowego wyświetlania odpowiedzi w przeglądarce. Jeśli model zwrócił element HTML inicjujący żądanie sieciowe, przeglądarka mogła rozpocząć komunikację jeszcze zanim zabezpieczenia zdążyły zneutralizować niebezpieczny fragment.

Trzecim etapem było obejście polityki Content Security Policy. Chociaż środowisko blokowało bezpośrednie ładowanie zasobów z nieautoryzowanych domen, dopuszczało określone usługi pośredniczące. Badacze wykazali, że taki dozwolony endpoint mógł pobrać zasób z serwera kontrolowanego przez napastnika. Jeśli wcześniej dane zostały zakodowane w ścieżce lub parametrze URL, finalnie trafiały do infrastruktury atakującego.

W praktyce cały scenariusz mógł wyglądać następująco: użytkownik otwierał link do zaufanej domeny, Copilot realizował osadzoną w nim instrukcję, odpowiedź zawierała element wywołujący połączenie sieciowe, a pośrednicząca usługa przekazywała żądanie na zewnętrzny serwer wraz z fragmentem wyprowadzanych danych. Całość odbywała się bez dodatkowej interakcji ze strony ofiary.

Konsekwencje / ryzyko

Skutki tej podatności należy ocenić jako bardzo poważne, zwłaszcza w organizacjach intensywnie korzystających z Copilota i przechowujących w Microsoft 365 dane o wysokiej wrażliwości. Atakujący mógł potencjalnie uzyskać dostęp do korespondencji, zaproszeń kalendarzowych, notatek, dokumentów firmowych oraz innych informacji dostępnych dla zalogowanego użytkownika.

Szczególnie niebezpieczne były scenariusze obejmujące krótkotrwałe sekrety, takie jak jednorazowe kody MFA, wiadomości z kodami weryfikacyjnymi lub linki resetu hasła. Uzyskanie takich danych we właściwym momencie mogło umożliwić przejęcie konta lub dalszą eskalację dostępu.

Istotny był również fakt, że link prowadził do legalnej i rozpoznawalnej domeny. To ograniczało skuteczność klasycznych mechanizmów antyphishingowych i zwiększało szansę, że użytkownik zaufa odnośnikowi. Ostateczny zasięg szkód zależał więc w dużej mierze od poziomu nadmiarowych uprawnień oraz skali ekspozycji danych w organizacji.

Rekomendacje

Ponieważ poprawka została wdrożona po stronie usługi zarządzanej, organizacje powinny skoncentrować się na działaniach ograniczających skutki podobnych incydentów w przyszłości. Kluczowe pozostają detekcja, kontrola uprawnień oraz podniesienie świadomości użytkowników.

  • monitorowanie logów pod kątem nietypowych adresów URL wyszukiwania Copilota, zwłaszcza z długimi lub zakodowanymi wartościami parametru q,
  • analiza ruchu związanego z usługami pośredniczącymi w pobieraniu zasobów i korelowanie go z użyciem Copilota,
  • przegląd uprawnień w SharePoint, OneDrive i Exchange zgodnie z zasadą najmniejszych uprawnień,
  • stosowanie etykiet wrażliwości i ograniczanie nadmiernej ekspozycji danych historycznych,
  • aktualizacja szkoleń awareness, aby użytkownicy wiedzieli, że także linki do zaufanych domen mogą być wektorem ataku,
  • projektowanie interfejsów AI zgodnie z zasadą, że odpowiedzi generowane przez model należy traktować jako dane nieufne do momentu bezpiecznego wyrenderowania.

Podsumowanie

Incydent SearchLeak pokazał, że bezpieczeństwo systemów AI nie może być analizowane wyłącznie przez pryzmat prompt injection ani tylko tradycyjnych błędów aplikacyjnych. Najgroźniejsze scenariusze pojawiają się wtedy, gdy oba światy łączą się w jeden skuteczny łańcuch eksploatacji.

Choć Microsoft usunął już opisaną lukę, sprawa pozostaje ważnym ostrzeżeniem dla firm wdrażających asystentów AI w środowiskach korporacyjnych. Ograniczanie uprawnień, monitoring nietypowych zachowań oraz traktowanie komponentów AI jako nowej powierzchni ataku powinny stać się standardem bezpieczeństwa.

Źródła

  1. One-Click Microsoft 365 Copilot Flaw Could Have Let Attackers Steal Emails, Files, and MFA Codes — https://thehackernews.com/2026/06/one-click-microsoft-365-copilot-flaw.html
  2. SearchLeak: How We Turned M365 Copilot Into a One-Click Data Exfiltration Weapon — https://www.varonis.com/blog/searchleak
  3. Microsoft Security Response Center — CVE-2026-42824 — https://msrc.microsoft.com/update-guide/
  4. National Vulnerability Database — https://nvd.nist.gov/