Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Microsoft opisał nowy atak boczny na zdalne modele językowe (LLM), nazwany Whisper Leak. Pozwala on pasywnemu podsłuchującemu — np. operatorowi sieci, atakującemu w tej samej sieci Wi-Fi lub obserwatorowi na łączu — wnioskować o temacie rozmowy z chatbotem, mimo że ruch jest szyfrowany (HTTPS/TLS). Skuteczność ataku wynika z analizy metadanych ruchu: rozmiarów i czasów nadejścia pakietów podczas strumieniowania odpowiedzi modelu. To nie jest błąd kryptograficzny TLS, tylko nadużycie informacji ujawnianej przez samą naturę strumieniowania tokenów.
W skrócie
Co wycieka? Nie treść wiadomości, lecz klasa/temat rozmowy (np. pytania o pranie pieniędzy, zdrowie, politykę).
Jak? Klasyfikator uczy się wzorców z sekwencji rozmiarów pakietów i odstępów czasowych przy strumieniowaniu odpowiedzi.
Skuteczność: Microsoft raportuje dla wielu popularnych modeli wyniki >98% AUPRC; w scenariuszu 1 rozmowa na 10 000 „szumu” możliwa jest 100% precyzja przy 5–50% pokrycia przypadków docelowych.
Kto załatał? Po jawnej koordynacji dostawcy tacy jak OpenAI, Mistral, Microsoft, xAI wdrożyli pierwsze obfuscatory strumienia (dodawanie losowego tekstu / parametry API) i inne utrudnienia.
Ryzyko: Realne dla użytkowników w środowiskach podwyższonego nadzoru (ISP, sieci publiczne), organizacji korzystających z LLM w wrażliwych domenach (prawo, zdrowie, compliance).
Kontekst / historia / powiązania
Whisper Leak wpisuje się w rosnące portfolio ataków kanałami pobocznymi na LLM:
Token-length side-channel (USENIX ‘24) — na podstawie długości tokenów (wnioskowanej z rozmiarów pakietów) rekonstruowano częściowo odpowiedzi oraz temat rozmowy.
Remote timing attacks (2024) — wykorzystują zależności czasowe w efektywnym wnioskowaniu (np. speculative decoding) do rozpoznawania właściwości promptu/odpowiedzi.
Microsoft buduje na tych pracach, łącząc rozmiary i timingi pakietów w jeden wektor cech i pokazując, że to wystarcza do trafnego klasyfikowania tematów w ruchu szyfrowanym.
Analiza techniczna / szczegóły luki
Założenie ataku: napastnik passive network observer ma podgląd do ruchu TLS między klientem a usługą LLM, ale go nie deszyfruje.
Powierzchnia ataku: większość klientów LLM strumieniuje odpowiedź — tokeny (lub małe grupy tokenów) są wysyłane na bieżąco. Dla TLS oznacza to ciąg pakietów o pewnych rozmiarach i przerwach. Ponieważ rozmiar szyfrogramu ~ rozmiarowi plaintextu + stałe narzuty, wzorce długości i czasu stają się „odciskiem palca” danego tematu i sposobu generacji.
Pipeline Whisper Leak (upraszczając):
Zbieranie próbek: generowanie zestawu wariantów pytań z wrażliwego tematu (POC: „legalność prania pieniędzy”) oraz dużego zbioru losowych pytań-szumu; rejestrowanie ruchu (np. tcpdump) dla różnych dostawców/modeli.
Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
Ewaluacja: metryka AUPRC na zbiorze ekstremalnie niezrównoważonym (np. 1:10 000 target:noise). Wynik: >98% dla wielu usług; w praktycznym modelu nadzoru wysoka precyzja przy istotnym recall.
Dlaczego to działa?
Autoregresja i (niekiedy) optymalizacje efektywności wprowadzają zależne od danych różnice czasowe.
TLS nie ukrywa rozmiarów i timingów rekordów/aplikacyjnych ramek; to metadane.
Minimalny PoC zbierania cech (edukacyjnie):
# przechwyć sesję HTTPS do dostawcy LLM (np. domena api.*)
sudo tcpdump -i eth0 -w llm.pcap 'tcp port 443 and host api.example-llm.com'
# wyodrębnij rozmiary i interwały z PCAP (pyshark)
import pyshark, numpy as np
cap = pyshark.FileCapture('llm.pcap', display_filter='tcp && tls')
sessions = {}
for p in cap:
key = (p.ip.src, p.tcp.stream) if 'TLS' in p else None
if not key: continue
ts = float(p.sniff_timestamp)
size = int(p.length) # długość ramki
sessions.setdefault(key, []).append((ts, size))
features = []
for k, seq in sessions.items():
seq.sort()
dts = np.diff([t for t,_ in seq], prepend=seq[0][0])
feats = list(zip([s for _,s in seq], dts))
features.append(feats)
print("sesji:", len(features))
(Powyższe służy naukowym ćwiczeniom nad detekcją wewnętrzną — nie do nadużycia).
Praktyczne konsekwencje / ryzyko
Model zagrożeń: ISP, operator chmury pośredniczącej, współużytkownicy Wi-Fi, każdy z możliwością passive sniffing.
Co można wywnioskować?Temat konwersacji (np. przestępczość finansowa, medyczne zapytania, poglądy polityczne). To wystarczy do profilowania i wyzwolenia działań (cenzura, targetowanie).
Sektory wrażliwe: prawo, zdrowie, finanse, sektor publiczny, media/NGO w krajach restrykcyjnych.
Skala: badanie obejmowało 28 modeli głównych dostawców; część z nich osiągała wyniki umożliwiające nadzór na masową skalę.
Rekomendacje operacyjne / co zrobić teraz
Dla dostawców/usług LLM (serwer)
Obfuskacja strumienia odpowiedzi — dodawanie losowego tekstu o zmiennej długości do chunków strumieniowych (wprowadzono m.in. w OpenAI, Azure; Mistral dodał dedykowany parametr). Silnie obniża skuteczność ataku.
Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
Ciągła ewaluacja — testy regresyjne pod kątem wycieków metadanych (AUPRC/ROC na syntetycznych zbiorach tematów).
Dla integratorów/architektów (klient, brzeg)
Wyłącz strumieniowanie dla przepływów „tajemniczych” (domyślnie stream=False / brak streamu w większości SDK). Segmentuj ruch (oddzielny endpoint/trasowanie dla zapytań wrażliwych).
Preferuj dostawców z wdrożonymi mitigacjami (OpenAI, Azure, Mistral, xAI — wg stanu na 7–9 listopada 2025).
VPN/zero-trust egress na wyjściu organizacji (utrudnia lokalnym przeciwnikom korelację strumienia, choć nie eliminuje ataku u dostawcy/ISP).
Buduj detektory anomalii na własnych bramach (np. wykrywanie nietypowych wzorców TLS/HTTP2 dla usług LLM, by lokalnie oceniać ryzyko ekspozycji).
Dla zespołów bezpieczeństwa (SOC/Blue)
Policy awareness: oznacz tematy wrażliwe i wymuś polityki non-streaming + dostawcy z mitigacjami.
Monitoring: rejestrowanie metryk egress (rozmiary rekordów, jitter) w kanałach do usług LLM, by audytować zgodność.
Szkolenia użytkowników:nie zadawać pytań o wysokiej wrażliwości przez LLM w sieciach niezaufanych (hotele, kawiarnie).
Przykładowe „kontrole” w praktyce (demo):
Blokowanie strumieniowania po stronie reverese-proxy (np. endpoint „sensitive” przekierowany do niestreamingowej ścieżki API).
Kontrola jakości dostawcy — test A/B: wysyłaj paczkę 100 pytań „sensitive” i 10 000 pytań „noise”; mierz AUPRC własnym klasyfikatorem metadanych — jeśli > próg (np. 0.9), eskaluj do zmiany dostawcy/konfiguracji.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Whisper Leak vs. Token-length (Weiss et al. 2024): Weiss celował w rekonstrukcję treści bazując na długościach tokenów; Whisper Leak skupia się na klasyfikacji tematu na bazie rozmiarów i timingów pakietów — skuteczne nawet, gdy usługodawca grupuje tokeny.
Whisper Leak vs. Remote Timing (Carlini & Nasr 2024): Carlini/Nasr eksploitują optymalizacje efektywności (np. speculative decoding) i subtelne różnice czasowe; Whisper Leak korzysta z makro-wzorca strumienia (rozmiar+czas) i działa na popularnych usługach.
Podsumowanie / kluczowe wnioski
Metadane ruchu LLM potrafią zdradzić temat rozmowy mimo TLS.
Atak jest praktyczny przy masowym nadzorze (ISP/Wi-Fi), co rodzi realne ryzyka dla prywatności i compliance.
Mitigacje istnieją, ale to trade-off koszt/latencja/jakość i nie dają pełnej eliminacji — potrzebny defense-in-depth po stronie dostawcy i rozsądna higiena użytkowania po stronie klienta.
Źródła / bibliografia
Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)
Na OpenVSX (alternatywny rejestr rozszerzeń VS Code) wykryto powrót kampanii GlassWorm – zestawu złośliwych rozszerzeń wykorzystujących niewidzialne znaki Unicode do ukrywania i wykonywania JavaScriptu. Nowa fala obejmuje 3 rozszerzenia (m.in. ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs) i według bieżących raportów odnotowała łącznie >10 tys. pobrań. Kampania kontynuuje wcześniej opisane techniki: C2 w łańcuchu Solana, kradzież tokenów GitHub/npm/OpenVSX oraz danych portfeli krypto z 49 popularnych wtyczek.
W skrócie
Co się stało: po październikowych czyszczeniach OpenVSX znów pojawiły się 3 zainfekowane rozszerzenia z ukrytym ładunkiem GlassWorm.
Jak działa: payload jest schowany w znakach PUA/VS (Private Use Area/Variation Selectors) – „puste” w edytorze, ale dekodowane i wykonywane przez JS. C2 i aktualizacje są osadzane w transakcjach Solana (trwałość, anonimizacja, niskie koszty).
Po co: kradzież sekretów (GitHub, npm, OpenVSX), drenaż krypto, tworzenie SOCKS proxy/HVNC i budowa infrastruktury przestępczej na stacjach devów.
Skala i spór: OpenVSX informował, że incydent z października był „opanowany” i że nie była to autonomiczna samoreplikacja; jednak badacze widzą „samopowielanie” przez kradzież i użycie poświadczeń.
Nowość: potwierdzone wejście na GitHub (commity z doklejonym, ukrytym dekoderem + eval) – to rozszerza wektor poza marketplace.
Kontekst / historia / powiązania
Pierwsza fala GlassWorm została opisana 20 października 2025 r., gdy wykryto pakiet zainfekowanych rozszerzeń na OpenVSX i w marketplace Microsoftu (łączny licznik pobrań szacowany na ok. 35,8 tys., choć mógł być sztucznie zawyżony przez atakujących). 2 listopada OpenVSX ogłosił rotację tokenów i dodatkowe zabezpieczenia po wykryciu wycieku >550 sekretów; jednocześnie podkreślił, że kod nie był „samoreplikującym się” robakiem w klasycznym sensie. 6 listopada badacze Koi i Aikido pokazali jednak nową falę oraz pivot na GitHub. 8 listopada media potwierdziły trzy świeże rozszerzenia na OpenVSX.
Analiza techniczna / szczegóły luki
1) „Niewidzialny” ładunek
Atak wykorzystuje PUA/VS (np. zakresy U+E000–U+F8FF, U+FE00–U+FE0F), które nie renderują się w edytorze, ale są parsowane przez dekoder w JS. Typowy wzorzec: dekoder mapujący punkty kodowe → bajty → eval. Na GitHub widziano jednolinijkowy wariant, który dołączał dekoder na końcu pliku.
2) Kanał C2/aktualizacji w Solanie
Rozszerzenia pobierają następne etapy na podstawie transakcji Solana (w polach danych trzymane są base64 z URL-ami serwerów C2). Rozwiązanie trudne do zdejmowania (odporne, tanie, anonimowe). Backup: Google Calendar z linkiem base64 w tytule wydarzenia.
3) Zdolności końcowe
Kradzież tokenów/logowań (GitHub/npm/OpenVSX), portfeli krypto (49 wtyczek), uruchamianie SOCKS proxy, HVNC (ukryty VNC) – praktycznie przejęcie stacji deweloperskiej jako węzła przestępczego.
4) Infrastruktura i IOC
Koi w nowej fali wskazało, że używana jest ta sama infrastruktura (zaktualizowane wskaźniki C2 publikowane w Solanie; przykładowo w raporcie widnieją adresy 199.247.10.166 oraz 199.247.13.106:80/wall jako punkty komunikacji/eksfiltracji).
Praktyczne konsekwencje / ryzyko
Łańcuchowe kompromitacje: kradzione tokeny wydawnicze pozwalają wstrzykiwać złośliwe aktualizacje do innych rozszerzeń/repozytoriów/teamów.
Trwałość i trudne wyłączenie:C2 na blockchainie zmniejsza skuteczność klasycznych Takedownów. Zmiana transakcji → nowy endpoint → „samoleczenie” C2.
Ryzyko finansowe i reputacyjne: wyciek sekretów organizacji, kradzież krypto, nadużycie zasobów (proxy, botnet z dev-workstation).
Rozszerzenie wektora: pojawienie się ukrytych commitów na GitHub (AI-like, wiarygodne modyfikacje) utrudnia code review i detekcję.
Rekomendacje operacyjne / co zrobić teraz
0) Szybkie kroki IR (dla SOC/ITSec)
Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
Rotuj sekrety: patche PAT/ghp, npm tokens, OpenVSX tokens, klucze do CI/CD; wymuś 2FA i SSO. (OpenVSX przeszedł już rotację tokenów, ale Twoja organizacja musi zrobić to samo).
1) Wykrywanie „niewidzialnego” kodu (proste skrypty)
Linux/macOS – skan katalogów rozszerzeń VS Code/VSCodium
# VS Code i VSCodium: typowe ścieżki
EXT_DIRS=("$HOME/.vscode/extensions" "$HOME/.vscode-oss/extensions" "$HOME/.vscode-insiders/extensions")
# Znaki PUA/VS: U+E000–U+F8FF, U+FE00–U+FE0F, U+E0100–U+E01EF
for d in "${EXT_DIRS[@]}"; do
[ -d "$d" ] || continue
echo "[*] Skanuję $d"
grep -RIl --include='*.js' --include='*.ts' \
-P "[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]" "$d" || true
done
Sekrety: ogranicz TTL tokenów, wprowadź krótko żyjące PAT, automatyczną re-rotację po wykryciu wycieku; secret scanning w CI. (Zgodne z kierunkiem zmian deklarowanych przez OpenVSX).
Publikacja rozszerzeń: SBOM + skan artefaktów przed publikacją, signowanie, zasada 4-oczu na „release”.
Review kodu: wymuś widoczność znaków niewidzialnych w IDE i Diffach (np. włącz „Render Control Characters” w VS Code, używaj pre-commit hooków skanujących PUA). (W raporcie Aikido wskazano, że interfejsy nie zawsze oznaczały te znaki).
Egress i DNS: blokady do znanych IOC oraz monitorowanie zapytań powiązanych z Solaną używaną jako kanał C2 (telemetria proxy, NetFlow/Zeek).
Różnice / porównania z innymi przypadkami
Klasyczne „tylne drzwi” w npm (post-install, skrypty lifecycle) były wyraźniejsze w kodzie; tutaj ładunek „nie istnieje gołym okiem” i potrafi przenikać code review.
C2 w Solanie to nowszy trend utrudniający Takedown – w porównaniu do typowych domen/URL na VPS, które łatwiej zawiesić.
Spór o „worma”: OpenVSX wskazuje, że brak autonomicznej replikacji; badacze argumentują, że automatyczne aktualizacje + wykorzystanie wykradzionych tokenów de facto umożliwia rozprzestrzenianie się w ekosystemie. Wniosek operacyjny: dla obrony nie ma to znaczenia – ścieżka propagacji i tak omija kontrole.
Podsumowanie / kluczowe wnioski
Niewidzialny kod + blockchain C2 + kradzież sekretów = bardzo skuteczny model ataku na ekosystemy developerskie.
Nowa fala na OpenVSX pokazuje, że nawet po rotacji tokenów atakujący szybko wracają – potrzebne są krótkie TTL, skanowanie podczas publikacji i silne procesy w organizacjach.
Blue Teamy powinny wdrożyć skan PUA, bloki IOC, telemetrię egress i procedury IR wyspecjalizowane dla stacji developerskich (zależne od IDE/marketplace).
Źródła / bibliografia
BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
Eclipse Foundation (OpenVSX) – aktualizacja bezpieczeństwa, rotacje tokenów i stanowisko nt. „self-replicating” (27.10.2025; podsumowane także 02.11.2025). (Eclipse Foundation Staff Blogs)
Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)
Badacze ujawnili świeży zestaw podatności w popularnych elementach infrastruktury AI: w silniku modeli Ollama oraz w stosie NVIDIA (Triton Inference Server i Container Toolkit/GPU Operator). Część błędów umożliwia zdalne wykonanie kodu (RCE) bez uwierzytelnienia lub ucieczkę z kontenera do hosta, co wprost zagraża klastrom Kubernetes i serwerom GPU. Informacje o nowych lukach i ich naprawach potwierdza m.in. serwis Dark Reading oraz biuletyny producentów.
W skrócie
Produkty narażone (przykłady):
Ollama – m.in. nowsze zgłoszenia: CVE-2025-51471 (token-steal/bypass auth), wcześniejsze: CVE-2024-37032 (RCE „Probllama”), CVE-2024-28224 (DNS rebinding), plus błędy DoS/overflow.
Wpływ: przejęcie serwera inferencji, kradzież modeli i danych, eskalacja uprawnień z kontenera do hosta, dostęp do innych workloadów na tym samym węźle GPU.
Ollama – aktualizacja do wydań z łatami (m.in. po CVE-2024-37032 oraz po CVE-2025-51471).
Kontekst / historia / powiązania
Od 2024 r. infrastruktura AI trafia coraz częściej na celownik: Wiz Research opisał RCE w Ollama (CVE-2024-37032, „Probllama”) – łatwe do sprowokowania przez błędy walidacji i brak natywnego uwierzytelniania, zwłaszcza w domyślnie publicznych wdrożeniach Docker. NCC Group wcześniej udowodniło, że DNS rebinding pozwala atakować lokalne instancje Ollama przez przeglądarkę ofiary. Równolegle 2025 przyniósł NVIDIAScape – krytyczny escape w Container Toolkit. Trend potwierdzają media branżowe: środek ciężkości badań przesuwa się z prompt-injection do warstwy infrastruktury (serwery inferencji, rejestry modeli, kontenery GPU).
Analiza techniczna / szczegóły luki
Ollama
CVE-2024-37032 („Probllama”) – RCE
Wada w obsłudze manifestów przy /api/pull pozwalała na path traversal i arbitrary file write/read, co w deploymentach Docker (root, 0.0.0.0) dawało prostą ścieżkę do RCE (np. przez manipulację ld.so.preload). Zalecana aktualizacja do wersji z 08.05.2024+.
CVE-2024-28224 – DNS rebinding
Atak z poziomu przeglądarki ofiary omijał Same-Origin Policy, umożliwiając zdalny dostęp do API Ollama na localhost, eksfiltrację plików oraz operacje na modelach. Naprawione w v0.1.29; rekomendowane m.in. sprawdzanie nagłówka Host i TLS, także dla loopback.
CVE-2025-51471 – kradzież tokenów / obejście auth
Cross-Domain Token Exposure: złośliwy WWW-Authenticate realm z /api/pull mógł wykradać tokeny i obchodzić kontrolę dostępu. Dotyczyło Ollama 0.6.7; patrz NVD/GitHub Advisory i poprawki projektu.
Wniosek: w praktyce te trzy klasy błędów łączą się w łańcuch ataku: rebinding ⇒ token-steal ⇒ pull/push z prywatnego rejestru ⇒ RCE/eksfiltracja.
NVIDIA Container Toolkit / GPU Operator
CVE-2025-23266 (CVSS 9.0) – błąd w hookach inicjalizacji kontenera; w pewnych konfiguracjach umożliwiał ucieczkę z kontenera i wykonanie kodu z podwyższonymi uprawnieniami na hoście.
CVE-2025-23267 (CVSS 8.5) – podatność w hooku update-ldcache; specjalnie spreparowany obraz mógł prowadzić do link following, skutkując manipulacją danymi/DoS.
Wersje naprawcze: Toolkit 1.17.8, GPU Operator 25.3.2, Device Plugin 0.17.3, MIG Manager 0.12.2; dodatkowe uwagi dla RHEL/OpenShift i notatka, że konfiguracje z crun nie są dotknięte 23266.
Praktyczne konsekwencje / ryzyko
Kradzież modeli i promptów, modyfikacja wag i artefaktów (supply-chain modeli), sabotaż inferencji.
Pivot z kontenera do hosta GPU (23266) ⇒ dostęp do innych namespace’ów/kontenerów na węźle, wyciek danych klientów i eskalacja w klastrze.
Ataki z przeglądarki na lokalne dev-maszyny (DNS rebinding) ⇒ eksfiltracja dokumentów/projektów R&D.
Ryzyko compliance: naruszenia izolacji danych, IP leakage, utrata integralności modeli.
Rekomendacje operacyjne / co zrobić teraz
1) Patch & wersje
NVIDIA: zaktualizuj Container Toolkit → 1.17.8, GPU Operator → 25.3.2, Device Plugin → 0.17.3, MIG Manager → 0.12.2. Dla OpenShift – użyj tagów v1.17.8-ubi8 / v0.12.2-ubi9. Jeśli używasz crun – 23266 nie dotyczy, ale 1.17.7 nadal wymaga łat na 23267.
Ollama: zaktualizuj do wersji usuwających CVE-2024-37032 i CVE-2025-51471 (sprawdź release notes projektu). Minimalnie ≥ v0.1.34 dla „Probllama”, naprawa 0.6.7-related dla token-steal.
2) Minimalizacja ekspozycji
Nie wystawiaj API Ollama publicznie. Jeśli musisz – wymuś reverse proxy z auth (OIDC/Basic) i TLS:
Pin’uj hashy warstw, weryfikuj źródła (allow-list domen/rejestrów), skanuj artefakty przed „pull”. (W RCE „Probllama” wektor przechodził przez /api/pull z prywatnego rejestru.)
5) Detekcja i IR
Wskaźniki podejrzanej aktywności (przykłady):
Nietypowe żądania /api/pull z zewnętrznych adresów, 4xx/5xx na /api/push, powtarzające się tworzenie modelu z niestandardowymi FROM.
W nodach GPU: logi runtime wskazujące na modyfikacje ld.so.preload, anomalie w hookach OCI, nieautoryzowane biblioteki preload (23266/23267).
Reguły (przykład Falco):
- rule: Write to ld.so.preload
desc: Potential container escape via ld.so.preload manipulation
condition: >
evt.type in (open, openat) and fd.name = "/etc/ld.so.preload" and
proc.name not in (ldconfig)
output: "Process %proc.name wrote to ld.so.preload (user=%user.name container=%container.id)"
priority: CRITICAL
Różnice / porównania z innymi przypadkami
Ollama – błędy głównie na styku API i walidacji danych (path traversal, token-steal, DNS rebinding), a więc ataki zdalne poprzez HTTP i łańcuchy z udziałem przeglądarek/serwerów proxy.
NVIDIA Container Toolkit/GPU Operator – błędy w hookach OCI i przepływie inicjalizacji, skutkujące eskalacją z kontenera do hosta (breakout), co zagraża całemu węzłowi i sąsiadującym workloadom.
Podsumowanie / kluczowe wnioski
Zaktualizuj wszystko, co dotyczy stosu AI – najpierw Toolkit 1.17.8 / GPU Operator 25.3.2, potem Ollama do wersji z łatami na RCE, rebinding i token-exposure.
Nie wystawiaj surowych endpointów inferencji do Internetu; dodaj auth i TLS na brzegu.
Odchudź uprawnienia kontenerów, stosuj Pod Security i NetworkPolicy, monitoruj anomalia w hookach OCI i modyfikacje ld.so.preload.
Traktuj modele jak łańcuch dostaw – weryfikuj źródła i hashe, skanuj pliki GGUF/manifesty przed użyciem.
Źródła / bibliografia
Dark Reading — przegląd nowych luk w Ollama i NVIDIA Triton/Toolkit (7 listopada 2025). (Dark Reading)
NVIDIA Security Bulletin: Container Toolkit (CVE-2025-23266, CVE-2025-23267) oraz wersje naprawcze. (NVIDIA Support)
Wiz Research: „Probllama” — CVE-2024-37032 (RCE w Ollama), wektory i mitigacje. (wiz.io)
NCC Group: CVE-2024-28224 (DNS rebinding w Ollama), szczegóły ataku i zalecenia. (NCC Group)
NVD: CVE-2025-51471 (Cross-Domain Token Exposure w Ollama 0.6.7), status i referencje. (NVD)
Skalowanie operacji bezpieczeństwa (SOC) rozbija się dziś o dwa twarde limity: czas reakcji i liczbę ludzi. Klasyczne MDR-y (Managed Detection and Response) odciążają zespoły, ale nadal cierpią na przeciążenie alertami i „eskalowanie zamiast rozwiązywania”. Startup Daylight proponuje alternatywę: połączenie agentowych systemów AI z nadzorem doświadczonych analityków, aby dostarczać rezultaty (containment, remediacje) zamiast samych powiadomień. Firma właśnie ogłosiła rundę 33 mln USD (Series A), która ma przyspieszyć rozwój platformy oraz modułów dla Identity Threat Response i Cloud Workload Protection.
W skrócie
33 mln USD Series A prowadzone przez Craft Ventures; udział m.in. Bain Capital Ventures i Maple VC. Całkowite finansowanie: 40 mln USD.
Daylight określa swój model jako MASS – Managed Agentic Security Services: autonomiczne agentowe AI + nadzór analityków 24/7.
Cel rundy: ekspansja w USA, rozwój platformy operacji bezpieczeństwa i uruchomienie modułów dla tożsamości oraz chmury.
Firma deklaruje wdrożenia „w mniej niż godzinę”, „do 90% mniej false positives” i klientów w USA/EU (m.in. The Motley Fool, Cresta, McKinsey Investment Office). (Deklaracje producenta)
Założyciele: Hagai Shapira (CEO) i Eldad Rudich (CTO) – weterani Unit 8200.
Kontekst / historia / powiązania
Runda ogłoszona 4–5 listopada 2025 r. następuje trzy miesiące po seedzie 7 mln USD i wpisuje się w trend przyspieszonego finansowania narzędzi AI-native SecOps. W tle mamy eksplozję ataków napędzanych AI, rosnące środowiska hybrydowe i chroniczny deficyt talentów w SOC. Daylight pozycjonuje MASS jako ewolucję MDR: agenci AI wykonują monitoring, triage, dochodzenia kontekstowe i wstępne remediacje, a analitycy podejmują decyzje o wyższym ciężarze.
Analiza techniczna / szczegóły podejścia
Architektura MASS (wysnuta z opisów publicznych):
Warstwa agentowa (AI-core): zestaw wyspecjalizowanych agentów wykonujących korelację sygnałów, priorytetyzację, „case building” oraz autonomiczne działania (np. izolacja hosta, blokada konta, polityka w EDR/IdP), z możliwością pracy cloud/on-prem/hybryda.
Nadzór ekspercki (human-in-the-loop): analitycy „kalibru PhD” potwierdzają hipotezy, rozszerzają zakres dochodzenia, zatwierdzają remediacje wysokiego ryzyka i utrzymują „guardrails” dla agentów.
Integracje i czas wartości: producent podkreśla szybkie wdrożenie (<1h) i pracę „w istniejącej infrastrukturze” – to sugeruje gotowe konektory do EDR/XDR, SIEM, IdP, chmur. (Deklaracje producenta)
Nowe moduły:Identity Threat Response i Cloud Workload Protection mają rozszerzyć autonomię poza klasyczne endpointy.
Różnica semantyczna: Daylight używa pojęcia MASS aby odróżnić się od „AI-assisted MDR”. Klucz to agentowość (samodzielne działanie agentów w granicach polityk) zamiast samego „copilota” do analizy zdarzeń.
Praktyczne konsekwencje / ryzyko
Plusy dla SOC:
Skrócenie MTTD/MTTR dzięki automatycznym dochodzeniom i remediacjom niskiego ryzyka.
Redukcja alert fatigue i kosztów eskalacji; potencjalnie mniej ról L1/L2, więcej „SRE-like SecOps”.
Ryzyka i „ciemne pola”:
Zaufanie do agentów: konieczne twarde guardrails, audyt działań i „two-person rule” dla akcji destrukcyjnych (np. masowe disable kont).
Bias danych i halucynacje: agentowe systemy oparte na LLM muszą mieć deterministyczne playbooki i walidację efektów.
Vendor lock-in & integracje: rzeczywista głębokość integracji z EDR/XDR/IdP/SaaS będzie decydować o skuteczności poza presales demo.
Regulacje/zgodność: ścieżki audytu, eDiscovery i zgodność z politykami tożsamości (zwłaszcza w UE). (Ocena własna na podstawie publicznych opisów architektury.)
Rekomendacje operacyjne / co zrobić teraz
Pilot 60–90 dni: wybrane segmenty (np. wybrane OU w IdP, część floty EDR, wycinek chmury). Zdefiniuj KPI: MTTD/MTTR, % zautomatyzowanych remediacji, precyzja triage.
RACI dla agentów: policy gates dla akcji o wysokim wpływie (disable użytkownika, kwarantanna zasobu chmurowego).
Playbooki „deterministyczne”: ustandaryzowane runbooki SOAR jako „rails” dla agentów; logowanie decyzji i wyników.
Ocena integracji: sprawdź konektory do twoich krytycznych systemów (IdP, EDR/XDR, chmury, SaaS).
Model zagrożeń AI: włącz AI threat modeling (np. ryzyka „model misuse”, nadmierna autonomiczność, eskalacja uprawnień).
Due diligence dostawcy: SLA na czas reakcji analityków, transparentność działań agentów, mechanizmy „kill-switch”.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Klasyczny MDR/XDR: zwykle „detect → alert → escalate”, ograniczona automatyzacja i często ręczne dochodzenia. Daylight twierdzi, że przechodzi do „detect → investigate → resolve” z agentami AI, a człowiek nadzoruje tylko trudne przypadki.
„AI-assisted SOC copilot”: narzędzia pomagające analitykom pisać zapytania lub streszczać alerty. MASS aspiruje do autonomii operacyjnej w ramach polityk (containment/remediacje), co zbliża je do „autonomic SOC”.
Podsumowanie / kluczowe wnioski
Runda 33 mln USD (Series A) potwierdza popyt na agentowe podejście do SecOps. MASS ma ambicję dostarczać wynik, nie tylko alert.
Sukces wdrożeń będzie zależeć od jakości integracji, dojrzałości guardrails i przejrzystości działań agentów.
Dla CISO to realna ścieżka do skrócenia MTTR bez liniowego zwiększania etatów – ale wymaga świadomego pilotowania, kontroli zmian i audytu.
Źródła / bibliografia
SecurityWeek: Daylight Raises $33 Million for AI-Powered MDR Platform (05.11.2025). (SecurityWeek)
Blog Daylight (Hagai Shapira): Lighting the Next Chapter… (04.11.2025). (daylight.ai)
Apple opublikował 3–4 listopada 2025 r. pakiet aktualizacji bezpieczeństwa dla iOS/iPadOS 26.1, macOS Tahoe 26.1 oraz Safari 26.1. Wśród ponad setki zaadresowanych usterek szczególnie wyróżnia się 19 luk w silniku przeglądarki WebKit, które mogły prowadzić m.in. do wycieków danych między domenami, korupcji pamięci i awarii procesów podczas przetwarzania złośliwej zawartości WWW. Apple nie zgłosił na ten moment dowodów na wykorzystanie tych błędów „in the wild”.
Skala poprawek: iOS/iPadOS 26.1: dziesiątki poprawek, w tym 19 dla WebKit; macOS Tahoe 26.1: ~105 poprawek; Safari 26.1: ~dwudziestka błędów (głównie WebKit/Safari UI).
Przykładowe skutki: exfiltracja danych cross-origin (CVE-2025-43480), wywołanie crashy/use-after-free/buffer overflow (np. CVE-2025-43438, CVE-2025-43429), spoofing UI/paska adresu w Safari (CVE-2025-43493, CVE-2025-43503).
Kredyty: część błędów WebKit wykryła AI-agent „Google Big Sleep” (wskazana także przez Apple i opisana przez Google).
Status eksploatacji: brak informacji o aktywnym wykorzystywaniu przez atakujących.
Kontekst / historia / powiązania
WebKit to silnik renderujący stojący za Safari na iOS, iPadOS i macOS; na iOS wszystkie przeglądarki muszą korzystać z WebKit, więc jego błędy mają systemowy zasięg. Kolejne wydania Apple od lat zawierają wielopakietowe poprawki WebKit – tu dodatkowo widoczna jest nowa praktyka: publiczne acknowledgements dla narzędzi AI (Google Big Sleep) za wkład w znajdowanie luk. To sygnał, że automatyzacja VR (vulnerability research) będzie coraz większym źródłem raportów CVE.
Analiza techniczna / szczegóły luki
Klasy błędów WebKit
Cross-origin data exfiltration – np. CVE-2025-43480 (Bugzilla 276208) oraz WebKit Canvas: CVE-2025-43392 pozwalające na wyciek danych obrazów między originami. W obu przypadkach problem rozwiązano przez wzmocnione sprawdzanie/stany cache.
Memory safety – liczne use-after-free, buffer overflows i błędy stanu skutkujące crashami lub korupcją pamięci (np. CVE-2025-43438, -43432, -43429, -43433, -43431). Łatki wzmacniają zarządzanie pamięcią, walidację granic i ograniczają niektóre optymalizacje (np. „disabling array allocation sinking”).
UI/Privacy w Safari – spoofing paska adresu i interfejsu (CVE-2025-43493, -43503) oraz obejście wybranych preferencji prywatności (CVE-2025-43502).
Poza WebKit (istotne z perspektywy obrony)
AMFI / symlinks / path parsing – szereg poprawek utrudniających dostęp do danych chronionych, także na starszych Macach z Intelem (np. CVE-2025-43390, -43468).
Kernel/ANE/libxpc – poprawa izolacji i ograniczenie możliwości fingerprintingu/obserwacji połączeń systemowych.
Praktyczne konsekwencje / ryzyko
Ataki przeglądarkowe bez interakcji: samo wejście na złośliwą stronę może wywołać błąd pamięci i potencjalnie umożliwić wykonanie kodu w sandboxie przeglądarki lub kradzież danych między kartami. W środowiskach BYOD/Mobile-first to realny wektor spear-phishingu przez URL/QR.
Ryzyko dla danych poufnych: luki cross-origin i w Canvas zwiększają szansę na wyciek sesji/tokenów lub podgląd zawartości renderowanej w kontekście innej domeny.
Łańcuchy eksploatacji: choć Apple nie raportuje „exploited in the wild”, zestaw błędów WebKit + komponenty systemowe może tworzyć łańcuch sandbox-escape → EoP, szczególnie na stacjach z macOS (przyp. liczba poprawek ~105).
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników i działów IT (MDM/UEM):
Natychmiastowa aktualizacja do: iOS/iPadOS 26.1, macOS Tahoe 26.1, Safari 26.1 (dla Sonoma/Sequoia). Wymuś „latest” w politykach MDM (defer=0 dla urządzeń wysokiego ryzyka).
Aktualizuj Safari osobno na starych wydaniach macOS (Sonoma/Sequoia), bo przeglądarka ma własny cykl wydań.
WAF/DNS filtering: blokada znanych domen phishingowych; monitoruj nagłe crashe WebKit jako sygnał anomalii (telemetria EDR/MDM).
Test regresji aplikacji webowych: sprawdź działanie krytycznych aplikacji (SAML/OIDC) w Safari po poprawkach WebKit, zwłaszcza funkcje oparte o Canvas/WebGL.
Ćwiczenia phishingowe celowane w link/QR – wyszkolenie użytkowników mobilnych.
Dla zespołów bezpieczeństwa / AppSec:
Zaktualizuj zestawy testów DAST/SAST o scenariusze cross-origin i Canvas.
Bug bounty / VR tooling: rozważ adopcję automatycznych agentów do poszukiwania błędów (trend: Big Sleep).
Różnice / porównania z innymi przypadkami
W poprzednich wydaniach Apple często łatane były pojedyncze luki „actively exploited”. Tym razem, mimo braku dowodów na aktywne ataki, wolumen poprawek WebKit jest wysoki, a w kredytach pojawia się AI-agent jako współautor odkryć – to odmienny akcent względem klasycznych raportów od ZDI/TAG/indywidualnych badaczy.
Microsoft Incident Response (DART) opisał nowy backdoor SesameOp, który wykorzystuje OpenAI Assistants API jako kanał command-and-control (C2). To nie jest podatność w OpenAI ani błąd konfiguracji — to nadużycie legalnego interfejsu API w celu ukrycia komunikacji atakujących w „szumie” ruchu do popularnej usługi chmurowej. OpenAI wraz z Microsoftem zidentyfikowali i wyłączyli klucz oraz powiązane konto wykorzystywane przez sprawcę; funkcja Assistants API i tak ma zostać wycofana w sierpniu 2026 r.
W skrócie
Odkrycie: lipiec 2025 podczas reakcji IR; w środowisku ofiary utrzymywano długotrwałą obecność (cel: utrwalenie i szpiegostwo).
Kanał C2: OpenAI Assistants API użyte jako „magazyn/relayer” poleceń i wyników, z kompresją i warstwowaniem kryptografii (sym./asym.).
Kontrola zadań: opis assistanta = SLEEP / Payload / Result; identyfikacja hosta, vector store per hostname, wątki i kasowanie wiadomości po użyciu.
Status platformy: to nadużycie funkcji, nie exploit; OpenAI/Microsoft skoordynowali wyłączenie klucza/konta.
Kontekst / historia / powiązania
Nadużywanie legalnych usług (tzw. LOLBAS/LOLCLOUD) do C2 to trend widoczny od lat (GitHub, Slack, Telegram, Pastebin). W 2025 r. ENISA raportuje nasilenie wykorzystywania narzędzi AI przez grupy APT i cyberprzestępców (od inżynierii społecznej, przez rozwój malware, po ukrywanie operacji). To raczej „turbo-doładowanie” starych technik niż zupełnie nowe zdolności ofensywne.
Analiza techniczna / szczegóły luki
Składniki i uruchomienie
Loader:Netapi64.dll (obfuskacja Eazfuscator.NET), znacznik uruchomienia C:\Windows\Temp\Netapi64.start, mutex jednosesyjny; dekoduje i uruchamia właściwy moduł z pliku kończącego się na .Netapi64.
Backdoor:.NETOpenAIAgent.Netapi64 — wbrew nazwie nie używa SDK agentów ani modeli, tylko Assistants API do pobierania poleceń i wysyłki wyników jako wiadomości. Konfiguracja z zasobów: OpenAI_API_Key|Dictionary_Key_Name|Proxy; obsługa proxy systemowego, B64 hostnamen. Mutex: „OpenAI APIS”.
Protokół C2 przez Assistants API
Zapytanie listy vector stores w koncie; jeśli brak rekordu z hostname — tworzy nowy (wiąże hosta z artefaktami w OpenAI).
Pobranie listy Assistants (paginacja do 100). Pola sterujące: description oraz instructions. description przyjmuje jedną z wartości:
SLEEP → odczyt timeSLEEP z wiadomości (po thread_id|message_id) i pauza wątku,
Payload → pobierz treść polecenia po thread_id|message_id, wykonaj w osobnym wątku, usuń wiadomość i assistanta,
Result → opublikuj wynik jako nową wiadomość (description=Result).
Cała wymiana kompresowana i szyfrowana (warstwowo: symetrycznie i asymetrycznie).
Wejście do procesu i utrwalenie
Wektor uruchomienia: .NET AppDomainManager injection w komponenty Visual Studio za pomocą spreparowanego pliku .config; w środowisku ofiary działała dodatkowo siatka internal web shelli wspierających orkiestrację.
Detekcje Microsoft
Sygnatury AV: Trojan:MSIL/Sesameop.A (loader) i Backdoor:MSIL/Sesameop.A (backdoor).
Alerty EDR: m.in. „Possible .NET AppDomainManager injection”.
Przykładowe zapytanie huntingowe (Defender XDR) do wykrywania urządzeń łączących się z api.openai.com.
Praktyczne konsekwencje / ryzyko
Ukrywanie w legalnym ruchu: egress do popularnego API (OpenAI) utrudnia klasyczne IOC-based blocking i analitykę opartą wyłącznie o domeny.
Szyfrowanie + kompresja: minimalizuje telemetry „na drucie” i zwiększa koszt analizy NDR.
Ślad w chmurze dostawcy: użycie vector stores / threads / messages zostawia artefakty możliwe do skorelowania z kluczem API (pomaga po incydencie, jeżeli dostawca współpracuje).
Trend rynkowy: wg ENISA i OpenAI rosną próby nadużyć usług AI, ale zazwyczaj to przyspieszanie istniejących TTP — dlatego kontrola egress + tożsamości kluczy API staje się krytyczna.
Rekomendacje operacyjne / co zrobić teraz
Monitoring & hunting (SOC)
Widoczność egress do api.openai.com: koreluj proces → host → częstotliwość; zacznij od kwerendy Microsoft (lub odpowiednika w SIEM/NDR). Ustal listę dozwolonych procesów/serwerów korzystających z API OpenAI.
Reguły behawioralne: wykrywaj AppDomainManager injection, niespodziewane ładowanie DLL do procesów Visual Studio, tworzenie znaczników w C:\Windows\Temp\*Netapi64*.
Anomalie DNS/HTTP: długie okresy SLEEP, nietypowa paginacja Assistants i bursty wiadomości mogą tworzyć charakterystyczne wzorce czasowe (mimo TLS). (Wniosek na podstawie opisu protokołu.)
Kontrola dostępu i „egress governance” (IT/SecOps)
Allowlista egress dla AI: ograniczaj ruch do usług AI do zatwierdzonych podsieci/procesów; w proxy weryfikuj nagłówki autoryzacji i kontekst procesu (jeżeli wspiera). (Najlepsza praktyka zgodna z case’em Microsoft.)
Zarządzanie kluczami API: rotacja, skan tajemnic, ochrona przed wyciekiem; w razie incydentu — unieważnij klucze i wnioskuj u dostawcy o logi zasobów (threads/vector stores).
Wymuś PUA/EDR w trybie block i tamper protection w Defenderze; włącz cloud-delivered protection.
IR / odzyskiwanie
Artefakty na hoście: poszukuj mutexów „OpenAI APIS”, plików w C:\Windows\Temp\Netapi64.*, wpisów konfiguracyjnych .config wskazujących AppDomainManager.
Artefakty u dostawcy: listy Assistants, threads, messages, vector stores powiązane z kompromitowanym kluczem. (Współpraca z OpenAI/Microsoft okazała się skuteczna w tej sprawie.)
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Względem „klasycznego” cloud-C2 (np. Slack/Telegram): SesameOp semantycznie mapuje logikę C2 na artefakty platformy AI (description = SLEEP/Payload/Result, threads, vector stores), co utrudnia pisanie prostych sygnatur i wymusza analizę zachowań aplikacji zamiast samych domen.
Względem generowania malware przez LLM: tu model nie jest wykorzystywany do generowania treści, a interfejs API – do transportu (stealth C2). To potwierdza obserwację OpenAI, że aktorzy głównie „dokładają AI do starych playbooków”.
Podsumowanie / kluczowe wnioski
SesameOp pokazuje, że governance nad ruchem do usług AI i bezpieczeństwo tożsamości API to nowe „must-have” w SOC. Należy inwentaryzować legalne użycia api.openai.com, egzekwować egress allowlisty, szukać behawioralnych anomalii .NET oraz artefaktów na hostach. Dobra współpraca z dostawcami (tu: Microsoft & OpenAI) przyspiesza neutralizację takich nadużyć.
Microsoft Security Blog — „SesameOp: Novel backdoor uses OpenAI Assistants API for command and control”, 3 listopada 2025. (Podstawowa analiza techniczna, detekcje, hunting.) (Microsoft)
OpenAI — „Disrupting malicious uses of AI: October 2025”. (Kontekst nadużyć usług AI, polityka egzekwowania.) (OpenAI)
BleepingComputer — „Microsoft: SesameOp malware abuses OpenAI Assistants API in attacks”, 3 listopada 2025. (Zewnętrzne potwierdzenie i streszczenie.) (BleepingComputer)
The Hacker News — „Microsoft Detects 'SesameOp’ Backdoor Using OpenAI’s API…”, 4 listopada 2025. (Dodatkowe omówienie, konsolidacja faktów.) (The Hacker News)