Archiwa: AI - Strona 165 z 175

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:

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.
Szybka rotacja infrastruktury – „jednorazowe” maszyny można porzucić po kampanii, co utrudnia korelację i blokowanie per-IP.
Lepszy social engineering – połączenie hostowanej infrastruktury + generatywnej AI (a czasem deepfake) zwiększa skuteczność BEC, szczególnie przy zmianach danych płatniczych.
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:

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.
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

Microsoft – Microsoft disrupts global cybercrime subscription service… (14 stycznia 2026) (The Official Microsoft Blog)
Microsoft Threat Intelligence – Inside RedVDS: How a single virtual desktop provider fueled worldwide cybercriminal operations (14 stycznia 2026) (Microsoft)
BleepingComputer – Microsoft seizes servers, disrupts massive RedVDS cybercrime platform (15 stycznia 2026) (BleepingComputer)
Microsoft News (EMEA, DE) – komunikat prasowy dot. RedVDS (styczeń 2026) (Source)
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:

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ć.
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).
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

Dwuetapowa moderacja: kontrola wejścia (prompty, obrazy źródłowe) + kontrola wyjścia (detekcja nagości/CSAM-risk, detekcja niekonsensualnej seksualizacji).
Twarde ograniczenia funkcji wysokiego ryzyka: ograniczanie/wyłączanie „image editing” w scenariuszach podatnych na „nudify”, zwłaszcza bez silnego age-gating.
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.
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

Ofcom – komunikat o wszczęciu formalnego dochodzenia (12 stycznia 2026). (www.ofcom.org.uk)
The Record – opis sprawy i tło skarg dot. „nudification”. (The Record from Recorded Future)
ICO – oświadczenie ws. Grok AI na X i kontaktu z X/xAI (styczeń 2026). (ICO)
GOV.UK / DSIT – stanowisko Technology Secretary ws. narzędzia Grok do generowania/edycji obrazów (9 stycznia 2026). (GOV.UK)
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)

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.
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.
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

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

Hakerzy polują na źle skonfigurowane proxy, żeby „za darmo” korzystać z płatnych LLM (OpenAI, Anthropic, Gemini i inne)

Wprowadzenie do problemu / definicja luki

Wraz z boomem na GenAI, wiele firm stawia „bramki” (reverse proxy, API gateway, internal proxy) przed modelami językowymi — żeby ujednolicić dostęp, logować ruch, ukryć klucze API albo kierować zapytania do różnych dostawców. Problem zaczyna się wtedy, gdy takie proxy jest wystawione do internetu bez odpowiedniej kontroli dostępu (albo ma zbyt liberalną konfigurację routingu). W praktyce staje się otwartą furtką: każdy może wysyłać żądania, a rachunek i limity zużywa właściciel infrastruktury.

Na początku stycznia 2026 r. GreyNoise opisało kampanie, w których aktorzy (w tym prawdopodobnie „szarzy” researcherzy, ale też profesjonalny threat actor) masowo skanowali i testowali endpointy powiązane z LLM-ami, polując właśnie na takie błędy konfiguracyjne.

W skrócie

GreyNoise zarejestrowało 91 403 sesje ataków na swojej infrastrukturze honeypot (Ollama) między październikiem 2025 a styczniem 2026 i wyodrębniło dwie osobne kampanie.
Kampania #1: SSRF (server-side request forgery) — wymuszanie połączeń wychodzących z serwera ofiary (m.in. przez mechanizmy „model pull” i integracje webhook).
Kampania #2: enumeracja i fingerprinting — od 28 grudnia 2025 dwa IP metodycznie sprawdzały 73+ endpointy modeli, generując 80 469 sesji w 11 dni, testując formaty zgodne z OpenAI i Google Gemini.
Celem jest wykrycie źle zabezpieczonych proxy / bramek, które pozwalają uzyskać dostęp do komercyjnych API LLM (czyli realnie: ktoś inny płaci za tokeny).

Kontekst / historia / powiązania

Ten wektor nie jest „nowy” jako idea: źle skonfigurowane reverse proxy potrafi ujawnić dostęp do zasobów, które miały być wewnętrzne (np. inne hosty w sieci, metadane, usługi lokalne), a także bywa nadużywane jako „pośrednik” do wykonywania żądań w imieniu serwera. To klasyczny fundament pod SSRF i nadużycia routingu.

Nowością jest to, że LLM-y są kosztowym zasobem (tokeny, limity, budżety) oraz coraz częściej stoją za nimi automaty (agenty, workflow, funkcje), więc nawet „niewinne” zapytania testowe mogą być wstępem do:

kradzieży budżetu (token draining),
pivotu do systemów wewnętrznych (jeśli gateway ma dodatkowe integracje),
eskalacji do wycieku danych (jeśli proxy ma dostęp do RAG/źródeł).

Dodatkowo Cisco zwraca uwagę, że wiele wdrożeń LLM bywa publicznie wystawionych przez pośpiech, kopiowanie przykładów konfiguracji i brak twardych kontroli dostępu (na przykładzie serwerów LLM wykrywanych przez Shodan).

Analiza techniczna / szczegóły luki

1) Kampania SSRF: „zmuś serwer, żeby zadzwonił do mnie”

GreyNoise opisuje kampanię aktywną od października 2025 do stycznia 2026, w której atakujący próbowali potwierdzać SSRF poprzez OAST (out-of-band application security testing) i domeny callback. W praktyce chodzi o to, żeby serwer ofiary wykonał połączenie wychodzące do kontrolowanej infrastruktury — co potwierdza podatność.

W raporcie pojawiają się m.in.:

wykorzystywanie mechanizmu Ollama model pull do podkładania URL-i rejestru,
współwystępujące próby przez integracje webhook (np. parametry typu MediaUrl w kontekście SMS/MMS),
charakterystyka automatyzacji (fingerprinty JA4, wskazania na narzędzia w stylu Nuclei).

GreyNoise ocenia, że ta część wygląda jak aktywność „research/bug bounty”, ale skala i timing (pik w okresie świątecznym) sugerują „grey-hat pushing boundaries”.

2) Kampania enumeracyjna: „zbuduj listę otwartych bramek do płatnych modeli”

Druga kampania jest bardziej niepokojąca operacyjnie. Od 28 grudnia 2025 dwa adresy IP wykonywały metodyczne próby na 73+ endpointach modeli, testując formaty API kompatybilne z OpenAI i Gemini. W 11 dni zrobiły 80 469 sesji.

Co istotne, testy były „ciche” — proste prompt-y („hi”, puste wejście, pytania faktograficzne), żeby:

zidentyfikować, czy endpoint odpowiada,
sfingerprintować, jaki model stoi za proxy,
nie wywołać alarmów SOC/abuse detection.

GreyNoise wiąże tę infrastrukturę ze „znanymi” aktywnościami skanowania i eksploatacji CVE, co sugeruje, że enumeracja ma zasilić większy pipeline (najpierw mapa, potem nadużycie/eksploatacja).

Dlaczego proxy jest tu kluczowe?

W wielu organizacjach wygląda to tak:

reverse proxy/gateway ma ważny klucz API do OpenAI/Anthropic itp.,
na zewnątrz wystawia „własny” endpoint (często kompatybilny z OpenAI),
jeśli brakuje authN/authZ, ograniczeń tras lub izolacji tenantów, atakujący może używać tego endpointu jak „darmowej karty” do płatnego API.

To jest klasyczna konsekwencja złej konfiguracji reverse proxy: „proxy robi to, o co prosisz”, jeśli nie ma bezpiecznych guardrail’i.

Praktyczne konsekwencje / ryzyko

Koszty i limity (token theft / budget drain)
Najbardziej bezpośredni efekt: nieautoryzowane zapytania spalają tokeny, limity rate i budżety — często zanim ktoś zauważy.
Ryzyko incydentu danych (jeśli gateway ma dostęp do RAG lub narzędzi)
Samo „hello” nic nie kradnie. Ale jeśli ten sam endpoint ma dostęp do: wewnętrznych konektorów, retrieval, funkcji/agentów, logów rozmów — to rośnie ryzyko wycieku lub nadużyć (np. wymuszanie działań przez integracje).
Sygnał, że jesteś „na liście”
GreyNoise podkreśla, że tak duża enumeracja to inwestycja; mapowanie infrastruktury zwykle poprzedza realne nadużycie.
Zgodność i reputacja
Koszty to jedno, ale druga sprawa to audyt, raportowanie incydentów, ślady w logach i ryzyko, że twoje zasoby AI staną się „publicznym serwisem” bez twojej wiedzy.

Rekomendacje operacyjne / co zrobić teraz

Minimum bezpieczeństwa dla „AI gateway / LLM proxy”

Wymuś uwierzytelnianie (mTLS, OAuth2, signed JWT, API keys per klient/usługa) i autoryzację (policy per endpoint/model).
Nie wystawiaj kompatybilnych endpointów OpenAI „na świat” bez kontroli dostępu, nawet jeśli to „tylko test”.
Rate limiting + quota per klient/IP/token, osobno dla endpointów „model list / models” i „chat/completions”.

Twarde ograniczenia ruchu wychodzącego (SSRF)

Egress filtering: serwery LLM/proxy nie powinny móc łączyć się „gdziekolwiek w internet”.
Blokuj domeny OAST/callback na DNS (GreyNoise wskazuje wzorce .oast. jako istotne w kampanii SSRF).
Jeśli używasz Ollama/pull: ogranicz „model pulls” do zaufanych rejestrów.

Detekcja i monitoring

Alertuj na wzorce enumeracji: wiele endpointów modeli w krótkim czasie, nietypowe sekwencje „niewinnych promptów” i skok liczby sesji.
Monitoruj fingerprinty sieciowe, jeśli masz taką możliwość (GreyNoise opisuje użycie JA4 do identyfikacji automatyzacji).
Przejrzyj logi reverse proxy pod kątem:
- nietypowych „OpenAI-compatible paths”,
- prób listowania modeli,
- powtarzalnych krótkich zapytań testowych.

Ramy kontrolne (żeby nie „zgubić” tego w backlogu)

W OWASP Top 10 dla aplikacji LLM temat nieautoryzowanego użycia, niewłaściwych kontroli oraz podatności wynikających z integracji i niebezpiecznych zachowań systemu przewija się wielokrotnie (np. ryzyka wokół nadużyć, DoS, ujawnień danych, supply chain i projektowania wtyczek/agentów). Traktuj te pozycje jako checklistę do przeglądu wdrożenia LLM.

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

Wycieki kluczy API: klasyka (klucz w repo/logach). Tu jest subtelniej: klucz może być dobrze ukryty, ale proxy jest otwarte i działa jak publiczna bramka.
Publicznie wystawione serwery LLM (self-hosted): inny wariant problemu, ale podobna przyczyna — wdrożenie „na szybko”, bez kontroli dostępu i segmentacji (Cisco opisuje, jak takie ekspozycje można masowo wykrywać).
SSRF „klasyczne” vs SSRF w ekosystemie GenAI: mechanika ta sama, ale konsekwencje szersze, bo pipeline AI często ma integracje i automatyzacje, a koszty LLM są bezpośrednio mierzalne (tokeny).

Podsumowanie / kluczowe wnioski

Od końcówki grudnia 2025 widać metodyczną enumerację endpointów LLM, ukierunkowaną na wykrycie źle skonfigurowanych proxy, które mogą dać dostęp do płatnych modeli kosztem ofiary.
Równolegle działa kampania SSRF, gdzie celem jest potwierdzanie podatności i kanału egress (callback).
Największe ryzyko „tu i teraz” to: koszty, limity, oraz potencjalny pivot w głąb środowiska, jeśli bramka AI jest spięta z danymi i narzędziami.
Obrona nie wymaga magii: authN/authZ na bramce, rate limit, egress filtering, blokady OAST, monitoring wzorców enumeracji.

Źródła / bibliografia

BleepingComputer – opis kampanii i obserwacji GreyNoise (9 stycznia 2026). (BleepingComputer)
GreyNoise – „Threat Actors Actively Targeting LLMs” (8 stycznia 2026), metryki, kampanie, IOCs i rekomendacje obrony. (GreyNoise)
ProjectDiscovery – seria o nadużyciach reverse proxy (kontekst bezpieczeństwa i skutki błędnej konfiguracji). (ProjectDiscovery)
Cisco Security – studium wykrywania publicznie wystawionych serwerów LLM (Ollama) i ryzyk wynikających z ekspozycji. (Cisco Blogs)
OWASP – Top 10 dla aplikacji LLM (ramy ryzyk i kontroli bezpieczeństwa dla wdrożeń GenAI). (OWASP Foundation)

Microsoft testuje politykę „RemoveMicrosoftCopilotApp”. IT będzie mogło odinstalować Copilota na urządzeniach zarządzanych

Wprowadzenie do problemu / definicja zmiany

Microsoft rozpoczął testy nowej polityki systemowej, która ma dać administratorom IT możliwość odinstalowania aplikacji Microsoft Copilot na urządzeniach zarządzanych (np. w środowiskach firmowych z MDM). Zmiana jest istotna dla organizacji, które chcą ograniczać „konsumenckie” doświadczenia AI na stacjach roboczych, uporządkować powierzchnię ataku i zmniejszyć zamieszanie użytkowników między Copilotem konsumenckim a Microsoft 365 Copilot.

W skrócie

Polityka nazywa się RemoveMicrosoftCopilotApp i pojawiła się w Windows 11 Insider Preview Build 26220.7535 (KB5072046) (kanały Dev/Beta).
Po włączeniu polityki Microsoft Copilot zostanie odinstalowany „jednorazowo” (a użytkownik nadal może go ponownie zainstalować).
Ma to działać w scenariuszach urządzeń zarządzanych m.in. przez Microsoft Intune oraz SCCM.
Polityka jest „targetowana” – uruchomi się tylko, jeśli urządzenie/użytkownik spełnia warunki (m.in. brak uruchomień Copilota przez 28 dni).

Kontekst / historia / powiązania

W ostatnich kilkunastu miesiącach Microsoft intensywnie przebudowywał doświadczenie Copilota w Windows i w środowiskach komercyjnych. W dokumentacji Microsoft wskazuje m.in., że konsumencka aplikacja Microsoft Copilot nie obsługuje logowania Entra i w praktyce kieruje użytkownika do Microsoft 365 Copilot Chat w przeglądarce, co dodatkowo komplikuje „kto z czego ma korzystać” w firmie.

Warto też pamiętać, że w 2025 r. Microsoft musiał reagować na błąd aktualizacji Windows 11, który przypadkowo odinstalowywał Copilota na części urządzeń i odpinał go z paska zadań — to pokazało, jak wrażliwy jest ten element ekosystemu na zmiany w dystrybucji i politykach.

Analiza techniczna / szczegóły polityki

Gdzie pojawiła się polityka

Nowa opcja została opisana przez Windows Insider Team w ogłoszeniu buildu 26220.7535. Administrator może ją włączyć w edytorze zasad grupy pod ścieżką:

User Configuration → Administrative Templates → Windows AI → Remove Microsoft Copilot App

Jak działa (logika warunkowa)

Polityka ma zastosowanie tylko wtedy, gdy spełnione są jednocześnie warunki:

Microsoft 365 Copilot i Microsoft Copilot są zainstalowane,
Microsoft Copilot nie został zainstalowany przez użytkownika,
Microsoft Copilot nie był uruchamiany przez ostatnie 28 dni.

Po włączeniu: aplikacja Microsoft Copilot zostanie odinstalowana „once” (jednorazowo). Użytkownik nadal może ją potem ponownie zainstalować, jeśli będzie chciał.

Zakres edycji Windows

Microsoft wskazuje dostępność polityki na Enterprise, Pro i EDU.

Zarządzanie z Intune / SCCM

BleepingComputer podaje, że odinstalowanie ma następować na endpointach zarządzanych przez Microsoft Intune lub