Archiwa: AI - Strona 92 z 94 - Security Bez Tabu

LPI Security Essentials (Moduł 022.4) -Szyfrowanie Danych

Zanim zaczniesz

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.

Czytaj dalej „LPI Security Essentials (Moduł 022.4) -Szyfrowanie Danych”

Microsoft ujawnia „Whisper Leak”: atak boczny ujawniający temat rozmów z LLM mimo szyfrowania

Wprowadzenie do problemu / definicja luki

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):

  1. 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.
  2. Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
  3. Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
  4. 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)

  1. 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.
  2. Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
  3. Packet injection / cover traffic — wtryski dodatkowych ramek/”szumu” (koszt: 2–3× narzut pasma).
  4. Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
  5. 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

  1. Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
  2. McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
  3. Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
  4. Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
  5. The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)

GlassWorm znowu na OpenVSX: trzy nowe rozszerzenia VS Code z ukrytym malware

Wprowadzenie do problemu / definicja luki

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)

  1. Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
    • ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs.
  2. Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
  3. 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

Windows (PowerShell)

$paths = @("$env:USERPROFILE\.vscode\extensions", "$env:USERPROFILE\.vscode-oss\extensions")
$pattern = '[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]'
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem -Recurse -Include *.js,*.ts -Path $p |
      Select-String -Pattern $pattern -AllMatches | Select-Object Path,LineNumber
  }
}

Prosty YARA snippet (heurystyka):

rule Invisible_Unicode_PUA_Eval_JS {
  meta: author="BlueTeam" description="GlassWorm-like hidden code"
  strings:
    $pua = /[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]+/u
    $eval = /eval\s*\(/ nocase
  condition:
    uint16(0) == 0xFFFE or uint16(0) == 0xFEFF or filesize < 5MB and $pua and $eval
}

2) Usuwanie podejrzanych rozszerzeń

# VS Code
code --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
code --uninstall-extension ai-driven-dev.ai-driven-dev
code --uninstall-extension adhamu.history-in-sublime-merge
code --uninstall-extension yasuyuky.transient-emacs

# VSCodium
codium --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
codium --uninstall-extension ai-driven-dev.ai-driven-dev
...

3) Twardnienie łańcucha wydawniczego

  • 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

  1. BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
  2. BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
  3. 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)
  4. Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
  5. Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)

Ollama i NVIDIA: nowe luki uderzają w infrastrukturę AI. Co musi zrobić dział SecOps?

Wprowadzenie do problemu / definicja luki

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.
    • NVIDIAContainer Toolkit/GPU Operator: CVE-2025-23266 (krytyczny container escape, CVSS 9.0) i CVE-2025-23267 (link-following/DoS).
  • 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.
  • Naprawy:
    • NVIDIA Container Toolkit ≥ 1.17.8 (oraz odpowiednie wersje GPU Operator/Device Plugin/MIG Manager).
    • 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

  1. 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+.
  2. 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.
  3. 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:
# Nginx (skrót)
server {
  listen 443 ssl http2;
  server_name ollama.example.com;
  ssl_certificate ...; ssl_certificate_key ...;

  auth_basic "Restricted";              # tymczasowo
  auth_basic_user_file /etc/nginx/.htpasswd;

  location / {
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:11434;
  }
}

(Wiz podkreśla brak natywnego auth w wielu wdrożeniach; reverse proxy to „must”.)

  • W instancjach lokalnych wymuś bind tylko do loopback:
# Linux (systemd override)
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=127.0.0.1"

3) Twardnienie kontenerów i K8s

  • Zabroń --privileged i host-mountów; używaj rootless (jeśli możliwe), seccomp/apparmor i redukcji capabilities:
# PodSecurityContext (skrócone)
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile: { type: RuntimeDefault }
  capabilities: { drop: ["ALL"] }
  • Segmentuj sieć przy pomocy NetworkPolicy – oddziel inference od reszty:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-only-proxy, namespace: ai }
spec:
  podSelector: { matchLabels: { app: ollama } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { name: ingress } }
      ports: [{ protocol: TCP, port: 11434 }]

4) Rejestry modeli i „model supply chain”

  • 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 Operatorbłę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

  1. 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.
  2. Nie wystawiaj surowych endpointów inferencji do Internetu; dodaj auth i TLS na brzegu.
  3. Odchudź uprawnienia kontenerów, stosuj Pod Security i NetworkPolicy, monitoruj anomalia w hookach OCI i modyfikacje ld.so.preload.
  4. 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)

Daylight pozyskuje 33 mln dol. na „agentowe” MDR. Co to oznacza dla SOC-ów?

Wprowadzenie do problemu / definicja luki

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

  1. Pilot 60–90 dni: wybrane segmenty (np. wybrane OU w IdP, część floty EDR, wycinek chmury). Zdefiniuj KPI: MTTD/MTTR, % zautomatyzowanych remediacji, precyzja triage.
  2. RACI dla agentów: policy gates dla akcji o wysokim wpływie (disable użytkownika, kwarantanna zasobu chmurowego).
  3. Playbooki „deterministyczne”: ustandaryzowane runbooki SOAR jako „rails” dla agentów; logowanie decyzji i wyników.
  4. Ocena integracji: sprawdź konektory do twoich krytycznych systemów (IdP, EDR/XDR, chmury, SaaS).
  5. Model zagrożeń AI: włącz AI threat modeling (np. ryzyka „model misuse”, nadmierna autonomiczność, eskalacja uprawnień).
  6. 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

  1. SecurityWeek: Daylight Raises $33 Million for AI-Powered MDR Platform (05.11.2025). (SecurityWeek)
  2. Blog Daylight (Hagai Shapira): Lighting the Next Chapter… (04.11.2025). (daylight.ai)
  3. SiliconANGLE: Daylight Security raises $33M… (04.11.2025). (SiliconANGLE)
  4. CTech / Calcalistech: Cyber startup Daylight raises $33 million… (04.11.2025). (ctech)
  5. Daylight – About / Leadership. (daylight.ai)

Apple łata 19 luk w WebKit. Aktualizacje iOS 26.1, macOS Tahoe 26.1 i Safari 26.1 – co musisz wiedzieć

Wprowadzenie do problemu / definicja luki

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

W skrócie

  • Produkty i wersje: iOS/iPadOS 26.1 (wydane 3 listopada), macOS Tahoe 26.1, Safari 26.1 (dla macOS Sonoma/Sequoia).
  • 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):

  1. 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).
  2. Aktualizuj Safari osobno na starych wydaniach macOS (Sonoma/Sequoia), bo przeglądarka ma własny cykl wydań.
  3. WAF/DNS filtering: blokada znanych domen phishingowych; monitoruj nagłe crashe WebKit jako sygnał anomalii (telemetria EDR/MDM).
  4. Hardening Safari: wyłącz automatyczne otwieranie „bezpiecznych” plików, ogranicz uprawnienia stron (kamera/mikrofon/clipboard).
  5. Test regresji aplikacji webowych: sprawdź działanie krytycznych aplikacji (SAML/OIDC) w Safari po poprawkach WebKit, zwłaszcza funkcje oparte o Canvas/WebGL.
  6. Ć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.
  • Threat hunting: wzbogacenie detekcji o sygnały WebKit (crash logs, abnormal Safari restarts).
  • 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.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj natychmiast: iOS/iPadOS 26.1, macOS Tahoe 26.1, Safari 26.1.
  • 19 luk w WebKit to materialne ryzyko dla każdego, kto korzysta z Safari lub WebView (a więc praktycznie wszystkich urządzeń iOS).
  • AI w VR (Big Sleep) przyspiesza wykrywanie podatności – spodziewaj się częstszych, „grubszych” paczek łatek.

Źródła / bibliografia

  1. SecurityWeek – „Apple Patches 19 WebKit Vulnerabilities”, 4 listopada 2025. (SecurityWeek)
  2. Apple – „About the security content of iOS 26.1 and iPadOS 26.1” (Published: Nov 3, 2025). (Apple Support)
  3. Apple – „About the security content of macOS Tahoe 26.1” (Published: Nov 3, 2025). (Apple Support)
  4. Apple – „About the security content of Safari 26.1” (Published: Nov 4, 2025). (Apple Support)
  5. Google Cloud Blog – „Our Big Sleep agent makes a big leap” (opis projektu i roli w wykrywaniu luk). (Google Cloud)

SesameOp — backdoor wykorzystujący OpenAI Assistants API do ukrytego C2. Analiza i zalecenia dla SOC

Wprowadzenie do problemu / definicja luki

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.).
  • Łańcuch: loader Netapi64.dll (obf. Eazfuscator.NET) + backdoor OpenAIAgent.Netapi64 ładowany przez .NET AppDomainManager injection.
  • 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: .NET OpenAIAgent.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

  1. Zapytanie listy vector stores w koncie; jeśli brak rekordu z hostname — tworzy nowy (wiąże hosta z artefaktami w OpenAI).
  2. 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).
  3. 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ć.

Źródła / bibliografia

  1. ENISA Threat Landscape 2025 (TLP:CLEAR), październik 2025. (Trendy wykorzystania AI przez aktorów zagrożeń.)
  2. Microsoft Security Blog — „SesameOp: Novel backdoor uses OpenAI Assistants API for command and control”, 3 listopada 2025. (Podstawowa analiza techniczna, detekcje, hunting.) (Microsoft)
  3. OpenAI — „Disrupting malicious uses of AI: October 2025”. (Kontekst nadużyć usług AI, polityka egzekwowania.) (OpenAI)
  4. BleepingComputer — „Microsoft: SesameOp malware abuses OpenAI Assistants API in attacks”, 3 listopada 2025. (Zewnętrzne potwierdzenie i streszczenie.) (BleepingComputer)
  5. The Hacker News — „Microsoft Detects 'SesameOp’ Backdoor Using OpenAI’s API…”, 4 listopada 2025. (Dodatkowe omówienie, konsolidacja faktów.) (The Hacker News)