Archiwa: AI - Strona 77 z 87 - Security Bez Tabu

Tag: AI

GhostPoster: złośliwe rozszerzenia do Chrome/Firefox/Edge z 840 tys. instalacji – malware ukryte w obrazach PNG

Wprowadzenie do problemu / definicja luki

Kampania GhostPoster pokazuje, że ryzyko nie musi zaczynać się od klasycznego “CVE” w przeglądarce. W tym przypadku problemem jest nadużycie modelu zaufania do sklepów z dodatkami: złośliwe rozszerzenia potrafią przejść weryfikację, wyglądać jak “normalne” narzędzia (tłumacz, adblock, pobieracz), a następnie uruchamiać ukryty ładunek już po instalacji.

Najbardziej niepokojący element GhostPoster to technika ukrywania kodu JavaScript w plikach PNG (steganografia / “doklejony” payload poza danymi obrazu), co utrudnia wykrywanie przez statyczną analizę paczki rozszerzenia.

W skrócie

  • W styczniu 2026 opisano kolejny zestaw 17 rozszerzeń powiązanych z GhostPoster, dostępnych w sklepach Chrome / Firefox / Edge, które łącznie zebrały ok. 840 000 instalacji.
  • Kampania była wcześniej nagłośniona w grudniu 2025 (pierwotnie w kontekście Firefoksa); wtedy wskazywano technikę ukrywania loadera w ikonie PNG.
  • Złośliwy kod po aktywacji umożliwia m.in. śledzenie aktywności przeglądania, podmianę linków afiliacyjnych, osłabianie zabezpieczeń (nagłówki), wstrzykiwanie iframe’ów do fraudu reklamowego.
  • Samo zdjęcie dodatku ze sklepu nie czyści infekcji – dodatki zainstalowane lokalnie mogą działać dalej, dopóki użytkownik/IT ich nie usunie.

Kontekst / historia / powiązania

GhostPoster został po raz pierwszy szerzej opisany w grudniu 2025 przez badaczy Koi Security na przykładzie dodatków do Firefoksa (m.in. “Free VPN Forever”) – już wtedy zwrócono uwagę na steganografię w PNG i wieloetapowy łańcuch infekcji.

Najnowsze ustalenia (styczeń 2026) wskazują, że infrastruktura i TTP tej samej kampanii obejmują też Chrome i Edge, a część dodatków mogła być obecna w sklepach nawet od 2020 r., co sugeruje długą, cierpliwą operację nastawioną na monetyzację i odporność na wykrycie.

Analiza techniczna / szczegóły luki

1) Steganografia i “nietypowy” loader w PNG

W wariancie opisanym przez Koi Security rozszerzenie czyta własny plik logo.png i przeszukuje surowe bajty w poszukiwaniu znacznika ===. Wszystko po znaczniku nie jest już obrazem – to ukryty JavaScript uruchamiany w czasie działania.

2) Łańcuch wieloetapowy i opóźnienia (evasion-by-design)

GhostPoster działa warstwowo:

  • Stage 1 (PNG): wydobycie loadera z ikony/obrazu,
  • Stage 2 (C2): loader pobiera właściwy payload z serwera zdalnego (w obserwacjach Koi: m.in. liveupdt[.]com oraz dealctr[.]com),
  • dodatkowo: rzadkie “check-in’y” (np. co 48h) i probabilistyczne pobieranie payloadu (np. tylko część prób), co utrudnia analitykom “złapanie” ruchu na żywo.

LayerX opisuje również mechanizmy opóźnionej aktywacji (≥48h) i warunkowego uruchamiania łączności C2 jako kluczowy element utrzymania się kampanii.

3) “Ewolucja” wariantów: delimiter >>>> i staging w background script

W styczniowym raporcie wskazano wariant, w którym logika stagingu została przeniesiona do background script, a payload jest ukrywany w zabundlowanym pliku graficznym (nie tylko ikonie). Skrypt skanuje bajty pod kątem delimitera >>>>, zapisuje dane w storage, dekoduje Base64 i wykonuje jako JavaScript.

4) Co robi payload po aktywacji (przykładowe funkcje)

Z opisu Koi i LayerX wynika, że po uruchomieniu złośliwy kod potrafi m.in.:

  • podmieniać linki afiliacyjne (kradzież prowizji) na platformach e-commerce,
  • wstrzykiwać tracking (np. przez elementy DOM / analitykę),
  • usuwać nagłówki bezpieczeństwa (np. Content-Security-Policy, X-Frame-Options), osłabiając ochronę przed clickjacking/XSS,
  • wstrzykiwać niewidoczne iframe’y do fraudu reklamowego/click fraud i dodatkowego śledzenia,
  • wdrażać mechanizmy CAPTCHA bypass (co zwiększa możliwości automatyzacji nadużyć w przeglądarce).

Praktyczne konsekwencje / ryzyko

Dla użytkownika indywidualnego

  • Utrata prywatności: profilowanie aktywności przeglądania i zachowań zakupowych.
  • Ryzyko dalszej infekcji / nadużyć: skoro payload jest pobierany zdalnie, operator może zmieniać funkcje w czasie (np. dołożyć phishing/credential theft), nawet jeśli dziś dominuje monetyzacja reklamowo-afiliacyjna. (To wniosek wynikający z opisanego modelu “loader + aktualizowany payload”.)

Dla organizacji (enterprise)

  • Shadow IT w przeglądarce: rozszerzenia instalowane “na własną rękę” omijają standardowe procesy oceny ryzyka.
  • Osłabienie polityk bezpieczeństwa aplikacji webowych przez manipulację nagłówkami (CSP/HSTS/anty-clickjacking) – to potencjalny “force multiplier” dla innych ataków webowych.
  • Trudność detekcji: długie uśpienie, selektywne check-in’y i steganografia powodują, że klasyczne podejście “sprawdź pliki JS w paczce” może nie wystarczyć.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania (IR-lite)

  • Sprawdź i usuń podejrzane rozszerzenia – zwłaszcza te “utility”, które mają dużo instalacji, a nie są od rozpoznawalnego wydawcy. Lista kampanii (styczeń 2026) obejmuje m.in.:
    • Google Translate in Right Click (~522k), Translate Selected Text with Google (~159k), Ads Block Ultimate, Floating Player – PiP Mode, Youtube Download, Instagram Downloader i inne.
  • Zakładaj, że usunięcie ze sklepu ≠ usunięcie z endpointu: jeśli dodatek był zainstalowany, nadal może działać do czasu ręcznego odinstalowania.

2) Monitoring i hunting (blue team)

  • Wdróż przynajmniej podstawowy audit dodatków (inventory: nazwa, ID, wydawca, uprawnienia, data instalacji, źródło instalacji) w przeglądarkach zarządzanych.
  • Monitoruj ruch DNS/HTTP(S) pod kątem znanych wskaźników (na przykład domen C2 opisywanych przez Koi: liveupdt[.]com, dealctr[.]com).
  • Poluj na symptomy: nietypowe modyfikacje DOM, wstrzyknięte iframe’y, podejrzane żądania sieciowe z kontekstu rozszerzeń, anomalie w nagłówkach odpowiedzi (utrata CSP/X-Frame-Options).

3) Prewencja w organizacji

  • Allow-listing rozszerzeń + blokada instalacji “z wolnej ręki” (tam, gdzie to możliwe).
  • Zasada minimum uprawnień: rozszerzenie, które prosi o szeroki dostęp do wszystkich stron, powinno być traktowane jak komponent wysokiego ryzyka.
  • Rozważ narzędzia/telemetrię, które wykrywają zachowanie (a nie tylko sygnatury w kodzie) – LayerX wprost rekomenduje podejście behavior-based i regularny audit dodatków.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

GhostPoster wpisuje się w trend “malware jako rozszerzenie”: zamiast exploitować przeglądarkę, atakujący wykorzystują fakt, że dodatki mają szerokie uprawnienia i użytkownicy instalują je masowo. Koi zwraca uwagę, że szczególnie kuszące są “darmowe” rozszerzenia VPN i narzędzia rzekomo zwiększające prywatność – a w praktyce bywają nośnikiem telemetryki lub gorzej.

Na tle wielu kampanii wyróżnia się tu ukrywanie kodu w PNG oraz bardzo konsekwentne mechanizmy opóźnień i selektywnej aktywacji, które zwiększają szanse przetrwania w sklepach i w środowiskach produkcyjnych.

Podsumowanie / kluczowe wnioski

  • 840 tys. instalacji w wielu sklepach dodatków pokazuje, że to nie incydent niszowy, tylko problem skali.
  • GhostPoster to kampania “zaprojektowana pod unikanie detekcji”: steganografia w PNG, staging, opóźnienia, modularny payload.
  • W praktyce ryzyko dotyczy zarówno użytkowników (śledzenie/monetyzacja), jak i firm (shadow IT, osłabianie zabezpieczeń web, trudność detekcji).
  • Najskuteczniejsze podejście obronne to połączenie: inventory + polityki instalacji + monitoring zachowania rozszerzeń oraz szybkie usuwanie podejrzanych dodatków z endpointów.

Źródła / bibliografia

  1. BleepingComputer – “Malicious GhostPoster browser extensions found with 840,000 installs” (17.01.2026). (BleepingComputer)
  2. LayerX – “Browser Extensions Gone Rogue: The Full Scope of the GhostPoster Campaign” (15.01.2026). (LayerX)
  3. Koi Security – “Inside GhostPoster: How a PNG Icon Infected 50,000 Firefox Users” (16.12.2025). (koi.ai)
  4. TechRadar – omówienie kampanii GhostPoster i reakcji ekosystemu dodatków (12.2025). (TechRadar)

Publiczny exploit na krytyczną lukę w FortiSIEM: zdalne RCE bez uwierzytelnienia i droga do roota (CVE-2025-64155)

Wprowadzenie do problemu / definicja luki

Fortinet FortiSIEM (SIEM/UEBA) dostał krytyczną podatność umożliwiającą zdalne wykonanie poleceń/kodu bez uwierzytelnienia w wyniku błędnej neutralizacji elementów w wywołaniu komendy systemowej (CWE-78). Luka jest śledzona jako CVE-2025-64155 i – co najważniejsze operacyjnie – ma już upubliczniony PoC/exploit, co zwykle znacząco przyspiesza adopcję przez atakujących.

Uwaga porządkująca nazewnictwo: część publikacji nagłośniła temat pod wcześniejszym identyfikatorem CVE-2025-25256 (sierpień 2025). Badacze opisują jednak, że dalsza analiza doprowadziła do odkrycia nowej, łańcuchowej podatności i przypisania jej CVE-2025-64155.

W skrócie

  • Co to jest: zdalna, nieuwierzytelniona podatność prowadząca do RCE i w typowym scenariuszu do pełnej kompromitacji (root).
  • Gdzie: FortiSIEM – problem dotyczy usług komunikacyjnych phMonitor (wskazywany port TCP/7900 jako kluczowy punkt ekspozycji/mitigacji).
  • Wersje podatne (przykładowe zakresy): 6.7.0–6.7.10, 7.0.0–7.0.4, 7.1.0–7.1.8, 7.2.0–7.2.6, 7.3.0–7.3.4 oraz 7.4.0.
  • Status eksploitu: PoC opublikowany, brak potwierdzonych raportów o masowym „in-the-wild” w momencie publikacji analiz (ale ryzyko gwałtownie rośnie).
  • Najważniejsze działanie: patch/upgrade + natychmiastowe odcięcie dostępu do TCP/7900 z sieci niezaufanych.

Kontekst / historia / powiązania

Badacze z Horizon3.ai wskazują, że phMonitor był już historycznie „wejściem” do kilku podatności w FortiSIEM (wspominane m.in. CVE-2023-34992 i CVE-2024-23108), a zainteresowanie podatnościami Fortinetu bywa wysokie także po stronie grup ransomware (w kontekście FortiSIEM przywołano wątek zainteresowania w wyciekach czatów).

W praktyce to klasyczny wzorzec: produkt infrastrukturalny (SIEM) często stoi wysoko w zaufaniu sieciowym, a kiedy pojawia się RCE bez auth + PoC, czas do prób skanowania/ataku w internecie zwykle skraca się do godzin–dni.

Analiza techniczna / szczegóły luki

Z perspektywy technicznej, opis Horizon3.ai jest szczególnie istotny, bo pokazuje nie tylko „command injection”, ale łańcuch prowadzący do roota:

  1. Brak uwierzytelnienia do handlerów w phMonitor
    phMonitor mapuje dziesiątki handlerów operacji (komendy/typy żądań) i – kluczowo – część z nich jest dostępna zdalnie bez autoryzacji.
  2. Wejście przez obsługę żądania storage typu elastic
    W określonym przepływie parametry z payloadu (XML) trafiają do skryptu elastic_test_url.sh jako argumenty. Wprowadzono warstwę „utwardzania” (np. owijanie argumentów w cudzysłowy), ale…
  3. Argument injection do curl zamiast klasycznego command injection
    Skrypt buduje komendę curl, a następnie ją wykonuje. Badacze pokazują, że da się „wstrzyknąć” dodatkowe argumenty curl (np. zapis do pliku) – finalnie wykorzystując funkcję --next, która pozwala łańcuchować żądania w jednej instancji curl. To omija część ochrony wynikającej z cytowania argumentów.
  4. Arbitrary file write jako użytkownik uprzywilejowany (admin), a potem eskalacja do roota
    W demonstracji plik wykonywalny cyklicznie uruchamiany w systemie jest nadpisywany, co daje shell jako „admin”, a następnie wykorzystywany jest fakt, że pewne pliki wykonywane przez root są zapisywalne przez admin (np. skrypt uruchamiany z crona), co prowadzi do root.

Dodatkowo BleepingComputer zwraca uwagę na praktyczny trop detekcyjny: w logach phMonitor (/opt/phoenix/log/phoenix.logs) warto szukać wpisów zawierających m.in. PHL_ERROR i wskazania URL payloadu oraz docelowej ścieżki zapisu.

Praktyczne konsekwencje / ryzyko

Dlaczego to „pali się” bardziej niż typowa podatność?

  • Brak uwierzytelnienia + zdalny wektor sieciowy → niski próg ataku, szybka automatyzacja skanami.
  • PoC publicznie dostępny → rośnie prawdopodobieństwo masowych prób, nawet jeśli wcześniej brak było obserwacji „in-the-wild”.
  • FortiSIEM jako „high-trust asset”: kompromitacja SIEM to nie tylko RCE na serwerze – to często dostęp do integracji, kluczy, tokenów, poświadczeń do kolektorów i systemów logowania, a także idealny punkt do ruchu bocznego.

Rekomendacje operacyjne / co zrobić teraz

1) Patch/upgrade – priorytet P1

Zgodnie z dostępnymi zestawieniami wersji naprawionych:

  • 7.4: aktualizuj do 7.4.1+
  • 7.3: do 7.3.5+
  • 7.2: do 7.2.7+
  • 7.1: do 7.1.9+
  • Linie 6.7 i 7.0: rekomendowana migracja do wspieranej, naprawionej wersji (zamiast oczekiwania na łatkę).

2) Ogranicz ekspozycję phMonitor (TCP/7900) – natychmiast

Jeśli nie możesz zapatchować od razu, wdrożenie kontroli dostępu do portu 7900 (tylko z zaufanych segmentów/hostów) jest wskazywane jako workaround.

Minimalny baseline:

  • zablokuj TCP/7900 z Internetu i sieci użytkowników,
  • dopuść wyłącznie komunikację wymaganą topologią (kolektory ↔ supervisor),
  • dodaj alerty na nietypowe źródła ruchu do 7900.

3) Detekcja i triage

  • Przeszukaj logi: /opt/phoenix/log/phoenix.logs pod kątem anomalii i wzorców typu PHL_ERROR oraz podejrzanych ścieżek zapisu.
  • Sprawdź integralność/zmiany w lokalizacjach wskazywanych w analizie (przykładowo pliki nadpisywane w scenariuszu PoC) i wykonaj szybki hunting pod kątem „nagle zmienionych” plików wykonywalnych/skryptów.

4) Po incydencie lub podejrzeniu kompromitacji

  • rotacja kluczy/poświadczeń dostępnych z FortiSIEM (integracje, konta serwisowe, tokeny),
  • przegląd połączeń wychodzących (reverse shell / nietypowe egress),
  • weryfikacja cronów i plików uruchamianych cyklicznie.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Warto zwrócić uwagę na różnicę jakościową: wiele błędów klasy „OS command injection” to pojedynczy punkt wstrzyknięcia. Tutaj badacze opisują argument injection do curl + arbitralny zapis pliku + eskalację przez błędne uprawnienia plików wykonywanych przez roota. To podejście jest szczególnie „produkcyjne” dla atakujących, bo:

  • pozwala obejść część utwardzeń (cytowanie argumentów),
  • daje stabilny prymityw (write-what-where w granicach uprawnień),
  • łatwo przerobić na trwałość (persistencję) przez pliki wykonywane cyklicznie.

Podsumowanie / kluczowe wnioski

  • CVE-2025-64155 to krytyczna podatność FortiSIEM umożliwiająca unauth RCE i typowo root w wyniku łańcucha błędów/konfiguracji.
  • Publiczny exploit/PoC znacząco zwiększa presję na szybkie działania obronne.
  • Najważniejsze kroki: aktualizacja do wersji naprawionych + odcięcie/ograniczenie TCP/7900 + szybki hunting w logach phMonitor.

Źródła / bibliografia

  1. BleepingComputer – informacja o upublicznieniu exploitu/PoC, mitigacji (port 7900) i wskazówkach dot. logów. (BleepingComputer)
  2. Horizon3.ai – techniczny write-up łańcucha: phMonitor → elastic_test_url.sh → argument injection do curl → zapis pliku → eskalacja do roota. (Horizon3.ai)
  3. Tenable – podsumowanie ryzyka, kontekst oraz tabela wersji podatnych/naprawionych. (Tenable®)
  4. NVD (NIST) – opis CVE i zakresy podatnych wersji. (NVD)

Reprompt: jedno kliknięcie wystarczało, by przejąć sesję Microsoft Copilot i wyprowadzić dane

Wprowadzenie do problemu / definicja luki

„Reprompt” to opisany przez Varonis Threat Labs łańcuch ataku na Microsoft Copilot (wariant konsumencki: Copilot Personal), w którym napastnik mógł wstrzyknąć polecenie do Copilota przez legalny link i doprowadzić do cichej eksfiltracji danych po jednym kliknięciu. Kluczowy element: Copilot akceptował prompt przekazany w parametrze URL q i wykonywał go automatycznie po załadowaniu strony, co (w połączeniu z obejściami zabezpieczeń) umożliwiało działanie „w imieniu” zalogowanego użytkownika.

Microsoft załatał problem w aktualizacjach z 13 stycznia 2026 (Patch Tuesday), a według opisu nie ma potwierdzonych dowodów masowego wykorzystania „in the wild” w momencie publikacji.

W skrócie

  • Mechanizm wejścia: phishingowy (lub podsunięty innym kanałem) link do Copilota z ukrytym promptem w parametrze q.
  • Dlaczego to groźne: 1 klik, bez wtyczek/connectorów, a atak mógł utrzymywać sterowanie nawet po zamknięciu karty Copilota.
  • Trik na guardraile: tzw. double-request (polecenie wykonania tej samej akcji dwa razy) oraz chain-request (kolejne instrukcje pobierane z serwera atakującego).
  • Status: załatane przez Microsoft (Patch Tuesday 13.01.2026); Varonis podaje, że środowiska Microsoft 365 Copilot (enterprise) nie były objęte tym konkretnym scenariuszem.

Kontekst / historia / powiązania

Reprompt wpisuje się w szerszą klasę zagrożeń dla asystentów LLM: indirect prompt injection (pośrednie wstrzyknięcie poleceń), gdzie „instrukcje” dostarcza nie sam użytkownik, lecz dane z zewnątrz (np. link, treść strony, dokument). Microsoft wprost opisuje, że skutkiem takich ataków bywa m.in. eksfiltracja danych i wykonywanie niezamierzonych akcji z uprawnieniami użytkownika, dlatego promuje podejście „defense-in-depth” (m.in. izolowanie danych nieufnych, mechanizmy detekcji typu Prompt Shields, kontrola egress i governance).

Analiza techniczna / szczegóły luki

Varonis rozbił Reprompt na trzy kluczowe techniki, które razem tworzyły stabilny łańcuch eksfiltracji:

1) Parameter 2 Prompt (P2P) injection – q w URL

Copilot potrafił przyjąć prompt w parametrze q (np. copilot.microsoft.com/?q=<PROMPT>), a następnie automatycznie go wykonać po otwarciu strony. To „feature” UX-owy, ale jednocześnie gotowy wektor do nadużyć, bo ofiara widzi „legalny” link do usługi Microsoft.

2) Double-request technique – obejście guardrails przez „zrób to dwa razy”

Według opisu badaczy, zabezpieczenia Copilota (np. zasada „nie pobieraj URL bez uzasadnienia”, redakcja wrażliwych danych) w praktyce miały działać głównie dla pierwszego żądania. Badacze uzyskali obejście, każąc Copilotowi powtarzać akcję (wywołanie/fetch) dwukrotnie – w przykładzie część wrażliwa była usuwana w pierwszym podejściu, ale przechodziła w drugim.

3) Chain-request technique – sterowanie „z serwera” i eksfiltracja etapami

Najbardziej niebezpieczny element to „łańcuch” poleceń: po starcie z linku, Copilot był nakłaniany do pobrania kolejnych instrukcji z domeny atakującego (stage1 → stage2 → stage3…), a każda odpowiedź mogła być użyta do zbudowania następnego kroku. To utrudnia:

  • ocenę szkody przez ofiarę (pierwszy prompt nie ujawnia pełnej intencji),
  • detekcję po stronie klienta (bo „prawdziwe” polecenia przychodzą później),
  • ograniczenie ilości wykradanych informacji (ataker adaptuje pytania).

Co mogło wyciec?

W scenariuszach przytaczanych w opisie pojawiają się m.in. pamięć/konwersacje Copilota, kontekst konta i informacje osobiste (np. aktywność, lokalizacja, wątki rozmów), zależnie od tego, do czego Copilot ma dostęp w danym kontekście.

Praktyczne konsekwencje / ryzyko

Największe ryzyko operacyjne wynika z kombinacji: 1 klik + legalny link + „niewidoczna” kontynuacja ataku. W praktyce to:

  • phishing nowej generacji: użytkownik nie wpisuje promptu, nie instaluje wtyczek, nie „zezwala” jawnie — tylko otwiera URL.
  • wyciek danych trudny do odtworzenia: instrukcje mogą być dostarczane dopiero po rozpoczęciu sesji, więc analiza „co dokładnie poszło” jest trudna.
  • ryzyko reputacyjne i compliance (zwłaszcza jeśli w Copilocie lądują dane wrażliwe), bo prompt injection omija typowy model „użytkownik świadomie pyta”.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (IT/SecOps)

  1. Wymuś aktualizacje: upewnij się, że aktualizacje z 13.01.2026 i kolejne są wdrożone na stacjach (Windows/Edge i komponenty Copilota).
  2. Higiena linków i szkolenia: dodaj do awareness prosty pattern: link do Copilota z długim ?q=... to sygnał ostrzegawczy (nawet jeśli domena jest prawdziwa).
  3. Kontrola egress / proxy: łańcuch ataku wymaga komunikacji z infrastrukturą atakera (pobieranie kolejnych instrukcji / „fetch URL”). Ograniczaj i monitoruj nietypowe połączenia do świeżych domen, szczególnie gdy inicjują je procesy przeglądarki w kontekście sesji Copilota.
  4. Warstwy ochrony dla prompt injection: jeśli używasz rozwiązań Microsoft, rozważ mechanizmy z rodziny „Prompt Shields” i podejście defense-in-depth (izolowanie danych nieufnych, polityki dostępu, audyt, DLP).

Dla użytkowników

  • Aktualizuj system i przeglądarkę, a do Copilota wchodź z własnego skrótu, nie z linków z wiadomości.
  • Jeśli Copilot otwiera się z automatycznie wypełnionym promptem, przeczytaj go przed wykonaniem (właśnie na tym żeruje ten wektor).

Różnice / porównania z innymi przypadkami

  • Reprompt (ten przypadek): „one-click” przez URL q, nacisk na utrzymanie kontroli po starcie i „prompt chaining” z serwera.
  • Klasa indirect prompt injection ogólnie: atakujący „przemyca instrukcje” w danych wejściowych, a skutkiem często jest data exfiltration (np. przez generowanie URL-i/znaczników, wywołania narzędzi, itp.). Microsoft opisuje to jako trudne do wyeliminowania i wymagające wielu warstw obrony.

Podsumowanie / kluczowe wnioski

Reprompt pokazał, że nawet „wygodne” funkcje typu prefill prompt z URL mogą stać się krytycznym wektorem, jeśli da się je połączyć z obejściem guardrails (double-request) i sterowaniem sekwencyjnym (chain-request). Atak był szczególnie niebezpieczny, bo minimalizował sygnały dla użytkownika i utrudniał detekcję po stronie endpointu. Z perspektywy bezpieczeństwa to kolejny argument, by traktować asystentów AI jak nową powierzchnię ataku, wymagającą polityk, monitoringu i kontroli przepływu danych — nie tylko „ustawień prywatności”.

Źródła / bibliografia

  1. BleepingComputer — opis ataku i wektora q (14.01.2026). (BleepingComputer)
  2. Varonis Threat Labs — analiza Reprompt (P2P, double-request, chain-request; aktualizacja 14.01.2026). (varonis.com)
  3. Microsoft MSRC — „How Microsoft defends against indirect prompt injection attacks” (29.07.2025) – kontekst i defense-in-depth. (Microsoft)
  4. Malwarebytes — potwierdzenie łatki w Patch Tuesday i kontekst ryzyka (15.01.2026). (Malwarebytes)
  5. SecurityWeek — podsumowanie technik i skutków (15.01.2026). (securityweek.com)

Microsoft przejmuje serwery i rozbija RedVDS – jak działała abonamentowa platforma „cybercrime-as-a-service”

Wprowadzenie do problemu / definicja luki

RedVDS nie był „kolejnym botnetem” ani pojedynczą grupą APT. To model biznesowy: tani, abonamentowy dostęp do jednorazowych maszyn Windows, które cyberprzestępcy wykorzystywali jako infrastrukturę do phishingu, BEC (Business Email Compromise), przejęć kont i oszustw finansowych. Microsoft opisuje RedVDS jako element rosnącego ekosystemu cybercrime-as-a-service, gdzie przestępcy kupują gotowe usługi, zamiast budować zaplecze samodzielnie.

Klucz: taka „hurtowa” infrastruktura obniża próg wejścia. Za kwoty rzędu 24 USD/mies. można było uruchamiać operacje na skalę masową, płacąc kryptowalutami i redukując ślady.

W skrócie

  • Microsoft ogłosił skoordynowane działania prawne w USA oraz – po raz pierwszy w tym typie sprawy – w Wielkiej Brytanii, równolegle z operacją z udziałem organów ścigania (w tym niemieckich) i Europolu.
  • Przejęto kluczową infrastrukturę i zajęto dwie domeny obsługujące marketplace oraz portal klientów RedVDS.
  • Microsoft wiąże RedVDS z ok. 40 mln USD zgłoszonych strat w USA od marca 2025.
  • W „zaledwie jednym miesiącu” ponad 2 600 maszyn RedVDS wysyłało średnio 1 mln phishingowych wiadomości dziennie do klientów Microsoftu.
  • Od września 2025 aktywność wspierana przez RedVDS miała prowadzić do kompromitacji lub oszukańczego dostępu do ponad 191 tys. organizacji globalnie.

Kontekst / historia / powiązania

Z perspektywy obrony (SOC/CSIRT) RedVDS wpisuje się w trend „industrializacji” cyberprzestępczości: atakujący specjalizują się w wąskich fragmentach łańcucha (dostęp, phishing, pranie pieniędzy, infrastruktura), a resztę kupują w modelu usługowym.

Według Microsoft Threat Intelligence RedVDS działał publicznie od 2019 r., oferując serwery w wielu lokalizacjach (m.in. USA, UK, Kanada, Francja, Holandia, Niemcy) i używał kilku domen (m.in. redvds[.]com, redvds[.]pro, vdspanel[.]space).

Microsoft przypisuje rozwój i operowanie marketplace’em aktorowi śledzonemu jako Storm-2470 oraz wskazuje, że z infrastruktury korzystało wiele innych podmiotów (np. Storm-0259 i inne „Stormy”), co sugeruje, że RedVDS był „multitenantem” dla przestępców finansowych, a nie narzędziem jednej kampanii.

W komunikacji Microsoftu przewija się też wątek AI-enabled fraud: RedVDS miał być często łączony z generatywną AI do szybszego typowania celów i tworzenia bardziej wiarygodnych wątków korespondencji, a w części przypadków również z narzędziami deepfake (zamiana twarzy, manipulacja wideo, klonowanie głosu).

Analiza techniczna / szczegóły luki

1) „Disposable Windows” jako produkt

Rdzeniem oferty były tanie serwery Windows dostępne przez RDP z pełnymi uprawnieniami administratora i bez limitów użycia. To idealne środowisko do:

  • masowego wysyłania phishingu (w tym obejścia reputacji źródeł),
  • hostowania stron/landingów, paneli i kitów phishingowych,
  • prowadzenia BEC i „payment diversion” (podmiana rachunków, zmiana danych do przelewu),
  • przejęć kont i dalszego poruszania się po organizacjach.

2) „Palec odcisku” infrastruktury – klonowany obraz Windows

Microsoft opisuje ciekawy aspekt obronny: wiele instancji było tworzonych z jednego, klonowanego obrazu Windows Server 2022, co pozostawiało wykrywalne, powtarzalne artefakty. Przykład: ten sam computer name: WIN-BUNS25TD77J, widoczny m.in. w certyfikatach RDP i telemetrii. Legalni dostawcy chmury zwykle losują/unikalizują takie identyfikatory – tu tego zabrakło.

3) Automatyzacja provisioningu

Operator miał stosować QEMU i sterowniki VirtIO do szybkiego generowania klonów na żądanie klienta. Mechanika była prosta: kopiowanie „master VM” bez poprawnego sysprep/unikalizacji tożsamości systemu, co przyspieszało dostarczanie i obniżało koszty, ale jednocześnie zostawiało spójne ślady.

4) Warstwa utrudniania atrybucji

RedVDS sprzedawano z płatnością w kryptowalutach (Microsoft wymienia m.in. Bitcoin, Litecoin oraz szeroką listę innych) i z narracją o „podmiocie” rzekomo podlegającym prawu Bahamów – klasyczny zabieg zwiększający tarcie dla egzekwowania prawa i identyfikacji operatorów.

Praktyczne konsekwencje / ryzyko

Dlaczego ta historia jest ważna także dla organizacji, które „nie widzą” RedVDS u siebie? Bo usługi tego typu zmieniają ekonomię ataku:

  1. Skalowanie – atakujący nie muszą inwestować w własne serwery/botnety. W komunikacie Microsoftu pada skala: w jeden miesiąc 2 600 maszyn i średnio 1 mln phishingów dziennie do samych klientów Microsoftu.
  2. Szybka rotacja infrastruktury – „jednorazowe” maszyny można porzucić po kampanii, co utrudnia korelację i blokowanie per-IP.
  3. Lepszy social engineering – połączenie hostowanej infrastruktury + generatywnej AI (a czasem deepfake) zwiększa skuteczność BEC, szczególnie przy zmianach danych płatniczych.
  4. Straty finansowe – Microsoft wskazuje ok. 40 mln USD zgłoszonych strat w USA od marca 2025, a przykłady ofiar obejmują m.in. podmiot farmaceutyczny i wspólnotę mieszkaniową.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, które sensownie adresują ten typ zagrożeń (nie tylko RedVDS):

Dla zespołów IT/SOC

  • Wzmocnij polityki SPF/DKIM/DMARC i egzekwuj je (quarantine/reject), a w M365 dopnij ochrony anty-spoofingowe – Microsoft wskazuje, że aktorzy wykorzystywali złożone scenariusze routingu i błędne konfiguracje ochron.
  • Poluj na artefakty RDP/telemetrii: jeśli masz telemetryczne możliwości EDR/XDR, rozważ detekcje oparte o wskazane przez Microsoft charakterystyki klonów (np. powtarzalne elementy połączeń RDP/certyfikatów, fingerprint hosta).
  • Kontrola egress + reputacja: nie opieraj blokad wyłącznie o statyczne listy IP – przy „disposable infra” potrzebujesz korelacji zachowań (nietypowe logowania, masowe wysyłki, anomalie w OAuth).
  • Włącz i wymuś MFA odporne na phishing (FIDO2/passkeys, auth-app z number matching) na kontach uprzywilejowanych i finansowych. BEC to gra o przejęcie skrzynki i manipulację płatnością.

Dla finansów, zakupów i operacji

  • Proces „out-of-band verification”: każda zmiana numeru rachunku/beneficjenta musi być potwierdzona innym kanałem (telefon na znany numer, wideoweryfikacja, portal dostawcy).
  • Dwustopniowa autoryzacja przelewów i limity kwotowe z dodatkowymi kontrolami dla „pierwszego przelewu na nowy rachunek”.
  • Szkolenia na BEC oparte o realne scenariusze (pilne faktury, zmiany rachunku, „CEO fraud”) – RedVDS był wykorzystywany właśnie do takich schematów.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

RedVDS warto zestawić z wcześniejszymi „takedownami” w modelu usługowym:

  • Phishing-as-a-Service vs Infrastructure-as-a-Service: przejęcie paneli/phishing kitów (PhaaS) ogranicza „narzędzie”, ale infrastruktura w stylu RedVDS to uniwersalny mnożnik – obsłuży phishing, BEC, hosting scamów i wiele innych działań naraz.
  • Wielu aktorów, jedna platforma: Microsoft wprost wskazuje, że z RedVDS korzystały różne „Stormy”, więc uderzenie w usługę ma szansę ograniczyć działalność całego ekosystemu klientów.
  • Legal + technika: kluczowy jest miks działań prawnych (USA i UK) oraz zajęć infrastruktury/domen, bo bez przejęcia marketplace’u i panelu klienta atakujący zwykle po prostu migrują.

Podsumowanie / kluczowe wnioski

Rozbicie RedVDS pokazuje, że współczesna cyberprzestępczość coraz częściej działa jak SaaS: tanio, masowo i z automatyzacją. Dla obrońców najważniejsze są dwa wnioski:

  1. Nie walczysz tylko z „atakującym”, ale z jego łańcuchem dostaw. Uderzenie w infrastrukturę-usługę może obniżyć tempo i skalę wielu kampanii naraz.
  2. BEC i phishing nie znikną po jednym takedownie. Trzeba domykać procesy (weryfikacja płatności) i technikę (MFA odporne na phishing, ochrona przed spoofingiem, detekcje anomalii).

Źródła / bibliografia

  1. Microsoft – Microsoft disrupts global cybercrime subscription service… (14 stycznia 2026) (The Official Microsoft Blog)
  2. Microsoft Threat Intelligence – Inside RedVDS: How a single virtual desktop provider fueled worldwide cybercriminal operations (14 stycznia 2026) (Microsoft)
  3. BleepingComputer – Microsoft seizes servers, disrupts massive RedVDS cybercrime platform (15 stycznia 2026) (BleepingComputer)
  4. Microsoft News (EMEA, DE) – komunikat prasowy dot. RedVDS (styczeń 2026) (Source)
  5. CyberScoop – kontekst współpracy z organami ścigania i Europolem (14 stycznia 2026) (CyberScoop)

Wielka Brytania wszczyna formalne postępowanie wobec X za obrazy „nudify” generowane przez Grok: co oznacza śledztwo Ofcom i jakie są ryzyka

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 r. w X (dawniej Twitter) zaczęły krążyć doniesienia o generowaniu i rozpowszechnianiu niekonsensualnych, seksualizowanych obrazów (tzw. „nudify” – cyfrowe „rozbieranie” postaci na zdjęciach) z użyciem narzędzi powiązanych z Grok, asystentem AI zintegrowanym z platformą. W odpowiedzi brytyjski regulator rynku łączności i bezpieczeństwa online – Ofcom – uruchomił formalne postępowanie wobec X na podstawie brytyjskiej Online Safety Act.

W praktyce nie chodzi o „lukę” w sensie CVE, lecz o nadużycie funkcji generatywnej AI połączone z potencjalnymi brakami w moderacji, ocenie ryzyka i mechanizmach ochrony małoletnich. Ofcom wprost wskazuje, że bada zgodność działań X z obowiązkami dotyczącymi ochrony użytkowników w Wielkiej Brytanii przed treściami nielegalnymi.

W skrócie

  • Ofcom wszczął formalne dochodzenie wobec X w związku z „poważnymi doniesieniami” o generowaniu i udostępnianiu seksualizowanych obrazów (w tym dotyczących dzieci) przy użyciu Grok.
  • Równolegle ICO (brytyjski organ ochrony danych) poinformował, że kontaktował się z X i xAI, by wyjaśnić środki zgodności z prawem ochrony danych i ochrony praw osób.
  • Rząd (DSIT) publicznie wezwał do szybkich działań wobec narzędzi umożliwiających tworzenie intymnych deepfake’ów.
  • To sygnał, że generatywne AI w social media wchodzi w etap twardej egzekucji wymogów: governance, oceny ryzyka, ograniczeń funkcji i ochrony dzieci – nie tylko „deklaracji zasad”.

Kontekst / historia / powiązania

Ofcom działa w ramach Online Safety Act, która nakłada na platformy obowiązki dotyczące m.in. ograniczania ryzyk i reagowania na treści nielegalne (szczególnie w obszarze ochrony dzieci). W tle jest rosnąca presja regulacyjna na platformy, które integrują generatywne modele AI bez wystarczających barier nadużyć.

Warto też zauważyć „dwutorowość” reakcji w UK:

  • Ofcom patrzy na bezpieczeństwo online i zgodność z obowiązkami platformy (dystrybucja/ekspozycja treści, procesy ochrony).
  • ICO patrzy na zgodność z prawem ochrony danych (w tym, czy są odpowiednie środki i podstawy prawne przetwarzania danych oraz ochrona praw osób).

To ważne dla firm: nawet jeśli „problemem” jest treść, konsekwencje mogą rozlać się na compliance, audyt danych, DPIA/ocenę skutków, logowanie zdarzeń i raportowanie.

Analiza techniczna / szczegóły zjawiska (bez instruktażu nadużyć)

Mechanizm nadużyć w takich przypadkach zwykle ma trzy warstwy:

  1. Warstwa funkcji: generowanie/edycja obrazów (tekst→obraz lub obraz→obraz) z możliwością „stylizacji” czy modyfikacji sylwetki. Im bardziej „uniwersalne” narzędzie, tym większa powierzchnia nadużyć.
  2. Warstwa obejść: użytkownicy testują granice filtrów (prompt-abuse), wykorzystują eufemizmy, wieloetapowe polecenia lub łączą generowanie z zewnętrznymi narzędziami. To powoduje, że proste blacklisty słów są niewystarczające – potrzebne są detektory semantyczne i moderacja multimediów (po wejściu i po wyjściu).
  3. Warstwa dystrybucji: nawet jeśli model generuje „tylko” część treści, kluczowa jest skala i szybkość rozchodzenia się materiałów na platformie. Ofcom bada właśnie, czy X prawidłowo ogranicza ryzyko i reaguje na treści, które mogą być nielegalne w UK.

W komunikacie Ofcom istotne jest to, że mówimy o formalnym postępowaniu (nie „monitoringu”), co zwykle oznacza oczekiwanie twardych dowodów: polityk, ocen ryzyka, skuteczności kontroli, wskaźników egzekucji, czasu reakcji i zdolności do ochrony małoletnich.

Praktyczne konsekwencje / ryzyko

Dla platform i dostawców AI

  • Ryzyko regulacyjne i finansowe (kary, nakazy naprawcze, ograniczenia funkcji, presja na „safety by design”). W debacie publicznej w UK pada też temat najsurowszych środków wobec platform w skrajnych przypadkach.
  • Ryzyko reputacyjne: wątek „AI-nudify” jest społecznie wyjątkowo wrażliwy, bo dotyczy przemocy seksualnej o charakterze wizerunkowym i ochrony dzieci.

Dla organizacji (pracodawców, szkół, administracji)

  • Impersonation i szantaż (sextortion/blackmail): materiały mogą być używane do nacisku na pracowników lub osoby publiczne.
  • Incydenty HR i prawne: rozpowszechnianie takich treści w kanałach firmowych, grupach czy czatach może natychmiast eskalować do incydentu bezpieczeństwa + naruszenia dóbr osobistych.

Dla użytkowników

  • Krzywda osobista i wtórna wiktymizacja (zwłaszcza przy masowej dystrybucji).
  • Trwałość cyfrowa: kopie w sieci, mirrorowanie i re-upload utrudniają pełne usunięcie.

Rekomendacje operacyjne / co zrobić teraz

Jeśli zarządzasz platformą, aplikacją lub wdrażasz generatywne AI

  1. Dwuetapowa moderacja: kontrola wejścia (prompty, obrazy źródłowe) + kontrola wyjścia (detekcja nagości/CSAM-risk, detekcja niekonsensualnej seksualizacji).
  2. Twarde ograniczenia funkcji wysokiego ryzyka: ograniczanie/wyłączanie „image editing” w scenariuszach podatnych na „nudify”, zwłaszcza bez silnego age-gating.
  3. Ocena ryzyka i dowody zgodności: przygotuj artefakty pod regulatora (risk assessment, testy red-team, metryki skuteczności filtrów, czasy reakcji, proces eskalacji). Ofcom wprost bada zgodność z obowiązkami OSA.
  4. Privacy/compliance: skoordynuj z zespołem ochrony danych – ICO już komunikuje, że oczekuje wyjaśnień dot. środków zgodności i ochrony praw osób.

Jeśli odpowiadasz za bezpieczeństwo w firmie

  • Zaktualizuj polityki AUP i komunikację: zakaz generowania/udostępniania treści niekonsensualnych, jasne ścieżki zgłaszania.
  • Dodaj do ćwiczeń IR scenariusz: „deepfake/AI-nudify pracownika + dystrybucja w social media”.
  • Przygotuj gotowe wzory: notice-and-takedown, eskalacja do platformy, zabezpieczenie dowodów, kontakt z prawnikiem/PR.

Jeśli jesteś użytkownikiem lub administratorem społeczności

  • Zgłaszaj treści i konta, archiwizuj dowody (linki, daty, zrzuty) na wypadek dochodzenia.
  • Ogranicz ekspozycję zdjęć (zwłaszcza dzieci) w publicznych profilach; rozważ watermarking wizerunkowy dla materiałów publikowanych oficjalnie.

Różnice / porównania z innymi przypadkami

To postępowanie jest charakterystyczne, bo regulator platform (Ofcom) wchodzi w obszar, który wielu kojarzy wyłącznie z „AI safety” i politykami modeli. UK pokazuje podejście: nawet jeśli źródłem jest generatywne AI, odpowiedzialność dotyka też dystrybucji i governance platformy.

Równoległa aktywność ICO podbija jeszcze jeden trend: generatywna funkcja w social media może uruchomić jednocześnie reżim bezpieczeństwa online i reżim ochrony danych.

Podsumowanie / kluczowe wnioski

  • Ofcom formalnie bada X pod kątem obowiązków z Online Safety Act po doniesieniach o seksualizowanych obrazach generowanych z użyciem Grok.
  • To nie „jednorazowy skandal”, tylko sygnał wejścia w etap egzekwowania bezpieczeństwa generatywnego AI w platformach: ryzyko, dowody, metryki, ograniczenia funkcji.
  • Firmy wdrażające generatywne obrazy powinny traktować ten przypadek jako wzorzec: moderacja multimodalna, safety-by-design, audyt i gotowość regulacyjna.
  • Równoległe działania ICO sugerują, że konsekwencje mogą obejmować także obszar danych osobowych i praw osób, a nie tylko moderację treści.

Źródła / bibliografia

  1. Ofcom – komunikat o wszczęciu formalnego dochodzenia (12 stycznia 2026). (www.ofcom.org.uk)
  2. The Record – opis sprawy i tło skarg dot. „nudification”. (The Record from Recorded Future)
  3. ICO – oświadczenie ws. Grok AI na X i kontaktu z X/xAI (styczeń 2026). (ICO)
  4. GOV.UK / DSIT – stanowisko Technology Secretary ws. narzędzia Grok do generowania/edycji obrazów (9 stycznia 2026). (GOV.UK)
  5. Financial Times – kontekst dochodzenia Ofcom i presji regulacyjnej. (Financial Times)

Pig Butchering-as-a-Service: jak „dostawcy usług” industrializują oszustwa inwestycyjne i romance baiting

Wprowadzenie do problemu / definicja luki

„Pig butchering” (chiń. sha zhu pan) to klasa oszustw, w których przestępcy budują relację (romantyczną lub „biznesową”), a potem przekonują ofiarę do inwestycji na fałszywej platformie (często pseudo-krypto/forex). Coraz częściej to już nie „pojedynczy scammerzy”, tylko zorganizowana gospodarka usługowa: Pig Butchering-as-a-Service (PBaaS) — zestaw gotowych narzędzi, szablonów, danych i infrastruktury, które można po prostu kupić i wdrożyć jak SaaS.

To ważna zmiana: bariera wejścia spada, a skala rośnie, bo „obsługa” oszustwa rozkłada się na wyspecjalizowanych dostawców (dane, konta, SIM, płatności, CRM, fałszywe platformy inwestycyjne, aplikacje mobilne, spółki-wydmuszki).

W skrócie

  • Badacze opisali dwie kluczowe kategorie dostawców PBaaS: (1) „marketplace” z danymi, kontami i materiałami do socjotechniki oraz (2) platformy CRM do zarządzania agentami i ofiarami (w tym panele admina, KYC, metryki „rentowności”).
  • Przykładowy „stack” PBaaS obejmuje m.in. skradzione dane PII, konta w serwisach społecznościowych, SIM-y, routery 4G/5G, IMSI catchery, zestawy zdjęć person („character sets”), a nawet moduły płatności P2P.
  • Infoblox wskazuje, że szablon strony z hostingiem może kosztować ok. 50 USD, a „pełny pakiet” (www + admin + VPS + aplikacja mobilna + dostęp do platformy tradingowej + rejestracja spółki w raju podatkowym + „rejestracja” u regulatora) startuje od ok. 20 000 juanów (~2 500 USD).
  • Równolegle widzimy „infrastrukturę-akcelerator” dla cyberprzestępczości: parkowane domeny i mechanizmy reklamowe/redirectów (direct search/zero-click), które w eksperymentach >90% czasu prowadzą do scamów, scareware lub malware.

Kontekst / historia / powiązania

Industrializacja i geografia

Według analiz Infoblox, w Azji Południowo-Wschodniej powstały setki „centrów scamowych” wspieranych praniem pieniędzy i handlem ludźmi; PBaaS jest jednym z motorów, który pozwala takim operacjom szybko się skalować bez dużego zaplecza technicznego po stronie „operatorów linii”.

„Words matter”: pig butchering vs romance baiting

INTERPOL zwraca uwagę, że sama nazwa „pig butchering” może stygmatyzować ofiary i zniechęcać do zgłaszania. Organizacja promuje termin „romance baiting”, który przenosi ciężar z „etykietowania” poszkodowanych na opis taktyk sprawców.

Analiza techniczna / szczegóły „luki” (PBaaS jako łańcuch dostaw)

Warto patrzeć na PBaaS jak na łańcuch dostaw cyberoszustwa: od pozyskania danych i tożsamości, przez kanały dotarcia, po platformę „inwestycyjną” i wypłatę/transfer środków.

1. „Penguin Account Store” — hurtownia zasobów do socjotechniki

Infoblox opisuje aktora działającego pod nazwami m.in. Heavenly Alliance / Overseas Alliance / Penguin Account Store, który sprzedaje „fraud kity”, szablony i komponenty potrzebne do uruchomienia oszustwa.

Kluczowe elementy oferty:

  • shè gōng kù — bazy PII (m.in. dane finansowe, historia podróży, informacje o rodzinie), wykorzystywane do selekcji „wartościowych” ofiar i budowania wiarygodności w rozmowie („znam ostatnie transakcje”).
  • skradzione konta (np. serwisy społecznościowe, komunikatory, konta deweloperskie) — tanie wejście w „zaufane” kanały kontaktu; Infoblox wskazuje, że konta mogą zaczynać się od ok. 0,10 USD.
  • sprzęt i telekom-enablers: pre-rejestrowane SIM-y, routery 4G/5G, IMSI catchery, a także „character sets” — paczki zdjęć (kradzione z social mediów) do spójnego budowania persony.
  • SCRM AI — platforma typu Social CRM do automatyzacji interakcji i „obsługi” ofiar w social mediach (Infoblox zastrzega, że nie wiadomo, ile tam faktycznie AI).
  • BCD Pay / Bochuang Guarantee — komponent płatności P2P powiązany (wg badaczy) z ekosystemem nielegalnego hazardu, co jest typowym „mostem” do prania i rozproszenia przepływów.

Wniosek obronny: Penguin działa jak „hurtownia części zamiennych” dla scamu — zasoby, które kiedyś wymagały kradzieży/operacji własnych, są dostępne w modelu marketplace.

2. „UWORK CRM” — panel dowodzenia operacją i skalowanie „agentów”

Drugą klasą dostawców są platformy CRM do zarządzania treścią, agentami i ofiarami. Infoblox opisuje sprzedawcę UWORK, od którego badacze pozyskali dostęp do CRM i przeanalizowali workflow.

Co jest istotne technicznie:

  • Panel admina oferuje szablony dla różnych narracji (krypto/forex/złoto), wielojęzyczność, integracje z e-mailem/Telegramem, a nawet geofencing (ograniczanie dostępu po IP, by utrudnić działania organów ścigania w „ryzykownych” jurysdykcjach).
  • „Legal-look” przez KYC: ofiara wgrywa dokumenty „weryfikacyjne”, co zwiększa zaufanie — i jednocześnie tworzy wtórne ryzyko nadużyć tożsamości.
  • Role i kontrola finansów: „pierwsza linia” agentów ma ograniczenia, a system może automatycznie eskalować depozyty i przenosić środki do kont poza zasięgiem agentów (ochrona „organizacji” przed defraudacją wewnętrzną).
  • Infoblox opisuje też element „udawanej wiarygodności” poprzez integracje z rozpoznawalnymi platformami tradingowymi (np. MetaTrader) i prezentację danych „w czasie rzeczywistym”.

3. Ekonomia PBaaS: dlaczego to rośnie?

PBaaS ma logikę klasycznego „crimeware-as-a-service”: niskie koszty startu, modułowość, szybkie kopiowanie kampanii.

Infoblox podaje twarde liczby:

  • ~50 USD za prosty szablon strony z hostingiem,
  • ~2 500 USD za „pełny pakiet” (www+admin, VPS, aplikacja, platforma tradingowa, spółka-wydmuszkowa, „rejestracja”).

Praktyczne konsekwencje / ryzyko

Dla osób prywatnych

  • Wiarygodność „na sterydach”: oszuści dysponują PII, spójnymi personami (zdjęcia/filmy), oraz dopracowanymi platformami „inwestycyjnymi”.
  • Wtórne szkody: przekazane dokumenty KYC, selfie, skany — mogą być odsprzedane i użyte w kolejnych oszustwach, przejęciach kont lub do „otwierania” rachunków-słupów.

Dla firm (w tym fintech, telekom, e-commerce)

  • Nadużycia tożsamości / fraud rosną, bo PBaaS dostarcza masowo konta, SIM-y i treści.
  • Ryzyko domenowe i reklamy: parkowane domeny + „direct search/zero-click” stają się kanałem dystrybucji scamów i malware. Infoblox pokazuje scenariusze, gdzie ta sama domena „dla skanera” wygląda niewinnie, a użytkownika mobilnego kieruje wprost na oszustwo; w ich eksperymentach to >90% przypadków.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team (organizacje)

  1. DNS i domeny
    • Włącz monitoring typosquattingu/look-alike domen dla brandu oraz domen krytycznych (logowanie, SSO, płatności).
    • Zasil polityki blokowania (Secure DNS / RPZ / SWG) o feedy scam/malvertising; traktuj parkowane domeny jako „domyślnie podejrzane” w ruchu użytkowników.
  2. Ochrona kanałów dotarcia
    • Zaostrz polityki przeciw przejęciom kont (MFA phishing-resistant gdzie to możliwe, anomalia logowań, kontrola nowych urządzeń).
    • Uważaj na „zaufane” kanały: WhatsApp/Telegram/IG/FB — PBaaS sprzedaje gotowe konta i persony.
  3. Procedury antyfraud / KYC
    • Traktuj „KYC-like” prośby poza zaufanym procesem jako sygnał incydentu (zwłaszcza gdy pojawiają się w kampaniach phishing/social).
    • Edukuj helpdesk i zespoły biznesowe: „platforma inwestycyjna + nacisk na szybki depozyt + kontakt relacyjny” to typowy wzorzec.

Dla użytkowników (praktyka)

  • Weryfikuj platformy inwestycyjne: domena, podmiot, licencja, opinie regulatorów — i pamiętaj, że PBaaS potrafi „udawać” rejestrację/wiarygodność.
  • Nie instaluj APK „z linku” ani profili/prowizjonowania na iOS z nieznanych źródeł — PBaaS aktywnie używa aplikacji mobilnych jako części scamu.
  • Jeśli relacja online szybko przechodzi w „wspólne inwestowanie”, a druga strona ma gotowy „panel” i presję czasu — traktuj to jako wysokie ryzyko. (To sedno romance baiting/pig butchering.)

Różnice / porównania z innymi przypadkami

PBaaS to ten sam kierunek, co MaaS/PhaaS, ale z innym „produktem końcowym”:

  • w MaaS sprzedaje się malware i dostęp,
  • w PBaaS sprzedaje się kompletną fabrykę oszustwa: dane + persony + kanały + platforma + płatności + operacyjny CRM.

Dodatkowo, infrastruktura reklamowo-domenowa (parkowanie + direct search) pełni rolę „ruchu na żądanie” dla scamów, analogicznie do botnetów-as-a-service w innych ekosystemach cyberprzestępczych.

Podsumowanie / kluczowe wnioski

  • Najgroźniejsza cecha PBaaS to industrializacja: gotowe komponenty sprawiają, że oszustwo staje się powtarzalnym procesem biznesowym, a nie „sztuką” pojedynczych sprawców.
  • „Dostawcy” jak Penguin (dane/konta/persony/płatności) oraz UWORK (CRM i panele operacyjne) pokazują, że obrona nie może skupiać się wyłącznie na „końcowych domenach” scamu — trzeba uderzać w enablers: infrastrukturę, płatności, domeny, dystrybucję.
  • Równolegle rośnie rola „szarej” infrastruktury internetowej (parkowane domeny i łańcuchy reklamowe), która utrudnia atrybucję i zwiększa zasięg kampanii.

Źródła / bibliografia

  • The Hacker News (12 stycznia 2026): opis dostawców PBaaS i kontekstu ekosystemu (The Hacker News)
  • Infoblox Threat Intel (8 stycznia 2026): „Scaling the Fraud Economy: Pig Butchering as a Service” — Penguin, UWORK, kosztorys, mechanika CRM (Infoblox)
  • Infoblox Threat Intel (16 grudnia 2025): „Parked Domains Become Weapons with Direct Search Advertising” — >90% przekierowań do złośliwych treści, profilowanie odwiedzających (Infoblox)
  • INTERPOL (17 grudnia 2024): „romance baiting” jako termin i wpływ języka na zgłaszalność (interpol.int)
  • Malanta (3 grudnia 2025): analiza infrastruktury „na poziomie APT” w ekosystemie domen/malware/hijackingu (kontekst przemysłowej skali) (malanta.ai)

UE uruchamia konsultacje ws. open source: „Europejskie Otwarte Ekosystemy Cyfrowe” jako odpowiedź na zależność od Big Tech

Wprowadzenie do problemu / definicja inicjatywy

Komisja Europejska rozpoczęła konsultacje publiczne („Call for Evidence”) dotyczące inictywy „Towards European Open Digital Ecosystems” – w praktyce: przygotowania strategii, która ma potraktować open source jako kluczową infrastrukturę cyfrową UE (a nie tylko „miły dodatek”) i ograniczać strategiczną zależność od dostawców spoza Europy.

Wątki cyberbezpieczeństwa są tu centralne: KE wprost wiąże zależność technologiczno-dostawczą z ryzykami łańcucha dostaw (supply chain), odpornością oraz zdolnością do zarządzania podatnościami.

W skrócie

  • Konsultacje trwają od 6 stycznia do 3 lutego 2026 r. i mają zasilić komunikat KE planowany na I kwartał 2026 r.
  • Inicjatywa obejmuje m.in. cloud, AI, cyberbezpieczeństwo, open hardware oraz zastosowania przemysłowe (np. automotive i produkcję).
  • KE podkreśla, że większość współczesnego oprogramowania bazuje na komponentach OSS (rzędu 70–90% linii kodu) – co czyni z open source element krytyczny dla gospodarki i bezpieczeństwa.
  • Równolegle rośnie presja na utrzymanie i finansowanie infrastruktury OSS (rejestry pakietów, CI/CD, dystrybucja), co ma bezpośrednie przełożenie na ryzyko w łańcuchu dostaw.

Kontekst / historia / powiązania

KE zapowiada przegląd dotychczasowego podejścia (w tym wcześniejszych działań i strategii 2020–2023), ale akcent przesuwa się z „używamy i dzielimy się kodem w instytucjach” na zbudowanie ekosystemu zdolnego do skalowania, utrzymania i monetyzacji rozwiązań OSS w Europie – z naciskiem na suwerenność, konkurencyjność i bezpieczeństwo.

W tle jest też rosnąca dyskusja o finansowaniu „cyfrowej infrastruktury publicznej”. GitHub (jako platforma ekosystemu) promował w 2025 r. koncepcję Europejskiego Sovereign Tech Fund jako mechanizmu finansowania utrzymania krytycznych zależności open source (w tym inwestycji w bezpieczeństwo).

Analiza techniczna / szczegóły inicjatywy

Z perspektywy cyberbezpieczeństwa „European Open Digital Ecosystems” dotyka trzech twardych warstw ryzyka:

1) Łańcuch dostaw software’u (supply chain) i przejrzystość zależności
KE wskazuje, że open source może zwiększać kontrolę nad stosem technologicznym, wspierać przejrzystość łańcucha dostaw i zarządzanie podatnościami (bo komponenty są audytowalne i weryfikowalne).

2) Utrzymanie i „zdolność operacyjna” OSS
Statystyka 70–90% udziału OSS w kodzie produkcyjnym oznacza, że realnym problemem nie jest „czy używamy OSS”, tylko czy potrafimy nim zarządzać (utrzymanie, aktualizacje, CVE, procesy wydawnicze, governance, odpowiedzialność).

3) Infrastruktura ekosystemu (rejestry pakietów, CI/CD, dystrybucja) jako punkt krytyczny
OpenSSF (fundacja skoncentrowana na bezpieczeństwie OSS) opisała publiczne rejestry pakietów i powiązane usługi jako fundament globalnego łańcucha dostaw, podkreślając narastające obciążenia: automatyczne CI, masowe skanery zależności, buildy kontenerowe oraz dodatkową falę ruchu generowaną przez narzędzia AI/agentów. To tworzy ryzyko „kruchości infrastruktury”, które wprost przekłada się na dostępność i bezpieczeństwo całych ekosystemów.

KE w samym „Call for Evidence” pyta interesariuszy m.in. o: bariery adopcji bezpiecznego OSS, modele biznesowe i działania UE, obszary technologiczne do priorytetyzacji oraz sektory, gdzie OSS może poprawić konkurencyjność i cyberodporność.

Praktyczne konsekwencje / ryzyko

Dla organizacji (publicznych i prywatnych) w UE:

  • Możliwe przesunięcie w zamówieniach publicznych i regulacjach w stronę preferowania rozwiązań otwartych / interoperacyjnych, ale też większego nacisku na dowody utrzymania i bezpieczeństwa (a nie sam fakt „open source”).
  • Rosnące znaczenie „higieny supply chain”: inwentaryzacja OSS, SBOM, proces aktualizacji, polityki kontrybucji upstream, ocena ryzyka „single maintainer / bus factor”.

Dla dostawców i maintainersów:

  • Szansa na wsparcie skalowania (nie tylko granty R&D), ale też presja na profesjonalizację utrzymania: SLA, security posture, procesy disclosure, CI hardening.

Dla bezpieczeństwa ekosystemu:

  • Jeśli problem finansowania i utrzymania infrastruktury OSS nie zostanie rozwiązany systemowo, rośnie ryzyko „wąskich gardeł” (availability, integralność dystrybucji, opóźnione patche), które uderzają w całe łańcuchy zależności.

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś CISO, architektem, liderem DevSecOps albo odpowiadasz za zakupy IT – warto potraktować tę inicjatywę jako „okno wpływu” na zasady gry w UE.

1) Weź udział w konsultacjach – merytorycznie, nie marketingowo
KE wprost prosi o przykłady barier i działań, które realnie poprawią adopcję i bezpieczeństwo OSS. Jeśli w Twojej organizacji „boli” procurement, compliance, brak ludzi do utrzymania, wymagania audytowe – to jest moment, by to opisać.

2) Zrób przegląd krytycznych zależności OSS (nie tylko aplikacji, też narzędzi i pipeline’u)
Skup się na: komponentach runtime, build chain, rejestrach, obrazach bazowych, narzędziach CI/CD, podpisywaniu artefaktów.

3) Wzmocnij praktyki supply chain security

  • SBOM + automatyczna walidacja w pipeline
  • polityka aktualizacji i „time-to-patch” dla krytycznych bibliotek
  • kontrola pochodzenia artefaktów (podpisy, weryfikacja, repozytoria proxy/cache)
  • minimalizacja „wasteful traffic” do publicznych rejestrów (cache, throttling) – to jest zarówno koszt, jak i ryzyko dostępności

4) Kontrybuuj upstream i/lub finansuj utrzymanie zależności
Z perspektywy ryzyka operacyjnego często taniej jest sfinansować utrzymanie krytycznej biblioteki niż ponosić koszty incydentu lub nagłej migracji.

5) Przygotuj się na „open source jako infrastruktura krytyczna”
To oznacza, że w rozmowach z dostawcami i w wewnętrznych standardach warto wymagać: jasnego modelu utrzymania, procesu reagowania na podatności, transparentnego governance i planu ciągłości.

Różnice / porównania z innymi przypadkami

  • KE 2026 vs podejście „instytucjonalne”: w dokumentach widać przejście od skupienia na wewnętrznym współdzieleniu kodu do narracji o ekosystemie rynkowym i „foundation infrastructure” w interesie strategicznym UE.
  • Model funduszu suwerenności (GitHub / inspiracja niemiecka): GitHub argumentuje za funduszem, który finansuje utrzymanie i bezpieczeństwo krytycznych zależności (z designem minimalizującym biurokrację). To podejście „infrastrukturalne” jest spójne z kierunkiem KE, choć nie przesądza o tym, jak UE to wdroży.
  • OpenSSF: infrastruktura rejestrów jako „cichy single point of failure”: list OpenSSF mocno akcentuje obciążenia (CI, skanery, AI) i potrzebę modeli finansowania proporcjonalnych do użycia – to ważne tło dla europejskich planów wzmacniania OSS.

Podsumowanie / kluczowe wnioski

UE próbuje ująć open source w ramy strategicznej infrastruktury, łącząc temat suwerenności technologicznej z bardzo praktycznymi problemami cyberbezpieczeństwa: kontrolą zależności, przejrzystością supply chain i zdolnością do utrzymania krytycznych komponentów.

Najważniejsze: to nie jest debata „open vs closed”, tylko „czy potrafimy skalować i zabezpieczać to, z czego i tak wszyscy korzystamy”. A konsultacje do 3 lutego 2026 r. są realną szansą, by branża wpłynęła na narzędzia (finansowanie, procurement, zachęty do upstream), które zdecydują o odporności europejskiego ekosystemu na lata.

Źródła / bibliografia

  1. Komisja Europejska / EUR-Lex – Call for Evidence: Towards European Open Digital Ecosystems (Ares(2026)69111) (EUR-Lex)
  2. The Register – Brussels plots open source push to pry Europe off Big Tech (The Register)
  3. Help Net Security – European Commission opens consultation on EU digital ecosystems (Help Net Security)
  4. GitHub Blog – We need a European Sovereign Tech Fund (The GitHub Blog)
  5. OpenSSF – Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship (openssf.org)