Archiwa: AI - Strona 153 z 178

UNC6426 wykorzystuje atak na łańcuch dostaw nx npm do przejęcia uprawnień administratora AWS w 72 godziny

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla organizacji rozwijających aplikacje w modelu chmurowym. Incydent przypisywany grupie UNC6426 pokazuje, że kompromitacja pojedynczego pakietu w ekosystemie npm może stać się początkiem pełnego przejęcia środowiska deweloperskiego, repozytoriów kodu oraz infrastruktury AWS.

W opisywanym scenariuszu punktem wejścia była wcześniejsza kompromitacja pakietu nx. Złośliwy komponent doprowadził do kradzieży poświadczeń dewelopera, a następnie umożliwił atakującym eskalację dostępu przez GitHub i CI/CD aż do roli administratora w chmurze.

W skrócie

Atak rozpoczął się od zainfekowanego pakietu nx w rejestrze npm, który uruchamiał złośliwy kod na stacji roboczej dewelopera. Napastnicy przechwycili token GitHub, przeprowadzili rekonesans w repozytoriach i pipeline’ach, a następnie pozyskali sekrety wykorzystywane w procesach automatyzacji.

Kolejnym etapem było nadużycie federacji GitHub-AWS opartej o OIDC. Dzięki zbyt szerokim uprawnieniom roli powiązanej z CloudFormation atakujący utworzyli nową rolę IAM z polityką AdministratorAccess, uzyskując pełną kontrolę nad środowiskiem AWS w czasie krótszym niż 72 godziny.

wejście przez kompromitację pakietu npm,
kradzież tokena GitHub i sekretów CI/CD,
wykorzystanie OIDC do uzyskania tymczasowych poświadczeń AWS,
eskalacja do pełnych uprawnień administratora,
eksfiltracja danych i działania destrukcyjne w środowisku produkcyjnym.

Kontekst / historia

Tłem incydentu była kompromitacja pakietu nx npm z sierpnia 2025 roku. Ustalenia wskazują, że napastnicy mieli wykorzystać podatny workflow typu pull_request_target, co pozwoliło im uzyskać podwyższone uprawnienia w procesie CI/CD i doprowadzić do publikacji złośliwych wersji pakietu.

Zainfekowane wydania zawierały skrypt postinstall, który po instalacji rozpoczynał zbieranie danych środowiskowych oraz poświadczeń. To istotny przykład tego, jak naruszenie lokalnego narzędzia developerskiego może bardzo szybko przełożyć się na kompromitację systemów budowania, repozytoriów oraz zasobów chmurowych.

Incydent łączy w sobie trzy krytyczne obszary ryzyka: bezpieczeństwo łańcucha dostaw oprogramowania, ochronę tożsamości oraz błędną konfigurację uprawnień w środowisku cloud-native. W praktyce oznacza to, że nawet pozornie ograniczony incydent na endpointcie dewelopera może stać się początkiem pełnoskalowego naruszenia organizacji.

Analiza techniczna

Złośliwy pakiet miał osadzać skrypt postinstall uruchamiający narzędzie do kradzieży poświadczeń określane jako QUIETVAULT. Mechanizm ten zbierał zmienne środowiskowe, informacje o systemie oraz cenne tokeny, w tym GitHub Personal Access Tokens. Dodatkowo wykorzystywał lokalnie dostępne narzędzia oparte na modelach językowych do przeszukiwania systemu pod kątem wrażliwych danych.

W analizowanym przypadku wykonanie złośliwego komponentu miało nastąpić w trakcie korzystania z edytora kodu używającego wtyczki Nx Console. Aktualizacja lub aktywacja komponentu doprowadziła do przejęcia tokena dewelopera, co otworzyło drogę do dalszych działań w środowisku GitHub.

Po uzyskaniu tokena PAT grupa UNC6426 przeprowadziła działania rozpoznawcze i wykorzystała narzędzie open source Nord Stream do wydobycia sekretów z pipeline’ów CI/CD. W ten sposób pozyskano poświadczenia konta serwisowego GitHub, a następnie użyto mechanizmu pobierania tymczasowych tokenów AWS STS dla roli powiązanej z GitHub Actions i CloudFormation.

Kluczową słabością okazały się nadmierne uprawnienia roli federowanej z GitHub. Po przejęciu dostępu do roli Actions-CloudFormation atakujący wdrożyli nowy stos CloudFormation z możliwością tworzenia zasobów IAM. Następnie utworzyli nową rolę i przypisali do niej politykę AdministratorAccess, uzyskując pełne uprawnienia administracyjne w AWS.

Po eskalacji rozpoczęła się faza post-exploitation. Obejmowała ona odczyt i eksfiltrację danych z koszyków S3, działania wymierzone w instancje EC2 i bazy RDS, odszyfrowywanie kluczy aplikacyjnych oraz ingerencję w repozytoria GitHub, które zostały przemianowane i ustawione jako publiczne.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją tego typu ataku jest błyskawiczne przejście od kompromitacji pojedynczego urządzenia deweloperskiego do pełnego naruszenia środowiska chmurowego. Skutki mogą obejmować utratę poufności danych, zniszczenie zasobów produkcyjnych, przejęcie repozytoriów oraz ujawnienie sekretów aplikacyjnych.

Incydent pokazuje również, że skrypty postinstall w pakietach npm nadal stanowią realny problem bezpieczeństwa. W połączeniu z szerokimi tokenami PAT, źle zabezpieczonymi sekretami CI/CD i nadmiarowymi uprawnieniami IAM tworzą one bardzo skuteczną ścieżkę eskalacji.

Rosnące znaczenie ma także ryzyko związane z narzędziami AI używanymi lokalnie przez programistów. Jeżeli takie komponenty mają dostęp do plików, tokenów i aktywnych sesji, ich kompromitacja może zwiększyć zasięg ataku i utrudnić wykrycie nieautoryzowanych działań.

Rekomendacje

Organizacje powinny ograniczać wykonywanie skryptów postinstall wszędzie tam, gdzie jest to możliwe. Jeśli całkowite wyłączenie nie wchodzi w grę, warto wdrożyć sandboxing procesów instalacyjnych, kontrolę integralności zależności oraz monitorowanie anomalii podczas instalacji pakietów.

Niezbędne jest również ścisłe stosowanie zasady najmniejszych uprawnień wobec kont serwisowych, ról federowanych przez OIDC i zasobów CloudFormation. Role używane przez GitHub Actions nie powinny mieć możliwości tworzenia nowych ról IAM ani dołączania polityk administracyjnych bez dodatkowych zabezpieczeń i wyraźnego uzasadnienia biznesowego.

W obszarze zarządzania tożsamością należy stosować krótkotrwałe i precyzyjnie ograniczone tokeny GitHub PAT, regularnie rotować sekrety oraz monitorować ich wykorzystanie. Szczególną uwagę powinny zwracać nietypowe użycia STS, tworzenie nowych ról IAM, dołączanie polityki AdministratorAccess oraz nagłe operacje na S3, EC2 i RDS.

blokowanie lub ograniczanie skryptów postinstall,
ochrona workflow GitHub Actions przed nadużyciem pull_request_target,
segmentacja uprawnień między środowiskiem developerskim i produkcyjnym,
monitorowanie IAM, STS, CloudFormation, S3, EC2 i RDS,
wdrożenie procedur szybkiego unieważniania tokenów i izolacji stacji deweloperskich,
analiza działań narzędzi AI operujących na endpointach programistów.

Podsumowanie

Przypadek UNC6426 stanowi modelowy przykład wieloetapowego ataku łączącego kompromitację łańcucha dostaw npm, kradzież tożsamości deweloperskiej, nadużycie sekretów CI/CD oraz eskalację uprawnień w AWS. Najważniejszy wniosek jest jednoznaczny: pozornie lokalny incydent związany z pakietem developerskim może w bardzo krótkim czasie doprowadzić do przejęcia całej infrastruktury chmurowej.

Dla zespołów bezpieczeństwa oznacza to konieczność jednoczesnej ochrony zależności software’owych, tokenów dostępowych, pipeline’ów automatyzacji i federacji między GitHub a AWS. Bez ograniczania uprawnień oraz ciągłego monitorowania ścieżek zaufania podobne incydenty będą coraz trudniejsze do powstrzymania.

Źródła

The Hacker News — UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours — https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html
Google Cloud — Cloud Threat Horizons Report, H1 2026 — https://cloud.google.com/
Praetorian — pull_request_target workflow security research — https://www.praetorian.com/
Endor Labs — Pwn Request / GitHub Actions workflow abuse analysis — https://www.endorlabs.com/
Socket — Analysis of AI-assisted software supply chain abuse — https://socket.dev/

Badacze oszukali przeglądarkę AI Comet: phishing przeciw agentowi skuteczny w mniej niż 4 minuty

Wprowadzenie do problemu / definicja

Przeglądarki agentowe oparte na sztucznej inteligencji mają wykonywać zadania w imieniu użytkownika: analizować treści, podejmować decyzje, wypełniać formularze i poruszać się między serwisami bez ciągłej ingerencji człowieka. Taki model działania zwiększa jednak powierzchnię ataku, ponieważ celem cyberprzestępców staje się już nie tylko użytkownik, ale również sam agent AI i jego mechanizm decyzyjny.

Najnowsze badania pokazują, że przeglądarka Perplexity Comet może zostać wciągnięta w scenariusz phishingowy w czasie krótszym niż cztery minuty. To istotny sygnał ostrzegawczy dla organizacji testujących lub wdrażających przeglądarki AI do zadań operacyjnych.

W skrócie

Badacze wykazali, że Comet może zostać zmanipulowany tak, aby zaakceptował złośliwą stronę i potraktował ją jako wiarygodną. Atak wykorzystuje zjawisko określane jako „Agentic Blabbering”, czyli nadmierne ujawnianie przez agenta własnych ocen, wahań i logiki działania.

Atakujący obserwuje reakcje agenta na stronę.
Następnie iteracyjnie modyfikuje treść phishingową.
Celem jest usunięcie sygnałów, które wzbudzają podejrzenia modelu.
W efekcie agent może wykonać działania zgodne z intencją oszusta.

Kontekst / historia

Bezpieczeństwo przeglądarek AI stało się w ostatnim czasie jednym z kluczowych tematów w obszarze ochrony systemów generatywnych i agentów wykonujących operacje w internecie. Wcześniejsze badania pokazywały już, że tego typu rozwiązania można nakłonić do niepożądanych działań za pomocą ukrytych instrukcji osadzonych w treści stron lub odpowiednio przygotowanego kontekstu.

Problem nie dotyczy wyłącznie pojedynczego produktu. Eksperci od miesięcy zwracają uwagę, że prompt injection w agentach przeglądarkowych może być wyjątkowo trudne do pełnego wyeliminowania, ponieważ wynika z samej architektury łączącej model językowy z możliwością wykonywania realnych akcji w środowisku webowym.

Analiza techniczna

Sednem opisanego scenariusza jest sprzężenie zwrotne pomiędzy zachowaniem przeglądarki AI a infrastrukturą atakującego. Agent analizuje stronę, ocenia ryzyko i planuje dalsze kroki. Jeżeli przeciwnik jest w stanie odczytać lub pośrednio wywnioskować, które elementy wzbudzają nieufność modelu, może automatycznie przebudowywać witrynę tak długo, aż zabezpieczenia przestaną reagować.

W badaniu wykorzystano zautomatyzowany proces optymalizacji wspierany przez model generatywny. Strona phishingowa była wielokrotnie modyfikowana na podstawie reakcji Comet, aż osiągnięto wariant, który agent uznał za akceptowalny. To oznacza przesunięcie ciężaru ataku z klasycznej socjotechniki wymierzonej w człowieka na manipulację samym mechanizmem decyzyjnym przeglądarki.

Technicznie atak łączy kilka klas ryzyka jednocześnie:

pośrednie prompt injection osadzone w treści strony,
nadużycie logiki planowania i wykonywania akcji przez agenta,
wykorzystanie ujawnianego toku rozumowania jako kanału informacyjnego,
optymalizację złośliwej strony pod konkretne zachowanie produktu i jego guardraile.

Szczególnie groźny jest aspekt skalowalności. Jeżeli przestępca zoptymalizuje złośliwą witrynę pod określony model i przeglądarkę, technika może działać wobec wielu użytkowników korzystających z tego samego rozwiązania.

Konsekwencje / ryzyko

Ryzyko operacyjne jest znaczące, ponieważ przeglądarki AI coraz częściej otrzymują dostęp do sesji użytkownika, poczty, historii przeglądania, tokenów, danych uwierzytelniających i aplikacji biznesowych. W takim modelu skuteczny phishing przeciwko agentowi może prowadzić nie tylko do wyłudzenia loginu i hasła, ale do znacznie szerszego kompromisu.

przejęcie kont użytkownika,
nieautoryzowane zakupy lub płatności,
wyciek danych z aplikacji webowych,
ujawnienie informacji z poczty i dokumentów,
nadużycie aktywnych rozszerzeń, w tym menedżerów haseł,
wykonanie działań wyglądających jak legalna aktywność użytkownika.

Dodatkowym problemem jest detekcja. Wiele obecnych mechanizmów bezpieczeństwa zostało zaprojektowanych z myślą o pomyłkach człowieka, a nie o sytuacji, w której zaufany agent software’owy zostaje oszukany przez odpowiednio przygotowaną stronę. To może utrudniać wykrywanie incydentów i opóźniać reakcję zespołów bezpieczeństwa.

Rekomendacje

Organizacje wdrażające przeglądarki agentowe powinny traktować je jak komponent uprzywilejowany i wysokiego ryzyka. Konieczne jest ograniczanie uprawnień do absolutnego minimum, zwłaszcza w odniesieniu do poczty, menedżerów haseł, sesji uwierzytelnionych, systemów finansowych i danych wrażliwych.

Ważne jest także rozdzielanie środowisk. Przeglądarka AI używana do automatyzacji zadań powinna działać w izolowanym profilu, kontenerze lub wydzielonej stacji roboczej, bez domyślnego dostępu do krytycznych kont i rozszerzeń.

wymaganie jawnej akceptacji człowieka dla działań wysokiego ryzyka,
monitorowanie zachowań agenta jak uprzywilejowanej automatyzacji,
logowanie sekwencji działań i analiza anomalii,
ograniczanie ekspozycji wewnętrznych sygnałów decyzyjnych i toku rozumowania,
uwzględnianie prompt injection i ataków web-agentowych w red teamingu.

Klasyczne testy phishingowe mogą okazać się niewystarczające, jeśli organizacja dopuszcza agentów AI do pracy na rzeczywistych danych i usługach. W takim przypadku potrzebny jest osobny model ryzyka oraz wyspecjalizowane procedury kontrolne.

Podsumowanie

Badanie dotyczące Comet pokazuje, że przeglądarki agentowe otwierają nową kategorię zagrożeń, w której przeciwnik nie musi już przede wszystkim oszukiwać człowieka, lecz samą logikę działania agenta AI. Mechanizm „Agentic Blabbering” oraz iteracyjne dostrajanie strony phishingowej na podstawie reakcji modelu znacząco obniżają koszt przygotowania skutecznego ataku.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że AI browsery nie powinny być traktowane wyłącznie jako wygodne narzędzia produktywności. To uprzywilejowane komponenty wykonawcze z dostępem do tożsamości, danych i procesów biznesowych, które wymagają izolacji, ograniczeń uprawnień i dedykowanych kontroli bezpieczeństwa.

Źródła

The Hacker News — https://thehackernews.com/2026/03/researchers-trick-perplexitys-comet-ai.html
Zenity Labs — PerplexedBrowser: How Attackers Can Hijack Comet to Takeover your 1Password Vault — https://labs.zenity.io/p/perplexedbrowser-how-attackers-can-weaponize-comet-to-takeover-your-1password-vault
TechCrunch — OpenAI says AI browsers may always be vulnerable to prompt injection attacks — https://techcrunch.com/2025/12/22/openai-says-ai-browsers-may-always-be-vulnerable-to-prompt-injection-attacks/
arXiv — WASP: Benchmarking Web Agent Security Against Prompt Injection Attacks — https://arxiv.org/abs/2504.18575
arXiv — ceLLMate: Sandboxing Browser AI Agents — https://arxiv.org/abs/2512.12594

Meta wzmacnia ochronę przed oszustwami w WhatsApp, Facebooku i Messengerze

Wprowadzenie do problemu / definicja

Meta ogłosiła wdrożenie nowych mechanizmów antyscamowych w WhatsApp, Facebooku i Messengerze. Celem zmian jest wcześniejsze wykrywanie prób wyłudzeń, przejęć kont oraz podszywania się pod zaufane osoby, marki i instytucje. To odpowiedź na rosnącą skalę kampanii socjotechnicznych, w których cyberprzestępcy wykorzystują zarówno klasyczny phishing, jak i bardziej subtelne techniki manipulacji użytkownikiem.

Nowe funkcje koncentrują się na analizie zachowań, treści i kontekstu komunikacji. Dzięki temu platformy Meta mają skuteczniej identyfikować podejrzane działania jeszcze przed pełną kompromitacją konta lub udanym oszustwem finansowym.

W skrócie

WhatsApp wprowadza ostrzeżenia dotyczące podejrzanych prób podłączania nowych urządzeń do konta.
Facebook testuje alerty związane z ryzykownymi zaproszeniami do znajomych.
Messenger rozwija wykrywanie wzorców oszustw, w tym fałszywych ofert pracy.
Użytkownicy mogą przekazywać podejrzane rozmowy do analizy przez systemy AI.
Meta wykorzystuje modele analizujące tekst, obrazy i sygnały kontekstowe do wykrywania podszywania się pod celebrytów, marki i instytucje.
Rozwijane są również mechanizmy identyfikacji zwodniczych linków prowadzących do spreparowanych witryn.

Kontekst / historia

Nowe zabezpieczenia wpisują się w szerszy trend walki z oszustwami prowadzonymi przez zorganizowane grupy przestępcze. Szczególnie istotnym obszarem pozostają komunikatory, ponieważ przejęcie dostępu do rozmów lub możliwość wysyłania wiadomości w imieniu ofiary znacząco zwiększa skuteczność dalszych działań socjotechnicznych.

Jednym z kluczowych problemów jest nadużywanie mechanizmu łączenia urządzeń w WhatsApp. Funkcja ta została zaprojektowana z myślą o wygodnym i bezpiecznym korzystaniu z konta na wielu terminalach, jednak w praktyce może zostać wykorzystana przez napastników, jeśli użytkownik zostanie nakłoniony do podania kodu autoryzacyjnego lub zeskanowania spreparowanego kodu QR.

Działania Meta są osadzone również w szerszym krajobrazie walki z sieciami scamowymi. Firma podkreśla, że usuwa duże wolumeny reklam i kont powiązanych z oszustwami oraz współpracuje z organami ścigania w ramach międzynarodowych operacji wymierzonych w zorganizowaną cyberprzestępczość.

Analiza techniczna

Z technicznego punktu widzenia najciekawszym elementem jest nowy system ostrzegania w WhatsApp. Mechanizm opiera się na analizie sygnałów behawioralnych, które mogą wskazywać, że próba podłączenia nowego urządzenia stanowi element oszustwa. Chodzi przede wszystkim o scenariusze, w których atakujący nakłania ofiarę do przekazania numeru telefonu, kodu logowania lub zeskanowania kodu QR pod fałszywym pretekstem.

Ten model kompromitacji jest szczególnie niebezpieczny, ponieważ różni się od klasycznego pełnego przejęcia konta. Ofiara często nadal zachowuje dostęp do własnego profilu, przez co incydent może pozostać niezauważony. Jednocześnie napastnik może uzyskać wgląd w wiadomości, śledzić konwersacje, a w niektórych przypadkach także wykorzystywać przejęty kanał do dalszego podszywania się pod właściciela konta.

Na Facebooku testowany jest model wykrywania podejrzanych zaproszeń do znajomych. Ocena ryzyka może uwzględniać takie sygnały jak niewielka liczba wspólnych znajomych, nietypowa aktywność profilu czy lokalizacja niezgodna z regionem użytkownika. To przykład analizy metadanych i korelacji cech profilu z prawdopodobieństwem oszustwa.

W Messengerze rozwijane są mechanizmy klasyfikacji rozmów pod kątem wzorców charakterystycznych dla nadużyć, takich jak fałszywe rekrutacje czy próby wyłudzeń finansowych. Dodatkową warstwę ochronną stanowi możliwość przesyłania podejrzanych konwersacji do analizy przez systemy sztucznej inteligencji. Równolegle Meta rozwija modele wykrywające podszywanie się pod znane osoby i marki oraz identyfikujące linki prowadzące do fałszywych stron.

Konsekwencje / ryzyko

Dla użytkowników końcowych największe ryzyko dotyczy utraty poufności komunikacji, podszywania się pod ofiarę oraz wykorzystania jej relacji społecznych do dalszych ataków. Kompromitacja komunikatora może prowadzić do wyłudzeń pieniędzy, kradzieży danych osobowych, przejęcia kolejnych kont i ataków wymierzonych w znajomych lub rodzinę.

W środowisku firmowym skutki mogą być jeszcze poważniejsze. Przejęty lub cicho monitorowany komunikator pracownika może stać się źródłem wycieku informacji operacyjnych, danych projektowych, ustaleń biznesowych czy informacji o strukturze organizacyjnej. Taki dostęp może wspierać kolejne kampanie phishingowe i spear phishingowe, ponieważ napastnik poznaje styl komunikacji, zależności służbowe i bieżące procesy wewnętrzne.

Szczególne znaczenie ma fakt, że tego typu nadużycia często wykorzystują legalne funkcje platform. W efekcie incydent nie musi objawiać się natychmiastowym zablokowaniem ofiary ani typowymi symptomami znanymi z infekcji malware, co utrudnia szybkie wykrycie zagrożenia.

Rekomendacje

Użytkownicy powinni zachować szczególną ostrożność wobec wszelkich próśb o podanie kodów, zatwierdzenie logowania, zeskanowanie kodu QR lub powiązanie konta z nowym urządzeniem. Takie działania należy traktować jako operacje wysokiego ryzyka i wykonywać wyłącznie z własnej inicjatywy, po dokładnej weryfikacji celu.

Nie udostępniać kodów autoryzacyjnych ani danych logowania osobom trzecim.
Nie skanować kodów QR przesyłanych przez nieznane lub podejrzane kontakty.
Regularnie sprawdzać aktywne sesje i listę podłączonych urządzeń.
Weryfikować nietypowe prośby innym kanałem komunikacji.
Zachować ostrożność nawet wobec wiadomości pochodzących z pozornie znanych kont.

W organizacjach warto rozszerzyć szkolenia z zakresu socjotechniki o scenariusze dotyczące komunikatorów i mechanizmów łączenia urządzeń. Zespoły bezpieczeństwa powinny również uwzględniać platformy społecznościowe i komunikacyjne jako ważny element telemetryki zagrożeń oraz procedur reagowania na incydenty.

Podsumowanie

Nowe funkcje wdrażane przez Meta pokazują, że walka z oszustwami przesuwa się z poziomu prostego filtrowania treści na poziom analizy zachowań, kontekstu i wzorców interakcji. Szczególnie istotne jest zabezpieczenie procesu podłączania urządzeń w WhatsApp, ponieważ jego nadużycie może prowadzić do trudnej do wykrycia kompromitacji komunikacji.

Rozszerzenie ochrony na Facebooka i Messengera potwierdza, że komunikatory i platformy społecznościowe są obecnie jednym z głównych pól działania cyberprzestępców. Dla użytkowników indywidualnych i organizacji oznacza to konieczność traktowania socjotechniki w komunikatorach jako pełnoprawnego wektora ataku wymagającego zarówno odpowiednich zabezpieczeń technicznych, jak i dojrzałości operacyjnej.

Źródła

Meta adds new WhatsApp, Facebook, and Messenger anti-scam tools — https://www.bleepingcomputer.com/news/security/meta-adds-new-whatsapp-facebook-and-messenger-anti-scam-tools/
Meta: Fighting scams across WhatsApp, Facebook and Messenger — https://about.fb.com/news/2026/03/fighting-scams-across-whatsapp-facebook-and-messenger/
WhatsApp FAQ: About linked devices — https://faq.whatsapp.com/1317564962315842
Dutch govt warns of Signal, WhatsApp account hijacking attacks — https://www.bleepingcomputer.com/news/security/dutch-govt-warns-of-signal-whatsapp-account-hijacking-attacks/
Meta joins global anti-scam operation targeting criminal networks — https://about.fb.com/news/2026/03/meta-joins-global-anti-scam-operation-targeting-criminal-networks/

PhantomRaven powraca: nowa fala złośliwych pakietów npm uderza w deweloperów i CI/CD

Wprowadzenie do problemu / definicja

PhantomRaven to kampania ataków na łańcuch dostaw oprogramowania wymierzona w ekosystem npm. Jej operatorzy publikują złośliwe pakiety podszywające się pod legalne biblioteki JavaScript, a następnie wykorzystują je do pobrania kolejnego etapu malware i kradzieży danych z maszyn deweloperskich oraz środowisk automatyzacji.

Najnowsza odsłona tej operacji pokazuje, że zagrożenie dla deweloperów pozostaje aktywne i jest rozwijane w sposób utrudniający klasyczne metody wykrywania. Problem nie dotyczy wyłącznie pojedynczych stacji roboczych, lecz całego procesu tworzenia i dostarczania oprogramowania.

W skrócie

W marcu 2026 roku opisano trzy nowe fale kampanii PhantomRaven, w których zidentyfikowano 88 złośliwych pakietów npm publikowanych z użyciem ponad 50 jednorazowych kont. Atakujący zastosowali technikę Remote Dynamic Dependencies, dzięki której właściwy złośliwy kod nie musiał znajdować się bezpośrednio w opublikowanej paczce.

Po instalacji malware zbierał między innymi adresy e-mail, dane systemowe, informacje konfiguracyjne oraz tokeny powiązane z usługami deweloperskimi i CI/CD. Następnie dane były eksfiltrowane do infrastruktury kontrolowanej przez napastników.

88 złośliwych pakietów npm w nowych falach kampanii
Ponad 50 kont wykorzystanych do publikacji
Kradzież danych z plików konfiguracyjnych i zmiennych środowiskowych
Celowanie w tokeny GitHub, GitLab, Jenkins i CircleCI
Obchodzenie detekcji poprzez zewnętrzne zależności i rotację infrastruktury

Kontekst / historia

PhantomRaven został ujawniony jesienią 2025 roku jako szeroko zakrojona kampania wymierzona w użytkowników npm. Już wtedy badacze wskazywali, że atak nie jest jednorazową akcją, lecz elementem szerszego modelu operacyjnego opartego na wielokrotnym publikowaniu nowych paczek, zmianie domen C2 i szybkim porzucaniu użytych kont.

Nowe fale aktywności obserwowano od listopada 2025 do lutego 2026 roku. Z perspektywy obrońców szczególnie istotne jest to, że operatorzy nie opierali się wyłącznie na ukrywaniu złośliwego kodu w samym archiwum npm, lecz konsekwentnie przenosili właściwy ładunek do zależności pobieranej z zewnętrznego adresu URL. Taki model utrudnia analizę statyczną i pozwala utrzymywać kampanię przez dłuższy czas.

Analiza techniczna

Rdzeń techniczny kampanii opiera się na mechanizmie Remote Dynamic Dependencies. W praktyce oznacza to, że wpis w pliku package.json może odwoływać się nie tylko do paczki z oficjalnego rejestru, ale również do zewnętrznego zasobu kontrolowanego przez napastnika. Gdy ofiara uruchamia standardową instalację zależności, narzędzie pobiera komponent spoza zaufanego źródła i wykonuje zawarty w nim kod.

Takie podejście daje atakującym kilka istotnych przewag. Złośliwy kod nie musi być wprost obecny w paczce widocznej w rejestrze, co zmniejsza szansę wykrycia przez automatyczne skanery. Dodatkowo ładunek może być modyfikowany po publikacji, bez konieczności aktualizowania pakietu npm, a infrastruktura eksfiltracji może być rotowana niemal niezależnie od samej paczki.

Według analiz złośliwy kod wykonywał po uruchomieniu kilka działań rozpoznawczych i eksfiltracyjnych. Obejmowały one zbieranie danych z plików takich jak .gitconfig i .npmrc, odczyt zmiennych środowiskowych oraz wyszukiwanie tokenów i sekretów związanych z popularnymi platformami developerskimi oraz systemami CI/CD.

pobieranie danych konfiguracyjnych z maszyny ofiary
odczyt informacji z plików użytkownika i ustawień npm
pozyskiwanie zmiennych środowiskowych
wyszukiwanie tokenów GitHub, GitLab, Jenkins i CircleCI
zbieranie telemetrii systemowej, w tym adresu IP, nazwy hosta, systemu operacyjnego i wersji Node.js
przesyłanie danych do serwerów C2

Eksfiltracja była realizowana głównie przez żądania HTTP GET, ale obserwowano również wykorzystanie HTTP POST oraz WebSocket jako metod zapasowych. Sugeruje to, że operatorzy dbali o odporność kanałów wycieku i chcieli zwiększyć skuteczność działania także w środowiskach z częściowo ograniczonym ruchem sieciowym.

Badacze zauważyli ponadto charakterystyczne cechy infrastruktury: spójne wzorce nazewnictwa domen zawierających słowo „artifact”, hostowanie na AWS EC2, brak certyfikatów TLS oraz niewielkie różnice między payloadami kolejnych fal. Oznacza to, że mimo zmian domen i kont publikujących model operacyjny kampanii pozostawał w dużej mierze niezmienny.

Dodatkowym elementem ryzyka jest stosowanie nazw pakietów wyglądających wiarygodnie i przypominających legalne projekty. Mechanizm ten bywa porównywany do slopsquattingu, czyli wykorzystywania nazw, które mogą zostać błędnie zasugerowane przez narzędzia AI lub bezrefleksyjnie skopiowane przez dewelopera z podpowiedzi czy niezweryfikowanego wpisu.

Konsekwencje / ryzyko

Skutki kampanii PhantomRaven mogą być znacznie poważniejsze niż zwykły incydent na pojedynczej stacji roboczej. Kompromitacja środowiska deweloperskiego daje atakującym możliwość pozyskania sekretów, które następnie mogą zostać użyte do dalszego ruchu bocznego, przejęcia pipeline’ów, dostępu do repozytoriów oraz potencjalnego skażenia procesu wydawniczego.

Największe ryzyko wynika z tego, że nawet jednorazowa instalacja złośliwego pakietu może otworzyć drogę do szerszego ataku na organizację. W przypadku przejęcia tokenów CI/CD lub danych dostępowych do repozytoriów incydent może szybko przerodzić się w naruszenie integralności kodu i artefaktów produkcyjnych.

przejęcie tokenów i sekretów używanych w procesach CI/CD
nieautoryzowany dostęp do repozytoriów i systemów build
ryzyko dalszego skażenia artefaktów i paczek
wyciek danych identyfikujących deweloperów i infrastrukturę
eskalacja do pełnowymiarowego ataku na łańcuch dostaw

Rekomendacje

Organizacje rozwijające oprogramowanie w ekosystemie JavaScript powinny traktować podobne kampanie jako trwałe zagrożenie operacyjne. Sama analiza podatności nie wystarczy, ponieważ problem dotyczy złośliwych pakietów i zależności pobieranych dynamicznie z niezaufanych lokalizacji.

blokować lub ściśle monitorować zależności wskazujące na zewnętrzne adresy URL w package.json
egzekwować korzystanie wyłącznie z zatwierdzonych rejestrów i zaufanych publisherów
wdrożyć skanowanie pakietów pod kątem złośliwych zachowań, nie tylko znanych CVE
analizować skrypty preinstall, postinstall i inne hooki instalacyjne
ograniczać uprawnienia tokenów deweloperskich i CI/CD zgodnie z zasadą najmniejszych uprawnień
rotować sekrety po każdym podejrzeniu instalacji niezweryfikowanej paczki
monitorować ruch wychodzący ze stacji deweloperskich i runnerów CI
szkolić zespoły, aby weryfikowały nazwy pakietów sugerowane przez narzędzia AI i poradniki zewnętrzne
utrzymywać wewnętrzny allowlist pakietów oraz mirror zależności dla projektów produkcyjnych
włączyć detekcję wskaźników kompromitacji związanych z nietypowymi domenami i ruchem HTTP bez TLS

W przypadku podejrzenia kompromitacji należy przeanalizować logi instalacji zależności, sprawdzić historię użycia tokenów, zweryfikować integralność pipeline’ów oraz odtworzyć listę pakietów instalowanych w okresie ryzyka. Reakcja powinna obejmować zarówno stacje robocze, jak i środowiska automatyzacji.

Podsumowanie

PhantomRaven potwierdza, że współczesne ataki na łańcuch dostaw w npm nie muszą wykorzystywać szczególnie skomplikowanego malware, aby były skuteczne. Wystarczy połączenie dobrze dobranej techniki ukrywania drugiego etapu, rotacji infrastruktury i wykorzystania zaufania deweloperów do popularnego ekosystemu pakietów.

Dla zespołów bezpieczeństwa kluczowe staje się dziś nie tylko monitorowanie tego, jakie biblioteki są instalowane, ale również skąd są pobierane i jakie działania wykonują podczas procesu instalacji. Kontrola pochodzenia zależności, ochrona sekretów i telemetria z procesów build pozostają podstawą obrony przed takimi kampaniami.

Źródła

BleepingComputer — New PhantomRaven NPM attack wave steals dev data via 88 packages — https://www.bleepingcomputer.com/news/security/new-phantomraven-npm-attack-wave-steals-dev-data-via-88-packages/
Endor Labs — The Return of PhantomRaven: Detecting Three New Waves of npm Supply Chain Attacks — https://www.endorlabs.com/learn/return-of-phantomraven

Jak ograniczyć wycieki danych przez agentów AI w nowoczesnym przedsiębiorstwie

Wprowadzenie do problemu / definicja

Agenci AI coraz częściej działają w firmach jako autonomiczni wykonawcy zadań: analizują dokumenty, pobierają dane z systemów, uruchamiają procesy i komunikują się z innymi aplikacjami bez stałego nadzoru człowieka. To zwiększa efektywność operacyjną, ale jednocześnie tworzy nową klasę ryzyk bezpieczeństwa, w której problemem nie jest wyłącznie sam model językowy, lecz cały ekosystem uprawnień, integracji i danych.

W praktyce źle zaprojektowany lub nadmiernie uprzywilejowany agent może stać się kanałem wycieku informacji, pośrednikiem w nieautoryzowanych operacjach albo trudnym do zauważenia punktem wejścia dla atakującego. Dlatego bezpieczeństwo agentów AI należy analizować szerzej niż bezpieczeństwo samej warstwy generatywnej.

W skrócie

Agenci AI rozszerzają powierzchnię ataku organizacji, ponieważ działają jak cyfrowi operatorzy z dostępem do danych i systemów.
Największe ryzyko wynika z połączenia autonomii, szerokich uprawnień oraz ograniczonej widoczności ich działań.
Atakujący mogą wykorzystać manipulację wejściem, kontekstem lub dokumentami, aby skłonić agenta do ujawnienia informacji lub wykonania niepożądanych akcji.
Skuteczna obrona wymaga inwentaryzacji agentów, ograniczenia uprawnień, audytu tokenów i stałego monitoringu działań.

Kontekst / historia

Przedsiębiorstwa najpierw wdrażały generatywną AI jako narzędzie wspierające użytkowników, a następnie zaczęły wykorzystywać ją do automatyzacji procesów. Kolejnym etapem stało się upowszechnienie agentów AI, którzy nie tylko odpowiadają na pytania, ale także samodzielnie wykonują sekwencje działań w oparciu o cele biznesowe i dostęp do środowiska firmowego.

Ta zmiana z modelu „AI jako asystenta” do modelu „AI jako operatora” znacząco zmienia profil ryzyka. Tradycyjne narzędzia bezpieczeństwa projektowano z myślą o użytkownikach, kontach technicznych i przewidywalnych integracjach aplikacyjnych. Agenci AI nie mieszczą się w pełni w żadnej z tych kategorii, ponieważ korzystają z wielu źródeł danych, konektorów SaaS, API, pamięci kontekstowej i logiki orkiestracji workflow.

Analiza techniczna

Najważniejszy problem techniczny dotyczy rozszerzonej powierzchni ataku poza sam model AI. Obejmuje ona tożsamość agenta, uprawnienia do systemów i danych, dokumenty stanowiące wejście dla modelu, konektory do aplikacji, pamięć kontekstową oraz mechanizmy przechowywania wyników. Właśnie w tych elementach najczęściej pojawiają się luki prowadzące do nadużyć.

Jednym z najbardziej praktycznych scenariuszy ataku jest manipulacja wejściem. Złośliwa instrukcja może zostać ukryta w dokumencie, wiadomości, arkuszu lub innym artefakcie przetwarzanym przez agenta. Jeśli agent ma możliwość nie tylko odczytu takich danych, ale również wykonywania akcji w systemach organizacji, może zostać nakłoniony do ujawnienia informacji, przesłania danych do nieautoryzowanego miejsca albo wykonania operacji niezgodnej z intencją właściciela procesu.

Istotnym zagadnieniem pozostaje także tzw. ciemna materia tożsamości, czyli zbiór kont, sesji, tokenów i uprawnień związanych z agentami AI, które nie zostały prawidłowo zinwentaryzowane. W wielu środowiskach agent otrzymuje szeroki dostęp na zapas, aby uniknąć błędów operacyjnych. Taki model prowadzi do nadmiarowych zezwoleń i sytuacji, w której pojedynczy komponent może odczytywać lub modyfikować zbyt wiele zasobów.

Z perspektywy obrony nie wystarczy więc zabezpieczyć modelu. Konieczny jest audyt całego łańcucha wykonawczego: identyfikacja agentów, mapowanie relacji z systemami, przegląd sekretów i tokenów, ograniczenie zakresu dostępu oraz wdrożenie kontroli wykrywających nietypowe lub nieautoryzowane działania.

Konsekwencje / ryzyko

Wycieki danych przez agentów AI mogą mieć wymiar operacyjny, regulacyjny i finansowy. Najbardziej oczywiste zagrożenie to ekspozycja danych poufnych, takich jak dokumentacja wewnętrzna, informacje handlowe, dane klientów czy materiały objęte tajemnicą przedsiębiorstwa. Jeśli agent ma dostęp do wielu repozytoriów i systemów, skala wycieku może być większa niż w przypadku pojedynczego konta użytkownika.

Drugim poziomem ryzyka są nieautoryzowane działania biznesowe. Agent może zostać skłoniony do wysłania wiadomości, pobrania zbioru danych, zmiany konfiguracji lub uruchomienia procesu w sposób technicznie poprawny, lecz sprzeczny z polityką bezpieczeństwa. Takie incydenty bywają trudne do wykrycia, ponieważ z perspektywy systemu akcja wygląda na legalną.

Trzecim problemem jest ograniczona widoczność. Jeżeli organizacja nie traktuje agentów AI jako odrębnych bytów tożsamościowych i nie prowadzi pełnego rejestrowania ich decyzji, czas wykrycia incydentu znacząco rośnie. To z kolei zwiększa ryzyko naruszeń zgodności, strat reputacyjnych oraz kosztownych zakłóceń operacyjnych.

Rekomendacje

Aby ograniczyć ryzyko wycieku danych przez agentów AI, organizacje powinny przyjąć podejście jednocześnie skoncentrowane na danych i tożsamości. W praktyce oznacza to wdrożenie kilku kluczowych działań.

Pełna inwentaryzacja agentów AI – należy zidentyfikować wszystkich agentów, ich właścicieli biznesowych, cele działania, modele, źródła danych i połączenia z systemami.
Zarządzanie tożsamością i uprawnieniami – każdy agent powinien funkcjonować jako jasno zdefiniowany podmiot z minimalnym zakresem dostępu zgodnym z zasadą najmniejszych uprawnień.
Audyt konektorów i tokenów – trzeba przeanalizować klucze API, tokeny, konta serwisowe i integracje SaaS, eliminując nadmiarowe zezwolenia i skracając czas życia sekretów.
Kontrola danych wejściowych i kontekstu – dokumenty, wiadomości i inne artefakty przetwarzane przez agentów powinny być traktowane jako potencjalny wektor ataku.
Monitoring działań agentów – warto rejestrować nie tylko logi systemowe, ale również kontekst decyzji, wykorzystane dane oraz wykonane akcje.
Ograniczenie autonomii dla operacji wysokiego ryzyka – działania obejmujące dane wrażliwe, transfer informacji poza organizację lub zmiany administracyjne powinny wymagać dodatkowej autoryzacji lub mechanizmu human-in-the-loop.
Regularne testy bezpieczeństwa – zespoły bezpieczeństwa powinny prowadzić przeglądy architektury, symulacje nadużyć, testy prompt injection i ocenę odporności workflow na manipulację kontekstem.

Podsumowanie

Agenci AI stają się pełnoprawnym elementem infrastruktury przedsiębiorstwa, a nie jedynie eksperymentalnym dodatkiem do produktywności. To oznacza, że powinny być objęte takim samym rygorem bezpieczeństwa jak użytkownicy uprzywilejowani, aplikacje krytyczne i konta techniczne.

Najważniejsza zmiana polega na odejściu od myślenia wyłącznie o modelu AI i skupieniu się na całym środowisku jego działania: tożsamościach, uprawnieniach, danych, integracjach i obserwowalności. Bez takiego podejścia agent AI może stać się cichym kanałem wycieku danych oraz trudnym do wykrycia elementem łańcucha ataku.

Źródła

The Hacker News — How to Stop AI Data Leaks: A Webinar Guide to Auditing Modern Agentic Workflows

InstallFix i fałszywe strony Claude Code: nowa kampania malvertisingowa uderza w użytkowników narzędzi AI

Wprowadzenie do problemu / definicja

InstallFix to nowy wariant ataku socjotechnicznego, który łączy malvertising z podszywaniem się pod legalne strony instalacyjne narzędzi dla programistów. W opisanej kampanii celem stali się użytkownicy Claude Code, czyli terminalowego asystenta kodowania, a głównym mechanizmem ataku było nakłonienie ofiary do skopiowania i uruchomienia spreparowanej komendy instalacyjnej.

To szczególnie niebezpieczny model działania, ponieważ bazuje na codziennych nawykach deweloperów. Wiele narzędzi CLI jest wdrażanych przez pojedyncze polecenie uruchamiane w terminalu, dlatego fałszywa instrukcja nie musi wyglądać podejrzanie, aby została uznana za wiarygodną.

W skrócie

Atakujący promują fałszywe strony Claude Code za pomocą sponsorowanych wyników wyszukiwania.
Ofiara trafia na stronę przypominającą legalny serwis producenta.
Prezentowana komenda instalacyjna uruchamia złośliwy kod zamiast prawdziwego narzędzia.
Efektem może być wdrożenie infostealera Amatera Stealer.
Największe ryzyko dotyczy kradzieży tokenów, poświadczeń i sekretów używanych w środowiskach deweloperskich.

Kontekst / historia

Kampanię opisali badacze z Push Security, wskazując, że fałszywe strony Claude Code były promowane reklamami kierowanymi do osób szukających instrukcji instalacji i użycia narzędzia w CLI. To rozwinięcie znanego już modelu ClickFix, w którym użytkownik sam wykonuje złośliwe polecenie pod pretekstem naprawy błędu, konfiguracji lub aktualizacji aplikacji.

Nowość nie polega tu na przełomowej technice technicznej, ale na bardzo trafnym doborze celu i scenariusza. Narzędzia AI dla programistów, podobnie jak inne aplikacje konsolowe, często są instalowane właśnie przez pojedynczą komendę, co tworzy idealne warunki do nadużyć i zwiększa skuteczność socjotechniki.

Analiza techniczna

Łańcuch ataku rozpoczyna się od reklamy sponsorowanej wyświetlanej ponad wynikami organicznymi. Po kliknięciu użytkownik trafia na stronę-klon, która wizualnie naśladuje legalny serwis, stosuje podobny język komunikacji i eksponuje gotową komendę do uruchomienia w terminalu.

Kluczowym elementem jest podstawienie spreparowanego polecenia. Po jego wklejeniu i uruchomieniu to sam użytkownik inicjuje wykonanie kodu z poziomu własnego konta, co utrudnia wykrycie ataku przez klasyczne mechanizmy ochronne nastawione na załączniki, phishing e-mailowy lub exploity przeglądarkowe.

W opisywanym przypadku skutkiem wykonania komendy było wdrożenie malware Amatera Stealer. Tego typu infostealery koncentrują się na pozyskiwaniu danych uwierzytelniających, ciasteczek sesyjnych, tokenów dostępowych, zapisanych sekretów oraz informacji z przeglądarek i lokalnych aplikacji.

Na stacjach roboczych deweloperów szczególnie cenne dla atakujących są:

tokeny Git i dane dostępowe do platform repozytoryjnych,
lokalnie zapisane klucze API,
poświadczenia do usług chmurowych i paneli administracyjnych,
sekrety używane w procesach budowania i wdrażania,
artefakty sesyjne, które w określonych scenariuszach mogą pomóc ominąć dodatkowe zabezpieczenia.

Znaczenie ma również infrastruktura wykorzystywana w kampanii. Napastnicy korzystają z domen i platform hostingowych, które nie zawsze wzbudzają automatyczne podejrzenia, przez co prosty filtering reputacyjny może okazać się niewystarczający.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest kompromitacja tożsamości deweloperskiej. We współczesnych organizacjach konto programisty często stanowi punkt wejścia do repozytoriów kodu, systemów CI/CD, środowisk testowych, usług chmurowych i innych elementów łańcucha dostaw oprogramowania.

Kradzież jednego zestawu poświadczeń może prowadzić do:

przejęcia prywatnych repozytoriów,
wstrzyknięcia złośliwego kodu do pipeline’ów CI/CD,
wycieku kodu źródłowego i sekretów,
uzyskania dostępu do środowisk testowych lub produkcyjnych,
dalszego ruchu bocznego wewnątrz infrastruktury organizacji.

Kampania pokazuje także rosnące ryzyko na styku AI i DevOps. Narzędzia wspierające kodowanie przyciągają szeroką grupę użytkowników, w tym osoby mniej doświadczone w ocenie zagrożeń, które częściej ufają gotowym instrukcjom i reklamom. Dodatkowym problemem jest krótki cykl życia domen oraz stron używanych w takich kampaniach, co sprawia, że statyczne IOC szybko tracą wartość operacyjną.

Rekomendacje

Organizacje powinny potraktować ten incydent jako sygnał ostrzegawczy dla całego procesu instalacji narzędzi deweloperskich i AI. Skuteczna odpowiedź wymaga zarówno kontroli technicznych, jak i zmian proceduralnych.

Wprowadzić zasadę niewklejania komend z niezweryfikowanych stron, reklam i wyników sponsorowanych.
Standaryzować instalację narzędzi poprzez wewnętrzne repozytoria, zatwierdzone pakiety lub kontrolowane mechanizmy dystrybucji.
Ograniczać uprawnienia na stacjach roboczych i stosować separację kont.
Monitorować polecenia pobierające i uruchamiające skrypty z Internetu oraz nietypowe procesy potomne po uruchomieniu terminala.
Chronić sekrety przy użyciu menedżerów sekretów, krótkotrwałych tokenów i regularnej rotacji kluczy.
Szkolić użytkowników z rozpoznawania malvertisingu i ryzyka związanego z fałszywymi stronami instalacyjnymi.
Rozszerzyć telemetrię EDR/XDR na środowiska deweloperskie, które powinny być traktowane jako zasoby wysokiej wartości.

Podsumowanie

InstallFix nie opiera się na nowym exploicie, ale skutecznie wykorzystuje współczesne nawyki pracy z terminalem, CLI i narzędziami AI. Atakujący przenoszą socjotechnikę z poczty elektronicznej do sponsorowanych wyników wyszukiwania i legalnie wyglądających stron, gdzie pojedyncza komenda może uruchomić pełny łańcuch kompromitacji.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest prosty: proces instalacji narzędzi deweloperskich musi być traktowany jako element powierzchni ataku. W realiach szybkiej adopcji AI nawet rutynowe skopiowanie komendy do terminala może zakończyć się utratą poświadczeń, dostępu do repozytoriów i zagrożeniem dla całego łańcucha dostaw oprogramowania.

Źródła

Dark Reading — https://www.darkreading.com/cloud-security/installfix-attacks-fake-claude-code
Anthropic Docs: Set up Claude Code — https://docs.anthropic.com/en/docs/claude-code/getting-started
Anthropic Docs: Quickstart — https://docs.anthropic.com/en/docs/claude-code/quickstart
Anthropic: Claude Code — https://www.anthropic.com/claude-code/

Terra Portal: AI pod nadzorem człowieka zmienia testy penetracyjne środowisk produkcyjnych

Wprowadzenie do problemu / definicja

Automatyzacja testów penetracyjnych z użyciem sztucznej inteligencji staje się jednym z najważniejszych kierunków rozwoju offensive security. W praktyce pełna autonomia takich narzędzi w środowiskach produkcyjnych wciąż budzi jednak uzasadnione obawy związane z ryzykiem operacyjnym, błędną oceną podatności oraz zgodnością z politykami organizacji. Terra Portal to nowa platforma desktopowa, która ma rozwiązywać ten problem poprzez połączenie agentowej AI z aktywnym nadzorem człowieka.

Model ten określany jest jako „human-governed AI”. Oznacza to, że agenci AI wykonują powtarzalne i czasochłonne zadania operacyjne, ale decyzje dotyczące działań wrażliwych, ryzykownych lub potencjalnie inwazyjnych pozostają po stronie specjalisty. Taki układ ma zwiększać skalę i szybkość testów, bez rezygnacji z kontroli wymaganej w żywych środowiskach biznesowych.

W skrócie

Terra Security zaprezentowała Terra Portal jako aplikację dla pentesterów i zespołów offensive security, która wspiera prowadzenie testów penetracyjnych z użyciem AI. Producent pozycjonuje rozwiązanie jako sposób na skrócenie czasu od wykrycia podatności do jej usunięcia z tygodni lub miesięcy do nawet kilku godzin.

Platforma łączy autonomicznych agentów AI z nadzorem człowieka.
Rozwiązanie jest przeznaczone do pracy w środowiskach produkcyjnych.
Celem jest przyspieszenie walidacji podatności i remediacji.
Produkt może wspierać zarówno zespoły wewnętrzne, jak i dostawców usług pentestingu.

Kontekst / historia

Rynek cyberbezpieczeństwa od kilku lat intensywnie rozwija automatyzację rekonesansu, analizy kodu, mapowania powierzchni ataku oraz walidacji podatności. Dotychczas organizacje zwykle wybierały pomiędzy tradycyjnymi narzędziami pentesterskimi, które są skuteczne, lecz trudne do skalowania, a systemami o wysokim poziomie autonomii, które w środowiskach produkcyjnych mogły generować zbyt duże ryzyko.

W tym kontekście Terra Portal wpisuje się w rosnący trend przechodzenia od jednorazowych testów projektowych do ciągłej walidacji bezpieczeństwa. To istotne szczególnie tam, gdzie presja regulacyjna, wymagania klientów oraz tempo zmian w infrastrukturze wymuszają szybsze potwierdzanie podatności i równie szybkie ich usuwanie.

Analiza techniczna

Sercem rozwiązania jest agentowy model pracy oparty na dwóch klasach komponentów AI. Pierwszą grupę stanowią autonomiczni agenci działający w tle. Odpowiadają oni za takie zadania jak rekonesans, przegląd kodu, generowanie przypadków testowych, analiza osiągalności, wykonywanie testów penetracyjnych, walidacja możliwości wykorzystania podatności, dokumentacja oraz wsparcie remediacji.

Drugą grupą są agenci typu Copilot, aktywowani wtedy, gdy sytuacja staje się bardziej złożona, pojawia się większe ryzyko biznesowe lub konieczne jest uwzględnienie ograniczeń organizacyjnych. W tym modelu człowiek pozostaje kluczowym punktem decyzyjnym dla działań wrażliwych, takich jak kontrolowana eksploatacja czy końcowa ocena wyników. To odróżnia platformę od koncepcji pełnej autonomii, gdzie decyzje o potencjalnie inwazyjnych działaniach mogłyby być pozostawione wyłącznie systemowi.

Według opisu rozwiązania platforma ma integrować się z szerszym ekosystemem agentowego pentestingu Terra Security. Skoordynowana grupa agentów ma stale mapować środowisko, identyfikować powierzchnię ataku, budować hipotezy dotyczące możliwych scenariuszy naruszenia i potwierdzać występowanie podatności. Jeśli automatyczne komponenty napotkają ograniczenia, pentester może przejąć sterowanie w tym samym kontekście operacyjnym, bez utraty ciągłości pracy.

Konsekwencje / ryzyko

Najważniejszą korzyścią z takiego podejścia jest skrócenie czasu między wykryciem problemu a jego naprawą. W praktyce może to oznaczać szybsze zamykanie krytycznych luk, zanim zostaną wykorzystane przez rzeczywistych atakujących. Dla zespołów bezpieczeństwa i dostawców usług oznacza to także większą wydajność operacyjną oraz możliwość nadzorowania większej liczby działań przy tych samych zasobach kadrowych.

Wdrożenie agentowej AI do testów środowisk produkcyjnych nie eliminuje jednak ryzyka. Nadal możliwe są błędne oceny wpływu podatności, wyniki fałszywie dodatnie lub fałszywie ujemne, niewłaściwe określenie zakresu działań czy naruszenie wewnętrznych polityk bezpieczeństwa. W organizacjach o wysokiej wrażliwości dochodzi do tego ryzyko reputacyjne i operacyjne, jeśli automatyczne testy wpłyną na dostępność usług lub integralność danych.

Istotne jest również to, że rozwój takich narzędzi może zmienić model biznesowy pentestingu. Zamiast punktowych audytów realizowanych co kilka miesięcy lub raz do roku, coraz bardziej realny staje się model ciągłej walidacji bezpieczeństwa. Taki kierunek zwiększa dojrzałość obronną organizacji, ale jednocześnie wymaga znacznie lepszych procesów governance, kontroli zmian i zarządzania wyjątkami.

Rekomendacje

Organizacje planujące wdrożenie AI do testów penetracyjnych powinny zacząć od precyzyjnego zdefiniowania granic autonomii. Każde działanie mogące wpływać na system produkcyjny, dane lub ciągłość działania powinno mieć jasno określony próg autoryzacji człowieka.

Formalnie zatwierdzać zakres testów i dopuszczalne techniki działania.
Rejestrować wszystkie działania agentów oraz decyzje operatorów.
Wdrożyć ścieżki eskalacji dla scenariuszy wysokiego ryzyka.
Kontrolować zmiany w politykach, regułach i konfiguracji automatyzacji.
Rozdzielić rekonesans, walidację i eksploatację na poziomy ryzyka.
Utrzymywać pełną telemetrię procesu, w tym logi, kontekst testów i wpływ na zasoby.

Z perspektywy operacyjnej równie ważne jest przygotowanie procesów remediacji do szybszego cyklu wykrycie–naprawa. Sama automatyzacja identyfikacji podatności nie przyniesie pełnych korzyści, jeśli organizacja nie będzie w stanie szybko triagować zgłoszeń, przypisywać odpowiedzialności i wdrażać poprawek.

Podsumowanie

Terra Portal pokazuje, że przyszłość testów penetracyjnych może należeć do modeli łączących agentową AI z kontrolą człowieka w krytycznych momentach procesu. Takie podejście ma potencjał znacząco zwiększyć skalę i tempo walidacji bezpieczeństwa, szczególnie w środowiskach wymagających ciągłego monitorowania ekspozycji na atak.

Jednocześnie skuteczność tego modelu będzie zależeć od jakości nadzoru, dojrzałości procesów governance oraz zdolności organizacji do bezpiecznego łączenia automatyzacji z eksperckim osądem. W praktyce nie chodzi więc o zastąpienie pentestera, lecz o przesunięcie jego roli z wykonawcy powtarzalnych czynności do operatora i decydenta w zautomatyzowanym procesie offensive security.

Źródła

Help Net Security — https://www.helpnetsecurity.com/2026/03/10/terra-security-terra-portal-pentesting-app/