Badanie Wiz dotyczące ataków agentowych identyfikuje siedem sygnatur, wskazując zarazem ograniczenia atrybucji

Wiz opublikował 29 października badanie identyfikujące siedem sygnatur ataków agentowych, jednocześnie przyznając, że ustalenie operatora nadal pozostaje trudne. Analiza ataków agentowych Wiz dotyczy włamań z udziałem agentów AI — oprogramowania wykorzystującego modele do wybierania działań i obsługi narzędzi. Jej główne napięcie dotyczy widoczności: rozpoznawalne zachowanie może pomagać śledczym, lecz nie pozwala wiarygodnie ustalić, kto kontrolował atak.

Microsoft, CrowdStrike i Huntress stanowią użyteczne punkty odniesienia. Ich dochodzenia opisują różne rodzaje dowodów — od odzyskanych plików atakujących po rejestry uwierzytelniania klientów. Różnice te mają znaczenie przy ustalaniu, czy incydent obejmował autonomiczne wykonanie, wsparcie AI, tradycyjne skrypty czy kombinację tych elementów.

Dla zespołów bezpieczeństwa w przedsiębiorstwach natychmiastowa presja ma charakter operacyjny. Oczekiwanie na definitywną atrybucję AI może opóźniać ograniczanie skutków, podczas gdy uznawanie każdego zautomatyzowanego włamania za agentowe może zniekształcać priorytety. Praktyczne pytanie dotyczy tego, jak szybko obrońcy potrafią rozpoznać nieautoryzowany dostęp, połączyć powiązaną aktywność i ją przerwać.

Badanie Wiz dotyczące ataków agentowych przenosi debatę w stronę obserwowalnego zachowania

Znaczenie tego raportu wynika z jego ujęcia problemu. Zamiast traktować udział AI jako etykietę przypisaną po włamaniu, przedstawia on kryteria behawioralne, które śledczy mogą analizować. Kryteria te tworzą punkt wyjścia do sprawdzania wyjaśnienia względem dowodów.

Użyteczna sygnatura wspiera dochodzenie; nie zastępuje dowodów na to, co atakujący faktycznie osiągnął.

To rozróżnienie oddziela analizę bezpieczeństwa od sporu o terminologię. Organizacja musi wiedzieć, czy tożsamość uzyskała nieautoryzowane uprawnienia, czy poświadczenia wyciekły oraz czy uzyskano dostęp do wrażliwych danych. Ustalenie odpowiedzialnego oprogramowania służy powiązanemu, lecz odmiennemu celowi.

Rozważmy różnicę między alertem a wnioskiem. Nietypowa sekwencja może uzasadniać dochodzenie, nie dowodząc jednak, że model wybrał każde działanie. Śledczy mogą zachować oba osądy: aktywność zasługuje na uwagę, a jej mechanizm działania pozostaje niepewny.

Jest to szczególnie istotne przy ocenie badań dostawców. Raport może zawierać cenne obserwacje, pozostawiając jednocześnie bez odpowiedzi pytania dotyczące szerszej interpretacji. Czytelnicy powinni odróżniać bazowe zapisy od wyjaśnienia, które badacze uznają za najbardziej prawdopodobne.

Ta sama dyscyplina dotyczy słowa autonomiczny. Operator może zatwierdzić cel, uruchomić narzędzie, przejrzeć wyniki pośrednie i interweniować, gdy proces utknie. Opisanie całej tej sekwencji jako autonomicznej może ukryć istotne różnice w kontroli.

Alternatywą jest opisanie zaobserwowanego delegowania zadań. Czy oprogramowanie wybierało cele, pisało polecenia, interpretowało błędy, czy jedynie wykonywało przygotowaną listę? Każda odpowiedź wskazuje inny wkład, z odmiennymi konsekwencjami dla wykrywania i reagowania.

Zmienia to również oczekiwania przedsiębiorstw wobec dostawców bezpieczeństwa. Twierdzenie o rozpoznawaniu AI zasługuje na przykłady potwierdzające, jasny język pewności oraz wyjaśnienie alternatywnych interpretacji. Jakość wykrywania powinna pozostać możliwa do oceny nawet wtedy, gdy model stojący za atakiem jest nieznany.

Istotne porównanie dotyczy zatem adaptacyjnego wykonania i zdolności obrońcy do jego odtworzenia. Tradycyjna automatyzacja nadal pozostaje częścią tego porównania. Jej obecność nie wyklucza użycia modelu w innym miejscu procesu.

Model może pomagać w tworzeniu skryptu, który później działa niezależnie. Z drugiej strony skrypt może zbierać wyniki, które agent wykorzystuje do decyzji o kolejnym działaniu. Dzienniki klienta nie muszą ujawniać takiego podziału pracy.

Dla nabywców tworzy to prosty standard oceny. Należy pytać, czy produkt identyfikuje istotne nieautoryzowane zachowanie, wyjaśnia swoje dowody i pomaga zespołom reagowania działać. Pewna etykieta AI niewiele wnosi, jeśli tych możliwości brakuje.

Siedem sygnatur dostarcza wskazówek, a nie werdyktu

• Utrzymująca się iteracja: Wiz opisuje zmienną aktywność prowadzoną w tempie maszyny, która trwa dłużej niż typowa sesja ręczna. Czas trwania pomaga ustalić kontekst.

• Pisemne uzasadnienie: Narzędzia zawierają wyjaśnienia zamierzonych działań. Taki tekst stanowi kolejny artefakt do zbadania.

• Adaptacyjna korekta: Kolejne próby zmieniają się po niepowodzeniach. Śledczy mogą porównywać te poprawki.

• Szeroki zakres: Aktywność systematycznie bada różne techniki. Sekwencja może ujawnić jej organizację.

• Równoległa eksploracja: Wiele możliwych ścieżek jest analizowanych jednocześnie. Poszerza to zakres dowodów, które osoby reagujące muszą połączyć.

• Walidacja przed wykonaniem: Wstępne kontrole poprzedzają istotne działania i obejmują środki mające ograniczać wykonanie.

• Jednorazowe artefakty: Opisowe pliki tymczasowe i ślady identyfikacyjne dostarczają wskazówek dotyczących przygotowania i ewidencjonowania. Stanowią one podsumowanie sygnatur ataków agentowych opisanych przez Wiz.

• Ich zbiorowe znaczenie: Kilka zgodnych obserwacji wspiera hipotezę skuteczniej niż pojedynczy wzorzec nazewnictwa. Żadna pojedyncza sygnatura nie powinna automatycznie przesądzać o atrybucji.

• Porównanie z legalną automatyzacją: Przy ocenie podobnego zachowania należy uwzględniać autoryzowane narzędzia testowe i administracyjne. Kontekst określa, czy działanie jest uzasadnione.

• Implikacja dla wykrywania: Wykrywanie ataków agentowych powinno ustalać tożsamości, uprawnienia, cele i konsekwencje obok wskazówek behawioralnych.

• Pytanie o fałszywe alarmy: Detektor wymaga oceny względem dozwolonej aktywności. W przeciwnym razie pozorna czułość może tworzyć obciążenie dochodzeniowe bez poprawy decyzji.

• Pytanie o brakujące dowody: Brak artefaktu nie dowodzi nieobecności agenta. Śledczy powinni dokumentować ograniczenia zbierania danych.

• Pytanie o pewność: Raporty powinny rozróżniać bezpośrednie obserwacje, wnioskowane zależności i nierozstrzygnięte wyjaśnienia. Kategorie te ułatwiają weryfikację.

• Pytanie o autoryzację: Rozstrzygające pozostaje, czy działanie przekroczyło uprawnienia. Dokładna etykieta modelu sama tego nie rozstrzygnie.

• Pytanie o zachowanie dowodów: Przechowywanie oryginalnych zapisów pozwala, by późniejsze ustalenia zmieniły ocenę bez przepisywania pierwotnych dowodów.

• Pytanie o adaptację: Sygnatura oparta na sposobie prezentacji wymaga weryfikacji. Jej użyteczność zależy od tego, czy zmiana prezentacji ją unieważnia.

• Pytanie operacyjne: Zespoły reagowania potrzebują wystarczających dowodów, aby przerwać szkodliwą aktywność przed rozstrzygnięciem każdej niepewności dotyczącej jej autora.

• Pytanie o raportowanie: Kadra kierownicza powinna otrzymać jasny opis dotkniętych systemów i potwierdzonych konsekwencji wraz z poziomem pewności co do proponowanego mechanizmu.

Przypadki ARTEX i Hermes pokazują, dlaczego dowody muszą pozostawać rozdzielone

Dochodzenie Zscaler z 14 października łączy ARTEX, framework do koordynowania wspomaganych przez AI testów bezpieczeństwa, z atakami na południowokoreańskie instytucje finansowe. Firma informuje o kradzieży danych osobowych dotyczących około 67 000 osób. Badacze opisali wykorzystanie aplikacji dostępnych z internetu, w tym portali zapytań i backendów aplikacji mobilnych. Ich ocena dotycząca aktora mówiącego po chińsku i działającego z motywacji finansowej miała umiarkowany poziom pewności. Ustalenia przedstawiono w analizie włamania do sektora finansowego.

Wspólny framework nie dowodzi wspólnego operatora, motywu ani rezultatu.

Analiza CrowdStrike z 7 października przedstawia inną perspektywę dowodową. Opisuje odzyskane pliki konfiguracji ARTEX, historie sesji Claude Code oraz pliki pamięci z infrastruktury kontrolowanej przez atakujących. Takie artefakty zapewniają widoczność wykraczającą poza aktywność zarejestrowaną w środowisku ofiary. CrowdStrike nie przypisał tej koreańskiej kampanii konkretnie nazwanemu przeciwnikowi w swojej analizie infrastruktury ARTEX.

Rozróżnienie to ma znaczenie, ponieważ nazwa narzędzia może stać się zbyt wygodną zasadą organizującą. Analitycy mogą grupować incydenty do porównań technicznych, nie twierdząc przy tym, że przeprowadziła je ta sama organizacja. Czytelnicy powinni zachować ten podział przy porównywaniu nagłówków.

Przypadek tajlandzki dotyczy innego frameworka i innych ograniczeń. Hunt.io poinformował, że odzyskane dzienniki wskazywały na działanie Hermes bez monitów o zatwierdzenie poleceń podczas włamania wymierzonego w Ministerstwo Finansów Tajlandii. Publikacja z 23 lipca opisywała wewnętrzną eksplorację oraz dowody naruszenia systemów.

Hunt.io stwierdził, że metoda uzyskania początkowego dostępu była niejasna. Nie znalazł również dowodów na eksfiltrację badanych plików ministerstwa. Ograniczenia te towarzyszą obserwacjom technicznym przedstawionym w dochodzeniu dotyczącym włamania z użyciem Hermes.

Ostatnie zastrzeżenie zmienia publiczny opis zdarzenia. Dowody na to, że atakujący przeszukiwał pliki, wspierają dochodzenie dotyczące dostępu. Same w sobie nie dowodzą, że pliki opuściły środowisko. Brak dowodów na eksfiltrację nie powinien też być uznawany za stwierdzenie, że kradzież była niemożliwa.

Przypadki te ilustrują różne pytania, na które musi odpowiedzieć przegląd incydentu. Odzyskana konfiguracja pomaga identyfikować narzędzia. Zapisy sesji pomagają wyjaśnić wykonanie. Zapisy ofiary pomagają ustalić wpływ. Dowody z jednej kategorii nie mogą automatycznie wypełniać luk w innej.

Dla programistów praktyczne znaczenie dotyczy granicy wokół wystawionej aplikacji. Sam przegląd aplikacji może pozostawić bez odpowiedzi pytania o poświadczenia i usługi dostępne za jej pośrednictwem. Dochodzenie musi ustalić te zależności, a nie je zakładać.

Dla pracowników wiedzy kwestia dotyczy informacji stojących za tymi zależnościami. Repozytorium dokumentów, portal klienta lub wewnętrzna usługa wyszukiwania oznaczają dostęp do rzeczywistych danych. Wartość wyjaśnienia opartego na AI zależy częściowo od tego, czy wyjaśnia ono taką ekspozycję.

Są to odrębne zgłoszone incydenty, każdy z własnymi dowodami. Łączenie ich największych liczb i najmocniejszych twierdzeń stworzyłoby bardziej dramatyczną historię, ale mniej trafną ocenę.

ConnectWise wywiera presję na istniejące zaufanie do aplikacji

Analiza Microsoft z 21 października przypisuje kompromitację ConnectWise Cloud Backup grupie Storm-0940, którą opisuje jako aktora powiązanego z chińskim państwem. Microsoft twierdzi, że ARTEX przyspieszył nadużywanie przejętych poświadczeń aplikacji i próby logowania do ponad 2 250 dzierżaw Microsoft 365. Dzierżawa to chmurowe środowisko Microsoft danej organizacji.

Firma wyraźnie rozróżnia próby dostępu od potwierdzonego wpływu. Aplikacja objęta naruszeniem, a nawet udane uwierzytelnienie, nie muszą oznaczać, że uzyskano dostęp do danych klientów lub je skradziono. Jej ustalenia opisują nadużycie istniejącego zaufania do aplikacji w analizie kampanii ConnectWise.

Kluczową ekspozycją jest zakres uprawnień, które aplikacja już posiada, gdy jej poświadczenia trafiają w ręce atakujących.

Tworzy to jednocześnie presję na klientów i dostawców. Klient musi rozumieć uprawnienia nadane w swoim środowisku. Dostawca musi wyjaśnić, co stało się z poświadczeniami wspierającymi tę relację.

Znaczenie analityczne AI ujawnia się w tym, co dzieje się po uzyskaniu dostępu. Jeśli oprogramowanie może oceniać okazje i podejmować działania przy mniejszej uwadze operatora, proces reagowania staje przed innym obciążeniem. Nie unieważnia to jednak pierwotnej decyzji o zaufaniu.

Uwierzytelnianie aplikacji wymaga także innych pytań niż znane dochodzenie dotyczące logowania pracownika. Która aplikacja działała? Jakie uprawnienia obowiązywały? Kto był właścicielem jej poświadczeń? Jakie zmiany nastąpiły? Odpowiedzi muszą wskazywać autoryzowaną relację, zanim zostaną ocenione odstępstwa od niej.

Dla nabywców korporacyjnych pytania te powinny należeć do oceny dostawców. Użyteczne zapewnienie opisuje kontrolę nad poświadczeniami, widoczność dla klienta, komunikację dotyczącą incydentów oraz obowiązki związane z odzyskiwaniem sprawności. Ogólne deklaracje o bezpiecznej AI nie mogą zastąpić tych szczegółów operacyjnych.

Na szczególną uwagę zasługuje rozróżnienie między próbą dostępu a dostępem skutecznym. Liczba prób mierzy skalę ukierunkowania ataku. Rejestry uwierzytelniania potwierdzają kolejny etap. Dowody zmian uprawnień lub dostępu do danych potwierdzają dalsze etapy. Każdy z nich wymaga własnego potwierdzenia.

Łączenie tych etapów może wprowadzać decydentów w błąd w przeciwnych kierunkach. Zawyżona liczba kompromitacji może zniekształcić skalę incydentu. Zbyt wąskie skupienie na powodzeniu logowania może pominąć istotne zmiany wymagające odrębnej analizy.

Odzyskiwanie sprawności wprowadza kolejną granicę. Przywrócenie usługi dostawcy odpowiada na pytanie o dostępność. Ustalenie, że nieautoryzowany dostęp ustał, odpowiada na pytanie o bezpieczeństwo. Klienci potrzebują dowodów odpowiednich dla obu kwestii, nawet jeśli dochodzenia się pokrywają.

Tymczasowe przerwanie działania może zatem wymagać decyzji operacyjnej, a nie prostego technicznego resetu. Organizacja musi rozważyć swoją zależność od usługi wraz z dowodami uzasadniającymi jej przywrócenie. Ocena ta powinna opierać się na aktualnych wytycznych dotyczących incydentów.

Badania Wiz dotyczące ataków agentowych należą do tej dyskusji, ponieważ skupiają uwagę na wzorcach wykonania. Przypadek konta ConnectWise dodaje konkretną relację zaufania. Razem skłaniają do analizy wzajemnego oddziaływania autoryzacji, wykrywania i reagowania.

Wniosek dla działów zakupów jest konkretny. Nabywcy powinni pytać, jak można sprawdzać i ograniczać uprawnienia integracji oraz jak wykrywane jest jej nieoczekiwane użycie. Pytania te pozostają przydatne niezależnie od wybranego przez atakującego frameworka.

Przypisanie ataku AI pozostaje mniej pewne niż nieautoryzowany dostęp

Huntress przedstawia ważne zastrzeżenie do opisu przypadku ConnectWise. Jego śledczy twierdzą, że ich telemetria jest zgodna z ustaleniami Microsoftu, lecz nie potwierdza niezależnie udziału AI. Ich własna ocena, oparta wyłącznie na zapisach klientów, osiąga niski do średniego poziom pewności.

Opisują narzędzia, które zmieniały się między kolejnymi uruchomieniami, a także żądania kontynuowane po usunięciu docelowej tożsamości aplikacji. Huntress nie miał wglądu w systemy atakującego ani w użycie bazowego modelu. Dlatego ich analiza wykonania ataku traktuje skrypty, interwencję operatora i agenta jako nakładające się możliwości.

Niepewność dotycząca udziału AI nie unieważnia dowodów nieautoryzowanej aktywności.

To najsilniejsza przeciwwaga dla zbyt pewnych interpretacji tych śladów. Sekwencja może wspierać hipotezę o agencie, pozostając jednocześnie zgodna z innymi wyjaśnieniami. Właściwą odpowiedzią jest przedstawienie konkurencyjnych wyjaśnień i wskazanie, jakie dowody mogłyby je rozróżnić.

Zmienione narzędzie może odzwierciedlać korektę wygenerowaną przez model. Może też wynikać z edycji kodu przez człowieka lub wyboru istniejącej opcji. Obserwacja zmiany potwierdza, że zachowanie się zmieniło; ustalenie jej autora wymaga dodatkowych dowodów.

Rozróżnienie to staje się szczególnie ważne przy omawianiu rozumowania. Logi mogą pokazywać działanie następujące po błędzie. Zazwyczaj nie ujawniają pełnego procesu decyzyjnego stojącego za tym działaniem. Raportowanie powinno unikać przedstawiania prawdopodobnego wyjaśnienia przyczynowego jako zaobserwowanego faktu.

Przypisanie ataku AI obejmuje również odrębne problemy atrybucji. Jeden dotyczy obecności modelu. Drugi — frameworka. Kolejny — człowieka lub organizacji, która nim kierowała. Pewność na jednym poziomie nie przenosi się automatycznie na pozostałe.

Odzyskany plik konfiguracyjny może wzmocnić identyfikację frameworka, nie ustalając jednak, kto go obsługiwał. Znany wzorzec infrastruktury może wspierać ocenę dotyczącą sprawcy, nie dowodząc, że określony model wygenerował polecenia.

Dlatego porównania między Wiz, Microsoft, CrowdStrike i Huntress powinny koncentrować się na ich dowodach. Obserwują one różne części działań. Zgodność może wzmacniać interpretację, lecz powtarzane przypisanie pochodzące z pierwotnego źródła nie stanowi niezależnego potwierdzenia.

Należy również uwzględniać zachęty komercyjne, nie odrzucając przy tym badań. Dostawcy bezpieczeństwa mają powody, by podkreślać nowe zagrożenia i własne możliwości reagowania. Czytelnicy powinni osobno oceniać opublikowane obserwacje i deklaracje produktowe.

Użyteczne porównanie produktów pyta, czy system wyjaśnia swoje alerty i zachowuje zapisy potrzebne do ich przeglądu. Powinno także wyjaśniać, które środowiska obserwuje, a które pozostają poza jego zasięgiem. Szerokie deklaracje dotyczące widoczności wymagają konkretnego zakresu.

Dla osób kierujących działaniami podczas incydentu wyzwaniem komunikacyjnym jest oddzielenie pewności od pilności. Zespół może mieć ograniczoną pewność co do udziału AI i jednocześnie mocne podstawy do ograniczenia incydentu. Raportowanie dla kadry zarządzającej powinno czynić oba osądy zrozumiałymi.

Ważna jest też sytuacja odwrotna. Silne dowody na udział agenta nie ustalają skali kradzieży danych. Atrybucja może stawać się jaśniejsza, podczas gdy wpływ pozostaje nierozstrzygnięty.

Wykrywanie ataków agentowych powinno zatem wspierać łańcuch decyzji. Ustal zachowanie, określ, czy było autoryzowane, zidentyfikuj dotknięte zasoby i udokumentuj pozostałą niepewność. Etykieta modelu jest użyteczna, gdy usprawnia ten łańcuch.

Co obserwować do stycznia 2027 roku

Kolejny etap powinien być oceniany na podstawie opublikowanych dowodów i wyników operacyjnych. Większa liczba komunikatów o incydentach związanych z AI byłaby mniej wartościowa niż jaśniejsze opisy tego, co agenci kontrolowali i co obrońcy zdołali przerwać.

Najsilniejsze potwierdzenie połączy artefakty po stronie atakującego, aktywność po stronie ofiary oraz niezależnie ustalone konsekwencje.

Pierwszym sygnałem jest silniejsze potwierdzenie w tych kategoriach dowodów. Warto obserwować dochodzenia, które zestawiają odzyskane zapisy agentów z uwierzytelnionymi działaniami w środowiskach ofiar. Takie dopasowanie pomogłoby odróżnić bezpośrednią delegację od przygotowania wspieranego przez AI.

Takie raportowanie wzmocniłoby argument, że agenci wykonują działania o istotnych konsekwencjach. Z kolei przypadki oparte wyłącznie na szybkości lub stylu kodu pozostawiłyby szerszą kwestię atrybucji nierozstrzygniętą. Rosnąca liczba incydentów nie może naprawić słabych podstaw dowodowych.

Drugim sygnałem jest mierzalna jakość wykrywania. Warto śledzić oceny wyjaśniające, jak proponowane ślady zachowują się wobec autoryzowanej automatyzacji. Legalne testowanie, administracja i działania wdrożeniowe zapewniają konieczne porównania.

Detektor, który identyfikuje szkodliwą aktywność przy jednoczesnym ograniczaniu obciążenia dochodzeniowego, wzmocniłby argument za obroną. System, który głównie rozpoznaje komentarze, konwencje nazewnictwa lub rytm działań, wymagałby węższej interpretacji swojej użyteczności.

Istotnym rezultatem jest to, czy analitycy szybciej podejmują właściwe decyzje. Nabywcy powinni szukać dowodów na to, co wykryto, jaki kontekst towarzyszył alertowi i jaka reakcja nastąpiła. Same opisy inteligencji modelu nie mogą potwierdzić tego rezultatu.

Trzecim sygnałem jest bardziej przejrzyste raportowanie odzyskiwania sprawności po naruszeniu integracji. Warto obserwować ujawnienia, które rozdzielają działania naprawcze dostawcy, dochodzenie klienta, przywrócenie usługi i usunięcie nieautoryzowanego dostępu. Każdy etap odpowiada na inne pytanie operacyjne.

Dowody, że etapy te są dokumentowane i koordynowane, wspierałyby zaufanie do gotowości reagowania. Utrzymująca się niejednoznaczność ujawniłaby problem zarządczy, nawet gdy pierwotny mechanizm włamania zostałby dobrze zrozumiany.

Sygnały te odnoszą się do tego samego napięcia obecnego w całej dyskusji o atakach agentowych Wiz: atakujący mogą delegować pracę, podczas gdy obrońcy nadal potrzebują wiarygodnego kontekstu. Wartość dla bezpieczeństwa wynika z uczynienia tego kontekstu użytecznym w działaniu.

Utrzymywanie dostępnego rejestru decyzji wspiera ten cel. Zespoły muszą zachowywać informacje o tym, co wiedziały, dlaczego działały i które pytania pozostawały otwarte. Przeszukiwalna baza wiedzy inżynierskiej może wspierać tę dokumentację obok wyspecjalizowanych systemów bezpieczeństwa.

Natychmiastowym działaniem jest przegląd sposobu, w jaki organizacja oceniłaby podobne ujawnienie. Zidentyfikuj, kto odpowiada za uprawnienia aplikacji, kto może pobrać istotne zapisy i kto może zatwierdzić ograniczenie incydentu. Poproś dostawców o rozróżnienie prób dostępu, skutecznego uwierzytelnienia, zmian uprawnień i potwierdzonej kradzieży danych. Zachowaj te rozróżnienia we własnej komunikacji dotyczącej incydentów. Wykorzystaj siedem śladów jako wskazówki do dochodzenia, a następnie sprawdź wyjaśnienie na podstawie dostępnych dowodów. Gdy dostawca twierdzi, że jego system wykrywa ataki agentowe, poproś o przykład pokazujący, co ustalił alert i co zrobili następnie responderzy. Taki przegląd stanowi konkretny punkt wyjścia do oceny gotowości bez czekania na doskonałą atrybucję.