Dlaczego techniczne i organizacyjne środki bezpieczeństwa są kluczowe dla zgodności z NIS2?
Dyrektywa NIS2 stawia jasne wymagania: organizacje objęte jej zakresem muszą wdrożyć odpowiednie i proporcjonalne środki cyberbezpieczeństwa – zarówno techniczne, jak i organizacyjne. Nie chodzi tu o sztuczną biurokrację czy „odhaczanie” zgodności na papierze. NIS2 wymusza realne zabezpieczenia, które mają chronić krytyczne usługi i dane przed współczesnymi zagrożeniami.
20 października 2025 r. Amazon Web Services (AWS) doświadczył jednej z najpoważniejszych awarii ostatnich lat. Jej bezpośrednią przyczyną okazał się pojedynczy punkt awarii (SPOF) w zautomatyzowanym systemie zarządzania rekordami DNS dla Amazon DynamoDB w regionie US-EAST-1 (N. Virginia). Błąd wywołał niedostępność kluczowych usług i kaskadowe problemy w innych komponentach AWS (m.in. EC2, Lambda, NLB), dotykając milionów użytkowników i tysięcy firm na całym świecie. Amazon opisał zdarzenie w oficjalnym podsumowaniu incydentu (post-mortem).
W skrócie
Root cause: „uśpiony” błąd wyścigu (race condition) w module DNS Enactor zarządzającym rekordami Route53 dla DynamoDB; doprowadził do usunięcia aktywnego planu DNS i pozostawienia pustego rekordu dla dynamodb.us-east-1.amazonaws.com. Automaty nie potrafiły się z tego samodzielnie podnieść — potrzebna była ingerencja operatorów.
Czas trwania: zakłócenia od 11:48 PM PDT 19.10 do ~3:01 PM PDT 20.10 (ok. 15 godzin do pełnej normalizacji).
Skala wpływu: globalne usługi i aplikacje (finanse, komunikatory, e-commerce, IoT). Media i analiza branżowa potwierdzają szerokie skutki i długi „ogon” problemów.
Status: przyczyna potwierdzona przez Amazon; opublikowano szczegółowe kroki naprawcze i plany zabezpieczeń.
Kontekst / historia / powiązania
Region US-EAST-1 to najstarszy i największy hub AWS — historycznie centrum kilku głośnych incydentów (m.in. S3 w 2017 r., Kinesis w 2020 r.). AWS utrzymuje repozytorium publicznych podsumowań incydentów, co pozwala porównać genezę i wzorce awarii. Reuters i inne tytuły wskazywały już w dniu zdarzenia na „wąskie gardło” w tym regionie.
Analiza techniczna / szczegóły luki
Co się wydarzyło w DNS? DynamoDB zarządza setkami tysięcy rekordów DNS w każdym regionie, a ich aktualizacje realizują dwa komponenty: DNS Planner (tworzy „plany” rekordów) i DNS Enactor (aplikuje je w Route53). Dla odporności Enactor działa równolegle w trzech AZ. Rzadki zbieg okoliczności spowodował, że dwa Enactory działały na różnych generacjach planu: starszy, opóźniony Enactor nadpisał nowszy plan dla endpointu regionalnego, a inny Enactor posprzątał (usunął) uznane za „stare” plany — w efekcie wszystkie adresy IP dla endpointu regionalnego zniknęły, a system utknął w niespójnym stanie, którego automaty nie umiały samodzielnie naprawić. Potrzebna była interwencja ręczna.
Dlaczego awaria była kaskadowa?
Brak rozwiązywalności DNS dla dynamodb.us-east-1.amazonaws.com spowodował zwiększone błędy API w DynamoDB (11:48 PM–2:40 AM PDT).
Zależne systemy (np. EC2 DropletWorkflow Manager) traciły dzierżawy i nie mogły uruchamiać nowych instancji; długa kolejka napraw doprowadziła do „congestive collapse” i konieczności celowego throttlingu oraz restartów komponentów. Pełna normalizacja EC2 nastąpiła o 1:50 PM PDT.
Network Load Balancer wchodził w błędne stany zdrowia (health checks) dla węzłów z niepropagowaną jeszcze konfiguracją sieci, co wywołało oscylacje i automatyczne przełączenia AZ w DNS. Normalizację NLB przywrócono m.in. przez tymczasowe wyłączenie automatycznych failoverów.
Lambda, ECS/EKS, Fargate miały podwyższone opóźnienia i błędy do czasu rozładowania backlogów i przywrócenia przepustowości.
Oś czasu (PDT):
11:48 PM 19.10 — start problemów DNS/DynamoDB.
2:25 AM 20.10 — odtworzenie informacji DNS; stopniowa poprawa.
10:36 AM–1:50 PM — przywracanie EC2 i propagacji stanów sieci.
Globalny efekt domina: choć awaria dotyczyła jednego regionu, odbiła się na platformach na całym świecie (bankowość, komunikatory, e-commerce, urządzenia IoT). To realny dowód, jak silnie scentralizowany jest Internet wokół kilku dostawców chmury.
Ryzyko operacyjne: aplikacje zależne od pojedynczego regionu i od DNS jako warstwy sterowania są narażone na „black-holing”, jeżeli automatyzacja DNS zawiedzie. Analizy branżowe i komentarze ekspertów podkreślają systemowe ryzyko koncentracji.
Rekomendacje operacyjne / co zrobić teraz
Architektura i odporność
Multi-Region by design: aktywno-aktywny lub aktywno-pasywny z automatycznym failoverem (Route53, global tables w DynamoDB, readiness probes). Testuj przełączenia pod presją (chaos engineering).
Odporność na awarie DNS: krótkie TTL dla krytycznych rekordów, lokalne cache z wygaszaniem, DNS failover poza dotkniętym regionem; monitoruj NXDOMAIN/EMPTY dla istotnych endpointów (alerting). (Wnioski z post-mortem.)
Separacja ścieżek kontroli i danych: alternatywne „out-of-band” kanały sterowania (np. awaryjne runbooki korzystające z innych regionów/kont).
Ogranicz zaufanie do pojedynczych automatyzacji: circuit breakers na poziomie infrastruktury (throttling per-service), ochrona przed congestive collapse w kolejkach wewnętrznych.
Eksploatacja i procesy 5. SLO/SLI dla DNS i control-plane: osobne SLI dla rozwiązywalności krytycznych endpointów + testy syntetyczne (np. ThousandEyes) z kilku AS/regionów. 6. Runbooki na „pusty rekord DNS”: szybkie obejścia (np. pinning na alternatywny endpoint / region), polityki cache-bypass, automatyczne rollbacki planów DNS. 7. Ćwiczenia: regularne GameDays z symulacją degradacji DNS i braku rozwiązywalności usług wewnętrznych.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
S3 (2017, US-EAST-1) — błąd operacyjny w narzędziach administracyjnych skutkował niedostępnością S3; dotknął warstwy storage/objektów. 2025 uderzył w DNS/control-plane i przez to rozlał się na wiele usług jednocześnie.
Kinesis (2020, US-EAST-1) — problem z capacity/scaling w komponencie analitycznym; obecnie mieliśmy race condition w automatyzacji DNS, co jest jakościowo innym wektorem.
Podsumowanie / kluczowe wnioski
DNS to krytyczna warstwa sterowania — pojedynczy błąd w orkiestracji DNS może wywołać globalny efekt domina.
US-EAST-1 to „single region of truth” dla wielu — jeśli Twoja architektura na nim polega, realnie akceptujesz wysokie ryzyko systemowe.
Automatyzacja musi mieć bezpieczniki — rozdzielenie ról, walidacja planów, ochrona przed wyścigami i kasowaniem aktywnych konfiguracji.
Ćwicz przełączenia i degradację — multi-region, testy syntetyczne, chaos engineering i runbooki awaryjne to inwestycja, która redukuje czas odcięcia.
Badacze Datadog Security Labs opisali nową technikę phishingu — CoPhish — która wykorzystuje agentów Microsoft Copilot Studio jako „wrapper” do dostarczania fałszywych żądań zgody OAuth z legalnej domeny Microsoftu (copilotstudio.microsoft.com). Atak kończy się uzyskaniem tokenu dostępu użytkownika i może prowadzić do przejęcia skrzynki pocztowej, OneNote czy innych zasobów przez Microsoft Graph. Microsoft potwierdził, że pracuje nad poprawkami w produktach, podkreślając jednocześnie element socjotechniczny ataku.
W skrócie
Wejście: ofiara trafia na udostępnioną stronę „demo” agenta Copilot Studio hostowaną w domenie Microsoftu i klika Login.
Przebieg: przycisk logowania przekierowuje do złośliwej aplikacji OAuth (wewnętrznej lub zewnętrznej), a po akceptacji uprawnień agent automatycznie ekfiltruje User.AccessToken np. przez żądanie HTTP do serwera atakującego (np. Burp Collaborator). Żądanie wychodzi z IP Microsoftu, więc ruch ofiary nie zdradza exfiltracji.
Zasięg uprawnień: nawet po niedawnych zmianach w Entra ID, konta z rolami administracyjnymi nadal mogą nadać szerokie uprawnienia aplikacjom; zwykli użytkownicy wciąż mogą zgodzić się na pewne zakresy (np. OneNote).
Status: Microsoft zapowiada dodatkowe zabezpieczenia i „utwardzenie” doświadczeń związanych ze zgodą/zarządzaniem aplikacjami.
Kontekst / historia / powiązania
CoPhish to wariant dobrze znanego „consent phishing” (MITRE ATT&CK T1528 – Steal Application Access Token), w którym ofiara sama przyznaje dostęp złośliwej aplikacji. W 2025 r. Microsoft zaostrzał domyślne polityki zgody w Entra ID, ograniczając możliwość nadawania niektórych uprawnień przez użytkowników końcowych. Jednak wektor pozostaje aktualny, zwłaszcza wobec administratorów aplikacji i w scenariuszach wewnętrznych.
Analiza techniczna / szczegóły luki
Host zaufany przez użytkowników Atakujący tworzy agenta Copilot Studio (we własnym tenantcie lub w skompromitowanym) i włącza „Demo website”, uzyskując URL w domenie Microsoftu. To znacząco zwiększa wiarygodność kampanii.
Backdoor w systemowym „Sign-in topic” Wbudowany temat logowania można modyfikować. Po akcji „Authenticate” badacze dodali krok „HTTP Request”, który wysyła zawartość zmiennej User.AccessToken w nagłówku (np. Token) do kontrolowanego endpointu.
Złośliwa aplikacja OAuth (multi-tenant) Atakujący rejestruje aplikację z odpowiednimi zakresami Graph i redirect URLhttps://token.botframework.com/.auth/web/redirect, po czym wpisuje client ID/secret do konfiguracji uwierzytelniania agenta. Kliknięcie „Login” kieruje ofiarę do workflow zgody.
Tokeny i zakresy W scenariuszu użytkownika wewnętrznego badacze uzyskali token z Mail.ReadWrite, Mail.Send, Notes.ReadWrite. Dla Application Administrator możliwe są nawet zakresy aplikacyjne (Application.ReadWrite.All) i szerokie Files/Sites.*.All.
Ślady w logach
Entra ID Audit: „Consent to application”.
Microsoft 365 Audit: operacja „Consent to application”.
Copilot Studio (Power Platform): BotCreate, BotComponentUpdate na *.topic.Signin.
Praktyczne konsekwencje / ryzyko
Business Email Compromise-as-a-Service: token daje atakującemu możliwość czytania/wykonywania akcji w imieniu użytkownika (np. wysyłka spear-phishingu z wewnętrznego konta).
Uprawnienia administracyjne: jeśli ofiarą jest Application Administrator, konsekwencje obejmują szerokie uprawnienia w Graph i potencjalne trwałe mechanizmy utrzymania dostępu.
Efekt „zaufanej domeny”: link w domenie Microsoftu zmniejsza czujność użytkowników i może obchodzić proste filtry reputacyjne.
Rekomendacje operacyjne / co zrobić teraz
Zaostrz polityki zgody w Entra ID
Ustal niestandardową politykę ograniczającą, kto i na jakie zakresy może wyrażać zgodę; przypisz ją jako domyślną.
Minimalnie: „Allow user consent for apps from verified publishers, for selected permissions (Recommended)” albo surowiej — wyłącz zgodę użytkownika i włącz workflow żądań od użytkowników.
Odbierz wszystkim możliwość rejestracji aplikacji Domyślnie każdy członek może tworzyć aplikacje. Zablokuj to ustawienie, aby utrudnić wewnętrzny „consent phishing”.
Monitoring i detekcja
Alerty na „Consent to application” (Entra/M365 Audit).
Zdarzenia Power Platform: BotCreate, BotComponentUpdate z *.topic.Signin.
Korelacje z anomaliami w Graph (np. wysyłka z konta, nietypowe dostępy do OneNote/Files).
Ogranicz powierzchnię ataku w Copilot Studio
Przeglądaj modyfikacje systemowego Sign-in topic.
Wyłącz i usuwaj nieużywane lub dziwnie nazwane boty/„demo websites”.
Zasady dla kont uprzywilejowanych
MFA phishing-resistant, PIM/JIT dla ról Application/Cloud Application Admin.
Oddzielne konta admin-only (bez licencji do codziennej pracy), zasady CA blokujące „risky consent”. (Najlepsze praktyki zgodne z dokumentacją Microsoft).
Edukacja użytkowników i zespół helpdesk
Szkolenia dot. zgody na aplikacje i rozpoznawania UX Copilot Studio vs. Microsoft 365 Copilot.
Procedura szybkiego cofania zgody i unieważniania tokenów (w tym odwołanie grantów w Entra).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Typowy „consent phishing” wykorzystuje link do strony zgody z domen niezwiązanych z Microsoftem lub z generics. CoPhish „owija” go w zaufaną domenę Copilot Studio i automatyzuje exfiltrację tokenu po stronie agenta (serwer Microsoft), co zaciemnia ślady w sieci ofiary.
Zmiany w Entra utrudniają część kampanii — ale nie dotyczą ról administracyjnych i niektórych wewnętrznych zakresów, więc powierzchnia ataku pozostaje.
Podsumowanie / kluczowe wnioski
CoPhish to nie „magiczna” luka w kryptografii OAuth, lecz sprytne nadużycie funkcji Copilot Studio i procesu zgody. Siłą ataku jest legitymizacja (domena Microsoft) i automatyzacja wycieku tokenu. Krytyczne są polityki zgody, odebranie prawa rejestracji aplikacji, monitoring zdarzeń oraz higiena ról administracyjnych. Microsoft zapowiada dalsze utwardzenie mechanizmów — nie zwalnia to jednak z wdrożenia kontroli po stronie tenantów.
Źródła / bibliografia
Datadog Security Labs — CoPhish: Using Microsoft Copilot Studio as a wrapper for OAuth phishing (analiza techniczna, IoC, detekcje). (securitylabs.datadoghq.com)
BleepingComputer — New CoPhish attack steals OAuth tokens via Copilot Studio agents (komentarz Microsoft, kontekst). (BleepingComputer)
Microsoft Learn — Manage app consent policies (Entra ID; konfiguracja polityk zgody). (Microsoft Learn)
Microsoft Learn — Configure how users consent to applications (ustawienia zgody użytkownika; zalecenia). (Microsoft Learn)
25 października 2025 r. ONZ otworzyła w Hanoi do podpisu pierwszy globalny traktat przeciw cyberprzestępczości („UN Convention against Cybercrime”, nieformalnie: Hanoi Convention). Wydarzenie zgromadziło delegacje dziesiątek państw i ma usprawnić współpracę międzynarodową w sprawach takich jak phishing, ransomware, handel ludźmi online czy mowa nienawiści. Już podczas ceremonii podpisania dokument zyskał szerokie poparcie – choć towarzyszą mu poważne zastrzeżenia dotyczące praw człowieka i wolności badań bezpieczeństwa.
W skrócie
Status: traktat otwarty do podpisu 25 października 2025 r. w Hanoi; 65 państw podpisało w pierwszym dniu. Wejście w życie: po złożeniu 40 dokumentów ratyfikacyjnych. Okno podpisów pozostaje otwarte do 31 grudnia 2026 r.
Cel: ujednolicenie przestępstw, procedur dowodowych i kanałów współpracy transgranicznej w sprawach cyber.
Kto podpisuje: m.in. UE oraz państwa członkowskie (zgoda na podpis wyrażona wcześniej przez Radę UE).
Kontrowersje: branżowe porozumienie Cybersecurity Tech Accord (m.in. Microsoft, Meta) i organizacje praw człowieka ostrzegają przed ryzykiem nadużyć („traktat nadzoru”) i penalizacją etycznych badań.
Kontekst / historia / powiązania
Negocjacje konwencji prowadziło UNODC po latach dyskusji nad potrzebą globalnych, a nie tylko regionalnych (np. europejskich), ram walki z cyberprzestępczością. Sekretarz Generalny ONZ podkreślił koszt cyberprzestępczości liczony w „bilionach dolarów rocznie” i konieczność ułatwienia współpracy między organami ścigania. Strona konwencji prowadzona przez UNODC potwierdza harmonogram: podpis w Hanoi, a następnie możliwość podpisywania w siedzibie ONZ w Nowym Jorku, z wejściem w życie 90 dni po 40. ratyfikacji.
Analiza techniczna / szczegóły traktatu
Choć pełny tekst jest obszerny, trzon instrumentu obejmuje trzy bloki, które mają największe znaczenie dla praktyków cyberbezpieczeństwa i zespołów prawnych:
Katalog przestępstw – od oszustw (phishing), przez ataki z użyciem malware/ransomware, po przestępstwa związane z treścią (np. mowa nienawiści) definiowane według standardów ONZ. To rozszerzenie tradycyjnych ujęć „komputerowych” czynów zabronionych o kategorie, które w wielu jurysdykcjach są nadal rozproszone.
Procedury dowodowe i e-dowody – zharmonizowane zasady zabezpieczania, utrwalania i udostępniania danych elektronicznych (logi, metadane, treści), ułatwiające szybką i zgodną z prawem wymianę materiału dowodowego między państwami. UNODC wskazuje, że konwencja ma promować „legalne badania” i zawiera klauzule ochrony praw człowieka.
Współpraca transgraniczna – kanały pomocy prawnej, tryb „nagłych wniosków” i punkty kontaktowe 24/7, aby skrócić czas reakcji w incydentach transgranicznych. UE potwierdziła zamiar podpisu i wdrażania zgodnie z własnymi standardami praw człowieka.
Praktyczne konsekwencje / ryzyko
Dla firm (CISO, SOC, DPO):
Więcej wezwań międzynarodowych o dane: krótsze terminy na „preservation” i przekazanie logów/treści organom zagranicznym – zwłaszcza dla usług chmurowych i platform o zasięgu globalnym.
Zwiększona interoperacyjność procedur dowodowych – potencjalnie mniej „tarć” prawnych przy przekazywaniu e-dowodów do państw sygnatariuszy.
Ryzyka praw człowieka i R&D – Tech Accord ostrzega, że nieprecyzyjne definicje mogą ułatwić nadmierny nadzór i kryminalizować testy penetracyjne/bezpieczeństwa prowadzone w dobrej wierze, jeśli lokalne prawo implementujące będzie restrykcyjne. Potrzebne będą wyraźne wyjątki i bezpieczne przystanie dla badaczy (np. coordinated vulnerability disclosure).
Dla organów ścigania i CERT/CSIRT:
Szybszy dostęp do danych transgranicznych i łatwiejsze wspólne operacje w sprawach ransomware czy oszustw finansowych.
Rekomendacje operacyjne / co zrobić teraz
Mapa jurysdykcyjna & readiness: zidentyfikuj, które kraje kluczowe dla Twojej działalności podpisały konwencję i śledź proces ratyfikacji (próg 40). Zaktualizuj playbooki SOC/LERT o tryby współpracy transgranicznej.
Retencja i łańcuch dowodowy: ustandaryzuj politykę data preservation (czas, zakres, integralność), aby spełnić oczekiwania nowych kanałów pomocy prawnej.
Legal & privacy by design: oceniaj wnioski o dane pod kątem zgodności z lokalnym prawem, RODO oraz klauzulami praw człowieka przewidzianymi przez konwencję; dokumentuj podstawy prawne i proporcjonalność.
Program CVD/bug bounty: wprowadź/wyraźnie opisz zasady coordinated vulnerability disclosure i zakres „dozwolonych testów” (safe harbor) – to ogranicza ryzyko penalizacji etycznych badań w krajach o ostrzejszej implementacji. (Obawy branży: Cybersecurity Tech Accord).
Ćwiczenia purple team: przetestuj scenariusze żądań danych z państw trzecich (różne formaty, SLA, szyfrowanie end-to-end), uwzględniając eskalacje do DPO/Legal.
Różnice / porównania z innymi przypadkami
Konwencja ONZ ma ambicję globalnego zasięgu i wspólnych, minimalnych standardów. W porównaniu z dotychczasową mozaiką porozumień i instrumentów regionalnych, stawia mocny akcent na ułatwienie dostępu do e-dowodów i mechanizmy 24/7. Jednocześnie zakres kategorii przestępstw i możliwe ingerencje w prywatność są szersze niż w wielu dotychczasowych reżimach – stąd krytyka NGO i sektora technologicznego, by implementacje krajowe nie prowadziły do nadużyć.
Podsumowanie / kluczowe wnioski
To się dzieje teraz: 25 października 2025 r. w Hanoi ruszył proces podpisywania; 65 podpisów na starcie podnosi szansę na szybkie przekroczenie progu 40 ratyfikacji.
Dla biznesu: przygotuj się na więcej i szybsze żądania o dane z zagranicy oraz audyty łańcucha dowodowego.
Dla bezpieczeństwa i prywatności: zadbaj o jasne wyjątki dla badań i procesy oceny proporcjonalności – inaczej istnieje ryzyko „efektu mrożącego” dla społeczności security.
Źródła / bibliografia
Reuters: „UN cybercrime treaty to be signed in Hanoi to tackle global offences” (25 października 2025). (Reuters)
UNODC (press): „UN Convention against Cybercrime opens for signature in Hanoi, Viet Nam” (25 października 2025). (UNODC)
UNODC (status): „United Nations Convention against Cybercrime — status & entry into force”. (UNODC)
Rada UE: „Fighting cybercrime: EU to sign UN Convention on cybercrime” (13 października 2025). (Consilium)
Cybersecurity Tech Accord: „Calls for changes to new UN treaty…” (29 lipca 2024) – stanowisko branży. (Cybersecurity Tech Accord)
Badacze z NeuralTrust opisali nową technikę ataku na przeglądarkę ChatGPT Atlas, w której złośliwy ciąg wygląda jak adres URL, ale jest celowo sformatowany niepoprawnie. Atlas traktuje taki input w pasku adresu („omnibox”) najpierw jak URL, a gdy walidacja nawigacji zawodzi, degraduje go do polecenia tekstowego – jednak z wyższym zaufaniem i słabszymi kontrolami, co umożliwia cichy jailbreak i przejęcie zachowania agenta.
OpenAI w materiałach o Atlasie podkreśla, że bezpieczeństwo agentów było priorytetem – jednak opisana technika pokazuje, że granica między „zaufaną” intencją użytkownika a nieufnym inputem bywa w praktyce rozmyta.
W skrócie
Wejście przypominające URL wklejone do omniboxa może zostać potraktowane jako wysokozaufany prompt, jeśli nie przejdzie walidacji URL.
To pozwala omijać warstwy ochronne i wymuszać działania agenta (np. phishing, destrukcyjne operacje na kontach w chmurze).
Luka wpisuje się w szerszą klasę zagrożeń prompt injection dla „agenticznych” przeglądarek (Atlas, Comet, itp.).
Kontekst / historia / powiązania
Badania Brave pokazały systemowe problemy pośredniego prompt injection w przeglądarkach z agentami – złośliwe instrukcje mogą być ukryte nie tylko w tekście strony, lecz nawet w obrazach/screenshotach. Dyskusja ta rozgorzała w tym samym tygodniu, w którym zadebiutował Atlas.
Media branżowe i technologiczne zwracały uwagę na nowe wektory ryzyka wynikające z możliwości działania w imieniu użytkownika (dostępy do zalogowanych serwisów, historii, plików).
Analiza techniczna / szczegóły luki
NeuralTrust opisuje łańcuch zdarzeń:
Przygotowanie ładunku – ciąg zaczyna się jak URL („https:” + domenopodobny fragment), ale zawiera język naturalny z imperatywami („follow these instructions…”) i celowe błędy (spacje, znaki, literówki).
Wyzwolenie – użytkownik kopiuje/wkleja „link” do omniboxa (np. po kliknięciu „Copy link”).
Iniekcja – walidacja URL nie przechodzi; Atlas traktuje treść jako prompt o pochodzeniu „od użytkownika”, z mniejszą liczbą kontroli.
Eksploatacja – agent wykonuje instrukcje: od otwarcia fałszywego Google (phishing) po operacje na Google Drive (np. kasowanie plików) przy użyciu sesji uwierzytelnionej użytkownika.
SecurityWeek streszcza ten sam mechanizm i podaje przykładowy „URL-prompt”, ilustrując eskalację zaufania wynikającą z błędu parsowania pomiędzy trybem „Nawiguj” a „Zapytać/Wykonaj”.
Praktyczne konsekwencje / ryzyko
Phishing i kradzież sesji/poświadczeń poprzez otwieranie stron podszywających się pod zaufane serwisy.
Operacje krzyżodomenowe w kontekście zalogowanego użytkownika (np. Drive, poczta) – tradycyjne SOP/CSRF nie chronią przed intencją agenta.
Degradacja polityk bezpieczeństwa (RL, guardraily) – prompt traktowany jako „intencja” może ominąć filtry treści.
Szerszy ekosystem agentów przeglądarkowych już wcześniej wykazał podatność na injection (w tym z obrazów), co dowodzi, że to problem systemowy, a nie pojedynczy bug.
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników końcowych (od razu):
Nie wklejaj do omniboxa „linków” z nieznanych źródeł; traktuj przycisk „Copy link” jak potencjalny wektor ataku.
Wyłącz/ogranicz automatyczne akcje agenta i wymagaj potwierdzenia przed dostępem do poczty, dysków, formularzy płatniczych.
Oddziel przeglądanie wrażliwe (bankowość, praca) od eksperymentów z agentem (np. osobny profil/konto).
Dla zespołów SecOps/AppSec (krótkoterminowo):
W politykach EDR/DLP i proxy oznaczaj ruch Atlas oraz monitoruj anomalie na kontach SaaS (Drive, O365).
Wprowadź kontrole kontekstowe (step-up MFA, reautoryzacja narzędzi) przy akcjach inicjowanych przez agentów.
Edukuj użytkowników: „URL ≠ URL” – pokaż przykłady obfuskacji i mechanizm degradacji do promptu. (na bazie case’u NeuralTrust).
Dla vendorów/pracujących nad agentami (średnioterminowo):
Twarde parsowanie i normalizacja URL; jeśli są niejednoznaczności – odrzuć, bez cichego fallbacku do trybu prompt.
Jawny wybór trybu (Navigate vs Ask/Act) i widoczny stan UI; brak automatycznych przełączeń.
Zasada najmniejszych uprawnień dla promptów z omniboxa; potwierdzenie użytkownika przy narzędziach/akcjach krzyżodomenowych.
Stripping instrukcji z inputów „URL-opodobnych” i tagowanie pochodzenia tokenów w rozmowie z LLM.
Różnice / porównania z innymi przypadkami
Comet / „niewidzialne” injekcje w obrazach: wektor to kontekst strony/screenshot, a nie omnibox; w Atlasie wektor siedzi w pasku adresu i podszywa się pod intencję użytkownika.
Klasyczne XSS/CSRF: atak nie łamie przeglądarkowego SOP – agent wykonuje akcje „w dobrej wierze”, co omija wiele klasycznych barier. (por. szersze omówienie w The Register i literaturze nt. agentów webowych).
Podsumowanie / kluczowe wnioski
Luka w omniboxie Atlasu to błąd granicy zaufania: URL-opodobny ciąg staje się wysokozaufanym promptem.
Efekt: jailbreaky i aktywne nadużycia w kontekście zalogowanego użytkownika.
Rozwiązania: twarde parsowanie, jawne tryby, potwierdzenia i proweniencja tokenów – do wdrożenia zarówno po stronie vendorów, jak i w politykach organizacji.
Źródła / bibliografia
NeuralTrust: „OpenAI Atlas Omnibox Prompt Injection: URLs That Become Jailbreaks” (24 paź 2025). (NeuralTrust)
SecurityWeek: „OpenAI Atlas Omnibox Is Vulnerable to Jailbreaks” (25 paź 2025). (SecurityWeek)
OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta. (OpenAI)
Brave: „Unseeable prompt injections… more vulnerabilities in Comet and other AI browsers”. (Brave)
The Register: „OpenAI defends Atlas as prompt injection attacks surface”. (The Register)
Dyrektywa NIS2 znacząco podnosi poprzeczkę w zakresie cyberbezpieczeństwa w Unii Europejskiej, rozszerzając wymagania na nowe sektory i obszary. Jednym z kluczowych – choć często niedocenianych – elementów jest bezpieczeństwo łańcucha dostaw oraz zarządzanie ryzykiem stron trzecich (third-party risk). Praktyka pokazuje, że nawet najlepiej zabezpieczona organizacja może zostać skutecznie zaatakowana poprzez luki u swojego dostawcy lub partnera.
Chińskojęzyczna grupa przestępcza znana jako Smishing Triad prowadzi trwającą kampanię phishingu SMS (smishing), w której zidentyfikowano ponad 194 000 złośliwych domen zarejestrowanych od 1 stycznia 2024 r. Celem jest wyłudzanie danych płatniczych i tożsamości poprzez fałszywe powiadomienia o opłatach drogowych, niedoręczonych paczkach i usługach rządowych. Infrastruktura rejestracyjna i DNS jest powiązana m.in. z rejestratorem w Hongkongu, natomiast hosting w dużej mierze działa na popularnych chmurach w USA.
W skrócie
Skala: 194 345 FQDN w 136 933 domenach bazowych; dzienny churn tysięcy nowych domen.
Infrastruktura: DNS po stronie chińskich dostawców (np. AliDNS), hosting i IP głównie w USA (np. AS13335/Cloudflare).
Wejścia socjotechniczne: SMS-y o mandatach za bramki/autostrady, niedoręczonych przesyłkach, a coraz częściej – logowanie do kont maklerskich.
Zyski grupy: szacunkowo >1 mld USD w ciągu 3 lat – wg śledztwa prasowego.
Zasięg: kampania globalna; podszywanie się pod banki, giełdy krypto, poczty państwowe i usługi w krajach UE (m.in. Polska, Litwa).
Kontekst / historia / powiązania
O Smishing Triad informowano już w 2023–2025 r. jako o ekosystemie PhaaS (Phishing-as-a-Service), który sprzedaje kity phishingowe i usługi na Telegramie, umożliwiając wielu podwykonawcom realizację kampanii na skalę przemysłową. Nowsze analizy pokazują rozszerzenie celów poza pocztę i opłaty drogowe na finanse i maklerkę.
Analiza techniczna / szczegóły kampanii
Domeny i wzorce: popularne prefiksy typu com-, rosnący udział gov- w ostatnich miesiącach; krótkie, mylące łańcuchy z myślnikami mają udawać znane TLD/brand (np. imitacje serwisów rządowych). 71,3% domen żyje <7 dni, a <6% przetrwa 3 miesiące. Taki churn utrudnia blokowanie.
Rejestracja/DNS/Hosting: ~68% domen zarejestrowanych w Dominet (HK) Limited; serwery głównie w USA (m.in. Cloudflare), natomiast zarządzanie DNS często przez AliDNS i Cloudflare. ~43,5 tys. unikalnych adresów IP.
Najczęściej podszywane marki/kategorie: USPS (~28 tys. FQDN) oraz toll services (~90 tys. FQDN). Kampanie dotyczą też banków, krypto, e-commerce, policji i spółek państwowych w wielu krajach (w tym w Polsce i na Litwie).
Łańcuch dostaw PhaaS: deweloperzy kitów, brokerzy danych (sprzedaż numerów), sprzedawcy domen, dostawcy hostingu, spamerzy SMS/RCS/IM, skanery „liveness” numerów, skanery blocklist – każdy element można „zamówić”.
Praktyczne konsekwencje / ryzyko
Kradzież danych i środków: wyłudzenia kart, danych osobowych, kodów OTP; dodawanie kart do portfeli mobilnych i szybkie wypłaty.
Ataki na konta maklerskie: po przejęciu kont sprawcy stosują „ramp & dump” (szybkie przeniesienie i pompowanie walorów niskiej płynności, a następnie realizacja zysków i cash-out).
Ryzyko dla organizacji: podszywanie się pod brandy (brand abuse), utrata zaufania klientów, koszty chargebacków i wsparcia.
Rekomendacje operacyjne / co zrobić teraz
Dla SOC/CSIRT i zespołów bezpieczeństwa
Blokady DNS/URL: wdrażajcie feedy oparte na pDNS + wzorcach domenowych (prefiksy com-, gov- i hyfenizacja), z automatycznym wygaszaniem/aktualizacją z powodu krótkiego TTL życia domen.
Polityki SMS: EDR/Mobile Threat Defense z detekcją linków w SMS/RCS/IM; regexy na słowa kluczowe dot. opłat drogowych/paczek i landingi z imitacjami CAPTCHy/ClickFix.
Ochrona kont finansowych: wymuście FIDO2/U2F (klucze sprzętowe) dla dostępu do usług finansowych i paneli klienta – minimalizuje skuteczność smishingu i kradzieży OTP.
Monitoring brand abuse: ciągły typosquatting + doppelganger hunt z fokusami na TLD .com/.gov-imitacje oraz nagły przyrost rejestracji prefixów.
Współpraca z dostawcami: szybka eskalacja do Cloudflare/hosterów i rejestratorów (Dominet HK itd.) w celu zdejmowania serwisów phishingowych; automatyzacja zgłoszeń.
Dla banków/domów maklerskich i fintechów
MFA odporne na phishing (FIDO2), risk-based auth, „step-up” przy dodawaniu kart do portfeli mobilnych i większych przelewach; geofencing dla provisioningów walletów.
Detekcja anomalii giełdowych związanych z „ramp & dump” z kont detalicznych (niskopłynne tickery, krótkie okna).
Dla użytkowników końcowych
Nie klikaj w linki z SMS-ów o dopłatach, mandatach, paczkach; wpisuj adres ręcznie lub używaj oficjalnej aplikacji.
Włącz klucze bezpieczeństwa do logowania (gdzie to możliwe) i unikaj podawania kodów 2FA na stronach z linków z SMS.
Różnice / porównania z innymi przypadkami
W odróżnieniu od typowych kampanii smishingowych opartych na pojedynczych kitach i stałych domenach, Smishing Triad to zdecentralizowany ekosystem PhaaS z intensywną rotacją domen (churn), podziałem ról i globalnym zasięgiem. Warto porównać to z wcześniejszymi falami podszywania się wyłącznie pod przewoźników – dziś ciężar przesuwa się na finanse i maklerkę, co zwiększa bezpośrednie straty finansowe.
Podsumowanie / kluczowe wnioski
Mamy do czynienia z operacją przemysłową, a nie pojedynczą kampanią.
Automatyzacja detekcji na poziomie DNS/URL, krótki cykl TTP-based takedown oraz MFA odporne na phishing są krytyczne.
Organizacje w UE (w tym w Polsce) również znajdują się w wektorze podszywania – należy nasilić monitoring brand abuse i edukację klientów.
Źródła / bibliografia
Palo Alto Networks Unit 42 – „The Smishing Deluge: China-Based Campaign Flooding Global Text Messages” (23 października 2025). (Unit 42)
The Hacker News – „Smishing Triad Linked to 194,000 Malicious Domains…” (24 października 2025). (The Hacker News)
Fortra – „Fortra Tracks Fivefold Increase in Brokerage Attacks YoY” (21 października 2025). (fortra.com)
The Wall Street Journal – „Chinese Criminals Made More Than $1 Billion From Those Scam Texts” (14 października 2025). (The Wall Street Journal)
