Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luki
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
„LLMjacking” to nadużycie infrastruktury dużych modeli językowych (LLM) przez osoby nieuprawnione — analogicznie do cryptojackingu, ale zamiast kopania kryptowalut na cudzym CPU/GPU, celem jest wykonywanie kosztownej inferencji, kradzież danych z kontekstu rozmów, a nawet próby wejścia głębiej w sieć przez integracje typu MCP.
W styczniu 2026 nagłośniono kampanię nazwaną Operation Bizarre Bazaar, w której atakujący polują na wystawione do internetu lub słabo uwierzytelnione endpointy LLM (np. self-hosted) i budują wokół tego cały „łańcuch dostaw” — od skanowania, przez walidację, po odsprzedaż dostępu w formie quasi-komercyjnej usługi.
W skrócie
- Badacze Pillar Security zarejestrowali ~35 000 sesji ataków na honeypotach w oknie ok. 40 dni (grudzień 2025 – styczeń 2026).
- Najczęściej wykorzystywane „wejścia” to domyślne/odsłonięte porty i brak kontroli dostępu, m.in. Ollama na 11434 oraz OpenAI-compatible API na 8000.
- Model działania obejmuje: Scanner → Validator → Marketplace, gdzie rynek miał funkcjonować pod domeną silver[.]inc, promując „unified gateway” do wielu modeli.
- Poza kradzieżą zasobów i odsprzedażą API, ryzyko dotyczy wycieku danych z promptów/konwersacji oraz pivotu przez serwery MCP (łączenie LLM z plikami, DB, API).
Kontekst / historia / powiązania
Zainteresowanie atakujących powierzchnią AI rośnie, bo:
- inferencja bywa droga (szczególnie przy GPU),
- endpointy LLM często są wdrażane „startupowo” — szybko, w środowiskach dev/stage, z publicznym IP,
- integracje narzędziowe (np. MCP) łączą LLM z zasobami o realnej wartości.
Niezależnie od Bizarre Bazaar, GreyNoise opisało w styczniu 2026 metodyczne mapowanie i sondowanie dziesiątek endpointów modeli oraz szukanie błędnych konfiguracji mogących ujawniać dostęp do komercyjnych API.
Analiza techniczna / szczegóły luki
1) Jak wybierane są cele
Według Pillar Security, przestępcy korzystają z narzędzi typu Shodan/Censys i reagują szybko — próby nadużyć pojawiają się w ciągu godzin od tego, gdy źle skonfigurowany endpoint zacznie być widoczny w wynikach skanów.
Typowe „higieniczne” błędy:
- brak uwierzytelniania i autoryzacji,
- wystawienie dev/stage na publiczny adres,
- brak limitów (rate limiting / quota),
- brak segmentacji sieciowej i egress control,
- publicznie dostępne integracje MCP.
2) Najczęstsze wektory wejścia (konkretne przykłady)
Wskazane w raportach przykłady misconfigów:
- Ollama bez auth na porcie 11434,
- OpenAI-compatible endpoints na 8000 dostępne z internetu,
- wystawione serwery MCP bez kontroli dostępu.
3) Łańcuch dostaw cyberprzestępców: Scanner → Validator → Marketplace
Pillar opisuje trójfazowy model:
- Scanner: rozproszona infrastruktura botów kataloguje odsłonięte endpointy LLM/MCP,
- Validator: waliduje działanie API (testy, enumeracja możliwości/modeli),
- Marketplace: monetyzuje dostęp — w raporcie wskazano silver[.]inc jako „bramę” odsprzedającą dostęp do wielu dostawców i promującą projekt „NeXeonAI”.
4) Oddzielna aktywność wokół MCP
W raporcie Pillar pojawia się też wątek osobnej kampanii rozpoznawczej ukierunkowanej na endpointy MCP, gdzie stawką bywa nie tylko koszt inferencji, ale potencjalny dostęp do zasobów (np. interakcje z Kubernetes, dostęp do usług chmurowych, wykonanie poleceń) — co w praktyce może być bardziej wartościowe niż samo „podkradanie” tokenów.
Praktyczne konsekwencje / ryzyko
- Koszty i nadużycia zasobów
Nieautoryzowane użycie inferencji może wygenerować duże rachunki lub zajechać GPU/CPU (DoS kosztowy). Pillar opisuje odsprzedaż dostępu z „rabatem” w modelu przestępczym. - Wyciek danych z promptów i historii konwersacji
Jeśli endpoint umożliwia wgląd w kontekst, logi, historię rozmów lub jeśli aplikacja nie izoluje tenantów/sesji, atakujący może wyciągnąć dane wrażliwe (PII, fragmenty kodu, treści biznesowe). - Pivot do sieci wewnętrznej przez integracje (MCP / narzędzia)
Jeżeli MCP/agent ma uprawnienia do plików, baz danych czy wewnętrznych API, „tylko” odsłonięty endpoint AI staje się punktem wejścia do klasycznych ataków na środowisko. - Ryzyko reputacyjne i prawne
Wycieki danych klientów, utrata poufności, potencjalne naruszenia RODO/umów, a do tego przerwy w działaniu usług (chatboty, support, sprzedaż).
Rekomendacje operacyjne / co zrobić teraz
Poniżej lista działań „od razu” (praktyka z SOC/CloudSec):
1) Odcięcie ekspozycji i twarde uwierzytelnienie
- Nie wystawiaj endpointów LLM/MCP bezpośrednio do internetu; schowaj je za VPN/ZTNA lub reverse proxy.
- Wymuś mTLS / OAuth2 / signed JWT / silne API keys + rotacja sekretów.
- Zastosuj IP allowlist (tam, gdzie to realne).
2) Kontrole kosztowe i anty-abuse
- Rate limiting / quotas per client, limity tokenów, limity równoległości.
- Alerty na anomalia: skoki requestów, nietypowe modele, nietypowe godziny, długie konteksty.
3) Telemetria i detekcja
- Loguj: źródłowe IP, user agent, klucze, endpointy, liczbę tokenów, czasy odpowiedzi, błędy 401/403.
- Koreluj z widocznością w Shodan/Censys (monitoring zewnętrzny własnych adresów).
4) Twarde zasady dla MCP / agentów i integracji narzędziowych
- Least privilege dla narzędzi (filesystem/DB/API), osobne konta serwisowe, minimalne scope.
- Rozdziel sieciowo warstwę LLM od zasobów krytycznych (segmentacja).
- Wprowadź polityki „tool allowlist” i ograniczenia komend/operacji (szczególnie tam, gdzie możliwe jest wykonywanie poleceń).
5) Higiena wdrożeń self-hosted (Ollama/vLLM i podobne)
- Zmień domyślne ustawienia, wyłącz publiczne bindy, nie zostawiaj portów typu 11434/8000 na WAN.
- Traktuj dev/stage jak produkcję: brak publicznych IP, brak „tymczasowo otwartego” API.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- Cryptojacking vs LLMjacking: w obu przypadkach kradniesz moc obliczeniową, ale przy LLM dochodzi wyższa wrażliwość danych (kontekst rozmów) i częściej ścieżka do systemów wewnętrznych przez integracje (MCP/agent tools).
- Skanowanie/rekonesans vs monetyzacja: GreyNoise opisywało kampanie silnie rekonesansowe, budujące listy celów i testujące formaty API. Z kolei Bizarre Bazaar (wg Pillar) idzie krok dalej — domyka pętlę „biznesową” przez walidację i odsprzedaż dostępu.
Podsumowanie / kluczowe wnioski
- Wystawione endpointy LLM/MCP przestały być „niszowym problemem” — pojawił się powtarzalny model przestępczy z monetyzacją.
- Największe ryzyko to nie tylko rachunki za GPU, ale też wyciek danych i pivot do wnętrza organizacji przez integracje narzędziowe.
- Najskuteczniejsza obrona jest nudna, ale działa: brak ekspozycji do internetu + silne auth + limity + monitoring + least privilege dla MCP.
Źródła / bibliografia
- Pillar Security — Operation Bizarre Bazaar: First Attributed LLMjacking Campaign… (28 stycznia 2026). (pillar.security)
- BleepingComputer — Hackers hijack exposed LLM endpoints in Bizarre Bazaar operation (28 stycznia 2026). (BleepingComputer)
- CSO Online — Crooks are hijacking and reselling AI infrastructure: Report (28 stycznia 2026). (CSO Online)
- GreyNoise — Threat Actors Actively Targeting LLMs (8 stycznia 2026). (greynoise.io)
- SecurityWeek — LLMs in Attacker Crosshairs, Warns Threat Intel Firm (12 stycznia 2026). (SecurityWeek)