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

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

Wprowadzenie do problemu / definicja luki

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

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

W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły luki

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

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

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

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

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

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

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

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

Co mogło wyciec?

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

Praktyczne konsekwencje / ryzyko

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

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

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (IT/SecOps)

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

Dla użytkowników

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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