Wojciech Ciemski, Autor w serwisie Security Bez Tabu

FulcrumSec twierdzi, że włamał się do Novo Nordisk. W tle 1,3 TB danych i ryzyko utraty własności intelektualnej

Wprowadzenie do problemu / definicja

Incydenty typu hack-and-leak należą dziś do najpoważniejszych zagrożeń dla sektora farmaceutycznego i biotechnologicznego. Tego rodzaju operacje łączą nieautoryzowany dostęp do systemów, kradzież danych oraz presję finansową opartą na groźbie ich publikacji. W przypadku globalnych firm medycznych stawką są nie tylko informacje operacyjne, ale także dokumentacja badań klinicznych, poufne dane rozwojowe oraz własność intelektualna o strategicznej wartości.

Właśnie w taki schemat wpisują się twierdzenia grupy FulcrumSec, która ogłosiła, że przeprowadziła włamanie do duńskiego koncernu farmaceutycznego Novo Nordisk. Według napastników kompromitacja miała objąć zarówno repozytoria kodu, jak i szeroki zestaw danych biznesowych oraz technicznych.

W skrócie

Grupa FulcrumSec przypisała sobie atak na Novo Nordisk.
Napastnicy twierdzą, że uzyskali dostęp z użyciem tokenu GitHub i następnie pozyskali kolejne poświadczenia.
Według deklaracji sprawców wykradziono około 1,3 TB danych oraz listę ponad 700 tysięcy plików.
W tle pojawia się żądanie okupu w wysokości 25 mln dolarów oraz groźba upublicznienia materiałów.
Incydent może mieć znaczenie nie tylko operacyjne, ale również regulacyjne, reputacyjne i biznesowe.

Kontekst / historia

Sprawa zyskała rozgłos po wcześniejszym ujawnieniu przez Novo Nordisk incydentu bezpieczeństwa, w ramach którego nieuprawnione osoby uzyskały dostęp do części wewnętrznych systemów IT i wyeksfiltrowały dane związane z badaniami klinicznymi. Firma wskazywała, że naruszone informacje miały charakter pseudonimizowany, co ograniczało możliwość bezpośredniej identyfikacji pacjentów bez dostępu do dodatkowych zbiorów danych.

W kolejnej fazie grupa FulcrumSec zaczęła publicznie budować narrację wokół skali ataku. To dobrze znany model działania środowisk nastawionych na wymuszenia: po uzyskaniu dostępu przestępcy próbują zwiększyć presję na ofiarę poprzez przedstawianie dowodów posiadania danych, podkreślanie ich wartości oraz sugerowanie szerokiego zasięgu kompromitacji.

Analiza techniczna

Najważniejszym elementem technicznym całej sprawy jest deklarowany wektor wejścia oparty na tokenie dostępu do GitHub. Jeżeli taki token jest nadmiernie uprzywilejowany, nie wygasa lub nie jest właściwie chroniony, może stać się początkiem pełnego łańcucha kompromitacji. Atakujący zyskuje wtedy możliwość klonowania repozytoriów, analizy kodu, przeszukiwania historii commitów oraz identyfikowania sekretów zapisanych w plikach konfiguracyjnych lub artefaktach deweloperskich.

Opisany scenariusz sugeruje, że początkowy dostęp mógł posłużyć do odnalezienia dalszych poświadczeń, kluczy API, danych do integracji CI/CD oraz dostępu do usług chmurowych i narzędzi badawczo-rozwojowych. W realiach dużych organizacji farmaceutycznych repozytoria bardzo często zawierają nie tylko kod aplikacji, ale też dokumentację procesową, pipeline’y danych, modele analityczne, komponenty AI oraz metadane wspierające prace R&D.

Szczególne znaczenie mają twierdzenia o możliwej kradzieży materiałów o wysokiej wartości biznesowej, takich jak nieujawnione programy lekowe, zastrzeżone struktury związków, elementy pipeline’u RNAi czy prywatne modele AI. Nawet jeśli część tych deklaracji nie została niezależnie potwierdzona, sam profil rzekomo przejętych danych wskazuje na potencjalne przeniknięcie do środowisk o znaczeniu strategicznym.

Nie mniej istotne są przedstawione przez sprawców próbki dowodowe, obejmujące listy plików oraz skradzione poświadczenia. Z perspektywy zespołów reagowania na incydenty oznacza to konieczność traktowania zdarzenia jako potencjalnie wielowarstwowego, obejmującego zarówno wyciek danych, jak i kompromitację tożsamości maszynowych, sekretów aplikacyjnych oraz kont uprzywilejowanych.

Konsekwencje / ryzyko

Dla sektora life sciences skutki podobnego incydentu mogą być znacznie poważniejsze niż w klasycznych atakach ransomware. Pierwszym obszarem ryzyka jest ekspozycja danych badań klinicznych oraz informacji regulacyjnych. Nawet jeśli dane są pseudonimizowane, nie można całkowicie wykluczyć ryzyka wtórnej reidentyfikacji po połączeniu ich z dodatkowymi zbiorami.

Drugim kluczowym zagrożeniem jest utrata własności intelektualnej. W branży farmaceutycznej takie zasoby są rezultatem wieloletnich inwestycji i mogą mieć bezpośredni wpływ na przewagę konkurencyjną, harmonogram projektów, relacje z partnerami oraz wycenę przedsiębiorstwa.

Trzecim problemem jest możliwość długotrwałej obecności przeciwnika w środowisku. Jeżeli naruszone zostały tokeny i konta wykorzystywane w procesach automatyzacji, integracjach chmurowych lub łańcuchu dostaw oprogramowania, incydent może otworzyć drogę do dalszych nadużyć, modyfikacji kodu, sabotażu buildów albo ataków na podmioty współpracujące.

Nie można też pominąć skutków reputacyjnych i prawnych. Firmy przetwarzające dane medyczne, badawcze i partnerskie muszą liczyć się z obowiązkami notyfikacyjnymi, kosztownym dochodzeniem forensycznym, kontrolami regulacyjnymi oraz potencjalnymi roszczeniami kontraktowymi.

Rekomendacje

Podstawowym działaniem powinien być natychmiastowy przegląd wszystkich tokenów dostępowych, kluczy API i sekretów używanych w repozytoriach, systemach CI/CD oraz integracjach z chmurą. Tokeny powinny być krótkotrwałe, ściśle ograniczone zakresem uprawnień i regularnie rotowane.

Równie ważne jest wzmocnienie bezpieczeństwa platform deweloperskich. Obejmuje to wdrożenie odpornego na phishing MFA, segmentację dostępu do repozytoriów, polityki least privilege oraz monitorowanie anomalii związanych z klonowaniem repozytoriów i wykorzystaniem tokenów osobistych lub serwisowych.

Organizacje powinny także prowadzić pełną inwentaryzację przepływu danych pomiędzy środowiskami badawczymi, deweloperskimi i produkcyjnymi. Mapowanie zależności między repozytoriami, magazynami danych, systemami analitycznymi, narzędziami MLOps i zasobami laboratoryjnymi jest niezbędne do oceny realnej skali kompromitacji.

Z perspektywy reagowania na incydenty należy przyjąć założenie, że przeciwnik mógł uzyskać zarówno dane, jak i poświadczenia. W praktyce oznacza to konieczność masowej rotacji sekretów, audytu kont uprzywilejowanych, analizy logów dostępu do repozytoriów, przeglądu systemów budowania oprogramowania oraz weryfikacji integralności krytycznych artefaktów.

Dla organizacji z branży farmaceutycznej istotne jest również wdrożenie dodatkowych zabezpieczeń wokół danych badań klinicznych i własności intelektualnej. Wśród nich warto wskazać szyfrowanie warstwowe, DLP ukierunkowane na dokumentację R&D, ścisłą kontrolę eksportu danych, znakowanie informacji oraz wyraźne rozdzielenie środowisk badawczych od narzędzi ogólnokorporacyjnych.

Podsumowanie

Domniemany atak na Novo Nordisk pokazuje, że współczesne kampanie wymuszeniowe coraz częściej koncentrują się na zasobach o najwyższej wartości strategicznej: repozytoriach kodu, sekretach dostępowych, danych badań klinicznych i własności intelektualnej. Nawet jeśli część twierdzeń sprawców nadal wymaga weryfikacji, sam scenariusz dobrze ilustruje skalę ryzyka związanego z kompromitacją tożsamości deweloperskich i niewłaściwie chronionych tokenów.

Dla firm działających w sektorach regulowanych to kolejny sygnał, że bezpieczeństwo łańcucha wytwarzania oprogramowania oraz ochrona środowisk R&D powinny być traktowane jako element krytyczny, a nie jedynie funkcja wspierająca działalność biznesową.

Źródła

SecurityWeek – Cybercrime Group Claims Novo Nordisk Hack
https://www.securityweek.com/cybercrime-group-claims-novo-nordisk-hack/

Biały Dom wzmacnia cyberbezpieczeństwo systemów bezpieczeństwa narodowego USA

Wprowadzenie do problemu / definicja

Systemy bezpieczeństwa narodowego USA, określane jako National Security Systems (NSS), należą do najbardziej wrażliwych środowisk teleinformatycznych administracji federalnej. Obejmują infrastrukturę przetwarzającą informacje niejawne oraz wspierającą działania wojskowe, wywiadowcze i strategiczne. W praktyce oznacza to, że każda luka organizacyjna, niespójność standardów lub opóźnienie w reagowaniu na zagrożenia może przełożyć się bezpośrednio na bezpieczeństwo państwa.

Nowe memorandum NSPM-12 pokazuje, że administracja USA chce uporządkować sposób nadzoru nad NSS, wzmocnić odpowiedzialność instytucji federalnych i zapewnić bardziej jednolity poziom ochrony dla całego ekosystemu tych systemów.

W skrócie

Biały Dom ogłosił memorandum NSPM-12, którego celem jest podniesienie poziomu cyberbezpieczeństwa systemów bezpieczeństwa narodowego. Dokument przywraca Komitet ds. Systemów Bezpieczeństwa Narodowego (CNSS) i nadaje mu kluczową rolę w zakresie ustalania bazowych wymagań bezpieczeństwa, koordynacji działań międzyagencyjnych oraz reagowania na sytuacje kryzysowe.

CNSS ma odpowiadać za nadzór nad cyberbezpieczeństwem NSS w skali całego rządu federalnego.
Dyrektor NSA obejmie funkcję National Manager for NSS.
Agencje federalne będą musiały prowadzić i corocznie aktualizować inwentaryzację systemów NSS.
Memorandum przewiduje także przegląd i harmonizację istniejących polityk oraz dyrektyw bezpieczeństwa.

Kontekst / historia

Przez lata ochrona federalnych systemów w USA rozwijała się w modelu rozproszonym. Poszczególne agencje odpowiadały za własne środowiska zgodnie z obowiązującymi politykami, wytycznymi i regulacjami sektorowymi. Taki model dawał elastyczność, ale jednocześnie zwiększał ryzyko nierównego poziomu zabezpieczeń między różnymi instytucjami.

W praktyce oznaczało to możliwość powstawania słabszych ogniw w środowisku międzyagencyjnym. Dla przeciwników prowadzących zaawansowane operacje cybernetyczne, zwłaszcza sponsorowane przez państwa, taka niespójność mogła stanowić okazję do ataku przez najmniej dojrzały organizacyjnie lub technicznie podmiot.

NSPM-12 należy więc postrzegać jako próbę odejścia od nadmiernie rozproszonego modelu governance na rzecz bardziej sformalizowanego i centralnie koordynowanego systemu zarządzania bezpieczeństwem NSS.

Analiza techniczna

Memorandum nie odnosi się do pojedynczej podatności ani konkretnego incydentu. Z technicznego punktu widzenia jego znaczenie polega na uszczelnieniu całego modelu zarządzania bezpieczeństwem oraz skróceniu ścieżki decyzyjnej między identyfikacją zagrożenia a wdrożeniem środków ochronnych.

CNSS otrzymuje kompetencje do ustalania minimalnych wymagań bazowych dla NSS. Taki mechanizm może przełożyć się na większą spójność w obszarach takich jak kontrola dostępu, segmentacja sieci, zarządzanie konfiguracją, monitorowanie bezpieczeństwa, reagowanie na incydenty oraz priorytetyzacja działań naprawczych.

Istotna jest również rola dyrektora NSA jako National Manager for NSS. Funkcja ta obejmuje doradztwo techniczne, rekomendowanie środków ochronnych i możliwość wydawania dyrektyw awaryjnych, gdy dostępne są przesłanki wywiadowcze wskazujące na zdolność lub zamiar przeciwnika do przeprowadzenia ataku na NSS. To szczególnie ważne w kontekście kampanii APT, wykorzystania luk zero-day oraz operacji wymierzonych w systemy krytyczne i niejawne.

Ważnym elementem memorandum jest także przegląd istniejących polityk, instrukcji i dyrektyw CNSS. Harmonizacja dokumentacji bezpieczeństwa ma znaczenie operacyjne, ponieważ redukuje problemy interpretacyjne, ogranicza różnice we wdrażaniu zabezpieczeń i ułatwia audyt zgodności.

Na szczególną uwagę zasługuje także obowiązek utrzymywania i corocznej aktualizacji inwentaryzacji systemów NSS. Pełna widoczność aktywów pozostaje fundamentem skutecznego zarządzania ryzykiem, planowania hardeningu, oceny pokrycia kontrolami bezpieczeństwa i szybkiego ustalenia skali incydentu.

Konsekwencje / ryzyko

Najbardziej odczuwalnym skutkiem NSPM-12 będzie wzrost formalizacji procesów bezpieczeństwa w agencjach odpowiedzialnych za NSS. Oznacza to konieczność aktualizacji polityk, modeli raportowania, procedur współpracy oraz sposobu nadzoru nad systemami o najwyższej krytyczności.

Z perspektywy ryzyka memorandum ogranicza kilka kluczowych problemów. Po pierwsze, zmniejsza prawdopodobieństwo istnienia słabszych ogniw pomiędzy agencjami. Po drugie, wzmacnia gotowość do reagowania na zagrożenia strategiczne dzięki możliwości szybkiego wdrażania działań ochronnych opartych na danych wywiadowczych. Po trzecie, zwiększa odpowiedzialność za zgodność z minimalnymi standardami bezpieczeństwa.

Jednocześnie nie można wykluczyć wyzwań wdrożeniowych. Centralizacja nadzoru może podnieść obciążenie administracyjne, a standaryzacja wymagań bywa trudna w środowiskach różniących się architekturą, klasyfikacją informacji i modelami operacyjnymi. Istotne będzie więc zachowanie równowagi między formalnym governance a szybkością reakcji technicznej.

Rekomendacje

Choć memorandum dotyczy amerykańskich systemów bezpieczeństwa narodowego, jego założenia stanowią wartościowy punkt odniesienia także dla innych organizacji publicznych oraz podmiotów współpracujących z administracją i sektorem obronnym.

Przeprowadzić pełną inwentaryzację systemów, zasobów i zależności krytycznych.
Zweryfikować, czy polityki bezpieczeństwa są spójne, aktualne i możliwe do skutecznego egzekwowania.
Ujednolicić minimalne baseline’y bezpieczeństwa dla systemów o najwyższej krytyczności.
Zacieśnić współpracę między SOC, zespołami reagowania na incydenty, architekturą bezpieczeństwa i zarządzaniem ryzykiem.
Przygotować procedury szybkiego wdrażania dyrektyw awaryjnych i zmian konfiguracyjnych.
Rozwijać zdolności threat intelligence oraz mechanizmy przekładania danych wywiadowczych na działania techniczne.
Regularnie testować gotowość operacyjną poprzez ćwiczenia tabletop, scenariusze red team i walidację planów reagowania.

Dobrą praktyką pozostaje również jasne przypisanie właścicielstwa systemów i odpowiedzialności decyzyjnej. W środowiskach wysokiego ryzyka nieprecyzyjny podział kompetencji często okazuje się większym problemem niż sama technologia.

Podsumowanie

NSPM-12 nie jest reakcją na jeden incydent, lecz elementem strategicznego wzmacniania ochrony amerykańskich systemów bezpieczeństwa narodowego. Memorandum przywraca znaczenie CNSS, rozszerza rolę NSA w obszarze NSS i podkreśla wagę standaryzacji, centralnego nadzoru oraz rzetelnej inwentaryzacji aktywów.

Dla specjalistów cyberbezpieczeństwa to wyraźny sygnał, że odporność najbardziej krytycznych środowisk zależy nie tylko od narzędzi ochronnych, ale również od jakości governance, szybkości koordynacji i spójności wymagań bezpieczeństwa.

Źródła

SecurityWeek — White House Issues Memo to Bolster NSS Cybersecurity — https://www.securityweek.com/white-house-issues-memo-to-bolster-nss-cybersecurity/
The White House — National Security Presidential Memorandum/NSPM-12 — https://www.whitehouse.gov/presidential-actions/2026/06/national-security-presidential-memorandum-nspm-12/
The White House — Fact Sheet: President Donald J. Trump Strengthens Cybersecurity for National Security Systems — https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-strengthens-cybersecurity-for-national-security-systems/

FBI ostrzega przed nową falą oszustw kryptowalutowych z udziałem kurierów odbierających gotówkę

Wprowadzenie do problemu / definicja

FBI ostrzegło przed nowym wariantem oszustw inwestycyjnych powiązanych z kryptowalutami, w którym przestępcy wykorzystują kurierów do osobistego odbioru gotówki od ofiar. Mechanizm ten stanowi rozwinięcie znanych schematów fraudowych i ma na celu obejście zabezpieczeń bankowych oraz utrzymanie fikcyjnej narracji o rzekomych zyskach z inwestycji.

W praktyce ofiara jest przekonywana, że uczestniczy w legalnym procesie inwestycyjnym. Gdy przelewy lub inne formy płatności elektronicznej napotykają blokady albo wzbudzają podejrzenia instytucji finansowych, oszuści przenoszą finalny etap przekazania środków do świata fizycznego.

W skrócie

Przestępcy podszywają się pod doradców inwestycyjnych lub operatorów platform kryptowalutowych.
Ofiara widzi na fałszywej platformie pozorne zyski i rosnące saldo konta.
W przypadku problemów z przelewem oszuści żądają wypłaty gotówki i przekazania jej kurierowi.
Taki model utrudnia wykrycie rzeczywistego beneficjenta środków i osłabia skuteczność klasycznych mechanizmów antyfraudowych.
Po przekazaniu pieniędzy ofiara jest często nakłaniana do kolejnych wpłat pod pretekstem podatków, opłat lub odblokowania środków.

Kontekst / historia

Oszustwa inwestycyjne związane z kryptowalutami od lat należą do najbardziej dochodowych form cyberprzestępczości finansowej. Wcześniejsze modele opierały się głównie na przelewach bankowych, zakupie aktywów cyfrowych lub przekazywaniu środków na portfele kontrolowane przez grupy przestępcze.

Wraz ze wzrostem skuteczności systemów AML, monitoringu transakcyjnego i procedur antyfraudowych w sektorze finansowym przestępcy zaczęli dostosowywać swoje taktyki. Włączenie kuriera do łańcucha oszustwa pozwala ograniczyć widoczność przepływu środków, utrudnia analizę ścieżki finansowej i zmniejsza skuteczność standardowych blokad realizowanych przez banki.

To pokazuje, że współczesne oszustwa coraz częściej przyjmują formę hybrydową, łącząc manipulację online z działaniami fizycznymi wykonywanymi w świecie rzeczywistym.

Analiza techniczna

Atak zazwyczaj zaczyna się od kontaktu przez media społecznościowe, komunikator, wiadomość SMS albo fałszywą personę eksperta inwestycyjnego. Celem pierwszego etapu jest zdobycie zaufania ofiary oraz zbudowanie wrażenia profesjonalizmu i wiarygodności.

Następnie ofiara trafia na spreparowaną platformę inwestycyjną lub do aplikacji, która symuluje legalne operacje finansowe. Interfejs może prezentować historię transakcji, wykresy, zyski oraz saldo konta, choć w rzeczywistości dane te są całkowicie fikcyjne. W tym modelu nie zawsze potrzebne jest zaawansowane złośliwe oprogramowanie — kluczową rolę odgrywa przekonująca imitacja prawdziwego środowiska inwestycyjnego oraz skuteczna inżynieria społeczna.

Gdy ofiara napotyka przeszkody przy realizacji przelewu, oszuści zmieniają taktykę i informują, że dalsza inwestycja albo odblokowanie środków wymaga przekazania gotówki kurierowi. Dla zwiększenia wiarygodności mogą stosować dodatkowe elementy uwierzytelnienia, takie jak ustalone hasło, numer seryjny banknotu lub szczegóły rzekomej procedury odbioru.

Po odebraniu gotówki przez kuriera fałszywy system aktualizuje saldo konta ofiary, tworząc pozorne potwierdzenie zaksięgowania środków. To etap krytyczny z perspektywy psychologicznej, ponieważ wzmacnia przekonanie, że cała operacja była legalna i skuteczna. W kolejnych krokach ofiara może zostać poproszona o następne płatności, przedstawiane jako podatki, opłaty administracyjne, prowizje lub koszty wypłaty środków.

Z technicznego punktu widzenia jest to połączenie oszustwa inwestycyjnego, impersonacji, obejścia kontroli bankowych i wieloetapowej socjotechniki. Choć przekazanie środków następuje fizycznie, cały łańcuch ataku pozostaje silnie zakorzeniony w infrastrukturze cyfrowej.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem są straty finansowe, które mogą sięgać bardzo wysokich kwot. Problem nie ogranicza się jednak wyłącznie do utraty pieniędzy. Ofiary często przekazują również dane osobowe, informacje bankowe, adres zamieszkania oraz szczegóły dotyczące swojej sytuacji majątkowej.

Taki zestaw informacji może zostać wykorzystany w kolejnych kampaniach oszustw, przy próbach kradzieży tożsamości lub w bardziej ukierunkowanych atakach socjotechnicznych. Dodatkowo udział kuriera podnosi poziom zagrożenia fizycznego, ponieważ ofiara wchodzi w bezpośredni kontakt z elementem operacyjnej infrastruktury przestępczej.

Z perspektywy instytucji finansowych zagrożenie pokazuje ograniczenia tradycyjnego monitoringu transakcyjnego. Jeśli końcowy transfer środków odbywa się poza systemem elektronicznym, klasyczne narzędzia detekcji mogą nie wystarczyć do skutecznego zatrzymania incydentu.

Pośrednio ryzyko dotyczy również organizacji i pracowników. Osoba oszukana prywatnie może stać się bardziej podatna na dalsze manipulacje, co zwiększa ekspozycję na spear phishing, BEC i inne ataki wykorzystujące zaufanie oraz presję psychologiczną.

Rekomendacje

Podstawową zasadą bezpieczeństwa jest traktowanie każdej nieoczekiwanej propozycji inwestycyjnej jako potencjalnego oszustwa do czasu jej niezależnej weryfikacji. Nie należy zakładać, że widoczne na platformie saldo lub historia zysków mają jakiekolwiek odzwierciedlenie w rzeczywistości.

Szczególną ostrożność trzeba zachować w sytuacji, gdy inwestycja wymaga wypłaty gotówki i przekazania jej nieznanej osobie. Wiarygodna instytucja finansowa nie powinna uzależniać inwestycji ani wypłaty środków od odbioru gotówki przez kuriera.

Weryfikuj tożsamość rozmówców innym, niezależnym kanałem komunikacji.
Sprawdzaj reputację platform inwestycyjnych przed przekazaniem środków.
Nie udostępniaj danych bankowych, dokumentów ani adresu osobom poznanym wyłącznie online.
Ignoruj niezamówione wiadomości, linki i obietnice szybkiego zysku.
Natychmiast zgłaszaj podejrzane zdarzenia do banku i odpowiednich służb.
W organizacjach uwzględniaj w szkoleniach scenariusze łączące socjotechnikę online z fizycznym odbiorem pieniędzy.

Dla sektora finansowego i zespołów bezpieczeństwa ważne jest także monitorowanie wskaźników behawioralnych, takich jak nagłe wysokie wypłaty gotówkowe, nietypowe wyjaśnienia klienta czy odwołania do inwestycji kryptowalutowych i opłat za odblokowanie środków. Takie sygnały mogą pomóc we wcześniejszym wykryciu nadużycia.

Podsumowanie

Ostrzeżenie FBI potwierdza, że oszustwa kryptowalutowe stale ewoluują i coraz częściej wykorzystują modele hybrydowe, które łączą manipulację cyfrową z działaniami fizycznymi. Włączenie kurierów do procesu odbioru gotówki ma jeden podstawowy cel: ominąć kontrole bankowe i wydłużyć cykl eksploatacji ofiary.

Dla użytkowników oznacza to potrzebę większej ostrożności wobec wszystkich ofert inwestycyjnych obiecujących szybkie zyski. Dla branży cyberbezpieczeństwa i sektora finansowego jest to sygnał, że przeciwdziałanie fraudom musi obejmować nie tylko analizę transakcji online, lecz także szerszy kontekst zachowań i operacji realizowanych poza systemami cyfrowymi.

Źródła

https://www.infosecurity-magazine.com/news/fbi-warns-courier-cash-pickups/
https://www.helpnetsecurity.com/2026/06/16/crypto-scammers-couriers-cash-pickups-fbi-warning/
https://www.fbi.gov/investigate/cyber/alerts

Athena: branżowa koalicja ma zabezpieczać open source przed podatnościami wykrywanymi przez AI

Wprowadzenie do problemu / definicja

Bezpieczeństwo oprogramowania open source wchodzi w nowy etap wraz z rozwojem narzędzi opartych na sztucznej inteligencji. Modele AI potrafią analizować duże bazy kodu szybciej niż tradycyjne zespoły bezpieczeństwa, co skraca czas między wykryciem błędu a jego potencjalnym wykorzystaniem. W odpowiedzi na tę zmianę Chainguard oraz grupa partnerów technologicznych i finansowych uruchomiły inicjatywę Athena.

Celem projektu jest wcześniejsze wykrywanie, korelowanie i usuwanie podatności w komponentach open source, zanim informacje o nich staną się publiczne i zanim zostaną wykorzystane przez atakujących. To podejście ma ograniczyć ryzyko wynikające z przyspieszenia procesu odkrywania luk przez systemy AI.

W skrócie

Athena to koalicja branżowa skoncentrowana na ochronie ekosystemu open source przed podatnościami, które mogą być coraz szybciej identyfikowane i uzbrajane dzięki AI. Inicjatywa skupia ponad dwa tuziny organizacji reprezentujących obszary infrastruktury, chmury, finansów i cyberbezpieczeństwa.

projekt ma wspierać wykrywanie i remediację podatności przed publicznym ujawnieniem,
platforma przetworzyła już ponad 20 tysięcy zgłoszeń,
wygenerowano ponad 2 tysiące poprawek,
działania objęły około 500 projektów open source.

Najważniejszym założeniem jest dostarczenie poprawek i mechanizmów ochronnych jeszcze w okresie embarga, zanim podatność trafi do szerokiej wiadomości.

Kontekst / historia

Przez lata model odpowiedzialnego ujawniania podatności opierał się na założeniu, że wykrycie złożonego błędu wymaga czasu, a okno pomiędzy odkryciem a eksploatacją daje szansę na przygotowanie aktualizacji. W praktyce coraz częściej okazuje się, że to założenie przestaje być wystarczające.

Narzędzia AI mogą analizować zależności, rozpoznawać wzorce błędów i wskazywać potencjalne ścieżki ataku znacznie szybciej niż klasyczne procesy badawcze. W świecie open source ma to szczególne znaczenie, ponieważ pojedyncza biblioteka bywa wykorzystywana przez tysiące aplikacji, usług chmurowych i środowisk krytycznych. To zwiększa skalę skutków jednej podatności i wymusza bardziej skoordynowane działania obronne.

Analiza techniczna

Architektura Athena opiera się na kilku warstwach operacyjnych, które mają przyspieszyć zarówno analizę zgłoszeń, jak i wdrażanie działań ochronnych. Pierwszą warstwą jest agregacja i korelacja informacji o podatnościach. Uczestnicy koalicji przekazują zweryfikowane ustalenia, w tym wyniki badań wspomaganych przez AI, a platforma usuwa duplikaty i ustala priorytety.

Drugim elementem jest remediacja przedembargowa. Zamiast czekać na publiczne ujawnienie, uczestnicy przygotowują prywatne poprawki, utwardzone warianty bibliotek lub przebudowane artefakty. Istotne jest też podejście klasowe, czyli eliminowanie całych kategorii błędów, a nie tylko pojedynczego przypadku.

Trzecia warstwa obejmuje ciągłą rekoncyliację z upstreamem. Oznacza to monitorowanie zmian w głównych repozytoriach projektów open source w trakcie embarga, aby utrzymywać poprawki w aktualnym stanie i wykrywać sytuacje, w których maintainerzy niezależnie natrafili na ten sam problem.

Czwarta warstwa to mitigacje niezależne od samego patcha. Partnerzy mogą wdrażać sygnatury detekcyjne, mechanizmy blokowania, virtual patching oraz dodatkowe zabezpieczenia ruchu i aplikacji. Jest to szczególnie ważne w środowiskach, gdzie szybkie wdrożenie aktualizacji nie zawsze jest możliwe.

Ostatni filar stanowi skoordynowane disclosure upstream. Docelowo poprawki mają trafiać do oryginalnych projektów open source, tak aby ograniczyć fragmentację ekosystemu i uniknąć długotrwałego utrzymywania prywatnych forków.

Konsekwencje / ryzyko

Z perspektywy obrońców Athena odpowiada na realny problem asymetrii między tempem wykrywania błędów a tempem ich usuwania. Jeśli model się sprawdzi, organizacje korzystające z popularnych komponentów open source mogą szybciej uzyskiwać ochronę przed podatnościami o wysokim wpływie.

Jednocześnie taka centralizacja informacji o nieujawnionych podatnościach rodzi istotne pytania dotyczące zaufania, segmentacji dostępu i governance. Sama platforma koordynująca staje się zasobem o bardzo wysokiej wartości, a więc potencjalnym celem dla przeciwników.

Ryzykiem pozostaje również nierównomierny dostęp do ochrony. Jeśli wcześniejsze poprawki, utwardzone pakiety lub dodatkowe mechanizmy obronne są dostępne przede wszystkim dla członków koalicji, część społeczności open source może uznać taki model za zbyt zamknięty. Pojawiają się też obawy o przejrzystość procesu bezpieczeństwa, jeśli kluczowe działania odbywają się poza publicznymi repozytoriami aż do momentu ujawnienia problemu.

Dla sektorów krytycznych, takich jak ochrona zdrowia, infrastruktura komunalna czy organizacje z ograniczonym personelem bezpieczeństwa, warstwowe mitigacje mogą jednak okazać się bardzo cenne. W takich środowiskach dodatkowa ochrona na poziomie sieci, platformy lub telemetryki może realnie zmniejszyć ekspozycję na ataki.

Rekomendacje

Firmy korzystające z open source powinny potraktować rozwój podobnych inicjatyw jako sygnał, że klasyczne zarządzanie podatnościami nie wystarcza już samodzielnie. Konieczne staje się połączenie szybkiego patchowania z dodatkowymi warstwami ochrony i lepszą widocznością łańcucha dostaw oprogramowania.

budować pełny inwentarz zależności i utrzymywać aktualny SBOM,
skracać czas wdrażania poprawek w procesach CI/CD,
przygotować awaryjne procedury aktualizacji dla krytycznych bibliotek,
wdrażać WAF, reguły detekcyjne, virtual patching i monitoring ruchu,
rozwijać praktyki secure supply chain, w tym weryfikację pochodzenia artefaktów i podpisywanie pakietów,
ocenić udział w inicjatywach wymiany informacji o podatnościach i zagrożeniach.

W praktyce największą odporność zyskają te organizacje, które połączą monitoring zależności, automatyzację remediacji i zdolność do szybkiego wdrażania środków tymczasowych jeszcze przed pełną aktualizacją.

Podsumowanie

Athena to próba dostosowania ochrony open source do realiów ery AI, w której wykrywanie podatności może przebiegać szybciej niż klasyczne procesy ich obsługi. Zamiast skupiać się wyłącznie na tradycyjnym modelu disclosure, inicjatywa promuje skoordynowaną i wielowarstwową ochronę jeszcze przed publicznym ujawnieniem problemu.

Jeśli ten model się upowszechni, może stać się ważnym wzorcem dla nowoczesnego zarządzania podatnościami w łańcuchu dostaw oprogramowania. Ostateczny sukces będzie jednak zależeć od jakości governance, relacji z maintainerami upstream oraz zachowania równowagi między skuteczną obroną a przejrzystością wobec społeczności open source.

Źródła

https://www.prnewswire.com/news-releases/chainguard-launches-athena-the-industry-coalition-to-fix-open-source-vulnerabilities-before-attackers-can-find-them-302799984.html
https://www.securityweek.com/tech-coalition-athena-targets-oss-vulnerabilities-ahead-of-disclosure/

Phantom Stealer: bezplikowy infostealer kradnący dane z przeglądarek

Wprowadzenie do problemu / definicja

Phantom Stealer to złośliwe oprogramowanie typu infostealer, którego głównym celem jest wykradanie poświadczeń, cookies sesyjnych oraz innych wrażliwych danych przechowywanych w przeglądarkach internetowych. Zagrożenie zwraca uwagę przede wszystkim ze względu na bezplikowy charakter działania, który ogranicza liczbę śladów pozostawianych na dysku i utrudnia wykrycie przez tradycyjne rozwiązania bezpieczeństwa oparte na sygnaturach.

W praktyce oznacza to, że atakujący koncentrują się na przejęciu tego, co dziś ma największą wartość operacyjną: tożsamości użytkownika, aktywnych sesji oraz dostępu do usług biznesowych obsługiwanych z poziomu przeglądarki.

W skrócie

Phantom Stealer jest rozprzestrzeniany głównie w kampaniach phishingowych, w których wykorzystywane są spreparowane załączniki podszywające się pod dokumenty biznesowe. Po uruchomieniu łańcucha infekcji malware działa przede wszystkim w pamięci operacyjnej, a następnie przechwytuje dane zapisane w przeglądarkach oraz informacje mogące ułatwić dalszą kompromitację środowiska.

kradnie zapisane hasła i dane autouzupełniania,
przechwytuje cookies sesyjne,
zbiera informacje finansowe i dane z narzędzi SaaS,
może odczytywać schowek, wykonywać zrzuty ekranu i rejestrować naciśnięcia klawiszy,
wykorzystuje model malware-as-a-service, który ułatwia szeroką dystrybucję.

Kontekst / historia

Infostealery od lat należą do najaktywniejszych narzędzi używanych przez cyberprzestępców. Wraz z rosnącym znaczeniem aplikacji chmurowych, bankowości internetowej i platform SaaS, przeglądarka stała się jednym z najważniejszych punktów dostępu do danych i procesów biznesowych. To właśnie w niej przechowywane są hasła, tokeny, dane formularzy oraz sesje pozwalające na szybki dostęp do krytycznych systemów.

Phantom Stealer wpisuje się w ten trend, ale wyróżnia się wieloetapowym łańcuchem infekcji oraz zastosowaniem technik utrudniających analizę. Istotne znaczenie ma również komercjalizacja tego typu narzędzi. Model MaaS sprawia, że z jednego rozwiązania może korzystać wielu operatorów, a rozwój funkcji i mechanizmów omijania detekcji przebiega szybciej niż w klasycznych, jednorazowych kampaniach.

Analiza techniczna

Atak zwykle rozpoczyna się od wiadomości phishingowej zawierającej załącznik udający legalny dokument, na przykład zapytanie ofertowe lub korespondencję handlową. Po otwarciu pliku uruchamiany jest zaciemniony skrypt wsadowy, który inicjuje kolejne etapy infekcji i przygotowuje środowisko do uruchomienia ładunku w pamięci.

W analizowanych kampaniach operatorzy wykorzystują kilka warstw ukrywania logiki działania. Celem jest zarówno utrudnienie analizy statycznej, jak i ograniczenie skuteczności podstawowych mechanizmów ochronnych. Szczególnie istotne jest to, że duża część złośliwej aktywności skupia się wokół droppera, a nie wyłącznie samego końcowego malware.

silnie zaciemnione polecenia PowerShell,
ukryte znaki Unicode,
ciągi zakodowane w Base64,
maskowanie wywołań API,
wielowarstwowe dekodowanie i uruchamianie kodu bez zapisu na dysku.

Po skutecznym uruchomieniu Phantom Stealer może zostać wstrzyknięty do legalnego procesu systemowego, co dodatkowo utrudnia detekcję. Tego typu działanie pozwala złośliwemu kodowi ukrywać się w kontekście zaufanych procesów i zmniejsza szansę na szybkie wykrycie incydentu przez użytkownika lub podstawowe systemy ochronne.

Po infekcji malware uzyskuje dostęp do szerokiego zestawu danych przechowywanych lokalnie lub używanych przez użytkownika w codziennej pracy.

zapisane poświadczenia w popularnych przeglądarkach,
cookies sesyjne,
dane autouzupełniania,
informacje z menedżerów haseł,
dane związane z bankowością online i aplikacjami SaaS,
zawartość schowka,
obraz pulpitu użytkownika.

Ważnym elementem kampanii jest także redundancja w eksfiltracji danych. Zamiast jednego kanału komunikacyjnego operatorzy mogą używać kilku równoległych metod przesyłania skradzionych informacji. Taki model zwiększa odporność operacji na blokowanie infrastruktury oraz utrudnia pełne odtworzenie przebiegu incydentu.

Konsekwencje / ryzyko

Skutki działania Phantom Stealer nie ograniczają się do pojedynczej kradzieży hasła. W środowisku firmowym przejęcie przeglądarki może oznaczać dostęp do skrzynek pocztowych, paneli administracyjnych, systemów finansowych, platform CRM, aplikacji chmurowych i narzędzi do zdalnego zarządzania. Szczególnie groźna jest kradzież cookies sesyjnych, ponieważ może umożliwić przejęcie aktywnej sesji bez konieczności ponownego uwierzytelniania.

Dla organizacji o wysokiej wartości biznesowej, zwłaszcza z sektora finansowego, oznacza to ryzyko dalszej eskalacji incydentu i wykorzystania skradzionych danych przez inne grupy przestępcze.

oszustwa finansowe i nieautoryzowane transakcje,
przejęcie kont uprzywilejowanych,
wtórne włamania do środowiska wewnętrznego,
eskalacja incydentu do ransomware lub BEC,
wyciek danych klientów i danych operacyjnych,
naruszenia regulacyjne oraz straty reputacyjne.

Rekomendacje

Organizacje powinny traktować przeglądarkę jako krytyczny punkt końcowy, a nie jedynie narzędzie użytkownika. W przypadku zagrożeń bezplikowych kluczowe znaczenie ma analiza zachowań, monitoring procesów oraz kontrola dostępu do tożsamości i sesji.

wdrożenie EDR lub XDR z analizą behawioralną procesów potomnych, PowerShell i prób iniekcji do legalnych procesów,
ograniczenie uruchamiania skryptów wsadowych, PowerShell i interpreterów poza uzasadnionym kontekstem administracyjnym,
monitorowanie nietypowych linii poleceń, dekodowania Base64 oraz prób uruchamiania kodu bez zapisu na dysku,
wzmocnienie ochrony poczty elektronicznej i sandboxingu załączników,
ograniczenie przechowywania haseł i tokenów w przeglądarkach,
stosowanie odpornych na phishing metod MFA,
regularne unieważnianie sesji po podejrzeniu kompromitacji,
segmentacja dostępu do systemów finansowych i administracyjnych,
szkolenie użytkowników w zakresie rozpoznawania phishingu podszywającego się pod korespondencję handlową,
aktualizowanie reguł detekcji na podstawie wskaźników kompromitacji i telemetryki od dostawców bezpieczeństwa.

W razie wykrycia infekcji nie należy ograniczać reakcji wyłącznie do resetu haseł. Konieczne jest również unieważnienie aktywnych sesji, analiza historii logowań, ocena ryzyka przejęcia tokenów oraz sprawdzenie, czy skradzione dane nie zostały wykorzystane do dalszego ruchu bocznego w środowisku.

Podsumowanie

Phantom Stealer pokazuje, że nowoczesne kampanie infostealerów coraz częściej łączą phishing ukierunkowany, techniki bezplikowe, wielowarstwowe zaciemnianie oraz elastyczną eksfiltrację danych. Atak na przeglądarkę stał się dziś w praktyce atakiem na tożsamość użytkownika i jego dostęp do kluczowych usług biznesowych.

Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia ciężaru obrony z klasycznego wykrywania plików na ochronę tożsamości, monitoring sesji oraz analizę zachowań procesów i skryptów uruchamianych w systemie.

Źródła

HTTP/2 Bomb: nowa technika DoS zagraża operatorom telekomunikacyjnym, IT i ochronie zdrowia

Wprowadzenie do problemu / definicja

HTTP/2 Bomb to nowo ujawniona technika odmowy usługi, oznaczona jako CVE-2026-49975, która wykorzystuje legalne mechanizmy protokołu HTTP/2 do gwałtownego wyczerpywania pamięci serwera. Nie jest to klasyczny atak oparty na ogromnym wolumenie ruchu, lecz metoda prowadząca do nieproporcjonalnie wysokiego zużycia zasobów po stronie usługi. W efekcie nawet relatywnie niewielkie możliwości techniczne napastnika mogą wystarczyć do zakłócenia działania podatnych systemów.

W skrócie

Nowa technika uderza w implementacje popularnych serwerów WWW i proxy obsługujących HTTP/2. Mechanizm łączy nadużycie kompresji nagłówków HPACK z manipulacją kontrolą przepływu, co umożliwia utrzymywanie rosnącego zużycia pamięci przy niewielkim ruchu wejściowym. Szczególnie zagrożone są organizacje posiadające rozbudowaną infrastrukturę internetową, w tym operatorzy telekomunikacyjni, firmy technologiczne oraz placówki ochrony zdrowia.

atak nie wymaga dużej przepustowości po stronie napastnika,
celem jest pamięć operacyjna i stabilność procesów serwerowych,
ryzyko dotyczy szeroko stosowanej infrastruktury webowej,
dostępne są poprawki i działania ograniczające skutki ataku.

Kontekst / historia

HTTP/2 powstał jako nowocześniejsza i wydajniejsza alternatywa dla HTTP/1.1. Wprowadził multipleksowanie strumieni, kompresję nagłówków HPACK oraz mechanizmy kontroli przepływu, które miały ograniczać narzut transmisji i poprawiać wydajność komunikacji w środowiskach o dużej skali.

W czerwcu 2026 roku badacze opisali jednak scenariusz, w którym dwa zgodne ze specyfikacją elementy protokołu mogą zostać połączone w skuteczny wektor DoS. Problem ma znaczenie praktyczne, ponieważ dotyczy komponentów infrastrukturalnych powszechnie wykorzystywanych na styku internetu i usług biznesowych. Mowa o warstwie, która często działa od lat bez głębszego przeglądu architektury bezpieczeństwa, mimo że odpowiada za krytyczne funkcje publikacji aplikacji i API.

Dodatkowy ciężar ryzyka wynika z dużej popularności HTTP/2 w organizacjach obsługujących rozproszony ruch i wysokie obciążenia. W takich środowiskach nawet krótkotrwała niedostępność może prowadzić do zakłóceń operacyjnych, problemów z ciągłością działania i naruszeń poziomów usług.

Analiza techniczna

Istota HTTP/2 Bomb polega na uzyskaniu silnej amplifikacji zużycia pamięci po stronie serwera. Atakujący wysyła niewielkie żądania, które wymuszają budowę znacznie większych struktur związanych z przetwarzaniem nagłówków. Kluczową rolę odgrywa tutaj HPACK, czyli mechanizm kompresji nagłówków w HTTP/2, wykorzystujący tablice dynamiczne i indeksowanie zamiast ciągłego przesyłania pełnych danych tekstowych.

W scenariuszu nadużycia niewielki ruch wejściowy może powodować kosztowne operacje po stronie odbiorcy. Następnie kontrola przepływu HTTP/2 jest wykorzystywana do ograniczenia możliwości szybkiego odesłania odpowiedzi i zwolnienia zaalokowanych zasobów. W praktyce prowadzi to do sytuacji, w której pamięć pozostaje zajęta przez dłuższy czas, a kolejne żądania zwiększają presję na proces i RAM.

To odróżnia HTTP/2 Bomb od wielu tradycyjnych ataków DDoS nastawionych głównie na przepustowość łącza. Tutaj nie trzeba generować masowego ruchu, by osiągnąć efekt niedostępności. Celem staje się destabilizacja procesu odpowiedzialnego za obsługę HTTP/2 lub doprowadzenie do wyczerpania pamięci, co może skutkować błędami, restartami usług albo całkowitym przerwaniem obsługi klientów.

Ważne jest również to, że problem nie wynika z błędu logiki biznesowej aplikacji ani obejścia uwierzytelniania. Podatność znajduje się niżej, w warstwie implementacyjnej i protokolarnej. Oznacza to, że nawet poprawnie napisane aplikacje webowe mogą być zagrożone, jeśli korzystają z niezałatanych komponentów frontowych, reverse proxy lub bram API.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją HTTP/2 Bomb jest utrata dostępności usług internetowych. W sektorach takich jak telekomunikacja czy IT może to przełożyć się na niedostępność portali klientowskich, interfejsów API, paneli administracyjnych, systemów zaplecza i usług o dużej skali. W ochronie zdrowia wpływ jest szczególnie wrażliwy, jeśli zakłócenia dotkną systemów rejestracji, portali pacjenta lub usług wspierających komunikację medyczną.

Ryzyko zwiększają trzy kluczowe czynniki: popularność podatnych komponentów, niski koszt przeprowadzenia ataku po stronie przeciwnika oraz brak centralnego zarządzania konfiguracją HTTP/2 w wielu organizacjach. W praktyce protokół ten bywa traktowany jako przezroczysta funkcja platformy, a nie jako krytyczna powierzchnia ataku wymagająca aktywnego nadzoru.

chwilowa lub długotrwała niedostępność usług,
wzrost wykorzystania pamięci i niestabilność procesów serwerowych,
przeciążenie warstw proxy i load balancerów,
problemy z ciągłością działania i naruszenie SLA,
wyższe koszty operacyjne związane z reagowaniem i analizą incydentu.

Dla zespołów bezpieczeństwa istotne jest również to, że klasyczne zabezpieczenia wolumetryczne lub proste limity zapytań mogą nie wystarczyć. Bez uwzględnienia specyfiki HTTP/2 oraz zachowania pamięci podczas przetwarzania nagłówków i blokowania odpowiedzi część środowisk może pozostać podatna mimo wdrożonych mechanizmów ochronnych.

Rekomendacje

Organizacje powinny w pierwszej kolejności zinwentaryzować wszystkie komponenty obsługujące HTTP/2 zarówno na brzegu infrastruktury, jak i wewnątrz środowiska. Obejmuje to główne serwery WWW, reverse proxy, gatewaye API, elementy service mesh, urządzenia bezpieczeństwa oraz platformy CDN.

niezwłocznie wdrożyć poprawki dostawców dla podatnych implementacji,
zweryfikować, gdzie HTTP/2 jest aktywne i czy jest rzeczywiście potrzebne,
rozważyć czasowe ograniczenie lub wyłączenie HTTP/2 dla usług o najwyższym ryzyku,
dostroić limity dotyczące nagłówków, liczby strumieni i zachowania połączeń,
monitorować nietypowy wzrost zużycia pamięci przez procesy obsługujące HTTP/2,
wdrożyć detekcję anomalii dla długotrwałych połączeń i nietypowych wzorców ramek,
przetestować odporność usług w kontrolowanym środowisku przedprodukcyjnym,
skoordynować działania między zespołami SOC, DevOps, SRE i administratorami sieci.

W środowiskach krytycznych warto przygotować plan awaryjny obejmujący szybkie przełączenie ruchu, zmianę profilu terminacji TLS/HTTP, eskalację do dostawców oraz gotowe playbooki reagowania na incydenty DoS warstwy aplikacyjnej. Dobrą praktyką jest również przegląd telemetrii pod kątem połączeń HTTP/2 utrzymujących niski transfer przy jednoczesnym rosnącym zużyciu pamięci.

Podsumowanie

HTTP/2 Bomb pokazuje, że funkcje projektowane z myślą o wydajności mogą stać się skutecznym wektorem ataku, jeśli zostaną połączone w nieoczekiwany sposób. Zagrożenie jest istotne, ponieważ dotyczy szeroko stosowanej infrastruktury webowej i pozwala osiągnąć znaczący efekt odmowy usługi przy niskim koszcie po stronie napastnika.

Dla organizacji z sektorów telekomunikacyjnego, IT i ochrony zdrowia priorytetem powinno być szybkie wdrożenie poprawek, przegląd ekspozycji usług HTTP/2 oraz wzmocnienie monitoringu dostępności i zużycia zasobów. To kolejny sygnał, że bezpieczeństwo warstwy protokołów pozostaje równie ważne jak ochrona samej aplikacji.

Źródła

Dark Reading — HTTP/2 Bomb Attacks Put Telcos, Healthcare Orgs at Risk — https://www.darkreading.com/vulnerabilities-threats/http-2-bomb-attacks-telcos-healthcare
Imperva Blog — Imperva Protects Against CVE-2026-49975 HTTP/2 Bomb — https://www.imperva.com/blog/imperva-customers-protected-against-cve-2026-49975-http-2-bomb-dos/
RFC 9113 — HTTP/2 — https://www.ietf.org/rfc/rfc9113.pdf
RFC 7541 — HPACK: Header Compression for HTTP/2 — https://www.ietf.org/ietf-ftp/rfc/rfc7541.txt.pdf
Radware Cybersecurity Alert — HTTP/2 Bomb June 2026 — https://www.radware.com/getattachment/38a70d60-bd2d-45ba-a44d-b7f12ca5d4d3/Threat-Alert-HTTP2-Bomb-June2026.pdf.aspx

SearchLeak w Microsoft 365 Copilot: luka 1-click umożliwiała cichą eksfiltrację danych

Wprowadzenie do problemu / definicja

SearchLeak to scenariusz ataku ujawniony w kontekście Microsoft 365 Copilot Search, w którym pojedyncze kliknięcie spreparowanego odnośnika mogło doprowadzić do niejawnego ujawnienia danych dostępnych dla ofiary. Problem wpisuje się w rosnącą kategorię zagrożeń związanych z pośrednim prompt injection w systemach AI zintegrowanych z zasobami przedsiębiorstwa.

W tego typu środowisku model językowy nie działa wyłącznie na treści wpisanej przez użytkownika, ale może także przeszukiwać i przetwarzać dane organizacyjne. To sprawia, że błędy na styku interfejsu, logiki promptów, warstwy renderowania i systemów uprawnień mogą prowadzić do realnej eksfiltracji informacji.

W skrócie

Badacze opisali podatność nazwaną SearchLeak, która pozwalała na wykradanie danych z Microsoft 365 Copilot po otwarciu specjalnie przygotowanego linku. Atak wykorzystywał parametr zapytania w adresie Copilot Search do dostarczenia złośliwej instrukcji interpretowanej przez system jako polecenie operacyjne.

Potencjalnym celem mogły być wiadomości e-mail, notatki ze spotkań, pliki OneDrive, dokumenty SharePoint oraz inne informacje biznesowe, do których użytkownik miał legalny dostęp. Luka została załatana przez Microsoft i oznaczona jako CVE-2026-42824.

Kontekst / historia

SearchLeak nie jest klasyczną podatnością pamięciową ani prostym błędem po stronie przeglądarki. To przykład luki wynikającej z połączenia kilku warstw działania nowoczesnej platformy AI: wejściowych parametrów linku, przetwarzania promptów, dostępu do danych organizacyjnych oraz sposobu prezentowania odpowiedzi.

Opisany wektor ataku należy do mniej znanego podzbioru indirect prompt injection, określanego jako parameter-to-prompt injection. Oznacza to, że złośliwa instrukcja nie musi znajdować się w dokumencie ani być wpisana ręcznie przez użytkownika. Wystarczy, że zostanie przemycona w parametrze adresu URL, który następnie zostanie potraktowany przez asystenta AI jako właściwe zapytanie.

Analiza techniczna

Mechanizm ataku składał się z kilku etapów. Najpierw napastnik przygotowywał odnośnik prowadzący do Microsoft 365 Copilot Search z odpowiednio spreparowanym parametrem q. Taki link mógł zostać dostarczony ofierze przez e-mail, komunikator firmowy lub inny kanał komunikacji.

Po kliknięciu Copilot interpretował zawartość parametru jako zapytanie i wykonywał instrukcje odnoszące się do danych dostępnych z kontekstu użytkownika. Złośliwy prompt mógł nakazać wyszukanie konkretnej wiadomości, wydobycie fragmentu treści, tytułu, kodu MFA, linku resetowania hasła albo innych poufnych danych, a następnie przygotowanie ich do przekazania dalej.

Kluczowym elementem obejścia zabezpieczeń było wykorzystanie osadzonego znacznika obrazu w konstrukcji związanej z funkcją wyszukiwania obrazem. Według opisu badaczy umożliwiało to wykorzystanie warunków wyścigu oraz faktu, że część operacji była wykonywana po stronie infrastruktury usług wyszukiwania, a nie bezpośrednio w przeglądarce użytkownika.

To ważny detal architektoniczny. Jeżeli system AI jednocześnie przyjmuje dane wejściowe z zewnątrz, odczytuje dane wewnętrzne, przetwarza je według instrukcji modelu i renderuje wynik zawierający aktywne elementy, granice zaufania zaczynają się zacierać. SearchLeak pokazał, że same mechanizmy ochronne nie zawsze wystarczają, jeśli można je ominąć przez nieoczywiste połączenie legalnych funkcji platformy.

Konsekwencje / ryzyko

Ryzyko związane z SearchLeak było szczególnie poważne dla organizacji intensywnie korzystających z Microsoft 365 Copilot i przechowujących w tym ekosystemie dużą ilość informacji poufnych. Potencjalny zakres wycieku mógł obejmować szeroki katalog danych biznesowych.

korespondencję e-mail,
notatki i ustalenia ze spotkań,
dokumenty SharePoint,
pliki OneDrive,
inne dane indeksowane i dostępne z poziomu Copilot.

Najgroźniejszy aspekt polegał na niskim progu interakcji. Użytkownik nie musiał pobierać pliku, uruchamiać makra ani wykonywać szeregu podejrzanych działań. Wystarczyć mogło samo kliknięcie odnośnika otwierającego usługę Copilot z ukrytą instrukcją.

Z perspektywy bezpieczeństwa przedsiębiorstwa jest to sygnał, że asystenci AI z dostępem do danych korporacyjnych stają się pełnoprawnym elementem powierzchni ataku. Wszędzie tam, gdzie model ma możliwość odczytu informacji i generowania odpowiedzi wpływających na dalszy przepływ danych, rośnie ryzyko prompt injection, eksfiltracji oraz obchodzenia granic zaufania.

Rekomendacje

Organizacje powinny traktować platformy AI z podobną ostrożnością jak systemy pocztowe, usługi tożsamościowe i krytyczne aplikacje SaaS. Ochrona nie powinna ograniczać się wyłącznie do aktualizacji producenta.

Ograniczyć nadmiarowe uprawnienia do SharePoint, OneDrive i skrzynek pocztowych, aby zmniejszyć możliwy zakres wycieku.
Przeprowadzić przegląd ekspozycji danych dla Copilot i ustalić, które repozytoria są indeksowane.
Wdrożyć klasyfikację oraz segmentację informacji, szczególnie dla danych wrażliwych i uprzywilejowanych.
Monitorować nietypowe wzorce użycia narzędzi AI, w tym podejrzane zapytania i niestandardowy dostęp do dokumentów.
Analizować linki prowadzące do usług AI w poczcie i komunikatorach, zwłaszcza jeśli zawierają rozbudowane parametry wejściowe.
Zadbać o separację instrukcji od danych, sanityzację wyników i ograniczanie aktywnej treści w odpowiedziach.
Upewnić się, że środowisko korzysta z aktualnych mechanizmów ochronnych oraz śledzić komunikaty producenta.
Szkolić użytkowników, że nawet link do zaufanej usługi wewnętrznej może stanowić nośnik ataku.

Podsumowanie

SearchLeak to istotny przykład nowoczesnej podatności w systemach GenAI dla przedsiębiorstw. Nie opierał się na tradycyjnym exploicie technicznym, lecz na nadużyciu logiki łączącej prompt, dane organizacyjne i mechanizmy renderowania odpowiedzi.

Dla zespołów cyberbezpieczeństwa wniosek jest jasny: rozwiązania AI należy traktować jako krytyczny składnik powierzchni ataku. Skuteczna ochrona wymaga nie tylko filtrowania promptów, ale również kontroli uprawnień, izolacji danych, monitorowania przepływów i twardych zasad bezpieczeństwa architektury.

Źródła

https://www.darkreading.com/application-security/copilot-searchleak-attack-1-click-data-theft
https://www.varonis.com/blog/searchleak
https://msrc.microsoft.com/